ZWave Bridge

psewar

Hallo zusammen,
ich versuche mich gerade daran meine ZWave-Geräte über den P44-DSB-X external ins Digitalstrom zu integrieren.
Ich habe es auch schon geschafft, dass ich die ZWave Nodes über den Usb-Stick auslesen kann und daraus InitMessages zu generieren die dann zum Beispiel die Thermostate im Digitalstrom als Blaue Klemmen erstellen.
Aber es happert noch etwas daran wie die Messages genau aussehen sollten.

Das Thermostat hat die folgenden "ZWave Events":

Temperature_Changed (Temperatursensor in Grad Celsius)
SetPoint_Changed (Eingestellte Temperatur in Grad Celsius manuell geändert)
WakeUp (Vermutlich für Digitalstrom wenig interessant)
Battery (Vermutlich in % noch nicht ganz sicher)

Hier wie die InitMessage dafür aktuell aussieht:
[{"message":"init","tag":"gZWave:10","protocol":"json","uniqueid":"gZWave:10","colorclass":3,"group":3,"output":"heatingvalve","controlvalues":true,"modelname":"MT02650 Devolo Thermostat (09356)","modelversion":"1.01","vendorname":"Danfoss","name":"Thermostat 10","buttons":[{"id":"Button_Temperature_Down","buttontype":2,"element":1,"group":48},{"id":"Button_Temperature_Up","buttontype":2,"element":2,"group":48}],"inputs":[{"id":"Input_Temperature","inputtype":11,"group":3},{"id":"Input_BatteryLow","inputtype":12}],"sensors":[{"id":"Sensor_Temperature","sensortype":1,"group":3,"updateinterval":1800}]}]

Zumindest wird das Thermostat so im Digitalstrom erstellt, auch wenn ich dann nur über die p44 den SetPoint ändern kann. Beim senden einer SetPoint aus ZWave an Digitalstrom schicke ich dann folgende Message, bekomme aber leider keine Antwort darauf vom p44:

[{"index":0,"type":"16","id":"heatingPower","value":"75","message":"channel","tag":"gZWave:10"}]

Bin ich da auf dem richtigen Weg, oder sollt ich das lieber anders machen?
Wie sollten die Messages richtig aussehen?

Beste Grüsse und vielen Dank,
Kay

luz

psewar ich versuche mich gerade daran meine ZWave-Geräte über den P44-DSB-X external ins Digitalstrom zu integrieren.

Cool 😀

psewar Wie sollten die Messages richtig aussehen?

So wie hier beschrieben.

In dem geposteten Beispiel scheint mir alles richtig, ausser dass die Message in einen Array verpackt ist mit den eckigen Klammern [ ] aussenrum. Diesen Mechanismus gibts nur für die Init-Message(s), nicht für die Kommunikation mit dem Device nachher. Also einfach die [ ] weglassen, dann funktioniert's vermutlich.

Hintergrund: Wenn das simple-Protokoll verwendet wird, kann nach der Init-Message kein JSON mehr gesendet werden. Ohne die Möglichkeit, mit dem Array mehrere Init-Messages zusammen als ein JSON-String zu senden, könnten gar nicht mehrere simple-Protokoll-Geräte auf einer Verbindung angelegt werden - nach der ersten Init-Message wäre das Protokoll auf simple umgeschaltet und weitere Init-Messages (die ja immer JSON sind) würden nicht mehr verstanden.

psewar

luz
Hmm ne das mit dem Array weglassen hatte ich auch schon probiert, leider kommt einfach gar keine Reaktion vom P44 auf meine Message. Gibt es ne Möglichkeit da nen Debug Flag oder etwas zu setzen / mitgeben, damit der P44 etwas mitteilungswilliger wird was ihm an einer Message nicht gefällt? 😉

Danke für den Link, hatte den auch verwendet um die ganzen Messages in meinem C# P44 Client zu implementieren.
Allgemein auch noch ein riesen Dankeschön für den coolen Gateway den Du da gebaut hast!

luz

psewar Gibt es ne Möglichkeit da nen Debug Flag oder etwas zu setzen / mitgeben, damit der P44 etwas mitteilungswilliger wird was ihm an einer Message nicht gefällt?

Jein - ich würde auf jeden Fall den Loglevel auf 6 stellen, dann siehst Du mehr.

Aber das Problem hier ist nicht, dass die Message an sich inkorrekt wäre, aber der Effekt ist wohl nicht das, was Du machen möchtest.

channels sind grundsätzlich outputs. Wenn das Gerät einen channel sendet (wie Deins das machst), dann ist das zum Synchronisieren, also wenn der Ausgang durch einen Einfluss von ausserhalb dS verstellt wird. Z.B. eine hue-Lampe über die hue-App. dS liest diese Werte selten überhaupt ein, aber sie sind wichtig wenn eine Szene gespeichert wird.

Nur, mir scheint, das ist nicht das was Du erreichen willst, oder?

Wenn dS die Ventilstellung (0..100% offen) beeinflussen soll, dann müsstest Du den channel heatingPower in die andere Richtung implementieren.
Wenn das Ventil nicht direkt gesteuert werden soll, sondern selber regelt und einem Raumsollwert folgen soll, dann musst Du die control message mit name=TemperatureSetPoint auswerten und dem Ventil als Sollwert übermitteln.
Wenn es darum geht, einen Sollwert für die Raumtemperatur an dS zu übermitteln, dann braucht es einen Sensor vom Typ 11 (relative Raumtemperaturerhöhung- oder Absenkung, 0.5=Standard, Wertebereich 0..1), oder einen Temperatursensor (Typ 1) mit usage=3 (Benutzerinteraktion).

Ob die Group 48 up/down-Buttons oder der Thermostat-Input in dS irgendeine sinnvolle Wirkung zeigen, habe ich keine Ahnung. Kann sein, aber gesehen habe ich das noch nie in Aktion. Hast Du da Hinweise von dS dazu?

PS: merke grade, dass ich im letzten Post Quatsch geschrieben hatte - ich habe den Array-Mechanismus auch für normale Messages mal nachimplementiert (Anfangs wars wirklich nur für die Init-Message), es spielt also keine Rolle mehr, ob mit oder ohne Array-Verpackung.

psewar

luz
Puhh ok, das mit dem LogLevel hat leider nichts gebracht selbst auf Stufe 7 sehe ich keinen Eintrag wenn ich meine Message schicke. Aber ja denke das Problem liegt wirklich daran, dass meine Messages nicht zu dem passen, was definiert wurde auf der InitMessage.

Also vielleicht beschreibe ich mal meine Ausgangslage vielleicht kannst mir dann sagen wie ich die InitMessage aufzubauen habe damit es meinem Setup entspricht.

Ich habe zum Beispiel die folgenden Heizkörper Thermostate: https://www.devolo.ch/glossar/funk-heizkoerperthermostat
Die haben neben den Down and Up Buttons zum Einstellen der Temperatur (in Celsius) auch einen Sensor der die Temperatur vor Ort misst (wird auch per ZWave übertragen) und dann sich selbst regelt anhand der eingestellten Temperatur.
Alle Temperaturen werden in Grad Celsius übermittelt im ZWave übermittelt.
Neben der Temperatur wird auch noch der Batterie Status übermittelt (z.B. 35%)
Die ganzen Werte würde ich gerne ans Digitalstrom übermitteln.
Allerdings würde ich natürlich auch gerne die Möglichkeit haben im Digitalstrom die Temperatur einzustellen (Hier muss ich dann wohl noch ne einigermassen gescheide umrechnung zwischen % und °c hinbekommen) und dies dann an die Thermostate weiterleiten.

Bisher ging ich davon aus, dass wenn ich in der InitMessage das output Property auf "heatingvalve" stelle, dass ich dann ChannelMessages an dS schicken kann mit der SetPoint Temperatur vom Thermostat,
Damit ich die vom Thermostat gemessene Temperatur an dS übermitteln kann hab ich auf der InitMessage einen Sensor definiert gehabt vom sensortype temperature (1).

Um den Battery Wert zu übermitteln, hab ich einen Input erstellt gehabt vom Typ DeviceHasLowBattery in ermangelung eines passenden sensor typs und durch vollkommene Unkentnis und Basteltrieb. 😉

Hier nochmals die InitMessage die ich dafür sende:
`{
"message": "init",
"tag": "gZWave:10",
"protocol": "json",
"uniqueid": "gZWave:10",
"colorclass": 3,
"group": 3,
"output": "heatingvalve",
"controlvalues": true,
"modelname": "MT02650 Devolo Thermostat (09356)",
"modelversion": "1.01",
"vendorname": "Danfoss",
"name": "Thermostat 10",
"inputs": [
{
"id": "Input_BatteryLow",
"inputtype": 12
}
],
"sensors": [
{
"id": "Sensor_Temperature",
"sensortype": 1,
"usage": 3,
"group": 3,
"updateinterval": 1800
}
]

Wie sollte die InitMessage korrekt aussehen für mein Szenario?

luz

Du hast darin nun einen sensortype=1, usage=3 "Sensor" (eigentlich: User-Einstellung, usage=3). Der würde (vermutlich, muss man überprüfen ob das in dS wirklich noch so funktioniert) die absolute Soll-Temperatur des Raumes beeinflussen. Den müsstest Du aus dem Einstellwert am MT02650 speisen.

Wenn Du auch noch die Ist-Temperatur im dS haben willst, dann brauchst noch einen sensortype=1, usage=1 Sensor (usage=1 = Raum).

{
  "id": "roomtemperature",
  "sensortype": 1,
  "usage": 1,
  "group": 3,
  "updateinterval": 1800
}

Damit du von dS aus die Solltemperatur verstellen kannst, musst Du die control message mit name=TemperatureSetPoint auswerten und dem Ventil als Sollwert übermitteln.

psewar Bisher ging ich davon aus, dass wenn ich in der InitMessage das output Property auf "heatingvalve" stelle, dass ich dann ChannelMessages an dS schicken kann mit der SetPoint Temperatur vom Thermostat [...]

Das ist nicht der Fall. Der Ausgangskanal bei Heizventilen ist direkt die Ventilstellung, 0..100%. Die berechnet dS intern aus Raum-Soll- und Ist-Temperaturwerten.

Wenn Du aber ein selbstregelndes Ventil hast, braucht dS nix zu berechnen, es reicht einfach, dass Du die Raum-Solltemperatur von dS erhältst. Die kommt eben über den control-value TemperatureSetPoint. Falls das Heizventil statt seinem eigenen Temperatursensor (der oft zu nah an der Heizung ist) auch einen externen Wert für die Regelung verwenden kann, dann gibts noch den control-value TemperatureZone (dazu muss es natürlich noch einen anderen, besser plazierten Raumsensor geben! Ansonsten ist es der Sensor des Ventils, der im dS als Raumsensor definiert wird und Du kriegst in TemperatureZone den eigenen Sensorwert gespiegelt)

Den channel kannst Du bei einem selbstregelnden Ventil ignorieren.

psewar Um den Battery Wert zu übermitteln, hab ich einen Input erstellt gehabt vom Typ DeviceHasLowBattery in ermangelung eines passenden sensor typs [...]

Ja, es gibt leider keinen prozentualen Batteriestands-Sensortyp im dS, nur den Typ 4 (Versorgungsspannung). Wenn Du den Batterietyp kennst, könntest Du aus den % ca. eine Spannung ableiten, etwa bei Lithiumzellen 2.6V..3.2V. Aber dann macht ein DeviceHasLowBattery eher mehr Sinn.

psewar

luz
Vielen Dank schonmal für die Hilfestellung, aber ich komm irgendwie nicht weiter.
Wenn ich dem P44 eine Message sende, sollte ich immer eine Antwort von ihm auf die Message erhalten, oder?

Hab es jetzt so umkonfiguriert wie ich es aus Deiner Nachricht gelesen habe, aber auch die Sensor Messages bleiben ohne Reaktion des P44. Auch wenn ich dort direkt die Logs anschaue auf log level 7, scheint es so als ob meine message gar nie angekommen wäre? Auch bei den "Show Inputs" werden die gesendeten Werte nie angezeigt.

Hier die Messages.
Init:
{ "message": "init", "tag": "gZWave:10", "protocol": "json", "uniqueid": "gZWave:10", "colorclass": 3, "group": 3, "output": "heatingvalve", "controlvalues": true, "modelname": "MT02650 Devolo Thermostat (09356)", "modelversion": "1.01", "vendorname": "Danfoss", "name": "Thermostat 10", "inputs": [ { "id": "heatingPower", "inputtype": 11, "group": 3 }, { "id": "Input_BatteryLow", "inputtype": 12 } ], "sensors": [ { "id": "Sensor_Temperature_Ist", "sensortype": 1, "usage": 1, "group": 3, "updateinterval": 1800 }, { "id": "Sensor_Temperature_Soll", "sensortype": 1, "usage": 3, "group": 3, "updateinterval": 1800 } ] }

Sensor SetPoint:
{ "index": 0, "id": "Sensor_Temperature_Soll", "value": "22", "message": "sensor", "tag": "gZWave:10" }

Sensor Ist:
{ "index": 0, "id": "Sensor_Temperature_Ist", "value": "25.45", "message": "sensor", "tag": "gZWave:10" }

luz

psewar Wenn ich dem P44 eine Message sende, sollte ich immer eine Antwort von ihm auf die Message erhalten, oder?

Nein. Nur die init-Message (und u.U. Fehler in anderen Messages) geben eine status-Antwort. Alle anderen Messages in beiden Richtungen sind als Notification ohne Bestätigungen zu verstehen.

psewar Hier die Messages.
Init:
[...]

Die ist technisch ok so. Ich würde den Ein- und Ausgängen noch je ein hardwarename spendieren, das ist das was in der UI der P44 angezeigt wird (und vielleicht dereinst auch im dSS, die Informationen wären dort vorhanden).
Die id hingegen ist intern für die API, die müsste nicht sooo sprechend sein.

psewar Sensor SetPoint:

Der index da drin ist falsch, 0 addressiert die Ist-Temperatur (den ersten definierte Sensor).
Weniger fehleranfällig ist die addressierung via id, die funktioniert aber nur wenn du index weglässt!
Also müsste die Message so aussehen (und als eine einzige Zeile mit LF oder CRLF am Ende gesendet werden!):

{ "id": "Sensor_Temperature_Soll", "value": "22", "message": "sensor", "tag": "gZWave:10" }

Nach dem Absenden dieser Message zeigt das log:

[2022-02-02 21:39:53.5511304182mS I] P44LoggingObj @0x102f1d600: device -> externalVdc (JSON) message received: { "id": "Sensor_Temperature_Soll", "value": "22", "message": "sensor", "tag": "gZWave:10" }
[2022-02-02 21:39:53.552     0mS N] vdSD 86BFD3C776A55ECCC0D068FC6204118F00 (Thermostat 10): sensor[1] Sensor_Temperature_Soll 'sensor_ty1': reports NEW value = 22.000 °C

psewar Sensor Ist:

Hier stimmt der Index 0, aber besser weglassen und die id verwenden:

{ "id": "Sensor_Temperature_Ist", "value": "25.45", "message": "sensor", "tag": "gZWave:10" }

Log:

[2022-02-02 21:50:07.764614211mS I] P44LoggingObj @0x102f1d600: device -> externalVdc (JSON) message received: { "id": "Sensor_Temperature_Ist", "value": "25.45", "message": "sensor", "tag": "gZWave:10" }
[2022-02-02 21:50:07.764     0mS N] vdSD 86BFD3C776A55ECCC0D068FC6204118F00 (Thermostat 10): sensor[0] Sensor_Temperature_Ist 'sensor_ty1': reports NEW value = 25.450 °C

Am einfachsten ist es, so Sachen erst mal direkt mit telnet und cut&paste auszuprobieren.

psewar

luz (und als eine einzige Zeile mit LF oder CRLF am Ende gesendet werden!):

Fast schon etwas peinlich, aber genau das war das Problem, das Json war zwar schon auf einer Zeile, hatte es nur fürs Forum aufgehübscht, aber der Serializer hat natürlich keinen LF an den Schluss gesetzt gehabt. Interessant, dass es bei der InitMessage aber trotzdem ging.

Vielen Dank für Deine Hilfestellungen, hoffe jetzt komm ich wieder für eine Weile alleine klar mit ausprobieren. 🙂