HM-LC-SW1-FM wird als HM-LC-SW2-FM erkannt

Begonnen von gestein, 01 Dezember 2018, 00:00:27

Vorheriges Thema - Nächstes Thema

Pfriemler

Umso schlimmer, dass es jetzt alle betrifft ...  :-\

Yep, ich habe aber kein Update gemacht, sondern die von Martin vor ein paar Tagen hier experimental eingestellte Version ausprobiert.
Die scheint jetzt etwas vorschnell den Weg ins SVN gefunden zu haben, nachdem die ersten Tests noch recht vielversprechend aussahen ...
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

frank

aber martin wohl, da es bereits offiziell ein attr modelForce zu geben scheint.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

@pfriemler
sag mal, hast du deinen beitrag #45 editiert?
bei meiner antwort #46 habe ich nur den ersten absatz aus #45 gesehen, auch ohne die fette überschrift. allerdings sehe ich nun keinen hinweis, dass du #45 editiert hättest.

ich bin total verwirrt und das nicht zum ersten mal.
muss ich dringend zum arzt?  :-[
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Pfriemler

Ja hatte ich.
Nein, mit Dir ist alles gut.
Wenn man seinen eigenen Beitrag innerhalb der ersten Minute ändert, kommt der Hinweis auf die Änderung nicht.
Ich profitiere sehr davon als Zu-Schnell-Absender  ;D
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

Habe noch einen Update eingestellt.
Bei virtuellen devices gab es noch ein Problem. Und ein paar weitere Details

sensorle

Hallo,
also bei mir wissen auch mit dem neuen Update (und anschließendem Neustart) die Devices nicht mehr welches Model sie sind.

Als Beispiel der Auszug aus der FHEM.cfg vor und nach dem Update für einen Switch

Vor dem Update:
define LichtFlurEG CUL_HM 1F254C
attr LichtFlurEG IODev myHmUART
attr LichtFlurEG autoReadReg 4_reqStatus
attr LichtFlurEG expert 2_raw
attr LichtFlurEG firmware 1.9
attr LichtFlurEG model HM-LC-SW1-FM
attr LichtFlurEG peerIDs 00000000,1F254C01,20B84201,6224C801,
attr LichtFlurEG room FLurEG,CUL_HM
attr LichtFlurEG serialNr KEQ0034276
attr LichtFlurEG subType switch
attr LichtFlurEG webCmd statusRequest:toggle:on:off
define FileLog_LichtFlurEG FileLog /media/usb/LichtFlurEG-%Y.log LichtFlurEG
attr FileLog_LichtFlurEG logtype text
attr FileLog_LichtFlurEG room CUL_HM


nach dem Update
define LichtFlurEG CUL_HM 1F254C
attr LichtFlurEG .mId 0004
attr LichtFlurEG IODev myHmUART
attr LichtFlurEG autoReadReg 4_reqStatus
attr LichtFlurEG expert 2_raw
attr LichtFlurEG firmware 1.9
attr LichtFlurEG model HASH(0x1b42458)
attr LichtFlurEG peerIDs 00000000,1F254C01,20B84201,6224C801,
attr LichtFlurEG room FLurEG,CUL_HM
attr LichtFlurEG serialNr KEQ0034276
attr LichtFlurEG subType
attr LichtFlurEG webCmd statusRequest:toggle:on:off
define FileLog_LichtFlurEG FileLog /media/usb/LichtFlurEG-%Y.log LichtFlurEG
attr FileLog_LichtFlurEG logtype text
attr FileLog_LichtFlurEG room CUL_HM


attr LichtFlurEG model HASH(0x1b42458)

Mache ich was falsch oder liegts am Update?

Danke,
Jürgen

LuckyDay

da es von 16Uhr heute ist, mußt du aus dem SVN holen , oder bis morgen fruh nach 8Uhr warten

sensorle

Hallo Hary,

Ooops, das wusste ich nicht.
Habs eben aus dem SVN geholt.

Nach dem Neustart sind alle Devices noch wie sie sein sollten.

Wenn ich jetzt allerdings versuche meinen fälschlicherweise als HM-LC-Sw2-FM erkannten Schalter mit
attr LichtDusche modelForce HM-LC-SW1-FM
als HM-LC-SW1-FM zu deklarieren kommt die Meldung
invalid model name:HM-LC-SW1-FM. Please check options

mache ich noch was falsch?

Danke
Jürgen


sensorle

Habe heute morgen noch mal ein komplettes Update durchgeführt (gestern Abend hatte ich nur die 10_CUL_HM.pm ersetzt).
Jetzt funktioniert modelForce!
Meine HM-LC-SW1-FM der sich fälschlicherweise als HM-LC-SW2-FM meldet (mit 2 Kanälen) wird nach
attr modelForce HMxxxx HM-LC-SW1-FM
ein Switch mit nur einem Kanal zur Auswahl.

Von einem echten HM-LC-SW1-FM unterscheidet er sich aber noch.

Auszug der fhem.cfg für einen echten HM-LC-SW1-FM:
define LichtFlurEG CUL_HM 1F254C
attr LichtFlurEG .mId 0004
attr LichtFlurEG IODev myHmUART
attr LichtFlurEG autoReadReg 4_reqStatus
attr LichtFlurEG expert 2_raw
attr LichtFlurEG firmware 1.9
attr LichtFlurEG model HM-LC-SW1-FM
attr LichtFlurEG peerIDs 00000000,1F254C01,20B84201,6224C801,
attr LichtFlurEG room FLurEG,CUL_HM
attr LichtFlurEG serialNr KEQ0034276
attr LichtFlurEG subType switch
attr LichtFlurEG webCmd statusRequest:toggle:on:off
define FileLog_LichtFlurEG FileLog /media/usb/LichtFlurEG-%Y.log LichtFlurEG
attr FileLog_LichtFlurEG logtype text
attr FileLog_LichtFlurEG room CUL_HM


Auszug der .cfg für den mit modelForce geänderten HM-LC-SW2-FM
define LichtFlurEG CUL_HM 1F254C
define LichtDusche CUL_HM 65C6E2
attr LichtDusche .mId 0009
attr LichtDusche IODev myHmUART
attr LichtDusche autoReadReg 4_reqStatus
attr LichtDusche expert 2_raw
attr LichtDusche firmware 2.8
attr LichtDusche model HM-LC-SW1-FM
attr LichtDusche modelForce HM-LC-SW1-FM
attr LichtDusche room CUL_HM
attr LichtDusche serialNr OEQ2071909
attr LichtDusche subType switch
attr LichtDusche webCmd getConfig:clear msgEvents
define FileLog_LichtDusche FileLog /media/usb/LichtDusche-%Y.log LichtDusche
attr FileLog_LichtDusche logtype text
attr FileLog_LichtDusche room CUL_HM
define LichtDusche_Sw_01 CUL_HM 65C6E201
attr LichtDusche_Sw_01 model HM-LC-SW1-FM
attr LichtDusche_Sw_01 peerIDs 00000000,20B71F01,65C6E201,
attr LichtDusche_Sw_01 room Bad
attr LichtDusche_Sw_01 webCmd statusRequest:toggle:on:off


Darf ich die fhem.cfg manuel so ändern, dass für den HM-LC-SW2-FM die Konfiguration des HM-LC-SW1-FM übernehme, also so:
define LichtFlurEG CUL_HM 1F254C
attr LichtFlurEG .mId 0004
attr LichtFlurEG IODev myHmUART
attr LichtFlurEG autoReadReg 4_reqStatus
attr LichtFlurEG expert 2_raw
attr LichtFlurEG firmware 1.9
attr LichtFlurEG model HM-LC-SW1-FM
attr LichtFlurEG peerIDs 00000000,1F254C01,20B84201,6224C801,
attr LichtFlurEG room FLurEG,CUL_HM
attr LichtFlurEG serialNr KEQ0034276
attr LichtFlurEG subType switch
attr LichtFlurEG webCmd statusRequest:toggle:on:off
define FileLog_LichtFlurEG FileLog /media/usb/LichtFlurEG-%Y.log LichtFlurEG
attr FileLog_LichtFlurEG logtype text
attr FileLog_LichtFlurEG room CUL_HM


Es funktioniert soweit. Der Switch wird jetzt angezeigt wie jeder andere  HM-LC-SW1-FM.
Habe ich durch die manuelle Anpassung der fhem.cfg irgenwelche Effekte zu befürchten?

Danke,
Jürgen.

frank

hallo martin,

ich habe gerade ein update gemacht und stelle folgendes im frontend fest:

1. beim attr model gibt es keine selectbox mehr. der aktuelle attr eintrag erscheint nur noch in einem textfeld.

für eigene devices, wie den universalsensor von dirk, gilt zusätzlich:

2. beim attr subType fehlen die "custom"-subtypes in der selectliste. der bereits vorhandene subtype im attribut wird allerdings noch in der attributübersicht angezeigt.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

#56
hallo martin,

schlimmer ist noch:

3. beim teamlead device fehlt jetzt das attr subType. ich kann es über das front end auch nicht setzen. wenn ich virtual aus der selectliste auswähle, erscheint ein popup mit der meldung: " subType illegal for virtual devices "

ohne das attribut fehlen wichtige events beim teamlead. bitte dringend fixen.

4. bei attr model steht jetzt: "VIRTUAL". war das nicht sonst kleingeschrieben? ich muss mal stöbern.
genau: sonst war attr model=virtual_X mit der anzahl der chn.


edit:
es betrifft bei mir alle virtuellen devices. (vccu, tc, teamlead, standard)

obwohl es auf der detailseite der virtuellen devices kein attr subType mehr gibt, zeigt "get hminfo param subType" bei allen virtuellen devices noch "virtual" an.

hast du das konzept der attribute bei virtuellen devices geändert?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Paul

Zitat von: frank am 08 Januar 2019, 12:27:57

bei attr model steht jetzt: "VIRTUAL". war das nicht sonst kleingeschrieben? ich muss mal stöbern.

es ist kleingeschrieben
Cubietruck, HM-USB, CUL, FS20, FHT, HUE, Keymatic

frank

hallo martin,

ZitatDie alten Versionen sind wieder eingecheckt. Ein weiteres Update sollte funktionieren.
Betroffen sind 10_CUL_HM.pm und HMConfig.pm
zur zeit habe ich noch die versionen von gestern.

10_CUL_HM.pm                         18170 2019-01-07 15:48:38Z martinp876
HMConfig.pm                          18171 2019-01-07 15:50:38Z martinp876
00_HMLAN.pm                          18152 2019-01-05 23:18:38Z martinp876
98_HMinfo.pm                         17838 2018-11-25 10:51:09Z martinp876




ZitatNun würde mich noch interessieren, wer sinnvoll beschreiben kann, was bei ihm passiert ist. Ich habe auch Rachmelder und Teamleads - die sind sauber upgedated worden mit der neuen SW.
Die Änderungen werden kommen - und wenn ich die Probleme kenne, kann ich diese korrigieren und testen.
ich könnte also noch weiter testen. vielleicht zuerst nur den teamlead.

ich habe gestern um ca 10:28 das update gestartet (siehe timestamps von state/peerList beim teamleadchannel).
kurz vorher hatte ich erfolgreich set alarmOn/alarmOff ausgeführt (siehe wiederum die timestamps).

nach dem update habe ich ebenfalls set alarmOn/alarmOff ausgeführt. die rauchmelder haben wieder erfolgreich aufgeheult und sich auch wieder beruhigt. soweit alles gut.

aber: im teamleadchannel wurden keine readings aktualisiert (ausser triggerCnt) und auch keine events generiert (siehe wieder die timestamps). auch ein wiederholtes set alarmOn/alarmOff, sowie ein zusätzliches set teamCall, haben keine readings aktualisiert. nur die rauchmelder haben immer korrekt geheult.



das device von meinem teamlead:
Internals:
   DEF        AAAAAA
   IODev      hmlan1
   LASTInputDev hmuart1
   MSGCNT     26
   NAME       SDTeam
   NOTIFYDEV  global
   NR         396
   NTFY_ORDER 50-SDTeam
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 SDTeam_Btn1
   cul868_MSGCNT 13
   cul868_RAWMSG A0B859440AAAAAA1ACE1F0002::-57:cul868
   cul868_RSSI -57
   cul868_TIME 2019-01-08 13:30:35
   hmuart1_MSGCNT 13
   hmuart1_RAWMSG 05000029859440AAAAAA1ACE1F0002
   hmuart1_RSSI -41
   hmuart1_TIME 2019-01-08 13:30:35
   lastMsg    No:85 - t:40 s:AAAAAA d:1ACE1F 0002
   protLastRcv 2019-01-08 13:30:35
   protRcv    13 last_at:2019-01-08 13:30:35
   protRcvB   13 last_at:2019-01-08 13:30:35
   protSnd    13 last_at:2019-01-08 13:30:35
   protSndB   13 last_at:2019-01-08 13:30:35
   protState  CMDs_done
   rssi_at_cul868 cnt:13 min:-58 max:-57 avg:-57.34 lst:-57
   rssi_at_hmuart1 cnt:13 min:-41 max:-41 avg:-41 lst:-41
   .attraggr:
   .attrminint:
   READINGS:
     2019-01-08 13:30:35   .protLastRcv    2019-01-08 13:30:35
     2019-01-08 13:30:35   state           CMDs_done
     2019-01-08 13:30:35   trigger         Short_2
     2019-01-08 13:30:35   trigger_cnt     2
   helper:
     BNO        2
     BNOCNT     1
     HM_CMDNR   133
     mId        FFF1
     regLst     ,0
     rxType     1
     subType    virtual
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       newChn     
       nextSend   1546950636.08554
       rxt        0
       vccu       ccu
       p:
       prefIO:
         hmlan1
     mRssi:
       mNo        85
       io:
         cul868:
           -57
           -57
         hmlan1:
         hmuart1:
           -41
           -41
         hmusb1:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     rssi:
       at_cul868:
         avg        -57.3461538461538
         cnt        13
         lst        -57
         max        -57
         min        -58
       at_hmuart1:
         avg        -41
         cnt        13
         lst        -41
         max        -41
         min        -41
     shadowReg:
     tmpl:
Attributes:
   .mId       FFF1
   IODev      hmlan1
   IOgrp      ccu:hmlan1
   group      Rauchmelder
   model      VIRTUAL
   room       01_ALARM
   webCmd     virtual


der channel von meinem teamlead:
Internals:
   .triggerUsed 0
   DEF        AAAAAA01
   NAME       SDTeam_Btn1
   NOTIFYDEV  global
   NR         397
   NTFY_ORDER 50-SDTeam_Btn1
   STATE      unknown
   TESTNR     2
   TYPE       CUL_HM
   chanNo     01
   device     SDTeam
   peerList   SD.SZ,SD.WZ,SD.AZ,
   sdTeam     sdLead
   .attraggr:
   .attrminint:
   READINGS:
     2019-01-08 09:33:29   eventNo         0C
     2019-01-08 09:33:29   level           1
     2019-01-08 10:28:31   peerList        SD.SZ,SD.WZ,SD.AZ,
     2019-01-08 09:32:50   recentAlarm     SDTeam
     2019-01-08 09:33:29   smoke_detect    none
     2019-01-08 10:28:22   state           unknown
     2018-11-29 11:23:50   teamCall        from SDTeam:5
     2019-01-08 13:30:01   trigger_cnt     12
   helper:
     fkt        sdLead1
     regLst     
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     role:
       chn        1
     shadowReg:
     tmpl:
Attributes:
   group      Rauchmelder
   model      VIRTUAL
   peerIDs    52BB9001,52BB9D01,52C4DF01,
   room       01_ALARM
   webCmd     alarmOn:alarmOff:teamCall:teamCallBat





in den 2 list fallen mir 3 dinge auf:

1. attr subType existiert nicht mehr.
2. attr model ist nun VIRTUAL, war früher virtual_1.
3. es gibt keine rssi oder andere einträge über den hmlan1, obwohl er die kommunikation macht.

die punkte 1. und 2. gelten für alle virtuellen devices.
allerdings zeigt "get hminfo param subType" für alle virtuellen devices virtual an.


sag was du noch benötigst.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html