Hallo zusammen,
hallo Martin,
nachdem die großen Baustellen bei CUL_HM vorerst weitgehend abgeräumt sind, aber noch die eine oder andere Kleinigkeit (vor allem dank der unermüdlichen Testerei von frank!) zutage getreten ist, gibt es hier mal wieder einen neuen Thread, in dem wieder die jeweils aktuellsten Stände zu finden sein sollen.
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 wieder super, wenn sich ein paar "Mutige" finden würden, die das vorab testen würden.
Wer testen will: Im Moment sind alle drei Bereiche nicht unbedingt voneinander abhängig, man kann also auch nur einzelne Dateien tauschen!
EDIT: Wer HMLAN im Einsatz hat, muss auch HMLAN tauschen!
Quellen (v.a.):
HMLAN-keepalive: https://forum.fhem.de/index.php/topic,120600.msg1152020.html#msg1152020 (https://forum.fhem.de/index.php/topic,120600.msg1152020.html#msg1152020)
HMinfo - Timerliste: https://forum.fhem.de/index.php/topic,120856.0.html (https://forum.fhem.de/index.php/topic,120856.0.html)
CUL_HM
- v.a. noch IO-Zuweisungen (Teil 2): https://forum.fhem.de/index.php/topic,123238.0.html (https://forum.fhem.de/index.php/topic,123238.0.html)
- "undefined subroutine" aus https://forum.fhem.de/index.php/topic,123473.0.html (https://forum.fhem.de/index.php/topic,123473.0.html)
Grüße,
Beta-User
EDIT: Die diffs gehen jetzt gegen den svn-Stand vom ?
EDIT2: CUL_HM (noch nicht: patch) enthält Stand 20.10. "levelInverse" und einen kleinen Fix in der commandref bzgl. param(s)
EDIT3a: jetzt wieder patch zu CUL_HM anbei
EDIT4a: Stände sind jetzt von 28.10.; habe etwas den Überblick verloren, was da alles drin ist... ::)
HMConfig ist nur für die relevant, die ein sehr spezielles Device haben.
EDIT5: CUL_HM jetzt auf dem Stand von 29.10. Nachmittag, diff liefere ich bei Gelegenheit nach
[OT-Nachtrag noch]
Wer ein HMUARTLGW als (Mit-) IO im Einsatz hat, sollte ab 31.10. per update auf die heute (30.10.) aktualisierte Fassung wechseln :) .
EDIT6: die seit 31.10. via svn verfügbaren Fassungen von HMinfo und HMConfig müßten den letzten hier geposteten gepatchten entsprechen. Die diff lasse ich einstweilen hier für die, die es genau wissen wollen...
CUL_HM enthält noch kleine Unterschiede, und bei HMLAN gab es wohl beim Einchecken ein Problem.
Weiterer Nachtrag, da hier vermutlich doch grade einige Leute reinschauen - damit die 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)
EDIT: komplette Module entfernt, aktuellere Fassungen gibt es in https://forum.fhem.de/index.php/topic,123874.0.html (https://forum.fhem.de/index.php/topic,123874.0.html)
Zitat
"Developer"?!? Meistens doch eher "User"
das stimmt ja mittlerweile auch nur noch bedingt ;)
Vielen Dank für die Mühen!
Nat. auch an frank und die Tester!Ich hab runtergeladen und spiele es nach einem fhem update mal auf meine Testsysteme.
Allerdings ist dort nicht wirklich viel HW angeschlossen und da ich am WE nicht zuhause bin kann ich aktuell auch nicht wirklich viel testen...
Wäre aber dann ein Test von "relativ alt" auf ganz aktuell...
...mal sehen.
EDIT:
1x fhem update (letzter Update bestimmt 3 Monate oder länger), shutdown restart, dann einspielen der neuen Patches (bzw. Full-Dateien) -> keine Auffälligkeiten
(aber halt leider auch nicht wirklich ein "Referenz-System" :-\ )
1x fhem update, Patches (bzw. Full-Dateien) eingespielt und dann shutdown restart -> keine Auffälligkeiten
(aber halt leider auch nicht wirklich ein "Referenz-System" :-\ )
Auf das Hauptsystem kann es dann leider erst frühestens am Mo oder so gehen...
Gruß, Joachim
Update: Martin hat gestern via svn updates bereitgestellt. Diese betreffen - zumindest auf den ersten Blick - zum großen Teil andere Themen.
Hoffe, den bisherigen Stand mit den gestrigen Änderungen soweit zusammengeführt zu haben, dass damit alles wieder paßt.
@Martin: wegen https://forum.fhem.de/index.php/topic,123473.0.html wird darum gebeten, die betreffenden Stellen in CUL_HM ggf. bevorzugt zu prüfen!
So ich hab jetzt mal meinem Hauptsystem ein Update verpasst und die Module aus dem Thread eingespielt...
Bislang gut, hab aber außer "shutdown restart" noch nix gemacht ;)
"Auffällig" sind nur folgende Logeinträge:
Zitat
2021.10.18 20:04:55 1: CUL_HM start inital cleanup
2021.10.18 20:04:55 3: Device XYZ added to ActionDetector with 000:20 time
...
2021.10.18 20:05:03 1: CUL_HM finished initial cleanup
Aber das ist schon ok so :)
Ich werde mal "testen" bzw. halt das System "normal" verwenden...
...und melden, wenn etwas auffällig ist.
Noch mal danke, Joachim
Zitat von: MadMax-FHEM am 18 Oktober 2021, 20:11:33
"Auffällig" sind nur folgende Logeinträge:
Vorab: Danke für's Mittesten, es sollte ja auch so sein, dass man "nichts" merkt (oder zumindest nicht mehr als bei der svn-Version).
Diese Einträge (und configCheck -f's) sind normal, das macht auch die reguläre Version so (früher allerdings in nochmal deutlich größerem Umfang ;) )
Martin hat übrigens vorhin schon wieder einen großen Teil eingecheckt (wie viel bzw. was nicht, muss ich mir noch ansehen) :) .
Mit den aktualisierten Dateien:
10_CUL_HM.pm:?/2021-10-18 UNSTABLE
98_HMinfo.pm:?/2021-10-18 UNSTABLE
00_HMLAN.pm:?/2021-10-18 UNSTABLE
kommen die stündlichen Meldungen:
2021.10.19 08:07:48 3: CUL_HM set VCCU update noArg
2021.10.19 08:07:50 3: CUL_HM set VCCU update noArg
2021.10.19 09:07:48 3: CUL_HM set VCCU update noArg
2021.10.19 09:07:51 3: CUL_HM set VCCU update noArg
jetzt immer doppelt.
Zitat von: Beta-User am 18 Oktober 2021, 20:42:05
Martin hat übrigens vorhin schon wieder einen großen Teil eingecheckt (wie viel bzw. was nicht, muss ich mir noch ansehen) :) .
zumindestens folgendes habe ich erst einmal erkannt (zeilennummern aus neuer version):
1. zeile 1016 wurde nicht geändert
2. zeile 4998 existiert immer noch
3. zeile 7390ff wurden nicht geändert
4. vor zeile 10880 fehlt jetzt leider (fraglich, ob prefered io noch funktioniert):
($iom) = grep {CUL_HM_operIObyIOName($_)} @{$hh->{io}{prefIO}} if(!$iom && @{$hh->{io}{prefIO}});5. zeile 10892 ist nun doppelt
6. zeile 10906 wurde nicht geändert
edit:
7. zeile 10898 reading iodev fehlt
Hmm, mal auf die Schnelle ein "sehr inoffizielles" Zwischenupdate mit der Bitte um kritische Durchsicht... (hoffe, das heute abend noch im Echtsystem testen zu können, sonst dauert das ggf. leider länger).
Also: Soweit ich das verstanden habe, hängt das mit CLIENTS eigentlich an HMLAN. Daher habe ich den Teil jetzt weitestgehend auf dem Stand von Martin belassen, dafür aber die CLIENT-Info wieder in HMLAN zusätzlich in den Instanz-Hash eingebaut und die commandref dann auch gleich mit in Angriff genommen (die war aber "komisch", mir ist leider nicht klar, ob jetzt alle Querverweise noch passen).
Die übrigen Zeilen von meiner alten Version sollten wieder eingebaut sein, zudem ist die "Erstdefinition" einer VCCU jetzt hoffentlich stressfrei möglich.
Zu den doppelten stündlichen Meldungen kann ich noch nichts sagen, das kann dauern.
Diffs folgen dann bei Gelegenheit, und wenn jemand das mit den IO-checks nur mit devspec2array testen könnte, wäre es super.
Zitatwenn jemand das mit den IO-checks nur mit devspec2array testen könnte, wäre es super.
wenn "Clients" bei einem io unter internals auftaucht und ":CUL_HM:" enthält, funktioniert das auch.
mit "devspec2array('Clients=.*:CUL_HM:.*')" wurden neulich (kurze phase, als meine 00_hmlan.pm auch das internal hatte) bei mir alle 4 io gefunden: cul, hmuart, hmlan und hmusb.
...ebend, so hatte ich das auch im Kopf...
Daher der update zum HMLAN (einschl. des anderen Patches):
Zitat von: martinp876 am 18 Oktober 2021, 20:32:36
[...] Das mit den "Clients" werden ich noch einmal prüfen. Aus meiner Sicht ist es ein fehlen der Daten in den IOs und sollte dort gelöst werden.
.
update im ersten post mit noch ein paar kleineren Änderungen zu heute mittag. Wer HMLAN im Einsatz hat, sollte dringlichst auch die Version von hier verwenden.
Zitat von: BroPi am 19 Oktober 2021, 09:37:31
kommen die stündlichen Meldungen:
2021.10.19 08:07:48 3: CUL_HM set VCCU update noArg
2021.10.19 08:07:50 3: CUL_HM set VCCU update noArg
2021.10.19 09:07:48 3: CUL_HM set VCCU update noArg
2021.10.19 09:07:51 3: CUL_HM set VCCU update noArg
jetzt immer doppelt.
Bisher konnte ich sowas bei mir mit den neuesten Versionen von vorhin nicht beobachten, und auch in den alten logs finde ich hier nichts vergleichbares. Also falls jemand eine Idee hat...?
Sonst suche ich bei Gelegenheit mal nach dem update-Befehl, ob der irgendwie in einer Timer-Schleife aufgerufen wird.
Servus
ich habe heute nur das update aus dem svn durchgeführt (bis jetzt war das 10_CUL_HM.pm von den Updates ausgenommen...)
Folgendes ist mir aufgefallen - (habe eine VCCU mir einem HMUart aktuelles FHEM)
Beim Hochfahren habe ich folgende Meldungen im log
2021.10.20 17:37:44 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
2021.10.20 17:37:44 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
2021.10.20 17:37:44 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
und bei einem HM-LC-SW1-FM folgende Meldung
2021.10.20 17:45:56 3: CUL_HM set Bad_Heizung on noArg
2021.10.20 17:45:56 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
2021.10.20 17:45:56 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
2021.10.20 17:45:57 3: CUL_HM set Bad_Heizung off noArg
2021.10.20 17:45:58 1: WriteStatefile: Cannot open ./log/fhem.save: Permission denied
Wobei bei einem HM-LC-SW2-FM
ist alles in Ordnung
2021.10.20 17:47:40 3: CUL_HM set Vitrine_Ofen on noArg
2021.10.20 17:47:42 3: CUL_HM set Vitrine_Ofen off noArg
Gruß
Helmut
Ich glaube ja nicht dass die save.file Meldungen vom update/CUL.hm kommen...
Wie sind denn Besitz- und Zugriffsrechte?
ls -la /opt/fhem/log/fhem.save
Gruß, Joachim
Zitat von: MadMax-FHEM am 20 Oktober 2021, 19:32:35
Ich glaube ja nicht dass die save.file Meldungen vom update/CUL.hm kommen...
+1
Vielleicht noch 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.Falls die patches helfen: Es darf dann gerne ein "paßt auch für mich" hier gepostet werden, zusammen mit der Info, was das Problem gewesen war, damit Martin auch eine Entscheidungsgrundlage hat.
Nicht erwünscht sind:
- Diskussionen über gelöste Probleme (es sei denn, jemand hat einen funktionierenden und eventuell besseren anderen Lösungsvorschlag)
- alles mögliche andere, das nicht seine Ursache in den CUL_HM- (etc.-) Modulen hat. Wer dazu unsicher ist, kann gerne einen neuen Thread aufmachen und von hier aus dahin verlinken, dann wird sich das vermutlich schon jemand ansehen.
Danke!
Also zunächst mal (weil [auch] "gewünscht"): helfen weiß ich nicht, hatte ja keine Probleme (zumindest sind mir keine aufgefallen / hab aber die Patches trotzdem mal eingespielt 8) )...
...aber zumindest läuft alles prima weiter...
Bis gestern (aufgefallen eben erst):
ich musste bei meinem Fensterdrehgriffsensor HM-SEC-RHS die Batterien wechseln (ist zwar erst neu im System aber war wohl mit alten Batterien ausgeliefert / oder "frisst" sie: mal sehen).
Dabei hat der wohl sein PAIRING "vergessen" (habe sowas im Kopf, dass das bei dem schon mal sein kann?). Kein Ding:
in fhem bei der vccu pairForSec und dann das Knöpfchen gedrückt etc. -> alles wieder gut.
Allerdings habe ich heute beide Testsysteme mal angeschaut und da ist mir das "rote Fragezeichen" aufgefallen: und es ist/war doch glatt der Fensterdrehgriffsensor...
...allerdings ist autocreate auf den Testsystemen deaktiviert. Sollte also doch kein Device angelegt werden?
Zumindest ist mir das früher nie passiert...
EDIT: beim ersten Anlernen vor einigen Wochen OHNE die Patches ist das bestimmt nicht passiert...
Daher die Frage bzw. eher "Hinweis" liegt das/kann das an den Patches liegen?
Auf dem Hauptsystem war (nat.) nichts (also kein rotes Fragezeichen), da war das Device ja schon da (und da soll es auch sein)...
Anmerkung: ich habe nicht die allerneuesten Patches, sondern Datum/Uhrzeit: 18 Oktober 2021, 20:11:33 bzw. (Testsystem um die es geht) 16 Oktober 2021, 11:35:17
ABER: es ist nat. kein Problem (und ich weiß ja noch nicht mal, ob es mit den Patches zu tun hat) und wirklich keine "Beschwerde"!! Wollte es nur mitteilen, nicht, dass doch was ist...
(Allerdings nat. fraglich, wer schon mehr als 1 System hat ;) Ich habe halt mein Hauptsystem und 2 Testsysteme, beide eben mit HM-Funkmodul aber [nat.] jeweils anderer HMID)
Gruß, Joachim
ZitatAllerdings habe ich heute beide Testsysteme mal angeschaut und da ist mir das "rote Fragezeichen" aufgefallen: und es ist/war doch glatt der Fensterdrehgriffsensor...
und was wollte das fragezeichen genau speichern?
Zitat von: frank am 22 Oktober 2021, 12:05:44
und was wollte das fragezeichen genau speichern?
Naja es steht ja bei Klick auf's "Fragezeichen" nur: last changes... und dann eben die "ID" des HM-Fensterdrehgriffsensors. Das ist ja ein Device mit nur einem Kanal bzw. ohne Kanal. Also (verm.) nur dieses Device...
Gruß, Joachim
Werde ich mir bei Gelegenheit ansehen, aber eigentlich glaubte ich nicht, irgendwas am "autocreate'"-Verhalten von CUL_HM geändert zu haben. Was Kanäle angeht, war CUL_HM (gefühlt) schon immer "hartnäckig", aber Hauptkanäle...? Sollte eigentlich nicht, und wenn, hätte diese "Macke" ziemlich sicher auch die offizielle Version.
[OT]
Die RHS sind echt nervtötend, wenn sie mal anfangen rumzuspacken...
wenn ich attribute ändere, erhalte ich immer eine genaue liste:
Last unsaved structural changes:
attr ccu room 90_Technik,CUL_HM
bei dir sah das dann so aus?
Last unsaved structural changes:
123456
dann sollte das wahrscheinlich besser so da stehen?
Last unsaved structural changes:
define HM_123456 CUL_HM 123456
@frank: ich glaube keines deiner Beispiele trifft :-\ und ja ich kenne das auch anders...
Aber: ich spiele das einfach noch mal nach...
EDIT:
Last unsaved structural changes:
define HM_614B9A CUL_HM 614B9A
Nur Knöpfchen gedrückt und promt: rotes Fragezeichen...
U.U. könnte ich mal (versuchen) eine alte (meine alte) Version(en) wieder einzuspielen und noch mal... Aber ich bin mir (sehr, sehr, sehr) sicher, dass ich das beim ersten Anlernen des Drehgriffsensors (vor ein paar Wochen) nicht hatte. Hatte aber auch schon lange (noch [viel] länger) kein update mehr gemacht...
EDIT: und der Test könnte etwas dauern... Sorry...
Gruß, Joachim
...spontane Idee: Wiedergänger des chanNo-Themas aus fheminfo?
am pairung wurde schon seit längerem "rumgeschraubt".
vermutlich braucht es eine weitere einschränkung ab zeile ~ 3912:
elsif($mhp->{mTp} eq "00"){######################################
ZitatNur Knöpfchen gedrückt und promt: rotes Fragezeichen...
obwohl kein autocreate und keine identischen system hmid.
mit oder ohne vccu?
was sagt fhem.log dazu?
Zitat von: frank am 22 Oktober 2021, 13:26:50
obwohl kein autocreate und keine identischen system hmid.
mit oder ohne vccu?
was sagt fhem.log dazu?
Alle Systeme:
autocreate disable 1
HMIDs alle unterschiedlich
IOs:
1x HMUSB-CFG2 (Hauptsystem)
1x HMUART direkt am PI
1x HMUART mittels USB-Adapter (für den Fall, wenn der HMUSB-CFG mal kaputt geht, weil auf dem Hauptsystem hab ich nur USB, auf dem PI steckt schon was)
vccu überall vorhanden, ebenso hminfo
bei der/den vccu ist auch das Device als unknown hinterlegt:
Hauptsystem (hier vermutlich beim ersten Anlernen):
unknown_614B9A received 2021-09-13 17:27:47
Testsystem 1 (von heute / ob zuvor schon da: keine Ahnung):
unknown_614B9A received 2021-10-22 12:27:24
Testsystem 2 (von heute / ob zuvor schon da: keine Ahnung):
unknown_614B9A received 2021-10-22 12:27:24
Log Hauptsystem
2021.10.22 12:27:38 3: CUL_HM received config CCU:vccu device: Fenster_WoZi_Griff. PairForSec: off PairSerial:
Log Testsystem 1:
2021.10.22 12:27:38 1: CUL_HM Unknown device HM_614B9A is now defined
2021.10.22 12:27:38 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
Log Testsystem 2
2021.10.22 12:27:38 1: CUL_HM Unknown device HM_614B9A is now defined
2021.10.22 12:27:38 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
Hmmm, hier noch Logeinträge (gefiltert nach besagtem Device) vom letzten Monat (also wohl beim "Erstanlernen"):
Hauptsystem:
2021.09.13 17:28:22 1: CUL_HM Unknown device HM_614B9A is now defined
2021.09.13 17:28:22 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: on PairSerial:
2021.09.13 17:28:22 3: CUL_HM pair: HM_614B9A threeStateSensor, model HM-SEC-RHS serialNr
2021.09.13 17:28:22 3: CUL_HM set HM_614B9A getConfig noArg
2021.09.13 17:29:59 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:29:59 2: CUL_HM HM_614B9A attack:01AFFE11614B9A00050000000000,01AFFE11614B9A000802010AAF0BFE0C11:01AFFE22614B9A00040000000000
2021.09.13 17:29:59 2: CUL_HM HM_614B9A attack:01AFFE11614B9A000802010AAF0BFE0C11,01AFFE11614B9A0006:01AFFE22614B9A00040000000000
2021.09.13 17:30:00 2: CUL_HM HM_614B9A attack:01AFFE11614B9A00040000000000,01AFFE11614B9A01040000000001:01AFFE22614B9A01040000000001
2021.09.13 17:30:00 2: CUL_HM HM_614B9A attack:01AFFE11614B9A00040000000000,01AFFE11614B9A01040000000001:01AFFE33614B9A01040000000001
2021.09.13 17:30:00 2: CUL_HM HM_614B9A attack:01AFFE11614B9A00040000000000,01AFFE11614B9A01040000000001:01AFFE33614B9A01040000000001
2021.09.13 17:30:21 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:30:21 3: CUL_HM set HM_614B9A getConfig noArg
2021.09.13 17:30:43 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:31:08 3: CUL_HM set HM_614B9A getConfig noArg
2021.09.13 17:31:41 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:32:42 2: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$
2021.09.13 17:55:02 3: CUL_HM set HM_614B9A deviceRename Fenster_WoZi_Griff
2021.09.14 07:30:26 2: CUL_HM Fenster_WoZi_Griff attack:01AFFE11614B9A0103,01AFFE11614B9A00040000000000:01AFFE22614B9A00040000000000
2021.09.14 07:30:26 2: CUL_HM Fenster_WoZi_Griff attack:01AFFE11614B9A0103,01AFFE11614B9A00040000000000:01AFFE22614B9A00040000000000
2021.09.14 07:30:27 2: CUL_HM Fenster_WoZi_Griff attack:01AFFE11614B9A0103,01AFFE11614B9A00040000000000:01AFFE33614B9A00040000000000
2021.09.14 07:30:27 2: CUL_HM Fenster_WoZi_Griff attack:01AFFE11614B9A0103,01AFFE11614B9A00040000000000:01AFFE22614B9A00040000000000
Testsystem 1:
2021.09.13 17:28:21 1: CUL_HM Unknown device HM_614B9A is now defined
2021.09.13 17:28:21 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:29:59 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:29:59 3: CUL_HM set HM_614B9A getConfig noArg
2021.09.13 17:29:59 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A000802010AAF0BFE0C11
2021.09.13 17:29:59 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE22614B9A00040000000000
2021.09.13 17:29:59 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A0006
2021.09.13 17:29:59 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE22614B9A00040000000000
2021.09.13 17:29:59 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A0006
2021.09.13 17:30:00 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE22614B9A01040000000001
2021.09.13 17:30:00 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A01040000000001
2021.09.13 17:30:21 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:30:21 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A00040000000000
2021.09.13 17:30:22 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A01040000000001
2021.09.13 17:30:22 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A0103
2021.09.13 17:30:43 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:31:41 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:31:41 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A00040000000000
2021.09.13 17:31:42 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A01040000000001
2021.09.13 17:31:42 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A0103
2021.09.13 21:07:31 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 21:07:31 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A00050000000000
2021.09.13 21:07:31 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A00080901
2021.09.13 21:07:32 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A0006
2021.09.13 21:09:02 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 21:09:02 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A00040000000000
2021.09.13 21:09:02 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A01040000000001
2021.09.13 21:09:03 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A0103
2021.09.13 21:10:12 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 21:10:13 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A01050000000001
2021.09.13 21:10:13 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A01082068
2021.09.13 21:10:13 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A0106
2021.09.13 21:10:43 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 21:10:43 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A00040000000000
2021.09.13 21:10:43 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A01040000000001
2021.09.13 21:10:44 2: CUL_HM HM_614B9A attack:01AFFE33614B9A00040000000000,01AFFE33614B9A01040000000001:01AFFE11614B9A0103
2021.09.14 07:30:26 3: CUL_HM set HM_614B9A getConfig noArg
2021.09.14 07:30:26 2: CUL_HM HM_614B9A attack:01AFFE33614B9A01040000000001,01AFFE33614B9A00040000000000:01AFFE11614B9A00040000000000
2021.09.14 07:30:26 2: CUL_HM HM_614B9A attack:01AFFE33614B9A01040000000001,01AFFE33614B9A00040000000000:01AFFE11614B9A00040000000000
2021.09.14 07:30:26 2: CUL_HM HM_614B9A attack:01AFFE33614B9A01040000000001,01AFFE33614B9A00040000000000:01AFFE22614B9A00040000000000
2021.09.14 07:30:27 2: CUL_HM HM_614B9A attack:01AFFE33614B9A01040000000001,01AFFE33614B9A00040000000000:01AFFE11614B9A00040000000000
2021.09.14 07:30:27 2: CUL_HM HM_614B9A attack:01AFFE33614B9A01040000000001,01AFFE33614B9A00040000000000:01AFFE22614B9A00040000000000
Testsystem 2:
2021.09.13 17:28:21 1: CUL_HM Unknown device HM_614B9A is now defined
2021.09.13 17:28:21 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:29:59 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:29:59 3: CUL_HM set HM_614B9A getConfig noArg
2021.09.13 17:29:59 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A000802010AAF0BFE0C11
2021.09.13 17:29:59 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE33614B9A00040000000000
2021.09.13 17:29:59 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A0006
2021.09.13 17:29:59 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A0006
2021.09.13 17:30:00 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE33614B9A01040000000001
2021.09.13 17:30:00 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A01040000000001
2021.09.13 17:30:00 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE33614B9A01040000000001
2021.09.13 17:30:21 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:30:21 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A00040000000000
2021.09.13 17:30:22 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A01040000000001
2021.09.13 17:30:22 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A0103
2021.09.13 17:30:43 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:31:41 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 17:31:41 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A00040000000000
2021.09.13 17:31:42 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A01040000000001
2021.09.13 17:31:42 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A0103
2021.09.13 21:07:31 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 21:07:31 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A00050000000000
2021.09.13 21:07:31 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A00080901
2021.09.13 21:07:32 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A0006
2021.09.13 21:09:02 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 21:09:02 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A00040000000000
2021.09.13 21:09:02 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A01040000000001
2021.09.13 21:09:03 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A0103
2021.09.13 21:10:12 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 21:10:13 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A01050000000001
2021.09.13 21:10:13 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A01082068
2021.09.13 21:10:13 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A0106
2021.09.13 21:10:43 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.09.13 21:10:43 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A00040000000000
2021.09.13 21:10:43 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A01040000000001
2021.09.13 21:10:44 2: CUL_HM HM_614B9A attack:01AFFE22614B9A00040000000000,01AFFE22614B9A01040000000001:01AFFE11614B9A0103
2021.09.14 07:30:26 3: CUL_HM set HM_614B9A getConfig noArg
2021.09.14 07:30:26 2: CUL_HM HM_614B9A attack:01AFFE22614B9A01040000000001,01AFFE22614B9A00040000000000:01AFFE11614B9A00040000000000
2021.09.14 07:30:26 2: CUL_HM HM_614B9A attack:01AFFE22614B9A01040000000001,01AFFE22614B9A00040000000000:01AFFE11614B9A00040000000000
2021.09.14 07:30:27 2: CUL_HM HM_614B9A attack:01AFFE22614B9A01040000000001,01AFFE22614B9A00040000000000:01AFFE11614B9A00040000000000
2021.09.14 07:30:27 2: CUL_HM HM_614B9A attack:01AFFE22614B9A01040000000001,01AFFE22614B9A00040000000000:01AFFE33614B9A00040000000000
Und ja: der Griffsensor war etwas "zickig" beim Anlernen, daher ein paar mehr Meldungen ;)
Aber mir ist (bewusst) kein rotes Fragezeichen aufgefallen...
...außer beim Hauptsystem und da hatte ich auch autocreate (wieder) enabled...
Wenn ich das (nur) übersehen haben sollte und das hier (somit) "Quatsch"/"falscher Alarm" war: ENTSCHULDIGUNG(aber norm. fällt mir ein rotes Fragezeichen ja schon auf, war diesmal ja auch so ;) )
EDIT: und ganz klar noch mal meinen DANK!! Endlich kann man (wohl) wieder fhem updates fahren!!Gruß, Joachim
ok, mit den fehlermeldungen ist klar, dass die einschränkung bei folgender zeile (1728ff) erfolgen muss:
if(!$mh{devH} && $mh{mTp} eq "00") { # generate device
my $sname = "HM_$mh{src}";
my $defret = CommandDefine(undef,"$sname CUL_HM $mh{src}");
Log 1,"CUL_HM Unknown device $sname is now defined ".(defined $defret ? " return: $defret" : "");
Anbei "inoffizielles" (will v.a. sagen: komplett ungetestetes und daher erst mal vor allem zur kritischen Durchsicht durch frank gedachtes) update.
Da ist im ganzen Modul nirgendwo was von "autocreate"/TYPE zu lesen, ich habe daher mal "auf Verdacht" was reingebastelt, und hoffe, damit nicht das "Sammelfeature" der VCCU zuerstört zu haben, aber das scheint "so oder so" weiter danach angesteuert zu werden, von daher müßte das eigentlich weiter passen...
Da sind noch weitere kleinere Anpassungen betr. die IO-Zuweisungen in bestimmten Fällen drin, dazu schreibe ich gleich noch was im anderen Thread.
Wenn frank das OK gibt kann ich ja mal testen...
Gruß, Joachim
Na ja, in einem Testsystem kann eigentlich nicht viel schiefgehen, und dann wüßten wir immerhin, ob das "autocreate-feature" weg ist...
Schlimmstenfalls schmiert FHEM ab :P .
Zitat von: Beta-User am 22 Oktober 2021, 15:26:17
Na ja, in einem Testsystem kann eigentlich nicht viel schiefgehen, und dann wüßten wir immerhin, ob das "autocreate-feature" weg ist...
Schlimmstenfalls schmiert FHEM ab :P .
Na dann...
Spiele ich demnächst mal alle Module von vorne und das hier ein...
EDIT: nix abgestürzt :) Und kein rotes Fragezeichen :) (auf dem anderen Testsystem ohne die neueste Version: erneut rotes Fragezeichen)
EDIT: im Log des "gepatchten" Systems steht aber nun gar nichts zu dem Vorgang...
EDIT: Patch läuft nun auf beiden testsystemen. Hauptsystem folgt... Dauert aber noch ein wenig...
Gruß, Joachim
Danke für die Rückmeldung.
Anmerkungen:
- Kein Log-Eintrag ist m.E. jedenfalls dann ok, wenn es eine VCCU gibt, wir wollen ja nicht "unknown - help me II" haben, oder? (eine verbose-4 könnte man in einem else-Zweig unterbringen, wenn es sein muss...)
- Interessant ist v.a. der Fall, das autocreate aus ist, aber ein pairing angestoßen wurde. Soll wäre: Device wird dann angelegt, der User will es ja eigentlich ausdrücklich so. Weiß aber nicht, ob das jetzt noch erfolgt, die Sprünge, die da im Code sind, sind "etwas unübersichtlich"...
Falls nein, ist vermutlich etwas mehr Nacharbeit gefragt, um den VCCU- bzw. IODev-Status betr. Pairing abzufragen.
ZitatKein Log-Eintrag ist m.E. jedenfalls dann ok, wenn es eine VCCU gibt, wir wollen ja nicht "unknown - help me II" haben, oder? (eine verbose-4 könnte man in einem else-Zweig unterbringen, wenn es sein muss...)
genau, joachims testsystem ist ja quasi wie ein unbeteiligter nachbar.
der darf ja keine infos kriegen und schon gar nicht ein definiertes device, das laut logs sogar dazwischen quatcht und getconfig absetzt! kein wunder, wenn manche höllische probleme beim anlernen hatten.
2021.09.14 07:30:26 3: CUL_HM set HM_614B9A getConfig noArgZitatInteressant ist v.a. der Fall, das autocreate aus ist, aber ein pairing angestoßen wurde.
pairing wurde nicht angestossen, sage ich. nur ein anlegen, denn mit diesen daten (PairForSec: off):
2021.10.22 12:27:38 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial: sollte der pairingcode wegen zeile 3928
nicht abgearbeitet werden:
if ( $hmPair ){# pairing is activealle 3 systeme melden angriffe von AFFE11, AFFE22 und AFFE33, da ja die attack erkennung auch nicht richtig funktioniert. siehe https://forum.fhem.de/index.php/topic,120459.0.html (https://forum.fhem.de/index.php/topic,120459.0.html)
nach den gesendeten befehlen ist AFFE1 jedenfalls das hauptsystem.
Korrekt: AFFE11 ist das Hauptsystem :)
Und ja, bei den weiteren "Versuchen" vorgestern (nicht gepostet, kann/könnte ich aber nachreichen) und heute wurde nur der Knopf am Drehgriffsensor gedrückt.
Bzw. falsch, vorgestern mit pairForSecs am Hauptsystem, damit der Drehgriffsensor die (vergessene) Zentrale wieder einlernt...
(ist aber für die Testsysteme dasselbe!?)
Logs müssen nicht sein, wollte nur mitteilen, dass halt nix drin war ;)
Wenn ich noch was testen kann: einfach melden.
Ansonsten steht noch aus die neuesten Patches ins Hauptsystem zu spielen...
...aber wohl erst morgen...
Danke noch mal, Joachim
ZitatAnsonsten steht noch aus die neuesten Patches ins Hauptsystem zu spielen...
...aber wohl erst morgen...
und da dann am besten noch mal richtig pairen, ob das auch noch funktioniert.
vorher möglichst auch das device löschen mit speichern und restart, damit das system vor dem pairen keine ahnung hat. vielleicht auch noch "set vccu clear unknownDev".
Zitat von: frank am 22 Oktober 2021, 21:41:08
und da dann am besten noch mal richtig pairen, ob das auch noch funktioniert.
vorher möglichst auch das device löschen mit speichern und restart, damit das system vor dem pairen keine ahnung hat. vielleicht auch noch "set vccu clear unknownDev".
Jep, mach ich.
Aber dann definitiv erst morgen ;)
Gruß, Joachim
@beta-user
vermutlich hat martin autocreate absichtlich verbannt, weil zu viele es abgeschaltet hatten. ;)
Zitat von: frank am 23 Oktober 2021, 01:07:09
@beta-user
vermutlich hat martin autocreate absichtlich verbannt, weil zu viele es abgeschaltet hatten. ;)
Man kann es zwar verbannen und auch für aktiviertes pairing einen Sonderweg gehen, aber wie hier gesehen, hat das Nebenwirkungen, über die man m.E. nicht so einfach weggehen sollte...
Nachdem das jetzt auch bei mir im Hauptsystem läuft, ist der letzte Stand samt patch wieder im ersten Beitrag zu finden. Das größte "Risiko", das ich im Moment dabei sehe ist, dass man autocreate wieder anschalten muss. Halte ich derzeit für das kleinere Übel, zumal sich viele wohl nicht über die Nebenwirkungen des Ausschaltens bewußt sind...
Kurzfassung für Augenreiber: anlassen und ungewolltes Zeug auf "ignore" stellen ist der von Rudi vorgesehene Weg und programmablauftechnisch der effektivere!
Dann ist mir noch was aufgefallen, was ich vermutlich in
HMLAN leider verbastelt hatte, bitte
aktualisieren!
Zitat von: frank am 23 Oktober 2021, 01:07:09
@beta-user
vermutlich hat martin autocreate absichtlich verbannt, weil zu viele es abgeschaltet hatten. ;)
Ah! Damit erklärt sich auch, warum es mir beim Pairing einiger Fensterkontakte vor ein paar Tagen, die neu angelegten Devices partout nicht in den, in autocreate (aktiv!) definierten Raum verschieben wollte.
Das Pairing ansonsten hat allerdings astrein auf anhieb funktioniert!
gb#
Zitat von: MadMax-FHEM am 22 Oktober 2021, 21:48:15
Jep, mach ich.
Aber dann definitiv erst morgen ;)
Gruß, Joachim
So, ausgeführt.
Also Module aus 1tem Post eingefügt, Device gelöscht, save, shutdown restart, autocreate aktiviert ;) , Drehgriffsensor neu gepaired...
Dann öfters mal das Knöpfchen gedrückt (kenne ich ja ;) ) und auch mal getConfig (und wieder Knöpfchen)...
Was mich gewundert hat (aber vielleicht muss das so), dass cfgState auf "updating" blieb, obwohl cmds_done war.
Daher habe ich auch (unnötigerweise?) weitere getConfig angestoßen...
Und auch mal autoReadReag auf "readMissing" gestellt...
Irgendwann war dann cfgState auf ok :)
(einfach so)
Hat etwas gedauert, was man auch am list sieht, cmds_done deutlich VOR cfgState ok...
Hier das list:
Internals:
CFGFN
DEF 614B9A
FUUID 6173cb59-f33f-753d-4988-a29f86511b742921
IODev hmusb
LASTInputDev hmusb
MSGCNT 33
NAME HM_614B9A
NR 2186
NTFY_ORDER 48-HM_614B9A
STATE ???
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
hmusb_MSGCNT 33
hmusb_RAWMSG E614B9A,0000,1CD311C6,FF,FFCA,298400614B9A0000002400304F45513230343730313780910101
hmusb_RSSI -54
hmusb_TIME 2021-10-23 10:47:56
lastMsg No:29 - t:00 s:614B9A d:000000 2400304F45513230343730313780910101
protLastRcv 2021-10-23 10:47:56
protRcv 22 last_at:2021-10-23 10:47:56
protSnd 19 last_at:2021-10-23 10:47:25
protState CMDs_done
rssi_at_hmusb cnt:34 min:-58 max:-53 avg:-55.61 lst:-54
READINGS:
2021-10-23 10:45:18 CommandAccepted yes
2021-10-23 10:47:56 D-firmware 2.4
2021-10-23 10:47:56 D-serialNr OEQ2047017
2021-10-23 10:47:24 IODev hmusb
2021-10-23 10:47:24 PairedTo 0xAFFE11
2021-10-23 10:45:18 R-cyclicInfoMsg off
2021-10-23 10:45:19 R-eventDlyTime 0 s
2021-10-23 10:45:19 R-ledOnTime 0.5 s
2021-10-23 10:45:19 R-msgRhsPosA closed
2021-10-23 10:45:19 R-msgRhsPosB open
2021-10-23 10:45:19 R-msgRhsPosC tilted
2021-10-23 10:45:18 R-pairCentral 0xAFFE11
2021-10-23 10:45:18 R-sabotageMsg on
2021-10-23 10:45:19 R-sign off
2021-10-23 10:45:18 R-transmDevTryMax 6
2021-10-23 10:45:19 R-transmitTryMax 6
2021-10-23 10:47:24 RegL_00. 00:00 02:01 09:00 0A:AF 0B:FE 0C:11 10:01 14:06
2021-10-23 10:47:24 RegL_01. 00:00 08:00 20:6C 21:00 22:64 30:06
2021-10-23 10:49:15 cfgState ok
2021-10-23 10:47:25 commState CMDs_done
helper:
HM_CMDNR 80
cSnd 01AFFE11614B9A01040000000001,01AFFE11614B9A0103
cfgStateUpdt 0
lastMsgTm 1634978876.26244
mId 0030
peerFriend peerAct,peerVirt
peerIDsRaw ,00000000
peerIDsState complete
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 20
supp_Pair_Rep 1
cmds:
TmplKey :no:1634978993.79073
TmplTs 1634978993.79073
cmdKey 1:1:0::HM_614B9A:0030: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})] [({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
...
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 +614B9A,00,00,00
nextSend 1634978876.36191
rxt 2
vccu vccu
p:
614B9A
00
00
00
prefIO:
mRssi:
mNo 29
io:
hmusb:
-48
-48
peerIDsH:
00000000 broadcast
prt:
bErr 0
sProc 0
rspWait:
tryMsg:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rssi:
at_hmusb:
avg -55.6176470588235
cnt 34
lst -54
max -53
min -58
shadowReg:
tmpl:
Attributes:
IOgrp vccu:hmusb
autoReadReg 5_readMissing
expert allReg,rawReg
firmware 2.4
model HM-SEC-RHS
peerIDs 00000000
serialNr OEQ2047017
subType threeStateSensor
Was mich wundert (ich aber nicht wirklich deuten kann, aber eigentlich denke da fehlen Infos/Register ist:
Zitat
2021-10-23 10:47:24 RegL_00. 00:00 02:01 09:00 0A:AF 0B:FE 0C:11 10:01 14:06
2021-10-23 10:47:24 RegL_01. 00:00 08:00 20:6C 21:00 22:64 30:06
Dachte evtl. "aufbohren" des Attributs "expert", hat aber nicht geholfen...
EDIT: was mich wundert, dass ein "get hm configCheck" da nichts "anmosert"...
EDIT: hatte mir ja das alte Device als raw kopiert, da waren die REGL auch schon drin. Liegt also nicht an diesen Versionen, außer ich hab mal nachgelesen etc. und erst dann kam das... Laut Datum des Raw sind die auch neuer...
setstate Fenster_WoZi_Griff 2021-10-21 11:46:59 .RegL_00. 00:00 02:01 09:00 0A:AF 0B:FE 0C:11 10:01 14:06
setstate Fenster_WoZi_Griff 2021-10-21 11:47:00 .RegL_01. 00:00 08:00 20:6C 21:00 22:64 30:06
Was das bedeutet: leider keine Ahnung :-\
EDIT: REGL-Einträge sind jetzt weg :) Sieht alles gut aus! :)Log (noch) "normale" verbose-Einstellungen:
2021.10.23 10:44:01 3: CUL_HM set vccu hmPairForSec 60
2021.10.23 10:44:10 1: CUL_HM Unknown device HM_614B9A is now defined
2021.10.23 10:44:10 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: on PairSerial:
2021.10.23 10:44:10 3: CUL_HM pair: HM_614B9A threeStateSensor, model HM-SEC-RHS serialNr
2021.10.23 10:44:10 3: CUL_HM set HM_614B9A getConfig noArg
2021.10.23 10:45:17 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 10:45:45 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 10:45:45 3: CUL_HM set HM_614B9A getConfig noArg
2021.10.23 10:46:11 3: CUL_HM set HM_614B9A getConfig noArg
2021.10.23 10:46:18 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 10:47:15 3: CUL_HM set HM_614B9A getConfig noArg
2021.10.23 10:47:23 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 10:47:56 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 10:48:25 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$
2021.10.23 10:49:12 3: HMinfo hm get:configCheck :
Auf den anderen Systemen ebenfalls die Module eingespielt, shutdown restart...
Dort ist autocreate deaktiviert...
-> kein rotes Fragezeichen :)
Weiß nicht, ob das hilft...
Wenn ich noch was tun kann/testen soll: einfach melden, ich sehe dann mal.
Ansonsten würde ich jetzt mal cycligMsgInfo aktivieren (um zu sehen, ob das geht)...
(hat der dumme Sensor wohl auch "vergessen" beim Batteriewechsel / oh, also ich hab jetzt den Sensor nicht zurückgesetzt, hätte ich sollen?)
EDIT: nach einigem Knöpfchen drücken (und wieder cmds_done -> cfgState updating / noch mal [und noch mal] Knöpfchen drücken dann cfgState ok) dann endlich übernommen :)
und das Log dazu:
2021.10.23 11:28:33 3: CUL_HM set HM_614B9A regSet exec cyclicInfoMsg on
2021.10.23 11:28:33 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$
2021.10.23 11:29:11 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 11:29:33 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$
2021.10.23 11:30:04 3: CUL_HM received config CCU:vccu device: HM_614B9A. PairForSec: off PairSerial:
2021.10.23 11:30:04 3: CUL_HM set HM_614B9A getConfig noArg
2021.10.23 11:31:05 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$
EDIT: was mir noch aufgefallen ist (aber für mich nicht schlimm ;) Ich kann mir ja behelfen :) ): "früher" wurden die neu angelegten HM-Devices in den Raum CUL_HM "verfrachtet" und auch ein FileLog-Device dazu angelegt... Das ist jetzt nicht passiert... Allerdings wohl auch schon nicht mehr mit den Versionen davor, also beim "Erstanlegen" des Fensterdrehgriffs letzten Monat (mit CUL_HM-Modulen, die bestimmt noch [viel] älter waren)...
Gruß, Joachim
Was mir noch aufgefallen ist, seit ich mit den Versionen hier "rumspiele":
ich habe ein notify, welches mir ein disconect des hmusb meldet.
Das hat bislang immer ausgelöst, bei shutdown restart (klar) und mir eine Nachricht gesendet.
Mit den Versionen hier aus dem Post ist das nicht mehr so.
EDIT: ich habe auch das 00_HMUARTLGW.pm aus dem verlinkten Thread eingespielt (18.10.)...
Ich bekomme nur mehr Meldungen beim Starten (die sind gleich geblieben).
Alte Abfolge bei shutdown restart:
Neuer Status bei hmusb cond: disconnected
Neuer Status bei hmusb Xmit-Events: ok:1 disconnected:2 init:1
FHEM-System restarted!
Neuer Status bei hmusb cond: ok
Neuer Status bei hmusb Xmit-Events: ok:1 init:1 disconnected:1
Neue Abfolge:
FHEM-System restarted!
Neuer Status bei hmusb cond: ok
Neuer Status bei hmusb Xmit-Events: ok:1 disconnected:1 init:1
Das ist seit dem 18.10. so...
Hier noch das notify dazu:
Internals:
DEF hmusb:Xmit-Events.*|hmusb:cond.* set TeleBot message Neuer Status bei hmusb $EVENT
FUUID 5fd8d700-f33f-753d-c989-e0059c0228104791
NAME nHMUSB
NOTIFYDEV hmusb
NR 1982
NTFY_ORDER 50-nHMUSB
REGEXP hmusb:Xmit-Events.*|hmusb:cond.*
STATE 2021-10-23 10:41:20
TRIGGERTIME 1634978480.64945
TYPE notify
READINGS:
2021-10-23 10:41:05 state active
Attributes:
Wäre jetzt doof, wenn ich disconnected nicht mehr mitbekäme.
Da ich das schon mal hatte und dann so einiges nicht gut war, würde ich das schon gerne "wieder" wollen :)
Gruß, Joachim
P.S.: erst hatte ich mich nur gewundert und gedacht och naja, verschluckt... Aber jetzt schon das 2te Mal, da ist dann doch wohl was anders...
GANZ WICHTIG: die vielen "kleinfieseligen" Anmerkungen/"Fehler" nicht übel nehmen!!
Ich bin mit der/den aktuellen Versionen (bislang) sehr zufrieden!!!
Aber ich denke je ausführlicher "Fehler"/"Unschönheiten" etc. berichtet/beschrieben werden, desto besser die "Hilfe" (so hoffe ich)...
...also weniger als "Kritik" verstehen mehr als meine "Methode" zu helfen.
(mehr kann ich ja leider nicht groß beisteuern)
Danke noch mal für die Mühen!!
Gruß, Joachim
ZitatWas mich gewundert hat (aber vielleicht muss das so), dass cfgState auf "updating" blieb, obwohl cmds_done war.
immer 60s nach dem ersten abarbeiten eines cmds. dann kommt die prüfung:
2021.10.23 10:48:25 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$=> und das configcheck-icon in hm.js/HMinfoTools.js wechselt von orange nach grün (ok) oder rot (fehler).
ZitatAnsonsten würde ich jetzt mal cycligMsgInfo aktivieren (um zu sehen, ob das geht)...
(hat der dumme Sensor wohl auch "vergessen" beim Batteriewechsel / oh, also ich hab jetzt den Sensor nicht zurückgesetzt, hätte ich sollen?)
wenn schon, denn schon, oder?
=> ein template für die lieblings konfiguration mit hm.js zusammenklicken, definieren und zuweisen.
damit überwacht gonfigcheck auch die registereinstellungen und mit einem cmd lassen sich alle register wieder herstellen. 8)
Zitat von: frank am 23 Oktober 2021, 11:36:12
immer 60s nach dem ersten abarbeiten eines cmds. dann kommt die prüfung:
2021.10.23 10:48:25 3: HMinfo hm get:configCheck :-f,^(HM_614B9A|HM_614B9A)$
=> und das configcheck-icon in hm.js/HMinfoTools.js wechselt von orange nach grün (ok) oder rot (fehler).
wenn schon, denn schon, oder?
=> ein template für die lieblings konfiguration mit hm.js zusammenklicken, definieren und zuweisen.
damit überwacht gonfigcheck auch die registereinstellungen und mit einem cmd lassen sich alle register wieder herstellen. 8)
Jaja, ich weiß.
Steht schon lange auf der LANGEN Liste was ich mir unbedingt mal anschauen wollte ;) :)
Aber aktuell viele andere (wichtigere) "Baustellen" und (leider) nicht nur in/mit fhem...
Danke, Joachim
ZitatAber aktuell viele andere (wichtigere) "Baustellen" und (leider) nicht nur in/mit fhem...
für den anfang: nur 2 dateien kopieren und über attribute aktivieren.
spart dann wahrscheinlich ganz automatisch immer wieder zeit ein, da vieles ganz offensichtlich wird.
mittelfristig hast du also mehr zeit für andere dinge. ;)
[OT!]
Zitat von: frank am 23 Oktober 2021, 12:29:55
für den anfang: nur 2 dateien kopieren und über attribute aktivieren.
spart dann wahrscheinlich ganz automatisch immer wieder zeit ein, da vieles ganz offensichtlich wird.
mittelfristig hast du also mehr zeit für andere dinge. ;)
Ok, ok ;)
1x die "offizielle" auf ein Testsystem und die Testversion auf das andere Testsystem... :)
Zitat
0.1. hm.js in den ordner /opt/fhem/www/pgm2 kopieren und vorhandene version ggf sichern. rechte beachten, zb über linux console:
Zitat
0.4 wichtig: damit keine neuen templates nach fhem restart verloren gehen, unbedingt die hinweise zur vorbereitung im wiki beachten (link beim fragezeichen).
Das hat aber gedauert, bis ich das Fragezeichen entdeckt hatte ;)
Mal sehen...
Gruß, Joachim
[/OT sorry]
Betr. OT: Kein Problem, solange Themen diskutiert werden, die potentiell für alle CUL_HM-User interessant sind, die wissen wollen, wie das aktuell "am besten" geht...
Betr. Meldungen: Niemand muss sich entschuldigen, wenn er hier was schildert, das er "bemerkenswert" findet ;) .
Mir hat das jedenfalls jetzt geholfen, sowas wie einen Vorschlag für einen "Masterplan" betr. das "autocreate"-Thema zu entwickeln. Wird aber etwas dauern, bis ich das in Ruhe für mich selbst durchgegangen bin.
Hier also der Versuch, das "autocreate"-Thema zu lösen...
Soll-Szenarien:
a) pairing nicht vom User angestoßen, keine VCCU, autocreate ist deaktiviert => es soll nichts passieren außer evtl. Einträgen im Log
b) pairing nicht vom User angestoßen, keine VCCU, autocreate ist aktiviert => Device soll angelegt werden, FileLog wird entsprechend autocreate-Vorgabe erstellt
c) pairing nicht vom User angestoßen, VCCU, autocreate ist deaktiviert => es soll nichts passieren, das Device wird von der VCCU eingesammelt, keine "help-me"-Einträge
d) pairing nicht vom User angestoßen, VCCU, autocreate ist aktiviert => Device soll angelegt werden, FileLog wird entsprechend autocreate-Vorgabe erstellt, kein VCCU-Eintrag
e) pairing vom User angestoßen, keine VCCU, autocreate ist deaktiviert => Device wird im "CUL_HM-Way" angelegt (=>kein FileLog)
f) pairing vom User angestoßen, keine VCCU, autocreate ist aktiviert => Device soll angelegt werden, FileLog wird entsprechend autocreate-Vorgabe erstellt
g) pairing vom User angestoßen, VCCU, autocreate ist deaktiviert => Device wird im "CUL_HM-Way" angelegt (=>kein FileLog), IO-Attribute "VCCU-like"
h) pairing vom User angestoßen, VCCU, autocreate ist aktiviert => Device soll angelegt werden, FileLog wird entsprechend autocreate-Vorgabe erstellt, IO-Attribute "VCCU-like"
Mit etwas Glück sollte die angehängte Fassung diese Szenarien entsprechend abbilden. @MadMax-FHEM: Könntest du das bitte mal durchspielen, ob das paßt? (Bitte wieder mit einem Testsystem anfangen...)
EDIT:
Nach etwas Nachdenken soll autocreate nicht angestoßen werden, wenn das pairing nicht läuft => nur noch Schreiben eines entsprechenden Log-Eintrags.
...und hier noch eine leicht veränderte Variante für HMLAN:
Da wird dann bei einem normalen FHEM-Start HMLAN_DoInit() erst in der NotifyFn() aufgerufen, aber früher wie die CUL_HM NotifyFn(), so dass der HMLAN dann jeweils bereits mit der richtigen hmId gestartet sein sollte, bevor dann die Initialisierung von CUL_HM aus stattfindet.
Bin zwar mal wieder nicht sicher, ob das viel hilft, aber sauberer ist es mAn. jedenfalls...
hast du auch an mehrere vccu gedacht?
Zitat von: frank am 25 Oktober 2021, 13:29:12
hast du auch an mehrere vccu gedacht?
Zumindest kurz :) .
Genauer meine ich, dass es so zu lesen ist:
keine VCCU = für das IODev ist keine VCCU zuständig,
VCCU = das IODev steht unter der Kontrolle einer VCCU
Ob das für das "Abfangen" mit einer VCCU (weiter hinten) auch klappt, wenn das "falsche" IODev die Daten reinspielt, habe ich aber nicht intensiver beleuchtet, da kann es theoretisch Lücken geben, die aber nicht gravierend sein sollten...
beim anlegen einer 2. vccu, wurde dieser zumindestens neulich ein io zugewiesen, das bereits der 1. vccu gehörte.
Danke für den Hinweis, da hatte die neu eingeführte Prüfung wohl den falschen Bezugspunkt ::) . Jetzt sollte es passen (update im "autocreate"-Beitrag).
Bisher sind Rückmeldungen eher spärlich gekommen, obwohl es ein paar downloads gab...
Folgende Probleme sind bekannt:
- CUL_HM ist definitiv nicht rereadcfg-fest, und ich habe auf die Schnelle auch keine Idee, wie man es reparieren könnte (siehe https://forum.fhem.de/index.php/topic,123608.msg1182501.html#msg1182501)
- "A112" (wobei mir unklar ist, ob das ein neues oder altes Thema ist, und wer der eigentliche Verursacher)
Zitat von: frank am 26 Oktober 2021, 17:19:49
so mittlerweile mit neuerem cul_hm gibt es probleme bei einem getconfig.
wenn der hmuart sendet, wird kein A112 gesendet, sodass der vd einschläft.
Ist die jeweils letzte Version von CUL_HM denn jetzt "vorschlagsfähig", was "autocreate" angeht? Was ist mit HMLAN? Dann wäre es Zeit, mal je einen patch draus zu machen und den ersten Beitrag upzudaten...
Zitat von: Beta-User am 26 Oktober 2021, 17:46:12
Bisher sind Rückmeldungen eher spärlich gekommen, obwohl es ein paar downloads gab...
Man kommt ja kaum mit dem Testen hinterher ;)
Wobei ich noch nicht mal zu denen gehöre, die runtergeladen haben...
...aktuell leider unterwegs, da wird das mit Testen schwer :-\
Aber ich werde das bzgl. autocreate mal durchschauen/-testen...
Gruß, Joachim
ZitatIst die jeweils letzte Version von CUL_HM denn jetzt "vorschlagsfähig", was "autocreate" angeht? Was ist mit HMLAN? Dann wäre es Zeit, mal je einen patch draus zu machen und den ersten Beitrag upzudaten...
sorry, aber nachdem ich im letzten update von martin keine änderungen der aktuellen probleme im diff gesehen habe, bin ich aus dem testen der versionen aus svn/oktober-patches wieder ausgestiegen.
es ist mir zu umständlich dauernd meine eigenen logmeldungen wieder einzubauen, um weitere probleme aufzuspüren.
verbesserungen baue ich bei mir natürlich auch ein.
allerdings habe ich autocreate nicht probiert, da ich an den einbau durch martin nicht wirklich glaube. ;)
keine meldungen sind gute meldungen. :)
danke für deine bemühungen
ps: neulich gab es in 00_hmlan 2x "Clients". absicht?
Hallo,
seit dem letzten Update habe ich folgendes Problem und an den Attributen oder DOIF habe ich nichts geändert:
Ich habe an einen HM-LC-SW1PBU-FM einen HM-SEN-MDIR-WM55 gepeert, sodass der Bewegungsmelder das Licht steuert.
Seit dem Update schaltet der Bewegungsmelder das Licht nicht mehr an. Und wenn ich es am Schalter anschalte und der Bewegungsmelder eine Bewegung erkennt schaltet das Licht wieder aus!
Wie kann man das wieder heilen?
Gruß
Udo
ZitatIch habe an einen HM-LC-SW1PBU-FM einen HM-SEN-MDIR-WM55 gepairt, sodass der Bewegungsmelder das Licht steuert.
du meinst also gepeert.
dann ist aber fhem fein raus, und es liegt nicht am update.
da haben sich vermutlich die register im aktor geändert. eventuell ein reset gemacht?
ich denke du machst am besten einen eigenen thread auf und postest dort mal je ein list von beiden.
Stichwort levelInverse?
ZitatStichwort levelInverse?
gute idee.
dann also schalter richtig einbauen und register anpassen.
alternative für umweltsünder: die aktuellen patches plus "attr param levelInverse"
Zitat von: Beta-User am 26 Oktober 2021, 19:51:09
Stichwort levelInverse?
Ja und warum, hat doch die ganze Zeit ohne Level Inverse funktioniert?!
Zitat von: Udomatic am 26 Oktober 2021, 20:13:41
Ja und warum, hat doch die ganze Zeit ohne Level Inverse funktioniert?!
Show us!
Bitte in cfg vor dem update schauen.
Zitat von: Beta-User am 26 Oktober 2021, 20:22:02
Show us!
Bitte in cfg vor dem update schauen.
Ok, hier gehts weiter
https://forum.fhem.de/index.php/topic,123688.0.html (https://forum.fhem.de/index.php/topic,123688.0.html)
ZitatIst die jeweils letzte Version von CUL_HM denn jetzt "vorschlagsfähig", was "autocreate" angeht?
wahrscheinlich nein.
Zitatpairing nicht vom User angestoßen,...
was meinst du damit?
das kann doch eigentlich nur bedeuten, dass du den empfang einer anlernmessage meinst, was aber kein pairing ist.
also definiert jede anlernmessage vom nachbarn ein device in fhem. sicherlich ohne attr ignore=1, oder?
das wiederum bedeutet, dass hminfo configcheck ziehmlich umfangreich wird, oder übersehe ich gerade was ;)
dann wird wohl auch jedem device ein io assigned. bin nicht sicher, ob das dann beim nachbarn reinquatscht.
hast du mal ein list von so einem device? am besten vor und nach restart.
ständig rote fragezeichen? da wird es hier aber viele threads geben.
eine echte ccu speichert auch keine nachbar devices.
Details müssen wir uns nochmal ansehen.
Es ist kein direktes Nutzen von autocreate wie in der Intro dargestellt, eher ein Tricksen wie ZWave das macht, das ganze aber immer unter den "alten" Voraussetzungen, so dass zumindest keine neuen Probleme entstehen sollten.
Diff sind im ersten Post. Mehr Details ein anderes Mal.
Update des HMLAN läuft bei mir ohne Probleme.
Ergänzung: Ich setze eine vccu mit zwei IO, dem HMLAN und einem CUL, ein.
Zitat von: Timmäää am 27 Oktober 2021, 08:08:28
Update des HMLAN läuft bei mir ohne Probleme.
Danke für die Rückmeldung, dann werde ich Martin mal anpingen wg. FHEM 6.1 - CUL_HM+ ist damit die letzte Hürde.
Anbei dann eine Version, die wenigstens ins Log schreibt, dass CUL_HM nicht rereadcfg-fest ist... (sonst nichts neues)
Zu dem autocreate-Thema:
Zitat von: frank am 26 Oktober 2021, 21:33:36
was meinst du damit?
das kann doch eigentlich nur bedeuten, dass du den empfang einer anlernmessage meinst, was aber kein pairing ist.
Nach wie vor tue ich mich schwer, den Funkverkehr und den Code ohne weiteres in Deckung zu bringen ::) . Mein Ausgangspunkt ist die von Martin vercodete Fallunterscheidung (#1748)
if(!$mh{devH} && $mh{mTp} eq "00") { # generate device ?Die aktuelle svn-Fassung (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_CUL_HM.pm#L1742) führt in so einem Fall immer ein CommandDefine() aus, was m.E. nicht in jedem Fall erwünscht ist.
Ergo ist der Vorschlag, das nur zu machen, wenn entweder die "zuständige" VCCU oder das IODev im pairing-Modus sind, oder das allgemeine autocreate aktiv (über diesen letzten Punkt kann man m.E. diskutieren, über den Weg bis dahin eigentlich nicht, oder?).
Über Fernwirkungen habe ich bisher nicht weiter nachgedacht, da bis hierhin eigentlich eher alles "beim alten" sein sollte...
Zitat
also definiert jede anlernmessage vom nachbarn ein device in fhem. sicherlich ohne attr ignore=1, oder?
Ob man bei nicht-laufendem pairing dann attr ignore setzen sollte, ist eine gute Frage (oder doch das autocreate ignorieren?). Im Moment ist es so gedacht, dass autocreate nur stattfindet, wenn keine VCCU zuständig ist, die das als "unknown_AB3456" einfangen würde.
Zitatdas wiederum bedeutet, dass hminfo configcheck ziehmlich umfangreich wird, oder übersehe ich gerade was ;)
Vermutlich; aber eben nur, wenn keine VCCU vorhanden ist (=>selber schuld...?)
Zitatdann wird wohl auch jedem device ein io assigned. bin nicht sicher, ob das dann beim nachbarn reinquatscht.
Unschön. Bin für Vorschläge offen ;) .
Zitat
eine echte ccu speichert auch keine nachbar devices.
Das mag ja sein, aber ist der Vorschlag, "unknown_.*" in der VCCU abzuschaffen? Oder ist es nur eine Begründung, warum man den Zweig
} elsif (!IsDisabled((devspec2array('TYPE=autocreate'))[0]) && !defined InternalVal($mh{ioName},'owner_CCU',undef)) {nicht ausführen sollte? (bzw. stattdessen eine Zeile ins Log schreiben mit Hinweis auf "pairing nicht aktiv, bitte VCCU definieren oder pairing-Modus aktivieren"?).
EDIT: Nach etwas Nachdenken finde ich die "schreib was ins log"-Variante eigentlich die beste. Der User bekommt einen deutlichen Hinweis, wenn er ins log schaut, es werden keine unnötigen Devices angelegt, und wir haben auch noch eine Option, auf CCU-FHEM hinzuweisen...
EDIT2: HMLAN sollte jetzt auch beim define was ins log schreiben...
Zitat von: frank am 26 Oktober 2021, 17:19:49
so mittlerweile mit neuerem cul_hm gibt es probleme bei einem getconfig.
wenn der hmuart sendet, wird kein A112 gesendet, sodass der vd einschläft.
[...]
entweder ansgars optimierungen sind nie eingeflossen, oder sie sind wieder kaputt.
schade eigentlich.
Zu einem großen Teil waren die betreffenden Codevorschläge von noansi nicht im aktuellen CUL_HM drin. An einer Stelle scheint was eingeflossen zu sein, es gab aber vor meinem genau einen Download der kompletten CUL_HM, das wirst dann du gewesen sein.
Anbei der Versuch, das zu integrieren, an einer Stelle war m.E. keine Änderung notwendig, ansonsten _könnte_ das so passen, richtig Testen (und ein aktualisiertes diff liefern) kann ich aber auch erst wieder frühestens heute abend. (Status daher ausdrücklich: experimentell!).
Auch, wenn wir alle des Testens möglicherweise müde sind: Wie immer wäre es toll, wenn sich jemand finden würde, der das Risiko eingehen kann und mag...
Nachtrag noch zur Frage der "doppelten Clients" in HMLAN: Das ist m.E. kein Problem, da geht es einmal um den Code-Hash, und einmal um den Instanz-Hash. Jedenfalls in letzterem ist es erforderlich, wenn man es nicht in CU_HM fixen will, und anscheinend schadet es auch nicht, wenn es zusätzlich im Instanz-Hash steht.
Zitat von: frank am 26 Oktober 2021, 19:39:13
scheinbar werden die io nicht unassigned, wenn man ein device auf ignore setzt, denn hmlan2 sendet weiterhin autonom die uhrzeit an 303AF8.
ein neuer bug.
Sorry, hatte ich irgendwie zu spät wieder auf dem Schirm, daher gleich noch ein update, das auch das noch beseitigen könnte. (Ist aber eher ein "fix auf Verdacht"...). die Idee dahinter ist, dem betreffenden Gerät kein IO zuzuweisen, ich bin nicht ganz sicher, ob da auf dem gewählten Weg auch klappt ::) .
PS: Danke für die schnellen Downloads aus dem letzten Post!
moin,
erst mal kurz zu a112:
ansgars version aus
#47 ist meiner meinung nach der beste kompromiss gewesen. diese version habe ich dann sehr lange genutzt, bis zu einer svn version ende september mit attribut-check.
ich vermute, dass der grosse auskommentierte codeblock am ende von cul_hm_assignio anhaltspunkte geben könnte. nicht umsonst hat martin hier so viel alten code aufbewahrt. ;)
ZitatAuch, wenn wir alle des Testens möglicherweise müde sind
vor allem sinnloses, weil unnötiges, testen macht mich besonders müde. :-\
dieses problem ist ja super speziell und erfordert viele tests, da alle möglichen kombinationen von unterschiedlichen io in 2 verschiedenen devices eine rolle spielen. bei mir 3x3=9 kombinationen, die jeweils ziehmlich lange dauern und anschliessend aufwändig analysiert werden müssen.
da will ich eigentlich erstmal herausfinden, was ansgar wirklich gemacht hat, um auch später in martins versionen vorab sehen zu können, ob und vor allem was er wie übernommen hat.
ich finde deinen einsatz wirklich wunderbar, aber bitte keine schnellschüsse.
ansgars deutliche zurückhaltung seit nun schon längerer zeit lässt mich auch viel spekulieren.
ps: zu ignore
Zitatdie Idee dahinter ist, dem betreffenden Gerät kein IO zuzuweisen
vor allem muss das gerät aus dem io entfernt werden (remove), wenn man das attribut ignore setzt.
edit: da war die reihenfolge der absätze durcheinandergeraten.
Zitat von: frank am 27 Oktober 2021, 12:31:02
erst mal kurz zu a112:
ansgars version aus #47 ist meiner meinung nach der beste kompromiss gewesen. diese version habe ich dann sehr lange genutzt, bis zu einer svn version ende september mit attribut-check.
Hmm, der Teil war eigentlich schon länger in "meiner" Patch-Sammlung drin, wenn ich den Überblick nicht komplett verloren habe...
Ggf. müßten dann die Änderungen von heute morgen teiweise wieder raus? (Da hatte ich leider deinen heutigen Hinweis im anderen Thread offenbar falsch verstanden, dass das noch nicht gefixt sei.)
Zitat
ich vermute, dass der grosse auskommentierte codeblock am ende von cul_hm_assignio anhaltspunkte geben könnte. nicht umsonst hat martin hier so viel alten code aufbewahrt. ;)
Anhaltspunkte vielleicht, aber ich bin auch etwas müde, was raten angeht...
Zitat
ps: zu ignorevor allem muss das gerät aus dem io entfernt werden (remove), wenn man das attribut ignore setzt.
...auch wieder wahr... Es muss sowohl beim startup beachtet werden wie auch bei Änderung im laufenden Betrieb. Fix-Versuch anbei (direkter remove beim Setzen des Attributs, dto. für dummy). Eigentlich sollte das keine großen Tests erfordern, aber vermutlich übersehe ich wieder was...
Zitatich finde deinen einsatz wirklich wunderbar, aber bitte keine schnellschüsse.
ansgars deutliche zurückhaltung seit nun schon längerer zeit lässt mich auch viel spekulieren.
Fühle mich auch deutlich unwohl in der jetzigen Rolle und würde mich gerne wieder zurückziehen. Andererseits will ich die User auch nicht komplett alleine lassen.
Anbei ist eine Version mit #47 + den sonstigen Stand von hier zurückgeschraubt (also entfernt, was zwischen #47 und heute morgen aus ansgars letzter Version eingeflossen war).
ZitatAnbei ist eine Version mit #47 + den sonstigen Stand von hier zurückgeschraubt (also entfernt, was zwischen #47 und heute morgen aus ansgars letzter Version eingeflossen war).
den satz habe ich jetzt schon 6-7 mal gelesen, aber noch nicht wirklich durchschaut. :)
trotzdem mal getestet + 00_hmlan.
-grob drübergeschaut: A112 verhalten beim vd sieht bei allen 3 io identisch wie gestern aus.
-die verschobene hmlan doinit zeigt jetzt auch alle cmds.
-sonst keine auffälligkeiten
Zitat von: frank am 27 Oktober 2021, 17:25:54
den satz habe ich jetzt schon 6-7 mal gelesen, aber noch nicht wirklich durchschaut. :)
;D , ja, verständlich schreiben ist nicht so einfach. Gemeint war: die Version von noansi aus Post #47 (im Thread zu dem A112-Thema) war schon länger in die hier zusammengeführten Patches integriert. Das hatte ich heute morgen erst auf den Stand von der letzten von noansi geposteten Fassung aus den nämlichen Thread gebracht, in der irrigen Annahme, dass die besser sei wie die aus #47. Also habe ich das wieder auf den Ausgangsstand (= Fassung aus #47) zurückgedreht, was diese Teile angeht.
Was
Zitattrotzdem mal getestet + 00_hmlan.
-grob drübergeschaut: A112 verhalten beim vd sieht bei allen 3 io identisch wie gestern aus.
-die verschobene hmlan doinit zeigt jetzt auch alle cmds.
-sonst keine auffälligkeiten
betrifft, habe ich nun wieder ein kleines Verständnisproblem: Ist das betr. A112 jetzt insgesamt (=alle IO-Typen?) ok, oder insgesamt buggy...? (vermutlich eher letzteres!)
Sonst scheint es soweit erkennbar erst mal ok zu sein, oder verstehe ich wieder was falsch?
(PS: HMLAN sollte eigentlich u.A. auch alle von dir benannten Patches enthalten).
ZitatGemeint war: die Version von noansi aus Post #47 (im Thread zu dem A112-Thema) war schon länger in die hier zusammengeführten Patches integriert. Das hatte ich heute morgen erst auf den Stand von der letzten von noansi geposteten Fassung aus den nämlichen Thread gebracht, in der irrigen Annahme, dass die besser sei wie die aus #47. Also habe ich das wieder auf den Ausgangsstand (= Fassung aus #47) zurückgedreht, was diese Teile angeht.
ok, verstanden. 8)
ZitatSonst scheint es soweit erkennbar erst mal ok zu sein, oder verstehe ich wieder was falsch?
falsch verstanden. :)
das gezeigte fehlverhalten im vd thread ist mit deiner version hier aus #70 identisch. keine verbesserung/verschlechterung. #70 habe ich dann sogar noch ein 2. mal runtergeladen und verglichen.
das "normale" betreiben der vd ist weiterhin gut, also erstmal nichts dringendes.
eine saubere, fehlerfreie io zuordnung finde ich derzeit wichtiger.
wünsch dir mal ein paar events zum reading IODev. rudi hat eine abstimmung gestartet.
https://forum.fhem.de/index.php/topic,123655.msg1182673.html#msg1182673 (https://forum.fhem.de/index.php/topic,123655.msg1182673.html#msg1182673)
ZitatFix-Versuch anbei (direkter remove beim Setzen des Attributs, dto. für dummy). Eigentlich sollte das keine großen Tests erfordern, aber vermutlich übersehe ich wieder was...
konnte ich gerade nicht festellen.
das device ist zumindestens weiterhin unter "get assignIDs" beim hmlan zu finden. im log war auch nichts zusehen.
Zitat von: frank am 27 Oktober 2021, 20:20:20
konnte ich gerade nicht festellen.
das device ist zumindestens weiterhin unter "get assignIDs" beim hmlan zu finden. im log war auch nichts zusehen.
Hmm, dann müßte in diesem Teil noch irgendwo was versteckt sein, das ich auf die Schnelle nicht sehe (#1268ff):
if ($attrVal) {
IOWrite($hash, '', 'remove:'.$hash->{DEF}) if defined $hash->{IODev}->{TYPE} && $hash->{IODev}->{TYPE} =~ m/^HM(?:LAN|UARTLGW)$/s && defined $hash->{DEF};
delete $hash->{IODev};
delete $hash->{READINGS}{IODev};
} else {
CUL_HM_assignIO($hash) ;
}Kann das grade nur auf dem Testsystem checken, und da sehe ich zumindest, dass das Internal IODev gelöscht wird.
Zitat von: frank am 27 Oktober 2021, 18:04:58
das "normale" betreiben der vd ist weiterhin gut, also erstmal nichts dringendes.
Klingt insgesamt danach, als sollte/könnte ich Martin mal wieder aktiv anpingen...?
Zitateine saubere, fehlerfreie io zuordnung finde ich derzeit wichtiger.
Das ist dann in der Tat (leider) weiter eine Baustelle, die anscheinend für mich zu groß ist. Aber evtl. hat da ja jemand "Wissendes" dann auch vollends Ideen, wie man das dann noch gradeziehen kann ::) ?
moin,
ZitatHmm, dann müßte in diesem Teil noch irgendwo was versteckt sein, das ich auf die Schnelle nicht sehe (#1268ff):
scheinbar ein reihenfolgeproblem, wegen iowrite.
return if(IsDummy($dev) || IsIgnored($dev));den block habe ich jetzt ganz vorne platziert, unter
if ($cmd eq "set"){so erscheint bei dummy und ignore im eventmonitor/log
2021.10.28 14:01:29.709 0 : HMLAN_Send: hmlan1 I:-1A164B
2021-10-28 14:01:29.866 Global global ATTR SwitchPBU05 ignore 11. die dummy intergration scheint mir noch nicht ganz richtig zu sein, da diese devices nun auch attr .ignored erhalten.
2. attr .ignored verschwindet grundsätzlich nach restart, muss das so?
3. bereits länger ignored devices bekommen beim restart scheinbar trotzdem IODev, sogar mein test reading IODev_test über assignioport ist aktuell.
Internals:
DEF 266A86
FUUID 603510ca-f33f-09c4-9dc4-ec7b836712fa49ab
IODev cul868
NAME DimPBU01
NR 734
NTFY_ORDER 48-DimPBU01
STATE Info_Cleared
TYPE CUL_HM
channel_01 DimPBU01_Dim
channel_02 DimPBU01_Dim_V_01
channel_03 DimPBU01_Dim_V_02
disableNotifyFn 1
.attraggr:
.attreocr:
.*
.attrminint:
READINGS:
2021-04-17 23:55:11 .D-devInfo 110100
2021-04-17 23:55:11 .D-stc 20
2021-10-27 16:21:32 .associatedWith DimPBU01,DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,DimPBU01
2021-05-25 21:39:48 .protLastRcv 20210525213948
2021-06-14 15:50:30 Activity unknown
2021-04-15 15:22:36 CommandAccepted yes
from archivexx D-firmware 2.6
from archivexx D-serialNr KEQ1110205
2021-10-27 16:21:27 IODev cul868
2021-10-25 15:30:43 IODev_test cul868
2021-05-17 14:04:10 PairedTo 0x1ACE1F
2021-05-17 14:04:09 RegL_00. 00:00 02:81 0A:1A 0B:CE 0C:1F 15:FF 18:00 62:5A
2021-10-16 17:53:23 cfgState PairMiss
2021-10-14 16:29:53 commState Info_Cleared
2021-04-15 15:02:48 fwUpdate done
2021-04-18 08:20:51 powerOn 2021-04-18 08:20:51
2021-10-14 16:29:53 state Info_Cleared
helper:
HM_CMDNR 206
mId 0068
peerFriend -
peerOpt -:dimmer
regLst 0
rxType 1
cmds:
TmplKey :1635344497.7944:1635344492.37385
TmplTs 1635344492.37385
cmdKey 0:1:0::DimPBU01:0068:00:
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-]
getVersion noArg
pair noArg
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
tplDel -tplDel-
tplSet_0 -tplChan-
unpair noArg
lst:
condition slider,0,1,255
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 1
tpl 1
io:
flgs 0
newChn +266A86,00,00,00
rxt 0
vccu
p:
266A86
00
00
00
prefIO:
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
prs 1
tmpl:
Attributes:
.mId 0068
IOgrp ccu:hmlan1
actCycle 024:00
actStatus unknown
autoReadReg 5_readMissing
devStateIcon {CUL_HM_getIcon($name)}
event-on-change-reading .*
expert defReg,allReg,rawReg,templ
firmware 2.9
ignore 1
model HM-LC-DIM1TPBU-FM
room CUL_HM
serialNr KEQ1110205
subType dimmer
webCmd getConfig:clear msgEvents----------------
zwei ungereimtheiten zu cul_hm_assignio
soweit ich assignioport verstehe, ist es hauptsächlich zum setzen von attribut/reading IODev. ein übergebenes io, wird zudem eventuell auch aussortiert und ggf durch ein gefundenes, typgleiches ersetzt.
das ersetzen durch assignio kann ggf ungereimtheiten hervorrufen, denke ich.
1. nach dem ersten aufruf (wechsel) setzt cul_hm erneut hash/iodev. wenn assignioport nun ein anderes gewählt hat, stimmen reading und internal nicht mehr überein.
2. der zweite aufruf (ohne wechsel) sollte eigentlich überflüssig sein. ausserdem gibt es ärger, wenn gewechselt wurde.
eigentlich müsste man immer nach assignioport prüfen, ob dadurch ein io wechsel vorgenommen wurde.
wenn assignioport ein wechsel durchgeführt hat, stimmt im ersten fall nur das reading nicht und im zweiten fall ist das neue und alte io ggf nicht richtig präpariert.
mist, nach dem löschen von attr ignore, hat nun das device kein io im hash/iodev
und hminfo hat nach einem set hminfo update 4 warnings gemeldet
Internals:
DEF 1A164B
FUUID 5c4ce2ef-f33f-09c4-0a7b-916ab5f9f48c008a
IODev
LASTInputDev cul868
MSGCNT 3
NAME SwitchPBU05
NR 614
NTFY_ORDER 48-SwitchPBU05
STATE on
TYPE CUL_HM
chanNo 01
cul868_MSGCNT 1
cul868_RAWMSG A0E9480021A164B1ACE1F0101C8003A::-66:cul868
cul868_RSSI -66
cul868_TIME 2021-10-28 13:58:37
disableNotifyFn 1
hmlan1_MSGCNT 1
hmlan1_RAWMSG RC6C42D24,0001,185BBB4F,FF,FFC5,9480021A164B1ACE1F0101C8003A
hmlan1_RSSI -59
hmlan1_TIME 2021-10-28 13:58:37
hmuart1_MSGCNT 1
hmuart1_RAWMSG 050000459480021A164B1ACE1F0101C8003A
hmuart1_RSSI -69
hmuart1_TIME 2021-10-28 13:58:37
lastMsg No:94 - t:02 s:1A164B d:1ACE1F 0101C8003A
peerList Tuer.SZ,self01,self02
protCmdDel 1
protLastRcv 2021-10-28 13:58:37
protRcv 1 last_at:2021-10-28 13:58:37
protSnd 1 last_at:2021-10-28 13:58:37
protState CMDs_done
protdummy 1 last_at:2021-10-28 13:55:07
rssi_at_cul868 cnt:1 min:-66 max:-66 avg:-66 lst:-66
rssi_at_hmlan1 cnt:1 min:-59 max:-59 avg:-59 lst:-59
rssi_at_hmuart1 cnt:1 min:-69 max:-69 avg:-69 lst:-69
rssi_hmlan1 cnt:1 min:-58 max:-58 avg:-58 lst:-58
CL:
Authenticated 0
BUF
FD 80
FW_ID 2215
LASTACCESS 1635426319
NAME WEB_192.168.1.31_56468
NR 2257
PEER 192.168.1.31
PORT 56468
SNAME WEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-10-28 15:03:07 state Connected
READINGS:
2021-03-23 13:13:50 Activity alive
2021-03-23 15:37:15 CommandAccepted yes
from archivexx D-firmware 2.8
from archivexx D-serialNr JEQ0033112
2021-03-23 15:26:24 PairedTo 0x1ACE1F
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgActionType off
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgCtDlyOff geLo
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgCtDlyOn geLo
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgCtOff geLo
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgCtOn geLo
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgCtValHi 100
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgCtValLo 50
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgMultiExec on
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgOffDly 0 s
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgOffTime unused
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgOffTimeMode absolut
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgOnDly 0 s
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgOnTime unused
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgOnTimeMode absolut
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgSwJtDlyOff on
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgSwJtDlyOn on
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgSwJtOff dlyOn
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-lgSwJtOn on
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shActionType jmpToTarget
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shCtDlyOff geLo
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shCtDlyOn geLo
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shCtOff geLo
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shCtOn ltLo
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shCtValHi 100
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shCtValLo 50
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shMultiExec off
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shOffDly 0 s
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shOffTime unused
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shOffTimeMode absolut
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shOnDly 0 s
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shOnTime 10 s
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shOnTimeMode absolut
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shSwJtDlyOff off
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shSwJtDlyOn on
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shSwJtOff dlyOn
2021-10-05 09:55:04 R-Tuer.SZ_chn-01-shSwJtOn dlyOff
2021-10-04 17:56:34 R-intKeyVisib visib
2021-10-04 17:56:34 R-localResDis off
2021-10-04 17:56:34 R-pairCentral 0x1ACE1F
2021-10-04 17:56:34 R-powerUpAction off
2021-10-05 09:55:02 R-self01-lgActionType off
2021-10-05 09:55:02 R-self01-lgCtDlyOff geLo
2021-10-05 09:55:02 R-self01-lgCtDlyOn geLo
2021-10-05 09:55:02 R-self01-lgCtOff geLo
2021-10-05 09:55:02 R-self01-lgCtOn geLo
2021-10-05 09:55:02 R-self01-lgCtValHi 100
2021-10-05 09:55:02 R-self01-lgCtValLo 50
2021-10-05 09:55:02 R-self01-lgMultiExec on
2021-10-05 09:55:02 R-self01-lgOffDly 0 s
2021-10-05 09:55:02 R-self01-lgOffTime unused
2021-10-05 09:55:02 R-self01-lgOffTimeMode absolut
2021-10-05 09:55:02 R-self01-lgOnDly 0 s
2021-10-05 09:55:02 R-self01-lgOnTime unused
2021-10-05 09:55:02 R-self01-lgOnTimeMode absolut
2021-10-05 09:55:02 R-self01-lgSwJtDlyOff off
2021-10-05 09:55:02 R-self01-lgSwJtDlyOn off
2021-10-05 09:55:02 R-self01-lgSwJtOff off
2021-10-05 09:55:02 R-self01-lgSwJtOn dlyOff
2021-10-05 09:55:02 R-self01-shActionType jmpToTarget
2021-10-05 09:55:02 R-self01-shCtDlyOff geLo
2021-10-05 09:55:02 R-self01-shCtDlyOn geLo
2021-10-05 09:55:02 R-self01-shCtOff geLo
2021-10-05 09:55:02 R-self01-shCtOn geLo
2021-10-05 09:55:02 R-self01-shCtValHi 100
2021-10-05 09:55:02 R-self01-shCtValLo 50
2021-10-05 09:55:02 R-self01-shMultiExec off
2021-10-05 09:55:02 R-self01-shOffDly 0 s
2021-10-05 09:55:02 R-self01-shOffTime unused
2021-10-05 09:55:02 R-self01-shOffTimeMode absolut
2021-10-05 09:55:02 R-self01-shOnDly 0 s
2021-10-05 09:55:02 R-self01-shOnTime 86400 s
2021-10-05 09:55:02 R-self01-shOnTimeMode absolut
2021-10-05 09:55:02 R-self01-shSwJtDlyOff off
2021-10-05 09:55:02 R-self01-shSwJtDlyOn on
2021-10-05 09:55:02 R-self01-shSwJtOff dlyOn
2021-10-05 09:55:02 R-self01-shSwJtOn dlyOff
2021-10-05 09:54:58 R-self02-lgActionType off
2021-10-05 09:54:58 R-self02-lgCtDlyOff geLo
2021-10-05 09:54:58 R-self02-lgCtDlyOn geLo
2021-10-05 09:54:58 R-self02-lgCtOff geLo
2021-10-05 09:54:58 R-self02-lgCtOn geLo
2021-10-05 09:54:58 R-self02-lgCtValHi 100
2021-10-05 09:54:58 R-self02-lgCtValLo 50
2021-10-05 09:54:58 R-self02-lgMultiExec on
2021-10-05 09:54:58 R-self02-lgOffDly 0 s
2021-10-05 09:54:58 R-self02-lgOffTime unused
2021-10-05 09:54:58 R-self02-lgOffTimeMode absolut
2021-10-05 09:54:58 R-self02-lgOnDly 0 s
2021-10-05 09:54:58 R-self02-lgOnTime unused
2021-10-05 09:54:58 R-self02-lgOnTimeMode absolut
2021-10-05 09:54:58 R-self02-lgSwJtDlyOff on
2021-10-05 09:54:58 R-self02-lgSwJtDlyOn on
2021-10-05 09:54:58 R-self02-lgSwJtOff dlyOn
2021-10-05 09:54:58 R-self02-lgSwJtOn on
2021-10-05 09:54:58 R-self02-shActionType off
2021-10-05 09:54:58 R-self02-shCtDlyOff geLo
2021-10-05 09:54:58 R-self02-shCtDlyOn geLo
2021-10-05 09:54:58 R-self02-shCtOff geLo
2021-10-05 09:54:58 R-self02-shCtOn geLo
2021-10-05 09:54:58 R-self02-shCtValHi 100
2021-10-05 09:54:58 R-self02-shCtValLo 50
2021-10-05 09:54:58 R-self02-shMultiExec off
2021-10-05 09:54:58 R-self02-shOffDly 0 s
2021-10-05 09:54:58 R-self02-shOffTime unused
2021-10-05 09:54:58 R-self02-shOffTimeMode absolut
2021-10-05 09:54:58 R-self02-shOnDly 0 s
2021-10-05 09:54:58 R-self02-shOnTime unused
2021-10-05 09:54:58 R-self02-shOnTimeMode absolut
2021-10-05 09:54:58 R-self02-shSwJtDlyOff on
2021-10-05 09:54:58 R-self02-shSwJtDlyOn on
2021-10-05 09:54:58 R-self02-shSwJtOff dlyOn
2021-10-05 09:54:58 R-self02-shSwJtOn on
2021-10-04 17:56:34 R-sign off
2021-10-04 17:56:34 R-statusInfoMinDly 0.5 s
2021-10-04 17:56:34 R-statusInfoRandom 0 s
2021-10-04 17:56:34 R-transmitTryMax 5
2021-10-05 09:54:54 RegL_00. 00:00 02:81 0A:1A 0B:CE 0C:1F 15:FF 18:00
2021-10-05 09:54:56 RegL_01. 00:00 08:00 30:05 56:00 57:01
2021-10-05 09:55:04 RegL_03.Tuer.SZ_chn-01 00:00 02:00 03:02 04:32 05:64 06:00 07:2A 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:20 8B:13 8C:33
2021-10-05 09:55:02 RegL_03.self01 00:00 02:00 03:00 04:32 05:64 06:00 07:F8 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:20 8B:64 8C:66
2021-10-05 09:54:58 RegL_03.self02 00:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:00 0B:13 0C:33 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:20 8B:13 8C:33
2021-10-24 14:40:04 cfgState ok
2021-10-28 13:58:37 commState CMDs_done
2021-10-28 13:58:37 deviceMsg on (to ccu)
2021-10-28 13:58:37 level 100
2021-10-28 13:58:37 pct 100
2021-10-28 13:54:48 peerList Tuer.SZ,self01,self02
2021-10-28 01:11:19 recentStateType ack
2021-10-28 13:58:37 state on
2021-10-27 20:12:36 timedOn off
- tmpl_self01:long ignore,
- tmpl_self01:short toggleOn-for-timerOff_switch:onTime:86400,
- tmpl_self02:long ignore,
- tmpl_self02:short ignore,
2021-10-18 01:11:19 trigLast fhem:02
2021-10-17 11:04:06 trig_Tuer.SZ Closed_1
helper:
HM_CMDNR 148
cSnd ,111ACE1F1A164B0201C80000
dlvlCmd ++A0111ACE1F1A164B0201C80000
lastMsgTm 1635422317.69535
mId 0069
peerFriend peerSens,peerVirt
peerIDsState complete
peerOpt 3:switch
regLst 0,1,3p
rxType 1
supp_Pair_Rep 0
tmplChg 0
cmds:
TmplKey Tuer.SZ,self01,self02:1635422092.56006:1635422092.95002
TmplTs 1635422092.95002
cmdKey 1:1:0::SwitchPBU05:0069:01:Tuer.SZ,self01,self02
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
eventL -peer- -cond-
eventS -peer- -cond-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
getVersion noArg
inhibit [(on|{off})]
off noArg
on noArg
on-for-timer -ontime-
on-till -time-
pair noArg
peerBulk -peer1,peer2,...- [({set}|unset)]
peerIODev [IO] -btn- [({set}|unset)] 'not for future use'
peerSmart -peerOpt-
press [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{self01})]
pressS [(-peer-|{self01})]
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
statusRequest noArg
toggle noArg
tplDel -tplDel-
tplPara010_self01_short_toggleOn-for-timerOff_switch_onTime -value-
tplSet_0 -tplChan-
tplSet_Tuer.SZ -tplPeer-
tplSet_self01 -tplPeer-
tplSet_self02 -tplPeer-
unpair noArg
lst:
condition slider,0,1,255
peer Tuer.SZ,self01,self02
peerOpt remove_Tuer.SZ_chn-01,Fenster.Bad,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU02_Btn_01,SwitchPBU02_Btn_02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.AZ.West_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,ccu_Btn2,ccu_Btn3,ccu_Btn4,ccu_Btn5,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1,virt_vd_Btn1
tplChan ES_00,ES_device,sw99,test,test01
tplDel self01:long>ignore,self02:long>ignore,self02:short>ignore,self01:short>toggleOn-for-timerOff_switch
tplPeer SwCondAbove_long,SwCondAbove_short,SwCondBelow_long,SwCondBelow_short,SwOff_long,SwOff_short,SwOnCond_long,SwOnCond_short,SwOn_long,SwOn_short,SwToggleIgnore,SwToggle_long,SwToggle_short,autoOff_long,autoOff_short,ignore_long,ignore_short,motionOnSw_long,motionOnSw_short,off-for-timer_switch_long,off-for-timer_switch_short,toggleOn-for-timerOff_switch_long,toggleOn-for-timerOff_switch_short
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 1
io:
flgs 0
newChn +1A164B,00,00,00
nextSend 1635422317.9717
rxt 0
vccu ccu
p:
1A164B
00
00
00
prefIO:
hmlan1
mRssi:
mNo 94
io:
cul868:
-66
-66
hmlan1:
-53
-53
hmuart1:
-69
-69
peerIDsH:
00000000 broadcast
1A164B01 self01
1A164B02 self02
1DE62001 Tuer.SZ_chn-01
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rssi:
at_cul868:
avg -66
cnt 1
lst -66
max -66
min -66
at_hmlan1:
avg -59
cnt 1
lst -59
max -59
min -59
at_hmuart1:
avg -69
cnt 1
lst -69
max -69
min -69
hmlan1:
avg -58
cnt 1
lst -58
max -58
min -58
shadowReg:
tmpl:
self01:long>ignore
self01:short>toggleOn-for-timerOff_switch 86400
self02:long>ignore
self02:short>ignore
Attributes:
IOgrp ccu:hmlan1
actCycle 024:00
actStatus alive
alias Lampe_Kueche_AP
autoReadReg 5_readMissing
commStInCh off
comment c26 ausgewechselt: 2020-04-27
event-on-change-reading .*
expert defReg,allReg,rawReg,templ
firmware 2.8
group Beleuchtung
model HM-LC-SW1PBU-FM
peerIDs 00000000,1A164B01,1A164B02,1DE62001
room 02_handy,30_Kueche
serialNr JEQ0033112
subType switch
timestamp-on-change-reading .*
webCmd :
2021.10.28 14:54:45.495 3 : HMinfo hminfo get:update :
2021.10.28 14:54:45.629 1 : PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_HMinfo.pm line 379.
2021.10.28 14:54:45.630 1 : stacktrace:
2021.10.28 14:54:45.631 1 : main::__ANON__ called by ./FHEM/98_HMinfo.pm (379)
2021.10.28 14:54:45.632 1 : main::HMinfo_status called by ./FHEM/98_HMinfo.pm (1939)
2021.10.28 14:54:45.632 1 : main::HMinfo_SetFn called by ./FHEM/98_HMinfo.pm (499)
2021.10.28 14:54:45.633 1 : main::HMinfo_autoUpdate called by fhem.pl (3427)
2021.10.28 14:54:45.633 1 : main::HandleTimeout called by fhem.pl (695)
2021.10.28 14:54:45.634 1 : PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_HMinfo.pm line 379.
2021.10.28 14:54:45.635 1 : stacktrace:
2021.10.28 14:54:45.635 1 : main::__ANON__ called by ./FHEM/98_HMinfo.pm (379)
2021.10.28 14:54:45.636 1 : main::HMinfo_status called by ./FHEM/98_HMinfo.pm (1939)
2021.10.28 14:54:45.637 1 : main::HMinfo_SetFn called by ./FHEM/98_HMinfo.pm (499)
2021.10.28 14:54:45.637 1 : main::HMinfo_autoUpdate called by fhem.pl (3427)
2021.10.28 14:54:45.638 1 : main::HandleTimeout called by fhem.pl (695)
2021.10.28 14:54:45.638 1 : PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_HMinfo.pm line 379.
2021.10.28 14:54:45.639 1 : stacktrace:
2021.10.28 14:54:45.640 1 : main::__ANON__ called by ./FHEM/98_HMinfo.pm (379)
2021.10.28 14:54:45.640 1 : main::HMinfo_status called by ./FHEM/98_HMinfo.pm (1939)
2021.10.28 14:54:45.641 1 : main::HMinfo_SetFn called by ./FHEM/98_HMinfo.pm (499)
2021.10.28 14:54:45.642 1 : main::HMinfo_autoUpdate called by fhem.pl (3427)
2021.10.28 14:54:45.642 1 : main::HandleTimeout called by fhem.pl (695)
2021.10.28 14:54:45.643 1 : PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_HMinfo.pm line 379.
2021.10.28 14:54:45.643 1 : stacktrace:
2021.10.28 14:54:45.644 1 : main::__ANON__ called by ./FHEM/98_HMinfo.pm (379)
2021.10.28 14:54:45.645 1 : main::HMinfo_status called by ./FHEM/98_HMinfo.pm (1939)
2021.10.28 14:54:45.645 1 : main::HMinfo_SetFn called by ./FHEM/98_HMinfo.pm (499)
2021.10.28 14:54:45.646 1 : main::HMinfo_autoUpdate called by fhem.pl (3427)
2021.10.28 14:54:45.646 1 : main::HandleTimeout called by fhem.pl (695)
meine zeile 379
next if($_ !~ m /at_.*$ehash->{IODev}->{NAME}/ );#ignore unused IODev
wahrscheinlich das selbe problem, wie vorher, nun mit cul_hm_assignio, das nun zu früh ist.
so funktioniert jetzt "attr ignore 1|0", aber nicht das löschen des attributs
elsif($attrName eq "ignore" || $attrName eq "dummy"){
if ($cmd eq "set"){
if ($attrVal) {
IOWrite($hash, '', 'remove:'.$hash->{DEF}) if defined $hash->{IODev}->{TYPE} && $hash->{IODev}->{TYPE} =~ m/^HM(?:LAN|UARTLGW)$/s && defined $hash->{DEF};
delete $hash->{IODev};
delete $hash->{READINGS}{IODev};
}
$attr{$name}{".ignoreSet"} = $attrVal; # remember user desire
foreach my $chNm(CUL_HM_getAssChnNames($name)){
if( $attrVal == 1){
$attr{$chNm}{$attrName} = 1;
if ($modules{CUL_HM}{helper}{primary} eq $chNm){#we need to find a new primary
CUL_HM_primaryDev();
}
}
elsif( defined $attr{$chNm}{".ignoreSet"}){
$attr{$chNm}{$attrName} = $attr{$chNm}{".ignoreSet"};
}
else{
delete $attr{$chNm}{$attrName};
}
}
if (!$attrVal) {
CUL_HM_assignIO($hash);
}
}
Zitat von: frank am 28 Oktober 2021, 14:49:42
moin,
scheinbar ein reihenfolgeproblem, wegen iowrite.
return if(IsDummy($dev) || IsIgnored($dev));
den block habe ich jetzt ganz vorne platziert, unter
if ($cmd eq "set"){
OK, macht Sinn! Danke für's aufspüren!
Zitat
so erscheint bei dummy und ignore im eventmonitor/log
2021.10.28 14:01:29.709 0 : HMLAN_Send: hmlan1 I:-1A164B
2021-10-28 14:01:29.866 Global global ATTR SwitchPBU05 ignore 1
Das ist schon mal was...
Zitat
1. die dummy intergration scheint mir noch nicht ganz richtig zu sein, da diese devices nun auch attr .ignored erhalten.
2. attr .ignored verschwindet grundsätzlich nach restart, muss das so?
Punkt 1 sollte weitgehend korrigiert sein. Beim jetzigen Drüberschauen fand ich überhaupt keine Erklärung, warum dieses versteckte Attribut überhaupt gesetzt wird, und auch die Abfragelogik erschließt sich mir grade nicht. Es macht zwar uU. Sinn, dann auch die Kanaldevices auf dummy/ignored zu setzen, aber den Hilfswert braucht man danach eigentlich nicht, und die Abfrage an sich scheint ins Leere zu gehen. Übersehe vermutlich wieder was...
Jedenfalls dürfte es nicht zu den "erlaubten" Attributen gehören und ist daher nicht Neustart-fest. Tendenziell würde ich es ausbauen/so umbauen, dass das nach der Erfüllung der Hilfsfunktion auch wieder weg ist, aber das sieht so aus, als hätte da jemand noch was vorgehabt?
Wie dem auch sei, meine eigentliche Absicht, das auf diesem Weg "abfangen" zu können, scheint halbwegs zielführend gewesen zu sein. Hätte mich fast gewundert, wenn es auf's erste Mal geklappt hätte ::) .
Zitat
3. bereits länger ignored devices bekommen beim restart scheinbar trotzdem IODev, sogar mein test reading IODev_test über assignioport ist aktuell.
Dazu habe ich noch keine Idee und fürchte, das kommt aus fhem.pl. Die Frage ist aber, ob das stört, weil jedenfalls CUL_HM im Optimalfall ja weiß, welche Devices bei welchem IO registriert werden müssen (wg. der Acks etc.). Und das sollte jedenfalls bis dahin entfallen sein(?). Reines Empfangen sollte nicht stören. (Übersehe ich ...?)
Zitat
----------------
zwei ungereimtheiten zu cul_hm_assignio
soweit ich assignioport verstehe, ist es hauptsächlich zum setzen von attribut/reading IODev. ein übergebenes io, wird zudem eventuell auch aussortiert und ggf durch ein gefundenes, typgleiches ersetzt.
das ersetzen durch assignio kann ggf ungereimtheiten hervorrufen, denke ich.
1. nach dem ersten aufruf (wechsel) setzt cul_hm erneut hash/iodev. wenn assignioport nun ein anderes gewählt hat, stimmen reading und internal nicht mehr überein.
2. der zweite aufruf (ohne wechsel) sollte eigentlich überflüssig sein. ausserdem gibt es ärger, wenn gewechselt wurde.
eigentlich müsste man immer nach assignioport prüfen, ob dadurch ein io wechsel vorgenommen wurde.
wenn assignioport ein wechsel durchgeführt hat, stimmt im ersten fall nur das reading nicht und im zweiten fall ist das neue und alte io ggf nicht richtig präpariert.
Sehr aufschlussreicher Befund!
Wir nähern uns m.E. des Pudels Kern. Ich habe den Bereich um #10942ff jetzt mal dahingehend umgebaut, dass eigentlich was im Log zu finden sein sollte, wenn fhem.pl den Vorschlag von CUL_HM ignoriert und was anderes assigned. Der Konflikt ist jetzt so herum gelöst, dass CUL_HM die Entscheidung von fhem.pl akzeptiert. Gefällt vermutlich Martin nicht, aber dies v.a., weil es der einfachere Weg war und wir m.E. erst mal feststellen müssen, wann das (warum?) passiert...
EDIT: den 2. Punkt habe ich vermutlich noch nicht ganz gedanklich durchdrungen...
Den "delete"-Fall hoffe ich repariert zu haben.
Edit: Bzgl. "delete" bei den Attributen sollte auch https://forum.fhem.de/index.php/topic,120328.msg1148467.html#msg1148467 (https://forum.fhem.de/index.php/topic,120328.msg1148467.html#msg1148467) jetzt gelöst sein?
Zitat von: frank am 28 Oktober 2021, 15:13:44
meine zeile 379
next if($_ !~ m /at_.*$ehash->{IODev}->{NAME}/ );#ignore unused IODev
Hmm, eigentlich sollte dann gleich der Teil gar nicht ausgewertet werden. Ein schnelles
last if !defined $ehash->{IODev}; davor sollte zumindest den Fehler verhindern...
Habe eben wieder einen kompletten Satz hochgeladen. Da sind die Änderungen von heute drin und evtl. auch was, was wieder ein, zwei Punkte von franks "offener-Punkte-Liste" holen könnte...
dummy und ignore funktionieren im prinzip. ob sie restart überleben wird sich noch zeigen.
bei dummy gibt es noch eine unklarheit.
wenn dummy, dann jetzt kein io mehr. dann sagt aber configcheck fehler:no io.
im prinzip ist das ja nun kein fehler, da ja absichtlich dummy gesetzt ist. andererseits ist es ja eine gute erinnerung, falls es nur vorübergehen geplant war.
wer nutzt es und wofür?
wenn die fehlermeldung bleiben soll, müsste nach dem ändern von dummy noch jeweils ein configcheck -f aufruf eingebaut werden, damit es automatisch kommt.
Bin unentschlossen.
Alternativ könnten wir bei dummy auch das letzte IO im Hash lassen und nur "deregistrieren"? Die prinzipielle Logik scheint ja jetzt zu passen, und an es wäre sowieso noch zu klären, ob die Automatik durch fhem.pl (es wird zumindest bei dummy ein IO beim Start zugewiesen, wenn eines vorhanden ist) irgendwelche unbeabsichtigten Nebenwirkungen hat. Oder reißen wir damit eine neue Lücke?
Muß mir das mal nochmal im Code ansehen, aber eigentlich wäre das doch ausreichend (wenn es nebenwirkungsfrei geht)?
(Sorry, dass das alles irgendwie grade so "Stückwerk" ist).
Weitere Meinungen?
hi,
bei mir gibt es drei phasen bei restart, in denen io in grösserer zahl zugewiesen werden.
das erste mal bei define.
da hier keine attribute existieren, wird jedem definierten device ein io zugeordnet. daher auch für ignore und dummy. ausgelöst durch cul_hm_assignio am ende von define, das könnte und sollte dort ersatzlos gestrichen werden, denke ich.
wenn jemand 100+ nachbar devices definiert hat...
edit: der erste sinnvolle zeitpunkt ist nach dem einlesen der readings, also nach dem save file.
edit2: dieser 2. block ist eigentlich auch zu früh vermutlich.
sinnvoll ist, wenn sowohl readings als auch alle relevanten attribute da sind. initial cleanup?
edit3: perfekt wäre der zeitpunkt, wenn 1. die readings da sind, und 2. die relevanten attribute zur ermittlung des gewünschten, optimalen io bereitstehen, und 3. wenn dies dann operabel ist. dann erst sollte cul_hm_assignio aufgerufen werden.
ich denke, da bräuchte es generell mal einen durchdachten ablaufplan.
mach dir mal meine geposteten logmeldungen in fhem.pl/setReadingsVal, damit du siehst, was ich meine.
https://forum.fhem.de/index.php/topic,123655.msg1182497.html#msg1182497 (https://forum.fhem.de/index.php/topic,123655.msg1182497.html#msg1182497)
Anbei mal wieder eine Testversion...
Zitat von: frank am 28 Oktober 2021, 23:11:41
hi,
bei mir gibt es drei phasen bei restart, in denen io in grösserer zahl zugewiesen werden.
das erste mal bei define.
da hier keine attribute existieren, wird jedem definierten device ein io zugeordnet. daher auch für ignore und dummy. ausgelöst durch cul_hm_assignio am ende von define, das könnte und sollte dort ersatzlos gestrichen werden, denke ich.
...irgendwie hat mich der dramatische Begleittext vor diesem assingio bisher davon abgehalten, da was zu ändern. Dabei habe ich vermutlich übersehen, dass das für die timerbasierte Variante wichtig war, und wir ja schon eine ganze Zeitlang andere Abläufe haben...
Jetzt also nur noch assignio an dieser Stelle, wenn kein IODev-Internal+$init_done? Damit sollten "echte" defines at runtime auch erfasst werden.
Zitat
wenn jemand 100+ nachbar devices definiert hat...
...sollte es jetzt helfen, dass bei der Initialisierung ignore und dummy beachtet werden? Zumindest beim Test sah das jetzt gut aus :) . Keine IODev-Internals mehr bei dummy=1 nach FHEM-Start, ignore sollte gleich sein.
Zitat
edit: der erste sinnvolle zeitpunkt ist nach dem einlesen der readings, also nach dem save file.
edit2: dieser 2. block ist eigentlich auch zu früh vermutlich.
sinnvoll ist, wenn sowohl readings als auch alle relevanten attribute da sind. initial cleanup?
Genau da müßte es jetzt eigentlich stattfinden :) .
Zitatedit3: perfekt wäre der zeitpunkt, wenn 1. die readings da sind, und 2. die relevanten attribute zur ermittlung des gewünschten, optimalen io bereitstehen, und 3. wenn dies dann operabel ist. dann erst sollte cul_hm_assignio aufgerufen werden.
...aus diesem Grund habe ich die NotifyFn mit höherer Prio versehen wie die aus CUL_HM. Eleganter wäre noansi's Vorschlag mit einer eigenen InitFn(), aufzurufen aus fhem.pl. Ggf. muss/sollte man sich Gedanken machen, wie das mit HMUARTLGW und TSCUL gehandhabt werden sollte (habe bisher in beide nicht reingeschaut).
Zitat
ich denke, da bräuchte es generell mal einen durchdachten ablaufplan.
mach dir mal meine geposteten logmeldungen in fhem.pl/setReadingsVal, damit du siehst, was ich meine.
https://forum.fhem.de/index.php/topic,123655.msg1182497.html#msg1182497 (https://forum.fhem.de/index.php/topic,123655.msg1182497.html#msg1182497)
Prinzipiell richtig, daher auch mein Aufgreifen des o.g. Vorschlags von noansi. Er hatte das Grundproblem ja sehr schön beschrieben, nur die logische Reihung von IO und Client fehlte da m.E. noch.
Ich werde leider über das WE vermutlich nicht dazu kommen, dieses Logging einzubauen und dann auch noch auszuwerten, zumal ich dann vermutlich auch noch "fliegende Devices" durch die Gegend tragen müßte. Als Minimallösung ist aber derzeit (seit gestern) zumindest mal ein CUL_HM-internes logging aktiviert, wenn es "komische" Wechsel gibt. An sich sollte es auch möglich sein, in CUL_HM/assignio selbst Wechsel zu loggen, ohne auf fhem.pl zurückgreifen zu müssen.
Jetzt wäre es m.E. erst mal sinnvoll, den jetzigen Stand auf "schlichte" Funktionalität zu prüfen.
CCU-FHEM kann man jetzt übrigens auch nur noch auf dummy/ignore setzen, wenn man vorher IOList löscht. Bitte um Rückmeldung, falls das eine blöde Idee gewesen sein sollte.
Wie immer wären daher mutige Tester gern gesehen :) , ich weise der guten Ordnung halber darauf hin, dass ich selbst das noch nicht im Echtsystem laufen lassen kann, geht erst irgendwann über das WE. Ich glaube zwar nicht, dass die Änderungen problematisch sind, aber wie üblich ist es leider nicht auszuschließen, dass ich was wichtiges übersehen haben könnte...
Testen heißt:
diese Version von CUL_HM.pm von hier
Rest von "ganz vorne"?
Weiß zwar niht wann ich dazu komme aber könnte heute klappen, zumindest mal Testsysteme...
Hauptsystem mal sehen.
Gruß, Joachim
P.S.: aktuell stehe ich auf 3 Systemen auf dem Stand von vor knapp 10 Tagen...
Ja, wobei die "Dringlichkeit" immer davon abhängt, was wann wie eingeflossen ist und was konkret im Einsatz ist...
Ich meine, der geänderte Ablauf bei der Initialisierung der IODev ist ein Anlass, die vorhin gepostete Version zu nehmen. Das gilt auch für "normale User", sobald der erste hier meldet, keine Probleme in seinem Echtsystem zu haben!
Zitat von: Beta-User am 29 Oktober 2021, 09:59:19
Ich meine, der geänderte Ablauf bei der Initialisierung der IODev ist ein Anlass, die vorhin gepostete Version zu nehmen. Das gilt auch für "normale User", sobald der erste hier meldet, keine Probleme in seinem Echtsystem zu haben!
Ok, "normaler User" da sehe ich mich mal ;)
Ich schaue mal, dass ich das bis heute Abend auch auf das Hauptsystem kriege und gebe Bescheid...
Gruß, Joachim
Zitat von: frank am 28 Oktober 2021, 21:19:12
wenn die fehlermeldung bleiben soll, müsste nach dem ändern von dummy noch jeweils ein configcheck -f aufruf eingebaut werden, damit es automatisch kommt.
Bin noch nicht sicher, welche Auswirkungen die letzte Änderung auf dieses spezielle Thema hat.
IODev wird zwar an dieser Code-Stelle im Moment nicht mehr gelöscht, dafür aber eben nach Neustart auch nicht mehr gesetzt => selbes "Problem" (aber mit autom. configcheck?).
Stellt sich die Frage, ob man ignore/dummy in HMinfo überhaupt behandeln sollte. Vorläufig würde ich das als Prio low ansehen. OK?
ich sag erstmal entwarnung.
meine logmeldungen zum reading iodev erfolgen nur noch einmal pro device. 40% weniger, prima.
leider immer noch auch für alle ignored devices.
das muss an den attributen/iodev,iogrp liegen, denke ich.
mit einem attr ".ignored" könnte man das wahrscheinlich umgehen, da dieses das jeweils erste attr wäre. ;)
...wenn man die Abfrage nach dem Richtigen IsXyz() macht, kommt hoffentlich auch bei ignore was richtiges raus ::) ... (ohne dass man weitere versteckte Attribute benötigt).
Da es bisher auch keine Prüfung auf "unnütz" bei Änderung der IOList der VCCU gab, habe ich das auch gleich noch ergänzt.
Damit sollten wir dann auch an der Stelle einen deutlichen Schritt nach vorne gekommen sein.
Danke für die Rückmeldung/Entwarnung!
Falls jemand einen diff -u zum svn Stand beisteuern könnte, würde ich gleich zu der jetzt in #1 zu findenden Version packen! Ist m.E. im Moment die deutlich beste, die wir haben...
wo sind die zusätzlichen ignore änderungen.
cul_hm im ersten post zeigt weiterhin io zuweisung bei ignored devices
dummy bleibt auch bei restart ok
Hmm, gg. dem ersten Stand ist Zeile 263 geändert:
CUL_HM_assignIO($h) if !IsDummy($name) && !IsIgnored($name);
Die sollte eigentlich beim Start die ignored rausfiltern. Wenn das nicht klappt, habe ich grade keine Idee, v.a. weil es ja in der Hinsicht keine Unterschiede zwischen beiden Varianten geben sollte und dummy (weiter) greift. ???
Dazu #1650 (neu)
next if IsDummy($HMdef) || IsIgnored($HMdef);
Die greift aber nur, wenn IODev-Attr gesetzt war. Vermutlich ist dann noch eine Lücke bei irgendeiner Indirektion via VCCU. Die bekomme ich aber vermutlich (schon allein aus Zeitgründen) selbst nicht aufgelöst.
So, nachdem hier alle pm-Dateien "verschwunden" sind hab ich die aus dem ersten Post eingespielt (die HMUARTLGW aus dem verlinkten Thread ist ja schon lange im Einsatz / auf den Testsystemen habe ich ja HMOD-PCB direkt und 1x per USB).
Schon vorher, also mit den "Patches" von so vor einer guten Woche habe ich immer wieder diese Einträge:
2021.10.29 17:05:39 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:05:44 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:05:49 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:05:54 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:05:59 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:04 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:09 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:14 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:19 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:24 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:29 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:34 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:39 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:44 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:49 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:54 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:06:59 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:04 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:09 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:14 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:19 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:24 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:29 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:34 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:39 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:44 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:49 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:54 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:07:59 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:08:04 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:08:09 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:08:14 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:08:19 3: HMinfo hminfo get:loadConfig :
2021.10.29 17:08:24 3: HMinfo hminfo get:loadConfig :
Ob das direkt nach dem Einspielen der Patches war kann ich leider nicht sagen (müsste mal das Log analysieren).
Bislang nur auf einem der Testsysteme...
Allerdings ist auf diesem Testsystem leider (aktuell) kein Homematic Gerät angelernt/vorhanden... :-\
Nur eben wegen Test (für den Fall, dass mein HM-USB-CFG2 mal kaputt geht) das HMOD-PCB dran.
HMINFO und vccu sind definiert...
Hier mal das list nach dem Einspielen der aktuellen Module und neustart:
Internals:
DEF AFFE22
FUUID 5e2de7e7-f33f-19f1-6e71-a8d8db1feaefb06d
FVERSION 10_CUL_HM.pm:?/2021-10-29 UNSTABLE
HM_UART_MSGCNT 96
HM_UART_RAWMSG 0500003CEF865A3229B500000098DB38
HM_UART_RSSI -60
HM_UART_TIME 2021-10-29 19:15:18
IODev HM_UART
LASTInputDev HM_UART
MSGCNT 96
NAME vccu
NR 154
NTFY_ORDER 48-vccu
STATE HM_UART:ok
TYPE CUL_HM
assignedIOs HM_UART
chanNo 01
disableNotifyFn 1
READINGS:
2021-10-29 19:06:32 IODev HM_UART
2021-10-29 19:06:38 IOopen 1
2021-10-29 19:06:38 state HM_UART:ok
2021-10-28 10:01:57 unknown_2ACA30 received
2021-10-27 11:02:45 unknown_2AD943 received
2021-10-27 11:56:43 unknown_2ADD14 received
2021-10-28 07:38:42 unknown_2ADD32 received
2021-10-27 16:23:50 unknown_2ADEB9 received
2021-10-29 19:13:41 unknown_2B1A82 received
2021-10-29 19:15:10 unknown_2B8E86 received
2021-10-29 19:13:27 unknown_2BA56B received
2021-10-29 19:14:41 unknown_2BBF72 received
2021-10-29 19:10:59 unknown_2C8BFC received
2021-10-29 19:14:58 unknown_2D9B77 received
2021-10-29 19:13:33 unknown_31D1FE received
2021-10-29 19:14:41 unknown_31D958 received
2021-10-29 19:15:14 unknown_32185B received
2021-10-29 19:14:10 unknown_32279A received
2021-10-29 19:13:33 unknown_3227F4 received
2021-10-29 19:15:09 unknown_322927 received
2021-10-29 19:15:18 unknown_3229B5 received
2021-10-28 07:46:36 unknown_48EA96 received
2021-10-29 19:13:10 unknown_4A32A4 received
2021-10-29 19:15:12 unknown_4A347F received
2021-10-29 19:14:01 unknown_4A7D5F received
2021-10-28 10:16:29 unknown_4A7FC7 received
2021-10-28 10:15:47 unknown_4A8036 received
2021-10-29 19:13:00 unknown_4AA97C received
2021-10-29 19:14:14 unknown_4B443D received
2021-10-29 19:13:05 unknown_4BDE84 received
2021-10-28 10:04:43 unknown_524FE3 received
2021-10-28 10:04:23 unknown_56A4B4 received
2021-10-28 09:57:31 unknown_56A660 received
2021-10-28 09:45:32 unknown_56B85B received
2021-10-28 10:07:27 unknown_577DA0 received
2021-10-28 09:24:05 unknown_577DA1 received
2021-10-29 19:14:22 unknown_5C29F8 received
2021-10-27 11:56:44 unknown_614B9A received
2021-10-29 19:13:59 unknown_62FD74 received
2021-10-28 08:39:00 unknown_68DFA3 received
2020-07-23 17:08:46 unknown_697334 received
2021-10-23 10:40:51 unknown_999999 received
2021-10-28 10:17:43 unknown_AFFE11 received
2021-10-29 19:13:43 unknown_AFFE33 received
helper:
HM_CMDNR 8
peerFriend peerSD,peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
cmds:
TmplKey :no:1635527192.71655
TmplTs 1635527192.71655
cmdKey 1:1:1::vccu::01:
cmdLst:
assignHmKey noArg
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
defIgnUnknown noArg
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getDevInfo noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
peerChan -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
postEvent -condition-
press [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{all})]
pressS [(-peer-|{all})]
raw -data- [...]
reset noArg
tplSet_0 -tplChan-
unpair noArg
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
listDevice noArg
param -param-
expert:
def 1
det 0
raw 1
tpl 0
io:
vccu vccu
ioList:
HM_UART
prefIO:
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
tmpl:
Attributes:
IOList HM_UART
IOgrp vccu
expert defReg,rawReg
model CCU-FHEM
room System
subType virtual
webCmd virtual:update
Das andere Testsystem war bzgl. genannter Meldungen unauffällig...
...bis ich eben nach dem Einspielen der aktuellen "Patches" neu gestartet habe...
Seit dem habe ich auf dem 2ten Testsystem auch diese Meldungen :-\
2021.10.29 19:09:20 3: HMinfo hm get:loadConfig :
2021.10.29 19:09:25 3: HMinfo hm get:loadConfig :
2021.10.29 19:09:30 3: HMinfo hm get:loadConfig :
2021.10.29 19:09:36 3: HMinfo hm get:loadConfig :
2021.10.29 19:09:41 3: HMinfo hm get:loadConfig :
Auf dem System sind ein paar HM-Geräte angelernt, bin aber grad nicht sicher, ob die aktuell auch laufen...
Auch hier mal ein lst der vccu nach Einspielen und Neustart:
Internals:
DEF AFFE33
FUUID 5c4779b1-f33f-ff8d-8884-fa763b450bea5038
FVERSION 10_CUL_HM.pm:?/2021-10-29 UNSTABLE
HMUART_USB_MSGCNT 112
HMUART_USB_RAWMSG 0500002F08865A32279A000000A4DC38
HMUART_USB_RSSI -47
HMUART_USB_TIME 2021-10-29 19:18:30
IODev HMUART_USB
LASTInputDev HMUART_USB
MSGCNT 112
NAME vccu
NR 19
NTFY_ORDER 48-vccu
STATE HMUART_USB:ok
TYPE CUL_HM
assignedIOs HMUART_USB
chanNo 01
disableNotifyFn 1
READINGS:
2021-10-29 19:08:27 IODev HMUART_USB
2021-10-29 19:08:46 IOopen 1
2021-10-23 14:01:19 cfgState ok
2021-10-29 19:08:46 state HMUART_USB:ok
2021-10-29 10:10:03 unknown_2ACA30 received
2021-10-29 00:22:49 unknown_2AD943 received
2021-10-29 00:20:56 unknown_2ADD14 received
2021-10-29 11:19:59 unknown_2ADD32 received
2021-10-29 16:05:57 unknown_2ADEB9 received
2021-10-29 19:16:40 unknown_2B1A82 received
2021-10-29 19:17:12 unknown_2B8E86 received
2021-10-29 19:17:48 unknown_2BA56B received
2021-10-29 19:17:04 unknown_2BBF72 received
2021-10-29 19:17:42 unknown_2C8BFC received
2021-10-29 19:17:23 unknown_2D9B77 received
2021-10-29 19:16:28 unknown_31D1FE received
2021-10-29 19:17:41 unknown_31D958 received
2021-10-29 19:17:41 unknown_32185B received
2021-10-29 19:18:30 unknown_32279A received
2021-10-29 19:16:28 unknown_3227F4 received
2021-10-29 19:17:49 unknown_322927 received
2021-10-29 19:17:41 unknown_3229B5 received
2019-04-18 18:03:19 unknown_453732 received
2021-10-29 15:14:18 unknown_48EA96 received
2021-10-29 19:16:07 unknown_4A32A4 received
2021-10-29 19:17:37 unknown_4A347F received
2021-10-29 19:16:06 unknown_4A7D5F received
2021-10-28 15:32:41 unknown_4A7FC7 received
2021-10-28 15:32:38 unknown_4A8036 received
2021-10-29 19:17:53 unknown_4AA97C received
2021-10-29 19:16:25 unknown_4B443D received
2021-10-29 19:17:38 unknown_4BDE84 received
2019-04-18 18:03:23 unknown_4E97A4 received
2019-10-12 12:16:48 unknown_51954D received
2021-10-29 19:04:48 unknown_524FE3 received
2019-07-21 16:14:18 unknown_55F0B6 received
2021-10-29 18:37:21 unknown_56A4B4 received
2021-10-29 19:15:27 unknown_56A660 received
2021-10-29 18:43:52 unknown_56B85B received
2021-10-29 18:25:02 unknown_577DA0 received
2021-10-29 18:52:16 unknown_577DA1 received
2021-10-29 19:17:04 unknown_5C29F8 received
2019-10-03 11:11:43 unknown_5F2959 received
2021-10-29 00:20:57 unknown_614B9A received
2021-10-29 19:16:09 unknown_62FD74 received
2021-10-29 08:30:09 unknown_68DFA3 received
2020-07-23 17:08:46 unknown_697334 received
2019-08-07 19:31:32 unknown_69B087 received
2019-07-14 23:24:12 unknown_69E542 received
2019-08-07 19:32:59 unknown_6C7538 received
2021-10-23 10:40:51 unknown_999999 received
2021-10-29 19:15:27 unknown_AFFE11 received
2021-10-29 19:11:35 unknown_AFFE22 received
helper:
HM_CMDNR 42
peerFriend peerSD,peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
cmds:
TmplKey :no:1635527307.44012
TmplTs 1635527307.44012
cmdKey 1:1:1::vccu::01:
cmdLst:
assignHmKey noArg
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
defIgnUnknown noArg
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getDevInfo noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
peerChan -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
peerSmart -peerOpt-
postEvent -condition-
press [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{all})]
pressS [(-peer-|{all})]
raw -data- [...]
reset noArg
tplSet_0 -tplChan-
unpair noArg
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt HM_69B087,HM_6C7538_Btn_01,HM_6C7538_Btn_02,HM_6C7538_Btn_03,HM_6C7538_Btn_04
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
listDevice noArg
param -param-
expert:
def 1
det 1
raw 0
tpl 0
io:
vccu vccu
ioList:
HMUART_USB
prefIO:
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
tmpl:
Attributes:
IOList HMUART_USB
IOgrp vccu
expert defReg,allReg
model CCU-FHEM
room System
subType virtual
webCmd virtual:update
Habe jetzt auf beiden Systemen verbose bei hminfo auf 2 stehen...
...damit erst mal Ruhe ist.
Wenn noch was benötigt wird, dann einfach melden...
Ich beobachte noch ein wenig und dann spiele ich das mal ins Hauptsystem...
...und dann mal sehen ;)
EDIT: auf dem Hauptsystem habe ich diese Einträge (noch ;) ) nicht. Aber da sind auch noch nicht die neuesten "Patches" drin... Aber gleich :)
EDIT: so nun auch auf dem Hauptsystem eingespielt, bislang alles i.O. :) Und hier (immer noch) keine Logeinträge von HMINFO... Auch hier mal das list der vccu.
Internals:
DEF AFFE11
FUUID 5c573a68-f33f-753d-dbdd-2769098533cc0e47
IODev hmusb
NAME vccu
NOTIFYDEV global
NR 31
NTFY_ORDER 48-vccu
STATE hmusb:ok
TYPE CUL_HM
assignedIOs hmusb
channel_01 vccu_Btn1
READINGS:
2021-10-29 19:30:06 IODev hmusb
2021-10-29 19:30:10 IOopen 1
2021-10-23 14:09:45 cfgState ok
2021-10-23 10:44:10 hmPair name:HM_614B9A SN: model:HM-SEC-RHS
2021-10-29 19:30:10 state hmusb:ok
2021-10-28 12:32:05 unknown_189A3D received
2021-07-08 12:42:22 unknown_322598 received
2021-10-29 18:39:21 unknown_3DA48A received
2020-12-03 18:11:04 unknown_4AA97C received
2021-07-09 11:07:20 unknown_5207F4 received
2021-10-29 19:04:48 unknown_524FE3 received
2021-10-23 10:41:40 unknown_614B9A received
2021-10-29 19:20:40 unknown_719ADF received
2021-10-29 19:11:35 unknown_AFFE22 received
2021-10-29 19:13:43 unknown_AFFE33 received
2021-10-29 18:39:22 unknown_B92AFC received
helper:
HM_CMDNR 156
mId FFF0
peerFriend -
peerOpt -:virtual
regLst
rxType 1
cmds:
TmplKey :no:1635528606.83408
TmplTs 1635528606.83408
cmdKey 0:1:1::vccu:FFF0:01:
cmdLst:
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
defIgnUnknown noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
tplSet_0 -tplChan-
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
listDevice noArg
param -param-
expert:
def 1
det 1
raw 0
tpl 0
io:
vccu vccu
ioList:
hmusb
prefIO:
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
IOList hmusb
IOgrp vccu
expert defReg,allReg
group IO-Module
model CCU-FHEM
room System
subType virtual
webCmd virtual:update
Und wie immer: wenn ich noch was tun kann/testen soll einfach Bescheid geben...
Gruß, Joachim
hminfo sucht wohl die datei, wo die gespeicherten konfigurationen sein müssen.
beim installieren von hm.js hast du sicher das attr zum automatischen speichern gesetzt.
attr wieder löschen, oder datei erzeugen.
Ok, beide Attribute gelöscht:
autoArchive
autoLoadArchive
Ok, autoLoadArchive hätte wohl gereicht... ;)
Stand halt so in der Anleitung ;)
Jetzt scheint Ruhe :)
Gruß, Joachim
zum speichern von selbst definierten templates nötig/ratsam.
steht glaube ich dabei.
So, die "29a" läuft jetzt auch hier seit einiger Zeit im Echtsystem.
Hatte noch eine "Hardwareleiche" in der Konfiguration stehen, die bekam "ignore" verpaßt - auch die scheint kein IO mehr zugewiesen zu bekommen.
Auch der Rest läuft - soweit auf die Schnelle erkennbar - stressfrei :) .
Testen müßte man noch die diversen "autocreate"-Varianten, das wird mir aber zumindest heute nicht reichen (eher dieses (lange) WE gar nicht).
Martin hatte ich angepingt, mal sehen, wann er sich ggf. meldet.
ZitatHatte noch eine "Hardwareleiche" in der Konfiguration stehen, die bekam "ignore" verpaßt - auch die scheint kein IO mehr zugewiesen zu bekommen.
meine 12 ignored devices bekommen mit v29a alle ein io durch fhem restart zugewiesen.
11 davon vor dem einlesen von fhem.save und eins kurz danach.
die 11 besitzen die attribute IODev
und IOgrp, also eigentlich falsch. das andere nur IOgrp.
ps:
es geht voran.
michael hat vorhin den 00_hmuart patch einegecheckt. :)
Ich wollte mal nur einwerfen, dass ich Euch allen hier EXTREMST dankbar bin dafür, dass Ihr den "Laden" CUL_HM so signifikat vorantreibt. Als beta-Tester wollte/konnte ich mich nicht zur Verfügung stellen, weil es bei mir noch nicht zu einem Testsystem gereicht hat und ich derzeit auf ein wartungsarmes Haupt-FHEM angewiesen bin (und meines läuft gerade so schön stabil).
Ich warte nur noch auf den Weckruf: "Jetzt lüppt's, ihr könnte bitte mal updaten!"
Kurz aus dem Off:
https://forum.fhem.de/index.php?topic=123771.msg1183420#msg1183420
ein Problem mit HM und mit den neuen Modulen läufts wieder.
Viele Grüße!
Andreas
Zitat von: frank am 30 Oktober 2021, 13:47:17
meine 12 ignored devices bekommen mit v29a alle ein io durch fhem restart zugewiesen.
11 davon vor dem einlesen von fhem.save und eins kurz danach.
die 11 besitzen die attribute IODev und IOgrp, also eigentlich falsch. das andere nur IOgrp.
Muss ich mal drüber nachdenken...
Mein Testdevice habe ich erst unter 29a auf ignore gesetzt => das Reading wird in dem Fall ja gelöscht. Es hatte vorher kein IODev-Attribut mehr, nur IOGrp. Evtl. haben wir ein Übergangsproblem? Evtl. könnte man in "init" aktiv löschen (und einen Hinweis ins Log schreiben, dass da noch was nicht gepaßt hatte?)?
Falls jemand kurzfristig Zeit/Lust hätte, das zu vercoden: es ist mir recht, wenn ich auch einfach "konsumieren" und/oder mittesten darf :) .
@frank: Was deine Liste angeht: falls du Ideen hast, was ggf. noch mit erledigt werden könnte... (s.o.). Bin zwar die Tage kurz nochmal drübergeflogen, aber das sah' mir - bis auf die jetzt miterledigten (?) - nicht nach "nebenbei" aus (so nicht sowieso schon Teil der Vorschläge hier).
Zitat
michael hat vorhin den 00_hmuart patch einegecheckt. :)
:) Ich weiß ;D , "jemand" hatte per pm nachgefragt, und wohl den richtigen Zeitpunkt erwischt... ;)
Zitat von: fhem-challenge am 30 Oktober 2021, 14:15:40
https://forum.fhem.de/index.php?topic=123771.msg1183420#msg1183420 (https://forum.fhem.de/index.php/topic,123771.msg1183420.html#msg1183420)
ein Problem mit HM und mit den neuen Modulen läufts wieder.
Danke für die Rückmeldung an dieser Stelle hier!
Zur Info: das schlechte Wetter war dazu gut, mal den CUL auf TSCUL umzustellen :) .
Völlig anleitungswidrig habe ich jetzt mal "nur" die firmware sowie "00_TSCUL.pm", "DevIoTS.pm" und "ReadingUtil.pm" aus der zip-file geholt. Zumindest scheint damit der CUL als IO in der VCCU eingebunden zu werden und liefert auch RSSI-Werte usw..
An sich würde mich interessieren, ob das (iVm. den aktuellen Modulfassungen) ggf. schon ausreicht für einen ordnungsgemäßen Betrieb, aber im Moment traue ich mich noch nicht, einfach mal die anderen IO's abzuschalten/aus der VCCU zu nehmen. Für einen "geht problemlos"-Erfahrungsbericht (oder eine entsprechende Äußerung eines Wissenden zur theoretischen Seite) wäre ich daher dankbar...
Wenn das nämlich ausreicht, kann man das auch einem fortgeschrittenen Anfänger noch vermitteln, der ggf. sonst Angst hat, bei jedem update wieder auf die Nase zu fallen und irgendwas wieder manuell ersetzen zu müssen :) .
Also ich hab mal "alte Spielzeuge" ausgepackt/reaktiviert: HM-DIS-WM55 und HM-DIS-EP
Zum einen damit ich an den/an dem Testsystem auch mal was hängen hab ;)
Und auch um mal zu testen: anlernen...
Also folgender Test verlief wie ich es mir vorgstellt habe/vorstellen/wünschen würde:
Hauptsystem autocreate disabled
Testsystem autocreate enabled
Testsystem: set vccu hmPairForSec 60 -> Anlernen am Display
-> Device wurde im Testsystem angelegt, auf dem Hauptsystem ist nichts passiert (naja zumindest nichts was man "offensichtlich" merkt ;) )
Auch kein unknown_ bei der vccu des Hauptsystems...
Ok, ich hatte übersehen, dass das Display dort noch angelegt war (dachte ich hätte das schon längst rausgenommen 8) habe das Display bestimmt schon seit 4 Jahren oder so nicht mehr im Einsatz / wobei im Einsatz war es so richtig noch nie...)
Gut daher dann einige wilde "ATTACK-Meldungen" im Log des Hauptsystems...
Werde das Display dort mal auf "ignore" setzen...
Nach ein paar Schwierigkeiten beim Lesen aller Register ist das Device nun vollständig und funktionabel vorhanden :)
(die Schwierigkeiten ließen sich aber mittels Wiki lösen: attr HM-Dis-WM55 msgRepeat 3 und hartnäckig bleiben ;) )
Wenn ich irgendwelche speziellen Szenarios testen soll: jetzt hab ich "Spielzeug-HW" :) (und vielleicht auch ab und an Zeit)
EDIT: @frank: hm.js ist echt klasse!! :) Wird demnächst auch auf dem Hauptsystem einziehen :)
Danke noch mal, Joachim
Bitte mal ins log schauen, siehe info von benni im nachbarthread
Zitat von: Beta-User am 30 Oktober 2021, 19:21:21
Bitte mal ins log schauen, siehe info von benni im nachbarthread
Meinst du den hier: https://forum.fhem.de/index.php/topic,123744.msg1183120.html#msg1183120
Also ich hab nichts auffälliges im Log, weder Testsystem noch HAuptsystem.
Auf dem Testsystem sogar mal shutdown restart -> alles gut!
Nutze aber kein AES...
Gruß, Joachim
Zitat von: Beta-User am 30 Oktober 2021, 19:21:21
Bitte mal ins log schauen, siehe info von benni im nachbarthread
Konnte ich zwischenzeitlich beheben!
Siehe: https://forum.fhem.de/index.php/topic,123744.msg1183562.html#msg1183562
gb#
Bin mir jetzt nicht sicher, ob das hier interessiert...
Jedenfalls habe ich heute früh einen update gemacht (via SVN), bis jetzt alles gut..
SVN und hier sollten momentan gleich sein oder ?
Habe hier als stiller User alle Betaversionen immer gleich eingespielt und viele Verbesserungen gespürt ohne groß was zu melden. Vielen Dank für die tolle Arbeit.
Es ist ein super stabiler Stand erreicht worden. Die Renameproblematik hat mich sehr gestört. Alles ist jetzt bestens.
Bei mir laufen hier 2 Systeme parallel. Mein Nachbar in der 2-ten Haushälfte hat eine Menge an HM-Gerätschaften. Und im Funk sehen wir uns gegenseitig.
Neuanmeldungen gingen oft schief, da trotz ausgeschalteter Autocreate-Funktion, Geräte angelegt wurden und dazwischen feuerten.
Nun folgender Test (10_CUL_HM.pm:?/2021-10-29 UNSTABLE):
Mein System: autocreate disabled
Nachbarsystem: autocreate enabled
Nachbarsystem: set vccu hmPairForSec 120 -> Anlernen durch Tastendruck
-> Device wurde im Nachbarsystem angelegt, auf dem meinem System ist nichts passiert (so soll es sein) es wurde aber ein unknown_ bei der vccu eingetragen.
Da kann ich jetzt gut mit leben. Übrigens: ein Fehler ist noch seit 2 Tagen im Logfile aufgetaucht:
2021.10.31 10:34:05 3: CUL_HM set kl_Zimmer_Mode_Btn press short all Burst 0 0.25
[b]2021.10.31 10:34:07 1: PERL WARNING: Use of uninitialized value $ctrlMode in right bitshift (>>) at ./FHEM/10_CUL_HM.pm line 2507.[/b]
2021.10.31 10:34:13 3: CUL_HM set Gaube_Mode_Btn press short all Burst 0 0.25
2021.10.31 10:35:00 3: CUL_HM set Anbau_Mode_Btn press short all Burst 0 0.25
2021.10.31 11:00:16 3: CUL_HM set VCCU update noArg
2021.10.31 11:00:16 3: CUL_HM set VCCU update noArg
Auch das doppelte Auftreten der VCCU update ist immer noch da, stört aber nicht weiter.
Zitat von: Rampler am 31 Oktober 2021, 17:06:59
SVN und hier sollten momentan gleich sein oder ?
Würde mich auch interessieren!
Ist das was gestern noch von martinp876 und mgernoth eingecheckt wurde der Stand, der auch hier anhängt?
Aktuell habe ich nämlich bei mir genau das alles erst mal vom update ausgeschlossen.
gb#
Hallo zusemmen,
Zitat von: Rampler am 31 Oktober 2021, 17:06:59
Bin mir jetzt nicht sicher, ob das hier interessiert...
Jedenfalls habe ich heute früh einen update gemacht (via SVN), bis jetzt alles gut..
SVN und hier sollten momentan gleich sein oder ?
Ganz gleich nicht, meine Kommentare sind z.B. ja zum überwiegenden Teil dafür da festzuhalten, wo die Quelle zur Lösung zu finden ist bzw. das Problem zu finden.
Im ersten Post war zu HMUARTLGW schon gestern was zu lesen, und zum Rest seit eben.
HMLAN scheint ein Problem mit dem Einchecken zu haben, Details hatte Martin nicht mitgeteilt. Ich hatte erst die commandref im Verdacht, vermute jetzt aber eher einen neueren pre-commit-hook, z.B. "my $foo= 'Bäh' if $baz". Mehr weiß ich im Moment nicht, also falls jemand Ideen hat oder die betreffende Stelle identifizieren kann: gerne!
Was CUL_HM betrifft, gibt es zum einen gewisse Teile (rund um autocreate), die Martin nicht übernommen hat, aber die wesentlichen Teile schon. Das im Detail durchzugehen, wird etwas dauern, bei autocreate scheine ich das nicht gut erklärt zu haben...
Nach der Meldung von @benni wg. des Loggings gehe ich auch davon aus, dass wir da so oder so noch mal nacharbeiten sollten. Aktueller Ansatz dazu wäre, ein Internal hochzählen zu lassen und bei Nichtvohandensein des Internals auch eine (erweiterte) verbose 0-Meldung ins Log zu schreiben. So sollte das einmalig passieren, und man kann am Zähler erkennen, wie gravierend das Problem ist?
Weiter war da noch was mir den AES-Keys, das noch unrund war.
Was heißt das nun:
- die svn-Fassung sollte für die meisten User ok sein, wer HMLAN im Einsatz hat, sollte bis zum Einchecken eines Updates die gepatchte von hier verwenden.
- Wer noch nicht die gepatchte Fassung hatte oder bisher nicht ins Log geschaut hatte, sollte so oder so (von der svn-Vorversion oder einer früheren patch-Version kommend nach dem update) ins Log schauen, ob das wegen eines Konfigurationsproblems "explodiert" und die Ursache beheben
- dringliche Aktionen bzgl. update vs. Version von hier sind m.E. nicht erforderlich.
- Es wird vermutlich nochmal eine Runde geben zu den o.g. Problemen. Von daher wäre ich dankbar, wenn es wieder ein paar Tester gäbe, oder:
Falls jemand Muße hat:
- Mein nächster Ausgangspunkt betr. CUL_HM wäre wieder eine "verglichene" Version auf aktuellem svn-Stand.
- Über TYPE=autocreate kann man streiten, ich meine aber, die Prüfung auf aktiviertes Pairing sei sinnvoll. Vielleicht sollte man Martin diese vereinfachte Variante vorschlagen? (Falls ichwas übersehe, darf mich an der Stelle auch jemand wissendes bremsen).
- Es dürfte nicht so schwierig sein, die o.g. Punkte noch abzuarbeiten.
-- Speziell @benni: ggf. könntest du einen Vorschlag zu dem Counter-Thema liefern? (kann auch in die letzte patch-Fassung eingebaut sein)
-- das mit den AES-keys ist ein Sonderthema bei der Attr-Routine bzw. der NotifyFn, aber vermutlich auch nicht übermäßig komplex. Je schneller wir einen getesteten Lösungsvorschlag haben, desto schneller wird es im svn landen - also "Freiwillige vor" (auch hier ist es m.E. prinzipiell egal, welche Basis).
Hoffe, der Stand ist jetzt klarer.
ZitatHMLAN scheint ein Problem mit dem Einchecken zu haben, Details hatte Martin nicht mitgeteilt.
die lösung hatte rudi umgehend gepostet
https://forum.fhem.de/index.php/topic,110125.msg1183519.html#msg1183519 (https://forum.fhem.de/index.php/topic,110125.msg1183519.html#msg1183519)
ZitatNach der Meldung von @benni wg. des Loggings gehe ich auch davon aus, dass wir da so oder so noch mal nacharbeiten sollten. Aktueller Ansatz dazu wäre, ein Internal hochzählen zu lassen und bei Nichtvohandensein des Internals auch eine (erweiterte) verbose 0-Meldung ins Log zu schreiben. So sollte das einmalig passieren, und man kann am Zähler erkennen, wie gravierend das Problem ist?
warum so ein aufwand mit dem zähler? das ist kontraproduktiv und falsch, finde ich.
user handeln in der regel sofort, wenn das blütenweisse log beschmuddelt wird. ;)
also: viele einträge => viel aufmerksamkeit => schnelles handeln.
benni hatte ja vermutlich schon immer einen konfigurationsfehler, der bisher nicht aufgefallen war.
wenn bennis erinnerung richtig ist und cul_hm deviceabhängig sowohl mit als auch ohne vccu arbeitet, hat cul_hm hier auch
falsch gehandelt. die vccu darf hier
kein io aussuchen, da nur attr IODev gesetzt war.
vermutlich war in diesen devices helper/io/vccu falsch gesetzt.
in die meldung gehört der devicename, damit man weiss welches device betroffen ist, um die konfiguration zu checken.
edit: martin erlaubt explizit gemischtes io handling
ZitatBeispiel Obsolet
Die Attribute "IOgrp" und "IOdev" schliessen sich aus. Der User kann einstellen, das die vccu sich um das IO kümmert ODER er definiert sein eigenes ODER er überlässt alles dem fhem-kernel.
https://forum.fhem.de/index.php/topic,122107.0.html (https://forum.fhem.de/index.php/topic,122107.0.html)
Zitat von: frank am 01 November 2021, 11:08:04
in die meldung gehört der devicename, damit man weiss welches device betroffen ist, um die konfiguration zu checken.
Genau das hatte ich eigentlich auch gemeint mit dem "besseren Logging."
Mir ging es gar nicht um eine Reduzierung der Messages, sondern (generell) um den Informationsgehalt der Meldungen, also woher kommt der Fehler, bzw. welches device ist davon betroffen, das ist in so einem Fall hilfreich und Zielführend!
Gehäufte (gleich lautende?) Messages zu sammeln und zu reduzieren um das Log nicht zu überfüllen wäre wahrscheinlich wesentlich zentraler aufzuhängen, Da müsste man ggf. erweiterte Log-Funktionen schaffen. Glaube nicht, dass Rudi oder sonst wer da so spontan Lust dazu hat. :)
Ich denke auch: Viele Meldungen => größerer Handlungsdruck => schnellere Problemlösung!
gb#
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 (https://forum.fhem.de/index.php/topic,122107.0.html)
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#
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
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.
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 (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.
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?
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
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.
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
Ab jetzt geht es betr. die patches hier weiter: https://forum.fhem.de/index.php/topic,123874.0.html
Zitat von: Timmäää am 03 November 2021, 07:50:53
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.
Das betraf bis eben v.a. den HMLAN mit dem darüber hinausgehen.
Ich habe btw. auch keine Idee dazu und würde empfehlen, bei ggf. noch vorhandenem Bedarf einen neuen Thread aufzumachen (und gerne im anderen Thread dann darauf hinzuweisen). Wie üblich: von den Funkthemen usw. habe ich keine Ahnung, aber wenn jemand eine funktionierende Lösung für ein erkanntes Teilproblem aufzeigen kann, baue ich das gerne ein und konsolidiere die Stände soweit mir möglich.
Damit wird dieser Thread jetzt (ausnahmsweise) geschlossen (zur Vermeidung von Konfusion...)