FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: Beta-User am 15 Oktober 2021, 23:56:29

Titel: [CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 15 Oktober 2021, 23:56:29
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)
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 16 Oktober 2021, 11:35:17
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 17 Oktober 2021, 15:18:11
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!
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 18 Oktober 2021, 20:11:33
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 18 Oktober 2021, 20:36:29
"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 ;) )
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag 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)  :) .
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: BroPi am 19 Oktober 2021, 09:37:31
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 19 Oktober 2021, 11:25:51
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 19 Oktober 2021, 15:30:56
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 19 Oktober 2021, 15:52:30
Zitat
wenn 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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 19 Oktober 2021, 16:07:17
...ebend, so hatte ich das auch im Kopf...
Daher der update zum HMLAN (einschl. des anderen Patches):
[...] 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.
.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 19 Oktober 2021, 22:00:32
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 19 Oktober 2021, 23:02:20
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Helmi55 am 20 Oktober 2021, 17:53:22
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 20 Oktober 2021, 19:32:35
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 21 Oktober 2021, 09:15:47
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!
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 22 Oktober 2021, 11:33:31
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 22 Oktober 2021, 12:05:44
Zitat
Allerdings 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?
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 22 Oktober 2021, 12:09:10
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 22 Oktober 2021, 12:18:16
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...
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 22 Oktober 2021, 12:19:17
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 22 Oktober 2021, 12:26:47
@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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 22 Oktober 2021, 12:41:11
...spontane Idee: Wiedergänger des chanNo-Themas aus fheminfo?
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 22 Oktober 2021, 13:15:36
am pairung wurde schon seit längerem "rumgeschraubt".

vermutlich braucht es eine weitere einschränkung ab zeile ~ 3912:
  elsif($mhp->{mTp} eq "00"){######################################
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 22 Oktober 2021, 13:26:50
Zitat
Nur 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?
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 22 Oktober 2021, 14:09:26
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 22 Oktober 2021, 14:27:59
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" : "");
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 22 Oktober 2021, 15:16:59
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 22 Oktober 2021, 15:24:15
Wenn frank das OK gibt kann ich ja mal testen...

Gruß, Joachim
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag 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 .
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 22 Oktober 2021, 15:35:04
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 22 Oktober 2021, 16:10:59
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 22 Oktober 2021, 21:11:16
Zitat
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...)
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 noArg
Zitat
Interessant 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 active
alle 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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 22 Oktober 2021, 21:31:02
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 22 Oktober 2021, 21:41:08
Zitat
Ansonsten 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".
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 22 Oktober 2021, 21:48:15
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 23 Oktober 2021, 01:07:09
@beta-user
vermutlich hat martin autocreate absichtlich verbannt, weil zu viele es abgeschaltet hatten.  ;)
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 23 Oktober 2021, 06:35:30
@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!
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Benni am 23 Oktober 2021, 07:42: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#
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 23 Oktober 2021, 11:03:38
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 23 Oktober 2021, 11:12:11
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...
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 23 Oktober 2021, 11:34:36
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 23 Oktober 2021, 11:36:12
Zitat
Was 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).


Zitat
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?)
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)
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 23 Oktober 2021, 12:11:55
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 23 Oktober 2021, 12:29:55
Zitat
Aber 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.  ;)
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 23 Oktober 2021, 13:58:09
[OT!]

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]
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 23 Oktober 2021, 15:07:00
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 25 Oktober 2021, 11:45:03
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 25 Oktober 2021, 12:14:27
...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...
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 25 Oktober 2021, 13:29:12
hast du auch an mehrere vccu gedacht?
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 25 Oktober 2021, 13:36:18
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...
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 25 Oktober 2021, 13:57:53
beim anlegen einer 2. vccu, wurde dieser zumindestens neulich ein io zugewiesen, das bereits der 1. vccu gehörte.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 25 Oktober 2021, 14:15:11
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).
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 26 Oktober 2021, 17:46:12
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)
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...
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 26 Oktober 2021, 18:12:00
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 26 Oktober 2021, 18:48:06
Zitat
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...
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?
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Udomatic am 26 Oktober 2021, 19:15:08
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 26 Oktober 2021, 19:28:47
Zitat
Ich 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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 26 Oktober 2021, 19:51:09
Stichwort levelInverse?
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 26 Oktober 2021, 19:58:26
Zitat
Stichwort levelInverse?
gute idee.
dann also schalter richtig einbauen und register anpassen.

alternative für umweltsünder: die aktuellen patches plus "attr param levelInverse"
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Udomatic am 26 Oktober 2021, 20:13:41
Stichwort levelInverse?

Ja und warum, hat doch die ganze Zeit ohne Level Inverse funktioniert?!
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 26 Oktober 2021, 20:22:02
Ja und warum, hat doch die ganze Zeit ohne Level Inverse funktioniert?!
Show us!
Bitte in cfg vor dem update schauen.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Udomatic am 26 Oktober 2021, 20:30:20
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)
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 26 Oktober 2021, 21:33:36
Zitat
Ist die jeweils letzte Version von CUL_HM denn jetzt "vorschlagsfähig", was "autocreate" angeht?
wahrscheinlich nein.

Zitat
pairing 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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 26 Oktober 2021, 22:10:24
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Timmäää am 27 Oktober 2021, 08:08:28
Update des HMLAN läuft bei mir ohne Probleme.
Ergänzung: Ich setze eine vccu mit zwei IO, dem HMLAN und einem CUL, ein.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 27 Oktober 2021, 09:59:35
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:
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.

Zitat
das wiederum bedeutet, dass hminfo configcheck ziehmlich umfangreich wird, oder übersehe ich gerade was  ;)
Vermutlich; aber eben nur, wenn keine VCCU vorhanden ist (=>selber schuld...?)

Zitat
dann 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...
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 27 Oktober 2021, 11:34:53
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 27 Oktober 2021, 12:10:42
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!
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 27 Oktober 2021, 12:31:02
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.  ;)

Zitat
Auch, 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
Zitat
die 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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 27 Oktober 2021, 13:45:48
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...

Zitat
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.
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).
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 27 Oktober 2021, 17:25:54
Zitat
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).
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 27 Oktober 2021, 17:33:17
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

Zitat
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

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).
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 27 Oktober 2021, 18:04:58
Zitat
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.
ok, verstanden.   8)

Zitat
Sonst 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)
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 27 Oktober 2021, 20:20:20
Zitat
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...
konnte ich gerade nicht festellen.
das device ist zumindestens weiterhin unter "get assignIDs" beim hmlan zu finden. im log war auch nichts zusehen.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 28 Oktober 2021, 12:49:37
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.

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...?

Zitat
eine 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 ::) ?
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 28 Oktober 2021, 14:49:42
moin,


Zitat
Hmm, 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 1


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?
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 28 Oktober 2021, 15:13:44
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 28 Oktober 2021, 15:43:07
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);
      }
    }
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 28 Oktober 2021, 15:51:44
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?
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 28 Oktober 2021, 16:01:19
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...
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 28 Oktober 2021, 20:47:04
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...
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 28 Oktober 2021, 21:19:12
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 28 Oktober 2021, 22:47:44
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?
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag 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.

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)
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 29 Oktober 2021, 09:36:32
Anbei mal wieder eine Testversion...
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 :) .

Zitat
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.
...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...
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 29 Oktober 2021, 09:44:26
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...
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 29 Oktober 2021, 09:59:19
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!
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 29 Oktober 2021, 10:11:12
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 29 Oktober 2021, 10:28:06
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?
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 29 Oktober 2021, 13:09:29
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.  ;)
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 29 Oktober 2021, 13:40:31
...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...
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 29 Oktober 2021, 17:16:07
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 29 Oktober 2021, 17:26:32
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 29 Oktober 2021, 19:22:25
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 29 Oktober 2021, 20:16:11
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.

 
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 29 Oktober 2021, 20:54:40
Ok, beide Attribute gelöscht:

autoArchive
autoLoadArchive

Ok, autoLoadArchive hätte wohl gereicht... ;)

Stand halt so in der Anleitung ;)

Jetzt scheint Ruhe :)

Gruß, Joachim
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 29 Oktober 2021, 21:15:09
zum speichern von selbst definierten templates nötig/ratsam.
steht glaube ich dabei.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 30 Oktober 2021, 07:10:48
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 30 Oktober 2021, 13:47:17
Zitat
Hatte 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.  :)
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Pfriemler am 30 Oktober 2021, 14:00:33
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!"
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: fhem-challenge am 30 Oktober 2021, 14:15:40
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 30 Oktober 2021, 14:43:13
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... ;)

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!
 
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 30 Oktober 2021, 15:23:08
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 :) .
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 30 Oktober 2021, 18:25:50
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 30 Oktober 2021, 19:21:21
Bitte mal ins log schauen, siehe info von benni im nachbarthread
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: MadMax-FHEM am 30 Oktober 2021, 19:34:44
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Benni am 31 Oktober 2021, 07:55:40
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#
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag 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 ?
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: BroPi am 31 Oktober 2021, 17:13:38
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Benni am 31 Oktober 2021, 21:03:08
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#
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 01 November 2021, 07:26:53
Hallo zusemmen,
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 01 November 2021, 10:04:03
Zitat
HMLAN 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)
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: frank am 01 November 2021, 11:08:04
Zitat
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?
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
Zitat
Beispiel 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)
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Benni am 01 November 2021, 12:04:58
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#


Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Benni am 01 November 2021, 12:15:59
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#
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Gisbert am 02 November 2021, 07:53:16
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​
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 02 November 2021, 14:29:23
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: mumpitzstuff am 02 November 2021, 19:52:48
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.
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Timmäää am 03 November 2021, 07:50:53
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
Titel: Antw:[CUL_HM] patches Oktober 2021 - die Zweite
Beitrag von: Beta-User am 03 November 2021, 11:00:42
Ab jetzt geht es betr. die patches hier weiter: https://forum.fhem.de/index.php/topic,123874.0.html

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...)