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

[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]

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 ?

[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]

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]

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

[DarkSnoop]

# ...

[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

[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

[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

[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.

[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

[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

[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

[Jürgen]

Hallo Ralf,

ich habe zwischendurch das neue Image von Robert mit Debian 9 aufgespielt. Inzwischen läuft auf dem Beagle auch noch ein NGINX Proxy und das Alexa Gateway.
An sich keine Probleme. Nutzt Du die SD Karte, oder hast Du das Image in in den Flash geschrieben?
Was mir nur auffällt: Bei der Telnet Anmeldung braucht der Beagle ewig, bis der Eingabeprompt erscheint.

Gruß Jürgen

[hubidoo]

Hallo an die IBB Beagleboner,

bei mir laufen ebenfalls seit 2016 drei BBBs mit Roberts Cape bestückt.
Alle drei laufen mit Roberts Original-Image auf dem internen 4Gb Flash.

Bei allen BBBs habe ich das Problem, dass bei intensiven Schreibzugriffen bei Updates, in der Regel beim Entpacken von .deb files, plötzlich das Dateisystem korrupt wird und nur noch read-only ist. Nach Booten vom Roberts Original-Image via SD-Card und Reparatur des Dateisystems kann ich dann nach gefühlten zehn Reparaturen die Updates zu Ende bringen. Bisher befand ich mich immer noch auf Jessie, also Debian 8, was so langsam mal angehoben werden müsste.

Mit 1wire hatte ich bis auf eine Störung, die ich auf ein streuendes Netzteil eines SAT Multischalters zurück führe, keine Probleme.
Bis auf das Update-Problem laufen die BBBs völlig störungsfrei. Einer davon wird vom HS als Gateway benutzt. knxd ist allerdings noch die Version 0.11.18. Mit einer frühen 0.14er Version von 2017 hatte ich massive Stabilitäts-Probleme und hatte das damals aufgegeben.

Da ich allerdings seit den ETS 5.5er Updates nicht mehr über den knxd programmieren kann, wollte ich einen Versuch mit der aktuellen 0.14er Version starten, davor aber alles auf den aktuellen Stand bringen.
Ein gestriger Versuch, eines der BBBs auf Stretch anzuheben, hat das Dateisystem völlig zerstört. Nach der Reparatur waren 6445 files in lost+found.
Da ich sowohl tägliche tar Archive auf ein NFS share erstelle, als auch tägliche Bareos Backups mache, sind die Daten an sich komplett vorhanden.

Beim Restore hatte ich die gleichen Probleme. Ein Entpacken des tar Archivs führte in mehreren Versuchen immer wieder zu einem korrupten Dateisystem.
Selbst als ich das tar Archiv auf dem file Server entpackte und via cp -a die Verzeichnisstruktur zurück kopieren wollte, traten die Dateisystemfehler auf.
Ich hatte verschiedene Netzteile getestet, alle mit mindestens 2-2,5A. Auch wenn das Cape nicht aufgesteckt ist, kommt es zu diesen Dateisystem-Korruptionen.
Die Ursache ist mir aktuell nicht klar. Ich vermute, dass es mit irgendeiner Einstellung oder Kernel-Parameter zusammen hängen könnte, da ich das Problem
a) von Anfang an hatte
b) es bei allen drei BBBs auftritt
Alle drei BBBs sind von element14.

Aktuell habe ich via NFS mount und chroot das System auf Stretch angehoben, aber spätestens beim zurück kopieren, wird das wieder auftreten, wenn ich die Ursache nicht finde. Alternativ überlege ich mir gerade, ob ich das Dateisystem tatsächlich via NFS anbinde, um das Problem zu umschiffen. Das ist immer noch schneller, als die SD-Karte, bei der das Problem übrigens ebenfalls nicht auftritt. Es betrifft nur den internen Flash.

Habt Ihr die original BBBs oder ebenfalls die von element14?
Die Kernfragen sind für mich:
Hat jemand ähnliche Erfahrungen mit korruptem Flash-Dateisystem und/oder bereits eine Ursache dafür identifiziert?

Könnt Ihr über die ETS 5.7.2 aktuell über den knxd mehrere Linien inklusive physikalische Adressen programmieren?
Wenn ja, welche Version vom knxd läuft da genau und wie sieht das Setup aus?
In der 0.11.18er Version sind die Configs grundverschieden. Im Prinzip ist das Setup noch so wie von 2016, als ich mit der ETS Version kleiner 5.5 alles am Laufen hatte.

Viele Grüße
Ralf