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

- bis auf das rssi-icon unterstützen alle icons longpoll.
  das rssi-icon wird bei jeder HMinfoTools aktualisierung neu berechnet.

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


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 1000 12.07.2020
* new: prototyp
* rev 1001 14.07.2020
* new: error-entity-tabelle mit autoupdate
* new: deutliche traffic reduzierung
* rev 1002 15.07.2020
* fix: startet wieder automatisch nach fhem restart
* rev 1003 19.07.2020
* new: zusätzliche anzeige von HMinfoTools auf raumseiten möglich
* rev 1004 24.07.2020
* new: HMinfoTools bietet nun bis zu 7 status-icons für jede entity
* rev 1005 27.07.2020
* new: massnahmen gegen laufzeitfehler integriert
* new: HMinfoTools hat eine kopfzeile bekommen
* rev 1006 05.08.2020
* new: csrfToken änderungen werden unterstützt
* new: io-namen in der kopfzeile sind entsprechend dem status eingefärbt und haben einen link
* new: die anwendung als weblink ist nun auf beliebigen raumseiten möglich
* fix: "connection lost"-probleme mit firefox/websocket verbessert
* rev 1007 06.08.2020
* new: neue icons für motorErr und smoke_detect
* new: sabotageAttack icon mit animation
* rev 1008 06.08.2020
* new: click funktion für icon battery: dialog zum anhängen eines textes an das attribut comment bei batterie-wechsel
* new: click funktion für icon cfgState: "set <parentDevice> getConfig"
* rev 1009 03.09.2020
* fix: fehlerbeseitigung für devices mit nicht gesetztem attr IODev
* rev 1010 25.03.2021
* new: 4 globale icon-click-funktionen
* new: request reduzierung
* fix: "connection lost" verbesserung
* rev 1011 03.11.2021
* new: icon für desired-io
* rev 1012 08.11.2021
* new: longpoll für rssi-icon
* new: ein io-wechsel über longpoll ändert nun das rssi-icon entsprechend
* 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