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

[frank]

die aktuelle version von HMdeviceTools.js (hm.js) ist nun wieder im alten thread zu finden.
die icons werden nun über HMinfoTools.js in HMdeviceTools.js integriert:
https://forum.fhem.de/index.php/topic,106959.0.html


ich möchte euch hier mal meine idee zur visualisierung des aktuellen kommunikationsstatus von devices vorstellen.
die "led" soll einerseits ein feedback erzeugen, um zu "sehen", dass ein cmd in verarbeitung ist, und andererseits soll dadurch einfach erkennbar sein, ob eine aktion beendet und erfolgreich war.

ziel => sobald die led grün leuchtet ist die ausgeführte aktion erfolgreich abgeschlossen. es gibt keine pending cmds und verifizierungen sind nicht mehr nötig.

ich bin überrascht wie gut das jetzt schon funktioniert.
besonders hilfreich zb bei batterie devices, die viele daten zu übertragen haben und zusätzlich durch schlechten funk und mieses timing auffallen. => zb set getConfig auf thermostate mit cul oder wlan io.


mittlerweile sind noch einige weitere icons hinzugekommen:

protokoll anzeige:
- in jedem channel auf der detailseite gibt es jetzt eine status led für das reading commState vom parent device.
- zusätzlich der reading value als text.
- änderungen über longpoll.

Code Auswählen Erweitern

white                       Info_Cleared, Info_unknown (no reading)
yellow                      CMDs_processing..., CMDs_FWupdate
orange                      CMDs_pending
red                         CMDs_done_Errors:1
green                       CMDs_done, CMDs_done_FWupdate
- mit klick-funktion: "set clear msgEvents"

cfgCheck:
cfgCheck zeigt device fehler und template fehler.
wenn template fehler enthalten sind, werden diese zusätzlich durch einfärben der betroffenen registerset links dargestellt.

- icon für cfgCheck (grün: ok, rot: fehler, weiss: kein reading, gelb: updating).
- änderungen über longpoll.
- wenn cfgCheck fehler zeigt (rot), werden diese detailiert im titel angezeigt.
- die links für die registerset bearbeitung sind nun farbig, wenn templates assigned sind:
- gelb: template assigned / kein templateCheck erfolgt.
- grün:template assigned / templateCheck ok.
- rot: template assigned / templateCheck zeigt fehler für diesen registerset.

battery:
- battery devices zeigen ein gefärbtes battery icon.
- grün: ok, orange: low, rot: critical.

sabotageAttack_ErrIoAttack_cnt:
- devices mit reading sabotageAttack_ErrIoAttack_cnt zeigen ein rotes "klingel" icon.
- änderungen über longpoll. mit animation, falls das icon schon existiert ("flammt" kurz weiss auf).
- mit klick-funktion: "set clear attack"

sabotageError:
- devices mit reading sabotageError zeigen ein gefärbtes "schloss" icon.
- änderungen über longpoll.
- grün: off, rot: on.

rssi:
- vom io, das im internal IODev gesetzt ist, wird der rssi_at_io min value angezeigt.
- farbcode:

Code Auswählen Erweitern

color    rssi                  special
-----------------------------------------------------
white    missing_rssi
green    -80 <  rssi
yellow   -90 <  rssi <= -80
orange   -99 <= rssi <= -90
red             rssi <  -99    ,missing_IODev

- mit klick-funktion: "set device clear rssi"

ActionDetector:
- der zustand des AD wird durch ein icon signalisiert.
- änderungen über longpoll.

Code Auswählen Erweitern

white unused (no attr actCycle)
yellow switchedOff (actCycle = 000:00)
orange unknown
red dead
green     alive



todolist
- das reading commState sollte weitere zustände anzeigen.

[Pfriemler]

coole Sache, werde ich nachstellen. Bin nur noch nicht dazu gekommen, gerade toben hier andere Baustellen.
Statt des rc_dot@(color) könntest Du die "diskreten" 10px-kreis-<color>" nehmen, die es in rot, gruen und gelb gibt und die schön klein sind.
Das Dunkelgrau habe ich mir heute (aus anderem Grund) kurzerhand mit der Rote-Augen-Entfernen-Funktion von Irfanview aus dem 10px-kreis-rot gebastelt und aus dem gelben einen orangenen umgefärbt. Anbei.

edit: orange etwas oranger auf Wunsch von frank.

[papa]

Eigentlich ist das doch ein Overlay über das "normale" DevState-Icon. Ich würde ein ähnliches Overlay gern für Batteriegeräte haben, um das DevState-Icon mit einen "Batterie-leer" Symbol zu dekorieren, wenn die Batterie zu Ende geht.
Könnte man nicht ein devStateOverlay Attribute einführen, welches dann die Generierung eines Overlay-Symbols macht - im einfachsten Fall per direkter Perl-Funktion oder ähnlich der devStateIcon-Funktionalität.
Ist zwar etwas OT - aber passt hier ganz gut hin.

[frank]

schau mal hier: https://forum.fhem.de/index.php/topic,97586.msg908277.html#msg908277

meine version ist wohl nicht ganz regel gerecht, da alle 3 elemente unter einem gemeinsamen "link" gruppiert sind.
dafür bekomme ich aber das default state verhalten.

edit
im wiki unter doif gibt es 1000000 bunte beispiele.

[frank]

Statt des rc_dot@(color) könntest Du die "diskreten" 10px-kreis-<color>" nehmen, die es in rot, gruen und gelb gibt und die schön klein sind.

die haben genau die richtige grösse.
allerdings wollte ich was "zukunftssicheres" haben.
irgendwie "verschwinden" im laufe der zeit alle png icons, habe ich das gefühl.

[frank]

anbei mal eine testversion von hm.js
edit: neue version mit mehr features ab jetzt immer im ersten post

mit "attr <webdevice> longpoll websocket" plus firefox gibt es noch einen fhemweb.js-fehler beim aufruf der detailseite eines channeldevices. nach bestätigung des fehlers funktioniert es allerdings wie vorgesehen.
unauffällig mit "attr <webdevice> longpoll 1".
edit: wurde gefixt.

- in jedem channel auf der detailseite gibt es jetzt eine status led für das reading commState vom parent device
- zusätzlich der reading value als text
- änderungen über longpoll
- genutzt werden zur zeit die "10px-kreis-<color>.png" icons in /opt/fhem/www/images/default
- wer alle 5 farben sehen will, muss die 2 zusätslichen icons für dunkelgrau und orange von pfriemler installieren

[Pfriemler]

Code Auswählen Erweitern

hm.js line 115:
TypeError: data.Results[0].Readings.commState is undefined

und

Code Auswählen Erweitern

fhemweb.js line 1059:
TypeError: FW_pollConn is undefined

hier funktioniert die Anzeige dann aber ...

orange etwas oranger im Beitrag weiter oben neu angehangen.

[frank]

hm.js line 115:

bei welchem channel taucht der fehler auf?
kommt der dann grundsätzlich?
zeig mal je ein list von diesem channel und seinem hauptdevice.

fhemweb.js line 1059:

ist dieser fehler unabhängig vom ersten?
kommt der grundsätzlich immmer, oder nur bei bestimmten devices/channels?
welchen fhem style nutzt du?
welche hardware, os, browser?
welche longpoll einstellung im web device?

[Pfriemler]

hm.js line 115 kommt nicht grundsätzlich, ich habe noch keine Korrelation erkannt. Vieles läuft einwandfrei.

"hm.js line 121: TypeError: object.Readings.commState is undefined" zb. bei

Code Auswählen Erweitern

Internals:
   DEF        266A77
   FUUID      5c5c498a-f33f-d113-1ee7-11fe3bd62c94df28
   IODev      HMUART
   NAME       HM_266A77
   NOTIFYDEV  global
   NR         46
   NTFY_ORDER 50-HM_266A77
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_266A77_Dim
   channel_02 HM_266A77_Dim_V_01
   channel_03 HM_266A77_Dim_V_02
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     from archivexx        .D-devInfo      110100
     from archivexx        .D-stc          20
     2020-06-05 20:03:34   .R-intKeyVisib  visib
     2016-03-03 22:02:34   .R-localResDis  off
     2020-06-06 13:37:35   .protLastRcv    2020-06-06 13:37:35
     2020-06-05 20:07:13   CommandAccepted yes
     from archivexx        D-firmware      2.9
     from archivexx        D-serialNr      KEQxxxxxx (von mir gelöscht)
     2020-06-05 20:03:34   PairedTo        0xxxxxx (auch von mir gelöscht
     2020-06-05 19:57:25   R-pairCentral   0xxxxxxx
     2020-06-05 20:03:34   RegL_00.        00:00 02:81 0A:14 0B:11 0C:AB 15:FF 18:00 2E:2E
     2016-03-29 08:51:36   phyLevel        0
     2020-06-05 20:07:50   powerOn         2020-06-05 20:07:49
     2016-03-03 21:59:42   sabotageAttackId_ErrIoId_3B4DAD cnt:23
     2016-03-08 22:28:38   sabotageAttack_ErrIoAttack cnt 24
     2020-06-06 13:37:35   state           CMDs_done
   helper:
     HM_CMDNR   218
     mId        0068
     peerFriend
     peerOpt    -:dimmer
     regLst     0
     rxType     1
     tmplChg    0
     cmds:
       TmplKey    :1592658732.81959:1592658732.85362
       TmplTs     1592658732.85362
       cmdKey     :0:1:0::0068:01
       TmplCmds:
       cmdList:
         assignHmKey:
         clear:[readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         deviceRename:newName
         fwUpdate:-filename- -bootTime- ...
         getConfig:
         getDevInfo:
         getRegRaw:[List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         getSerial:
         getVersion:
         pair:
         raw:data ...
         regBulk:-list-.-peer- -addr1:data1- -addr2:data2- ...
         regSet:[prep|exec] -regName- -value- ... [-peerChannel-]
         reset:
         tplDel:tmplt
         unpair:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +266A77,00,01,00
       rxt        0
       vccu       vccu
       p:
         266A77
         00
         01
         00
       prefIO:
         HMUART
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     tmpl:
Attributes:
   .devInfo   110100
   .mId       0068
   .stc       20
   IODev      HMUART
   IOgrp      vccu:HMUART
   alias      HM_266A77 (HM-LC-DIM1TPBU-FM, Fundus)
   autoReadReg 0_off
   comment    ehemals Einbauort EGWz über Esstisch, ab 2018 frei
   event-on-change-reading .*
   expert     2_full
   firmware   2.9
   group      Aktoren
   model      HM-LC-DIM1TPBU-FM
   room       Pool
   serialNr   KEQxxxxxxx
   subType    dimmer
   webCmd     getConfig

also Hauptdevice.

fhemweb.js line 1059 kommt nur, wenn nicht vorher hm.js meckerte.

Code Auswählen Erweitern

Internals:
   DEF        414004
   FUUID      5ed65bc5-f33f-d113-2d94-9d05bb9a6091d7b2
   IODev      HMUART
   NAME       HM_414004
   NOTIFYDEV  global
   NR         1036
   NTFY_ORDER 50-HM_414004
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 HM_414004_Dim
   channel_02 HM_414004_Dim_V_01
   channel_03 HM_414004_Dim_V_02
   .attraggr:
   .attrminint:
   READINGS:
     1900-01-01 00:00:01   .D-devInfo      110100
     1900-01-01 00:00:01   .D-stc          20
     2020-06-02 16:09:16   .R-intKeyVisib  visib
     2020-06-15 18:04:23   .protLastRcv    2020-06-15 18:04:23
     2020-06-02 16:08:56   CommandAccepted yes
     from archivexx        D-firmware      2.9
     from archivexx        D-serialNr      MEQ1566901
     2020-06-15 18:04:12   PairedTo        0xAAAAAA
     2020-06-02 16:08:05   R-pairCentral   0xAAAAAA
     2020-06-15 18:04:12   RegL_00.        00:00 02:81 0A:14 0B:11 0C:AB 15:FF 18:00
     2020-06-18 13:24:32   commState       CMDs_done_Errors:1
     2020-06-15 18:04:07   powerOn         2020-06-15 18:04:07
     2020-06-18 13:24:32   state           MISSING ACK
   helper:
     HM_CMDNR   237
     mId        0071
     peerFriend
     peerOpt    -:dimmer
     regLst     0
     rxType     1
     tmplChg    0
     cmds:
       TmplKey    :1592658732.81959:1592658732.8548
       TmplTs     1592658732.8548
       cmdKey     :0:1:0::0071:01
       TmplCmds:
       cmdList:
         assignHmKey:
         clear:[readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         deviceRename:newName
         fwUpdate:-filename- -bootTime- ...
         getConfig:
         getDevInfo:
         getRegRaw:[List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         getSerial:
         getVersion:
         pair:
         raw:data ...
         regBulk:-list-.-peer- -addr1:data1- -addr2:data2- ...
         regSet:[prep|exec] -regName- -value- ... [-peerChannel-]
         reset:
         tplDel:tmplt
         unpair:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +414004,00,01,00
       rxt        0
       vccu       vccu
       p:
         414004
         00
         01
         00
       prefIO:
         HMUART
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     tmpl:
Attributes:
   .mId       00B4
   IODev      HMUART
   IOgrp      vccu:HMUART
   autoReadReg 3_onChange
   expert     2_raw
   firmware   2.9
   model      HM-LC-DIM1T-PL-3
   room       Pool
   serialNr   MEQ1566901
   shAlias    Univ.Dimm2
   subType    dimmer
   webCmd     getConfig:clear msgEvents
ist fehlerfrei,
Unterkanal

Code Auswählen Erweitern

Internals:
   DEF        41400401
   FUUID      5ed65bc7-f33f-d113-6e2b-9ed2b6798f9905e2
   NAME       HM_414004_Dim
   NOTIFYDEV  global
   NR         1037
   NTFY_ORDER 50-HM_414004_Dim
   STATE      unreachable
   TYPE       CUL_HM
   chanNo     01
   device     HM_414004
   peerList   self01,
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   READINGS:
     2020-06-13 12:40:31   .R-self01-lgCtDlyOff geLo
     2020-06-13 12:40:31   .R-self01-lgCtDlyOn geLo
     2020-06-13 12:40:31   .R-self01-lgCtOff geLo
     2020-06-13 12:40:31   .R-self01-lgCtOn geLo
     2020-06-13 12:40:31   .R-self01-lgCtRampOff geLo
     2020-06-13 12:40:31   .R-self01-lgCtRampOn geLo
     2020-06-13 12:40:31   .R-self01-lgCtValHi 100
     2020-06-13 12:40:31   .R-self01-lgCtValLo 50
     2020-06-13 12:40:31   .R-self01-lgDimJtDlyOff rampOff
     2020-06-13 12:40:31   .R-self01-lgDimJtDlyOn rampOn
     2020-06-13 12:40:31   .R-self01-lgDimJtOff dlyOn
     2020-06-13 12:40:31   .R-self01-lgDimJtOn dlyOff
     2020-06-13 12:40:31   .R-self01-lgDimJtRampOff off
     2020-06-13 12:40:31   .R-self01-lgDimJtRampOn on
     2020-06-13 12:40:31   .R-self01-lgDimMaxLvl 100 %
     2020-06-13 12:40:31   .R-self01-lgDimMinLvl 0 %
     2020-06-13 12:40:31   .R-self01-lgDimStep 5 %
     2020-06-13 12:40:31   .R-self01-lgMultiExec on
     2020-06-13 12:40:31   .R-self01-lgOffDly 0 s
     2020-06-13 12:40:31   .R-self01-lgOffDlyBlink on
     2020-06-13 12:40:31   .R-self01-lgOffDlyNewTime 0.4 s
     2020-06-13 12:40:31   .R-self01-lgOffDlyOldTime 0.4 s
     2020-06-13 12:40:31   .R-self01-lgOffDlyStep 5 %
     2020-06-13 12:40:31   .R-self01-lgOffLevel 0 %
     2020-06-13 12:40:31   .R-self01-lgOffTime unused
     2020-06-13 12:40:31   .R-self01-lgOffTimeMode absolut
     2020-06-13 12:40:31   .R-self01-lgOnDly 0 s
     2020-06-13 12:40:31   .R-self01-lgOnDlyMode setToOff
     2020-06-13 12:40:31   .R-self01-lgOnLvlPrio high
     2020-06-13 12:40:31   .R-self01-lgOnMinLevel 10 %
     2020-06-13 12:40:31   .R-self01-lgOnTime unused
     2020-06-13 12:40:31   .R-self01-lgOnTimeMode absolut
     2020-06-13 12:40:31   .R-self01-lgRampOffTime 0.5 s
     2020-06-13 12:40:31   .R-self01-lgRampOnTime 0.5 s
     2020-06-13 12:40:31   .R-self01-lgRampSstep 5 %
     2020-06-13 12:40:31   .R-self01-shCtDlyOff geLo
     2020-06-13 12:40:31   .R-self01-shCtDlyOn geLo
     2020-06-13 12:40:31   .R-self01-shCtOff geLo
     2020-06-13 12:40:31   .R-self01-shCtOn geLo
     2020-06-13 12:40:31   .R-self01-shCtRampOff geLo
     2020-06-13 12:40:31   .R-self01-shCtRampOn geLo
     2020-06-13 12:40:31   .R-self01-shCtValHi 100
     2020-06-13 12:40:31   .R-self01-shCtValLo 50
     2020-06-13 12:40:31   .R-self01-shDimJtDlyOff rampOff
     2020-06-13 12:40:31   .R-self01-shDimJtDlyOn rampOn
     2020-06-13 12:40:31   .R-self01-shDimJtOff dlyOn
     2020-06-13 12:40:31   .R-self01-shDimJtOn dlyOff
     2020-06-13 12:40:31   .R-self01-shDimJtRampOff off
     2020-06-13 12:40:31   .R-self01-shDimJtRampOn on
     2020-06-13 12:40:31   .R-self01-shDimMaxLvl 100 %
     2020-06-13 12:40:31   .R-self01-shDimMinLvl 0 %
     2020-06-13 12:40:31   .R-self01-shDimStep 5 %
     2020-06-13 12:40:31   .R-self01-shMultiExec off
     2020-06-13 12:40:31   .R-self01-shOffDly 0 s
     2020-06-13 12:40:31   .R-self01-shOffDlyBlink on
     2020-06-13 12:40:31   .R-self01-shOffDlyNewTime 0.4 s
     2020-06-13 12:40:31   .R-self01-shOffDlyOldTime 0.4 s
     2020-06-13 12:40:31   .R-self01-shOffDlyStep 5 %
     2020-06-13 12:40:31   .R-self01-shOffLevel 0 %
     2020-06-13 12:40:31   .R-self01-shOffTime unused
     2020-06-13 12:40:31   .R-self01-shOffTimeMode absolut
     2020-06-13 12:40:31   .R-self01-shOnDly 0 s
     2020-06-13 12:40:31   .R-self01-shOnDlyMode setToOff
     2020-06-13 12:40:31   .R-self01-shOnLvlPrio high
     2020-06-13 12:40:31   .R-self01-shOnMinLevel 10 %
     2020-06-13 12:40:31   .R-self01-shOnTime unused
     2020-06-13 12:40:31   .R-self01-shOnTimeMode absolut
     2020-06-13 12:40:31   .R-self01-shRampOffTime 0.5 s
     2020-06-13 12:40:31   .R-self01-shRampOnTime 0.5 s
     2020-06-13 12:40:31   .R-self01-shRampSstep 5 %
     2020-06-13 12:40:28   .R-statusInfoMinDly 2 s
     2020-06-13 12:40:28   .R-statusInfoRandom 1 s
     2020-06-13 12:40:28   .R-transmitTryMax 6
     2020-06-16 08:15:47   .peerListRDate  2020-06-16 08:15:47
     2020-06-15 17:57:34   CommandAccepted yes
     2020-06-13 12:40:28   R-powerUpAction off
     2020-06-13 12:40:31   R-self01-lgActionTypeDim toggelDim
     2020-06-13 12:40:31   R-self01-lgOnLevel 100 %
     2020-06-13 12:40:31   R-self01-shActionTypeDim jmpToTarget
     2020-06-13 12:40:31   R-self01-shOnLevel 100 %
     2020-06-13 12:40:28   R-sign          off
     2020-06-15 18:04:13   RegL_01.        00:00
     2020-06-15 18:04:19   RegL_03.self01  00:00 01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:52 0D:63 0E:20 0F:00 10:14 11:C8 12:0A 13:05 14:05 15:00 16:C8 17:0A 18:0A 19:04 1A:04 26:00 27:14 28:52 29:63 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:26 8B:14 8C:52 8D:63 8E:20 8F:00 90:14 91:C8 92:0A 93:05 94:05 95:00 96:C8 97:0A 98:0A 99:04 9A:04 A6:20 A7:14 A8:52 A9:63
     2020-06-14 14:35:43   commState       Info_Cleared
     2020-06-15 18:04:07   deviceMsg       off (to vccu)
     2020-06-15 18:04:07   dim             stop:off
     2020-06-15 18:04:07   level           0
     2020-06-15 18:04:07   overheat        off
     2020-06-15 18:04:07   overload        off
     2020-06-15 18:04:07   pct             0
     2020-06-20 15:12:12   peerList        self01,
     2020-06-15 18:04:09   phyLevel        0
     2020-06-15 18:04:07   recentStateType info
     2020-06-15 18:04:07   reduced         off
     2020-06-18 13:23:57   state           unreachable
     2020-06-15 18:04:07   timedOn         off
     2020-06-15 17:57:34   trigLast        fhem:02
   helper:
     peerFriend peerSens,peerVirt
     peerOpt    3:dimmer
     regLst     1,3p
     tmplChg    0
     cmds:
       TmplKey    self01,:1592658732.81959:1592658732.85483
       TmplTs     1592658732.85483
       cmdKey     :1:0:0::0071:01self01,
       TmplCmds:
         tplSet_self01:[DimOff_long|DimOff_short|DimOn_long|DimOn_short|SwCondAbove_long|SwCondAbove_short|SwCondBelow_long|SwCondBelow_short|SwOnCond_long|SwOnCond_short|motionOnDim_long|motionOnDim_short]
       cmdList:
         clear:[readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
         down:[-changeValue-] [-ontime-] [-ramptime-] ...
         eventL:-peer- -cond-
         eventS:-peer- -cond-
         getConfig:
         getRegRaw:[List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
         inhibit:[on|off]
         off:
         old:
         on-for-timer:-ontime- [-ramptime-]...
         on-till:-time- [-ramptime-]...
         on:
         pct:[-value-|old] ... [-ontime-] [-ramptime-]
         peerBulk:-peer1,peer2,...- [set|unset]
         peerIODev:[IO] -btn- [set|unset]... not for future use
         peerSmart:[8BattSensor1_Btn_01|8BattSensor1_Btn_02|8BattSensor1_Btn_03|8BattSensor1_Btn_04|8BattSensor1_Btn_05|8BattSensor1_Btn_06|8BattSensor1_Btn_07|8BattSensor1_Btn_08|8BattSensor3_Btn_07|8BattSensor3_Btn_08|AAZS|AlarmanlagePowerTick|ArmFull|ArmPartial|BewMelder1|BewMelder2|BewMelder3|BewMelder4|BewMelder5|Briefkastenklappe|Briefkastentor|CCU2|Disarm|DispFB_Btn_01|DispFB_Btn_02|DispFB_Btn_03|DispFB_Btn_04|DispFB_Btn_05|DispFB_Btn_06|DispFB_Btn_07|DispFB_Btn_08|DispFB_Btn_09|DispFB_Btn_10|DispFB_Btn_11|DispFB_Btn_12|DispFB_Btn_13|DispFB_Btn_14|DispFB_Btn_15|DispFB_Btn_16|DispFB_Btn_17|DispFB_Btn_18|DispFB_Btn_19|DispFB_Btn_20|Eingang6Taster_LeftDown|Eingang6Taster_LeftUp|Eingang6Taster_MidDown|Eingang6Taster_MidUp|Eingang6Taster_RightDown|Eingang6Taster_RightUp|EnMonitorHS1_SenF|EnMonitorHS1_SenI|EnMonitorHS1_SenPwr|EnMonitorHS1_SenU|EnMonitorHS2_SenF|EnMonitorHS2_SenI|EnMonitorHS2_SenPwr|EnMonitorHS2_SenU|EnMonitorSM1_SenF|EnMonitorSM1_SenI|EnMonitorSM1_SenPwr|EnMonitorSM1_SenU|EnMonitorStecker1_SenF|EnMonitorStecker1_SenI|EnMonitorStecker1_SenPwr|EnMonitorStecker1_SenU|EnMonitorStecker2_SenF|EnMonitorStecker2_SenI|EnMonitorStecker2_SenPwr|EnMonitorStecker2_SenU|EnMonitorStecker3_SenF|EnMonitorStecker3_SenI|EnMonitorStecker3_SenPwr|EnMonitorStecker3_SenU|EnMonitorStecker4_SenF|EnMonitorStecker4_SenI|EnMonitorStecker4_SenPwr|EnMonitorStecker4_SenU|FB12_Btn_01|FB12_Btn_02|FB12_Btn_03|FB12_Btn_04|FB12_Btn_05|FB12_Btn_06|FB12_Btn_07|FB12_Btn_08|FB12_Btn_09|FB12_Btn_10|FB12_Btn_11|FB12_Btn_12|FB4Alarm_armExt|FB4Alarm_armInt|FB4Alarm_disarm|FB4Alarm_light|FB4V2_Btn_01|FB4V2_Btn_02|FB4V2_Btn_03|FB4V2_Btn_04|FB4V_Btn1|FB4V_Btn2|FB4V_Btn3|FB4V_Btn4|FK_DGBad|FK_DGTreppe|FK_EGHaustuer|FK_EGWC|FK_KGBad|FK_KGHAR|FK_OGBad|FK_OGNordL|FK_OGNordR|FK_OGOst|FK_OGWest|GarageAussentaster|GarageEM1|GarageEM2|GarageLadesteckdosenFernbedienung|GarageRemoteAir|GarageRemoteLightAutomatic|GarageRemoteLightManual|GarageSchloss|GaragentorSensor|GewitterBlitz|GewitterWarnung|HM_190D0F|HM_2CE159_Btn_01|HM_2CE159_Btn_02|HM_PB4Dis1_Btn_01|HM_PB4Dis1_Btn_02|HM_PB4Dis1_Btn_03|HM_PB4Dis1_Btn_04|HM_PB4Dis1_Btn_05|HM_PB4Dis1_Btn_06|HM_PB4Dis1_Btn_07|HM_PB4Dis1_Btn_08|HM_PB4Dis1_Btn_09|HM_PB4Dis1_Btn_10|HM_PB4Dis1_Btn_11|HM_PB4Dis1_Btn_12|HM_PB4Dis1_Btn_13|HM_PB4Dis1_Btn_14|HM_PB4Dis1_Btn_15|HM_PB4Dis1_Btn_16|HM_PB4Dis1_Btn_17|HM_PB4Dis1_Btn_18|HM_PB4Dis1_Btn_19|HM_PB4Dis1_Btn_20|KBLichtschalter1_Down|KBLichtschalter1_Up|KBLichtschalter2_Down|KBLichtschalter2_Up|KGSz2Taster_Down|KGSz2Taster_Up|KGSzBettlicht_down|KGSzBettlicht_up|Klingelknopf|Kueche2Taster_Down|Kueche2Taster_Up|Lichthupe_Sen_01|Lichthupe_Sen_02|Nachbar_SC2_01|Nachbar_SC2_02|Nachbar_SC2_03|Nachbar_SC2_04|Nachbar_SC2_05|Nachbar_SC2_06|Nachbar_SC2_07|Nachbar_SC2_08|Nachbar_SC2_09|Nachbar_SC2_10|Nachbar_SC2_11|Nachbar_SC2_12|Nachbar_SC2_13|Nachbar_SC2_14|Nachbar_SC2_15|Nachbar_SC2_16|Nachbar_SC2_17|Nachbar_SC2_18|Nachbar_SC2_19|Nachbar_SC2_20|Nachbar_SC2_21|Nachbar_SC2_22|Nachbar_SC2_23|Nachbar_SC2_24|Nachbar_SC2_25|Nachbar_SC2_26|Nachbar_SC2_27|Nachbar_SC2_28|Nachbar_SC2_29|Nachbar_SC2_30|Nachbar_SCO_01|Nachbarzentrale|PANIC|RHS_1|RegenSensor1_Rain|SCo_Kueche|SCo_Terrasse|SchalterSensorSCI3_1_ch03|SchalterSensorSCI3_2_ch03|SensorKGSzLiO|SensorKGSzLiU|SensorKGSzReO|SensorKGSzReU|Sw1CFW_Btn_01|Sw1CFW_Btn_02|TeamRauchmelder|Wassermelder_1|Wz2Taster1_Down|Wz2Taster1_Up|Wz6TasterLeftDown|Wz6TasterLeftUp|Wz6TasterMidDown|Wz6TasterMidUp|Wz6TasterRightDown|Wz6TasterRightUp|vccu_Btn10_AlarmBlinkOff|vccu_Btn11_AlarmBlinkOn|vccu_Btn12_Watchdog|vccu_Btn13_KompOverload|vccu_Btn14|vccu_Btn15|vccu_Btn16|vccu_Btn17|vccu_Btn18|vccu_Btn19|vccu_Btn1_ACK_FB_diverse|vccu_Btn20_TestBurst|vccu_Btn2_ACK_Eingang6Taster|vccu_Btn3_ACK_PB4Dis|vccu_Btn4_ACK_AAZS|vccu_Btn5_diverseSensoren|vccu_Btn6|vccu_Btn7|vccu_Btn8|vccu_Btn9|vi_Lightbox1_AllOff|vi_Lightbox1_LeftDown|vi_Lightbox1_LeftUp|vi_Lightbox1_RightDown|vi_Lightbox1_RightUp]
         press:[long|short] -peer- [-repCount(long only)-] [-repDelay-] ...
         regBulk:-list-.-peer- -addr1:data1- -addr2:data2- ...
         regSet:[prep|exec] -regName- -value- ... [-peerChannel-]
         sign:[on|off]
         statusRequest:
         stop:
         toggle:
         tplDel:tmplt
         up:[-changeValue-] [-ontime-] [-ramptime-] ...
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
     vDim:
       idPhy      41400401
       idV2       41400402
       idV3       41400403
Attributes:
   alexaName  Universaldimmer 2
   alias      Universaldimmer2 (zbV)
   cmdIcon    off:general_aus on:general_an up:control_plus down:control_minus
   devStateIcon off:light_light_dim_00@darkgrey:on on:light_light_dim_100@yellow:off 9\d.*:light_light_dim_90:off 8\d.*:light_light_dim_80:off 7\d.*:light_light_dim_70:off 6\d.*:light_light_dim_60:off 5\d.*:light_light_dim_50:off 4\d.*:light_light_dim_40:off 3\d.*:light_light_dim_30:off 2\d.*:light_light_dim_20:off 1\d.*:light_light_dim_10:off .*:light_light_dim_00_old@darkred:toggle
   event-on-change-reading .*
   genericDeviceType switch
   group      Steckdosen
   model      HM-LC-DIM1T-PL-3
   peerIDs    00000000,41400401,
   room       CUL_HM,Pool,Licht
   webCmd     pct
wirft den Fehler.

Ich habe aktuell nicht die Zeit in die Tiefe zu gehen, sorry.

Style ist "dark"
Der Tip mit dem Browser ist gut: Chrome liefert am PC (win10) als auch auf dem Androiden

Code Auswählen Erweitern

hm.js line 121:
Uncaught TypeError: Cannot read property 'Value' of undefined


longpoll ist "websocket".

Jetzt du.

[frank]

probier mal die neu angehängte version.

[Pfriemler]

erst morgen. Bin Arbeit.

[frank]

na gut. 

die änderungen sollten "nur" die hm.js fehler beseitigen.
gegen fhemweb.js hilft derzeit wohl nur "attr web longpoll 1".

mit longpoll=websocket konnte ich die fehler teilweise provozieren:
sie sollten, denke ich, nur bei einem exklusiven channel device (DEF 8-stellig) auftauchen, da ich hier den informchannel für longpoll erweitere, um auch die infos vom hauptdevice zu bekommen.

das bedeutet erst noch forschung.

[Pfriemler]

so. hm.js version 20.06.2020 19:00 Uhr:
für die DEF 266A77 (erstes Listing):
Firefox:

hm.js line 123:
TypeError: object.Readings.commState is undefined

Chrome:

hm.js line 123:
Uncaught TypeError: Cannot read property 'Value' of undefined

Also unverändert.


Ähnliche Meldungen bei Unterkanälen, dann aber bei line 115.

edit:
sinnlose Infos gelöscht.

Korrelation erkannt: Die Firefox-meldung bezieht sich ganz konkret auf das reading "commState". Exisitiert dieses nicht im Gerätekanal, gibt es Mecker.
Ein einfaches getConfig löst das Problem.

Bei mir sind insbesondere die lange stabil laufenden oder im Pool liegenden Geräte diesbezüglich nicht aktuell.

[frank]

die hm.js fehler tauchen bei dir immer dann auf, wenn das hauptdevice (noch?) kein reading commState hat.
das muss ich noch umfangreicher abfangen.

übrigens bekomme ich die fhemweb.js fehlermeldungen nur mit websocket plus firefox.
chrome auf android und winxp ist toleranter.

[Pfriemler]

Ja super. Das mit commState haben wir gerade zeitgleich erkannt Erklärung im Post.

chrome auf android und winxp ist toleranter.

Stimmt, Chrome wirft auch auf win10 den fhemweb.js-Fehler gar nicht.

[frank]

fehlendes commState sollte jetzt geschichte sein. 

[Pfriemler]

fehlendes commState sollte jetzt geschichte sein. 

ACK. "Info_unknown" kommt stattdessen.

Dafür habe ich wieder einen neuen:
"hm.js line 45: TypeError: iconCell is null" bzw. "hm.js line 45: Uncaught TypeError: Cannot set property 'innerHTML' of null"
wenn ich nicht in der Device-Ansicht, sondern in einem Raum ein Gerät über webCmd oder devStateIcon schalte.
War auch in der Vorversion schon so, wollte es gerade posten, aber habe noch schnell die neue Version gecheckt.

edit: Nä, warte mal, nicht bei allen Schaltern ... ?
edit: Kann es noch nicht korrelieren. Auf einigen Geräten kommt es, auf anderen nicht.
Keine Abhängigkeit von Schalter/Dimmer, Ein/Mehrkanal, devStateIcon, icon, ... die Unterkanäle eines HM-MOD-RE-8 schalten ohne Fehler ebenso wie HM-LC-Sw1-PCB oder HM-LC-Sw4-DR.
Fehler kommt auch bei nicht-Schalt-Aktionen, wie etwa statusRequest.

[frank]

"hm.js line 45: TypeError: iconCell is null"

die 17:00 uhr version sollte das fixen.

[Pfriemler]

die 17:00 uhr version sollte das fixen.

Aber sowas von.
Schöne Sache jetzt. Großes Lob! Ich (darein schauend wie das Schwein ins Uhrwerk) werde es genießen!
Mittelfristig noch ein passendes SVG - aber das ist ja schnell angepasst.

[frank]

wegen dem fhemweb.js fehler hat rudi heute ein änderung für fhemweb.js eingecheckt.
was sagt deine konsole dazu (menü>extras>web-entwickler>web-konsole)?

meine erfahrungen zum thema: https://forum.fhem.de/index.php/topic,112181.msg1066302.html#msg1066302

[martinp876]

coole sache. Habe mir erwas ähnliches gebaut - für Tablet-UI. Noch bin ich nur semi-zufrieden mit meiner Lösung.
Was ich will ist eine Info über Device-Status/Device-Probleme. Für mich ist Protocol-only zu kurz gesprungen. Allerdings ist die Anwendung mit der Anzeige cool.

Zuerst einmal: Was will ich sehen
- Abstrakt: Status/Alarme/Warnings eines Device welche mir mitteilen: Mit dem Device stimmt etwas nicht - Admin, Hilfe bitte.
- Welche Zustande zählen dazu. In HMInfo gibt es einen Ansatz, die Meldungen zu sammeln. Das sind nur die Alarme - bei der normalen Anzeige braucht es einen Status, also mehr "info"
  - Gruppe "Protokoll" - wird im Reading "commState" abgebildet. Es ist seit kurzen ein Reading, so dass man Events nutzen kann
  - Batterie - gehört in die Kategorie warning
  - alive (actStatus) - kategorie "error"
  - Weitere Readings (siehe HMInfo) sabotageError:off, powerError:ok, overload:off, overheat:off, reduced:off,motorErr:ok, error:none, uncertain:yes, smoke_detect:none, cover:closed

Das ganze in einem Status abzubilden Bedarf einer Priorisierung:
+ So ist Alive sicher Prio 1. Wenn "Dead" ist alles andere egal
+ alle anderen Readings benötigen eine funktionierende Kommunikation. Hierzu zählt: Ist das(oder zumindest ein mögliches) IO funktional? In HMInfo gibt es nun ein "ping" in set "hm commandRequestG ping" mit welchem man prüfen kann, dass das/die Devices ansprechbar sind. Wie immer defensiv - bei RTs wird gewartet bis sie aufwachen
+ So, das Device lebt und wir können kommunizieren - jetzt wird es komplexer
++ es "gab" protokol fehler. Ein Teil der kommandos könnte fehlgeschlagen sein. Bei Registern ist dies manuel zu prüfen (bei Templates kann man es über HMInfo). Zu unterschieden: nur nicht-korrigierte Fehler sind relevant
++ protokol: Pending. In etwa gleicher level - wir müssen noch auf die Übertragung warten
++ Device fehler wie Overload, Power-Error, Motor-Error: Das Device wird nicht das machen was es soll, es hat ein internes Problem
++ Battery: low warning level. Man muss "nur" in absehbarer Zeit die Batterien wechseln.
++ Info: Motor fährt (rollo/Dimmer)
++ green: keine Fehler, kommunikation möglich, alles übertragen

das alles muss abgebildet sein um den "gesundheitszustand" einer Device darzustellen. Wenn grün kann ich sicher sein, dass der Kanal das macht, was ich will.

Zusatz:Config-check ist nicht inkludiert. Ebenso sollte man das Ablöschen der alten Kommunikatiosfehlern betrachten.

=> dann bin ich zufrieden mit der Darstellung

[frank]

Für mich ist Protocol-only zu kurz gesprungen. Allerdings ist die Anwendung mit der Anzeige cool.

das ist auch nur ein erster kleiner appatizer. 

aber unterschätze nicht den informationsgehalt dieser unscheinbaren, kleinen led. es liegt jetzt natürlich auch an dir, ihr noch mehr leben ein zu hauchen.

- wie letztens schon kurz angesprochen, fehlen auf alle fälle noch events für die queues der automatischen getconfigs und statusrequests und was sonst noch in den tiefen von cul_hm schlummert.
falls noch aktionen geplant sind, sollten diese hier auftauchen, finde ich.

- bei CMDs_pending fände ich äusserst hilfreich, wenn es 2 unterschiedliche pendigs gäbe. eins für devices, die unbedingt ein manuelles eingreifen benötigen (config, lazy) und ein 2. pending, das ohne eingriff automatisch abgearbeitet wird.

- eventuell fehlt für fwupdate auch noch ein fehlerevent für commstate. es gibt zwar das reading fwupdate mit fehlerangabe, aber im state stand dann bisher nur FWupdate_done, was nach erfolg aussieht.


in der pipeline ist gerade eine anzeige für configcheck.

ausblick, träume:
letztendlich wäre mein plan in etwa:
vielleicht eine handvoll icons für die zustandsbeschreibung auf deviceebene hier in hm.js
dann zusätzlich eine art widget für hminfo, das einerseits systeminfos darstellt (zb io zustände) und andererseits eine liste der problematischen devices zeigt. jede zeile wäre dann ählich der zustandsanzeige wie im device.

im idealfall ist die deviceliste leer und der rest leuchtet grün.

edit: ein weiteren commstate wunsch ergànzt.

[Pfriemler]

wegen dem fhemweb.js fehler hat rudi heute ein änderung für fhemweb.js eingecheckt.
was sagt deine konsole dazu (menü>extras>web-entwickler>web-konsole)?

Wurde heute beim Update mit eingespielt.

edit: Tatsächlich:
bei manchen Geräten keine Probleme, bei manchen die "connection lost" wie Du beschreibst.
D...d!

Code Auswählen Erweitern

13:28:55.679 Inform-channel opened (websocket) with filter LED_Gong,LED_Gong_Led fhemweb.js:507:13
Firefox kann keine Verbindung zu dem Server unter ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=LED_Gong,LED_Gong_Led;since=1592911724;fmt=JSON&fw_id=2383&timestamp=1592911735677 aufbauen. fhemweb.js:1214:18
13:28:55.686 Inform-channel opened (websocket) with filter LED_Gong,LED_Gong_Led fhemweb.js:507:13
Die Verbindung zu ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=LED_Gong,LED_Gong_Led;since=1592911724;fmt=JSON&fw_id=2383&timestamp=1592911735677 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1214:18
13:28:55.689 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<

edit2: bisher korreliert: Devices werden fehlerfrei dargestellt, Unterkanäle werfen den connection-Fehler.

[frank]

die toolbar bietet neues spielzeug. 

aktuelle testversion im 1. post.

- automatischer configcheck und templateCheck bei  seitenerstellung und refresh.
zur zeit nur manuell.
- die checks sind device spezifisch.

hminfo configCheck zeigt device fehler und template fehler in einem bericht. das icon ist nur für die device fehler zuständig. template fehler werden separat an den registerset links dargestellt.

- icon für configCheck (grün: ok, rot: fehler, weiss: kein configCheck ermittelt)
- wenn die maus auf dem icon ist, wird der configCheck bericht sichtbar.

- die links für die registersetbearbeitung sind nun farbig, wenn templates assigned sind.
- gelb: kein templateCheck erfolgt, grün templateCheck ok, rot: templateCheck zeigt fehler

[martinp876]

Nun werde ich vorsichtig.
Configcheck( welcher template check beinhaltet) kostet schon Performance.bei jedem öffnen einer seite ist mir das zu viel.
Wenn, dann müsste man es intelligenter machen. Das Ergebnis von configcheck abspeichern und nur abrufen. Configcheck automatisch starten, wenn die configuration geändert wird. Da dies bei einem getconfig einer mehrkanaldevice aber zu häufig stattfindet und zu oft getriggert wird sollte es im (doppelten) batch stattfinden. Zu beachten ist, dass auch die peers neu geprüft werden müssen.
Es muss also ein eigener Ablauf erstellt werden.
Beachte: in 95% der Anwendungen eines user wird sich die configuration nicht geändert haben. Fhem mit perl auf pi hat definitiv eine endliche Performance!

Die anzeige der queues ist schön, aber sekundär.

P.s.: attr readingsondead sollte commState beinhalten. Das ist schon einmal ein erster Schritt

[Pfriemler]

Configcheck( welcher template check beinhaltet) kostet schon Performance.bei jedem öffnen einer seite ist mir das zu viel.

Ich habe da weniger ein Problem. hm.js wird ja nur ausgeführt, wenn es in der zuständigen FHEMWEB-Instanz installiert ist. Für meinen ADMIN-Zugang habe ich sowohl das als auch codemirror.js eingebunden, in den Bedienoberflächen ist beides obsolet.
Oder sehe ich da was falsch?

@frank: Läuft hier anscheinend ohne Probleme. Muss jetzt allerdings longpoll=1 setzen, sonst ist der configCheck nicht erfolgreich.
Ist auch sonst jetzt eine lästige Sache. Rudis oder Deine Baustelle?

[frank]

automatischer configcheck:
ich denke, ich werde es so entschärfen, das nur beim "ersten" seitenaufruf automatisch gecheckt wird. weitere checks kann man dann manuell durch klick auf das icon starten.

wenigstens einen automatischen check finde ich schon wichtig, da man ansonnsten eher selten einen check durchführt.

einerseits sehe ich das thema auch eher entspannter wie pfriemler. es passiert ja nur auf der detailseite und der befehl wird zudem nonblocking ausgefürt.
andererseits erzeugt fhem aber auch viele refreshs, wenn man attribute bearbeitet und/oder cmds aus den selectlisten startet. da sind dann die configchecks schon überflüssig.

mal schauen woran man erkennt, dass es sich um den "ersten" seitenaufbau handelt.


firefox-websocket-problem:
das wird noch spannend.
zur zeit entweder firefox/lonpoll=1 oder websocket/chrome.

[Pfriemler]

@frank: Läuft hier anscheinend ohne Probleme. ...

Nein, ganz und gar nicht. Die eigentliche Funktion der Register- und Templatebearbeitung ist jetzt kaputt, das Fenster bleibt leer.
Wieder mal nur bei mir?

edit: Rückspielen der Version vom 21.6. -> Register funzen wieder.

[frank]

Nein, ganz und gar nicht. Die eigentliche Funktion der Register- und Templatebearbeitung ist jetzt kaputt, das Fenster bleibt leer.

ja ja..., wenn man auf dem weg zum einchecken denkt, dass man schnell nur noch ein paar "kosmetische" korrekturen erledigen kann. denkste. 

update im beitrag.


ist das longpoll=websocket eigentlich irgendwo voraussetzung?
seit anbeginn war bei mir longpoll=1 eingestellt und hat immer funktioniert.
noch erkenne ich eher nachteile als vorteile. 

aber sicherlich wird irgendwann auch firefox/websocket funktionieren.

[Pfriemler]

Der Teufel steckt immer im Detail
Sieht jetzt besser aus.

websocket scheint mir eine moderne und letztlich eher resourcenschonendere und schnellere Ablösung für das alte longpoll zu sein. Mit longpoll=websocket und Firefox hatte ich bis vor einigen Tagen nirgends Probleme.

[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


[martinp876]

Kurze zwischen antwort, da ich aktuell nicht ans system komme,
Configcheck muss nach reboot aufgerufen werden. War in der ersten Version nicht der Fall. Sollte aber schon aktiv sein.

Dass commstate nicht stimmt und die Details zum check nicht dargestellt werden darf nicht sein, werde ich suchen.

[martinp876]

1. protState: unknown

protState ist gelöst. Nun, nach deinem letzten Reboot wurde das Device noch nicht angesprochen.
Ich denke ich werden nach Reboot protState und commState auf "cleared" setzen. CMDs-done ist unlauter.

2. configuration check: TmplChk

ist geklärt

wäre es nicht sinnvoll nach restart einen automatischen configCheck zu schedulen

ist drin

3. es fehlen in deviceInfo weiterhin

ok, das waren die Zeilenumbrüche.

[Wzut]

@frank,
wie sind denn eigentlich die Grenzwerte für rot-gelb-grün beim RSSI Icon festgelegt ?
Ich wundere mich etwas das ich bei -55 schon gelb habe ....

[frank]

hi wzut,

ich habe die bereiche erst einmal wie in hminfo gewählt.
die farbtabelle ist im ersten post und entscheidend ist der min wert. gelb liegt im bereich -60 bis -80.

zuerst hatte ich den avg ausgewertet.
aber bei devices, die eventuell nur phasenweise störungen (zb zeitweise geschlossene türen) durch schlechte rssi haben, würden eventuell unerkannt bleiben.

um so etwas näher zu untersuchen, löscht man durch klick auf das icon alle rssi und wartet ab, ob bei der nächsten störung wieder schlechte min rssi vorhanden sind.

ich habe aber auch schon daran gedacht, die nicht grünen bereiche etwas kleiner zu wählen und gelb zb erst ab -70 oder -75 zu starten.

andererseits ist gelb bei anderen icons eigentlich noch keine warnung. zb cmds_processing ist gelb und zeigt eher eine aktivität. gelb gibt es auch sehr selten.

was denkst du denn?

[Wzut]

ah sorry , die Tabelle im ersten Post habe ich übersehen. Wenn die Wertebereiche die gleichen sind wie in HMinfo sind ist das schon ok.
Gedanklich war ich natürlich auch direkt auch bei avg / ist , daher auch die Verwunderung, aber der min Wert von -62 wird nun in Stein gemeißelt sein bis zum nächsten FHEM Neustart. D.h. egal wie gut die Verbindung jetzt noch werden sollte, gelb wird bleiben.
IMHO wäre avg oder ist logischer.

[papa]

Mit -60 wären bei mir fast alle im Warning-Bereich. Ich habe für mein RSSI-Readingsgroup Gelb ab -80 & Rot ab -85. Ist vielleicht etwas eng - aber auch mit -80 sind mir noch keine Empfangsprobleme aufgefallen.

[marvin78]

-80 läuft in der Regel top und ich denke, dass ich trotz 7 IODevs im Haus und außen, trotzdem etwa 25% der Geräte in diesem Bereich sehr zuverlässig betreibe.

[frank]

ok, scheinbar verwirrt das auftauchen von gelb (habe mich auch schon dabei erwischt).

ich habe den farbcode mal so angepasst, dass bis -80 grün ist.
rot weiterhin ab -100, um mit der hminfo fehlermeldung kompatibel zu bleiben.

das grundlegende problem einer rssi "bewertung" ist, dass jeder gemessene rssi, egal wie schlecht er auch ist, immer von einer erfolgreichen message kommt. somit können rückschlüsse auf probleme auch immer nur spekulationen sein.
zusätzlich "kaschiert" cul_hm auch ziehmlich gut kleinere probleme mit entsprechenden wiederholungen.

aber der min Wert von -62 wird nun in Stein gemeißelt sein bis zum nächsten FHEM Neustart. D.h. egal wie gut die Verbindung jetzt noch werden sollte, gelb wird bleiben.
IMHO wäre avg oder ist logischer.

wie gesagt, du musst nicht bis zum restart warten. ein klick auf das icon löscht die gesammelten rssi, für dieses device.

avg halte ich nach wie vor für ziehmlich "nichts sagend" oder schwammig.
bei einer guten installation mit intakter hardware sollten min, max und avg idealerweise wenig von einander abweichen. probleme beginnen, wenn überhaupt, mit schlechten rssi werten. da auch gelegentlich schlechte rssi probleme verursachen können, halte ich den min wert der rssi-statistik dafür am aussagekräftigsten.

ist-werte sind normal nicht vorhanden und wären natürlich das beste mittel, um akute probleme sichtbar zu machen.
daher habe ich auch im hinterkopf eine zusätzliche anzeige einzubauen, die bei vorhandenem "attr rssiLog" sichtbar wird und dann in realtime entsprechend signalisiert.


also update im ersten post.

[frank]

@Pfriemler
wegen connection lost: hier mal eine neue version zum testen.


edit:
vorläufige version entfernt, neue version im ersten post.

[Pfriemler]

Das Stetige am mir ist meine Unstetigkeit. Oder so ähnlich 
Gerade erst heruntergeladen, viele Änderungen (oink, oink).
Ist Installiert und wird beobachtet. Bisher keine Meldung.

Habe gezielt nach schlechten rssi gesucht und mich gewundert, warum viele eigentlich gut erreichbare Geräte gelb sind.
-> Ist das wirklich volle Absicht, dafür die min-Werte heranzuziehen? Im Betrieb reicht dann ein mal nicht erreichbares optimales IO, um temporär schlechte Verbindung und damit auch schlechte min-rssi zu bekommen. Gut als Warnung "da ist ... " oder eben "da war mal ein Problem". Aber wenn das Problem schon lange nicht mehr besteht ...?
jm2c.

edit: sollte ich vll. gelegentlich die rssi händisch löschen (hminfo), gerade nach solchen Vorfällen?
edit2: geht ja total einfach, siehe https://forum.fhem.de/index.php/topic,112156.msg1073567.html#msg1073567. Da wurde das ja auch schon diskutiert. ACK.

[Pfriemler]

neues vom "connection lost": beim Aufruf von "hminfo", sowohl in FF als auch Chrome. In Chrome allerdings verschwindet die Meldung nach 5 s, während sie im FF immer wieder aufpoppt.
Sonst beim Firefox immer mal regelmäßig bei diversen Devices gesehen, jetzt aber nie mir. Ein Erfolg, immerhin.

Bin leider ahnungslos, was ich an Hilfen liefern könnte.

[frank]

Sonst beim Firefox immer mal regelmäßig bei diversen Devices gesehen, jetzt aber nie mir. Ein Erfolg, immerhin.

habe ich schon erwartet. 

nutzt du wlan, oder "langsame" hardware?
ein neuladen der seite hilft dann aber, oder?

HMinfoTools macht eventuell zicken, aber ein update ist in arbeit.

edit: patchvorschlag gelöscht.

[Pfriemler]

nutzt du wlan, oder "langsame" hardware?

nein, und ein i5-3330 und Win10 auf SSD ist zwar nicht das frischeste, aber von "langsam" wirklich weit entfernt.
Der RPi3 ist auch an der Strippe.
An der Theorie könnte aber was dran sein ... auf dem Surface Pro 5 ( i5-7300U) gibt es auch im FF keine Meldung.

ein neuladen der seite hilft dann aber, oder?

hatte ich natürlich längst versucht. Bei Chrome kommt "connection lost" dann wieder - genau einmal.
Am FF ändert das nichts.

deswegen kommentiere mal diese beiden zeilen in fhemweb.js aus (1103):

Morgen, wenn der "lahme" PC wieder an ist.

Warte hier auf Edit von morgen.

btw: ich nehme Deine [cul_hm] im Betreff höchsterfreut zur Kenntnis

[frank]

neues vom "connection lost": beim Aufruf von "hminfo", sowohl in FF als auch Chrome. In Chrome allerdings verschwindet die Meldung nach 5 s, während sie im FF immer wieder aufpoppt.
Sonst beim Firefox immer mal regelmäßig bei diversen Devices gesehen, jetzt aber nie mir. Ein Erfolg, immerhin.

bei hminfo hilft natürlich nur eine verbesserung von HMinfoTools.js. 
probiere die version aus dem anhang.

Bin leider ahnungslos, was ich an Hilfen liefern könnte.

HMinfoTools unter firefox ist am sensibelsten.

hier kannst du mal die web konsole öffnen und alle fehlermeldungen bis auf css wie im pic aktivieren.
in den einstellungen (zahnrad) noch zeitstempel auswählen.

dann einmal reload, vielleicht 10s warten, mit rechter maustaste in die meldungen klicken und über "meldungen exportieren nach zwischenablage" hier posten.


edit: file entfernt, weiter unten gibt es eine neuere version.

[frank]

edit: patchvorschlag entfernt.

[Pfriemler]

f..k ... Antwort fast fertig, einmal falsch geklickt, alles weg. Also nochmal:

Sorry, gestern war PC-freier Tag. Aber jetzt.

Habe die Prozedur mit altem HMInfoTools.js und ungepatchter fhemweb.js erst einmal geübt. Fehler gibt es nur, wenn ich hminfo ohne Konsole aufrufe und die Konsole erst danach öffne. Dann kann ich sowas wie hier herausziehen:

Code Auswählen Erweitern

11:54:29.609 11:54:29.609 ERRMSG:< fhemweb.js:517:13
11:54:29.610 11:54:29.611 Inform-channel opened (websocket) with filter hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1 fhemweb.js:517:13
11:54:29.611 Firefox kann keine Verbindung zu dem Server unter ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1;since=1614596034.548;fmt=JSON&fw_id=161124&timestamp=1614596069609 aufbauen. fhemweb.js:1250:18
11:54:29.612 11:54:29.613 Inform-channel opened (websocket) with filter hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1 fhemweb.js:517:13
11:54:29.613 Die Verbindung zu ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1;since=1614596034.548;fmt=JSON&fw_id=161124&timestamp=1614596069609 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1250:18
11:54:29.613 11:54:29.613 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< fhemweb.js:517:13
11:54:29.613 Firefox kann keine Verbindung zu dem Server unter ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1;since=1614596034.548;fmt=JSON&fw_id=161124&timestamp=1614596069612 aufbauen. fhemweb.js:1250:18
11:54:29.614 11:54:29.615 HMinfoTools: "Connection lost" detected! (011111) fhemweb.js:517:13
11:54:29.615 11:54:29.615 HMinfoTools: close and open informchannel fhemweb.js:517:13
11:54:29.635 Die Verbindung zu ws://192.168.178.108:8088/fhem?XHR=1&inform=type=status;filter=hminfo,8BattSensor1,EnMonitorHS2,EnMonitorStecker3,HM_190D0F,HM_THS_Garage,HM_THS_OGWest,TDiffSens0,TDiffSens1,EnMonitorStecker4,FK_KGBad,HM_2E2125,HM_3710C0,HM_6F08AD,HM_UWS1,HM_UWS2,LEDDimmer4,Lightbox1,RegenSensor1,Rundumleuchte,HM_266A77_Dim,HMSw2Terrasse,HM_6F08C0,Hutschienen_4x_Schalter_1,LEDDimmer3,SCo_Kueche,EnMonitorStecker3_Sw,HM_UniDimPl_1_Dim,HM_UniDimPl_1_Dim_V_01,HM_266A77,HM_UniDimPl_1;since=1614596034.548;fmt=JSON&fw_id=161124&timestamp=1614596069612 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1250:18
11:54:29.684 GEThttp://192.168.178.108:8088/fhem?detail=hminfo
[HTTP/1.1 200 OK 1312ms]
Mit der letzten Zeile allerdings wird die Seite wohl reloaded - und danach gab es keine Fehler mehr, solange die Konsole geöffnet war. Oink. Auch wenn ich die Seite manuell reloade - kein Fehler.

gestrige HMInfoTools, immer noch kein patch im fhemweb.js:
Keine Fehler mehr.

alte HMInfoTools, gepatchte fhemweb.js (Version fhemweb.js 23453 2021-01-01 18:10:12Z - bei mir ist die von Dir bezeichnete Zeile 1103 allerdings die 1094 (verwende Notepad++, da stimmen die Zeilennummern von Fehlermeldungen eigentlich immer)... FHEM meldet hier den Fehler:

Code Auswählen Erweitern

fhemweb.js line 1095: TypeError: FW_pollConn is undefined
wirkt auf mich logisch, wenn ein Objekt geschlossen wird, dessen Vorhandensein in der auskommentierten Zeile abgefragt wird ... ? ... oink?

btw: ich kopiere die .js bei geschlossenen Tabs nach FHEM und rufe danach hminfo über Lesezeichen auf. Dabei verhält sich der erste Aufruf immer noch wie der Stand vor der .js-Kopie, ich vermute Browsercache. Erst nach einem manuellen Reload bleibt das Verhalten reproduzierbar.
edit: Das hat frank auch schon genau so beschrieben in https://forum.fhem.de/index.php?action=post;quote=1071906;topic=112825.0;last_msg=1084127

Bleibe jetzt bei original fhemweb.js und neuerer HMInfoTools.js. und freu mich ...

[frank]

mit aktueller fhemweb.js kommst du vielleicht auf die selben zeilen. 

FW_version["fhemweb.js"] = "$Id: fhemweb.js 23811 2021-02-23 21:04:49Z rudolfkoenig $";

1094 in deiner version ist schon richtig.
die fehlermeldung zeigt aber, dass du beim patchen irgend etwas falsch gemacht hast.

ohne den fhemweb patch hatte ich halt hin und wieder diese endlose "connection lost" orgie.
das hängt eventuell auch vom wetter ab. 

Bleibe jetzt bei original fhemweb.js und neuerer HMInfoTools.js. und freu mich ...

dann wirst du die orgie sicherlich auch irgendwann noch mal sehen.
seltsam finde ich eigentlich, dass wir scheinbar die einzigen sind, die dieses phänomen zu gesicht bekommen.


ps: du hast ganz schön viele devices mit problemen, sehe ich gerade.

[Pfriemler]

mit aktueller fhemweb.js ...

updates mache ich eigentlich nur sehr gelegentlich und das letzte war gerade erst vor ein paar Tagen ... dachte ich ...

die fehlermeldung zeigt aber, dass du beim patchen irgend etwas falsch gemacht hast.

Wüsste nicht was. Ich sollte doch aus "if(FW_pollConn) FW_pollConn.close();" lediglich ein bedingungsloses "FW_pollConn.close();" machen, oder? Nur funktioniert das wenn das uninitialisiert ist o.ä.?

Ich warte geduldig auf die nächste "Orgie". Stand jetzt kommt einfach nix mehr.

ps: du hast ganz schön viele devices mit problemen, sehe ich gerade.

Schönes Testmaterial, nicht? Du solltest erst mal meinen peerCheck sehen  Dabei funktioniert alles, FHEM weiß es nur nicht...

Das meiste sind Geräte, die aktuell offline sind wegen Unbenutzung (Weihnachtskram, Mess-Zwischenstecker) oder noch zu erfolgendem Einbau (manches wurde auch gekauft, aber nun doch nicht gebraucht, aber noch nicht verkauft, anderes ist nur provisorisch angelernt/gepeert und die Register unerreichbar, weil ich autoReadReg noch default gelassen habe) etc. Die "Rundumleuchte" ist ein temporär benutzter HM-LC-Sw1-Ba-PCB mit 3V Betriebsspannung (das ist dem immer zu wenig, aber er wurde auf 3-V-Betrieb umgebaut (hinter Eingangsregler gespeist) und läuft deswegen super, ich muss nur noch die Batterieerkennung "hacken", damit Ubatt wieder Pegel bekommt), ein Dimmer aus der Reserve wurde zum Steuern einer LED-Leuchte kurz einbebaut und hatte Overload (habe kurzerhand den zweiten Reservedimmer eingebaut und war noch nicht dazu gekommen zu untersuchen, ob meine low-energy-hacks das verursacht haben könnten), was der "HM_UniDimPl_1_Dim" aber an sabotageAttack zu meckern hat ist mir gänzlich unerklärlich, hier gibt es weit und breit keinen anderen HM-User und ich habe auch schon ewig keine Versuche mit CCU etc gemacht geschweige denn dabei dieses Gerät verwendet ...
Die Chance, dass diese "Pseudofehlerliste" absehbar kürzer wird ist eher gering.

[frank]

Wüsste nicht was. Ich sollte doch aus "if(FW_pollConn) FW_pollConn.close();" lediglich ein bedingungsloses "FW_pollConn.close();" machen, oder?

genau.
da fällt mir erst einmal weiter nichts zu ein. eventuell noch ein sporadisches problem mit deiner deiner HMinfoTools version. ich behalte es mal im hinterkopf.

was der "HM_UniDimPl_1_Dim" aber an sabotageAttack zu meckern hat ist mir gänzlich unerklärlich

ich hatte letztens auch zu grübeln:
da hatte ich einen mit fhem gepairten sensor resettet, der aber weiterhin in fhem vorhanden war.
anschliessend habe ich diesen sensor mit einem dimmer direkt gepeert, den fhem nicht kannte.
die msgs vom dimmer an den sensor hat fhem natürlich bemerkt und als angriff angesehen. 
da gab es dann aber ein zusätzliches attack reading im sensor, dass die hmid des dimmers enthielt.

[frank]

zum jubiläum von 70 downloads mal ein update von hm.js im ersten post.

einige verbesserungen, optimierungen und fehlerbeseitigungen.
(auch gegenüber der vorläufigen version aus antwort #53)

[Pfriemler]

da fällt mir erst einmal weiter nichts zu ein. eventuell noch ein sporadisches problem mit deiner deiner HMinfoTools version. ich behalte es mal im hinterkopf.

Äh ... wir redeten doch gerade von einem Problem, verursacht durch eine Änderung von mir in fhemweb.js?

anschliessend habe ich diesen sensor mit einem dimmer direkt gepeert, den fhem nicht kannte.

Das ist ja nachzuvollziehen und logisch. Ha. Meine ellenlange peerCheck-Fehlerliste hängt ja unter anderem damit zusammen, dass die Informationen aus lange angelegten, aber länger nicht per getConfig aktualisierten Geräten mittelfristig wegzudiffundieren scheinen. Wenn da FHEM eine Info abhanden gekommen ist, sieht der peer natürlich wie ein Attack aus.
Ist hier aber nicht der Fall gewesen - die peers waren bekannt.

zum jubiläum von 70 downloads mal ein update von hm.js im ersten post.

Da stand bis eben noch 0 Downloads 

[frank]

Äh ... wir redeten doch gerade von einem Problem, verursacht durch eine Änderung von mir in fhemweb.js?

genau.
wenn du behauptest, alles richtig gemacht zu haben, muss die fehlermeldung ja eine andere ursache gehabt haben.

hm.js und hminfotools.js nutzen funktionen aus fhemweb.js, um longpoll für mehr devices zu ermöglichen, als normalerweise vorgesehen sind. denn auf jeder detailseite kommen über longpoll von haus aus nur die events, die zum device der detailseite gehören.

dazu muss die aktuelle default-longpoll verbindung, die fhem immer öffnet, zunächst geschlossen werden, um danach die erweiterte longpoll verbindung zu öffnen. firefox mit websocket reagiert hierbei sehr empfindlich, wenn versucht wird die 1. verbindung zu schliessen, wenn diese noch nicht vollständig etabliert war.
wenn dadurch auch noch der seitenaufbau verzögert wird, schlägt eventuell zusätzlich der connection-lost-mechanismus von fhem zu, der nun ebenfalls versucht die verbindung zu erneuern.
im ungünstigsten fall kommt es dann zu einer dead-loop.

langsamer seitenaufbau bei hminfo mit vielen entities, die fehler zeigen, kann schon mal ein connection lost zeigen. allerdings sollte es dann nicht zur dead-loop führen.
daher habe ich als notlösung in hminfotools ein seitenreload eingebaut, der nach 5 connection-lost ausgelöst wird.



attack:
es gibt einen kleinen, feinen unterschied zwischen hm.js und hminfotools.js.
hm.js zeigt attack, sobald das attack reading existiert, also auch uralte attacks.
ein klick aufs icon löscht das reading (set clear attack).

hminfo zeigt default "nur" attacks seit dem letzten fhem restart an (iCRI__protocol) wie bei allen protokoll fehlern.
da mich auch "alte" attacks interessieren, habe ich das attr sumERROR in hminfo erweitert:

Code Auswählen Erweitern

sabotageAttack_ErrIoAttack_cnt:ok


tip:
jeder sollte eigentlich auch attr sumERROR mit

Code Auswählen Erweitern

cfgState:ok
erweitern, um alle entities zu sehen, die durch den automatischen hminfo configCheck auffällig werden

[Pfriemler]

wenig neues von den "connection losts":

... firefox mit websocket reagiert hierbei sehr empfindlich, wenn versucht wird die 1. verbindung zu schliessen, wenn diese noch nicht vollständig etabliert war.
wenn dadurch auch noch der seitenaufbau verzögert wird, schlägt eventuell zusätzlich der connection-lost-mechanismus von fhem zu, der nun ebenfalls versucht die verbindung zu erneuern.
im ungünstigsten fall kommt es dann zu einer dead-loop.

Klingt plausibel und erklärt die meisten meiner Beobachtungen gut.
Es gibt noch einen recht zuverlässigen Mechanismus zum Auslösen von connection losts: Geräte versuchen zu bedienen bevor die Seite vollständig geladen wurde. Dead loops hatte ich nur noch ganz wenige, ein einfacher Seitenreload hat sie sämtlich behoben. Diese Dauerhänger sind jedenfalls komplett weg.
Insgesamt ist es für mich so viel besser brauchbar. Ich bin entzückt!

[frank]

Dead loops hatte ich nur noch ganz wenige, ein einfacher Seitenreload hat sie sämtlich behoben. Diese Dauerhänger sind jedenfalls komplett weg.

das betrifft jetzt aber nur hminfotools, oder?

1. wenn ja: der automatische reload nach 5/6 lost kommt und funktioniert auch?

2. wenn nein:
bei hm.js kann ich bei mir keine fehler mehr in der webkonsole sehen. eine geänderte websocket verbindung wird auch nur bei einer "echten" channel entity initialisiert, um die zusätzlichen events des hauptdevices zu bekommen.
wenn connection lost erst später, nach einem erfolgreichen seitenaufbau auftaucht, ist die verbindung scheinbar wirklich kurz tot.

[Pfriemler]

Nein, die connection losts kamen - nur noch extrem selten - bei Detailseiten von HM-Geräten. Ich könnte mir aber gut vorstellen, dass sie so gut wie nichts mehr mit hm.js zu tun haben. Das wird dann wirklich der Ungeduld des FF zuzuschreiben sein.
Der Reload-Mechanismus war mir schon bei den Versuchen mit der Webkonsole aufgefallen - ich habe mich gewundert, was nach einem Rudel Fehlermeldungen denn plötzlich einen reload initiiert.
Und auch da war schon auffällig, dass (neben dem manuellen auch) dieser automatische Reload das Gezeter um die connection lost beeendete.

Wie ich schon sagte: Für mich ist es gerade optimal.

Was anderes: Hattest Du mal darüber nachgedacht, bei schwachen Batterien in HmInfoTools auch ein entsprechendes Symbol zu verwenden oder wird das zu kompliziert? in hm.js, sehe ich gerade, ist es ja schon...

[frank]

Wie ich schon sagte: Für mich ist es gerade optimal.

vielleicht noch etwas optimaler mit der angehängten HMinfoTools.js?
vielleicht ändert sich auch nichts, ist zumindestens mein aktueller stand.

Was anderes: Hattest Du mal darüber nachgedacht, bei schwachen Batterien in HmInfoTools auch ein entsprechendes Symbol zu verwenden oder wird das zu kompliziert? in hm.js, sehe ich gerade, ist es ja schon...

genau, hm.js kennt drei unterschiedliche icons mit unterschiedlichen farben.
das wurde aus performance gründen aber bisher nicht in hminfotools übernommen.
mit einem optimierten kombi-icon aber irgendwann einmal denkbar.

edit: HMinfoTools.js entfernt, da neues update existiert.

[frank]

moin,
neuer name und neue version.

die status icons werden nun über HMinfoTools.js in HMdeviceTools.js (neuer name von hm.js) integriert.
das erspart eine menge doppelten code und das verhalten der icons ist immer identisch.
also die neue version von HMdeviceTools.js von hier installieren: https://forum.fhem.de/index.php/topic,106959.0.html