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

[Jürgen]

Hallo elschrunner

Robert war hier schon ein halbes Jahr nicht mehr online. Seine letzte Aussage war, dass er für das alte Beagle Board keine Capes mehr baut, weil die inzwichen zu langsam sind. Für One Wire gibt es ja spezielle Server, dazu findest Du hier im Forum einige Beiträge.
Mein Cape läuft hoffentlich noch lange weiter, denn der Beagle macht auch SmarthomeNG, Alexa und Firewall.

Schreib doch Robert mal an, ob er noch ein Cape auf Lager hat.

Gruß Jürgen

[elschrunner]

Gibt es dieses BBB IBBCape noch irgendwo oder einen Ersatz dafuer ?

[GHild]

Mir persönlich ist die gelbe Kurve etwas zu glatt für einen 1-Wire Temperatursensor.

Du könntest mal prüfen, ob die Sensoren vernünftige Werte liefern, am besten direkt über den Port 2121 am BBB.

192.168.xx.yy:2121

Bei mir sieht die Config-Datei anders aus, siehe hierzu Post #321:
https://knx-user-forum.de/forum/öffe...69#post1637669


Und hier noch ein Beispiel, wie ich die 1-Wire Werte auf den KNX-Bus bekomme:

ist:
    type: num
    visu_acl: rw                                                                                                                                                                        
    knx_dpt: 9                                                                                                                                                                          
    database: 'yes'                                                                                                                                                                    
    enforce_updates: 'true'                                                                                                                                                              
    ow_addr: 28.3A959A070000                                                                                                                                                            
    ow_sensor: T                                                                                                                                                                        
    knx_send: 3/0/10                                                                                                                                                                    
    knx_cache: 3/0/10                                                                                                                                                                    
    knx_init: 3/0/10        
​

[ugobald]

Jetzt habe ich festgestellt, dass in Home Assistant unterschiedliche Werte von den 1-Wire-Temperatursensoren ankommen und zwar abhängig davon, ob ich die KNX oder 1-Wire-Integration verwende:

2023-08-09 17_42_42-Window.png

Die Werte vom gleichen Sensor im Vergleich:

2023-08-09 17_43_33-Window.png
Die gelbe Kurve, also die Werte von der 1-Wire-Integration scheinem mir die korrekten zu sein.

Jetzt könnte es folgende Fehlerquellen geben:

1. Beaglebone mit 1-Wire und KNX-Schnittstellen (owfs und eibd)
2. SmartHomeNG, welches die 1-Wire-Adressen an KNX-Gruppenadressen weiterleitet
3. Die KNX-Integration von Home Assistant, die die Werte falsch übernimmt oder falsch anzeigt

Um die Suche ein bisschen systematisch anzugehen, würde ich bei Nr. 1 anfangen wollen und dazu würde ich gerne owfs sowie eibd updaten wollen.

Wie mache ich das am einfachsten, ohne dass es mir die Config zerschießt?
Bei mir scheitert es schon daran, den Installationsordner auf dem Beaglebone zu finden.

Die /etc/owfs.conf sieht momentan so aus:

# 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 ########################
!server: server = localhost:4304
server: i2c=ALL:0

####################### OWHTTPD #########################

http: port = 2121
alias = /opt/ow-alias

####################### OWFTPD ##########################

ftp: port = 2120

####################### OWSERVER ########################

server: port = 4304

Vielen Dank

[ugobald]

Hi zusammen, mittlerweile habe ich in den Web Interfaces von KNX und OW realistische Werte anstatt der Nullen. Wahrscheinlich war ich einfach nicht geduldig genug und die erste Einspeiserunde war noch nicht vorbei
Jedenfalls ging der Transfer viel einfacher und schneller als gedacht, jetzt werde ich noch SHNG auf dem BBB deaktivieren und das ganze dann so ruhen lassen.

Danke euch!

/Nachtrag:
Was habt ihr eigentlich bei onewire für einen Wert bei cycle eingestellt?
Entspricht das dem Intervall, nachdem jeder Sensor reihum abgefragt wird?

[bmx]

In SHNG kannst Du z.B. im smarthome-warnings.log schauen ob es dort Fehler oder Warnungen gibt. Das Admin Interface bietet für das knx Plugin eine Oberfläche wo auch Statistiken zu den Gruppenadressen gezeigt werden. Wenn das dort alles leer ist, läuft es wohl eher nicht ;-)
Das ist mit Onewire ähnlich, auch dort sollten im Webinterface Werte zu sehen sein. Wenn nicht, dann kann zumindest SHNG nichts vom owserver empfangen. Dann kann man immer noch mal Onewire via http Oberfläche anschauen

[ugobald]

Klingt logisch. SmartVisu benötige ich eigentlich gar nicht und würde es daher deaktivieren.
Wie kann ich im neuen SHNG sehen, ob die Verbindung zu KNX und 1-Wire steht? Bei 1-Wire hatte ich im SHNG Webinterface z. B. überall eine Temperatur von 0 °C stehen, es wurde also kein Wert übermittelt. Oder geht das nur in der ETS, wenn die Gruppenadressen beschrieben werden?

[GHild]

Bei mir auf dem Pi sieht es auch wie bei dir, d.h. die Dienste sind 'Nicht aktiv'. Sie laufen ja auch nicht auf dem Pi, sondern auf dem BBB.

Wenn du die smartVISU nutzt, musst du dort in der Konfig auch die IP-Adresse umstellen, vom BBB auf den Pi.

Auf dem BBB kannst du SHNG anhalten und deaktivieren über

sudo systemctl stop smarthome
sudo systemctl disable smarthome

Ich habe einen USB CC2531 Dongle an dem BBB hängen und in zigbee2mqtt konfiguriert.
Bei mir läuft mosquitto auf dem BBB, könnte aber auch auf dem Pi installiert werden.

[ugobald]

Danke für deine schnelle Rückmeldung.
Ich benötige zur Zeit tatsächlich nur KNX und 1-Wire vom BBB. Und heute habe ich in Proxmox eine neue VM mit Debian 12 und SmartHomeNG 1.9.5 aufgesetzt, was soweit läuft.

Mein KNX-Plugin (also die plugin.yaml) ist so konfiguriert:

2023-08-06 20_42_26-Window.png
Die host-IP entspricht dabei der IP des BBB und der Port passt auch. Auch 1-Wire habe ich entsprechend konfiguriert (so wie es beim alten SmartHomeNG war).

Beide Dienste scheinen aber nicht zu funktionieren:

2023-08-06 20_44_49-Window.png

1. Funktioniert das erst, wenn ich das alte SmartHomeNG deaktiviert habe? Und wie deaktiviert man das richtig?
2. Wie hast du Zigbee an deinen BBB bekommen? Ich nutze dafür aktuell einen Sonoff Dongle an meinem Home Server.

[GHild]

Ja, ich habe das mittlerweile so umgesetzt, d.h. auf dem Pi4 läuft u.a. die smartVISU und smarthomeNG.

Der BBB stellt neben knx, onewire, und enocean vom Cape auch noch zigbee über zigbee2mqtt zur Verfügung.

Wenn du nur knx und onewire vom Cape nutzt, ist der Umzug von smarthomeNG ziemlich einfach, da die beiden ohnehin als service laufen und über das IP angesprochen werden.
Du musst dann im etc/plugin.yaml (in der smarthomeNG Installation auf dem Pi) für die Plugins knx und onewire nur die IP des BBB angeben, also z.B.

knx:  
    plugin_name: knx
    host: 192.168.xx.yy
    port: 6720
ow:
    plugin_name: onewire
    host: 192.168.xx.yy
    port: 4304
    cycle: 300

wobei 192.168.xx.yy die IP des BBB ist.
smarthomeNG auf dem BBB kannst du dann disablen und anschließend löschen.

Etwas kompliziert wird es für enocean, da hier das SH-Plugin direkt auf das serielle Device zugreift.
Ich habe das nun durch ser2net gelöst. Dazu musste ich aber etwas am enocean-Plugin ändern und das rfc2217-Protokoll verwenden.

Bis jetzt läuft es stabil.

[ugobald]

Hallo Gerd,
konntest du dein Vorhaben der dedizierten Installation von SmartHomeNG auf einem Raspberry umsetzen?
Wäre nämlich auch daran interessiert, SmartHomeNG vom IBB Cape zu trennen, da auch ich mein Debian updaten müsste, um die neueste Version von SmartHomeNG installieren zu können.

Würde das denn überhaupt funktionieren? Weil owfs und knxd, also die Schnittstellen-Software, sind ja Plugins von SmartHomeNG und benötigen direkten Zugriff auf die Hardware vom IBB Cape.

Aber zugegebenermaßen habe ich zu wenig Ahnung davon.

[GHild]

Hallo Jürgen,

zunächst vorweg: Ich nutze den Beaglebone Black als Host für meine smarthomeNG Installation, die smartVisu läuft auf einem Pi 4.

Kürzlich musste ich vom Plugin darsksky auf piratewthr wechseln, da darksyky dank Übernahme durch Apple nicht mehr kostenfrei ist.
Das piratewthr plugin war erst in SHNG V1.9.4 verfügbar, das dann auch eine neue Version des Enocean-Plugins beinhaltete. Und die braucht Python 3.8, In Buster ist aber nur Python 3.7 enthalten.
Ein Upgrade nur der Python-Version hatte ich auch schon mal bei Debian 9 probiert... habe ich aber nicht hinbekommen und bin deshalb auf Debian 10 gewechselt.
Jetzt habe ich es erst gar nicht probiert, sondern bin gleich auf Debian 11 migriert.

Vor ein paar Wochen musste ich schon den Kernel auf Version 5.10 upgraden, um einen MBUS Master ansprechen zu können (Auslesen des neuen Wärmemengenzählers). Das ging aber durch die Installation von Paketen.

Deine Frage hat mich etwas in's Grübeln gebracht, ob ich nicht die SH-Instanz auch auf den Pi4 verlagern sollte und den BBB nur für die Zugriffe auf die angeschlossenen Devices (knx, enocean, zigbee, mbus, IR Lesekopf) verwende. Dann sollten fast keine Updates des BBB mehr nötig sein und die Beschränkung auf 4GB des eMMC sollte auch kein Thema mehr sein.

Für Enocean wird es vmtl etwas komplizierter (über socat?), der Rest läuft ja ohnehin über ein IP-basiertes API oder MQTT.

Würde mich interessieren, wie die anderen Capes eingebunden sind.

Grüße, Gerd

[Jürgen]

Hallo Gerd,

danke für Deinen Bericht, bestimmt eine große Hilfe!
Gab es einen besonderen Grund für das Update?
Die letzte Änderung bei meinem Beagle war die Installation eines Mailgateways, da mein Provider keine unverschlüsselten Mails mehr von meinem Merten IC1 annehmen wollte...

Gruß Jürgen

[GHild]

Hallo User dieses Capes,

vor Kurzem bin ich mit dem BBB und dem Cape auf Debian 11 Bullseye migriert und das System läuft stabil.
Im Gegensatz zu Debian 10 wurde das Cape nicht out of the box erkannt, sondern erforderte etwas Handarbeit.

Hier sind die wesentlichen Schritte

1) Backup, z.B Erstellen einer bootfähigen SD-Karte mit einem Abbild des aktuellen Systems

2) Aktuelles Bullseye Image ziehen, aus https://rcn-ee.net/rootfs/
Ich habe das Minimal Image ausgewählt, da die 4 GB Flash Speicher ohnhin knapp werden.

3) Auf SD Karte 'brennen', in BBB einsetzen und neu starten (Image noch nicht in Flash schreiben lassen)

4) Mit dmesg, syslog, ... prüfen, ob Cape erkannt wurde, z.B. ob die i2c Devices vorhanden sind

5) Bei mir war das nicht der Fall, daher Device Overlay des Capes in /boot/uEnv.txt explizit angeben:

smarthome@bbb:/boot$ diff uEnv.txt uEnv.txt.bak
25c25
< dtb_overlay=cape-bone-ibb-00A0.dtbo
---
#dtb_overlay=<file8>.dtbo
​

6) Neu starten, das Cape sollte nun erkannt werden

7) Weitere Installation gemäß Komplettanleitung von smarthomeng. Achtung: smarthome installiert einige Python Packages, die der BBB selbst kompilieren muss. Dazu werden zwischenzeitlich mehrere 100MB bis 1GB in /tmp abgelegt. Auf der SD Karte sollte das kein Problem sein, im eMMC schon.

8) Zu knxd:

/etc/knxd.conf:

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

Nicht vergessen, den User knxd der Gruppe dialout hinzuzufügen.

9) Zu onewire:

In /etc/owfs.conf

# USB device: DS9490
#server: usb = all                                                                                                                                                                                                
server: i2c = dev/i2c-3:0
server: i2c = dev/i2c-4:0
server: i2c = dev/i2c-5:0
server: i2c = dev/i2c-6:0

10) Wenn alles gut und stabil läuft, kann das Image von der SD Karte in den eMMC übertragen werden.

11) Leider reserviert das OS dann mehrere 100 MB für Swap und temporäre Dateien. Daher habe ich eine andere/frische SD Karte eingesetzt, unter /local gemountet und smarthome und zigbee2mqtt dorthin verschoben.

Vielleicht hilft das, um andere Capes am Leben zu erhalten

Grüße
Gerd

[awknx]

Ich tippe eher auf den PIN oder was hardwaremäßiges, aber da kenn ich micht nicht aus. Auch mein Backup unter Debian 10 mag nicht mehr mit den Schnittstellen arbeiten. Ich hab mir jetzt auf die Schnelle ein IP Schnittstelle für die Hutschiene beschafft, damit SHNG und SV erst mal wieder laufen - das klappt auch. Den 1-wire brauche ich eigentlich nicht, aber EnOcean schmerzt noch, weil meine Fenstergriffe damit angebunden sind.

Ansonsten läuft Debian 11.

Langfristiger werde ich wohl zum Raspi wechseln, nachdem das Cape ja auch nicht mehr gepflegt wird bzw. erhältlich ist. Es war eigentlich eine coole Entwicklung für das BBB.