Status-Updates via websocket (longpoll) zu Java

[rudolfkoenig]

readingsUpdate statt event ist irrefuehrend, weil ersteres nicht immer ein event erzeugt.

Wer den Patch baut, soll bitte nicht vergessen, dass:
- er etliches umbauen (FHEMWEB.pm, fhemweb.js, fhemweb_*.js) und alles testen darf.
- es weitere Applikationen gibt, die auf dem aktuellen Format angewiesen sind, d.h. "tabula rasa" ist nicht drin.

[justme1968]

naja... es ist die nachricht die über die änderung eines readings informiert. von daher passt es schon. der punkt ist das nicht alle events readings änderungen sind und man das auch im format zum ausdruck bringen sollte.

[justme1968]

ich habe hier: https://forum.fhem.de/index.php/topic,70903.0.html mal etwas code gepostet mit dem man das ganze testen und dann darüber diskutieren kann.

[philipptrenz]

Danke dir! Es scheint als hätte ich (noch?) keine Berechtigung in FHEM Development zu schreiben. Deshalb eine kurze Anmerkung hier, vielleicht kannst du sie übernehmen:

Ich bin gestern über die HUEDevice Websocket Message gestolpert, diese gibt mehrere Readings zurück. Das sollte auf jeden Fall berücksichtigt werden

Code Auswählen Erweitern


["HUEDevice1","dim06%","..."]
["HUEDevice1-onoff","1","1"]
["HUEDevice1-onoff-ts","2017-04-20 17:42:20","2017-04-20 17:42:20"]
["HUEDevice1-pct","1","1"]
["HUEDevice1-pct-ts","2017-04-20 17:42:20","2017-04-20 17:42:20"]
["HUEDevice1-state","dim06%","dim06%"]
["HUEDevice1-state-ts","2017-04-20 17:42:20","2017-04-20 17:42:20"]


Mein Vorschlag wäre daher die Readings zu entkoppel. In dieser Schreibweise besteht auch die Möglichkeit, weitere Devices mitzuliefern etc.:

Code Auswählen Erweitern


{
"event": {
"HUEDevice1": {
"onoff": { "value":"1", "timestamp":"2017-04-20 17:42:20" },
"ptc": { "value":"1", "timestamp":"2017-04-20 17:42:20" },
"state": { "value":"dim06%", "timestamp":"2017-04-20 17:42:20" }
}
}
}


[justme1968]

ja. mehrere reading events in eine nachricht zusammen zu fassen könnte sinnvoll sein. wenn alle timestamps identisch sind könnte man die auch eine ebene höher ziehen und die nachricht noch kürzer machen.

generell sollten alle devices änderungen an mehreren readings zusammen fassen. aktuell ist das aber nur fhem intern zu sehen.

[justme1968]

als format würde ich eher so etwas vorschlagen:

Code Auswählen Erweitern

{
"event": {
"device": "HUEDevice1", "timestamp":"2017-04-20 17:42:20" , "readings" : [
{ "reading": "onoff", "value":"1" },
{ "reading": "ptc", "value":"1" },
{ "reading": "state", "value":"dim06%" }
]
}
}

[philipptrenz]

Sofern der timestamp stets identisch ist, müsste das ja passen. Können mit einem Event mehrere Devices getriggert werden? Oder ist das evtl. zukünftig geplant?
Wenn der Name root-Node ist, wäre auch das möglich. Damit bleibt das Format ausbaubar.

Code Auswählen Erweitern

{
"event": {
"HUEDevice1": {
"timestamp":"2017-04-20 17:42:20",
"readings" : [
{ "reading": "onoff", "value":"1" },
{ "reading": "ptc", "value":"1" },
{ "reading": "state", "value":"dim06%" }
]
},
"HUEDevice2": {
"timestamp":"2017-04-20 17:42:20",
"readings" : [
{ "reading": "onoff", "value":"1" },
{ "reading": "ptc", "value":"1" },
{ "reading": "state", "value":"dim06%" }
]
}
}
}

[justme1968]

nein. in einem BulkUpdate block kann immer nur ein device aktualisiert werden.

wenn ein reading mit einem abweichenden timestamp dabei ist kann man das so abbilden:

Code Auswählen Erweitern

{
"event": {
"device": "HUEDevice1", "timestamp":"2017-04-20 17:42:20" , "readings" : [
{ "reading": "onoff", "value":"1" },
{ "reading": "ptc", "value":"1", "timestamp":"2017-04-20 17:42:10" },
{ "reading": "state", "value":"dim06%" }
]
}
}

das ist aber eine ziemliche ausnahme. bzw. passiert eigentlich nur wenn in einem rutsch mehrere historische werte für das gleiche reading gesetzt werden. d.h. das gleiche reading kann im prinzip mehrfach auftauchen.

[philipptrenz]

Alles klar! Aber solche Ausnahmen sind immer gefährlich in der Implementierung übersehen zu werden. Ist die Nachrichtenlänge so entscheidend für die Performance? Werden die longpolls nicht asynchron gepusht? Sonst fände ich die Ausgabe mit timestamp je reading doch schlüssiger und weniger missverständlich.