[hm.js] testversion: icons für commState, cfgState, rssi, battery, sabotage, ...

[Pfriemler]

f..k ... Antwort fast fertig, einmal falsch geklickt, alles weg. Also nochmal:

Sorry, gestern war PC-freier Tag. Aber jetzt.

Habe die Prozedur mit altem HMInfoTools.js und ungepatchter fhemweb.js erst einmal geübt. Fehler gibt es nur, wenn ich hminfo ohne Konsole aufrufe und die Konsole erst danach öffne. Dann kann ich sowas wie hier herausziehen:

Code Auswählen Erweitern

11:54:29.609 11:54:29.609 ERRMSG:< fhemweb.js:517:13
11:54:29.610 11:54:29.611 Inform-channel opened (websocket) with filter hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1 fhemweb.js:517:13
11:54:29.611 Firefox kann keine Verbindung zu dem Server unter ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1;since=1614596034.548;fmt=JSON&fw_id=161124&timestamp=1614596069609 aufbauen. fhemweb.js:1250:18
11:54:29.612 11:54:29.613 Inform-channel opened (websocket) with filter hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1 fhemweb.js:517:13
11:54:29.613 Die Verbindung zu ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1;since=1614596034.548;fmt=JSON&fw_id=161124&timestamp=1614596069609 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1250:18
11:54:29.613 11:54:29.613 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< fhemweb.js:517:13
11:54:29.613 Firefox kann keine Verbindung zu dem Server unter ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1;since=1614596034.548;fmt=JSON&fw_id=161124&timestamp=1614596069612 aufbauen. fhemweb.js:1250:18
11:54:29.614 11:54:29.615 HMinfoTools: "Connection lost" detected! (011111) fhemweb.js:517:13
11:54:29.615 11:54:29.615 HMinfoTools: close and open informchannel fhemweb.js:517:13
11:54:29.635 Die Verbindung zu ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1;since=1614596034.548;fmt=JSON&fw_id=161124&timestamp=1614596069612 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1250:18
11:54:29.684 GEThttp://192.168.178.108:8088/fhem?detail=hminfo
[HTTP/1.1 200 OK 1312ms]
Mit der letzten Zeile allerdings wird die Seite wohl reloaded - und danach gab es keine Fehler mehr, solange die Konsole geöffnet war. Oink. Auch wenn ich die Seite manuell reloade - kein Fehler.

gestrige HMInfoTools, immer noch kein patch im fhemweb.js:
Keine Fehler mehr.

alte HMInfoTools, gepatchte fhemweb.js (Version fhemweb.js 23453 2021-01-01 18:10:12Z - bei mir ist die von Dir bezeichnete Zeile 1103 allerdings die 1094 (verwende Notepad++, da stimmen die Zeilennummern von Fehlermeldungen eigentlich immer)... FHEM meldet hier den Fehler:

Code Auswählen Erweitern

fhemweb.js line 1095: TypeError: FW_pollConn is undefined
wirkt auf mich logisch, wenn ein Objekt geschlossen wird, dessen Vorhandensein in der auskommentierten Zeile abgefragt wird ... ? ... oink?

btw: ich kopiere die .js bei geschlossenen Tabs nach FHEM und rufe danach hminfo über Lesezeichen auf. Dabei verhält sich der erste Aufruf immer noch wie der Stand vor der .js-Kopie, ich vermute Browsercache. Erst nach einem manuellen Reload bleibt das Verhalten reproduzierbar.
edit: Das hat frank auch schon genau so beschrieben in https://forum.fhem.de/index.php?action=post;quote=1071906;topic=112825.0;last_msg=1084127

Bleibe jetzt bei original fhemweb.js und neuerer HMInfoTools.js. und freu mich ...

[frank]

mit aktueller fhemweb.js kommst du vielleicht auf die selben zeilen. 

FW_version["fhemweb.js"] = "$Id: fhemweb.js 23811 2021-02-23 21:04:49Z rudolfkoenig $";

1094 in deiner version ist schon richtig.
die fehlermeldung zeigt aber, dass du beim patchen irgend etwas falsch gemacht hast.

ohne den fhemweb patch hatte ich halt hin und wieder diese endlose "connection lost" orgie.
das hängt eventuell auch vom wetter ab. 

Bleibe jetzt bei original fhemweb.js und neuerer HMInfoTools.js. und freu mich ...

dann wirst du die orgie sicherlich auch irgendwann noch mal sehen.
seltsam finde ich eigentlich, dass wir scheinbar die einzigen sind, die dieses phänomen zu gesicht bekommen.


ps: du hast ganz schön viele devices mit problemen, sehe ich gerade.

[Pfriemler]

mit aktueller fhemweb.js ...

updates mache ich eigentlich nur sehr gelegentlich und das letzte war gerade erst vor ein paar Tagen ... dachte ich ...

die fehlermeldung zeigt aber, dass du beim patchen irgend etwas falsch gemacht hast.

Wüsste nicht was. Ich sollte doch aus "if(FW_pollConn) FW_pollConn.close();" lediglich ein bedingungsloses "FW_pollConn.close();" machen, oder? Nur funktioniert das wenn das uninitialisiert ist o.ä.?

Ich warte geduldig auf die nächste "Orgie". Stand jetzt kommt einfach nix mehr.

ps: du hast ganz schön viele devices mit problemen, sehe ich gerade.

Schönes Testmaterial, nicht? Du solltest erst mal meinen peerCheck sehen  Dabei funktioniert alles, FHEM weiß es nur nicht...

Das meiste sind Geräte, die aktuell offline sind wegen Unbenutzung (Weihnachtskram, Mess-Zwischenstecker) oder noch zu erfolgendem Einbau (manches wurde auch gekauft, aber nun doch nicht gebraucht, aber noch nicht verkauft, anderes ist nur provisorisch angelernt/gepeert und die Register unerreichbar, weil ich autoReadReg noch default gelassen habe) etc. Die "Rundumleuchte" ist ein temporär benutzter HM-LC-Sw1-Ba-PCB mit 3V Betriebsspannung (das ist dem immer zu wenig, aber er wurde auf 3-V-Betrieb umgebaut (hinter Eingangsregler gespeist) und läuft deswegen super, ich muss nur noch die Batterieerkennung "hacken", damit Ubatt wieder Pegel bekommt), ein Dimmer aus der Reserve wurde zum Steuern einer LED-Leuchte kurz einbebaut und hatte Overload (habe kurzerhand den zweiten Reservedimmer eingebaut und war noch nicht dazu gekommen zu untersuchen, ob meine low-energy-hacks das verursacht haben könnten), was der "HM_UniDimPl_1_Dim" aber an sabotageAttack zu meckern hat ist mir gänzlich unerklärlich, hier gibt es weit und breit keinen anderen HM-User und ich habe auch schon ewig keine Versuche mit CCU etc gemacht geschweige denn dabei dieses Gerät verwendet ...
Die Chance, dass diese "Pseudofehlerliste" absehbar kürzer wird ist eher gering.

[frank]

Wüsste nicht was. Ich sollte doch aus "if(FW_pollConn) FW_pollConn.close();" lediglich ein bedingungsloses "FW_pollConn.close();" machen, oder?

genau.
da fällt mir erst einmal weiter nichts zu ein. eventuell noch ein sporadisches problem mit deiner deiner HMinfoTools version. ich behalte es mal im hinterkopf.

was der "HM_UniDimPl_1_Dim" aber an sabotageAttack zu meckern hat ist mir gänzlich unerklärlich

ich hatte letztens auch zu grübeln:
da hatte ich einen mit fhem gepairten sensor resettet, der aber weiterhin in fhem vorhanden war.
anschliessend habe ich diesen sensor mit einem dimmer direkt gepeert, den fhem nicht kannte.
die msgs vom dimmer an den sensor hat fhem natürlich bemerkt und als angriff angesehen. 
da gab es dann aber ein zusätzliches attack reading im sensor, dass die hmid des dimmers enthielt.

[frank]

zum jubiläum von 70 downloads mal ein update von hm.js im ersten post.

einige verbesserungen, optimierungen und fehlerbeseitigungen.
(auch gegenüber der vorläufigen version aus antwort #53)

[Pfriemler]

da fällt mir erst einmal weiter nichts zu ein. eventuell noch ein sporadisches problem mit deiner deiner HMinfoTools version. ich behalte es mal im hinterkopf.

Äh ... wir redeten doch gerade von einem Problem, verursacht durch eine Änderung von mir in fhemweb.js?

anschliessend habe ich diesen sensor mit einem dimmer direkt gepeert, den fhem nicht kannte.

Das ist ja nachzuvollziehen und logisch. Ha. Meine ellenlange peerCheck-Fehlerliste hängt ja unter anderem damit zusammen, dass die Informationen aus lange angelegten, aber länger nicht per getConfig aktualisierten Geräten mittelfristig wegzudiffundieren scheinen. Wenn da FHEM eine Info abhanden gekommen ist, sieht der peer natürlich wie ein Attack aus.
Ist hier aber nicht der Fall gewesen - die peers waren bekannt.

zum jubiläum von 70 downloads mal ein update von hm.js im ersten post.

Da stand bis eben noch 0 Downloads 

[frank]

Äh ... wir redeten doch gerade von einem Problem, verursacht durch eine Änderung von mir in fhemweb.js?

genau.
wenn du behauptest, alles richtig gemacht zu haben, muss die fehlermeldung ja eine andere ursache gehabt haben.

hm.js und hminfotools.js nutzen funktionen aus fhemweb.js, um longpoll für mehr devices zu ermöglichen, als normalerweise vorgesehen sind. denn auf jeder detailseite kommen über longpoll von haus aus nur die events, die zum device der detailseite gehören.

dazu muss die aktuelle default-longpoll verbindung, die fhem immer öffnet, zunächst geschlossen werden, um danach die erweiterte longpoll verbindung zu öffnen. firefox mit websocket reagiert hierbei sehr empfindlich, wenn versucht wird die 1. verbindung zu schliessen, wenn diese noch nicht vollständig etabliert war.
wenn dadurch auch noch der seitenaufbau verzögert wird, schlägt eventuell zusätzlich der connection-lost-mechanismus von fhem zu, der nun ebenfalls versucht die verbindung zu erneuern.
im ungünstigsten fall kommt es dann zu einer dead-loop.

langsamer seitenaufbau bei hminfo mit vielen entities, die fehler zeigen, kann schon mal ein connection lost zeigen. allerdings sollte es dann nicht zur dead-loop führen.
daher habe ich als notlösung in hminfotools ein seitenreload eingebaut, der nach 5 connection-lost ausgelöst wird.



attack:
es gibt einen kleinen, feinen unterschied zwischen hm.js und hminfotools.js.
hm.js zeigt attack, sobald das attack reading existiert, also auch uralte attacks.
ein klick aufs icon löscht das reading (set clear attack).

hminfo zeigt default "nur" attacks seit dem letzten fhem restart an (iCRI__protocol) wie bei allen protokoll fehlern.
da mich auch "alte" attacks interessieren, habe ich das attr sumERROR in hminfo erweitert:

Code Auswählen Erweitern

sabotageAttack_ErrIoAttack_cnt:ok


tip:
jeder sollte eigentlich auch attr sumERROR mit

Code Auswählen Erweitern

cfgState:ok
erweitern, um alle entities zu sehen, die durch den automatischen hminfo configCheck auffällig werden

[Pfriemler]

wenig neues von den "connection losts":

... firefox mit websocket reagiert hierbei sehr empfindlich, wenn versucht wird die 1. verbindung zu schliessen, wenn diese noch nicht vollständig etabliert war.
wenn dadurch auch noch der seitenaufbau verzögert wird, schlägt eventuell zusätzlich der connection-lost-mechanismus von fhem zu, der nun ebenfalls versucht die verbindung zu erneuern.
im ungünstigsten fall kommt es dann zu einer dead-loop.

Klingt plausibel und erklärt die meisten meiner Beobachtungen gut.
Es gibt noch einen recht zuverlässigen Mechanismus zum Auslösen von connection losts: Geräte versuchen zu bedienen bevor die Seite vollständig geladen wurde. Dead loops hatte ich nur noch ganz wenige, ein einfacher Seitenreload hat sie sämtlich behoben. Diese Dauerhänger sind jedenfalls komplett weg.
Insgesamt ist es für mich so viel besser brauchbar. Ich bin entzückt!

[frank]

Dead loops hatte ich nur noch ganz wenige, ein einfacher Seitenreload hat sie sämtlich behoben. Diese Dauerhänger sind jedenfalls komplett weg.

das betrifft jetzt aber nur hminfotools, oder?

1. wenn ja: der automatische reload nach 5/6 lost kommt und funktioniert auch?

2. wenn nein:
bei hm.js kann ich bei mir keine fehler mehr in der webkonsole sehen. eine geänderte websocket verbindung wird auch nur bei einer "echten" channel entity initialisiert, um die zusätzlichen events des hauptdevices zu bekommen.
wenn connection lost erst später, nach einem erfolgreichen seitenaufbau auftaucht, ist die verbindung scheinbar wirklich kurz tot.

[Pfriemler]

Nein, die connection losts kamen - nur noch extrem selten - bei Detailseiten von HM-Geräten. Ich könnte mir aber gut vorstellen, dass sie so gut wie nichts mehr mit hm.js zu tun haben. Das wird dann wirklich der Ungeduld des FF zuzuschreiben sein.
Der Reload-Mechanismus war mir schon bei den Versuchen mit der Webkonsole aufgefallen - ich habe mich gewundert, was nach einem Rudel Fehlermeldungen denn plötzlich einen reload initiiert.
Und auch da war schon auffällig, dass (neben dem manuellen auch) dieser automatische Reload das Gezeter um die connection lost beeendete.

Wie ich schon sagte: Für mich ist es gerade optimal.

Was anderes: Hattest Du mal darüber nachgedacht, bei schwachen Batterien in HmInfoTools auch ein entsprechendes Symbol zu verwenden oder wird das zu kompliziert? in hm.js, sehe ich gerade, ist es ja schon...

[frank]

Wie ich schon sagte: Für mich ist es gerade optimal.

vielleicht noch etwas optimaler mit der angehängten HMinfoTools.js?
vielleicht ändert sich auch nichts, ist zumindestens mein aktueller stand.

Was anderes: Hattest Du mal darüber nachgedacht, bei schwachen Batterien in HmInfoTools auch ein entsprechendes Symbol zu verwenden oder wird das zu kompliziert? in hm.js, sehe ich gerade, ist es ja schon...

genau, hm.js kennt drei unterschiedliche icons mit unterschiedlichen farben.
das wurde aus performance gründen aber bisher nicht in hminfotools übernommen.
mit einem optimierten kombi-icon aber irgendwann einmal denkbar.

edit: HMinfoTools.js entfernt, da neues update existiert.

[frank]

moin,
neuer name und neue version.

die status icons werden nun über HMinfoTools.js in HMdeviceTools.js (neuer name von hm.js) integriert.
das erspart eine menge doppelten code und das verhalten der icons ist immer identisch.
also die neue version von HMdeviceTools.js von hier installieren: https://forum.fhem.de/index.php/topic,106959.0.html