FHEM - Hausautomations-Systeme > Homematic

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

<< < (2/25) > >>

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:

--- Zitat ---HMinfoTools.js nach www/pgm2 (wo auch hm.js liegt), Attribut JavScript in der FHEMWEB-Instanz wie für hm.js ergänzt
--- Ende Zitat ---
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.  8)

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:

--- Zitat von: martinp876 am 12 Juli 2020, 20:35:46 ---hier einmal zum Testen.
--- Ende Zitat ---

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln