Vorstellung: hm2mqtt & mqtt-smarthome

[owagner]

Das ist so beabsichtigt -- laut mqtt-smarthome-Spezifikation kann der Inhalt entweder ein einfacher Wert oder ein JSON-encodiertes Objekt sein, welche zusätzliche Metainformation zu den Daten enthält: https://github.com/mqtt-smarthome/mqtt- ... age-format und https://github.com/owagner/hm2mqtt#mqtt-message-format

Die Option "Disable ReGa Name Sync" unterdrückt das Laden von Gerätenamen aus der Logikschicht-Schicht ("ReGaHSS") auf der CCU. In diesem Fall entsprechen die Topics den Seriennummern (mit Kanalsuffix) der Geräte. Es entspricht der Option hm.disableReGa, siehe https://github.com/owagner/hm2mqtt#available-options

[Michael_Langhauser]

Hallo,

ist es durch mqtt möglich Homematicgeräte ohne die Geräte neu anlernen zu müssen diese zb. in FHEM zu schalten und darzustellen. Ich habe das bestimmt nicht richtig verstanden. Stehe noch am Anfang mit Smarthome.

Grüße

Michael

[starfish]

danke Oliver, alle Unklarheiten beseitigt

[owagner]

Ich habe gerade die Version 0.12 released, mit folgendenden Änderungen seit 0.10:

* 0.12 - 2015/06/11 - owagner
- generate "ts" and "lc" timestamp fields in published messages
- no longer automatically register with reportValueUsage
- add a command channel and bind/unbind commands as an reportValueUsage interface
- new option "hm.bindaddress"
* 0.11 - 2015/03/14 - owagner
- include "hm_unit" and "hm_enum" in published messages, when applicable

Download: https://github.com/owagner/hm2mqtt/releases/tag/v0.12

[Nano]

Das mqtt-smarthome-Konzept ist in langen Diskussionen mit Sebastian 'hobbyquaker' Raff gewachsen, zuerst während der ioBroker-Konzeptionierungsphase, dann während der gemeinsamen Arbeit daran. Von ihm stammt auch die Idee für das CCU2-Addon-Package für hm2mqtt.

Wie ist das denn in Zukunft weiter geplant mit ioBroker und dem mqtt-smarthome-Konzept?
Sollte man eher einen Adapter für ioBroker entwickeln oder lieber eine xxx2mqtt Komponente?
Oder erfolgt keine weitere Zusammenarbeit?

Ich persönlich finde das Konzept basierend auf MQTT prima.
Aktuell sehe ich nämlich das Dilemma, dass es schon ein großes Wirrwarr an HW gibt, die es gilt, einzubinden.
Jetzt kommt noch hinzu, dass überall HW-spezifische Adapter/Bindings/Module mit unterschiedlicher Funktionalität entstehen, die nur jeweils für die eine Plattform (FHEM[Perl], OpenHAB[Java], ioBroker[Javascript/Node.js]) zur Verfügung stehen.

[hobbyquaker]

Sollte man eher einen Adapter für ioBroker entwickeln oder lieber eine xxx2mqtt Komponente

Ich versuch es mal "unparteiisch" zu beantworten

xy2mqtt ist universell, man baut einen Adapter nur einmal und es ist für die User diverser anderer Smarthome-Software (ioBroker, CCU.IO, Node-RED, FHEM, OpenHAB, ...) auch von Nutzen.
Um jetzt die Nachteile eines xy2mqtt gegenüber einen ioBroker-Adapter darzulegen muss ich etwas weiter ausholen und versuche mal den wesentlichen Unterschied zwischen mqtt-smarthome und ioBroker zu erklären:
mqtt-smarthome beschäftigt sich nicht mit "Abstraktion" und "Metadaten". Will heissen ein Anwender eines xy2mqtt muss für die weitere Verwendung der Datenpunkte/Topics wissen welche Datenpunkte es überhaupt gibt. Es gibt keine Gerätebeschreibungen und keine Abstraktion in der Form dass z.B. ein Homematic Dimmer und ein KNX Dimmer beides Instanzen eines abstrakten Dimmers sind der dann für eine Logik-Engine oder eine Visualisierung zur Verfügung steht.
ioBroker hingegen verwaltet Metadaten und führt eine eigene Abstraktionsschicht ein. So kann z.B. ioBroker.vis "wissen" welche Datenpunkte in einem bestimmten Widget sinnvoll verwendbar sind. Und so können auch Zuordnungen zu z.B. Räumen oder Gewerken realisiert werden die dann wiederum in der Script-/Logik-Engine zur Verfügung stehen.
Die Frage ob man nun lieber einen ioBroker-Adapter oder xy2mqtt baut hängt auch von dem System ab das man anbindet. Wenn das System nur wenige Meta-Daten anbietet bzw. erfordert würde ich pauschal zu xy2mqtt raten. Möchte man ein komplexes System mit vielerlei unterschiedlicher Aktorik/Sensorik und "Spezialitäten" wie einer bereits im System vorhandenen Abstraktion anbinden bietet ein ioBroker-Adapter unter Umständen einen Mehrwert, wenn man denn eine "monolithische" Lösung wie ioBroker als Zentrale einsetzen möchte.
Wer sein System kennt und auch gerne selbst Software entwickelt ist bei mqtt-smarthome sehr gut aufgehoben und hat maximale Flexibilität und am wenigsten Aufwand wenn einzelne Module ausgetauscht werden sollen. Es ist auch durchaus praktikabel im Kern auf mqtt-smarthome zu setzen aber dennoch ioBroker oder OpenHAB daneben zu nutzen, z.B. weil es dort so eine schöne Visu gibt oder vielleicht weil es dort einen bestimmten Adapter gibt.
Wer allerdings eine Lösung haben will die möglichst wenig Einrichtungs- und Administrations-Aufwand hat, auch für nicht-Software-Entwickler gut zu handhaben ist, einem vieles von dem worum sich ein mqtt-smarthome Anwender selbst kümmern muss abnimmt und alles bietet was man so braucht ist aber denke ich bei ioBroker besser aufgehoben.

[Nano]

Vielen Dank für die ausführliche Antwort.

Eine Frage noch dazu:
Da ioBroker ja quasi eine Abstraktion mit Meta-Daten einführt, frage ich mich, ob es z.B. mit dem MQTT-Adapter auch möglich ist bzw. sein sollte, quasi einen abstrakten Dimmer (um bei dem Beispiel zu bleiben) zu erstellen, den ioBroker dann als Dimmer "wahrnimmt", um dann die von Dir beschriebenen Vorteile zu haben. Man baut quasi verschiedene Topics zu einem abstrakten Dimmer zusammen.
Die Meta-Daten selbst sollen nicht Bestandteil von MQTT Topics sein. Er würde also "manuell" erstellt.

Aktuell werden die Topics ja "nur" auf Objekte mit Zuständen abgebildet.

[promd]

Hallo,

ich habe in meinem setup hm2mqtt und mosquitto auf einem raspi installiert.
Die einzelnen Komponenten laufen auch soweit gut.
hm2mqtt gibt mir allerdings in regelmäßigen Abständen eine Exception zurück:

com.tellerulam.hm2mqtt.MQTTHandler$2 connectionLost
WARNING: Connection to MQTT broker lost
Connection lost (32109) - java.io.EOFException
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:138)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:267)
at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:56)
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:100)
... 1 more

NodeRed bekommt die "connected" pubs mit, aber nichts weiter.

hm2mqtt wird gestartet mit:

Code: Alles auswählen

java -jar hm2mqtt.jar hm.host=192.168.00.20

Irgendwelche Ideen, was mir noch fehlt zum Glück ?

[owagner]

Mach mal Logging auf dem Mosquitto an und schau, ob da mehr steht, wieso die Verbindung abbricht.

[promd]

***UPDATE***: Problem gelöst: ich musste hm.localhost auf die tatsächliche IP setzen.


Da war tatsächlich noch ein zweiter hm2mqtt in Hintergrund, den hatte ich übersehen.
Vielen Dank erst mal für die schnelle Antwort

Leider bekomme ich immer noch keine Messages für Events...
Noch ein paar weitere Details zu meinem Setup:
- Homematic CCU 1 (!) mit XML-API 1.10
- Ein RaspberryPi mit Mosquitto, hm2mqtt und Node-Red

Für die Tests bisher starte ich nur Mosquitto und hm2mqtt.
Die Messages kontrolliere ich mit

Code: Alles auswählen

 mosquitto_sub -t hm/#

Das klappt auch, ich bekomme eine "2" für den "connected" status.

Darüber hinaus bekomme ich aber keine Messages.
Wenn ich gleich eine ebene tiefer subscribe "hm/#/#", dann kommt gar nichts mehr.

Für mein Verständnis: ich sollte für jeden geänderten Schaltzustand an einer HM Komponente eine Nachricht bekommen, es bedarf keiner weiteren Konfiguration - richtig ?

Hier noch mal ein Mitschnitt des hm2mqtt output. In dieser Zeit habe ich wiederholt geschaltet....

INFO: Not seen a XML-RPC request for over 300s, re-initing...
Jul 14, 2015 1:58:10 PM com.tellerulam.hm2mqtt.HMXRConnection sendInit
INFO: Sending init to 192.168.88.20:2000 with binary://127.0.1.1:39128
Jul 14, 2015 1:58:10 PM com.tellerulam.hm2mqtt.HMXRConnection sendInit
INFO: Init to 192.168.88.20:2000 with binary://127.0.1.1:39128 successful
Jul 14, 2015 1:58:10 PM com.tellerulam.hm2mqtt.HMXRConnection sendInit
INFO: Sending init to 192.168.88.20:2001 with binary://127.0.1.1:39128
Jul 14, 2015 1:58:10 PM com.tellerulam.hm2mqtt.HMXRConnection sendInit
INFO: Init to 192.168.88.20:2001 with binary://127.0.1.1:39128 successful
Jul 14, 2015 1:59:10 PM com.tellerulam.hm2mqtt.XMLRPCServer isIdle
INFO: Not seen a XML-RPC request for over 300s, re-initing...
Jul 14, 2015 1:59:10 PM com.tellerulam.hm2mqtt.HMXRConnection sendInit
INFO: Sending init to 192.168.88.20:2000 with binary://127.0.1.1:39128
Jul 14, 2015 1:59:10 PM com.tellerulam.hm2mqtt.HMXRConnection sendInit
INFO: Init to 192.168.88.20:2000 with binary://127.0.1.1:39128 successful
Jul 14, 2015 1:59:10 PM com.tellerulam.hm2mqtt.HMXRConnection sendInit
INFO: Sending init to 192.168.88.20:2001 with binary://127.0.1.1:39128
Jul 14, 2015 1:59:10 PM com.tellerulam.hm2mqtt.HMXRConnection sendInit
INFO: Init to 192.168.88.20:2001 with binary://127.0.1.1:39128 successful
Jul 14, 2015 2:00:10 PM com.tellerulam.hm2mqtt.XMLRPCServer isIdle