Problem bei Upgrade auf SmartVISU 3.1 und OpenHAB3

[wu3mi]

Hallo zusammen,

Winterprojekt ist halt immer die smartVisu ;-)

Ich will mein aktuelles Setup (SV2.9 und OH2) auf die aktuellsten umstellen.
Openhab ist bereits geschehen und nun folgt die Visualisierung.

Es klappt bereits einiges - einiges muss auf Grund des neuen Treibers umgeschrieben werden > aber alles gut
Ich hab nur leider so nen lästigen Fehler und ich komm einfach nicht dahinter.

Zeitüberschreitung!

Leider kann ichs nicht zuordnen, von wo der Fehler kommt.

Für nen Hint wäre ich dankbar.

many thx
wu3mi

[wvhn]

Zum Treiber kann ich leider mangels Wissen kaum Hilfestellung leisten. Hier gibt es ein paar Hintergründe dazu. Ohne Authentifizierung sollte demnach der openhab2-Treiber auch noch mit openHAB 3 funktionieren.

Aus meiner Sicht ist noch ein Bug im Treiber Zeile 32 bei timeout. Dies müsste 5000 sein, wenn 5 Sekunden gemeint sind, da der Timeout in Millisekunden angegeben wird.

Wenn das nicht ausreicht, deaktiviere mal "realtime" auf der smartVISU-Konfigurationsseite im Treiber-Abschnitt. Dort scheint zumindest der Timeout-Fehler im Zusammenhang mit der eventsource.js herzukommen.

Gruß
Wolfram

[wu3mi]

Hallo wvhn

besten Dank für das Schnelle Feedback.

An das Realtime hatte ich ebenfalls gedacht > dies hat leider nichts geholfen.

hab nun den Timeout von 5 auf 5000 geändert (final nun auf 50) und die Fehlermeldung kommt nicht mehr.
Im Treiber steht jedoch, dass dies Angeben in [s] sind. Nun bin ich etwas verunsichert.
Weißt du, wer den Treiber geschrieben hat?

besten Dank im Voraus

[wvhn]

Der Treiber stammt von PatrikG.
Tatsächlich wird der Timeout in der init-Methode des Treibers nochmal mit 1000 multipliziert - also in Millisekunden umgerechnet. Das hatte ich übersehen. Warum das erst im Code gemacht wird und ob das überall wirkt, überblicke ich nicht. Die Tatsache, dass der Fehler bei Dir im Abstand von 2-3 Millisekunden kam und mit der Verlängerung des timeout jetzt weg ist, deutet m.E. auf einen Fehler an dieser Stelle hin.

Gruß
Wolfram

[PatrikG]

An das Realtime hatte ich ebenfalls gedacht > dies hat leider nichts geholfen.

Schwer vorstellbar, da die Meldungen des ersten Screenshots von der eventsource.js (Drittanbieter) stammen, welche eigentlich nur aktiviert wird, wenn realtime=true und die Authentifizierung aktiv ist. Demzufolge sollten die Meldungen des ersten Screenshots nach Deaktivierung von realtime verschwinden. Diese Meldungen sind, wenn ich mich recht erinnere, by-design, denn der Entwickler des Polyfill hat da einen automatischen Reconnect eingebaut und dieser steht auf 60000ms. Ausschalten kann man den nicht und auch nicht, dass dies als error angezeigt wird.

Nun zum zweiten Fehler: Wenn die Zeitüberschreitungen bei Erhöhung des timeouts weg sind, dann ist dein OpenHAB-Server eindeutig zu langsam. Und ja, es sind Sekunden. Es sind nur deswegen so viele "zeitgleiche" Meldungen, weil für jedes Item auf der Seite ein eigener Serveraufruf zur Statusabfrage initiiert wird und jeder Aufruf seinen eigenen timeout hat. Erst danach startet die Eventsource die auf Statusänderungen wartet.

An diesem Verhalten ändert auch der realtime-Switch nichts. Ganz im Gegenteil: wenn der false ist, dann wird jedes Item per refreshtimer (Standard: jede Sekunde) neu abgefragt, soll heißen alles startet wieder von vorne.

[wu3mi]

Hallo Patrik PatrikG

danke fürs Feedback. Die Screenshots sind mit "realtime = true" >> das Zitat von mir in deinem Post bezog sich auf die generellen Fehlermeldungen. Wie gesagt, ich konnte es nicht zuordnen.

Das mit dem "zu langsamen Server" hatte ich auch vermutet > hab die beiden Systeme auf zwei verschiedenen System laufen. Ich werde es die Tage mal auf dem OH Server laufen lassen.

Generelle Beobachtung:
Wenn ich den openhab2 Treiber wähle, kommen
a) die Inhalte von OH schneller
b) keine Fehlermeldung wegen zeitüberschreitung o.ä.

Wenn ich den openhab Treiber wähle kommt bei

 // servertimeout in seconds
    timeout : 10,

kein Fehler der Zeitüberschreitung mehr.

Ich melde mich wieder wenn ich SV auf den OH Server gesiedelt habe.

danke für eure Arbeit und Bemühungen

[PatrikG]

Der grobe Unterschied zw. den beiden Treibern ist die Verwendungsmöglichkeit von Authentifizierung und der Eventhandler, da der Namespace zw. OH2 und OH3 unterschiedlich ist. D.h. der OpenHAB2-Treiber geht, wenn die Authentifizierung nicht benötigt und Realtime aus ist. Ist Realtime an dann läuft zwar der Eventhandler, aber der bekommt nie Daten, da der verwendete Namespace nicht stimmt.

[wu3mi]

Hallo PatrikG ,

hab nun testweise die SV auf dem gleichen Gerät/Server wie OH und leider muss ich den Timeout noch immer größer 10s halten.
stört mich jetzt aber nicht.

Ich strauchle noch etwas mit dem "eventhandler" > hatte ich bisher noch nicht am Schirm > was genau sind die Vorteile bzw. die Features?

Danke

[wvhn]

Die Visu läuft im wesentlichen auf dem Client - abgesehen von den php-Skripten. Die SV auf den OH-Server umzuziehen, macht zumindest aus Sicht der Treiber-Performance wenig Sinn, weil sie an dem Kommunikationsweg zwischen OH-Server und Browser nichts ändert.

Es wäre schon gut zu wissen, was die Kommunikation so ausbremst, dass Du 10 Sekunden Timeout einstellen musst. Kannst Du das in den Entwicklertools des Browsers nachvollziehen? Dort kannst Du Dir einzelne „Anfragen“ anzeigen lassen, oder „XHR“. Auch das Timing kannst Du Dir anzeigen lassen.

Gruß
Wolfram

[PatrikG]

OpenHAB ist ne JAVA-Anwendung und benötigt allein schon deswegen auch entsprechende Ressourcen. Mit nem Raspi oder ähnlichen wird das nicht wirklich prickelnd.
Ich glaube, dass im 2.9-Treiber noch kein Timeout integriert war, dadurch war das hier noch egal, da wurde gewartet bis halt was kam.

Beim Aufruf einer Seite mit SV-Items werden zuerst die Grunddaten inkl. Status aller auf der Seite befindlichen SV-Items vom OpenHAB-Server abgefragt. Jedes SV-Item erzeugt dabei einen eigenen Serveraufruf. Wenn Echtzeit-Daten aktiviert ist, wird der Eventhandler aktiviert. Dieser öffnet einen Kanal zum OpenHAB-Server und wartet auf Statusänderungen von den Items auf der jeweiligen SV-Seite, damit der Status der SV-Items in Echtzeit aktualisiert wird. Ändert sich nichts, passiert auch nichts.
Ist Echtzeit-Daten deaktiviert, fordert SmartVISU von sich aus jede Sekunde den Status der angezeigten SV-Items vom OpenHAB-Server an, egal ob geändert oder nicht.
Echtzeit-Daten ist also schneller und ressourcenschonender.

Ich würde mal "klein" anfangen. Eine SV-Seite mit nur einem einfachen Item zum Schalten mit Status. Im Treiber den Debugswitch auf true setzen und dann die Seite aufrufen. Da wird dann schon mal viel protokolliert. Wenn das funktioniert dann würde ich schauen, ob ich damit schalten kann und ob geänderte Status angekommen usw.

[wu3mi]

Ich werde die nächsten Tage mal die html sites bereinigen. Ich vermute, dass einige items ins "Leere zeigen".
Werde anschließend die Kommunikationszeiten checken und mich danach wieder melden.

Danke

[wu3mi]

PatrikG


ich bin noch immer am Säubern meiner Visu (alte widgets ersetzen und der Gleichen) und bin aktuell beim device.shutter.
Mein Eintrag:

{{ device.shutter ('EG_Kueche_RollladenWest', 'Rollladen West', 'Rollladen_EG_KuecheWest','','','','','', '','0','100') }}

Laut Doku:

{{ device.shutter(id, txt, item_move, item_stop, item_pos, item_shift, item_angle, item_saved, value_top, value_bottom, step, mode, background, value_pos_1, value_pos_2, text_pos_1, text_pos_2) }}

In OH ist Rollladen_EG_KuecheWest ein rollershutter item und empfängt (UP | DOWN | STOP)
Wenn ich wie oben angeführt es mit debugge, bekommt ich leider beim "DOWN" command ein "STOP" (=value 1) >> sollte mEn "100" sein. 100 wird im Treiber als DOWN interpretiert.

Ich komme aktuell nicht dahinter an was es liegen könnte.

thx

[PatrikG]

hast du https://github.com/Martin-Gleiss/sma...nts_openHAB.md gelesen?

Ich habe device.shutter damals nicht getestet, aber ich denke es verhält similär zu device.blind .

[wu3mi]

PatrikG

ja, die hints hab ich gelesen aber leider hatte ich keinen Erfolg.
Beim Debuggen sehe ich, dass bei smartvisu "UP" eine "0" gesendet wird und bei smartvisu DOWN eine "1".
Laut Definition und Treiber ist 0 = UP, 1 = STOP, 100=DOWN.
Hab nun schon mehrmals meinen Eintrag (siehe oben) gecheckt, doch leider kein erfolg bei device.shutter und device.blind.
Ich denke, dass es nicht am Treiber liegt sondern eher, was ich richtung treiber geschickt wird.

[wvhn]

Up und down in dem Sinne gibt es bei dem Openhab Rollershutter nicht. Es gibt nur item_pos, das die Position in Prozent angibt.

{{ device.shutter('', '', '', 'RollershutterItem', 'RollershutterItem', '', '', '',0, 100) }}

sollte funktionieren. Notfalls kannst Du 0 und 100 für min und max tauschen, wenn die Richtungen nicht passen. Auf item_stop wird eine 1 gesendet, wenn die Stoptaste betätigt wird.

Gruß
Wolfram