aller erster proof of concept für longpoll im json format

[justme1968]

anbei ein sehr rudimentärer 'proof of concept' wie longpoll messages im json format aussehen könnte.

das format schaut aktuell so aus:
{ "event": {"device": <name>, "reading": <name>, "value": <wert>, "timestamp": <ts>} }
{ "state": {"device": <name>, "STATE": <wert>, "value": <icon>} }

anmerkungen:
- durch das zusammenfassen von readings wert und readings timestamp sind es unterm strich
  nicht mehr daten als im aktuellen format die über die leitung gehen. wenn man die ziemlich langen
  und sprechenden namen noch etwas einkürzt könne man sogar sparen.

- auf perl seite habe ich zum testen erst mal das json modul und encode_json verwendet.
  damit muss man sich erst mal keine gedanken um das maskieren von sonderzeichen machen.
  eine endgültige version würde das vermutlich trotzdem selber machen damit das json modul nicht
  voraussetzung ist.

- die fhemweb js seite ist komplett rückwärts kompatibel. die json nachricht wird wieder in das alte
  3-element-array format umgewandelt so das fhemweb widgets mit setValueFn oder updateLine damit
  erst mal weiter funktionieren.

- wenn man auf json umstellt ist es vermutlich sinnvoll in FW_widgets eine longpollFn zu haben die direkt
  die json daten bekommt und eventuell eine messageFn für die privaten nachrichten.

- ich habe noch keine extra nachricht für die attribut änderungen eingebaut.
  da auf js seite alles rückwärts kompatibel ist geht es trozdem. das sollte für die richtige version natürlich
  eingebaut werden.

- die #FHEMWEB nachrichten kommen noch im alten 3-elemente-array format
  dafür sollte man über eine modul eigene nachricht gehen.

- was ich hier zum testen nicht gemacht habe ist das json format optional zu machen. eine endgültige version
  braucht das natürlich damit die anderen frontends zeit zum umstellen haben.

das ganze ist erst mal als diskussionsgrundlage und zum testen mit anderen frontends gedacht. wie das format der nachrichten am besten ausschaut und welche nachrichten es von fhem gibt wäre festzulegen. so lange sich module mit eigenen anforderungen an die nachrichten an das vorgegebene format halten ist das ganze dann auch sehr gut erweiterbar.

beispiele für modul spezifische nachrichten:
- nachrichten zwischen fhemweb und browser (dialog auf machen, js code ausführen,...)
- readingsGroup update nachrichten. hier könnte ich zeilen uns spalten nummern verwenden statt
  künstlicher reading namen
- readingsHistory nachrichten zum aktualisieren oder löschen einer bestimmten zeile


edit: im oben verlinkten thread ist eben auch die idee aufkommen das man alle readingsUpdates aus einem BulkUpdate in einer json nachricht zusammen fasst. damit würden auch die frontends mit bekommen wenn events zusammen gehören. die übertragene datenmenge wird dadurch noch geringer da man das device nur ein mal übertragen muss und auch identische timestamps nur ein mal.

[Thorsten Pferdekaemper]

Hi,
vielleicht habe ich da was verpasst...
Wozu ist das ganze gut? Oder anders gefragt: Welches Problem wird damit gelöst?
Bevor es zu Missverständnissen kommt: Das sind echte Fragen, es ist nicht wertend gemeint.
Gruß,
   Thorsten

[justme1968]

damit wird gelöst:

- das format der nachrichten ist dokumentiert, standardisiert und erweiterbar
- die übertragene datenmenge ist (etwas) geringer
- wert und timestmap kommen atomar in einer nachricht
- encoding probleme werden vermieden
- module die direkt mit dem frontend kommunizieren wollen können das über den gleichen generellen weg tun
- vor allem in verbindung mit den websockets ist das ganze für andere frontends deutlich sauberer
  da direkt device und reading namen übertragen werden statt alles in einen string zu packen
- ...

ansonsten gibt es schon zwei oder drei threads die das in der vergangenheit mehrfach angesprochen haben.

[DeeSPe]

Ich kenne mich mir der ganzen bisherigen longpoll Implementierung leider überhaupt nicht aus.
Habe mir bisher auch noch nicht die Mühe gemacht das JS auseinander zu pflücken, es war einfach bisher nicht nötig...
Die Idee finde ich aber wirklich gut, besonders auch das Zusammenfassen der Events aus readingsBulkUpdate.
Die anderen Auswirkungen kann ich leider nicht beurteilen.
Andre's Erklärungen klingen aber sinnvoll.

Gruß
Dan

EDIT:
Was spricht gegen?

Code Auswählen Erweitern

{ "e": {"d": <name>, "r": <name>, "v": <wert>, "t": <ts>} }
{ "s": {"d": <name>, "S": <wert>, "v": <icon>} }