fhem.js - websocket connection to fhem via node.js proxy

rretsiem · 28 April 2015, 15:42:56

Zitat von: Werner Schäffer am 28 April 2015, 14:18:30
Außerdem bin ich nach wie vor der Ansicht dass dies nur eine Hilfslösung ist und das eigentliche Ziel sein sollte die Websocket-Funktionalität direkt in fhem.pl einzubauen.

Der Ansicht bin ich auch, aber mangels Perl-Kenntnissen ist das ein Problem, dass ich nicht lösen kann.

Zitat
Außerdem ist mir die Abfolge "inform on -> get change -> open telnet -> JsonList2 device ->wait for response -> emit JsonList an client" einfach nicht sympatisch und widerspricht meinen Vorstellungen.

Ich bin da ja gern lernfähig, aber was ist denn der Unterschied zu deiner Lösung mit:
"inform on -> get change wenn foundSingleEntity -> open telnet -> list * -> parse compl. list result -> update buffer -> emit an listener"

im Vergleich meine:

"inform on -> get change "immer" -> open telnet -> Jsonlist2 <device> -> result in Buffer -> emit an listener"

Werner Schäffer · 28 April 2015, 19:42:24

Zitat von: rretsiem am 28 April 2015, 15:42:56

"inform on -> get change wenn foundSingleEntity -> open telnet -> list * -> parse compl. list result -> update buffer -> emit an listener"

im Vergleich meine:

"inform on -> get change "immer" -> open telnet -> Jsonlist2 <device> -> result in Buffer -> emit an listener"

wenn du dir das genau anschaust sieht das so aus:

"inform on -> emit an client -> (get change wenn not foundSingleEntity -> open telnet -> list * -> parse compl. list result -> update buffer)"

der emit findet sofort statt - das andere passiert erst danach - warum ich dieses nachlesen mache weiß ich gerade auch nicht mehr - das nehme ich vielleicht wieder raus

rretsiem · 28 April 2015, 20:48:43

Macht Sinn und wenn du es so erklärst dann sehe ich auch den Fehler bei mir.
Wenn es also einen Weg geben würde das inform on sauber in eine vorhandenen JSON Buffer zu "mergen" und währenddessen bereits den emit() zu schicken müsste ich auch kein Jsonlist2 <device> extra machen.
Leider ist mir das eben mit dem Format welches inform in liefert nicht gelungen.
Zumindest nicht mit den Versuchen die ich bisher unternommen hatte, da es nach dem 3. Wert in der Zeile schwierig ist daraus ein JSON zu generieren.
Hast du dazu eine Idee?

Ich finde halt weiterhin das "list" mit seinen gelieferten Werten sehr schlecht als Ausgangswert für einen Buffer.

Werner Schäffer · 01 Mai 2015, 16:05:30

Zitat von: rretsiem am 28 April 2015, 20:48:43
...
Wenn es also einen Weg geben würde das inform on sauber in eine vorhandenen JSON Buffer zu "mergen" und währenddessen bereits den emit() zu schicken müsste ich auch kein Jsonlist2 <device> extra machen.
Leider ist mir das eben mit dem Format welches inform in liefert nicht gelungen.
Zumindest nicht mit den Versuchen die ich bisher unternommen hatte, da es nach dem 3. Wert in der Zeile schwierig ist daraus ein JSON zu generieren.
Hast du dazu eine Idee?
...

Ich habe mir das nochmals angeschaut und ich sehe da auch keine Möglichkeit das zu mixen. Es bleiben 3 Möglichkeiten:

1.) Nur mit list und inform
2.) alles mit JsonList2
3.) man macht beides, aber voneinader getrennt

Ich habe mich für 3. entschieden, da ich 1.) einfach so brauche. Ich habe jetzt einfach noch 'getDeviceOnChange' und 'getAllDevicesOnChange' eingebaut. Diese beiden liefern dann eine JsonList2 der Device die sich geändert hat. Getriggert wird dies auch über "inform" und dann einen JsonList2 Request für die geänderte Device.

Auf Client-Seite kann man dann entscheiden ob man nur den Wert haben, der auch schnell geliefert wird oder ober man die ganze JsonList2 haben will, was aber länger dauert. Bei mir sind da manchmal bis zu 5 Sekunden vergangen.

Das die Werte bei 1) in einem Buffer gespeichert werden, kann man sicher diskutieren. Er bringt ohne Zweifel einen kleinen Performancevorteil wenn man alle Werte haben will, da sie ja nicht erst von fhem geholt werden müssen. Aber der Gewinn ist wirklich sehr gering, da der List im Gegensatz zum JsonList2 sehr schnell beantwortet wird und man bei Bedarf einfach Daten sich von fhem.pl holt anstatt sie aus dem Buffer zu holen. Wenn ich mir meine Client-Anwendung anschaue, bei der ich diesen "list" unbedingt brauche, so wird das aber nur sehr selten aufgerufen (1 bis 2-mal pro tag).

Werner Schäffer · 01 Mai 2015, 16:08:15

Achja, die Client-Anwendung von der ich da dauernd spreche ist eine Android Widget und seit heute im Google-Shop als
"FHEMswitch" zu finden.

Werner Schäffer · 04 Mai 2015, 19:54:51

Es gibt eine neue Version auf

https://github.com/winne27/fhem.js

Enthalten sind ein paar kleiner Bug-Fixes.

Werner Schäffer · 26 Mai 2015, 15:15:36

Auf https://github.com/winne27/fhem.js gibt es eine neue Version von fhem.js

Die neue Version enthält einen Bugfix und einen neuen Parameter "extendedMode" mit dem gesteuert werden kann, ob bei einer Statusänderung einer fhem-Device auch ein JsonList2 für diese Device an Clients ausgeliefert werden soll. Wird dies nicht benötigt, kann dieses Feature abgeschaltet werden, was einiges an Resourcen spart. Default: abgeschaltet.

Werner Schäffer · 06 September 2015, 13:43:47

Auf https://github.com/winne27/fhem.js gibt es eine neue Version von fhem.js

Die neue Version beseitigt ein Problem mit Devices, die ein "_" in ihrem Namen hatten.

nofear87 · 16 Oktober 2015, 08:52:13

Klasse Arbeit Werner! Genau sowas habe ich gesucht.

Hast du dir zufällig schon einmal Gedanken darüber gemacht wie man die LogFiles am besten über die "API" anbietet um beispielsweise auf dem Client Plots zu erzeugen (z.B. mit D3.js)?

Werner Schäffer · 16 Oktober 2015, 16:01:59

Eine einfache Möglichkeit gibt es dafür schon:

in der params.js steht defaultmäßig

exports.pathHTML = false;

dies ersetzen durch

exports.pathHTML = /path/to/fhem/logs;

Jetzt lassen sich die Logfiles mit http://fhem.js.url:yourport/logfile_name im Client einlesen.

Dies ist allerdings ein http-Request und kein Websocket-Request mit serverseitiger automatischer Aktualisierung. Zur Aktualisierung muss hier clientseitig immer das gesamte Logfile neu geladen werden.

Falls fhem.js neue Logeinträge automatisch über Websockets ausliefern soll müsste man schon nochmals richtig Hand anlegen an fhem.js

nofear87 · 17 Oktober 2015, 08:30:45

Ok, so ähnlich habe ich mir da auch gedacht. Ich werde mal ein bisschen experimentieren. Danke!

KOAL · 20 Oktober 2015, 22:13:07

Hallo Leute,

hab ne "blöde" Frage, wie installier ich diesen Server, benötige den doch für FHEMswitch.
geht das mit wget...und dann?? oder muss ich das ZIP-File auf den RPI kopiern??

Sorry, dafür bin ich zu blöd.

LG
KOAL

nofear87 · 30 Oktober 2015, 14:55:40

Zitat von: Werner Schäffer am 16 Oktober 2015, 16:01:59
Eine einfache Möglichkeit gibt es dafür schon:

in der params.js steht defaultmäßig

exports.pathHTML = false;

dies ersetzen durch

exports.pathHTML = /path/to/fhem/logs;

Jetzt lassen sich die Logfiles mit http://fhem.js.url:yourport/logfile_name im Client einlesen.

Dies ist allerdings ein http-Request und kein Websocket-Request mit serverseitiger automatischer Aktualisierung. Zur Aktualisierung muss hier clientseitig immer das gesamte Logfile neu geladen werden.

Falls fhem.js neue Logeinträge automatisch über Websockets ausliefern soll müsste man schon nochmals richtig Hand anlegen an fhem.js

brauch node.js nicht root rechte um an die logs zu kommen?

HansDampfHH · 24 Januar 2016, 18:31:14

Ich nutze fhem.js nun bereits einige Zeit und bin sehr zufrieden.
Super Arbeit !

Aktuell habe ich auch Max Wand- und Heizthermostate. STATE steht in fhem auch bei zum Beispiel 22.5 °C.
Über den Socket bekomme ich aber über getAllValuesOnChange folgenden Response:
"Wandthermostat":"MAXLAN_errorInCommand:"

Kann mir jemand vielleicht einen Hinweis geben was da los ist und wie ich das beheben kann?

Werner Schäffer · 24 Januar 2016, 18:48:34

Zitat von: HansDampfHH am 24 Januar 2016, 18:31:14
...
Aktuell habe ich auch Max Wand- und Heizthermostate. STATE steht in fhem auch bei zum Beispiel 22.5 °C.
Über den Socket bekomme ich aber über getAllValuesOnChange folgenden Response:
"Wandthermostat":"MAXLAN_errorInCommand:"
...

Geb mal auf dem Server folgenden Befehl ein:

telnet localhost 7022

und dann im Telnet-Prompt

inform on

und beobachte den Output der dann bei jeder State-Änderung erzeugt wird. Tritt dein Problem dort schon auf so ist es ein fhem Problem und du musst das hier im Forum an einer anderen Stelle einbringen. Ansonsten nochmals hier!

Anmerkung: ich habe Homematic Thermostaten und die haben auch ihre eigene Philosophie und man bekommt über inform on auch nicht alle Informationen die man gern hätte. Workarround: definiere in fhem einen Dummy der mit den Werten deines Wunsches gefüllt wird. Dies bekommt man dann über inform on mit.