FHEM - Hausautomations-Systeme > Homematic

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

(1/26) > >>

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: ---define hminfo HMinfo
--- Ende Code ---

- 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: ---update add https://raw.githubusercontent.com/frank962/fhem/main/autoupdate/controls_HMtools.txt
--- Ende Code ---

- 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: ---attr <myFHEMWEB> JavaScripts pgm2/HMinfoTools.js
--- Ende Code ---
HMinfoTools 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: ---set hminfo update
--- Ende Code ---
- über ein attribut lässt sich dieser vorgang auch automatisieren, zb alle 10 min:

--- Code: ---attr hminfo autoupdate 00:10
--- Ende Code ---
nach 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: ---defmod my_weblink weblink htmlCode <table><tbody><tr><td id="hminfotools_weblink" dev="hminfo"></td></tr></tbody></table>
--- Ende Code ---

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: --- // 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

--- Ende Code ---
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: ---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

--- Ende Code ---
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.
--- Zitat ---Eine Auflistung nach devices könnte ich als get implementieren.
--- Ende Zitat ---
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!

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln