aktuelle CUL_HM Version macht bei mir massive Peering-Probleme

[blackbite]

Hallo zusammen,
ich habe nun fast 2 Tage an meiner zerschossenen FHEM-Umgebung gesessen, um festzustellen, dass die akutelle CUL_HM mal wieder die Ursache ist. Sorry für diese harte Aussage, aber da schwingt einfach der Unmut für wiederholtes Leiden mit...

Meine Umgebung war monatelang absolut sauber zumindest laut HMInfo check.
Einzige Änderungen waren das Update und ein Devicerename meiner ThreeStateSensors. Danach hat HMInfo behauptet, das unzählige Peers nicht mehr korrekt sind. Dachte zuerst, es läge am Devicerename. Aber der war wohl nur der Trigger für das Problem.
Habe überall wo die umbenannten Devices gepeered waren die ganze Geschichte mit unpeer, peer bis hin zu neu pairen und wieder peeren durch.
Bei einigen Geräten liessen sich die Peers wieder herstellen....aber...
Bei allen Devices, bei denen mehr als 3 Peers eingetragen werden sollten, weigerte sich CUL_HM nun per getconfig die Peers erfolgreich einzutragen (Peer incomplete, missing, etc.).
Das waren z.B. die HM-SEC-SIR-WM, oder aber auch ein einfacher HM-LC-SW1-FM. Es scheint auch egal zu sein, was für ein HM-Device es ist. Ich habe mit peerbulk an verschiedenen Devices versucht, mehr als 3 Peers hinzuzufügen. Das scheint aber generell nicht mehr zu funktionieren.
Ich bin wieder zurück auf Revision 23856 und konnte innerhalb kürzester Zeit alle Peers wieder problemlos hinzufügen.
Evtl. hat das mit dem geänderten Verhalten in Bezug auf "multi fragment messages" zu tun (Glaskugel). Bin leider nicht so fit im Coding.
Wenn ich weitere Infos liefern soll, bitte gerne melden.
VG

[blackbite]

Ich antworte mir mal selber, bzw. bitte konkreter um Hilfe. Vielleicht war meine Beschreibung zu lang...

Kann bitte mal jemand testen, ob er mehr als 3 Peers unter der aktuellen CUL_HM Version verbinden kann und ein getconfig dann noch den 4. Peer auslesen kann?
Max. 3 Peers klappen bei mir. Beim 4 kommen keine Register mehr an... folglich cfgState Fehler.

set zzz peerBulk 11110101
set zzz peerBulk 11110201
set zzz peerBulk 11110301
set zzz peerBulk 11110401
usw.

Später mit
set zzz peerBulk 11110401 unset
alles rückwärts

Vielen Dank!

[frank]

Meine Umgebung war monatelang absolut sauber zumindest laut HMInfo check.

hminfo hat einiges auch monatelang gar nicht angezeigt. 

warum überhaupt neu peeren und pairen?
ich dachte nur der name war neu. das interessiert ja nicht die realen geräte.
klingt sehr nach unnötigem aktionismus. 

mit nur einem set peerbulk kann man auch mehrere peers in einem rutsch setzen, daher der zusatz "bulk".

zeig mal ein sniff vom peerbulk.

[noansi]

Hallo Blackbite,

heute schon ein update gemacht und noch mal versucht?

Gruß, Ansgar.

[blackbite]

warum überhaupt neu peeren und pairen?

mit nur einem set peerbulk kann man auch mehrere peers in einem rutsch setzen, daher der zusatz "bulk".

Hi Frank,
naja, nachdem nichts mehr half und hminfo nicht zufrieden zu stellen war, habe ich halt nach Lehrbuch wieder drüber gepaired und die Peers versucht neu einzutragen.

Beim peerbulk war ja genau die Absicht festzustellen, ab wann getconfig die Register nicht mehr ausliest. Deshalb habe ich die Peers einzeln hinzugefügt und immer brav ein getconfig gemacht. Reproduzierbar hat dann beim 4. Peer getconfig nicht mehr getan, was es hätte tun sollen. Die Register des 4. Peers konnten nicht mehr gelesen werden und der cfgState war entsprechend fehlerhaft.

Ich muss mal schauen, was die heutige Version bringt. Bin noch auf alter Revision. Traue mich schon fast nicht mehr, weil jetzt wieder alles läuft.... Aber danke, dass Du mal drüber geschaut hast.
Vielleicht bin ich ja nachher mal mutig.

[blackbite]

Hallo Blackbite,

heute schon ein update gemacht und noch mal versucht?

Gruß, Ansgar.

Hallo Ansgar,

hättest Du denn konkrete Hinweise, dass die heutigen Änderungen auch mit meinem Problem zu tun haben? 
Kann ja fast nicht glauben, dass ich der Einzige bin...
Sehe improve pair und irgendwelche responsewait im aktuellen Changeset.
Merci und Grüße

[noansi]

Hallo Blackbite,

hättest Du denn konkrete Hinweise, dass die heutigen Änderungen auch mit meinem Problem zu tun haben?

ja.
Siehe https://forum.fhem.de/index.php/topic,119853.msg1148058.html#msg1148058 und da dem link folgen. Ist zwar etwas anders gelöst, als vorgeschlagen, müßte es aber bezüglich Peer-Read tun.

Gruß, Ansgar.

[frank]

nach Lehrbuch wieder drüber gepaired

nichts für ungut, aber das "lehrbuch" gehört in den müll. 
da steht sicherlich noch alles resetten, rebooten und system neu aufsetzen!

[blackbite]

Hallo Blackbite,
ja.
Siehe https://forum.fhem.de/index.php/topic,119853.msg1148058.html#msg1148058 und da dem link folgen. Ist zwar etwas anders gelöst, als vorgeschlagen, müßte es aber bezüglich Peer-Read tun.

Gruß, Ansgar.

Vielen Dank Ansgar. Verstehe zwar nur die Hälfte davon, aber ich erkenne die Parallelen 
Werde morgen mal updaten und berichten.

[blackbite]

nichts für ungut, aber das "lehrbuch" gehört in den müll. 
da steht sicherlich noch alles resetten, rebooten und system neu aufsetzen!

In meiner Verzweiflung und Halbblindheit hätte ich das wohl auch noch in Betracht gezogen... 
Konnte mir auch keinen Reim darauf machen, warum es mir  nach einem Devicerename die Peers zerschiesst. Vorher ein  hminfo configCheck ohne jeglichen Fehler. Dann Backup+Update gemacht und 5 threestatesensors umbenannt. Danach war das Chaos perfekt.
Tja, Du darft gerne mein neuer Mentor werden. Aber Dein  Niveau ist mir einfach zu hoch.  Muss mich an Otto halten. Dem kann ich gerade so noch folgen.
Ok, genug geschwafelt. Versuch folgt morgen. Vielen Dank und stay negative 

[blackbite]

Hallo Blackbite,

heute schon ein update gemacht und noch mal versucht?

Gruß, Ansgar.

Hi Ansgar,

Update soweit ok. Device mit 4 Peers wird mit getConfig wieder komplett gelesen. Für mich lediglich noch diese Kleinigkeit auffällig https://forum.fhem.de/index.php/topic,120321.0.html.

[sepultura30]

Hallo,

das Problem besteht immer noch .... https://forum.fhem.de/index.php/topic,120179.0.html

Hi Ansgar,

Update soweit ok. Device mit 4 Peers wird mit getConfig wieder komplett gelesen. Für mich lediglich noch diese Kleinigkeit auffällig https://forum.fhem.de/index.php/topic,120321.0.html.

[noansi]

Hallo sepultura30,

mir scheint, Du verwechselt Dein Problem mit dem hier.
Wegen eines neuen Readings in allen Channels triggern Deine Channels vermutlich zu unspezifisch geschriebene notiefies oder DOIFs.

Gruß, Ansgar.

[sepultura30]

Hallo Ansgar,

So sieht der Schlüssel aus:

channel_01 SchluesselSandro_unlock
channel_02 SchluesselSandro_lock
channel_03 SchluesselSandro_light
channel_04 SchluesselSandro_open

und das Notify sieht so aus

SchluesselSandro_light set Licht_Haustuer on-for-timer 90

Was ist daran falsch

Änderung: Habe alle Notifys angepasst, jetzt läuft alles -> Danke für den Denkanstoss

SchluesselSandro_light:trigger:.* set Licht_Haustuer on

Grüße

Sandro

Hallo sepultura30,

mir scheint, Du verwechselt Dein Problem mit dem hier.
Wegen eines neuen Readings in allen Channels triggern Deine Channels vermutlich zu unspezifisch geschriebene notiefies oder DOIFs.

Gruß, Ansgar.

[martinp876]

Mir nicht klar, ob ich richtig liege -aber manche HM Devices haben Probleme bei jedem 4. Peer. Die Antwort-message ist schlicht 2 Zeichen zu kurz. Extrem hässlich und nicht zu beheben-

Wenn du einmal 4 peers einrichtest und die messages sniffst - dann sicherheitshalben ein getConfig.
Bislang hatte das Problem noch keiner reklamiert - ich habe bei mir solche Konstellationen in betrieb.

Zeige den Sniff und ich suche einmal. Dann prüfen wir ob es stimmt - und suchen den Workaround.