[HMinfoTools.js] ein WebUI für das modul HMinfo

[frank]

die aktuelle version von HMinfoTools.js ist nun bei github zu finden.
durch einbundung des thirdparty-repository kann ein update nun über das "normale" fhem update bezogen werden.
siehe hinweise unter "Installation".


moin,
anbei ein webui für hminfo.

HMinfoTools.js erstellt eine übersichtliche tabelle aller devices und channels, die vom hminfo modul als "problematisch" ermittelt wurden. siehe hminfo internals (iCRI_..., iERR_..., iW_...).
die reihenfolge der ermittelten entities entspricht der unter hminfo internals.

entsprechend konfiguriert, kann die tabelle permanent den aktuellen zustand des homematic systems darstellen.
alle icons unterstützen longpoll, wodurch viele device infos "live" sind.




Installation
- zunächst ist natürlich ein hminfo device nötig:

Code: [Auswählen]

define hminfo HMinfo
- automatischen download über den fhem update mechanismus einrichten. ein paar beispiele für den fhem update cmd sind in diesem post zu finden: https://forum.fhem.de/index.php/topic,112825.msg1197938.html#msg1197938

Code: [Auswählen]

update add https://raw.githubusercontent.com/frank962/fhem/main/autoupdate/controls_HMtools.txt
- die installierte version von HMinfoTools.js kann über den fhem cmd "version" angezeigt werden

- beim FHEMWEB device das neue file HMinfoTools.js zusätzlich eintragen (leerzeichen getrennte liste):

Code: [Auswählen]

attr <myFHEMWEB> JavaScripts pgm2/HMinfoTools.jsHMinfoTools sollte nun nach dem aufrufen der detailseite des hminfo devices über den internals sichtbar sein.
hat hminfo noch keine fehlerhaften entities ermittelt, ist nur eine "leere" tabelle zu sehen, siehe sreenshot hminfotools01.png.

- hminfo ermittelt fehlerhafte entities durch den cmd:

Code: [Auswählen]

set hminfo update- über ein attribut lässt sich dieser vorgang auch automatisieren, zb alle 10 min:

Code: [Auswählen]

attr hminfo autoupdate 00:10nach fhem restart bis zum ersten hminfo update dauert es dann auch 10 min bis zum ersten hminfo update.
ein beispiel mit einer "vollen" tabelle zeigt screenshot hminfotools02.png.


Konfiguration
- attr longpoll=websocket für das verwendete FHEMWEB device ist sicherlich zu empfehlen, da es je nach anzahl der devices zu erheblichem datenaustausch kommen kann.

- zur reduzierung des traffics zwischen server und browser sollte, wie überall grundsätzlich empfohlen, bei allen devices das "attr event-on-change-reading .*" für alle readings genutzt werden.

- zusätzlich ist es möglich HMinfoTools auf raumseiten anzuzeigen, zb mit einem weblink device:

Code: [Auswählen]

defmod my_weblink weblink htmlCode <table><tbody><tr><td id="hminfotools_weblink" dev="hminfo"></td></tr></tbody></table>
der name des weblink devices (my_weblink) ist beliebig, die id des td-elementes ist zwingend einzuhalten, das attribut dev="hminfo" des td-elementes muss den namen des hminfo devices bekommen.

- alle icons unterstützen longpoll. zu beachten ist:
1. rssi-icon
wenn in einem device "attr rssiLog 1" gesetzt ist, ändert sich das icon entsprechend den dadurch erzeugten rssi events, die vom aktuell genutzten IODev gemessen wurden (reading: rssi_at_"IODev").
bei jedem reload der tabelle entspricht der farbcode des icons zunächst grundsätzlich dem statistischen rssi-min-wert des aktuellen IODev.
bei einem rssi-min-wert hat der antennenmast die selbe farbe wie der rest. und bei aktuellen rss-werten ist er immer weiss.
2. desired-io-icon

Code: [Auswählen]

// color attr IOgrp set                              attr IODev set                           none
// ---------------------------------------------------------------------------------------------------------------------------
// white no prefered set                                                         
// green                        1. prefered                                 reading = attr
// yellow 2. prefered
// orange no prefered
// red no prefered (opt none), missing_IODev       reading != attr, missing_IODev           only red
bei diesem icon müssen zunächst einige vorbereitungen vorgenommen werden, damit das reading IODev entsprechende events erzeugt. siehe diesen post https://forum.fhem.de/index.php/topic,112825.msg1184583.html#msg1184583

- wichtige ergänzungen für das hminfo attribut sumERROR
einige fehlermeldungen, die hminfo ermittelt, werden durch readings, die bestimmte werte enthalten, verursacht. diese reading/value kombinationen sind im attr sumERROR hinterlegt und können beliebig erweitert/geändert werden. die einträge werden durch komma getrennt.
folgende erweiterungen finde ich empfehlenswert:

Code: [Auswählen]

1. "cfgState:ok"                                                         => alle entities
2. "sabotageAttack_ErrIoAttack_cnt:ok"                                   => alle devices
3. "R_tempList_State:verified"                                           => HM-CC-TC, HM-CC-RT
4. "R_P1_tempList_State:verified"                                        => HM-TC-IT
5. "R_P2_tempList_State:verified"                                        => HM-TC-IT
6. "R_P3_tempList_State:verified"                                        => HM-TC-IT
7. "valveCtrl:restart:unknown:ok:miss_1:miss_2:miss_3:miss_4:miss_5"     => virtueller HM-CC-TC
8. "smokeChamber:ok"                                                     => HM-SEC-SD-2
9. "alarmTest:ok"                                                        => HM-SEC-SD-2
4./5./6./8./9. sind ungetestet, da mir die devices fehlen


Weitere Infos:
- HMdeviceTools.js thread: https://forum.fhem.de/index.php/topic,106959.0.html.
- funktionen über die genutzten icons sind hier zu finden: https://forum.fhem.de/index.php/topic,112156.0.html.
- verwendung auch ohne HMdeviceTools.js möglich.

[frank]

@matinp876

hallo martin,

für eine automatische aktualisierung der device tabelle könnte ich einen neuen trigger gebrauchen.
dieser sollte signalisieren, dass sich entweder die liste der entities geändert hat, und/oder die fehlerkategorien einer entitie.

am schönsten wäre eine liste mit den entities inklusive deren aktuellen fehlerkategorien.
zb, wenn es 3 devices mit fehlern gibt, die zum teil in mehreren fehlerkategorien auftauchen:

errorDevices => "device1:cat1,cat2,cat4 device2:cat2,cat4 device3:cat1"

[martinp876]

Mal auf die Schnelle laut denken:
Einen trigger erhältst du, wenn sich die Anzahl der Einträge einer Kategorie andert.

Die Liste der entities ist in internals da man hier einen link zur entity erhält.

Info level wird nicht detailiert.
Configcheck könnte man als warning addieren.
Im übrigen sind die Kriterien vom user einstellbar. Allerdings nicht der level (Err Warning).

Unzureichend könnte nun sein, das in internals der inhalt des readings nicht angezeigt wird. Das ist nur in den readings zu sehen.... Sollte ich verbessern.

Die entities erhältst du aus den internals eigentlich recht einfach.
Eine Auflistung nach devices könnte ich als get implementieren.
Als trigger wäre dann ein reading lastChange <date> möglich

Deine angeforderte devicelists will ich nicht, da es eine endlose zeile ergibt, welch immer schlecht/nicht lesbar ist. Genau das wollte ich verhindern.

[frank]

ich denke, ich muss noch mal präzisieren, damit wir das selbe meinen. vor allem die begriffe: entity, device und channel.

1. ich erzeuge die tabelle aus den in den internals (CRI, ERR, W) vorhandenen namen. da hier sowohl namen von parent-devices (DEF=6-stellig) auftauchen, als auch namen von channel-devices (DEF=8stellig), spreche ich ab jetzt von der "entity-tabelle" oder liste.
ich hatte von device-tabelle gesprochen, da es alles fhem devices sind.

2. der trigger soll ein aktualisierung dieser entity-tabelle auslösen, wenn es eine änderung der entities gibt.

3. ich habe nun gesehen, dass sich in der detail ansicht von hminfo teilweise sogar die internals ändern, wenn gleichzeitig ein reading updatet. eventuell wenn readingname und internalname identisch sind.
das kannte ich noch nicht.

ausserdem ändern sich readings scheinbar auch zwischen den hminfo-updates. bisher dachte ich, das passiert nur bei einem hminfo-update.

sehr verwirrend.
ich muss jetzt erst mal untersuchen, ob die automatischen internals änderungen zu diesem zeitpunkt auch wirklich im internal existieren. also auch in einem list oder jsonlist2 vorhanden sind.

4.

Eine Auflistung nach devices könnte ich als get implementieren.

wenn schon, dann bräuchte ich ein get für eine entity-liste. siehe oben.

das ist aber nicht nötig.
wenn es das lastChange reading "nur" mit timestamp gibt, ist das vollkommen ok.
da ich dann aber sowieso einen request machen muss, hole ich mir lieber gleich ein jsonlist2 von hminfo und bekomme damit alle internals, readings und attribute auf einmal.

der vorteil, wenn die "benötigten" daten bereits über longpoll automatisch kommen, wäre halt, einen request einzusparen.

für die longpoll unterstützung der icons werden alle events für jede entity der liste gepollt, plus events des zugehörigen parent devices für channel entities, plus hminfo events.

5. eine neue config fehler-kategorie wäre wirklich gut.

[Pfriemler]

Ich werde mich mal wieder gleich ins Testgetümmel stürzen.

Liebe Leuts, lieber Martin insbesondere,

ich fände, dass diese beiden Erweiterungen (mindestens aber hm.js) sich ein Pinning im Homematic-Forum verdient haben!

[martinp876]

hier einmal zum Testen.

hm.js sollte in contribute abgelegt werden - besser zu finden.

[Pfriemler]

HMinfoTools.js nach www/pgm2 (wo auch hm.js liegt), Attribut JavaScript in der FHEMWEB-Instanz wie für hm.js ergänzt, Martins 98_HMinfo.pm aus dem Beitrag nach FHEM und reload - in hminfo tut sich nichts.
Auch nicht nach einem Neustart. Habe ich was übersehen? hm.js funtkioniert nach wie vor.
edit: geht auch nicht mit der alten 98_HMinfo.pm. Nur dafür wesentlich weniger Fehlermeldungen im Log.
Ich hatte übrigens keine Probleme mit der 98_HMinfo.pm #22387 nach Neustarts.

[frank]

HMinfoTools.js nach www/pgm2 (wo auch hm.js liegt), Attribut JavScript in der FHEMWEB-Instanz wie für hm.js ergänzt

genau richtig.
mit einem neuen js-file muss man immer auch die browserseiten refreshen ("Strg + R" bei firefox), damit die aktuelle seite sich die js-files neu einliesst.
bei chrome im handy lösche ich sogar zuerst alle fhem-tabs.


HMinfoTools.js aus dem start post funktioniert nur mit der "normalen" 98_hminfo.pm.

für die von martin hier angehängte hminfo.pm muss ich erst anpassung vornehmen.
ein erster versuch ist diesem post angehängt.
diese version funktioniert dann nur mit der von martin angehängten hminfo.pm.


ohne attr autoUpdate musst du eventuell erst "set hminfo update" ausführen, damit in hminfo etwas passiert.

oder bei dir gibt es keine fehler in den devices. 

[Pfriemler]

Ich hasse das! Siehe letzter Satz meiner Sig. 
Ich hatte auch schon vorher einige ERR_ in hminfo. Komisch. Wie auch immer. Natürlich geht jetzt alles.

[frank]

hier einmal zum Testen.

sieht gut aus.

- readings werden wohl nur noch bei hminfo_update updated.
- internals bleiben mit angepasstem namen ruhig.
- lastErrChange sieht auch gut aus.
- keine warnings im log.


kleinigkeiten:

1. zu viele events bei speziellen readings

ich habe bei mir jetzt alle event attribute gelöscht.
es macht dann den eindruck, dass es grundsätzlich in hminfo nur events bei change geben soll. richtig?

allerdings feuern diese readings bei jedem update, auch ohne change, immer dann, wenn der value=0 ist.
sobald ein "echter" value existiert, feuern sie nur bei change. :
- CRI__protocol
- W__protocol
- ERR_valveCtrl (eigenes reading über attr sumERROR)

komischer weise passiert dies nicht bei I_autoReadPend=0


2. kein einheitlicher internals name bei W__protocol

ERR__protocol wird zu iERR__protocol => logisch
W__protocol wird aber zu iW__protoNames => besser wäre hier iW__protocol


3. falsche kategorie und ebenfalls kein einheitlicher internals name für ERR__unreachable

ERR__unreachable wird zu iW__unreachNames => besser wäre hier iERR__unreachable.



fragen:

welche logik verbirgt sich eigentlich hinter der anzahl der "underscore" zeichen bei den fehler kategorien?
zb hat protocol immer 2 underscore, egal ob W, ERR oder CRI. macht ja sinn.
alle fehlerreadings aus dem attribut sumERROR bekommen wohl nur einen underscore.

warum hat nun iERR___rssiCrit 3 underscore?
es wird ja wohl aus einem I_ reading abgeleitet.

die eigentliche frage ist aber, ob du mit der anzahl der underscore quasi einen zusätzlichen level innerhalb einer kategorie charakterisieren möchtest?

wenn ja, habe ich den eindruck, dass eventuell 1 underscore der höchste level sein soll und 3 underscore der niedrigste.
wenn das auch stimmt, wäre es aber besser level 1 und level 3 quasi zu tauschen, damit sie in der reihenfolge der wichtigkeit nach in den internals dargestellt/sortiert sind. somit dann auch in HMinfoTools.

also die wichtigsten fehler mit den meisten underscore zeichen markieren.


edit:

noch ein kleiner wunsch zum schluss. 

wäre es möglich, in parent devices ein neues internal ein zu fügen, in dem die modes des devices enthalten sind?
ich weiss, dass ich es auch unter get deviceInfo finden kann.
wenn es aber in einem internal stehen würde, könnte ich dutzende requests einsparen, da das internal dann automatisch in einem jsonlist2 mitkommen würde, das ich eh schon anfrage.

ich möchte ein CMDs_pending in commState für zb config devices spezieller darstellen, weil hier ja ein manueller eingriff zwingend erforderlich ist (knöpfchen drücken).

[frank]

neues update im ersten post.

Code: [Auswählen]

rev 1001 14.07.2020
    new: error-entity-tabelle mit autoupdate
    new: deutliche traffic reduzierung

cmds_pending blinkt jetzt. 
was sagt safari dazu?

[Pfriemler]

Also ich bekomme beim Aufruf von hminfo nach einem Neustart (edit) die HMInfoTools erst angezeigt, wenn ich "set hminfo update" schicke und dann die Seite im Browser reloade. Beides sollte unnötig sein. ? Jetzt im laufenden Betrieb geht es dann. Ich werde das mal weiter untersuchen.

[frank]

Also ich bekomme beim Aufruf von hminfo nach einem Neustart (edit) die HMInfoTools erst angezeigt, wenn ich "set hminfo update" schicke und dann die Seite im Browser reloade.

HMInfoTools sammelt fehler aus den internals von hminfo ein und zeigt diese dann an.
diese sind nach restart aber noch nicht vorhanden, sondern erst nach hminfo update, entweder manuell oder automatisch nach etwa der zeit, die in attr autoupdate eingestellt ist. also ggf warten.

das erste automatische hminfo update nach fhem restart könnte martin sicherlich vorziehen, je nach einstellung von attr autoUpdate.

zumindestens startet HMInfoTools ab jetzt automatisch, wenn das erste update mit fehlern kommt.
ein früheres hminfo update, sollte martin initiieren.


@all
neues update im ersten post.

[frank]

hallo martin,

1. sabotageAttack fehler "verschwinden" nach fhem restart. readings im device bleiben bestehen.
erst neue attacks erzeugen wieder einen "CRI_protocol" fehler.

2. frage zu "set device clear msgEvents"

ist es richtig, dass der befehl auch die protocol fehler löscht?
da es ja mittlerweile auch "set clear msgError" gibt, hätte ich vermutet, dass die fehler nicht auch über clear msgEvents gelöscht werden.

"set device clear msgEvents" kann durch klick auf die led's ausgelöst werden.
leider verschwinden dann die entities aus der liste.

3. "set hminfo cmdRequestG ping" pingt auch ignored devices an, die dann in der fehlerliste erscheinen.
das sollte nicht sein, denke ich.

[Knallkopp_02]

Hallo liebe Programmierer,

Ich bin noch im Anfangsstatium, was händische Einfügen von irgendwelchen Scripten angeht, und möchte nocheinmal nachfragen, ob ich alles richtig verstanden habe, was ich machen muss, damit alles läuft.

Ein HMInfo Device habe ich schon definiert und das läuft auch.
Jetzt lade ich mir HMinfoTools.js  herunter und packe es in den Ordner www/pgm2 und gehe dann die Schritte 0.1 - 0.4 der Anleitung zum hm.js durch mit den entsprechenden Anpassungen.
Wiedersprüchlich ist die Aussage, das ich die hm.js brauche oder nicht?

Soweit habe ich das nun alles gemacht, bekomme aber auf der Detailseite nicht mehr angezeigt als vorher.

Gruß Knallkopp_02