Fhemweb websockets und get ID's

[Syrex-o]

Hallo zusammen,

Im FhemNative Thread wurde ich jetzt schon öfter darauf angesprochen, wann endlich get Befehle unterstützt werden.

Leider muss ich mich immer damit entschuldigen, dass ich nicht eindeutig identifizieren kann, welches Device im Frontend welche Antwort erwartet.

Nun hat mich @mumpitzstuff netterweise auf diesen Bereich aufmerksam gemacht.

Kleine Skizze des Problems:
- Chart 1 will Daten aus einem Log
- Chart 2 andere Daten
- beide Komponenten sind in einem Raum im Frontend und senden somit nahezu synchron die Anfrage. Die Reihenfolge der Antworten ist nicht immer identisch.
--> ein Chart hat dann mindestens Falsche Werte oder keine.

Wenn ich mir etwas wünschen dürfte, sollten Websocket "get" Anfragen entweder:
- die Möglichkeit erlauben, eine ID mit zusenden
- zusätzlich mit dem Device und der FUID antworten

Gibt es grundsätzlich den Gedanken das einzubauen?

Vielen Dank im voraus.
Beste Grüße

[rudolfkoenig]

Was spricht bei so einem Setup gegen mehrere Verbindungen zu FHEMWEB?

[Syrex-o]

Was spricht bei so einem Setup gegen mehrere Verbindungen zu FHEMWEB?

Ich sehe nicht ganz, warum das nötig sein sollte.
Außerdem gibt es dann ja kein richtiges halten mehr.

Nun sollen es am Ende nicht nur Charts sein und dann bauen alle Komponenten eine Verbindung zu fhem auf?

Das scheint mir das Problem etwas zu erschlagen.

[rudolfkoenig]

Ich sehe nicht ganz, warum das nötig sein sollte.

Weil ich dann nicht was Neues implementieren muss???

Beim Laden einer Webseite macht der Browser auch mehrere Verbindungen parallel auf, will sagen, mein Vorschlag ist nicht ungewoehnlich.
Wenn die einzelnen SVGs einer Seite via <embed>-Tag oder mit JavaScript geladen werden, wird doch genau das gemacht.

Außerdem gibt es dann ja kein richtiges halten mehr.

Das habe ich leider nicht verstanden.

[Syrex-o]

Weil ich dann nicht was Neues implementieren muss???

OK, verständlich.

Die idee verstehe ich schon.

Das habe ich leider nicht verstanden.

Nun wenn man der Idee folgt, dann erstellt der nächste User einen Raum der 20 Charts enthält, die alle Daten von FHEM abfragen. Dafür baue ich dann 20 Verbindungen auf. Ist das für dieses Szenario wirklich zielführend?

Mal ein anderer Ansatz. Verarbeitet Fhemweb die Anfragen denn immer nacheinander?
Mit anderen Worten, wenn ich die Reihenfolge der Anfragen  bestimme, antwortet fhemweb dann definitiv in dieser Reihenfolge?

[rudolfkoenig]

Mit anderen Worten, wenn ich die Reihenfolge der Anfragen  bestimme, antwortet fhemweb dann definitiv in dieser Reihenfolge?

Haengt davon ab:
Generell ist FHEM Single-Threaded, d.h. wenn eine Aufgabe ohne Weiteres berechnet werden kann dann ja.
Ausnahme: falls ein get Aufruf FHEM blockieren kann (z.Bsp. wg Anfrage an externes Geraet, und warten auf die Antwort), dann koennen Module die Antwort per "asyncOutput" liefern, z.Zt. nutzen diese Moeglichkeit 25 Module aus 500+.
In diesem Fall liefert get zunaechst nichts zurueck, und wenn die Antwort vom Geraet eintrifft, werden ueber FHEMWEB die Daten in einem JSON so eingepackt, dass die Gegenstelle (fhemweb.js) das erkennt, und die Daten asynchron im Dialog anzeigt. Wenn man zwei solche Anfragen ueber die gleiche Verbindung absetzt, dann kann man die Antwort nicht der Frage zuordnen.

[Syrex-o]

Haengt davon ab:
Generell ist FHEM Single-Threaded, d.h. wenn eine Aufgabe ohne Weiteres berechnet werden kann dann ja.
Ausnahme: falls ein get Aufruf FHEM blockieren kann (z.Bsp. wg Anfrage an externes Geraet, und warten auf die Antwort), dann koennen Module die Antwort per "asyncOutput" liefern, z.Zt. nutzen diese Moeglichkeit 25 Module aus 500+.
In diesem Fall liefert get zunaechst nichts zurueck, und wenn die Antwort vom Geraet eintrifft, werden ueber FHEMWEB die Daten in einem JSON so eingepackt, dass die Gegenstelle (fhemweb.js) das erkennt, und die Daten asynchron im Dialog anzeigt. Wenn man zwei solche Anfragen ueber die gleiche Verbindung absetzt, dann kann man die Antwort nicht der Frage zuordnen.

Dann besteht ja quasi doch ein weiterer Bedarf dafür, anstatt mehrere Verbindungen herzustellen.

Wenn das natürlich erstmal nicht geplant ist, dann implementiere ich get Befehle als eigene Verbindung, die anschließend getrennt wird.

[rudolfkoenig]

Dann besteht ja quasi doch ein weiterer Bedarf dafür, anstatt mehrere Verbindungen herzustellen.

Sehe ich (noch) nicht.

Diese Befehle werden einzeln von Menschen ausgefuehrt, die Antworten kommen "normalerweise" schnell, und man setzt "normalerweise" nicht mehr als einen ab, bevor die Antwort angekommen ist. Und wenn es nicht normal laeuft, dann muss die Antwort vom Benutzer im Kopf zu der Frage zugeordnet werden.

[justme1968]

es gibt noch mehr fälle in denen antworten asynchron kommen können. und sogar die antworten eines einzigen geräts können out of order zurück kommen.

das macht das zugrundeliegende problem sehr viel komplexer da es nicht reicht eine antwort einem gerät zuzuordnen sondern sie auch dem konkreten kommando zuordnen muss.

das öffnen einer verbindung pro kommando deckt alle diese fälle und vermutlich noch mehr jetzt schon korrekt ab. von daher ist es ganz und gar nicht die schlechteste lösung.


ich denke im normalen betrieb fällt das ganze in zwei kategorien: der benutzer setzt ein paar kommandos interaktiv ab (die anzahl ist überschaubar) oder es werden mehrerere charts mit get geholt (die datenmenge pro get ist recht gross). in beiden fällen sollte sich der overhead durch neue verbindungen in grenzen halten.

beim initialen verbindungsaufbau sollte man die daten nicht mit get abholen sondern per list oder jsonlist und aktualisierungen sollte man dann oder longpoll bekommen. in beiden fällen stellt sich das problem der zuordnung dann nicht.

[Syrex-o]

Ich stimme dir vollkommen zu.

Ich werde die Variante mit einzelnen Verbindungen und get Befehlen testen.
Spannend war die Frage eigentlich besonders aus einem Grund:
Es wurde schon eine websocket Implementierung für FHEM geschrieben, die genau das macht.
Das Device antwortet mit dem Ergebnis und dem Device Namen, für die Zuordnung.

Ich vergleichel die beiden Varianten mal und berichte dann.