FHEM - Hausautomations-Systeme > Homematic

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

(1/17) > >>

frank:
moin,
anbei ein webui für hminfo.


Anleitung:
- HMinfoTools ist auf der detailseite des hminfo devices über den internals sichtbar.
  hat hminfo noch keine fehlerhaften entities erkannt, zb nach fhem restart bis zum ersten hminfo update,
  ist nur eine "leere" tabelle zu sehen. siehe sreenshot hminfotools01.png.
  ein beispiel mit einer "vollen" tabelle zeigt screenshot hminfotools02.png.

- 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.


- es werden alle devices gelistet, bei denen hminfo fehler erkannt hat.
  siehe hminfo internals (iCRI_..., iERR_..., iW_...).
- die reihenfolge entspricht der unter hminfo internals.

- HMinfoTools aktualisiert sich automatisch bei erkannten fehleränderungen.
  dazu werden die events des hminfo readings "lastErrChange" genutzt.
  damit hminfo automatische updates initiiert, muss das attribut autoUpdate gesetzt werden.
  "attr hminfo autoUpdate 00:10" updatet zb alle 10 minuten.
  alternativ kann jederzeit ein manuelles update ausgeführt werden: "set hminfo update".

- 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

- attr longpoll=websocket für das verwendete fhem webdevice 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.

- 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:
- hinweise zur installation eines js-files sind bei HMdeviceTools.js zu finden: 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.



die aktuelle version ist hier im anhang zu finden.

History:

* rev 2000 21.11.2021
* new: HMinfoTools.js erzeugt nun auch die icons für HMdeviceTools.js (neuer name für hm.js)
* new: mit einem hminfo userattr "HMinfoTools_deviceMode=all" können jetzt alle devices angezeigt werden.
* rev 2001 22.11.2021
* fix: fehlender Templatecheck für HMdeviceTools integriert
* rev 2002 23.11.2021
* fix: problem bei desired-io-check, wenn IOgrp ohne prefered IO
* rev 2003 24.11.2021
* new: rssi overview bei klick auf das zahnrad oben rechts
* new: checkbox zum toggeln der auswahl der anzuzeigenden devices: all devices / error devices
* rev 2004 28.11.2021
* new: rssi overview optimiert und erweitert
* new: rssi auswertung: IODev ranking und empfehlung/möglichkeit zum setzen von attr IOgrp
* rev 2005 02.12.2021
* fix: verbesserungen zur vermeidung von fhem-style-problemen

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