FHEM - Hausautomations-Systeme > Homematic
[CUL_HM] patches Oktober 2021 - die Zweite
Benni:
--- Zitat von: frank am 01 November 2021, 11:08:04 ---edit: martin erlaubt explizit gemischtes io handlinghttps://forum.fhem.de/index.php/topic,122107.0.html
--- Ende Zitat ---
Ob das aber wirklich sinnvoll ist?
Ich denke ein IO, das über eine vccu verwaltet wird, sollte dem User nicht mehr als IO für die explizite Zuweisung per Att IODev zur Verfügung stehen. Dazu wäre dann ja das prefered-IO in IOgrp zu verwenden.
Ein IO, das nicht mehr unter der Verwaltung einer vccu steht, natürlich schon!
Das wäre dann übrigens bei mir der Fall gewesen: Das IO hat in der FHEM-Installation ja noch existert (dummy=1 / physikalisch nicht mehr vorhanden) und war dem Device per Attr IODev zugewiesen. Also hätte hier gar keine IO-Zuweisung stattfinden müssen.
Auch dann hätte ich wahrscheinlich die Fehlkonfiguration schnell gefunden denn das entsprechende Device hätte einfach nicht mehr funktioniert.
Allerdings hätte dann schon früher, als das IO noch unter Verwaltung der vccu stand, die Fehlkonfiguration in vccu auffallen können. Hätte sogar stillschweigend korrigiert werden können, indem IODev gelöscht und IOgrp entsprechend mit vccu und prefered IO gesetzt worden wäre.
gb#
Gisbert:
Hallo Beta-User,
ich hatte den HMLAN vor längerer Zeit außer Betrieb genommen, da sich ein disconnect ans andere reihte.
Nachdem ich ein Update beim 00_HMLAN.pm (?), genau weiß ich es nicht mehr, gemacht hatte, lief es sehr gut.
In den letzten Tagen, insbesondere mit der aktuellen Version, kommen wieder häufiger disconnects.
Viele Grüße Gisbert
Beta-User:
--- Zitat von: Gisbert am 02 November 2021, 07:53:16 ---Nachdem ich ein Update beim 00_HMLAN.pm (?), genau weiß ich es nicht mehr, gemacht hatte, lief es sehr gut.
In den letzten Tagen, insbesondere mit der aktuellen Version, kommen wieder häufiger disconnects.
--- Ende Zitat ---
Bin etwas ratlos, welche Version du denn wann jetzt genau im Einsatz hattest. Die aktuelle svn-Version ist ja schon recht alt, und eventuell hattest du den in der im ersten Thread auch eingeflossenen patch angewendet?
Wie dem auch sei, ich bin jetzt mal über die letzten Fassungen von HMLAN und CUL_HM drüber und hätte wieder mal Testversionen im Angebot - bislang von meiner Seite nur grob angetestet.
Ä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.
mumpitzstuff:
Ich habe keine Ahnung ob ich hier richtig bin, aber nachdem ich heute ein "update all" angestoßen habe, sind alle meine Feuermelder (HM-SEC-SD) im state: unreachable. Hat jemand eine Idee woran das liegen könnte?
--- Code: ---Internals:
DEF 23457F
FUUID 5c4b8852-f33f-55cb-ee36-49cbe6bf5a10d383
FVERSION 10_CUL_HM.pm:0.251580/2021-10-30
IODev MapleWifi868
NAME SMOKE_SCHLAFZIMMER
NR 31
NTFY_ORDER 48-SMOKE_SCHLAFZIMMER
STATE unreachable
TESTNR 1
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
peerList self01
protCmdDel 1
protResnd 1 last_at:2021-11-02 19:26:19
protResndFail 1 last_at:2021-11-02 19:26:24
protSnd 1 last_at:2021-11-02 19:26:14
protSndB 2 last_at:2021-11-02 19:26:19
protState CMDs_done_Errors:1
sdTeam sdLead
READINGS:
2021-11-02 19:35:52 Activity alive
2021-09-01 16:12:28 D-firmware 1.0
2021-09-01 16:12:28 D-serialNr KEQ0709128
2021-11-02 19:26:14 IODev MapleWifi868
2021-11-02 11:01:52 PairedTo 0x26E92F
2021-09-01 16:33:43 R-pairCentral 0x26E92F
2021-11-02 11:01:52 RegL_00. 00:00 02:01 0A:26 0B:E9 0C:2F
2021-11-02 11:01:48 battery ok
2021-11-02 11:02:53 cfgState ok
2021-11-02 19:26:24 commState CMDs_done_Errors:1
2021-10-28 08:32:45 eventNo 0C
2021-11-02 11:01:48 level 0
2021-11-02 19:25:52 peerList self01
2021-11-02 11:01:47 powerOn 2021-11-02 11:01:47
2021-10-28 08:32:32 recentAlarm vccu
2021-11-02 11:01:48 recentStateType info
2021-10-28 08:32:45 smoke_detect none
2021-11-02 19:26:34 state unreachable
2021-10-28 08:30:40 teamCall from vccu:2
2020-07-18 21:10:39 trigLast SMOKE_SCHLAFZIMMER:short
2020-07-18 21:10:39 trig_SMOKE_SCHLAFZIMMER Short_4
2021-10-28 08:30:40 trigger Short_2
2021-10-28 08:32:46 trigger_cnt 12
helper:
HM_CMDNR 170
cSnd ,0126E92F23457F010E
fkt sdLead1
mId 0042
peerFriend peerSD
peerIDsState complete
peerOpt p:smokeDetector
regLst 0
rxType 2
cmds:
TmplKey self01:no:1635877552.36656
TmplTs 1635877552.36656
cmdKey 1:1:0:sdLead1:SMOKE_SCHLAFZIMMER:0042:01:self01
cmdLst:
alarmOff noArg
alarmOn noArg
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})]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
statusRequest noArg
teamCall noArg
teamCallBat noArg
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_self01 -tplPeer-
unpair noArg
lst:
condition Smoke Alarm,no alarm,tone off
peer self01
peerOpt SMOKE_AUSSEN,SMOKE_BAD,SMOKE_KINDERZIMMER,SMOKE_WOHNZIMMER,VIRTUAL_ACTOR_Btn1,vccu
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 +23457F,00,00,00
nextSend 1635877579.19009
rxt 0
vccu vccu
p:
23457F
00
00
00
prefIO:
mRssi:
mNo
peerIDsH:
00000000 broadcast
23457F01 self01
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
shadowReg:
tmpl:
Attributes:
IOgrp vccu
actCycle 099:00
actStatus alive
alarmDevice Actor
alarmSettings |set SMOKE_SCHLAFZIMMER alarmOn;define at_SMOKE_SCHLAFZIMMER at +00:05:00 set SMOKE_SCHLAFZIMMER alarmOff|set SMOKE_SCHLAFZIMMER alarmOff|00:21
autoReadReg 4_reqStatus
devStateIcon off:secur_smoke_detector .*:secur_smoke_detector@red
expert defReg,rawReg
firmware 1.0
model HM-SEC-SD
msgRepeat 1
peerIDs 00000000,23457F01
room SCHLAFZIMMER
serialNr KEQ0709128
subType smokeDetector
webCmd statusRequest:teamCall:alarmOn:alarmOff
--- Ende Code ---
Ich bin mir eigentlich fast sicher, das es vor dem Update noch nicht so war, kann aber auch gern noch mal ein Backup einspielen, um das zu überprüfen...
PS: Nach einem statusRequest steht der state erst auf MISSING ACK und wenig später wieder auf unreachable. Das ist jetzt durchgängig bei allen Rauchmeldern so, einen Hardware Defekt kann ich also ausschliessen.
PSPS: Bei meinen Fenstersensoren oder Heizungsreglern sind mir übrigens keine Unregelmäßigkeiten aufgefallen.
Timmäää:
Hi Mumpitzstuff,
diese Updates hier sind nicht im SVN, sondern gehen darüber hinaus. Dein Problem hatte ich letztens auch, dachte es liege an dem hier bezogenen HMLAN-Update, aber nach einem Reboot des FHEM-Servers ging es bei mir wieder und ich habe keine weitere Analyse betrieben.
Es war wie bei dir: Bei allen Geräten unreachable und/oder Missing_ACK.
Gruß,
Tim
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln