Dieser Thread schließt an an "Oktober-patches II (https://forum.fhem.de/index.php/topic,123436.msg1179901.html#msg1179901)"
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 (https://forum.fhem.de/index.php/topic,106959.0.html)
- TSCUL&Co: https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796 (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 (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
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 (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!
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...
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äää
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ß
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...).
Zitat von: Beta-User am 03 November 2021, 10:55:55
Dieser Thread schließt an an "Oktober-patches II (https://forum.fhem.de/index.php/topic,123436.msg1179901.html#msg1179901)"
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
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 :) .
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!
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
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 (//http://://forum.fhem.de/index.php/topic,123944.0.html)
Weiter bin ich allerdings mangels Zeit noch nicht.
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
:) 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 ::) ...)
Bei mir läuft mit deinen patches weiterhin alles wunderbar, keinerlei Auffälligkeiten.
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;
Hi Martin, hallo zusammen,
vielleicht kurz mein Kenntnisstand zum HMLAN-Update:
Zitat von: Timmäää am 08 November 2021, 07:48:35
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ß :) .
Zitat
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.
Zitat von: Timmäää am 08 November 2021, 07:48:35
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):
$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...
Zitat von: Beta-User am 08 November 2021, 09:13:59
@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#
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 ;D .
Wer HMLAN im Einsatz hat - entweder die svn-Fassung nehmen, oder in meiner diese Zeile in Initialize aktivieren:
$hash->{Clients} = ":CUL_HM:";
Hallo,
Zitat von: Timmäää am 08 November 2021, 07:48:35
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
Zitat von: mgernoth am 08 November 2021, 10:24:13
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).
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")
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.
Vorab mal ein fettes Danke zurück an alle Mit-Tester und Mit-Überlegenden!
Zitat von: martinp876 am 09 November 2021, 06:45:24
Anyway - ich hoffe, wir sind jetzt auf Stand
Was HMLAN angeht: Ja.
Bzgl. CUL_HM gibt es m.E. noch Diskussionsbedarf, s.u.
Zitat von: martinp876 am 09 November 2021, 06:45:24
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).
Zitat von: martinp876 am 09 November 2021, 06:45:24
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 (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.
Zitat von: Beta-User am 09 November 2021, 10:11:37
- 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.
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
}
}
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:
Zitat von: dancatt am 05 Oktober 2021, 10:12:42
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
# $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
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.).
Hallo Beta-User,
Thread ist jetzt hier eröffnet:
https://forum.fhem.de/index.php/topic,124136.0.html
...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 (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 (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 (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 (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 (https://forum.fhem.de/index.php/topic,120328.0.html) (#1252)
-- falsche io zuweisungen nach fhem restart (da waren doch die wesentlichen Teile in die jetzige svn-Version eingearbeitet gewesen, oder irre ich mich?)
moinsen,
Zitat von: Beta-User am 17 November 2021, 09:19:19
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...
ZitatWer 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?
Zitat von: Pfriemler am 17 November 2021, 17:06:33
Seit wann ist ein unkompliziertes Anlegen von HM-Geräten durch einen define-Befehl wieder möglich?
War irgendwo von "unkompliziert" die Rede ;D ?!? 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 :-* .
ZitatWenn "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)).
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
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
Sorry, hatte ich überhaupt nicht auf dem Radar...
noansi hat ja dankenswerter Weise schon hier (https://forum.fhem.de/index.php/topic,122425.msg1170698.html#msg1170698) 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... :) )
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:
# $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:
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
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).
Sehr gut, Beta-User!
Die Heizung geht jetzt wieder automatisch an und aus, klasse!!!! ;D ;D ;D
Gruß,
Friedhelm
:) 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 ;D ).
Wie in https://forum.fhem.de/index.php/topic,124276.0.html (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!
Martin hat ein Update eingecheckt.. Ich bin gespannt...
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
Ohne dich Beta-User wäre das nichts geworden. Auch wenn es tester und maintainer braucht, du hast es getrieben!
Fettes Danke!
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 ! :)
Seit dem Update erhalte ich ohne erkennbaren Zusammenhang folgengende Warnungen im Abstand von 1-3 Stunden
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
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:
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.
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:
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);
Ja, ignored und dummy Attribute habe ich bei ein paar Geräten gesetzt, ich teste jetzt mal und melde mich.
Die Warnungen bleiben:
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.
Zeile 941: m/^(?:TSCUL|HMUARTLGW)$/s);
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:
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...
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.
@Beta-User: Zeile 941, weil ich eine Leerzeile vor 'if(...' eingefügt habe.
Zitat2021.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.
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
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.
da das internal definiert aber leer ist, hilft wahrscheinlich folgende ergänzung:
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);
ZitatBisher 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.
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.
@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?
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?
Zitat von: Migul47 am 15 Dezember 2021, 21:33:25
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...