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

Begonnen von Beta-User, 03 November 2021, 10:55:55

Vorheriges Thema - Nächstes Thema

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:
ZitatVö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:
Zitat von: Beta-User am 02 November 2021, 14:29:23
Ä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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

ZitatDa 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!
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

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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

#4
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
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ß
Zotac CI547 32GB RAM 500GB SSD,ESXI 6.5, VM-Fhem5.8, VM-ioBroker, Cul 868Mhz;Cul 433Mhz = Busware, LGW, HM-MOD-RPI-PCB, Uniroll, IT YCR-100 TMT2100,ITR-1500, LD382 mit Wifilight, ESA 2000 + SENSOR WZ SET,FS20 TFK, HM-Sec-SC, HM-CC-RT-DN,PCA301,

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.

Zitat von: Timmäää am 04 November 2021, 20:20:54
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...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

#6
Zitat von: Beta-User am 03 November 2021, 10:55:55
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...

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: MadMax-FHEM am 05 November 2021, 23:19:53
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!

Zitat
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 :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Benni

#8
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:


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:


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
----------------------------------------------------
FHEM in TrueNAS-Jail
HMLGW + HM-Komponenten, alexa-fhem, Modbus/TCP, Modbus/RS485, LG-WebOS, Firmata, 1wire, ESP-RGBWW, DaikinAC per WLAN, Shellys, Denon AVR, Fronius WR, Helios Wohnraumlüftung, ...

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.
fhem 6.0 auf Rpi3 Bookworm
HM-LAN-CFG (FW 0.965), HM-MOD-UART, 2x HM-TC-IT-WM-W-EU, 4x HM-Sec-RHS und 3x HM-CC-RT-DN, 6x HM-LC-Bl1-FM mit je 1x Somfy-Motor,
2x HM-LC-SW2-FM für Licht und Lüfter, 2x HM-PB-6-WM55, Alexa, Jeelinkcross, CUL, CUNO2, IR-Blaster

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

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:
    $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 ::) ...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Timmäää

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

Timmäää

#14
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;