Hallo zusammen,
die derzeit verfügbaren free@home-Integrationen in OpenHAB, fhem & Co. basieren alle auf dem XMPP-Protokoll, das der System Access Point spricht. Das mag zwar mehr oder weniger gut funktionieren, toll finde ich persönlich das aber nicht.
Mir wäre es lieber, ich könnte bspw. einen Raspberry Pi an den Bus klemmen und free@home-Telegramme mithören und selbst erzeugen. Dadurch wäre auch eine bessere Integration in andere Smart-Home-Plattformen möglich und man wäre nicht mehr so abhängig von B+J/ABB.
Hat sich schon jemand in dieser Richtung betätigt?
Offiziell ist die Linie von B+J/ABB, daß free@home mit KNX inkompatibel ist. Dem ist jedoch nicht unbedingt so. Rein physikalisch sprechen die kabelgebundenen free@home-Komponenten sehr wohl KNX und befolgen den Standard. Das überrascht auch nicht, wenn man bedenkt, daß bspw. die UP-Binäreingänge kaum mehr enthalten als einen ABB Blue 3.0-ASIC als KNX-Transceiver und einen Atmega32, der den Transceiver ansteuert. Das sieht in etwa so aus wie hier: https://www.mikrocontroller.net/topic/285003
Auch logisch setzt free@home ja auf KNX auf, da die Limitierung auf 64 Teilnehmer genau der KNX-Limitierung für eine Linie entspricht. Für mich klingt free@home daher wie "KNX light", weil die Gerätedefinitionen für ETS nicht vorliegen und daher nur der System Access Point diese konfigurieren kann. Wie das funktioniert und welche Bedeutung die über den Bus gehenden Telegramme haben, muß doch herauszufinden sein! 🙂
Habe mal direkt bei B+J nach dem Protokoll gefragt und bekam diese Antwort:
Die Buskommunikation nutzt das KNX Protokoll. Allerdings können die Geräte nicht mit eine ETS programmiert werden, da in den Busankopplern eine spezielle Firmware steckt um die Geräte mit unsere grafischen Oberfläche programmieren zu können.
Dadurch werden Gruppenadressen und physikalische Adressen dynamisch durch den SysAP den Geräten zugeordnet. Deshalb kann free@home nicht mit KNX gemischt werden.
Das hört sich ja schon mal gut an. Daß die Zuordnung dynamisch erfolgt und das die ETS verwirren würde, überrascht jetzt eher weniger. Selbst wenn man den Mechanismus, wie diese Zuordnung erfolgt, erstmal nicht nachvollziehen kann, bedeutet das aber, daß die restlichen Telegramme, die über den Bus gehen, dem KNX-Standard folgen und somit sollten sie ja relativ einfach zu verarbeiten bzw. zu reproduzieren sein 🙂
Moin zusammen,
Mein ABB Außendienstmitarbeiter hat mir hinter vorgehaltener Hand gesagt, dass er mit einer üblichen Schnittstelle für KNX den Bus ausgelesen hat und so die Gruppenadressen über den Busmonitor mitgelesen hat.
Ich selber habe es noch nicht getestet, da ich leider keine ETS und auch keine Programmierschnittstelle habe.
Gruß Triple5Soul
Danke für die Bestätigung - es überrascht mich nicht, daß das funktioniert, aber es ist gut zu wissen, daß es schon jemand probiert hat.
Jetzt bräuchte ich nur noch eine free@home-Installation, mit der man geeignete Daten generieren kann. Unsere ist noch im Bau...
Das mag zwar mehr oder weniger gut funktionieren, toll finde ich persönlich das aber nicht.
Doofe Frage: Warum nicht?
Das mag zwar mehr oder weniger gut funktionieren, toll finde ich persönlich das aber nicht.
Doofe Frage: Warum nicht?
Mehrere Gründe:
1) Theoretisch kann B+J die XMPP-Funktionalität deaktivieren oder derart einschränken, daß kein Zugriff auf den AP mehr möglich ist
2) Der XMPP-Stack auf dem AP stellt nicht die gesamte mögliche Funktionalität bereit, die die Sensoren und Aktoren bieten, bzw. muß diese nicht bereitgestellt werden
3) Ein Verständnis der Buskommunikation würde die Entwicklung und Integration von eigenen Komponenten ermöglichen, die B+J/ABB nicht selbst bereitstellt
Derzeit mag die XMPP-basierte Integration in OpenHAB & Co. zwar funktionieren, gefühlt ist das aber nur eine Duldung, weil B+J das ganz einfach unterbinden kann. Auf Hardwareebene geht das nicht, weil B+J/ABB ganz offensichtlich interne Wiederverwertung von KNX-Hard- und Softwarekomponenten betreibt und das auch weiterhin machen will. Ist ja auch sinnvoll.
Ich habe an diesem Thema auch großes Interesse. Hier könnte man ein Reporting/Statistik-Tool erstellen, dass dieses Thema ohne vorherige Aktivierung nutzbar macht und keine internen F@H-Ressourcen verbraucht. Für Openhab wäre das der Oberhammer. 🙂
Interessante Idee. Man müsste nur diese Anleitung befolgen KNX auf Rapi 3
und die entsprechende Hardware für knapp 85€ kaufen. Danach sollte man alles weitere aus dem Bus extrahieren können was benötigt wird.
Ich habe leider zur Zeit keine zeit dazu. Familie geht nun mal vor 🙂
Es gibt im rootfs in der Firmware eine Datei namens telegrammodel.xml, die vom SysAp-Busmonitor verwendet wird. Darin sind alle Telegramme beschrieben, die der Busmonitor anzeigen kann. Habe immer noch kein eigenes f@h-System, aber bin gespannt, ob die Telegramme der Beschreibung entsprechen. Sollte das so sein, wäre es supereinfach, ein entsprechendes device zu bauen, weil man quasi nichts reverse engineeren müsste.
Bist Du mittlerweile schon weitergekommen? Ich hätte die Hoffnung, dass eine solche Integration wesentlich schneller sein kann als alles über den SysApp abzuwickeln. Ich mein, vergleiche ich App vs. Schalter, dann ist da ein enormer Unterschied... 😉
Würde mich wirklich sehr interessieren...
Eine andere Hardware hierfür: https://www.hackster.io/news/zdi-s-knx-hat-integrates-your-raspberry-pi-or-other-sbc-into-a-knx-eib-home-automation-network-4528dfd7a354
Konnte leider noch nicht daran arbeiten. Konnte wegen Corona erst vor einem Monat einziehen und mein Installateur rückt das Passwort für das Installer-Konto nicht raus...
Hi,
Konnte leider noch nicht daran arbeiten. Konnte wegen Corona erst vor einem Monat einziehen und mein Installateur rückt das Passwort für das Installer-Konto nicht raus...
Hast Du das zwiscchenzeitlich bekommen? Wenn nein, sag ihm doch bitte das er Dir ein Backup auf ein USB Stick anlegen soll (also Projekt und Key) weil Du Dich sicherer fühlst wenn Du es selbst hättest um ggf. bei was auch immer ....
Der Rest geht dann von alleine, schlussendlich hast Du Ihn auch vermutlich bezahlt ...
Grüße
Ich lege hier mal meine bisherigen Erkenntnisse ab:
- Der SysAP hat die Bus-Adresse 0.1.0
- Die Adressen der Teilnehmer sind im Modus ?debug=1 über das Webinterface ersichtlich (Gerätekonfiguration->XYZ->Wartung->Adresse)
Eine Angabe von bspw. 101 ist der Wert des uint16 in hex, in Dreiernotation dann also 0x101 = 0.1.1
Weiteres Beispiel: 1CC = 0x1CC = 0.1.204
- Der SysAP sendet periodisch einen broadcast an 0/0/0, der ein Ping von den Busteilnehmern anfordert:
L_Busmon: BC 01 00 00 00 E1 03 03 A3 :L_Data low from 0.1.0 to 0/0/0 hops: 06 T_Data_Broadcast A_DeviceDescriptor_Read Type:03
- Die Busteilnehmer antworten mit einem Paket, das drei Besonderheiten aufweist:
1. hat es eine ungültige Länge
2. die APDU-ID ist nicht KNX-konform, d.h. die ID 0x343 ist nicht im Standard definiert und somit die Bedeutung der Nutzdaten unbekannt
3. die APDU-Daten beinhalten zwei numerische IDs - eine in der Form
AB Bg xx xx xx xx (die auf dem Gehäuse aufgedruckte ID) mit g = 2 oder 7
und eine in der Form
AB Bh yy yy yy yy mit h = 6
- Ein neues Gerät am Bus nimmt die Adresse 0.1.1 an und meldet sich via broadcast an 0/0/0, woraufhin der SysAP antwortet und das Gerät konfiguriert
- Sensoren senden an Gruppenadressen, die zufällig gewählt erscheinen - ich habe bspw. 22/0/119, 26/0/179, 3/3/231 und 18/1/140 gesehen
(evtl. ergeben die Gruppenadressen als uint16 mehr Sinn und sehen nur in KNX-Notation zufällig aus)
Lichtschalter lassen sich einfach steuern, bspw. mittels knxd:
./knxtool groupswrite ip:localhost 22/0/119 01 ./knxtool groupswrite ip:localhost 22/0/119 00
schaltet die auf dieser Gruppenadresse lauschende Lampe ein und aus.
- Obige Annahme, dass AB Bh yy yy yy yy eine zweite numerische ID sei, ist falsch. Aus telegrammodel.xml ergibt sich, dass ABBh das Feld "manufacturer" darstellt und bspw. der Wert 0xABB6 dem Hersteller "CNDEX" entspricht
- Die Antworten auf den periodischen Ping-Broadcast sind vom Typ "dd-response", was den Inhalt nun komplett ersichtlich macht
- Somit ist auch erklärt, warum verschiedene Geräte Antworten mit unterschiedlicher Länge zurückliefern: die Anzahl der channels variiert
Bin im Übrigen gerade dabei, einem Open Source-KNX-Stack das Protokoll von free@home beizubringen. Wollte das ursprünglich über knxd machen, aber der Codestil ist mir vom Geschmack her zu eigen und die API ist komplett auf KNX fokussiert, ohne Zugriff auf darunterliegende Schichten zu bieten. Hätte also knxd selbst erweitern müssen und das wäre nicht reusable gewesen, wenn man was mit bare metal bauen wollte (was eines meiner Ziele ist).