[jetzt im svn] [CUL_HM +] patches November 2021

[Beta-User]

Dieser Thread schließt an an "Oktober-patches II"

Vorab zum Verständnis dieses Threads: Wer ein Problem mit der aktuell per update zu bekommenden Fassung hat, möge bitte die hier geposteten und verlinkten Versionen (soweit die Module im Einsatz sind: komplett!) einspielen und schauen, ob sich sein Problem erledigt hat.
(Nur) Wenn nicht, dann gehört eine entsprechende Meldung hierher.

EDIT: Es sei aber darauf hingewiesen, dass die letzten Modulfassungen allesamt striktere Konsistenzprüfungen der Attribute vornehmen, und dadurch erst Konfigurationsfehler etc. auffallen, die bisher nicht in dieser Form sichtbar waren. Bitte daher ggf. auch checken, ob die Konfiguration "problematischer" Geräte eventuell fehlerhaft oder unvollständig ist!

EDIT2: Wer von sehr CUL_HM-Versionen kommt, die etwas älter sind (>6 Monate) hat uU. das Problem, dass sehr viel mehr Events kommen als früher und manche Eventhandler dann zu "unscharf" sind. In der Folge werden dann uU. viel zu viele Aktionen ausgelöst. Bitte daher ggf. auch die Event-Handler mal kritisch ansehen (die Foren-Suche sollte viele derartige Fälle bringen).
EDIT3: Spezielles Suchwort für EDIT2 noch: "commStInCh off" (ist aber nur eine Teilabhilfe!).

Das ganze ist [WIP], also work in progress und kann daher noch Fehler enthalten, und soll wie das letzte Mal ein Angebot für Martin sein, vorab möglichst getesteten Code dann wieder ins svn einchecken zu können - ergo wäre es wie bisher gehandhabt klasse, wenn sich ein paar "Mutige" finden würden, die das vorab testen würden.

Ausgangspunkt ist der svn-Stand vom 01.11.2021 - da sind dann einige Hinweise aus dem vorgenannten Post überholt.
Wer HMLAN im Einsatz hat, sollte auch HMLAN tauschen! Bisherige gepatchte Fassungen schaden zwar nicht, sind aber für Tests nicht optimal, weil die "Erkennung" von HMLAN-Geräten als "gültige" IO's in CUL_HM umgestellt wurde und so ggf. eventuell neu entstandene Lücken schneller erkannt werden können.

Da hier vermutlich doch grade einige Leute reinschauen - damit die (aktualisierte) Tool-"Sammlung" komplett ist:
- WebUI [hm.js]:   https://forum.fhem.de/index.php/topic,106959.0.html
- TSCUL&Co: https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796
Dazu etwas ausführlicher: Ich betreibe meinen Original-CUL jetzt auch mit TSCUL und habe daher im Moment sowohl CUL (MapleCUN), TSCUL und HMUARTLGW als IO im Einsatz. Für TSCUL allerdings nur in einer "lite"-Fassung zum Testen:

Völlig anleitungswidrig habe ich jetzt mal "nur" die firmware sowie "00_TSCUL.pm", "DevIoTS.pm" und "ReadingUtil.pm" aus der zip-file geholt. Zumindest scheint damit der CUL als IO in der VCCU eingebunden zu werden und liefert auch RSSI-Werte usw..

Bisher konnte ich keine gravierenden Probleme feststellen (mit den letzten beiden "patches II"-Fassungen), außer vielen Log-Einträgen, die damit zusammenzuhängen scheinen, dass Testgeräte wieder gelöscht wurden, aber der TSCUL das nicht mitgeteilt bekommen hat, und sich im Unterschied zu anderen IO-TYPE's darüber beschwert .
Falls jemand Interesse hat, diese Art des Testens (mit dem Ziel, TSCUL besser in die "Normalmodule" integriert zu bekommen) mitzumachen, würde mich das freuen .


Zum Eigentlichen - Aufgangspunkt ist:

Änderungen HMLAN:
- use DevIo; (wg. pre-commit hooks?)
- ansonsten bisherige patch-Fassung, aber ohne Instanz-Hash-:Clients:, also insbesondere (hoffentlich) weiter verbessertes reconnect/reboot-Verhalten.

Änderungen CUL_HM:
- :Clients:-Erkennung so umgestellt, dass man es in HMLAN nicht braucht (vereinfachte Fassung per einfacher alternativer Abfrage auf TYPE=HMLAN). Die Aktualisierung von HM_LAN ist damit nicht mehr verpflichtend, sondern nur noch empfolen;
- Counter für die IO-Geschichte eingebaut (mAn. ist die aktualisierte Logik schneller als die alte! Es wird nur einmal ein (um den Device-Namen erweiterter) Log-Eintrag erzeugt). In dem Zusammenhang: Die alte Logik war eigentlich nur erst mal ein erster Versuch, um irgendwelchen Missmatches überhaupt auf die Spur zu kommen, und von daher auch noch nicht bis ins letzte durchdacht und ausgereift...
- gg. der bisherigen patch-Fassung etwas vereinfachte Logik für das automatisierte Anlegen von Devices (nur noch hmPair aktiv?-Abfrage).
- Manche der von Benni in https://forum.fhem.de/index.php/topic,123744.msg1183485.html#msg1183485 geschilderten warnings müßten beseitigt sein. Allerdings ist mir nicht ganz klar, wie die überhaupt entstanden sind... Da scheint auch sonst noch irgendwas kaputt gewesen zu sein.
- "proposed"-Ermittlung aus Reading ist entsprechend Martins Wünschen draußen, kann sein, dass damit auch ein Teil der Mismatches in der Zuweisung entfällt (oder was dazukommt ). Auch von daher macht das mit dem Counter m.E. mehr Sinn.

Für die key-Zuweisung bei AES, wenn man neue IO's in die VCCU-IOList aufnimmt (?) habe ich derzeit noch keine Idee.

Werde es bei Gelegenheit auch selbst wieder im Echtsystem testen, aber die bisherige Geschwindigkeit kann ich nicht mehr leisten. Nach dem Selbsttest gibt es dann vermutlich einen "November"-Patches-Thread .

Über die Änderungen an den anderen Dateien habe ich weiter nur überschlägig geschaut.

Vergleich zum Stand von gestern: HMLAN unverändert, bei CUL_HM ist die anliegende Fassung möglicherweise wieder "REREADCFG-fest", und HMLAN und HMUARTLGW bekommen hoffentlich die Info, wenn ein CUL_HM-Device gelöscht wurde (ad TSCUL: Info wäre hilfreich, wie man das ggf. ergänzen müßte).

Patches folgen, wenn die CUL_HM-Version auch auf meinem Hauptsystem läuft.

Viel Spaß beim Testen

[frank]

Da hier vermutlich doch grade einige Leute reinschauen - damit die (aktualisierte) Tool-"Sammlung" komplett ist:

- WebUI [HMinfoTools.js] https://forum.fhem.de/index.php/topic,112825.msg1184335.html#new
jetzt ganz neu mit desired-io-check, der das aktuell genutzte io mit dem gewünschten io vergleicht.

wenn rudi meinen letzten wunsch eincheckt, kann man den io-check/io-wechsel sogar live mitverfolgen!

[Beta-User]

Wasserstandsmeldungen:

- Generell scheint die CUL_HM-Version von gestern in meiner Installation keine (neuen) Probleme zu haben, patches sind im ersten Post zu finden.
- Da es doch ein paar Downloads auch von HMLAN gab, wäre es interessant zu wissen, ob das Zusammenspiel dieser beiden Module mit den hier geposteten Fassungen soweit klappt (habe nach wie vor keinen HMLAN). Es sei nochmals darauf hingewiesen, dass die aktuellen svn-Versionen (derzeit) nicht aufeinander abgestimmt sind!


Was meinen TSCUL-Test angeht, hatte ich nach dem FHEM-Start erst einige viele Einträge im Log für ein Gerät, das m.E. so gar nicht exisitiert (ggf. noch in einem gespeicherten HMinfo-save?). Aber seit einiger Zeit taucht dazu auch nichts mehr im Log auf. Muss das aber noch näher untersuchen, wo das ggf. herkommt...

[Timmäää]

Hi,

ich hatte beide Module heruntergeladen und nutze sie seit heute Morgen. Ich wollte noch etwas warten bevor ich eine Rückmeldung gebe, aber deine Anfrage hat mich jetzt zur Zwischenmeldung bewegt. Ich setze einen CUL und einen HMLAN via vccu ein.

Bislang läuft alles reibungslos, wobei ich aber auch mit den svn Versionen keine Probleme hatte.

Gruß,
Timmäää

[Intruder1956]

Hallo, Ich setzte eine HmUARTLGW mit VCCU ein.
Seit dem 01.11.21 laut Log habe ich nach dem FHEM-Update mit meinem HM-SEN-DB-PCB Probleme. Er funktioniert nicht mehr. Leider habe ich nur die letzten 3 Backupdateien, ab dem 01.11.21 bis jetzt.
Ich schalte mit dem HM-SEN-DB-PCB alle meine vorhanden Lampen im Blink-Modus, weil ich schwerhörig bin und die Klingel nicht höre wenn meine Hörgeräte mit dem Fernseher oder Telefon verbunden bin.
Ist es möglich die letzten Dateien vor dem 01.11.21 zu bekommen ??
Hier ein List von meinem HM-SEN-DB-PCB

Code Auswählen Erweitern

nternals:
   .AttrList  .devInfo .mId .stc IODev IOgrp actCycle actStatus aesCommReq:1,0 aesKey:5,4,3,2,1,0 autoReadReg:0_off,1_restart,2_pon-restart,3_onChange,4_reqStatus,5_readMissing,8_stateOnly burstAccess:0_off,1_auto commStInCh:on,off do_not_notify:1,0 dummy:1,0 event-aggregator event-min-interval event-on-change-reading event-on-update-reading expert:multiple,defReg,allReg,rawReg,templ,none firmware hmKey hmKey2 hmKey3 hmProtocolEvents:0_off,1_dump,2_dumpFull,3_dumpTrigger ignore:1,0 levelMap levelRange model modelForce:ACTIONDETECTOR,ACTIONDETECTOR,ASH550,ASH550I,CCU-FHEM,CMM,DORMA_ATENT,DORMA_BRC-H,DORMA_RC-H,HM-CC-RT-DN,HM-CC-RT-DN-BOM,HM-CC-SCD,HM-CC-TC,HM-CC-VD,HM-DIS-EP-WM55,HM-DIS-TD-T,HM-DIS-WM55,HM-DW-WM,HM-ES-PMSW1-DR,HM-ES-PMSW1-PL,HM-ES-PMSW1-PL-DN-R1,HM-ES-PMSW1-PL-DN-R2,HM-ES-PMSW1-PL-DN-R3,HM-ES-PMSW1-PL-DN-R4,HM-ES-PMSW1-PL-DN-R5,HM-ES-PMSW1-SM,HM-ES-TX-WM,HM-HM-LC-DW-WM,HM-LC-AO-SM,HM-LC-BL1-FM,HM-LC-BL1-FM-2,HM-LC-BL1-PB-FM,HM-LC-BL1-SM,HM-LC-BL1-SM-2,HM-LC-BL1PBU-FM,HM-LC-DDC1-PCB,HM-LC-DIM1L-CV,HM-LC-DIM1L-CV-2,HM-LC-DIM1L-CV-644,HM-LC-DIM1L-PL,HM-LC-DIM1L-PL-2,HM-LC-DIM1L-PL-3,HM-LC-DIM1L-PL-644,HM-LC-DIM1PWM-CV,HM-LC-DIM1PWM-CV-2,HM-LC-DIM1T-CV,HM-LC-DIM1T-CV-2,HM-LC-DIM1T-CV-644,HM-LC-DIM1T-DR,HM-LC-DIM1T-FM,HM-LC-DIM1T-FM-2,HM-LC-DIM1T-FM-644,HM-LC-DIM1T-FM-LF,HM-LC-DIM1T-PL,HM-LC-DIM1T-PL-2,HM-LC-DIM1T-PL-3,HM-LC-DIM1T-PL-644,HM-LC-DIM1TPBU-FM,HM-LC-DIM1TPBU-FM-2,HM-LC-DIM2L-CV,HM-LC-DIM2L-SM,HM-LC-DIM2L-SM-2,HM-LC-DIM2L-SM-644,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM-2,HM-LC-JA1PBU-FM,HM-LC-RGBW-WM,HM-LC-SW1-BA-PCB,HM-LC-SW1-DR,HM-LC-SW1-FM,HM-LC-SW1-FM-2,HM-LC-SW1-PB-FM,HM-LC-SW1-PCB,HM-LC-SW1-PL,HM-LC-SW1-PL-3,HM-LC-SW1-PL-CT-R1,HM-LC-SW1-PL-CT-R2,HM-LC-SW1-PL-CT-R3,HM-LC-SW1-PL-CT-R4,HM-LC-SW1-PL-CT-R5,HM-LC-SW1-PL-DN-R1,HM-LC-SW1-PL-DN-R2,HM-LC-SW1-PL-DN-R3,HM-LC-SW1-PL-DN-R4,HM-LC-SW1-PL-DN-R5,HM-LC-SW1-PL-OM54,HM-LC-SW1-PL2,HM-LC-SW1-SM,HM-LC-SW1-SM-2,HM-LC-SW1-SM-ATMEGA168,HM-LC-SW1PBU-FM,HM-LC-SW2-DR,HM-LC-SW2-DR-2,HM-LC-SW2-FM,HM-LC-SW2-FM-2,HM-LC-SW2-PB-FM,HM-LC-SW2-SM,HM-LC-SW2PBU-FM,HM-LC-SW4-BA-PCB,HM-LC-SW4-DR,HM-LC-SW4-DR-2,HM-LC-SW4-PCB,HM-LC-SW4-PCB-2,HM-LC-SW4-SM,HM-LC-SW4-SM-2,HM-LC-SW4-SM-ATMEGA168,HM-LC-SW4-WM,HM-LC-SW4-WM-2,HM-MOD-EM-8,HM-MOD-EM-8BIT,HM-MOD-RE-8,HM-OU-CF-PL,HM-OU-CFM-PL,HM-OU-CFM-TW,HM-OU-CM-PCB,HM-OU-LED16,HM-PB-2-FM,HM-PB-2-WM,HM-PB-2-WM55,HM-PB-2-WM55-2,HM-PB-4-WM,HM-PB-4DIS-WM,HM-PB-4DIS-WM-2,HM-PB-6-WM55,HM-PBI-4-FM,HM-RC-12,HM-RC-12-B,HM-RC-12-SW,HM-RC-19,HM-RC-19-B,HM-RC-19-SW,HM-RC-2-PBU-FM,HM-RC-2-PBU-FM-2,HM-RC-4,HM-RC-4-2,HM-RC-4-3,HM-RC-4-3-D,HM-RC-4-B,HM-RC-8,HM-RC-DIS-H-X-EU,HM-RC-KEY3,HM-RC-KEY3-B,HM-RC-KEY4-2,HM-RC-KEY4-3,HM-RC-P1,HM-RC-SEC3,HM-RC-SEC3-B,HM-RC-SEC4-2,HM-RC-SEC4-3,HM-SCI-3-FM,HM-SEC-CEN,HM-SEC-KEY,HM-SEC-KEY-O,HM-SEC-KEY-S,HM-SEC-MDIR,HM-SEC-MDIR-2,HM-SEC-MDIR-3,HM-SEC-RHS,HM-SEC-RHS-2,HM-SEC-SC,HM-SEC-SC-2,HM-SEC-SCO,HM-SEC-SD,HM-SEC-SD-2,HM-SEC-SFA-SM,HM-SEC-SIR-WM,HM-SEC-TIS,HM-SEC-WDS,HM-SEC-WDS-2,HM-SEC-WIN,HM-SEN-DB-PCB,HM-SEN-EP,HM-SEN-LI-O,HM-SEN-MDIR-O,HM-SEN-MDIR-O-2,HM-SEN-MDIR-O-3,HM-SEN-MDIR-SM,HM-SEN-MDIR-WM55,HM-SEN-RD-O,HM-SEN-WA-OD,HM-SWI-3-FM,HM-SYS-SRP-PL,HM-TC-IT-WM-W-EU,HM-WDC7000,HM-WDS10-TH-O,HM-WDS100-C6-O,HM-WDS100-C6-O-2,HM-WDS20-TH-O,HM-WDS30-OT2-SM,HM-WDS30-OT2-SM-2,HM-WDS30-T-O,HM-WDS40-TH-I,HM-WDS40-TH-I-2,HM-WS550,HM-WS550LCB,HM-WS550LCW,HM-WS550TECH,IS-WDS-TH-OD-S-R3,KFM-DISPLAY,KFM-SENSOR,KS550,KS550LC,KS550TECH,KS888,OLIGO-SMART-IQ-HM,PS-SWITCH,PS-TH-SENS,ROTO_ZEL-STG-RM-DWT-10,ROTO_ZEL-STG-RM-FDK,ROTO_ZEL-STG-RM-FEP-230V,ROTO_ZEL-STG-RM-FFK,ROTO_ZEL-STG-RM-FSA,ROTO_ZEL-STG-RM-FSS-UP3,ROTO_ZEL-STG-RM-FST-UP4,ROTO_ZEL-STG-RM-FWT,ROTO_ZEL-STG-RM-FZS,ROTO_ZEL-STG-RM-FZS-2,ROTO_ZEL-STG-RM-HS-4,ROTO_ZEL-STG-RM-WT-2,S550IA,SCHUECO_263-130,SCHUECO_263-131,SCHUECO_263-132,SCHUECO_263-133,SCHUECO_263-134,SCHUECO_263-135,SCHUECO_263-144,SCHUECO_263-145,SCHUECO_263-146,SCHUECO_263-147,SCHUECO_263-155,SCHUECO_263-157,SCHUECO_263-158,SCHUECO_263-160,SCHUECO_263-162,SCHUECO_263-167,SCHUECO_263-XXX,SENSOTIMER-ST-6,VIRTUAL,WDF-SOLAR,WS888 msgRepeat oldreadings param peerIDs readOnly:0,1 readingOnDead:multiple,noChange,state,periodValues,periodString,channels rssiLog:1,0 serialNr showtime:1,0 stateFormat:textField-long subType:AlarmControl,KFM100,THSensor,blindActuator,blindActuatorSol,dimmer,display,keyMatic,motionAndBtn,motionDetector,no,outputUnit,powerMeter,powerSensor,pushButton,remote,repeater,rgb,senBright,sensRain,sensor,singleButton,siren,smokeDetector,swi,switch,thermostat,threeStateSensor,timer,tipTronic,virtual,winMatic timestamp-on-change-reading
   DEF        4E07A1
   FUUID      5c458176-f33f-4aae-16d1-74f3f46035f59708
   IODev      myHmUARTLGW
   NAME       Flur_Eingang_Klingel
   NR         562
   NTFY_ORDER 48-Flur_Eingang_Klingel
   STATE      Flur_Eingang_Klingel Short
   TYPE       CUL_HM
   chanNo     01
   disableNotifyFn 1
   READINGS:
     2021-11-05 11:49:42   .D-devInfo      010101
     2021-11-05 11:49:42   .D-stc          40
     2021-08-19 12:24:18   .R-ledMode      off
     2018-02-06 10:42:45   .R-longPress    0.4 s
     2021-11-05 12:02:57   .associatedWith Flur_Eingang_Klingel,Flur_Eingang_Klingel
     2021-11-05 11:49:45   .peerListRDate  2021-11-05 11:49:45
     2021-11-05 11:49:45   .protLastRcv    20211105114945
     2021-11-05 11:49:43   CommandAccepted yes
     2021-11-05 11:49:42   D-firmware      1.0
     2021-11-05 11:49:42   D-serialNr      NEQ0955461
     2021-11-05 12:20:38   IODev           myHmUARTLGW
     2021-11-05 11:49:44   PairedTo        0xF11234
     2021-11-05 11:49:44   R-pairCentral   0xF11234
     2018-02-06 10:42:45   R-sign          off
     2021-11-05 11:49:44   RegL_00.        00:00 02:01 05:00 0A:F1 0B:12 0C:34 14:06 18:00
     2021-11-05 11:49:44   RegL_01.        00:00 04:10 08:00 30:06
     2021-11-04 18:07:47   aesCommToDev    ok
     2021-11-04 18:07:47   aesKeyNbr       00
     2021-11-05 11:14:09   alive           yes
     2021-11-05 11:14:09   battery         ok
     2021-11-05 11:50:45   cfgState        ok
     2021-11-05 11:49:45   commState       CMDs_done
     2021-11-05 11:14:09   powerOn         2021-11-05 11:14:09
     2021-11-05 11:14:09   recentStateType info
     2021-11-01 14:17:46   state           Flur_Eingang_Klingel Short
     2018-02-24 09:44:09   trigDst_VCCU    noConfig
     2021-11-01 14:17:46   trigger         Short_11
     2021-11-01 14:17:46   trigger_cnt     11
   helper:
     HM_CMDNR   105
     mId        00DC
     peerFriend peerAct,peerVirt
     peerIDsState complete
     peerOpt    4:pushButton
     regLst     0,1,4p
     rxType     4
     cmds:
       TmplKey    :no:1636110177.8204
       TmplTs     1636110177.8204
       cmdKey     1:1:0::Flur_Eingang_Klingel:00DC:01:
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         peerSmart  -peerOpt-
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         sign       [(on|{off})]
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         trgEventL  -peer- -condition-
         trgEventS  -peer- -condition-
         trgPressL  [(-peer-|{all})]
         trgPressS  [(-peer-|{all})]
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt    Arbeit_Heizung_WindowRec,Arbeit_Heizung_remote,Bad_Heizung_WindowRec,Bad_Heizung_remote,Ess_Heizung_WindowRec,Ess_Heizung_remote
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +4E07A1,00,00,00
       rxt        0
       vccu       VCCU
       p:
         4E07A1
         00
         00
         00
       prefIO:
     mRssi:
       mNo       
     peerIDsH:
       00000000   broadcast
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     tmpl:
Attributes:
   .mId       00DC
   DbLogExclude .*
   IOgrp      VCCU
   alias      Flur_Eingang_Klingel
   autoReadReg 4_reqStatus
   expert     defReg,rawReg
   firmware   1.0
   group      Alarm
   model      HM-SEN-DB-PCB
   peerIDs    00000000
   room       CUL_HM,ioBroker
   serialNr   NEQ0955461
   subType    pushButton

Bevor ich hier gelesen habe , hatte ich schon Batterien gewechselt, neu Konfiguriert und VCCU im Pair-Modus versetzt.

Es waren ja einige Dateien im Update für HM am 01.11.21

Wäre echt cool wenn schnell geholfen würde.
Sollte was an Info fehlen bitte melden.

Vielen Dank und Gruß

[Beta-User]

OK, also eigentlich kein Thema, das hierher gehört...
Die komplette svn-History zu CUL_HM bekommst du in https://svn.fhem.de/trac/log/trunk/fhem/FHEM/10_CUL_HM.pm - mit Klick auf den jeweiligen Revisionsstand kommt man auf die volle Datei, unten sind Links zum Download.

Warum der Sensor ein Problem hat, kann ich dir nicht sagen und würde einen separaten Thread vorschlagen, du willst ja nicht ewig auf dem vorgestrigen Stand bleiben, und wir wollen ggf. wissen, wenn es neue Probleme gibt (svn und patches dürften hier keine Unterschiede zeigen).
Es wäre aber ggf. hilfreich zu wissen, welches die letzte funktionierende Version war.

Bislang läuft alles reibungslos, wobei ich aber auch mit den svn Versionen keine Probleme hatte.

Danke für die Rückmeldung!
Hier bisher auch keine neuen Probleme zu erkennen (höchstens, dass TSCUL Funkprobleme aufdeckt, die bisher unerkannt geblieben waren...).

[MadMax-FHEM]

Dieser Thread schließt an an "Oktober-patches II"

Aber: sollte man DORT (also im Oktober-Thread) nicht "prominenter" auf hier verweisen, also z.B. im ERSTEN Post? (statt ganz hinten   )

Und evtl. die dort befindlichen *.pm Dateien rausnehmen (oder sind die noch relevant?).


So ich hab auch mal runtergeladen, einspielen muss ich mal sehen, bin über's WE weg...

EDIT: fhem update und dann einspielen nehme ich mal an?

EDIT: auf meinem Testsystem hab ich es mal so gemacht: läuft (weiterhin). Auch das sonst als "zickig" bekannte "Display" läuft... configCeck sagt prima (gut ich musste noch mal getConfig machen / ist aber glaube ich bei dem Display "normal"), nur "verify that peer is set on both sides": Kanal1 und Kanal2 sind wie im Wiki vorgeschlagen mit der vccu gepeert. Da muss ich noch mal prüfen... Mal sehen. Aber erst am So oder Mo...

Code Auswählen Erweitern


peer not verified. Check that peer is set on both sides
    HM_3515DA_Dis_01: p:vccu
    HM_3515DA_Dis_02: p:vccu


Gruß, Joachim

[Beta-User]

Aber: sollte man DORT (also im Oktober-Thread) nicht "prominenter" auf hier verweisen, also z.B. im ERSTEN Post? (statt ganz hinten   )

...ist eine Frage der Leseweise, jetzt ist der Hinweis jedenfalls auch im ersten Post und die pm sind dort raus.
Danke für den Schubs!

EDIT: auf meinem Testsystem hab ich es mal so gemacht: läuft (weiterhin). Auch das sonst als "zickig" bekannte "Display" läuft... configCeck sagt prima [...]

Danke auch für diese Rückmeldung .

[Benni]

Guten Morgen!

Ich habe eben auch mal den aktuellen Stand in meine produktive Instanz eingespielt (fhem update + files aus #1).

Grundsätzlich scheint im ersten Schnell-Check alles zu laufen wie es soll.

Einzige Auffälligkeit war wieder (oder immer noch?) direkt beim Neustart von FHEM eine ganze Latte an Warnings durch CUL_HM:

Code Auswählen Erweitern


2021.11.06 08:35:31.276 1: CUL_HM start inital cleanup
2021.11.06 08:35:38.446 1: CUL_HM finished initial cleanup
2021.11.06 08:35:38.633 1: PERL WARNING: Use of uninitialized value $ps in substitution (s///) at ./FHEM/10_CUL_HM.pm line 9642.
2021.11.06 08:35:38.633 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 9140.
2021.11.06 08:35:38.633 1: PERL WARNING: Use of uninitialized value $name in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 9142.
2021.11.06 08:35:38.633 1: PERL WARNING: Use of uninitialized value $name in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 9143.
2021.11.06 08:35:38.634 1: PERL WARNING: Use of uninitialized value $name in string eq at ./FHEM/10_CUL_HM.pm line 9144.
2021.11.06 08:35:38.634 1: PERL WARNING: Use of uninitialized value $name in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 9145.
2021.11.06 08:35:38.634 1: PERL WARNING: Use of uninitialized value $name in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 9147.
2021.11.06 08:35:38.634 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4681.
2021.11.06 08:35:38.634 1: PERL WARNING: Use of uninitialized value $list in addition (+) at ./FHEM/10_CUL_HM.pm line 9520.
2021.11.06 08:35:41.643 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_CUL_HM.pm line 9840.


Kurz danach kommt dann noch das da:

Das scheint aber erst mal keine Probleme zu verursachen (die Meldungen sind auch nicht neu) ... muss ich mal schauen ob ich was dazu finde, sonst mach ich für den Teil noch einen separaten Thread für HMUARTLGW auf.

gb#

Edit1:
Eventuell hängen die Meldungen teilweise auch damit zusammen:

Code Auswählen Erweitern


configCheck done:

missing register list
    HG.XX.WS.Wetter: RegL_01.Wetterstation_chn-FF

peer not defined
    ccu_Btn8_BadTaster: id:5FE04302

peer not verified. Check that peer is set on both sides
    EG.SP.WT.Wandthermostat_Weather: p:EG.SP.HZ.Heizung.rechts_chn-22
    EG.SP.WT.Wandthermostat_Weather: p:EG.SP.HZ.Heizung.rechts_chn-B0
    EG.WZ.WT.Wandthermostat_Weather: p:EG.EZ.HZ.Heizung_chn-22
    EG.WZ.WT.Wandthermostat_Weather: p:EG.EZ.HZ.Heizung_chn-BD
    HG.XX.WS.Wetter: p:Wetterstation_chn-FF

trigger sent to unpeered device
    OG.SZ.FK.hinten: 000000


Muss ich mal sehen, wie ich diesen _chn-xx Müll wegberkomme. Einfaches getConfig scheint nicht zu reichen.

Edit2:
Habe für die HMUART-Meldungen einen separaten Thread eröffnet: https://forum.fhem.de/index.php/topic,123948.0.html

Edit3:
Die Wetterstation und den Wettersensor konnte ich bereinigen. Nach manuellem Anlegen des nicht-existierenden Kanals FF konnte ich das Peering mit peerBulk löschen. Die entsprechenden Meldungen aus configCheck sind raus!

Das hat auch bei dem ccu_Btn funktioniert!

Bei den _Weather - Kanälen hat das so leider nicht funktioniert! Ich habe noch im Hinterkopf, dass martinp876 mal gemeint hat, mit den _Weather-Kanälen gäbe es ein Darstellungsproblem.
Woanders habe ich glaube ich gelesen, dass durch Rücksetzen der betroffenen Devices und erneutem Anlernen und peeren die "falschen" peers raus wären. Das wollte ich aber heute nicht dran!

[hugomckinley]

Guten Abend,

ich war Leidtragender von nicht mehr funktionierender AES Kommunikation.

Ich habe gerade FHEM upgedated und die beiden Files aus #1 eingespielt.

Sieht sehr gut aus!

Vielen Dank für die Mühe.

Gruß,
Hugo

[locodriver]

Auch ich habe die Files runtergeladen.
Das List der VCCU sieht viel "kompletter" aus als vorher.
S. auch: .https://forum.fhem.de/index.php/topic,123944.0.html
Weiter bin ich allerdings mangels Zeit noch nicht.

[MadMax-FHEM]

Nun ist es auch auf einem meiner Hauptsysteme eingespielt: fhem update und die beiden Dateien aus Post 1 eingespielt.

Alles prima

Hauptsystem 2 folgt morgen...

Vielen Dank, Joachim

[Beta-User]

  Danke für die Rückmeldungen!

@Benni: Die Ursachenforschung hilft mir weiter. Mit diesen #9642f sollte es besser werden, ohne dass  nur weitere Pflaster geklebt werden:

Code Auswählen Erweitern

    $ps =~ s/_chn-\d\d$// if defined $ps;
    if (!$p || defined $ps && $peers =~ m/$ps/){

(Irgendwann hatte ich den Eindruck, dass reines Pflasterkleben nicht effektiv weiterführt, aber zumindest scheinen die verteilten nicht zu Problemen geführt zu haben; da hatte ich nämlich noch eine kleine Sorge ...)

[Timmäää]

Bei mir läuft mit deinen patches weiterhin alles wunderbar, keinerlei Auffälligkeiten.

[Timmäää]

Im SVN hat Martin ein HMLAN-Update eingecheckt. Diff gegen Beta-User 2021-11-02:

devIo inkludiert Martin erst beim HMLAN_Initialize
Zeile 841:   return DevIo_OpenDev($hash, 1, "HMLAN_DoInit",  sub(){}); -> den sub-Teil hat Martin rausgenommen
Zeile 916: hat Martin herausgenommen:  $hash->{helper}{q}{sending} = 1;

[Beta-User]

Hi Martin, hallo zusammen,

vielleicht kurz mein Kenntnisstand zum HMLAN-Update:

Zeile 916: hat Martin herausgenommen:  $hash->{helper}{q}{sending} = 1;

Die Zeile stammt aus noansis (?) "anti-Reboot"-Patch, die hatte ich schlicht so übernommen, da als funktionierend berichtet. Kann sein, dass die nicht notwendig ist, ich gehe davon aus, dass Martin das geprüft hat und es schlicht besser weiß .

Zeile 841:   return DevIo_OpenDev($hash, 1, "HMLAN_DoInit",  sub(){}); -> den sub-Teil hat Martin rausgenommen

Da hätte ich vermutlich etwas mehr Erläuterung dazu schreiben sollen, das ist uU. etwas "watndat":
- Es funktioniert auch ohne (und hatte es ja auch lange).
- Die Wirkung ist die, dass durch diesen "Pseudo-Callback" bei gekappter Verbindung nicht bei praktisch jedem fhem-pl-Schleifendurchlauf versucht wird, diese wieder herzustellen, sondern dann nur noch alle 60 Sekunden (einstellbar).
Ist eine Abwägungsfrage, die man "irgendwie" entscheiden kann. Nach meinem persönlichen Bauchgefühl wäre vermutlich der Pseudo-Callback iVm. einem kürzeren Einstellwert (10 Sekunden) für den timeout ein guter Kompromis.

devIo inkludiert Martin erst beim HMLAN_Initialize

Nicht ganz korrekt: DevIo wird _nochmals_ via "use" eingebunden. Grund ist irgendein komischer pre-commit-Hook, den zu knacken Martin erst im x-ten-Anlauf durch diese etwas seltsame Doppelung geschafft hat (https://forum.fhem.de/index.php/topic,110125.msg1185281.html#msg1185281).

Was in der Differenzbetrachtung noch fehlt (Define):

Code Auswählen Erweitern

$hash->{Clients} = ":CUL_HM:";
Damit ist es wieder kompatibel mit der im svn verfügbaren CUL_HM-Version, in "meiner" Fassung war das auskommentiert und dafür ein paar Zeilen in CUL_HM darauf angepaßt. Die werde ich wieder ändern.

@Benni:
konntest du ggf. schon checken, ob die Änderungen in #9642f das bewirken, was sie sollen: keine Logeinträge+gesäuberte Devices?
Dann würde ich diesen Teil bei Gelegenheit auch noch in "meine" CUL_HM-Fassung reinbasteln...

[Benni]

@Benni:
konntest du ggf. schon checken, ob die Änderungen in #9642f das bewirken, was sie sollen: keine Logeinträge+gesäuberte Devices?
Dann würde ich diesen Teil bei Gelegenheit auch noch in "meine" CUL_HM-Fassung reinbasteln...

Das ist jetzt leider blöd gelaufen, denn zwischenzeitlich habe ich meinen config bereinigt und konnte den _chn-Müll aus den Weather-Channels rausschmeißen (tatsächlich nur per Reset der Devices).

Ich kann dir jetzt also leider nicht bestätigen, dass deine Änderung wirkt (obwohl sie das damit sollte, wenn ich es richtig sehe )
Die Warnungen bei mir sind jedenfalls mit Verschwinden der "falschen" _chn ebenfalls verschwunden.

Das ist dann zumindest eine Bestätigung für die ermittelte Ursache

gb#

[Beta-User]

Danke für die Rückmeldung!
Hätte ja sein können, du hättest irgendwo noch ein RAW-listing von einem kaputten Device gehabt, das du testweise hättest einspielen können...

Na ja, habe jetzt jedenfalls auch diesen Teil vorsorglich eingearbeitet, weil es einen zweiten Betroffenen gibt; vielleicht hat er diesen Thread zwischenzeitlich auch gefunden und ist willens, sich dazu zu äußern .

Kompletten Code wieder hier anbei, da bisher nur kurz auf generelle Lauffähigkeit getestet .

Wer HMLAN im Einsatz hat - entweder die svn-Fassung nehmen, oder in meiner diese Zeile in Initialize aktivieren:

Code Auswählen Erweitern

$hash->{Clients} = ":CUL_HM:";

[mgernoth]

Hallo,

Zeile 916: hat Martin herausgenommen:  $hash->{helper}{q}{sending} = 1;

Damit ist mein no-reboot-Patch wirkungslos, diese Zeile ist essentiell für die Funktion.

Viele Grüße
  Michael

[Beta-User]

Hallo,

Damit ist mein no-reboot-Patch wirkungslos, diese Zeile ist essentiell für die Funktion.

Viele Grüße
  Michael

Danke für die schnelle Klarstellung!

Anbei dann also wieder eine "patches"-Fassung von HMLAN, die diese Zeile beinhaltet und mit der CUL_HM aus dem Vorpost zusammenpaßt.

Da ist dann auch der Pseudo-Call noch/wieder drin und (neu) ein timeout von 10 Sekunden vorgeschlagen (als Referenzpunkt für Skeptiker: HMUARTLGW hat das etwas anders mit 5 Sekunden vercoded, und darüber hat sich mind. die letzten 2 Jahre auch keiner beschwert).

Wäre super, wenn das jemand auf Funktionalität testen könnte, der einen HMLAN hat und mal kurzfristig ein "paar" Log-Einträge verkraften kann (die Zeile mit der Log-Anweisung in HMLAN_Ready() (am Anfang) einfügen).

[martinp876]

HMLAN updated.
use DEVio ist an einer seltsamen Stelle - allerdings hat Rudi das einchecken unterbunden, wenn es nicht hier implementiert ist. Hm.

DEVio nextOpenDelay ist wirklich eine spezielle implementierung, parameter zu übergaben. Da muss man erst einmal drauf kommen, hier einstellungen zu suchen, wenn man das Modul nutzt! Wer hat sich den Orden verdient?

Anyway - ich hoffe, wir sind jetzt auf Stand - sorry für meine Bugs ("sending")

[Timmäää]

Danke Beta-User für deine vielen Vorschläge und Testversionen und dir martinp876 für das ständige Prüfen und Einchecken
Ich bin seit heute Morgen mit der 2021-11-08 von Beta-User fehlerfrei unterwegs und werde die Datei ausm SVN morgen per Update reinziehen.

Großen Dank euch!

*update*
Ist ja heute noch mit ins Update gerutscht, gar nicht gemerkt durch mein exclude.

[Beta-User]

Vorab mal ein fettes Danke zurück an alle Mit-Tester und Mit-Überlegenden!

Anyway - ich hoffe, wir sind jetzt auf Stand

Was HMLAN angeht: Ja.
Bzgl. CUL_HM gibt es m.E. noch Diskussionsbedarf, s.u.

sorry für meine Bugs ("sending")

Kein Problem, es haben ja ein paar Leute aufgepaßt . Und irgendwie bin ich manchmal auch nicht sicher, ob mir nicht auch das eine oder andere jetzt durchgerutscht ist, anbei daher nochmal eine aktuelle CUL_HM-Fassung (#1034 hatte ich beim Bereinigen nach dem HMLAN-update wohl übersehen).

DEVio nextOpenDelay ist wirklich eine spezielle implementierung, parameter zu übergaben. Da muss man erst einmal drauf kommen, hier einstellungen zu suchen, wenn man das Modul nutzt! Wer hat sich den Orden verdient?

Das hatte ich irgendwann mal für MYSENSORS aus MQTT2_CLIENT geklaut, wenn ich das richtig in Erinnerung habe. Habe damals auch erst gedacht "watndat...?!?" Finde es an sich ist es nichts ungewöhnliches, dass im Instanzhash Parameter zu finden sind, die das Verhalten beeinflussen, aber eine "nutzlose" anonyme sub zu gebrauchen, fand ich auch "öhm..."

Was CUL_HM angeht, gibt es m.E. noch (mind.) folgende Baustellen, die man klären sollte:
- rereadcfg: Das funktioniert nur, wenn mit dem letzten "delete" einer CUL_HM-Instanz auch wieder NOTIFYDEF bereinigt wird (m.E.: urgent!)
- automatisches Anlegen von Geräten: Sollte m.E. nur aktiv sein, wenn der User etwas veranlasst. Alles andere gibt Probeme (!)! Die Minimalfassung ist hier enthalten, die volle (Unterstützung von "TYPE=autocreate") war in den OktoberII-patches mal drin, da fehlte eigentlich nur das "ver-room-en" nach CUL_HM für die Hauptinstanz (Teil a) - nur nach User-Anforderung - ist m.E. wichtig!)
- Benni's "uninitialized"-Baustelle (war irgendwo nochmal zu finden): Die Pflaster scheinen nicht zu schaden, die letzten Änderungen sind nicht durchgetestet, aber von Benni für "müßte passen" erklärt worden... (na ja, sind nur komische Log-Einträge => low prio);
- frank's Liste in https://forum.fhem.de/index.php/topic,120857.0.html ist vermutlich jetzt auch wieder kürzer geworden, aber afaik gäbe es da auch noch ein paar offene Punkte.
Da ich selbst das alles (vermutlich) nicht brauche (ich wohne auf dem Land und erwarte nicht, dass einer meiner Nachbarn noch mit BidCoS anfangen wird und habe configDB im Einsatz), werde ich meine Aktivitäten jetzt einstellen. Die Langform der Erklärung (zu autocreate) ist jeweils irgendwo in diesem Thread oder den anderen patches-Threads zu finden.

Den Thread lasse ich (zumindest erst mal) offen, falls jemand Fragen v.a. zu den obigen Punkten hat, stehe ich dafür gerne bereit.

CU.

[Beta-User]

- automatisches Anlegen von Geräten: [...] die volle (Unterstützung von "TYPE=autocreate") war in den OktoberII-patches mal drin, da fehlte eigentlich nur das "ver-room-en" nach CUL_HM für die Hauptinstanz (Teil a) - nur nach User-Anforderung - ist m.E. wichtig!)

Da Wiederfinden Freude macht, hier nochmal die "volle Fassung" als Diskussionsgrundlage incl. Zuweisung des "richtigen Rooms" nach TYPE=autocreate-Aktivität. Würde den Teil ab Zeile 1769 ersetzen, ist ungetestet.

Code Auswählen Erweitern

  if(!$mh{devH} && $mh{mTp} eq "00") { # generate device
    my $sname = "HM_$mh{src}";
    my $acdone;
    if ( InternalVal($mh{ioName},'hmPair',InternalVal(InternalVal($mh{ioName},'owner_CCU',''),'hmPair',0 ))) { # initiated via hm-pair-command => User wants actively have the device created
        if (IsDisabled((devspec2array('TYPE=autocreate'))[0]) ) {
            my $defret = CommandDefine(undef,"$sname CUL_HM $mh{src}");
            Log 1,"CUL_HM Unknown device $sname is now defined ".(defined $defret ? " return: $defret" : "");
        } else {
            DoTrigger('global', "UNDEFINED $sname CUL_HM $mh{src}"); #Beta-User: procedure similar to ZWave
            CommandAttr(undef,"$sname room CUL_HM");
        }
        $acdone = 1;
    } elsif (!IsDisabled((devspec2array('TYPE=autocreate'))[0]) && !defined InternalVal($mh{ioName},'owner_CCU',undef)) {
        #Beta-User: no vccu, write Log
        Log3($mh{ioName},2,"CUL_HM received learning message from unknown id $mh{src} outside of pairing mode. Please enable pairing mode first or define a virtual device w. model: CCU-FHEM.");
    }
    if ($acdone) {
        $mh{devH} = CUL_HM_id2Hash($mh{src}); #sourcehash - changed to channel entity
        $mh{devH}->{IODev} = $iohash;
        if (!$modules{CUL_HM}{helper}{hmManualOper}){
          my $ioOwn = InternalVal($mh{ioName},'owner_CCU','');
          $defs{$sname}{IODev} = $defs{$mh{ioName}};
          if ($ioOwn) {
            $attr{$sname}{IOgrp} = $ioOwn;
            $mh{devH}->{helper}{io}{vccu} = $ioOwn;
            if (   defined($mh{myRSSI})
                && $mh{myRSSI} ne ''
                && $mh{myRSSI} >= -50) { #noansi: on good rssi set prefered, too
              $attr{$sname}{IOgrp} .= ':'.$mh{ioName};
              my @a = ();
              $mh{devH}->{helper}{io}{prefIO} = \@a;
            }
          }
          else{
            $attr{$sname}{IODev} = $mh{ioName};
          }
        }
        $mh{devH}->{helper}{io}{nextSend} = $mh{rectm}+0.09 if(!defined($mh{devH}->{helper}{io}{nextSend}));# io couldn't set
    }
  }

[FFHEM]

Hallo zusammen,
da hier ja fleißig an den HM-Modulen gearbeitet wird, erst einmal mein Dankeschön an alle!
Ich habe den Oktober- und November-Thread soweit durchgearbeitet, aber für mich steht immer noch eine Frage aus:
Seit einigen Monaten habe ich Probleme mit dem weekprofile für Heizungsthermostate, ähnlich diesem User hier:

Mit kaputt meinte ich dass im Reading "R_tempList_State" der Wert "incomplete" steht und sich dieses auch nicht mehr ändert.
Teilweise steht auch in den Readings "R_3_..." incomplete und andere Readings haben ein "set_" vor dem Wert.

Habe nun das Ganze mal mit weekprofile für ein Thermostat probiert, da habe ich das gleiche Problem.

Wie gesagt, habe ich das gleiche Problem schon seit einigen Monaten und kann eine weekprofile-Änderung manchmal nur mit zusätzlichem getconfig übertragen.
Irgendeine Kombination von HMinfo/10_CUL_HM hatte dies auch gekonnt, ich steige aber nicht mehr durch, welche.
Ein aktuelles Update aller HM-Module mit dem neuesten

Code Auswählen Erweitern

# $Id: 10_CUL_HM.pm 25158 2021-11-09 Beta-User $
bringt auch nicht den Erfolg. Bei mir steht dann im Thermostaten immer noch "incomplete".

Frage: Stammt dieser Fehler aus HMinfo.pm? Und wenn ja, wird daran auch gearbeitet und welche Version von HMinfo.pm kann ich verwenden?
Vielen Dank!
Gruß,
Friedhelm

[Beta-User]

Soweit ich das noch in Erinnerung habe, war das in dem von dir zitierten Fall eigentlich kein originäres weekprofile oder CUL_HM-Problem, sondern v.a. auch eines, das mit Funkproblemem zu tun hatte (optimale IO-Zuweisung etc.). Vor allem: das jetzt gelöst ist.

Du solltest m.E. dazu einen neuen Thread aufmachen und etwas "Futter bei die Fische" geben (lists etc.).

[FFHEM]

Hallo Beta-User,
Thread ist jetzt hier eröffnet:

https://forum.fhem.de/index.php/topic,124136.0.html

[Beta-User]

...hier doch mal wieder ein update, auch wenn mich weiter wundert, dass Martin zu den offenen Fragen aus https://forum.fhem.de/index.php/topic,123874.msg1185568.html#msg1185568 bisher geschwiegen hat.

Änderungen gg. der letzten Fassung:
- "autocreate" ist in der "Vollversion" drin (nachdem @Pfriemler in https://forum.fhem.de/index.php/topic,124179.msg1187590.html#msg1187590 zu der Frage etwas kritisches geäußert hatte, das ich nicht komplett verstanden habe);
- franks Anliegen aus https://forum.fhem.de/index.php/topic,124090.0.html sollte bis auf die "uninitialized"-Warnings gelöst sein;
- manche der Punkte aus https://forum.fhem.de/index.php/topic,120857.msg1154321.html#msg1154321 habe ich mir angesehen, glaube aber, dass da noch Dinge drauf sind, die gelöst sein dürften, insbesondere:
-- Löschen der logIDs in den IOs (#1252)
-- falsche io zuweisungen nach fhem restart (da waren doch die wesentlichen Teile in die jetzige svn-Version eingearbeitet gewesen, oder irre ich mich?)

[Pfriemler]

moinsen,

Meine Meinung ist: "Fremde" Geräte sollten grundsätzlich nicht automatisch angelegt werden, wenn eine VCCU vorhanden ist.

Prinzipiell ebenfalls ACK, weil es den Normaluser vor überflüssigen Infos bewahrt. Ich persönlich hatte mit dem autocreate fremder Geräte noch nie ein Problem, es war eher hilfreich zu wissen was in der Nachbarschaft so neues aufläuft. Wenn "autocreate" fremder Geräte ohne vorherigens "pair" seitens VCCU also (für Experten) zuschaltbar wäre: optimal.
Ebenfalls ACK: was die VCCU da teilweise unter "unknown" angelegt hatte bisher, war aus meiner bescheidenen Sicht ein eher bunter Mix aus Fremd- und (später) eigenen angelegten Gerätschaften. Ich lösche die Liste regelmäßig ohne Probleme...

Wer die "braucht", sieht die HmID in der VCCU und kann dann ja manuell anlegen.

Seit wann ist ein unkompliziertes Anlegen von HM-Geräten durch einen define-Befehl wieder möglich?

[Beta-User]

Seit wann ist ein unkompliziertes Anlegen von HM-Geräten durch einen define-Befehl wieder möglich?

War irgendwo von "unkompliziert" die Rede ?!? Ein Define kann man (mWn. schon immer) stressfrei absetzen, und ich würde auch davon ausgehen, dass passende Nachrichten dann zugestellt werden und den Nebel nach und nach lichten... Inwieweit Kanäle angelegt werden usw.: k.A., aber Experten werden das hinbekommen, modelForce sei Dank .

Wenn "autocreate" fremder Geräte ohne vorherigens "pair" seitens VCCU also (für Experten) zuschaltbar wäre: optimal.

Bin für Vorschläge für Vorschläge offen, aber erst mal warte ich immer noch auf Martins ausführlicherer Rückmeldung zu dem "autocreate"-Thema "as is", das ist ja so schon kompliziert genug.
(Der aktuelle Code im svn führt jedenfalls nach meinem Verständnis eine Anlernmessage unabhängig von jeglichem User-Willen zum Anlegen des Devices samt aller Kanäle und ist daher eher bei deinem "lass alles autocreate-n, was so in die Gegend funkt" (aber ohne LogFile und die sonstigen "services" von TYPE=autocreate)).

[FFHEM]

Hallo Beta-User, Martin,
ich kann mir gut vorstellen, dass Ihr viel "um die Ohren" habt, nur zur Info und nur für den Fall, dass es in Vergessenheit geraten/nicht bekannt/noch nicht erkannt ist:

Es gibt noch das Problem, das ich mit einem HM-Regensensor mit dem Attribut

Code Auswählen Erweitern

param      offAtPon,onAtRain
habe. Bei neueren 10_CUL_HM-Versionen (ab ca. August 2021) schaltet die automatische Sensorheizung nicht mehr:

https://forum.fhem.de/index.php/topic,122425.msg1170042.html#msg1170042

Das funktioniert auch mit dem neuesten Patch (noch) nicht.
Gruß,
Friedhelm

[Beta-User]

Sorry, hatte ich überhaupt nicht auf dem Radar...

noansi hat ja dankenswerter Weise schon hier darauf hingewiesen, wie man (nicht nur) dieses Problem lösen kann. Für die übrigen Fälle scheinen "wir" nach und nach schon Lösungen eingebaut zu haben, der HM-SEN-RD-O scheint die letzte "params"-Sonderlocke gewesen zu sein, die noch gefehlt hat.

Das Modul lädt, und ich hoffe auch, dass ein einfaches Setzen der helper-Einträge ausreichend ist, aber wie üblich kann ich für nichts garantieren ...

(...eigentlich wollte ich ja nur das stateFormat-Problem lösen, und es dann irgendwann auch gut sein lassen, aber weil du so nett gefragt hast... )

[FFHEM]

Habe den Patch soeben eingespielt, restliche HM-Module sind alle up-to-date, Regensensor mit Regen beträufelt -> Sensor meldet Regen, aber Heizung ist nicht an!
Mit dieser 10_CUL_HM.pm-Version vom Mai 2021 funktioniert es:

Code Auswählen Erweitern

# $Id: 10_CUL_HM.pm 24449 2021-05-16 09:03:48Z martinp876 $

EDIT: Ich habe das Attribut jetzt nicht manuell noch einmal beschrieben, wie ich es sonst zur Reparatur mache, sondern nur den Patch eingespielt,  shutdown restart, Regen simuliert.

Die Heizung:

Code Auswählen Erweitern

Internals:
   DEF        67B24202
   FUUID      5ccb033e-f33f-26cd-d907-ac7db584698d01cd
   NAME       Regensensor_Heizung
   NR         1155
   NTFY_ORDER 48-Regensensor_Heizung
   STATE      off
   TYPE       CUL_HM
   chanNo     02
   device     Regensensor
   disableNotifyFn 1
   READINGS:
     2021-11-18 11:22:08   CommandAccepted yes
     2021-11-17 09:35:37   cfgState        ok
     2021-11-18 12:19:40   commState       CMDs_done
     2021-11-18 11:22:08   recentStateType ack
     2021-11-18 11:22:08   state           off
     2021-11-18 11:22:08   timedOn         off
     2021-11-18 11:22:08   trigLast        fhem:02
   helper:
     peerFriend
     peerOpt    -:sensRain
     regLst     
     cmds:
       TmplKey    :no:1637234249.98024
       TmplTs     1637234249.98024
       cmdKey     1:0:0::Regensensor:00A7:02:
       cmdLst:
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         getConfig  noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         off        noArg
         on         noArg
         on-for-timer -sec-
         on-till    -time-
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         toggle     noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
       lst:
         condition  dry,off,on,rain
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     peerIDsH:
     role:
       chn        1
     tmpl:
Attributes:
   alias      Regensensor_Heizung
   group      Wetter
   model      HM-SEN-RD-O
   param      offAtPon,onAtRain
   room       Wetterstation

[Beta-User]

Sorry, blöder Typo. Jetzt werden auch beim FHEM-Start die helper-Einträge erzeugt...
(Die alte Version zu vergleichen bringt relativ wenig: wie geschrieben hatte noansi ja bereits erläutert, an was es hängt, und an dem Punkt der Attribut-Validierung wird es m.E. kein zurück geben).

[FFHEM]

Sehr gut, Beta-User!
Die Heizung geht jetzt wieder automatisch an und aus, klasse!!!! 
Gruß,
Friedhelm

[Beta-User]

  Danke für die Rückmeldung,

dann werde ich halt dann doch bei Gelegenheit nochmal ein diff in den ersten Post hängen müssen, oder ein "November II" anfangen (?)  ...

@frank: Hast du zufällig schon eine Rückmeldung zu den anderen Themen?
(die übrigen Punkt aus der offenen-Punkte-Liste hatte ich zum Teil mehrfach kurz angeschaut, aber teils war unklar, ob es schon länger gelöst ist (A112), oder ich hatte Verständnisschwierigkeiten zu erfassen, was da überhaupt Sache ist - die Funk-Protokoll-Analyse ist nach wie vor nicht "meins"... Falls da support gewünscht ist, schaue ich es mir an, bräuchte dann aber jemanden, der mir das so erklärt, dass ich folgen kann ).

[jayjay]

Wie in https://forum.fhem.de/index.php/topic,124276.0.html diskutiert hatte ich mit der offiziellen CUL_HM Version Probleme beim direkten Pairing von zwei Homematic Geräten, speziell beim Pairing eines 6-fach Tasters HM-PB-6-WM55 an einen Dimmer HM-LC-Dim1TPBU-FM. Der Taster fing beim Drücken der Anlerntaste direkt an gelb zu blinken, anstatt grün zu blinken und auf das Drücken der Taste die angelernt werden soll zu warten. Der direkte Übergang zum gelben Blinken ist das Verhalten beim Anlernen and eine Zentrale im Pairing Modus. Das Verhalten hat sich auch bei Autocreate disabled nicht geändert. Nur wenn ich das Gerät in die ignoreTypes Liste aufnahm hat sich der Taster richtig verhalten und konnte mit dem Aktor direkt gepairt werden.
Mit dem hier diskutiert Update von CUL_HM hat es dann Bestens funktioniert, ohne ignoreType Eintrag.

Ich finde es auch gut, dass neue Geräte z.B. vom Nachbarn aber auch eigene nicht automatisch angelegt werden.

Danke an alle Beitragenden!

[Timmäää]

Martin hat ein Update eingecheckt.. Ich bin gespannt...

[Beta-User]

Hallo zusammen,

soweit ich das beurteilen kann, ist jetzt der "gesammelte Stand" ins svn übernommen.

Nochmal ein fettes DANKE an alle für's mit testen und überlegen!

Grüße, Beta-User

[Timmäää]

Ohne dich Beta-User wäre das nichts geworden. Auch wenn es tester und maintainer braucht, du hast es getrieben!

Fettes Danke!

[Violinux]

Auch ich bin überrascht, wie gut CUL_HM nun geht. Seit gestern V-25272
gegen 14 Uhr aus SVN geladen, bis dato keine Probleme. Prima !   

[Ellert]

Seit dem Update erhalte ich ohne erkennbaren Zusammenhang folgengende Warnungen im Abstand von 1-3 Stunden

Code Auswählen Erweitern

2021.12.01 17:24:11.849 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_CUL.pm line 939, <GEN8> line 102.
2021.12.01 17:24:11.857 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_HMUARTLGW.pm line 1456, <GEN8> line 102.


mit folgenden Versionen

Code Auswählen Erweitern

10_CUL_HM.pm    25272 2021-11-28 12:34:00Z martinp876
98_HMinfo.pm    25159 2021-10-30 17:37:57Z martinp876
00_HMUARTLGW.pm 25203 2021-11-08 09:18:29Z mgernoth

configCheck liefert keine Hinweise.

Hier das Stacktrace zu den Warnungen:

Code Auswählen Erweitern

2021.12.02 00:48:40.477 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_CUL.pm line 939.
2021.12.02 00:48:40.479 1: stacktrace:
2021.12.02 00:48:40.480 1:     main::__ANON__                      called by ./FHEM/00_CUL.pm (939)
2021.12.02 00:48:40.481 1:     main::CUL_Parse                     called by ./FHEM/00_CUL.pm (840)
2021.12.02 00:48:40.481 1:     main::CUL_Read                      called by fhem.pl (3895)
2021.12.02 00:48:40.482 1:     main::CallFn                        called by fhem.pl (773)
2021.12.02 00:48:40.489 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_HMUARTLGW.pm line 1456.
2021.12.02 00:48:40.490 1: stacktrace:
2021.12.02 00:48:40.491 1:     main::__ANON__                      called by ./FHEM/00_HMUARTLGW.pm (1456)
2021.12.02 00:48:40.492 1:     main::HMUARTLGW_Parse               called by ./FHEM/00_HMUARTLGW.pm (1574)
2021.12.02 00:48:40.493 1:     main::HMUARTLGW_Read                called by fhem.pl (3895)
2021.12.02 00:48:40.493 1:     main::CallFn                        called by fhem.pl (773)


Beeinträchtigungen sind mir nicht aufgefallen.

[Beta-User]

Klingt für mich nach Devices ohne zugewiesenes IO (das gab es vorher nicht), also ignore oder dummy.

Kannst du mal folgende defined?-Ergänzung in CUL (ab 937) testen:

Code Auswählen Erweitern

if($flgh & 0x20 &&       #noansi: see HMUARTLGW, not to collide with it
           defined $modules{CUL_HM}{defptr}{$src}->{IODev} &&
           $modules{CUL_HM}{defptr}{$src}->{IODev}->{TYPE} =~
                        m/^(?:TSCUL|HMUARTLGW)$/s);

[Ellert]

Ja, ignored und dummy Attribute habe ich bei ein paar Geräten gesetzt, ich teste jetzt mal und melde mich.

[Ellert]

Die Warnungen bleiben:

Code Auswählen Erweitern

2021.12.02 12:12:08.448 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_CUL.pm line 941.
2021.12.02 12:12:08.464 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_HMUARTLGW.pm line 1456.


Code Auswählen Erweitern

Zeile 941:                         m/^(?:TSCUL|HMUARTLGW)$/s);

[Beta-User]

Das ist komisch, denn bei mir ist das "nur" Zeile 940.
Vermutlich hast du dann noch eine weitere Prüfung eingezogen, oder? Also so was:

Code Auswählen Erweitern

        if($flgh & 0x20 &&       #noansi: see HMUARTLGW, not to collide with it
           defined $modules{CUL_HM}{defptr}{$src}->{IODev} &&
           defined $modules{CUL_HM}{defptr}{$src}->{IODev}->{TYPE} &&
           $modules{CUL_HM}{defptr}{$src}->{IODev}->{TYPE} =~
                        m/^(?:TSCUL|HMUARTLGW)$/s);


Dass das ggf. nur was gegen das warning aus CUL bewirkt, ist erst mal logisch, und wer einen HMLAN hat, kann vermutlich dasselbe ein drittes Mal haben...

[frank]

wenn das nur gelegentlich auftaucht, würde ich mal beim cul verbose 5 setzen, um auslösenden rawmessages zu sehen. dann sieht man welches device verantwortlich ist.

[Ellert]

@Beta-User: Zeile 941, weil ich eine Leerzeile vor 'if(...' eingefügt habe.

2021.12.02 15:59:17.808 5: CUL_Read: CUL1 /A0DEEA610688D9D71D7250601000017

2021.12.02 15:59:17.810 4: CUL_Parse: CUL1 A 0D EE A610 688D9D 71D725 0601000017 -62.5
2021.12.02 15:59:17.811 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_CUL.pm line 941, <GEN12> line 36.
2021.12.02 15:59:17.813 5: CUL1: dispatch A0DEEA610688D9D71D72506010000::-62.5:CUL1
2021.12.02 15:59:17.820 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/00_HMUARTLGW.pm line 1456, <GEN12> line 36.
2021.12.02 15:59:17.938 5: CUL_Read: CUL1 /A11EEA00271D725688D9D040A1DDF4A46770035

2021.12.02 15:59:17.940 4: CUL_Parse: CUL1 A 11 EE A002 71D725 688D9D 040A1DDF4A46770035 -47.5

Die HMid 688D9D gehört zu einem Fenstersensor, das war bisher der einzige Fall seit ich CUL auf verbose 5 gesetzt habe.

Code Auswählen Erweitern

Internals:
   CUL1_MSGCNT 16
   CUL1_RAWMSG A19F1A603688D9D71D725B6430D2615701D1BBE877C2C021E3D39::-70.5:CUL1
   CUL1_RSSI  -70.5
   CUL1_TIME  2021-12-02 18:54:07
   DEF        688D9D
   FUUID      5cae257f-f33f-5a4b-26e1-f58b8a715b073dbb
   HMLGW_MSGCNT 16
   HMLGW_RAWMSG 0500001DF1A603688D9D71D725B6430D2615701D1BBE877C2C021E3D39
   HMLGW_RSSI -29
   HMLGW_TIME 2021-12-02 18:54:07
   IODev     
   LASTInputDev HMLGW
   MSGCNT     32
   NAME       HM_688D9D
   NR         384
   NTFY_ORDER 48-HM_688D9D
   STATE      open
   TYPE       CUL_HM
   chanNo     01
   disableNotifyFn 1
   READINGS:
     2021-11-19 01:17:12   Activity        alive
     2021-11-24 17:00:16   CommandAccepted yes
     2021-04-15 18:22:19   D-firmware      1.0
     2021-04-15 18:22:19   D-serialNr      PEQ0572218
     2021-11-24 17:00:17   PairedTo        0x000000
     2019-04-10 19:21:28   R-cyclicInfoMsg on
     2019-04-10 19:21:28   R-eventDlyTime  0 s
     2019-04-10 19:21:28   R-msgScPosA     open
     2019-04-10 19:21:28   R-msgScPosB     closed
     2021-11-24 17:00:17   R-pairCentral   0x000000
     2019-04-10 19:21:28   R-sabotageMsg   on
     2019-04-10 19:21:28   R-sign          on
     2019-04-10 19:21:28   R-transmDevTryMax 6
     2019-04-10 19:21:28   R-transmitTryMax 6
     2021-11-24 17:00:17   RegL_00.        00:00 02:01 09:01 0A:00 0B:00 0C:00 10:01 14:06
     2021-11-24 17:00:17   RegL_01.        00:00 08:01 20:9C 21:00 30:06
     2021-11-24 17:00:16   aesCommToDev    ok
     2021-11-24 17:00:16   aesKeyNbr       00
     2021-11-24 16:12:47   alive           yes
     2021-11-24 17:00:43   battery         ok
     2021-11-24 17:00:15   cfgState        updating
     2021-11-24 17:00:17   commState       CMDs_done
     2021-11-24 17:00:43   contact         open (to broadcast)
     2021-09-27 13:20:10   powerOn         2021-09-27 13:20:10
     2021-11-24 16:12:47   recentStateType info
     2021-11-24 16:12:47   sabotageError   off
     2021-11-24 17:00:43   state           open
     2019-04-10 19:19:40   trigDst_broadcast noConfig
     2021-11-24 17:00:43   trigger_cnt     175
   helper:
     HM_CMDNR   190
     mId        00C7
     peerFriend peerAct,peerVirt
     peerIDsState complete
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     cmds:
       TmplKey    :no:1638443251.60462
       TmplTs     1638443251.60462
       cmdKey     1:1:0::HM_688D9D:00C7:01:
       cmdLst:
         assignHmKey noArg
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerChan   -btnNumber- -actChn- [({single})] [({set}|unset)] [actor|remote|both]
         peerSmart  -peerOpt-
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         sign       [(on|{off})]
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         trgEventL  -peer- -condition-
         trgEventS  -peer- -condition-
         trgPressL  [(-peer-|{all})]
         trgPressS  [(-peer-|{all})]
         unpair     noArg
       lst:
         condition  closed,open,tilted
         peer       
         peerOpt    FensterWZvirtual_Btn1,FensterWZvirtual_Btn2,FensterWZvirtual_Btn3,Geschirrspueler_Sw,HM_46B316,HM_56E8EC_Sw_01,HM_56E8EC_Sw_02,HM_56E8EC_Sw_03,HM_56E8EC_Sw_04,HM_56E8EC_Sw_05,HM_56E8EC_Sw_06,HM_56E8EC_Sw_07,HM_56E8EC_Sw_08,HM_56EF0C,HM_56F3E3,HM_5F1C17,HM_70331C,Heiz_Nacht,Heiz_Tag,LCSW4_Sw_03,LCSW4_Sw_04,RTDN1_ArbZ_WindowRec,RTDN1_ArbZ_remote,RTDN1_Bad_WindowRec,RTDN1_Bad_remote,RTDN1_SZ_WindowRec,RTDN1_SZ_remote,RTDN_WZ1_WindowRec,RTDN_WZ1_remote,RTDN_WZ2_WindowRec,RTDN_WZ2_remote,TasterWZvirtual_Btn1,TasterWZvirtual_Btn2,TasterWZvirtual_Btn3,TasterWZvirtual_Btn4,TasterWZvirtual_Btn5,TasterWZvirtual_Btn6,TempWZ1virtual_Btn1,TempWZ1virtual_Btn2,VCCU,Waschmaschine_Sw
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        1
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +688D9D,00,00,00
       nextSend   1638467647.12854
       rxt        2
       vccu       
       p:
         688D9D
         00
         00
         00
       prefIO:
     mRssi:
       mNo       
     peerIDsH:
       00000000   broadcast
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     tmpl:
Attributes:
   IOgrp      VCCU:HMLGW
   actCycle   002:50
   actStatus  alive
   alias      000_Fenstersensor_frei
   autoReadReg 4_reqStatus
   commStInCh off
   devStateIcon closed:fts_window_1w open:fts_window_1w_open
   do_not_notify 1
   dummy      1
   event-on-change-reading contact
   event-on-update-reading battery
   expert     defReg,allReg,rawReg
   firmware   1.0
   group      0_Raumklimastatus
   icon       fts_window_1w_open
   ignore     1
   model      HM-SEC-SCO
   peerIDs    00000000
   room       5_Heizung,CUL_HM
   serialNr   PEQ0572218
   subType    threeStateSensor

Bisher dachte ich, dass der nicht mehr mitspielt, wenn

Code Auswählen Erweitern

   do_not_notify 1
   dummy      1
   ignore     1

gesetzt ist.
Ich hatte gehofft, dass der Sensor sich so verhält als wäre er auskommentiert.

Der Sensor ist in Betrieb und mit einer RaspberryMatic CCU gepaired, nach dem ich ihn im FHEM unpaired hatte. Vorher hat als Ersatz gedient.
Für den Fall das ein anderer Sensor seinen Geist aufgib und es mal wieder Pairingprobleme gibt.
Ich nutze den Winter um mich mit der CCU vertraut zu machen.

[frank]

da das internal definiert aber leer ist, hilft wahrscheinlich folgende ergänzung:

Code Auswählen Erweitern

if($flgh & 0x20 &&       #noansi: see HMUARTLGW, not to collide with it
           defined $modules{CUL_HM}{defptr}{$src}->{IODev} &&
           $modules{CUL_HM}{defptr}{$src}->{IODev} &&
           $modules{CUL_HM}{defptr}{$src}->{IODev}->{TYPE} =~
                        m/^(?:TSCUL|HMUARTLGW)$/s);


Bisher dachte ich, dass der nicht mehr mitspielt, wenn

cul_hm beachtet ihn ja auch nicht mehr, wie du an den timestamps erkennen kannst. "attr ignore 1" sollte ausreichen.

allerdings wissen die io das ja nicht und empfangen trotzdem grundsätzlich alles, was gesendet wird. die messages werden nur nicht weitergereicht.

Code Auswählen Erweitern

2021.12.02 15:59:17.810 4: CUL_Parse: CUL1 A 0D EE A610 688D9D 71D725 0601000017 -62.5
2021.12.02 15:59:17.940 4: CUL_Parse: CUL1 A 11 EE A002 71D725 688D9D 040A1DDF4A46770035 -47.5
der fk hat seinen status an 71D725 gesendet, der eine aes signierung der ccu auslöst. sicherlich deine ccu.
hoffentlich nicht die selbe hmid wie die hmid der cul_hm vccu, damit ein "zwischenquatschen" ausbleibt.

[Ellert]

@frank: Danke für die Erläuterungen, 71D725 ist tatsächlich die HMId der CCU ich hatte es eher geahnt als gewust weil die HmId in FHEM nicht zufinden war.
Ein Blick in die Datei /usr/local/etc/config/ids des CCU Pi hat es bestätigt.

Mit den Raw Messages habe ich mich bisher nicht beschäftigen müssen.

Mir ist bei der Inbetriebnahme (Batterie einlegen und Pairen) der HM-Geräte für die CCU aufgefallen, dass die Geräte in FHEM nicht mehr automatisch angelegt werden (das gefällt mir) allerdings hatte ich HM_.* nicht in ignoreTypes gesetzt.

Autocreate nur beim Pairen - Ist das jetzt schon umgesetzt?

[Migul47]

Hallo,

Seit April funktioniert mein HM-DIS-EP-WM55 nicht mehr richtig. Die Texte werden nur noch zufällig mal angezeigt. In den Readings steht alles drin. Lt. LED werden auch die Daten gesendet. Eventuell aber nicht richtig?

[Beta-User]

Seit April funktioniert mein HM-DIS-EP-WM55 nicht mehr richtig. Die Texte werden nur noch zufällig mal angezeigt. In den Readings steht alles drin. Lt. LED werden auch die Daten gesendet. Eventuell aber nicht richtig?

Hab's gelesen, und überhaupt keine Idee, wo anfangen...

(version CUL_HM + IO-Module, ...., .... logs für das Setzen von Werten, .... => INFO, bitte!)

Werde jetzt diesen Thread schließen, weil eigentlich alles im svn ist => neuen Thread anfangen, Infos dort liefern...