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

[frank]

fehlendes commState sollte jetzt geschichte sein. 

[Pfriemler]

fehlendes commState sollte jetzt geschichte sein. 

ACK. "Info_unknown" kommt stattdessen.

Dafür habe ich wieder einen neuen:
"hm.js line 45: TypeError: iconCell is null" bzw. "hm.js line 45: Uncaught TypeError: Cannot set property 'innerHTML' of null"
wenn ich nicht in der Device-Ansicht, sondern in einem Raum ein Gerät über webCmd oder devStateIcon schalte.
War auch in der Vorversion schon so, wollte es gerade posten, aber habe noch schnell die neue Version gecheckt.

edit: Nä, warte mal, nicht bei allen Schaltern ... ?
edit: Kann es noch nicht korrelieren. Auf einigen Geräten kommt es, auf anderen nicht.
Keine Abhängigkeit von Schalter/Dimmer, Ein/Mehrkanal, devStateIcon, icon, ... die Unterkanäle eines HM-MOD-RE-8 schalten ohne Fehler ebenso wie HM-LC-Sw1-PCB oder HM-LC-Sw4-DR.
Fehler kommt auch bei nicht-Schalt-Aktionen, wie etwa statusRequest.

[frank]

"hm.js line 45: TypeError: iconCell is null"

die 17:00 uhr version sollte das fixen.

[Pfriemler]

die 17:00 uhr version sollte das fixen.

Aber sowas von.
Schöne Sache jetzt. Großes Lob! Ich (darein schauend wie das Schwein ins Uhrwerk) werde es genießen!
Mittelfristig noch ein passendes SVG - aber das ist ja schnell angepasst.

[frank]

wegen dem fhemweb.js fehler hat rudi heute ein änderung für fhemweb.js eingecheckt.
was sagt deine konsole dazu (menü>extras>web-entwickler>web-konsole)?

meine erfahrungen zum thema: https://forum.fhem.de/index.php/topic,112181.msg1066302.html#msg1066302

[martinp876]

coole sache. Habe mir erwas ähnliches gebaut - für Tablet-UI. Noch bin ich nur semi-zufrieden mit meiner Lösung.
Was ich will ist eine Info über Device-Status/Device-Probleme. Für mich ist Protocol-only zu kurz gesprungen. Allerdings ist die Anwendung mit der Anzeige cool.

Zuerst einmal: Was will ich sehen
- Abstrakt: Status/Alarme/Warnings eines Device welche mir mitteilen: Mit dem Device stimmt etwas nicht - Admin, Hilfe bitte.
- Welche Zustande zählen dazu. In HMInfo gibt es einen Ansatz, die Meldungen zu sammeln. Das sind nur die Alarme - bei der normalen Anzeige braucht es einen Status, also mehr "info"
  - Gruppe "Protokoll" - wird im Reading "commState" abgebildet. Es ist seit kurzen ein Reading, so dass man Events nutzen kann
  - Batterie - gehört in die Kategorie warning
  - alive (actStatus) - kategorie "error"
  - Weitere Readings (siehe HMInfo) sabotageError:off, powerError:ok, overload:off, overheat:off, reduced:off,motorErr:ok, error:none, uncertain:yes, smoke_detect:none, cover:closed

Das ganze in einem Status abzubilden Bedarf einer Priorisierung:
+ So ist Alive sicher Prio 1. Wenn "Dead" ist alles andere egal
+ alle anderen Readings benötigen eine funktionierende Kommunikation. Hierzu zählt: Ist das(oder zumindest ein mögliches) IO funktional? In HMInfo gibt es nun ein "ping" in set "hm commandRequestG ping" mit welchem man prüfen kann, dass das/die Devices ansprechbar sind. Wie immer defensiv - bei RTs wird gewartet bis sie aufwachen
+ So, das Device lebt und wir können kommunizieren - jetzt wird es komplexer
++ es "gab" protokol fehler. Ein Teil der kommandos könnte fehlgeschlagen sein. Bei Registern ist dies manuel zu prüfen (bei Templates kann man es über HMInfo). Zu unterschieden: nur nicht-korrigierte Fehler sind relevant
++ protokol: Pending. In etwa gleicher level - wir müssen noch auf die Übertragung warten
++ Device fehler wie Overload, Power-Error, Motor-Error: Das Device wird nicht das machen was es soll, es hat ein internes Problem
++ Battery: low warning level. Man muss "nur" in absehbarer Zeit die Batterien wechseln.
++ Info: Motor fährt (rollo/Dimmer)
++ green: keine Fehler, kommunikation möglich, alles übertragen

das alles muss abgebildet sein um den "gesundheitszustand" einer Device darzustellen. Wenn grün kann ich sicher sein, dass der Kanal das macht, was ich will.

Zusatz:Config-check ist nicht inkludiert. Ebenso sollte man das Ablöschen der alten Kommunikatiosfehlern betrachten.

=> dann bin ich zufrieden mit der Darstellung

[frank]

Für mich ist Protocol-only zu kurz gesprungen. Allerdings ist die Anwendung mit der Anzeige cool.

das ist auch nur ein erster kleiner appatizer. 

aber unterschätze nicht den informationsgehalt dieser unscheinbaren, kleinen led. es liegt jetzt natürlich auch an dir, ihr noch mehr leben ein zu hauchen.

- wie letztens schon kurz angesprochen, fehlen auf alle fälle noch events für die queues der automatischen getconfigs und statusrequests und was sonst noch in den tiefen von cul_hm schlummert.
falls noch aktionen geplant sind, sollten diese hier auftauchen, finde ich.

- bei CMDs_pending fände ich äusserst hilfreich, wenn es 2 unterschiedliche pendigs gäbe. eins für devices, die unbedingt ein manuelles eingreifen benötigen (config, lazy) und ein 2. pending, das ohne eingriff automatisch abgearbeitet wird.

- eventuell fehlt für fwupdate auch noch ein fehlerevent für commstate. es gibt zwar das reading fwupdate mit fehlerangabe, aber im state stand dann bisher nur FWupdate_done, was nach erfolg aussieht.


in der pipeline ist gerade eine anzeige für configcheck.

ausblick, träume:
letztendlich wäre mein plan in etwa:
vielleicht eine handvoll icons für die zustandsbeschreibung auf deviceebene hier in hm.js
dann zusätzlich eine art widget für hminfo, das einerseits systeminfos darstellt (zb io zustände) und andererseits eine liste der problematischen devices zeigt. jede zeile wäre dann ählich der zustandsanzeige wie im device.

im idealfall ist die deviceliste leer und der rest leuchtet grün.

edit: ein weiteren commstate wunsch ergànzt.

[Pfriemler]

wegen dem fhemweb.js fehler hat rudi heute ein änderung für fhemweb.js eingecheckt.
was sagt deine konsole dazu (menü>extras>web-entwickler>web-konsole)?

Wurde heute beim Update mit eingespielt.

edit: Tatsächlich:
bei manchen Geräten keine Probleme, bei manchen die "connection lost" wie Du beschreibst.
D...d!

Code Auswählen Erweitern

13:28:55.679 Inform-channel opened (websocket) with filter LED_Gong,LED_Gong_Led fhemweb.js:507:13
Firefox kann keine Verbindung zu dem Server unter ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=LED_Gong,LED_Gong_Led;since=1592911724;fmt=JSON&fw_id=2383&timestamp=1592911735677 aufbauen. fhemweb.js:1214:18
13:28:55.686 Inform-channel opened (websocket) with filter LED_Gong,LED_Gong_Led fhemweb.js:507:13
Die Verbindung zu ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=LED_Gong,LED_Gong_Led;since=1592911724;fmt=JSON&fw_id=2383&timestamp=1592911735677 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1214:18
13:28:55.689 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<

edit2: bisher korreliert: Devices werden fehlerfrei dargestellt, Unterkanäle werfen den connection-Fehler.

[frank]

die toolbar bietet neues spielzeug. 

aktuelle testversion im 1. post.

- automatischer configcheck und templateCheck bei  seitenerstellung und refresh.
zur zeit nur manuell.
- die checks sind device spezifisch.

hminfo configCheck zeigt device fehler und template fehler in einem bericht. das icon ist nur für die device fehler zuständig. template fehler werden separat an den registerset links dargestellt.

- icon für configCheck (grün: ok, rot: fehler, weiss: kein configCheck ermittelt)
- wenn die maus auf dem icon ist, wird der configCheck bericht sichtbar.

- die links für die registersetbearbeitung sind nun farbig, wenn templates assigned sind.
- gelb: kein templateCheck erfolgt, grün templateCheck ok, rot: templateCheck zeigt fehler

[martinp876]

Nun werde ich vorsichtig.
Configcheck( welcher template check beinhaltet) kostet schon Performance.bei jedem öffnen einer seite ist mir das zu viel.
Wenn, dann müsste man es intelligenter machen. Das Ergebnis von configcheck abspeichern und nur abrufen. Configcheck automatisch starten, wenn die configuration geändert wird. Da dies bei einem getconfig einer mehrkanaldevice aber zu häufig stattfindet und zu oft getriggert wird sollte es im (doppelten) batch stattfinden. Zu beachten ist, dass auch die peers neu geprüft werden müssen.
Es muss also ein eigener Ablauf erstellt werden.
Beachte: in 95% der Anwendungen eines user wird sich die configuration nicht geändert haben. Fhem mit perl auf pi hat definitiv eine endliche Performance!

Die anzeige der queues ist schön, aber sekundär.

P.s.: attr readingsondead sollte commState beinhalten. Das ist schon einmal ein erster Schritt

[Pfriemler]

Configcheck( welcher template check beinhaltet) kostet schon Performance.bei jedem öffnen einer seite ist mir das zu viel.

Ich habe da weniger ein Problem. hm.js wird ja nur ausgeführt, wenn es in der zuständigen FHEMWEB-Instanz installiert ist. Für meinen ADMIN-Zugang habe ich sowohl das als auch codemirror.js eingebunden, in den Bedienoberflächen ist beides obsolet.
Oder sehe ich da was falsch?

@frank: Läuft hier anscheinend ohne Probleme. Muss jetzt allerdings longpoll=1 setzen, sonst ist der configCheck nicht erfolgreich.
Ist auch sonst jetzt eine lästige Sache. Rudis oder Deine Baustelle?

[frank]

automatischer configcheck:
ich denke, ich werde es so entschärfen, das nur beim "ersten" seitenaufruf automatisch gecheckt wird. weitere checks kann man dann manuell durch klick auf das icon starten.

wenigstens einen automatischen check finde ich schon wichtig, da man ansonnsten eher selten einen check durchführt.

einerseits sehe ich das thema auch eher entspannter wie pfriemler. es passiert ja nur auf der detailseite und der befehl wird zudem nonblocking ausgefürt.
andererseits erzeugt fhem aber auch viele refreshs, wenn man attribute bearbeitet und/oder cmds aus den selectlisten startet. da sind dann die configchecks schon überflüssig.

mal schauen woran man erkennt, dass es sich um den "ersten" seitenaufbau handelt.


firefox-websocket-problem:
das wird noch spannend.
zur zeit entweder firefox/lonpoll=1 oder websocket/chrome.

[Pfriemler]

@frank: Läuft hier anscheinend ohne Probleme. ...

Nein, ganz und gar nicht. Die eigentliche Funktion der Register- und Templatebearbeitung ist jetzt kaputt, das Fenster bleibt leer.
Wieder mal nur bei mir?

edit: Rückspielen der Version vom 21.6. -> Register funzen wieder.

[frank]

Nein, ganz und gar nicht. Die eigentliche Funktion der Register- und Templatebearbeitung ist jetzt kaputt, das Fenster bleibt leer.

ja ja..., wenn man auf dem weg zum einchecken denkt, dass man schnell nur noch ein paar "kosmetische" korrekturen erledigen kann. denkste. 

update im beitrag.


ist das longpoll=websocket eigentlich irgendwo voraussetzung?
seit anbeginn war bei mir longpoll=1 eingestellt und hat immer funktioniert.
noch erkenne ich eher nachteile als vorteile. 

aber sicherlich wird irgendwann auch firefox/websocket funktionieren.

[Pfriemler]

Der Teufel steckt immer im Detail
Sieht jetzt besser aus.

websocket scheint mir eine moderne und letztlich eher resourcenschonendere und schnellere Ablösung für das alte longpoll zu sein. Mit longpoll=websocket und Firefox hatte ich bis vor einigen Tagen nirgends Probleme.