[hm.js] testversion: icons für commState, cfgState, rssi, battery, sabotage, ...

[frank]

neues update.

jetzt immer im ersten post.

- longpoll über websocket sollte jetzt auch mit firefox funktionieren.
- da configcheck fehlermeldungen im log erzeugt und der automatismus noch nicht wunschgemäss funktioniert, ab jetzt erst einmal über manuelle auslösung mit einem klick auf das icon.

[Pfriemler]

im Testbetrieb. Keine Fehler bisher bei websocket.

Mir war heute aufgefallen, dass bei Devices mit autoReadReg = 0 der Configcheck natürlich rot wurde, bis man ein manuelles getConfig ausgelöst hatte. Danach blieb es aber immer noch rot bis zum Reload der Seite (grün). Die manuelle Variante jetzt finde ich auch völlig ok.

Aktuell kämpfe ich damit, dass FHEM hartnäckig der Meinung ist, es gäbe noch anhängige Registeränderungen:

Code Auswählen Erweitern

get hm configCheck -f ^HM_376BB2$ : configCheck done:

Register changes pending
    HM_376BB2
Allerdings wüsste ich nicht was noch anhängig sein sollte. Wie werde ich die los? clear msgEvents auf Gerät und VCCU bringen nichts.
Das ist aber kein Problem mit hm.js.

[frank]

neues update im 1. post

- es werden keine eigenen icons mehr benötigt.
  dazu habe ich das default icon rc_dot angepasst.
- battery status
- rssi anzeige


@pfriemler
schön das firefox jetzt auch bei dir funktioniert.

[martinp876]

Also mit automatischem Config-Check habe ich immer noch ein Problem.
Ich sehe hier eine andere Lösung welche in CUL_HM installiert ist. Hier kann man den Check einbauen, wenn er "notwendig" ist.
Schliesslich muss man ihn nur machen, wenn Register gelesen/gesetzt/geändert wurden - oder templates verändert wurden.
Das geht eh in Franks Richtung, die anstehenden Überprüfungen darzustellen.
Am Ende muss ein "ConfigState" je Entity herauskommen. Die zum Device gehörenden Meldungen kann man dann per Get abholen.

Config-Check dauert, ist nicht Performance-optimiert (muss auch nicht)

[frank]

weiteres update eingecheckt.

- neues icon für den action status hinzugefügt
- deutlicher performancegewinn beim umfärben der icons.
  besonders deutlich bei der protokoll led zu bemerken.
- rssi anzeige umgestellt auf das IODev aus den internals.
  benötigt wird die aktuellste 98_JsonList2.pm von heute, sonst sieht man nur rot. 
- manueller configCheck verbessert:
  nach dem start des checks färbt sich das icon zunächt gelb, um ein feedback vom klick zu erhalten,
  falls es mit dem  ergebnis mal länger dauert.


@martin
ein flag/trigger für einen "lohnenden" device configCheck hört sich gut an. sicherlich inklusive template check. 

[martinp876]

Wie gesagt: ConfigCheck ist - nach meiner festen! Überzeugung - nichts, was bei einem Aufruf oder update einer Webpage ausgeführt werden sollte.

Config-check beinhaltet schon seit "immer" das prüfen der Templates. Es prüft alles, was ich kenne und was "generel gültig" ist.

So, nun habe ich configCheck auf neue Füsse gestellt.
a) die Tests sind unverändert
b) Das Erebnis von ConfigCheck wird im Reading configState einer jeden Entity dargestellt
c) die Details zu ConfigCheck kann man mit "get <deviceInfo>" einsehen. Damit brauchen wir nicht  noch ein weiteres kommando.
d) configCheck wird automatisch ausgeführt, wenn die Konfiguration verändert wird. Wird also automatisch upgedated.
e) get hm configInfo hat etwas mehr Text zu den Informationen aus configCheck


Ist heute nach SVN gekommen.

[frank]

Wie gesagt: ConfigCheck ist - nach meiner festen! Überzeugung - nichts, was bei einem Aufruf oder update einer Webpage ausgeführt werden sollte.

ok, dann braucht cgfState aber eventuell noch etwas feintuning:

1.

Config-check beinhaltet schon seit "immer" das prüfen der Templates.

wie schon vermutet, fehlt aber scheinbar ein trigger, der ggf einen erneut nötigen template check initiiert.
in allen 4 möglichen situationen konnte ich keine reaktion dies bezüglich feststellen:

a. cfgState=TmplChk => device register ändern, so dass das template ok wird.
b. cfgState=TmplChk => template ändern, so dass es dem device register entspricht.
c. cfgState=ok          => device register ändern, so dass das template nicht ok wird.
d. cfgState=ok          => template ändern, so dass es dem device register nicht entspricht.

erst durch ein "get hminfo configCheck" lässt sich die erzeugte diskrepanz zwischen cfgState und realität beheben.

2. soweit ich das beobachten konnte, wurden die neuen readings cfgState nach fhem update auch erst durch einen manuell gestarteten configcheck erzeugt.

3. ignored devices, bei denen das attr ignore gelöscht wird, erzeugen ebenfalls kein reading cfgState, auch wenn sie viele fehler enthalten.

4. wann genau erscheint cfgState=updating? dieser status tauchte irgend wann auf und blieb bestehen.

5. könntest du unter "get deviceInfo" auch die details von template missmatch anzeigen?
hier fehlen die infos über die abweichenden readings.

[martinp876]

Finetuning wird wohl nötig sein.
A. Inhaltlich sollte configcheck komplett sein. Falls es noch erweiterungen gibt, bitte melden
B. Trigger könnten fehlen, sehe ich aktuell aber nicht.
Ändert man Register müsste, autoreadcfg vorausgesetzt, ein getconfig aufgerufen werden, ein getconfig in die autoq gesetzt werden. Dabei wird der check gestartet, der status geht auf reading oder ähnlich. Wird getconfig manuell ausgeführt oder automatisch passiert es auch. Nur reading sollte mit den resultaten überschrieben werden.
  Appliziert man ein template könnte a) alle register passen =>status ist sowieso ok. Oder b) register passen nicht. Dann werden diese gesetzt und wir sind beim obigen Fall regset.

C) mit get deviceinfo sollte man alle abweichungem der entity sehen. Das habe ich oben schon erwähnt

Deine punkte a-d habe ich nicht verstanden. Sollte cfgstate tmplchk melden gibt es eine Diskrepanz. Details in debiceInfo oder get hm configCheck -f <entity>.
Um den fehler zu beheben würde ich nicht an den Register dikekt spielen sondern set hm templateExe ausführen. Und etwas warten

[frank]

Deine punkte a-d habe ich nicht verstanden. Sollte cfgstate tmplchk melden gibt es eine Diskrepanz. Details in debiceInfo oder get hm configCheck -f <entity>.
Um den fehler zu beheben würde ich nicht an den Register dikekt spielen sondern set hm templateExe ausführen. Und etwas warten

die punkte 1a-1d beschreiben 4 versuche einen template check zu triggern / provozieren.

meine erwartungen, hoffnungen und wünsche sind ja folgende:
über das reading cfgState möchte ich den aktuellen fehlerzustand der konfiguration "beobachten" können.
hier im speziellen fall den template check.


gegeben:
- HM-ES-PMSW1-PL chan0, parent device.
  230v aktor ist immer wach, daher kaum verzögerungen zu erwarten.
  keine chn01-probleme möglich, weil multi-channel-device.

- template mit einem parameter für register confBtnTime=permanent assigned.
- register im device und template sind synchron, deshalb zeigt cfgState=ok.


1. versuch (mein punkt 1c. aus letztem post):
- manuelle register änderung über regset mit: "set regSet confBtnTime 5"

ergebnis:
- register wurde ordnungsgemäss gesetzt und mit automatischem getconfig bestätigt.
- null reaktion beim reading cfgState.
- weiterhin wird cfgState=ok angezeigt, was definitiv eine falsche aussage ist.
- es müsste mindestens cfgState=updating, oder irgend eine andere änderung erfolgen.


erst ein manuelles hminfo configCheck zeigt den fehler:

Code Auswählen Erweitern

template mismatch
    SwitchES01: 0:0-> failed
  confBtnTime :5 should permanent

bei "get deviceInfo" fehlt die letzte zeile zum value:

Code Auswählen Erweitern

Device name:SwitchES01
   mId      :00AC  Model=HM-ES-PMSW1-PL
   mode    :normal - activity:alive
   protState : CMDs_done pending: none

configuration check: TmplChk
   TmplChk: template mismatch
      =>0:0-> failed


2. versuch (mein punkt 1b. aus letztem post):
- nach hminfo configcheck ist nun cfgState=TmplChk, also erst einmal alles gut.

- jetzt versuche ich den template fehler zu beseitigen, indem ich den parameter vom template ebenfalls ändere.
- manuelle parameter änderung über "set tplPara000_0_tplCheck_confBtnTime 5" aus dem set menü.

ergebnis:
- parameter wurde im template reading ordnungsgemäss gesetzt.
- null reaktion beim reading cfgState.
- weiterhin wird cfgState=TmplChk angezeigt, was definitiv wieder eine falsche aussage ist.
- es müsste mindestens cfgState=updating, oder irgend eine andere änderung erfolgen.


versuche 1a und 1d sollten jetzt auch klar sein.

gruss frank


edit: template zum testen angehängt:

Code Auswählen Erweitern

set hminfo templateDef tplCheck confBtnTime "test" confBtnTime:p0

[martinp876]

ok, ok.... war keine Heldentat
Ich habe die Automatik überarbeitet

[frank]

das sieht schon viel besser aus.

hier mal die 2 versuche mit neum cul_hm im eventmonitor:

Code Auswählen Erweitern

----- versuch1 (regSet) => gestartet mit cfgState=ok
2020-07-03 17:01:31.151 CUL_HM SwitchPBU06 R-powerUpAction: set_off
2020-07-03 17:01:31.171 CUL_HM SwitchPBU06 commState: CMDs_pending
2020-07-03 17:01:31.238 CUL_HM SwitchPBU06 cfgState: updating
2020-07-03 17:01:31.262 CUL_HM SwitchPBU06 commState: CMDs_processing...
2020-07-03 17:01:31.417 CUL_HM SwitchPBU06 commState: CMDs_pending
2020-07-03 17:01:31.519 CUL_HM SwitchPBU06 commState: CMDs_processing...
2020-07-03 17:01:31.815 CUL_HM SwitchPBU06 commState: CMDs_pending
2020-07-03 17:01:31.916 CUL_HM SwitchPBU06 commState: CMDs_processing...
2020-07-03 17:01:32.211 CUL_HM SwitchPBU06 commState: CMDs_done
2020-07-03 17:01:35.339 CUL_HM SwitchPBU06 cfgState: TmplChk,RegIncom
2020-07-03 17:01:35.361 CUL_HM SwitchPBU06 commState: CMDs_pending
2020-07-03 17:01:35.387 CUL_HM SwitchPBU06 commState: CMDs_processing...
2020-07-03 17:01:36.944 CUL_HM SwitchPBU06 R-powerUpAction: off
2020-07-03 17:01:37.374 CUL_HM SwitchPBU06 commState: CMDs_pending
2020-07-03 17:01:37.374 CUL_HM SwitchPBU06 commState: CMDs_processing...
2020-07-03 17:01:40.692 CUL_HM SwitchPBU06 commState: CMDs_done

----- versuch1 (regSet) => abgebrochen und manuellen configCheck ausgelöst
2020-07-03 17:03:14.910 CUL_HM SwitchPBU06 cfgState: Info_Expecting
2020-07-03 17:03:15.466 CUL_HM SwitchPBU06 cfgState: TmplChk

----- versuch2 (tplPara) => gestartet
2020-07-03 17:06:00.000 CUL_HM SwitchPBU06 tplPara000_0_ES_00_powerUpAction off

----- versuch2 (tplPara) => abgebrochen und manuellen configCheck ausgelöst
2020-07-03 17:06:40.628 CUL_HM SwitchPBU06 cfgState: Info_Expecting
2020-07-03 17:06:41.156 CUL_HM SwitchPBU06 cfgState: ok


- im ersten versuch fehlt quasi ein zweites "updating", weil "RegIncom" automatisch korrigiert wurde.
- "Info_Expecting" schreibe ich ins cfgState, wenn ich einen manuellen configCheck starte.

- die parameter änderung im zweiten versuch wurde weiterhin nicht erkannt.

[martinp876]

so update again.

"Info_Expecting" schreibe ich ins cfgState, wenn ich einen manuellen configCheck starte. 

Privat ist das ok. hm.js sollte sich nicht in vorhandene Readings einmischen!

Das Triggern des Checks habe ich "verlegt". Dadurch wird es nun häufiger "angefahren" und man sieht Zwischenstände.
Ich versuche später, diese noch zu unterdrücken....  dauert etwas.
=> die aktuelle Version ist eingescheckt.

[frank]

Das Triggern des Checks habe ich "verlegt". Dadurch wird es nun häufiger "angefahren" und man sieht Zwischenstände.
Ich versuche später, diese noch zu unterdrücken....  dauert etwas.
=> die aktuelle Version ist eingescheckt.

prima, das funktioniert nun schon ganz gut.


wenn ein TpltCheck fehler in cfgCheck besteht, wird dieser nicht automatisch entfernt, wenn ich diesen fehler über hminfo templateSet korrigiere. ich ändere damit einen parameter.

[frank]

neues update verfügbar.

- das configCheck icon signalisiert jetzt das reading cfgState mit longpoll unterstützung.
- keine klick funktion mehr für configCheck.
  daher nun bei nicht synchronem reading cfgCheck bitte fehler melden, damit martin cfgState nachbessern kann.

- neues "schloss" icon für devices mit reading sabotageError und lonpoll unterstützung.

- neues "klingel" icon für devices mit reading sabotageAttack_ErrIoAttack_cnt und lonpoll animation.
- klick funktion für sabotageAttack_ErrIoAttack_cnt: set clear attack.

- klick funktion für commState: set clear msgEvents.

- das rssi icon zeigt nun eine färbung entsprechend dem min value. nicht mehr avg.
- klick funktion für rssi: set clear rssi.


hoffentlich habe ich nichts vergessen. 

[frank]

@martin

aktuell gibt es 3 probleme mit "get deviceInfo" im zusammenspiel mit den readings commState und cfgState.


a. nach fhem restart:

Code Auswählen Erweitern

Device name:Thermostat.OZ
   mId      :0039  Model=HM-CC-TC
   mode    :config,wakeup,burstCond - activity:alive
   protState : unknown pending: none

configuration check: TmplChk

1. protState: unknown
hier gibt es eine diskrepanz mit dem reading commState, das ja den letzten zustand zb "Cmds_done" gespeichert hat.

sollte commState eventuell nach restart ebenfalls unknown anzeigen?
dann würde man auch gut erkennen, ob die automatischen statusrequests nach restart bereits gestartet wurden, oder noch in der queue hängen.

2. configuration check: TmplChk
das check resultat ist richtig und entspricht dem reading cfgCheck.
hier fehlen allerdings die genauen infos, da noch kein configCheck gestartet worden ist.

wäre es nicht sinnvoll nach restart einen automatischen configCheck zu schedulen und bis zu dessen ausführung hier zusätzlich eine info darüber zu positionieren?

beispiel:  "waiting for details after fhem restart - configCheck is scheduled"

wenn man einen automatischen configCheck scheduled, sollte man das dann auch im reading cfgState verkünden.


b. im "normalen" betrieb:

3. es fehlen in deviceInfo weiterhin grundsätzlich die detaillierten infos zu den template checks, die von "get hminfo configCheck" geliefert werden.

configCheck zeigt details zu den angemahnten registern:

Code Auswählen Erweitern

configCheck done:

template mismatch
    Thermostat.OZ: 0:0-> failed
  backlOnTime :20 should 15


bei deviceInfo fehlen die infos über die register unterschiede:

Code Auswählen Erweitern

Device name:Thermostat.OZ
   org ID    :0039  Model=HM-CC-TC
   alias ID :0039  Model=HM-CC-TC
   mode    :config,wakeup,burstCond - activity:alive
   protState : CMDs_done pending: none

   Thermostat.OZ_Weather state:T: 17.4 H: 66
   Thermostat.OZ_Climate state:set_desired-temp 6.5
   Thermostat.OZ_WindowRec state:last:trigLast
configuration check: TmplChk
   TmplChk: template mismatch
      =>0:0-> failed