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 (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.
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:
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.
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.
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.
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.
schau mal hier: https://forum.fhem.de/index.php/topic,97586.msg908277.html#msg908277 (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.
ZitatStatt 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.
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
hm.js line 115:
TypeError: data.Results[0].Readings.commState is undefined
und
fhemweb.js line 1059:
TypeError: FW_pollConn is undefined
hier funktioniert die Anzeige dann aber ...
orange etwas oranger im Beitrag weiter oben neu angehangen.
Zitathm.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.
Zitatfhemweb.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?
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
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.
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 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
hm.js line 121:
Uncaught TypeError: Cannot read property 'Value' of undefined
longpoll ist "websocket".
Jetzt du.
probier mal die neu angehängte version.
erst morgen. Bin Arbeit.
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.
so. hm.js version 20.06.2020 19:00 Uhr:
für die DEF 266A77 (erstes Listing):
Firefox:
Zitathm.js line 123:
TypeError: object.Readings.commState is undefined
Chrome:
Zitathm.js line 123:
Uncaught TypeError: Cannot read property 'Value' of undefined
Also unverändert.
:o
Ä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.
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.
Ja super. Das mit commState haben wir gerade zeitgleich erkannt :-) Erklärung im Post.
Zitat von: frank am 21 Juni 2020, 13:14:44
chrome auf android und winxp ist toleranter.
Stimmt, Chrome wirft auch auf win10 den fhemweb.js-Fehler gar nicht.
fehlendes commState sollte jetzt geschichte sein. :)
Zitat von: frank am 21 Juni 2020, 15:37:49
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.
Zitat"hm.js line 45: TypeError: iconCell is null"
die 17:00 uhr version sollte das fixen.
Zitat von: frank am 21 Juni 2020, 17:15:15
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.
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 (https://forum.fhem.de/index.php/topic,112181.msg1066302.html#msg1066302)
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
ZitatFü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.
Zitat von: frank am 22 Juni 2020, 16:11:37
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!
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×tamp=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×tamp=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.
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
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
Zitat von: martinp876 am 23 Juni 2020, 21:22:48
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?
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.
Zitat von: Pfriemler am 23 Juni 2020, 21:29:42
@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.
Zitat von: Pfriemler am 24 Juni 2020, 00:29:54
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.
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.
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.
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:
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.
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.
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)
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. ;)
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.
Zitat von: martinp876 am 29 Juni 2020, 15:29:32
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.
ZitatConfig-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.
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
Zitat von: martinp876 am 30 Juni 2020, 18:54:49
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:
template mismatch
SwitchES01: 0:0-> failed
confBtnTime :5 should permanent bei "get deviceInfo" fehlt die letzte zeile zum value:
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-> failed2. 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:
set hminfo templateDef tplCheck confBtnTime "test" confBtnTime:p0
ok, ok.... war keine Heldentat :(
Ich habe die Automatik überarbeitet
das sieht schon viel besser aus.
hier mal die 2 versuche mit neum cul_hm im eventmonitor:
----- 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.
so update again.
Zitat"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.
ZitatDas 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.
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. :)
@martin
aktuell gibt es 3 probleme mit "get deviceInfo" im zusammenspiel mit den readings commState und cfgState.
a. nach fhem restart:
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:
configCheck done:
template mismatch
Thermostat.OZ: 0:0-> failed
backlOnTime :20 should 15
bei deviceInfo fehlen die infos über die register unterschiede:
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
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.
Zitat1. 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.
Zitat2. configuration check: TmplChk
ist geklärt
Zitatwäre es nicht sinnvoll nach restart einen automatischen configCheck zu schedulen
ist drin
Zitat3. es fehlen in deviceInfo weiterhin
ok, das waren die Zeilenumbrüche.
@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 ....
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?
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.
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.
-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.
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.
Zitataber 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.
@Pfriemler
wegen connection lost: hier mal eine neue version zum testen.
edit:
vorläufige version entfernt, neue version im ersten post.
Das Stetige am mir ist meine Unstetigkeit. Oder so ähnlich ;D
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.
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.
ZitatSonst 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.
Zitat von: frank am 27 Februar 2021, 18:28:52
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.
Zitatein 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.
Zitatdeswegen 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 :-)
Zitat von: Pfriemler am 27 Februar 2021, 18:01:19
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.
ZitatBin 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.
edit: patchvorschlag entfernt.
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:
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×tamp=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×tamp=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×tamp=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×tamp=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:
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 ...
mit aktueller fhemweb.js kommst du vielleicht auf die selben zeilen. 8)
ZitatFW_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. :)
ZitatBleibe 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.
Zitatmit aktueller fhemweb.js ...
updates mache ich eigentlich nur sehr gelegentlich und das letzte war gerade erst vor ein paar Tagen ... dachte ich ...
Zitatdie 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.
Zitatps: du hast ganz schön viele devices mit problemen, sehe ich gerade.
Schönes Testmaterial, nicht? Du solltest erst mal meinen peerCheck sehen ;D 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.
ZitatWü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.
Zitatwas 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.
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)
Zitat von: frank am 01 März 2021, 14:55:08
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?
Zitatanschliessend 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.
Zitat von: frank am 01 März 2021, 16:16:13
zum jubiläum von 70 downloads mal ein update von hm.js im ersten post.
Da stand bis eben noch 0 Downloads ;D
ZitatÄ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:
sabotageAttack_ErrIoAttack_cnt:oktip:
jeder sollte eigentlich auch attr sumERROR mit
cfgState:okerweitern, um alle entities zu sehen, die durch den automatischen hminfo configCheck auffällig werden
wenig neues von den "connection losts":
Zitat von: frank am 02 März 2021, 11:48:57
... 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!
ZitatDead 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.
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...
ZitatWie 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.
ZitatWas 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.
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 (https://forum.fhem.de/index.php/topic,106959.0.html)