Beaglebone Cape mit KNX & 4x Onewire; Enocean, RTC, eHZ möglich

[hubidoo]

Hallo Jürgen,

nein, das betrifft nur das interne Flash. Via SD-Card passiert das nicht.
Auf jeden Fall ist das entweder ein Interrupt- oder Kernel-Parameter Problem spezifisch für den Flash-Speicher.
Habe von Daniel gerade die Rückmeldung gehört, dass er ebenfalls einen element14 BBB hat und bei ihm klappte das problemlos.
Da ist also irgendwas anders als bei mir.

Telnet? Du meinst vermutlich SSH/Putty? Da stimmt die Namensauflösung nicht im Netz, wenn die Anmeldung lange dauert.
Das Zusammenspiel DHCP<->DNS muss passen im Netz und zwar für für Hosts und IPs, dann klappts auch mit den Nachbarn.
pfSense ist hier zu nennen. Damit erschlägt man auch IPSec/IKEv2 oder OpenVPN für VoIP-Telefone.

Ich habe für mich beschlossen, in Zukunft via NFS zu booten.
Das hat den Charme, dass ich nur ein System warten muss und Änderungen erhalten ad hoc alle drei Systeme.
Ein Ausfall ist ebenfalls unwahrscheinlicher, da auf dem Backend Storage Server ein FreeBSD/FreeNAS ZFS System werkelt.
Entwickeln ist ebenfalls einfacher, da man sich das NFS Share auch auf dem Linux PC mounten kann.
Die Unterscheidung der Hostnamen und Jobs läuft über die Namensauflösung und damit ist das abhängig von der MAC Adresse.
Vermutlich werde ich auch die Raspberries auf NFS umstellen. Die sind ja eh anfälliger wegen den SD-Karten, wobei mein erster seit 2012 durch läuft im 24/7 Betrieb.
Ich habe auch einen im Außenbereich als Hühnerhaus-Server, der auch mal tiefe Minustemperaturen aushalten muss. Bisher keine Ausfälle, läuft alles gechillt durch.
Einzige Ausnahme sind meine BBBs mit dem Flashproblem bei Updates.
Der Teufel steckt, wie immer, im Detail.

Grüße
Ralf

[hubidoo]

Hallo zusammen,

zur Info: nachdem ich von Scratch begonnen und das aktuelle und offizielle debian 9 beaglebone Image geflasht hatte, war der Spuk zu Ende.
Damit ist das filesystem nun stabil, d.h. der Fehler liegt irgendwo in dem Image von Robert vergraben. Gefunden habe ich es noch nicht.
Jetzt mache ich erstmal mit dem neuen Image weiter. 1wire, LDAP-Anbindung, automounter, backup dump und bareos-fd funktioniert schon mal wieder.
knxd und enocean fehlt noch.

Grüße
Ralf

[Jürgen]

Hallo Ralf,

danke für die Info. Würdest Du eventuell - so wie Robert - ein funktionierendes Image zur Verfügung stellen?

Gruß Jürgen

[Robert]

nachdem ich von Scratch begonnen und das aktuelle und offizielle debian 9 beaglebone Image geflasht hatte, war der Spuk zu Ende.
Damit ist das filesystem nun stabil, d.h. der Fehler liegt irgendwo in dem Image von Robert vergraben. Gefunden habe ich es noch nicht.

Sehr wahrscheinlich hast du ein "sehr neues" BBB mit einem neuen eMMC. Die Hersteller kriegen meist das Comand Queuing des eMMMC 5.1 standards hin, was bei hoher/gleichzeitiger Schreiblast dazu führt, dass sich der eMMC verschluckt. Dafür gibt es dann "quirks" um dem Kernel zu verraten, dass der eMMC das nicht hinbekommt (was er laut Standard können müsste). Daher: neues BBB mit altem Kernel kann da problematisch sein.

[Energiezwerg]

Hallo Jürgen,
ich hatte auch das Problem, dass das Image mit Debian 8 vom Robert zu alt war. Ich hatte es nicht störungsfrei geschafft, python auf 3.5 oder höher zu updaten.

Anbei meine Anleitung, wie ich mein BBB auf den aktuellen Stand gebracht habe.

Mein Zeil war: BBB Debian 9 oder 10 mit knxd und 1-wire

Ablauf:
# debian 9.9 flahser laden und flashen
https://rcn-ee.net/rootfs/2019-06-15...-15-2gb.img.xz

User: debian, pass: temppwd

Dann einen neuen user z.B. smarthome anlegen.

> su
> mkdir /home/smarthome
> useradd smarthome --home /home/smarthome -c /bin/bash
> nano /etc/sudoers
# User alias specification
smarthome ALL=(ALL:ALL) ALL
> passwd smarthome
# prompt auf /bin/bash umstellen
> chsh smarthome -s /bin/bash
> logout/in
# user debian löschen
> userdel --remove debian
# alles auf deutsch stellen
> sudo dpkg-reconfigure locales
> sudo dpkg-reconfigure tzdata
# alles aktualisieren
> sudo apt-get update
> apt-get upgrade

# 1-wire installieren
# Dann den owserver konfigurieren. Bei mir läuft alles mit folgenden Eintragen ohne Probleme.

> sudo apt-get install owserver owhttpd
> sudo vi /etc/owfs.conf
# ibb cape
server: i2c = dev/i2c-2:0
server: i2c = dev/i2c-3:0
server: i2c = dev/i2c-4:0
server: i2c = dev/i2c-5:0

owserver starten und testen

> sudo systemctl restart owserver

http://<ip>:2121

# KNX Server installieren

> sudo apt-get install git-core build-essential fakeroot debhelper libusb-1.0 libsystemd-dev dh-systemd libev-dev libfmt3-dev
> git clone https://github.com/knxd/knxd.git
> cd knxd
> dpkg-buildpackage -b -uc
# .... warten
> cd ..
> sudo dpkg -i knxd_*.deb knxd-tools_*.deb

knxd konfigurieren:

> sudo systemctl edit --full knxd
[Unit]
Description=KNX Daemon
After=network.target knxd.socket
Requires=knxd.socket

[Service]
EnvironmentFile=/etc/knxd.ini
ExecStart=/usr/bin/knxd /etc/knxd.ini
User=knxd
Group=knxd
Type=notify

#Restart=on-failure
#RestartSec=10

[Install]
WantedBy=multi-user.target network-online.target
Also=knxd.socket

# knx Konfiguration mit knxd.ini

> sudo nano /etc/knxd.ini
[A.tcp]
server = knxd_tcp
systemd-ignore = true
[C.tpuarts]
device = /dev/ttyS2
driver = tpuart
[debug-server]
name = mcast:knxd
[debug-tunnel]
trace-mask = 0x0
[main]
cache = B.cache
addr = 1.1.240
client-addrs = 1.1.240:8
connections = server,A.tcp,C.tpuarts
systemd = systemd
[server]
debug = debug-server
discover = true
server = ets_router
tunnel = tunnel
[tunnel]
debug = debug-tunnel

Dann müssen zwingend die Berechtigungen angepasst werden.

> sudo usermod -a -G dialout knxd
> sudo usermod -a -G tty knxd

Später habe ich ein upgrade auf Debian 10 (buster) gemacht. Auch damit läuft bis jetzt alles ohne Probleme.

smarthome:[~]> sudo cat /etc/apt/sources.list
[sudo] Passwort für smarthome:
deb http://deb.debian.org/debian buster main contrib non-free
deb http://deb.debian.org/debian buster-updates main contrib non-free
deb http://deb.debian.org/debian-security buster/updates main contrib non-free
deb [arch=armhf] http://repos.rcn-ee.com/debian/ buster main

[hubidoo]

Sehr wahrscheinlich hast du ein "sehr neues" BBB mit einem neuen eMMC. Die Hersteller kriegen meist das Comand Queuing des eMMMC 5.1 standards hin, was bei hoher/gleichzeitiger Schreiblast dazu führt, dass sich der eMMC verschluckt. Dafür gibt es dann "quirks" um dem Kernel zu verraten, dass der eMMC das nicht hinbekommt (was er laut Standard können müsste). Daher: neues BBB mit altem Kernel kann da problematisch sein.

Hallo Robert,

die BBBs sind alle von 2016 und liefen mit 4.8.0-rc8-bone1, der im Oktober 2016 raus kam. Der aktuelle "ohne Probleme" ist der 4.14.71 unter debian 9.11.
Unter /sys/kernel/debug/mmc1 ist bei beiden Kernel timing spec und clock identisch, Rest auch:

#cat /sys/kernel/debug/mmc1/ios
clock: 52000000 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 3 (8 bits)
timing spec: 1 (mmc high-speed)
signal voltage: 0 (3.30 V)
driver type: 0 (driver type B)

Eine dynamische Anpassung nach I/O erfolgt auch nicht. Hatte gerade einen Schreibtest mit dd laufen lassen.
Wo müsste ich das denn sehen?

Viele Grüße
Ralf

[hubidoo]

Hallo Ralf,

danke für die Info. Würdest Du eventuell - so wie Robert - ein funktionierendes Image zur Verfügung stellen?

Gruß Jürgen

Da ist eigentlich nichts großartiges zu machen.
Was ich getan hatte, entspricht 1:1 dem, was der Energiezwerg bereits berichtete plus noch meinen internen Kram mit Systemzugangsgruppen für sudo und ssh via LDAP, bareos-fd für Backups und automounter für NFS, was ich für zusätzliche tar Archive, dumps, und Austausch letsencrypt Zertifikate verwende.

Viele Grüße
Ralf

[DarkSnoop]

# ...

[awknx]

Hallo BBCapes,

ich wollte mit der neuen NG 1.7 endlich mal meine alte Installation neu aufsetzen. Da es leider für mich als Linux-Trottel kein fertiges Image gibt, wollte ich das nun zu Fuß machen, bleibe aber an diversen Stellen hängen.

1. OK - Aktuelles Image (bone-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz) auf eine SD übertragen und in den BB geflasht, sowie auf dem BB eine feste IP eingestellt

2. OK - Nach der Komplettanleitung NG installiert und konfiguriert.

3. Nach der Konplettanleitung knxd installiert und da hänge ich nun auch schon, weil sich die Konfiguration bei Debian 10 wohl grundlegend geändert hat. Ich habe versucht, das Ganze mit dem Eintrag in die knxd.conf zu lösen:

smarthome@smarthome:~$ sudo systemctl status knxd.socket
● knxd.socket - KNX Daemon (socket)
Loaded: loaded (/lib/systemd/system/knxd.socket; enabled; vendor preset: enabled)
Active: active (listening) since Tue 2020-04-14 09:42:43 CEST; 13s ago
Listen: /var/run/knx (Stream)
[::]:6720 (Stream)
Tasks: 0 (limit: 1027)
Memory: 20.0K
CGroup: /system.slice/knxd.socket

Apr 14 09:42:43 smarthome systemd[1]: Listening on KNX Daemon (socket).
smarthome@smarthome:~$ sudo systemctl status knxd.service
● knxd.service - KNX Daemon
Loaded: loaded (/etc/systemd/system/knxd.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2020-04-14 09:43:03 CEST; 124ms ago
Main PID: 18875 (knxd)
Tasks: 1 (limit: 1027)
Memory: 368.0K
CGroup: /system.slice/knxd.service
├─18875 /usr/bin/knxd -e 0.0.1 -E 0.0.2:8 -c -b ipt:192.168.2.75
└─18878 /usr/bin/knxd -e 0.0.1 -E 0.0.2:8 -c -b ipt:192.168.2.75

Apr 14 09:43:03 smarthome systemd[1]: Starting KNX Daemon...

Der Service wird mir nur fehlerfrei angezeigt, wenn ich es als IP Schnittstelle (ipt definiere.

Was da mir da aber nun völlig abgeht, ist die physische Verbindung zum Cape. Wo und wie muss ich das in der knxd.conf hinterlegen? Fehler sehe ich auch im NG nicht, aber es passiert halt auch nichts.

4. Den Onewire konnte ich erst mal gar nicht richtig installieren, da bekam ich gleich eine Fehlermeldung vom APT. Erst nachdem ich wie oben angegeben die owfs.conf wie folgt ergänzt habe, war die nochmalige Installation möglich:

GNU nano 3.2 /etc/owfs.conf

# Sample configuration file for the OWFS suite for Debian GNU/Linux.
#
#
# This is the main OWFS configuration file. You should read the
# owfs.conf(5) manual page in order to understand the options listed
# here.

######################## SOURCES ########################
#
# With this setup, any client (but owserver) uses owserver on the
# local machine...
! server: server = 127.0.0.1:4304
#
# ...and owserver uses the real hardware, by default fake devices
# This part must be changed on real installation
server: i2c = dev/i2c-2:0
server: i2c = dev/i2c-3:0
server: i2c = dev/i2c-4:0
server: i2c = dev/i2c-5:0
#
# USB device: DS9490
#server: usb = all
#
# Serial port: DS9097
#server: device = /dev/ttyS1
#
# owserver tcp address
#server: server = 192.168.10.1:3131
#
# random simulated device
#server: FAKE = DS18S20,DS2405
#
######################### OWFS ##########################
#
#mountpoint = /mnt/1wire
#allow_other



smarthome@smarthome:~$ sudo systemctl start owserver
Job for owserver.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status owserver.service" and "journalctl -xe" for details.
smarthome@smarthome:~$

Aber irgendwas stimmt trotzdem nicht. Mit den beiden angegebenen Befehlen sehe ich auch nicht mehr.

5. Mit EnOcean habe ich noch gar nicht angefangen...


Ich hoffe, ihr/Robert könnt mir da weiterhelfen. Für Leute wie mich, wäre ein aktuelles, vorkonfiguriertes Images von Robert Gold wert ;-)

Viele Grüße
Andi

[awknx]

Update:

1-wire habe ich nun zum Laufen bekommen - unklar, wo das Problem lag.

knx habe ich zum Laufen bekommen - statt der knx.conf habe ich eine knx.ini angelegt und mit den Daten aus dem Thread gefüllt. Damit ging es dann. Vermutlich ist auf meinem System damit nun aber ein Durcheinander der verschiedenen Konfigurationen vorhanden. Eine saubere Festlegung, was wo rein muss, wäre sinnvoll.

enocean tappe ich noch völlig im Dunkeln.


Und was mich noch ziemlich beschäftigt hat, ist, dass das aktuelle Image für den BBB eine vorkonfigurierte Oberfläche mit Namen Cloud9 enthält, die verhindert, dass man einen vernünftigen Webserver (SmartVisu) laufen lassen kann. Da muss man erst zig Pakete/Dienste runterwerfen, damit der Apache läuft...

[awknx]

Wäre schön, wenn ihr mir mit Enocean noch auf die Sprünge helfen könntet :-)

Update: Läuft - Robert konnte mir da weiterhelfen. Das Problem war an anderer Stelle. Die Installation von SmarthomeNG nach Komplettanleitung installiert das Paket pyserial nicht mit, welches aber vom Plugin benötigt wird...

[awknx]

Zum knxd über das Cape noch eine Frage. Ist das dann ein KNX IP Router? Ich frage deshalb so blöd, weil ich testweise zwei Sonoff integrieren wollte. Das geht grundsätzlich auch mit der KNX-Firmware, nur landen die KNX-Befehle bisher nicht auf dem Bus (werden wohl per Multicast gesendet). Die Ansteuerung über WLAN funktioniert einwandfrei.

Vielleicht habe ich da in der Konfiguration des knxd noch einen Wurm drin - siehe #294 ?

[bmx]

Wäre schön, wenn ihr mir mit Enocean noch auf die Sprünge helfen könntet :-)

Update: Läuft - Robert konnte mir da weiterhelfen. Das Problem war an anderer Stelle. Die Installation von SmarthomeNG nach Komplettanleitung installiert das Paket pyserial nicht mit, welches aber vom Plugin benötigt wird...

Welches von Dir genutzte Plugin braucht pyserial?

[awknx]

enocean

[awknx]

So, der knxd läuft nun auch rund und es lassen sich die Sonoff über SmarthomeNG und die Smartvisu per KNX ansteuern. Das macht richtig Spass, weil die Teile billig sind und sich einfach für KNX pimpen lassen.

Zur Info unter Debian 10:

Es braucht da nur die knxd.conf mit dem Eintrag

KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -c -D -R -T -S -b tpuarts:/dev/ttyS2"

also nicht die im Thread vorkommende knxd.ini


Jetzt bin ich wieder glücklich mit meinem BBB und dem Cape vom Robert :-)