Vorstellung: hm2mqtt & mqtt-smarthome

[promd]

Hallo noch mal...
Nachdem das ganze jetzt läuft und ich ein paar Stunden damit verbracht habe, möchte ich mal einen Punkt in die Runde werfen.

Macht es wirklich Sinn, atomar auf Ebene der "Datapoints" zu publishen ?
Ich versuche z.B. im Moment auf einen Bewegungsmelder zu reagieren.
Die Struktur ist wie folgt:

Code: Alles auswählen

<state>
 <device name="Bewegungsmelder" ise_id="4166" unreach="false" sticky_unreach="false" config_pending="false">
  <channel name="Bewegungsmelder:0" ise_id="4167"->
   <datapoint name="BidCos-RF.LEQ0657358:0.UNREACH" type="UNREACH" />
   <datapoint name="BidCos-RF.LEQ0657358:0.STICKY_UNREACH" type="STICKY_UNREACH" />
   <datapoint name="BidCos-RF.LEQ0657358:0.CONFIG_PENDING" type="CONFIG_PENDING" />
   <datapoint name="BidCos-RF.LEQ0657358:0.LOWBAT" type="LOWBAT"/>
   <datapoint name="BidCos-RF.LEQ0657358:0.RSSI_DEVICE" type="RSSI_DEVICE"/>
   <datapoint name="BidCos-RF.LEQ0657358:0.RSSI_PEER" type="RSSI_PEER"/>
   <datapoint name="BidCos-RF.LEQ0657358:0.DEVICE_IN_BOOTLOADER" type="DEVICE_IN_BOOTLOADER"/>
   <datapoint name="BidCos-RF.LEQ0657358:0.UPDATE_PENDING" type="UPDATE_PENDING"/>
  </channel>
  <channel name="Bewegungsmelder" ise_id="4196">
   <datapoint name="BidCos-RF.LEQ0657358:1.BRIGHTNESS" type="BRIGHTNESS"/>
   <datapoint name="BidCos-RF.LEQ0657358:1.MOTION" type="MOTION"/>
  </channel>
</device>
</state>

Wenn sich jetzt was bewegt, dann bekommt Mosquitto immer 2 Messages, eine für "MOTION", und eine für "BRIGHTNESS" (und einen weiteren "INSTALL_TEST").
Fällt der Wert für "MOTION" übrigens wieder auf "0", dann kommt nur die Message für "MOTION" ?!

Ohne die Details zu kennen, zu denen die CCU Events auslöst, wäre mein Vorschlag alle (verfügbaren ?) DATAPOINTS in den Payload aufzunehmen.

Um bei meinem Beispiel zu bleiben: Jemand löst den Bewegungssensor aus, und das Außenlicht soll angeschaltet werden- aber eben nur, wenn es dunkler als "x" ist.
Mit dem momentanen Zustand gibt das ein Problem. "MOTION" löst aus, aber die Information "BRIGHTNESS" ist nicht verfügbar....
Jetzt kann ich entweder über die XML-API noch mal direkt nach "BRIGHTNESS" fragen, oder ich Cache die Information "MOTION" und warte auf die "BRIGHTNESS" Message ('oder umgekehrt, denn die Reihenfolge der Zustellung ist ja nicht garantiert.

Generell sollte der Event den Umfang der Nachricht definieren, und nicht das Informationsfragment ?

Ein weiteres Beispiel: Ein Dimmer sendet gleich 7 Messages (LEVEL, LEVEL_REAL, WORKING, DIRECTION und drei ERROR_*).

Gibt es eine Dokumentation die den Prozess der Event-Auslösung auf der CCU beschreibt ?
Ich würde gerne besser verstehen, welche Attribute verfügbar wären...

Gruß...

[dero]

Hi,

Die modulare Idee gefällt mir sehr gut! Ich nutze jetzt seit 2 Jahren FHEM und plane den Umstieg auf etwas neues. Dabei bin ich über openhab gestoltpert, aber dies ist ein echtes Kreuzfahrtschiff...

Ich habe jetzt meine eigene Logik-Umgebung in Scala gebaut und werde die gemäß den mqtt-smarthome-Richtlinien an mqtt anbinden.

Drei Fragen:
- läuft hm2mqtt mit HM-CFG-LAN?
- wie aufwändig wäre ein rfxcom2mqtt?
- eine Empfehlung für die UI? (web, android, wp, ios)

Dero

[hobbyquaker]

Hallo!

läuft hm2mqtt mit HM-CFG-LAN?

hm2mqtt benötigt einen "Schnittstellenprozess" vor dem HM-CFG-LAN. Das kann der "rfd" von eQ-3 sein (hierfür könnte man "hmcon" nutzen: https://github.com/hobbyquaker/hmcon ), alternativ wäre auch Homegear an dieser Stelle denkbar.

- wie aufwändig wäre ein rfxcom2mqtt?

Kann ich mangels rfxcom Kenntnissen nicht einschätzen. Grundsätzlich würde ich aber sagen: die *2mqtt sind keine große Sache.

- eine Empfehlung für die UI? (web, android, wp, ios)

Da ist alles mögliche Denkbar. Dank MQTT könnte man aber auch mit überschaubarem Aufwand die Visualisierung von z.B. ioBroker oder OpenHAB nutzen. Bluefox hat auch ein vis-für-Node-RED gebaut, auch das könnte eine Möglichkeit sein. Ansonsten könnte man auch was eigenes aufbauen, MQTT macht es einem relativ leicht eine Webseite oder eine iOS/Android App anzubinden. Unter dem Dach des mqtt-smarthome Projekts gibt es (stand Heute) noch keine Visualisierung.

Grüße,
Sebastian

[owagner]

Hi,

Macht es wirklich Sinn, atomar auf Ebene der "Datapoints" zu publishen ?

Guter Punkt. Das xml-rpc-Protokoll sieht tatsächlich einen Event pro Datenpunkt vor, und hm2mqtt gibt das derzeit stupide weiter.

Es gibt mehrere Möglichkeiten, damit umzugehen:

1) ich publishe weiterhin jeden Datenpunkt direkt, aber inkludiere als Subobjekt immer den gesamten Kanalstatus (hue2mqtt macht das so ähnlich)

2) ich publishe weiterhin jeden Datepunkt direkt und zusätzlich auf dem Kanalnamen selbst ein zuammengefasstes Paket mit allen Kanalwerten (ähnlich 1). Hier ist dann der Zeitpunkt des Publishens interessant -- vielleicht läßt sich hier etwas aus Multicall-Paketen ableiten o.ä., das muss ich mir mal genauer auf der niedrigen Ebene anschauen.

Gibt es eine Dokumentation die den Prozess der Event-Auslösung auf der CCU beschreibt ?
Ich würde gerne besser verstehen, welche Attribute verfügbar wären...

Es gibt die Datenpunktdokumentation, die zur Script-Doku gehört: http://www.eq-3.de/downloads.html, Suche nach "Script". Die Reihenfolge, in der Events ausgelöst werden, ist aber m.E. nirgends dokumentiert, die muss man empirisch ermitteln. Das hängt m.E. davon ab, wie der rfd eingehende Telegramme dekodiert (faktisch sind z.B. "MOTION" und "BRIGHTNESS" bestimmt ein Funktelegram)

Viele Grüße,
Olli

[owagner]

- eine Empfehlung für die UI? (web, android, wp, ios)

Kochrezept: Ich baue mir das selbst, auf Basis von AngularJS (Warnung: Ist von Google).

Es gibt ja inzwischen MQTT über Websockets, und mosquitto unterstützt das. Kleiner AngularJS-Provider, der alle Topics subscribed und diese dann als Variable im root scope anlegt -> alle Werte im AngularJS-Kontext verfügbar, z.B. in einem Template

Code: Alles auswählen

{{hm_Thermostat_Esszimmer_TEMPERATURE.val|number:1}}<

[dero]

Man könnte auch die REST-API von openhab emulieren und dann sollten auch die openhab-Clients laufen.

Hier mal eine kleine Geschwacksprobe von meiner Scala-Engine:

Code: Alles auswählen

    
    val BathroomPIR = Switch("BathroomPIR") tagged "PIRs" autoUpdate true
    val BathroomLight = Switch("Bathroom") tagged "Lights" autoUpdate true

    val BathroomPIRR = Rule("BathroomPIR ON") run { case BathroomPIR.Update(_, OnOff.ON) => BathroomLight.command(OnOff.ON) }

Deklariert einen PIR und einen Lichtschalter. Wenn der PIR seinen Status von <irgendwas> auf ON setzt, geht das Licht an. Rules werden über Scalas Patter-Matching gematcht. Das ganze ist noch eine Trockenübung, muss noch die Anbindung an mqtt basteln...

Pattern-Matching-Beispiele:

Code: Alles auswählen

    Rule("Any item updated") run { case Item.Update(who, from, to) =>println(s"Item $who received update from $from to $to") }
    Rule("Any item commanded") run { case Item.Command(who, cmd) => println(s"Item $who received command $cmd") }
    Rule("Any switch updated") run { case Switch.Update(who, from, to) =>println(s"Switch $who received update from $from to $to") }
    Rule("Any switch commanded") run { case Switch.Command(who, cmd) => println(s"Switch $who received command $cmd") }

Gruppen:

Code: Alles auswählen

    val Switches = Group.Switch("Switches") grouping Switch.regex(".*")
    val LightSwitches = Group.Switch("LightSwitches") grouping Switch.tagged("Lights")

dero

[Homoran]

Bluefox hat auch ein vis-für-Node-RED gebaut, auch das könnte eine Möglichkeit sein.

Ist hier:
https://www.npmjs.com/package/node-red-vis

Gruß
Rainer

[dero]

Ich habe eine Frage zu: https://github.com/mqtt-smarthome/mqtt- ... tecture.md

Ich nehme mal an, wenn ein "set" zu HM geschickt wird, dass HM den neuen Wert mit einem "status" quittieren wird, da HM bidirektional arbeiten. D.h. der State-Change in meinem Logik-Framework wird durch durch die "status"-Message getriggert.

Aber wie verhält es sich mit Geräten, die NICHT bidirektional arbeiten? Sollte das xyz2mqtt-Modul trotzdem per "status" ein "set" reflektieren? Damit man eine konsistente Semantik hat.

Grüße

dero

[owagner]

Eigentlich kann das nicht zwingend symmetrisch sein.

Bei hm2mqtt ist das so, eben weil HM's Datenpunktkonzept so funktioniert.

Bei knx2mqtt z.B. schon nicht mehr, da dort in der Regel Befehls- und Rückmeldegruppenadressen nicht identisch sind.

Wenn das Protokoll keinen Rückmeldekanal hat, ist das halt so, man weiss den Status nicht. Wenn man sich für den letzten Schaltbefehl interessiert, muss man halt /set/ retainen und abfragen oder cachen.

Viele Grüße,
Olli

[dero]

Okay, verstehe, d.h. die xyz@mqtt-Module sollten 1:1 die physischen Capabilities abbilden.

Dero