Homematic Integration... aber wie

[Gast1961]

Also mir hilft deine Anleitung sehr um einen ersten Einblick zu bekommen was gemacht werden muss um werte zu übergeben!
danke

Ah, das habe ich verwechselt, die Frage war von dir. Gern geschehen, freut mich wenn's hilft!

[DerStandart]

Ich mache beim Anlegen beim Anlegen einer großen Anzahl von Variablen in IPS das Wenigste mit der Maus - da wird man ja blöd im Kopf. 95% bei so einer Aktion lassen sich super und schnell über Skripte lösen.

Ich habe im letzten Monat eine Kundenanlage mit knapp 60 Rolladenkanälen gehabt. Das war innerhalb von 2-3 Stunden erledigt. Mit klicken hier und klicken da wäre ich wahrscheinlich heute noch nicht fertig.

[predi ger many]

Gast1961 :

Der ursprüngliche Grund für den Post war, dass ich eine FERTIGE Lösung gesucht habe, wo man mit einem Gerät hinkommt. Also ohne CCU. Also ein Gateway was Bidcois und KNX spricht.

Ziel war eine Reduzierung der Komplexität.

Das gibt es nicht fertig.

Wenn man kein Homematic IP hat kann man das aber mittels FHEM realisieren, denn FHEM kann Homematic direkt ansprechen ohne CCU.

Aktuell baue ich folgende Lösungen. FHEM mit Weinzierl Modul und Homematic USB Funkmodul.
Damit fällt die CCU weg und das IPGateway für ETS auch. Das ganze auf nen PI. Kosten inkl Gehäuse Netzteil und PI keine 100 Euro.

Sobald die Lösung fertig ist, werde ich sie publizieren. Das wird dann auch für absolute Nichtprogrammierer umsetzbar sein

[netfriend]

Gast1961 :

Der ursprüngliche Grund für den Post war, dass ich eine FERTIGE Lösung gesucht habe, wo man mit einem Gerät hinkommt. Also ohne CCU. Also ein Gateway was Bidcois und KNX spricht.

Ziel war eine Reduzierung der Komplexität.

Das gibt es nicht fertig.

Wenn man kein Homematic IP hat kann man das aber mittels FHEM realisieren, denn FHEM kann Homematic direkt ansprechen ohne CCU.

Aktuell baue ich folgende Lösungen. FHEM mit Weinzierl Modul und Homematic USB Funkmodul.
Damit fällt die CCU weg und das IPGateway für ETS auch. Das ganze auf nen PI. Kosten inkl Gehäuse Netzteil und PI keine 100 Euro.

Sobald die Lösung fertig ist, werde ich sie publizieren. Das wird dann auch für absolute Nichtprogrammierer umsetzbar sein

Was ist daraus geworden?

[Michael H]

Hallo,

wir haben ein PlugIn für knXpresso und Homematic entwickelt. Man benötigt allerdings eine CCU, ein Android Gerät und ein IP-Interface. Sollte alles vorhanden sein, ist die Lizenz für die ersten Tester kostenlos.


Gruß
Michael Hartmann

[predi ger many]

Was ist daraus geworden?

Ja, es ist etwas daraus geworden. Aktueller Stand.

Ich habe einen PI mit Raspbian Stretch und dort läuft FHEM. In dem PI ist das alte Funkmodul verbaut.
Die Homematic Devices sind mit dem Funkmodul verbunden, d.h. ohne CCU.

Im Netz läuft ein Weinzierl BAOS 774.

Im FHEM habe ich generisches Perl Script, was alle Datenpunkte von den Homematic Devices im FHEM in das BAOS
schaufelt und umgekehrt. Natürlich nur bei Änderung. Um den Sync auszulösen, braucht es jede Menge FHEM Config.
Da das extrem fehleranfällig ist, habe ich die Erzeugung der Konfig in Excel gepackt... nur noch Copy & Paste.

Aktuell also keine CCU mehr. Aktuell aber zwei Devices... KNX IP Interface und PI mit FHEM.


Next Steps 1:

1. Einbau einer Waveshare Serial Expansion HAT for Raspberry Pi, I2C Interface, 2-ch UART, 8 GPIOs.
2. Homematic Funkmodul mit der Waveshare zum laufen bringen
3. Einbau Weinzierl kBerry und zum Laufen bringen (falls möglich direkt über FT1.2 oder per knxd)

Anmerkungen: Durch den Einbau der Waveshare HAT sollten 3 unabhängige COM Anschlüsse verfügbar sein. Dadurch
sollten mehrere Serielle Module funktionieren.

Next Steps 2:

Wenn Obiges tut, werde ich mal piVCCU installieren und mir dann mal NodeRed anschauen. Wenn das alles kann, werde
ich wohl auf piVCCU Nodered umschwenken. Ggf. werde ich mal bei Jens Maus anfragen, ob der knxd in RaspberryMatic
integrieren kann. Dann wäre piVCCU überflüssig.

[predi ger many]

Hallo,

hier der aktuelle Stand. Es gab in den letzten Tagen viel Bewegung.

Die Daten fliegen mittlerweile von der CCU oder FHEM in den kBerry auf folgendem Weg:

CCU <-- --> Node Red <-- --> MQTT Server <-- --> BOAS SDK (MQTT Client) <-- --> BOAS SDK (Redis) <-- --> BOAS SDK (Socket)
FHEM<-- --> MQTT Server <-- --> BOAS SDK (MQTT Client) <-- --> BOAS SDK (Redis) <-- --> BOAS SDK (Socket)

Der Zwischenstep über MQTT wird bald entfallen, denn es gibt für Node Red auch einen Redis Adapter. Um den zum Laufen zu bringen
sind allerdings noch ein "paar" Code Changes im SDK notwendig.

Der finale Weg wird dann wohl so aussehen:

CCU <-- --> Node Red <-- --> BOAS SDK (Redis) <-- --> BOAS SDK (Socket)
FHEM<-- --> Node Red <-- --> BOAS SDK (Redis) <-- --> BOAS SDK (Socket)

Node Red hat einen enormen Vorteil. Man kann alles grafisch zusammenklicken. Flows kann man zum Download bereitstellen.
Der Weg über Redis hat mich anfangs nicht überzeugt... noch eine Zwischenschicht. Allerdings macht die Sinn, denn Redis stellt
eine Queue bereit, so dass egal von welche Seite ein Update kommt die Reihenfolge immer stimmt.

Mit dieser Implementierung öffnen sich dann weitere Wege. Man wird dann Ecocean, Z-Wave usw. implementieren können.

Wichtig: Die Daten werden nativ in den kBerry geschrieben als wären die Devices echte KNX Devices. Es werden keine Gruppenadressen genutzt, sondern die echten Datenpunkte.

Viele Grüße
Predi

[OleDeluxe]

…
Ggf. werde ich mal bei Jens Maus anfragen, ob der knxd in RaspberryMatic
integrieren kann. Dann wäre piVCCU überflüssig.

Hi Predi,

damit wäre RaspberryMatic ja quasi direkt KNX tauglich ohne Zwischenstep. Hast du das weiter verfolgt?

Gruß Sven

[predi ger many]

Hallo,

Weinzierl stellt mit dem kBerry einen KNX Stack bereit. Über diesen soll man auf den kBerry zugreifen. Ich habe bei Weinzierl
eine Anfrage gestellt und eine klare Aussage bzgl KNXD bekommen. Kein Support.

Ich habe dann wochenlang mit dem kBerry und KNXD experimentiert. KNXD ist massiv verbuggt und läuft nicht stabil als IP Interface
oder IP Router mit dem kBerry. Ich glaube auch nicht, dass es jemals sauber laufen wird.

Seitens Weinzierl ist nicht vorgesehen, dass man den kBerry als IP Interface betreibt und dann über GA in die Datenpunkt schreibt.
Vorgesehen ist, dass man über BOAS direkt in die Datenpunkte schreibt. Dies hat einen Vorteil. Wenn man ein Gateway entwickelt,
welches per BOAS arbeitet, verhalten sich die Geräte wie native Geräte.

Am Anfang als ich mich mit dem kBerry und BOAS beschäftigt habe, dachte ich, dass ich allein auf weiter Flur bin. Weit gefehlt.
Es gibt eine NodeJS Implementierung und Weinzierl unterstützt hier richtig. Das SDK ist Klasse. Allerdings bin ich wohl der Erste,
der etwas Richtiges damit macht. Jetzt stehen Anpassungen an so, dass alles smooth wird. Stabil bis zum Erbrechen ist die NodeJS
Implementierung bereits.

Wenn man Homematic mit dem kBerry als Gateway machen würde, entsteht folgender Kommunikationsweg:

HM <-- --> Third Party Software <-- --> kBerry als Gateway <-- --> KNX Gruppenadresse <-- --> kBerry Datenpunkt

Nachteil daran ist, dass ein Datenpunkt immer nur eine sendende Adresse haben kann und die wird hier "verbraten".

Der Vorteil beim BOAS ist, dass man HM nicht über GAs koppelt. Sondern direkt in die Datenpunkte schreibt. Ein HM Gerät,
was über BOAS eingebunden wird, wird sich so verhalten wie ein natives KNX Device.

Zum Thema piVCCU und RaspberryMatic. RaspberryMatic und piVCCU basieren auf einem total eingeschränktem Linux.
Bei RaspberryMatic irgendwelche Software nachzuinstallieren, ist ein Granaten-Mist. Alles muss portiert werden. piVCCU
umgeht das durch Virtualisierung. Nachteil ist der Resourcenverbrauch. Beide Projekte werden gepflegt, aber es gibt
bereits den Nachfolger Debmatic. Das ist eine CCU auf einem normalen Debian.

Meine Testplattform ist aktuell: Debian mit Debmatic, FHEM, Node Red und kBerry. Als Schnittstellen sind verbunden
per GPIO das alte HM Funkmodul, der kBerry, ein EnoceanPI Modul und und ein Razberry 2. Alles über ingesamt 2
Waveshare Serial Expansion HAT angeschlossen. Die zwei Module stellen mir 4 serielle Ports per I2C zur Verfügung.
Theoretisch könnte ich noch ein Modul anschließen an den Standard Serial Port des PI.


Homematic wird immer einen Zwischenstep brauchen. Man kann es über GAs oder über BOAS machen.
Für Homematic gibt es einen Node-Red Node. Für BOAS gibt es ein SDK, welches Redis als Schnittstelle im Bauch hat.
Für Redis gibt es auch einen Node-Red Node. HM Devices kann man ja auch direkt in FHEM betreiben. Für FHEM
gibt es auch einen Node-Red Node.

Wenn ich mir alle auf dem Markt verfügaren Lösungen anschauen. Was haben die im Bauch? Node Red.

Node Red ist die ideale Plattform um Welten miteinander zu verbinden.

Hier mal ein Sample, was ich letzte Woche getestet habe um zu verstehen, was alles möglich wird.:

1. Ich habe einen Datenpunkt im kBerry als DPT 9.001 definiert.
2. Ich habe eine GA definiert, welche mir den Wert eines KNX Tempsensors in den DP des kBerry schiebt
3. Ich habe im FHEM ein virtuelles Device angelegt.
4. Ich habe den Datenpunkt aus dem kBerry mit dem virtuellen Device gesynct
5. Ich habe einen HM Heizungsaktor mit dem virtuellen Device gepairt.

... KNX Temperatursensor an HM Native. Mit einer CCU geht das nicht nativ, aber es mittels Offset. Dafür
habe ich im Node Red auch schon nen Flow. Der berechnet das Delta des KNX Tempsensors zum internen
Sensor des HM HKT und sendet das entsprechende Offset.

[shaolinmaster]

Raspi, IOBroker, fertig! Alle Datenpunkte sind dann im Broker verfügbar.

[predi ger many]

Raspi, IOBroker, fertig! Alle Datenpunkte sind dann im Broker verfügbar.

Und wie macht der IOBroker das? Per Gruppenadresse. Den Weg können 100 andere Programme auch.

Gruppenadressen = virtuell
Datenpunkt = physisch

Mit BOAS kann man Datenpunkte ohne Umweg über eine GA direkt schreiben. Hat so einige Vorteile.

Meine persönliche Meinung zu IOBroker: IOBroker ist seinerzeit aus CCU.IO hervorgegangen. Si-So-Software.

[markofnoise]

Hallo zusammen,

ich stand auch vor 5 Jahren vor dem Problem KNX und Homematic zu integrieren.

Znächst hatte ich:
1. fhem ohne CCU, mit HMLAN
2. knxd
3. viel Programmierung mit notify auf fhem und immer wieder Probleme mit der Übersicht
4. Ablösung vom knxd durch ein knxip Modul in fhem

Dann kam der Umstieg auf Docker auf einer Synology (raspy würde natürlich auch gehen) und iobroker.

1 Container mit iobroker
1 Container mit fhem

Lösung:
iobroker mit Adapter für:
fhem, KNX, node red, Blockly

Fazit:
iobroker als Vermittler der verschiedenen Protokollwelten ist wunderbar einfach und bietet sehr viele Möglichkeiten. Coden geht, muss aber nicht. Läuft absolut stabil.

Verwendete Protokolle/Systeme:
Gira Homeserver, iobroker, fhem
KNX
KNX-RF
Homematic
ZigBee (Hue Bridge und Conbee)
Z-Wave
Modbus TCP

LG
Markus