Neues HM-CC-RT-DN flutet Log-Datei

[holmexx]

Moin,

ein (hoffentlich) neues HM-CC-RT-DN flutet die Log-Datei unmittelbar nach dem Anlernen mit:

Code Auswählen Erweitern

2024.09.15 21:54:30 3: LogHist Cullie:  04194392 A F101 06367252 00 0E 87 8010 3F0931 250258 0208000000 -70dB
2024.09.15 21:54:30 3: LogHist Cullie:  000091                 As 10 97 A001 250258 3F0931 03045805250103
2024.09.15 21:54:30 3: LogHist Cullie:  04194513 A F103 06367348 01 10 97 A001 250258 3F0931 03045805250103 _CCAdly:4 _dhmSt:96
2024.09.15 21:54:30 3: LogHist Cullie:  04194641 A F101 06367500 00 0E 97 8010 3F0931 250258 0204320000 -69.5dB
2024.09.15 21:54:30 3: LogHist Cullie:  000342                 As 10 A7 A001 250258 3F0931 03045805250107
2024.09.15 21:54:30 3: LogHist Cullie:  04194768 A F103 06367600 02 10 A7 A001 250258 3F0931 03045805250107 _CCAdly:8 _dhmSt:100
2024.09.15 21:54:30 3: LogHist Cullie:  04194896 A F101 06367756 00 0E A7 8010 3F0931 250258 0205100000 -69.5dB
2024.09.15 21:54:30 3: LogHist Cullie:  001812                 As 0B 98 8470 580125 000000 00D6
2024.09.15 21:54:30 3: LogHist Cullie:  04196144 A F103 06368980 01 0B 98 8470 580125 000000 00D6 _CCAdly:4
2024.09.15 21:54:30 3: LogHist Cullie:  04201027 A F101 06373888 00 1C 10 008E 8543FB B1F4CC 06CFE481AAA1392EE63712D81A5FCA194C0B03 -86dB
2024.09.15 21:54:30 3: LogHist Cullie:  04201582 A F101 06374440 00 27 10 018E 8543FB B1F4CC 06CFE482444BA2704E1414914747CC526FA53C53BE6E6E73A100E0450CBE -86dB
2024.09.15 21:54:30 3: LogHist Cullie:  04212352 A F101 06385212 00 0F 03 8610 787FA4 250258 0AA8DF0F0000 -40.5dB
2024.09.15 21:54:30 3: LogHist Cullie:  018052                 As 10 04 A001 250258 787FA4 00040000000000
2024.09.15 21:54:30 3: LogHist Cullie:  04212466 A F103 06385308 01 09 03 A112 250258 787FA4  _CCAdly:4 _dhmSt:96
2024.09.15 21:54:30 3: TSCUL_ParseTsHM: Cullie HM repeat failed to 787FA4/HM_787FA4:  04212706 A F109 06385568 00 09 03 A112 250258 787FA4  _sfail _noAnsw
2024.09.15 21:54:31 3: LogHist Cullie:  000342                 As 10 A7 A001 250258 3F0931 03045805250107
2024.09.15 21:54:31 3: LogHist Cullie:  04194768 A F103 06367600 02 10 A7 A001 250258 3F0931 03045805250107 _CCAdly:8 _dhmSt:100
2024.09.15 21:54:31 3: LogHist Cullie:  04194896 A F101 06367756 00 0E A7 8010 3F0931 250258 0205100000 -69.5dB
2024.09.15 21:54:31 3: LogHist Cullie:  001812                 As 0B 98 8470 580125 000000 00D6
2024.09.15 21:54:31 3: LogHist Cullie:  04196144 A F103 06368980 01 0B 98 8470 580125 000000 00D6 _CCAdly:4
2024.09.15 21:54:31 3: LogHist Cullie:  04201027 A F101 06373888 00 1C 10 008E 8543FB B1F4CC 06CFE481AAA1392EE63712D81A5FCA194C0B03 -86dB
2024.09.15 21:54:31 3: LogHist Cullie:  04201582 A F101 06374440 00 27 10 018E 8543FB B1F4CC 06CFE482444BA2704E1414914747CC526FA53C53BE6E6E73A100E0450CBE -86dB
2024.09.15 21:54:31 3: LogHist Cullie:  04212352 A F101 06385212 00 0F 03 8610 787FA4 250258 0AA8DF0F0000 -40.5dB
2024.09.15 21:54:31 3: LogHist Cullie:  018052                 As 10 04 A001 250258 787FA4 00040000000000
2024.09.15 21:54:31 3: LogHist Cullie:  04212466 A F103 06385308 01 09 03 A112 250258 787FA4  _CCAdly:4 _dhmSt:96
2024.09.15 21:54:31 3: LogHist Cullie:  04212706 A F109 06385568 00 09 03 A112 250258 787FA4  _sfail _noAnsw
2024.09.15 21:54:31 3: LogHist Cullie:  04212740 A F103 06385576 01 10 04 A001 250258 787FA4 00040000000000 _CCAdly:4 _dhmSt:364
2024.09.15 21:54:31 3: LogHist Cullie:  04213008 A F103 06385844 01 10 04 A001 250258 787FA4 00040000000000 _CCAdly:4 _dhmSt:632
2024.09.15 21:54:31 3: LogHist Cullie:  04213276 A F103 06386112 01 10 04 A001 250258 787FA4 00040000000000 _CCAdly:4 _dhmSt:900
2024.09.15 21:54:31 3: TSCUL_ParseTsHM: Cullie HM repeat failed to 787FA4/HM_787FA4:  04213514 A F109 06386376 00 10 04 A001 250258 787FA4 00040000000000 _sfail _noAnsw
2024.09.15 21:54:33 3: LogHist Cullie:  018052                 As 10 04 A001 250258 787FA4 00040000000000
2024.09.15 21:54:33 3: LogHist Cullie:  04212466 A F103 06385308 01 09 03 A112 250258 787FA4  _CCAdly:4 _dhmSt:96
2024.09.15 21:54:33 3: LogHist Cullie:  04212706 A F109 06385568 00 09 03 A112 250258 787FA4  _sfail _noAnsw
2024.09.15 21:54:33 3: LogHist Cullie:  04212740 A F103 06385576 01 10 04 A001 250258 787FA4 00040000000000 _CCAdly:4 _dhmSt:364
2024.09.15 21:54:33 3: LogHist Cullie:  04213008 A F103 06385844 01 10 04 A001 250258 787FA4 00040000000000 _CCAdly:4 _dhmSt:632
2024.09.15 21:54:33 3: LogHist Cullie:  04213276 A F103 06386112 01 10 04 A001 250258 787FA4 00040000000000 _CCAdly:4 _dhmSt:900
2024.09.15 21:54:33 3: LogHist Cullie:  04213514 A F109 06386376 00 10 04 A001 250258 787FA4 00040000000000 _sfail _noAnsw
2024.09.15 21:54:33 3: LogHist Cullie:  04213525 A F101 06386384 00 0F 90 8610 787AC2 000000 0AA8D60C0300 -63.5dB
2024.09.15 21:54:33 3: LogHist Cullie:  04213638 A F103 06386480 01 09 90 A112 250258 787AC2  _CCAdly:4 _dhmSt:96
2024.09.15 21:54:33 3: LogHist Cullie:  04213768 A F101 06386628 00 0A 90 8002 787AC2 250258 00 -62dB
2024.09.15 21:54:33 3: LogHist Cullie:  020672                 As 0B 14 A001 250258 787FA4 0103
2024.09.15 21:54:33 3: LogHist Cullie:  04215003 A F103 06387840 01 0B 14 A001 250258 787FA4 0103 _CCAdly:4 _dhmSt:2628
2024.09.15 21:54:33 3: LogHist Cullie:  04215268 A F103 06388108 01 0B 14 A001 250258 787FA4 0103 _CCAdly:4 _dhmSt:2896
2024.09.15 21:54:33 3: LogHist Cullie:  04215532 A F103 06388372 01 0B 14 A001 250258 787FA4 0103 _CCAdly:4
2024.09.15 21:54:33 3: TSCUL_ParseTsHM: Cullie HM repeat failed to 787FA4/HM_787FA4:  04215770 A F109 06388632 00 0B 14 A001 250258 787FA4 0103 _sfail _noAnsw

250258 ist die hmId des CUL
787FA4 ist das neue HM-CC-RT-DN

FHEM läuft auf einem RaspPi, IODev ist ein Cul V3 von busware; dieser ist bestückt mit VTS 0.41 CUL868. Die entsprechenden Module und Anpassungen für diese Firmware sind erfolgt.

Ist das neue Thermostat etwa vom Auspacken kaputt gegangen?

Gruß Holger

[noansi]

Hallo Holger,

der 787FA4 wird mit gutem RSSI empfangen.
Scheitern tut jedoch das Lesen der Register, da der RT schon nicht auf die Aufforderung zum wach bleiben antwortet. Entweder empfängt er die Aufforderung nicht oder er fühlt sich nicht angesprochen.

War das Pairing erfolgreich oder glaubst Du nur, dass es das war?
list vom RT?

Gruß, Ansgar.

[holmexx]

Hallo Ansgar,

jetzt, wo du es sagst: ich glaube nur, dass das Pairing erfolgreich war. Lt. Display am Thermostat selbst sollte es erfolgreich gewesen sein. Das Funksymbol ist an, dauerhaft. Auch funktioniert das Ansteuern durch FHEM (virtueller Fensterkontakt, virtueller Temperatursensor, Wochenplan mit Topics -> Thermostat reagiert auf Topicänderung).

Anbei das Listing.

Gruß Holger

Du darfst diesen Dateianhang nicht ansehen.

[holmexx]

... ich vermute mal, dass das "cfgState -> RegMiss" in den Readings (was ich großzügig überlesen habe) bedeutet, dass das Pairing eben nicht erfolgreich war. Oder?

[noansi]

Hallo Holger,

... ich vermute mal, dass das "cfgState -> RegMiss" in den Readings (was ich großzügig überlesen habe) bedeutet, dass das Pairing eben nicht erfolgreich war. Oder?

Das Knöpchen Drücken zum Pairing wurde empfangen und dementsprechend Modell und Seriennummer und Firmwareversion aufgenommen. Ich hoffe, Du hast zuvor auch hmPairForSec für eine ausreichende Zeit gesetzt.

Jedoch sehe ich keinen Hinweis auf ein erfolgreiches Pairing.
Wenn die Register gelesen werden könnten, dann würde R-pairCentral die Antwort geben können.

Paire einfach nochmal, aber nichts löschen.

Gruß, Ansgar.

[holmexx]

Hallo Ansgar,

jetzt habe ich

cfgState -> RegMiss,RegPend

Ich habe noch mal ein manuelles

set hm_Schlafzimmer getConfig

hinterher geschoben. Mal sehen was passiert. (787FA4 hat sich umgezogen und heißt nun hm_Schlafzimmer)

Gruß
Holger

[holmexx]

... Schade, getConfig ist durch, aber es bleibt bei

cfgState -> RegMiss,RegPend

Die Log-Datei freut sich allerdings:

Code Auswählen Erweitern

2024.09.17 19:57:08 3: CUL_HM received config CCU: device: hm_Schlafzimmer. PairForSec: on
2024.09.17 19:57:08 3: CUL_HM pair: hm_Schlafzimmer thermostat, model HM-CC-RT-DN serialNr TEQ0440385


[holmexx]

... vielleicht noch ein persönlicher Eindruck hinterher:

Das Thermostat habe ich bei Ama... gekauft und kam in einer nicht mehr ganz taufrisch aussehenden Verpackung, der auch die Bedienungsanleitung fehlte. Mein Verdacht: ich habe eine Rücksendung als Neuware bekommen. Daraus könnte man ableiten, dass dieses Teil schon mal irgendwo angemeldet war.

[holmexx]

Hallo Ansgar,

ich finde auch das im Log, seit ich mit diesem Thermostat kämpfe:

Code Auswählen Erweitern

TSCUL_ParseTsHM: Cullie NAME undef for did 000000

Cullie, der noch in "Scully" umbenannt werden muss, ist natürlich der/die/das CUL.

Gruß
Holger

[noansi]

Daraus könnte man ableiten, dass dieses Teil schon mal irgendwo angemeldet war.

Laut Anleitung sollte das Thermostat dann den Fehler F4 anzeigen.

F4 Anlernkonflikt,    es    ist
bereits eine Zentrale
als Verknüpfungspart-ner angelernt
Heizkörperthermostat in
der Zentrale löschen; Ab-lernfunktion durchführen

[holmexx]

F4 habe ich nicht. Kann ich ein "Ablernen" machen? Ich habe zu diesem Thermostat ein virtuelles Gerät mit 2 Kanälen für Fensterkontakt und Temperatursensor nebst notify etc. angelegt. Muss ich das dann alles löchen und neu machen?

[noansi]

Kann ich ein "Ablernen" machen?

Kannst Du, entspricht einem Werksreset nach Anleitung.

Ich habe zu diesem Thermostat ein virtuelles Gerät mit 2 Kanälen für Fensterkontakt und Temperatursensor nebst notify etc. angelegt. Muss ich das dann alles löchen und neu machen?

Das peering zu Deinen virtuellen devices wird nach dem Werksreset weg sein. Das müsstest Du nur neu setzen.

Eine VCCU solltest Du einrichten.

[holmexx]

Wenn eine VCCU bei nur einem CUL auch Sinn macht, muss das Wiki aber überarbeitet werden. Ich habe nach Lesen des Beitrages nicht das Gefühl gehabt, dass ich bei nur einem CUL eine VCCU benötige. Im Moment ist auch nur ein HomeMatic-Thermostat im Einsatz, aber die 4 noch im Einsatz befindlichen MAXe werden wohl diesen Winter nicht überleben (der Stelltrieb schafft es nicht mehr, das Ventil zu schließen). Sehr schade, weil die Dinger klaglos funktioniert haben.

[holmexx]

Es bleibt dabei

Code Auswählen Erweitern

cfgState -> RegMiss,RegPend

Und sofort waren wieder diese dutzenden Meldungen im Log: erst die History, gefolgt von der "TSCUL_ParseTsHM: Cullie HM repeat failed to 787FA4/787FA4 ..." und "TSCUL_ParseTsHM: Cullie NAME undef for did 000000".

Nun wird ja immer wieder gewarnt, einen CUL für HomeMatic einzusetzen. Anderseits wird die tsculfw als Heilmittel gepriesen. Kann es sein, dass es auch mit dieser Firmware (v0.41) nicht (immer) läuft?

Recht frustierte Grüße
Holger

[holmexx]

Ach ja, ich habe hier noch eine Geschichte, die sich vor einiger Zeit zugetragen hat. Mein Vermieter kam mit allerlei Woodoo-Elektronik, um meine Wohnung (neu) zu vermessen (schade für ihn, die Wohnfläche wurde nicht größer, hihi). U.a. war auch ein Tablet dabei, welches sich via Bluetooth mit dem Woodoo-Gerät koppeln sollte. Tat es aber nicht. In meiner Wohnung laufen 2 WLAN-Accesspoints von ubiquity/UniFi. Nach vorübergehendem Abschalten - und ich meine tatsächlich "Spannung weg, aus" - verband sich das Tablet plötzlich mit dem 3D-Scanner. Kann es sein, dass diese Accesspoints, die wohl in übertragendem Sinne "sehr laut" sind, auch hier unqualifiziert dazwischen funken? Bei ~2,4 GHz (Bluetooth) und 2,5 GHz (WLAN) kann ich mir das vorstellen. 868,3 MHz und 2,5 GHz scheinen mir jedoch recht weit auseinander zu liegen. Allerdings ist mein Physik-Schulwissen aber auch 50 Jahre alt.

Vielleicht ist hier ja jemand, der aus dem 3. Untergeschoss des Maschinenraums heraus eine Ahnung hat.

Gruß
Holger

[holmexx]

1 1/2 Stunden später, die Hoffnung stirbt zuletzt: nichts hat sich geändert, leider

Code Auswählen Erweitern

cfgState -> RegMiss,RegPend
commState -> CMDs_done_Errors:1
state -> MISSING ACK

HomeMatic-Experiment gescheitert??

Gruß (immer noch frustriert)
Holger

[holmexx]

Neuer Tag, neues Glück.

• RaspPi 3B+ neu aufgesetzt mit Debians Bullenauge
• FHEM installiert (Package source debian.fhem.de/nightly)
• service fhem gestoppt
• TSCUL Perl Module aus dem Paket eingespielt, sogar noch Ownership angepasst (ist eigentlich gar nicht nötig, da vorher schon world readable)
• den mit tsculfw v0.41 ausgestatteten CUL angesteckt
• /dev/ttyACM0 geprüft -> vorhanden, Rechte passen
• service fhem gestartet
• CUL wird sofort erkannt und eingerichtet als TSCUL, rfmode HomeMatic, mein Name "Scully"
• eventueller Schönheitsfehler: PERL Warning: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_autocreate.pm line 747
• attr Scully hmId 250258 -> check

VCCU einrichten lt. Wiki

• define VCCU CUL_HM 250258 -> check
• attr VCCU model CCU-FHEM -> check
• attr VCCU IOList Scully -> fail: Scully does not support CUL_HM
• Konfiguration gespeichert
• service fhem gestoppt

Nun habe ich etwas getan, worauf hier die Todestrafe steht: Attribut händisch in der fhem.cfg eingetragen.

• in Erwartung des herabsausenden Fallbeils service fhem gestartet -> check
• attr VCCU IOgrp VCCU -> check

Unmittelbar darauf erschienen in den Readings der VCCU mein (Problem?)-Thermostat und die beiden vom Nachbarn:

Code Auswählen Erweitern

unknown_787FA4 dst 000000 rssi -60.5 2024-09-18 12:36:31
unknown_853608 dst 29F40A rssi -94   2024-09-18 12:33:57    <-- Nachbar
unknown_AD12CF dst 29F40A rssi -97   2024-09-18 12:35:37    <-- dito
Nun wird die Log-Datei nicht mehr mit History und _noAnsw geflutet, sondern unregelmäßig alle paar Sekunden erscheint

Code Auswählen Erweitern

... TSCUL_ParseTsHM: Scully NAME undef for did 000000
Hier habe ich erstmal aufgehört, weil ich denke, dass das ein Fehler ist, den es gerade zu ziehen gilt Um mal die Dimension zu erfassen: das neue System läuft jetzt 53 Minuten und die Log-Datei ist bereits ~35 kByte groß! 98% davon ist die obige Zeile.

Gruß
Holger

@Ansgar: ist habe vorhin erst realisiert, dass Du der Ersteller der alternativen Firmware bist. Wenn du interesiert bist, Zeit hast etc. könnten wir dem Ganzen gründlich auf den Zahn fühlen. Ich scheue auch nicht davor zurück, mein System noch mal neu aufzusetzen.

[frank]

... TSCUL_ParseTsHM: Scully NAME undef for did 000000

soweit ich den code verstehe, passiert das ggf nur bei messages von unbekannten sendern (also zb vom nachbarn).

das pairen und auslesen deines rt sollte trotzdem funktionieren, denke ich.

zeig mal je ein aktuelles list vom rt und der vccu.
ausserdem zeig mal ein: "list DEF=000000"

[holmexx]

Die beiden Nachbargeräte, die ich empfange haben doch ein "dst" drin (29F40A). Mein Thernostat, was wohl doch einen Schlag weg hat, kommt oben mit dst 000000. Listing kommt sofort ...

[holmexx]

... Listing kommt sofort ...

Nee, kommt nicht. list DEF=000000 liefert nichts! Allerdings habe ich eine Idee. Ich konnte vorhin doch nicht abwarten und habe ein erneutes Werksreset/pairing gemacht. Nun steht in den Readings dieses seltsamen Thermostats

Code Auswählen Erweitern

PairedTo 0xF10000 2024-09-18 15:11:03
RegL_00.
RegL_07.

Das ist, sogar mit meinen laienhaften Kenntnissen erkennbar, Unsinn, oder? Bevor du fragst, weil das ja auch bei nicht gesetzter hmId kommen könnte: die hmId ist gesetzt (250258). Ich denke mal, das Teil war schon mal verschickt worden von Ama..., wurde zurück geschickt, weil es nicht funktioniert (siehe oben), der Ama...-Techniker (hust) hat neue Batterien rein gemacht -> ah, Display geht an -> ist in Ordnung -> zurück in den Verkauf. Und das habe ich bekommen. Da wird wohl das Schreiben in ein oder mehrere Register nicht funktionieren. Ich geb jetzt auf. Vielen Dank an Ansgar und Dich!! Ich muss jetzt nur klären, ob ich fies bin und es auch zurück schicke (dann kriegt vermutlich der nächste Ärger damit), oder ob ich auf die 70€ verzichte. Denke .. Denke .. ich glaube nicht

Gruß
Holger

[frank]

1. devices löschen und/oder resetten ist in der regel kontraproduktiv!
das zauberwort heisst "drüberpairen"

2. gestern war es jedenfalls schon von dir gepairt:

Code Auswählen Erweitern

2024.09.15 21:54:30 3: LogHist Cullie:  04212352 A F101 06385212 00 0F 03 8610 787FA4 250258 0AA8DF0F0000 -40.5dB
3.

Nun habe ich etwas getan, worauf hier die Todestrafe steht: Attribut händisch in der fhem.cfg eingetragen.

auch wenn ich nicht zur gruppe der henker gehöre, könnte es in deinem fall passen. 

[holmexx]

Tja, das "drüberpairen". Ich habe x-Mal drüber gepairt, x-Mal reset/pairing gemacht, ohne dass es je zu einem wirklichen Erfolg gekommen ist. Sobald ich ins Schlafzimmer komme, geht das Thermostat mittlerweile sofort in Paarungsstellung (sorry ).

Wie es aussieht, freut sich nur der CUL (hier: Cullie), dass er sich gepaart hat. Vom Thermostat (787FA4/hm_Schlafzimmer) habe ich noch keine solche Freudensschreie gehört. Trotz alledem will mal noch die beiden fehlenden Listings nachtragen (siehe Anhang). "Cullie" heißt mittlerweile "Scully", weshalb die VCCU natürlich "Mulder" heißen MUSS.

Gruß
Holger

[holmexx]

Apropos Henker: Die Fehlermeldung "Scully does not support CUL_HM" sollte gefixt werden. Mein spontaner Verdacht ist, dass auf den Typ "CUL" geprüft wird, es aber bedingt durch die Firmware, ein "TSCUL" ist. Sollte ich irgendwo anders noch mal einen Thread diesbezüglich aufmachen, oder geht das seinen internen Weg?

[frank]

Tja, das "drüberpairen". Ich habe x-Mal drüber gepairt, x-Mal reset/pairing gemacht, ohne dass es je zu einem wirklichen Erfolg gekommen ist.

jetzt ist der rt, warum auch immer, mit F10000 gepairt.
darum reagiert er jetzt nur noch auf befehle von seinem herrchen F10000, also nicht mehr auf deine zentrale, mit der hmid 250258.

also erst am device mit knöpfchen drücken den werkreset machen.
dann über die vccu pairen.

[noansi]

Hallo Holger, hallo Frank,

2. gestern war es jedenfalls schon von dir gepairt:

Guter Hinweis in doppelter Hinsicht.
Hatte ich nicht realisiert
und gestern mit einem meiner RTs das Verhalten nachzustellen versucht.
Und siehe da:

Code Auswählen Erweitern

2024.09.17 23:25:49.924 4: LogHist CUNX_HM868:  07519330 A F101 14340424 00 0F B7 8610 519E1F F11034 0A9CD10A32C4 -41dB
2024.09.17 23:25:49.925 4: LogHist CUNX_HM868:  07519522 A F103 14340520 01 09 B7 A112 F11034 519E1F  _CCAdly:4 _dhmSt:96
2024.09.17 23:25:49.928 4: TSCUL_ParseTsHM: CUNX_HM868 HM repeat failed to 519E1F/TR_Wohnen:  07519692 A F109 14340788 00 09 B7 A112 F11034 519E1F  _sfail _noAnsw
ist mal aufgetreten.
Spontane Vermutung, wenn der RT seinen Status an die Zentrale schickt, statt an broadcast, dann mag er keine "A112 Hallo Wach" Aufforderung. Und erst recht nicht beantworten. Eventuell geht es ihm in dem Zustand auch zu schnell.

Code Auswählen Erweitern

2024.09.17 23:26:21.672 4: TSCUL_Parse: CUNX_HM868  07551457 A F103 14372420 01 0B D6 A001 F11034 519E1F 0403 _CCAdly:4 _dhmSt:96
2024.09.17 23:26:21.804 4: TSCUL_Parse: CUNX_HM868  07551588 A F101 14372572 00 0E D6 8010 519E1F F11034 0100000000 -38dB
2024.09.17 23:26:21.833 4: TSCUL_send:  CUNX_HM868  211592                 As 10 E6 A001 F11034 519E1F 04040000000001
2024.09.17 23:26:21.836 4: TSCUL_SendFromQueueHM:  CUNX_HM868  id:519E1F rtoms:2240
2024.09.17 23:26:21.863 4: TSCUL_Parse: CUNX_HM868  07551651 A F101 14372600 00 0F B8 8610 519E1F F11034 0A9CD10A32C4 -38dB
2024.09.17 23:26:21.950 4: TSCUL_Parse: CUNX_HM868  07551738 A F103 14372696 01 10 E6 A001 F11034 519E1F 04040000000001 _CCAdly:4 _dhmSt:96
2024.09.17 23:26:22.228 4: TSCUL_Parse: CUNX_HM868  07552015 A F103 14372972 01 10 E6 A001 F11034 519E1F 04040000000001 _CCAdly:4 _dhmSt:372
2024.09.17 23:26:22.359 4: TSCUL_Parse: CUNX_HM868  07552143 A F101 14373128 00 0E E6 8010 519E1F F11034 0208000000 -38dB
gab es auch mal.

Was dann erst mal hilft, ist beim RT ein set clear msgEvents damit die Befehls Queue geleert wird und dann ein getConfig. Und warten, bis der RT seinen Status an broadcast sendet und dann sollte er auf A112 reagieren und die Register können dann gelesen werden.

Natürlich alles erst, wenn das Fremde Pairing erst mal entfernt ist.

Ein list vom CUL wäre noch interessant.

Gruß, Ansgar.

[frank]

das ist dann also ein "cyclic-broadcast-bug", der offensichtlich mit fw 1.5 beim rt eingeführt wurde.

das ist dann also der grund, weswegen im wiki zum rt eine selten absurde vorgehensweise zum pairen empfohlen wird. 
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Pairen_bei_Firmware_1.5

Was dann erst mal hilft,

wenn man alle befehle immer manuell über knöpchen-drücken (auslösen des "countdowns") von fhem abholt bis fhem cmds_done anzeigt, gibt es scheinbar auch keine probleme.

[noansi]

Hallo Frank, hallo Holger,

das ist dann also ein "cyclic-broadcast-bug", der offensichtlich mit fw 1.5 beim rt eingeführt wurde

gute Frage.

Vor hektischen Korrekturaktionen erst mal schauen, ob Holger mit den letzten Tipps weiter kommt.

Die A112 Automatik in der Firmware hat ansonsten bisher bei mir prima funktioniert. Möchte ich nicht wieder raus werfen, nur weil sich eine Firmware Version eines devices merkwürdig verhält. Eine Prüfung auf Destination 000000 könnte ich vor der Generierung der A112 message noch ergänzen, aber dann muss klar sein, ob das nicht andere devices wieder beeinträchtigt, weil die dann wieder einschlafen.

PERL Warning: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_autocreate.pm line 747

Ja, undef define Rückgabe von CUL_HM führt dazu, da diesbezüglich unsauber in autocreate behandelt. Aber nicht tragisch.

fail: Scully does not support CUL_HM

Ist ein Bug.
Sämtliche Clients Abfragen zum IO machen auf /:CUL_HM:/ . Blöd, wenn nur einer oder keiner der Doppelpunkte in den Clients beim CUL steht, weil eben sehr wenige Clients oder nur CUL_HM unterstützt werden.
Das ist nicht nur in meiner Sonderversion so, sondern auch in der 10_CUL_HM.pm im SVN.

IOList löschen bringt noch ein paar Unsauberkeiten als Warnings bezüglich nutzung von undef Strings (weil das Attribut mit del erst gelöscht wird, dann aber nochmals verwendet wird).

TSCUL_ParseTsHM: Scully NAME undef for did 000000

000000 sollte der Actiondetctor sein. Merkwürdig, dass der keinen Namen hat, oder ist keiner angelegt? Ein unsauberes if mit Zugriff auf ein undefiniertes device hash im Code kann so was auslösen, respektive das device kaputt erstellen.
Ich habe einen ActionDetector in meiner fhem.cfg definiert und den Log Eintrag noch nie beobachtet. Der Log Eintrag ist Reultat einer Prüfung in TSCUL, um solche kaputten HM device hashes entdecken zu können.
Ein ActionDetector sollte aber von CUL_HM automatisch angelegt werden, wenn keiner existiert, so anscheinend Martins Plan mit CUL_HM_ActGetCreateHash(). Das kann natürlich dann auch schief gehen.
Für das Pairing sollte das jedoch ohne Belang sein.

Gruß, Ansgar.

[holmexx]

Moin, Moin

eigentlich wollte ich das Teil ja heute zurück schicken, aber da ihr nicht aufgebt, werde ich weiter versuchen. Das nur als Zwischenmeldung, da ich heute vor dem Abend nicht dazu komme.

Gruß
Holger

[holmexx]

Es ist ja kaum zu fassen,

"normales" reset/pairing hatte ich ja nun schon unzählige Male gemacht, so dass ich gleich mal den von Frank vorgeschlagenen intuitiven Weg genommen habe (also diesen). Und Tatatataaaaa: In den Readings steht

Code Auswählen Erweitern

PairedTo 250258

Dafür sind die "_sfail _noAnsw" im Sekundenabstand im Log wieder da (die History dazwischen habe ich weggelassen):

Code Auswählen Erweitern

2024.09.19 18:46:23 3: TSCUL_ParseTsHM: Scully HM repeat failed to 787FA4/th_Schlafzimmer:  02981087 A F109 06924676 00 09 25 A112 250258 787FA4  _sfail _noAnsw
...
2024.09.19 18:46:24 3: TSCUL_ParseTsHM: Scully HM repeat failed to 787FA4/th_Schlafzimmer:  02981895 A F109 06925484 00 10 26 A001 250258 787FA4 03055802250107 _sfail _noAnsw
...
2024.09.19 18:46:25 3: TSCUL_ParseTsHM: Scully HM repeat failed to 787FA4/th_Schlafzimmer:  02983387 A F109 06926976 00 0D 27 A001 250258 787FA4 03080510 _sfail _noAnsw

Außerdem gelingt mir das Einrichten des virtuellen Fensterkontaktes nicht wieder. Erneut ist es - denke ich - ein Pairing-Problem. Was habe ich getan:

• define vdev_Schlafzimmer CUL_HM 580225
• attr vdev_Schlafzimmer model VIRTUAL
• attr vdev_Schlafzimmer IOgrp Mulder (ist die VCCU)
• set vdev_Schlafzimmer virtual 2
• gewartet bis CMDs_DONE
• ...
• rename vdev_Schlafzimmer_Btn1 vfk_Schlafzimmer
• attr vfk_Schlafzimmer webCmd postEvent open:postEvent closed
• set vfk_Schlafzimmer peerChan 0 th_Schlafzimmer_WindowRec single set

Und da beginnen die Pairing-Probleme wieder. In den Readings des virtuellen Fensterkontakts steht:

Code Auswählen Erweitern

peerList th_Schlafzimmer_WindowRec

In den Attributes:

Code Auswählen Erweitern

peerIDs 787FA403

Das ist alles i.O. soweit. Aber das th_Schlafzimmer_WindowRec meldet (Readings):

Code Auswählen Erweitern

cfgState updating 2024-09-19 18:49:40 <-- seit 45 Minuten unverändert
state    unpeered

Attributes:

Code Auswählen Erweitern

peerIDs peerUnread

Folgerichtig - wie ich vermute - schlägt dann auch

Code Auswählen Erweitern

set th_Schlafzimmer_WindowRec regSet winOpnTemp 8 vfk_Schlafzimmer

fehl mit

cannot calculate value. Please issue set th_Schlafzimmer_WindowRec getConfig first - invalid

Dass das Setzen der Temperatur auf 8°C ein Gimmick ist, ist mir schon klar. Aber irgendwas läuft doch wieder nicht rund, oder? Oder bin ich zu ungeduldig??

Gruß
Holger

P.S.: der Nachbar hat offenbar nicht nur 2 Geräte, sondern mittlerweile sehe ich 22 Geräte, die nicht zu mir gehören. Ist das ein zusätzliches Problem?

[noansi]

Hallo Holger,

schön, dass Du bis zu PairedTo 250258 gekommen bist.

Es ist nicht gut, wenn Du das mit den ... weg lässt, denn da steckt jeweils ein Stück Vorgeschichte im Log, was u.U. helfen kann, die Glaskugel zu erhellen.

ist beim RT ein set clear msgEvents damit die Befehls Queue geleert wird und dann ein getConfig. Und warten, bis der RT seinen Status an broadcast sendet

probiert? Ergebnis? Log? List?
Das Log kannst Du bitte noch verbessern, wenn Du vorher beim CUL verbose 4 setzt. Dann ist die ganze Kommunikation im Log.

Ein list vom CUL wäre noch interessant.

habe ich auch nicht grundlos geschrieben.

Gruß, Ansgar.

[holmexx]

Hallo Ansgar,

Es ist nicht gut, wenn Du das mit den ... weg lässt, denn da steckt jeweils ein Stück Vorgeschichte im Log, was u.U. helfen kann, die Glaskugel zu erhellen.

Code Auswählen Erweitern

2024.09.19 18:46:23 3: LogHist Scully:  02847140 A F001 06790724 00 0F 24 8610 787FA4 000000 0AA8D20F1700 -46dB
2024.09.19 18:46:23 3: LogHist Scully:  02859995 A F001 06803576 00 27 10 008E 98FA3F 29F40A 0006FDF7B02F69F1513DFDA3F6AEE7B380E654E1D1DEA12B548C952AEA6F -100.5dB
2024.09.19 18:46:23 3: LogHist Scully:  02863053 A F001 06806636 00 21 10 008E AD12CF 29F40A 16123F7955C0D7EABE22265B2B91EB9DEA64C904164E3853 -102dB
2024.09.19 18:46:23 3: LogHist Scully:  02863239 A F001 06806824 00 21 10 008E AD12CF 29F40A 16123F7BC7A89B0E0CBBBDBA0915BC14B8D8D2B083B8907B -102.5dB
2024.09.19 18:46:23 3: LogHist Scully:  02889292 A F001 06832876 00 0F 62 8610 787C6F 000000 0A88D40A0040 -51dB
2024.09.19 18:46:23 3: LogHist Scully:  02977280 A F001 06920868 00 0D BC A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:23 3: LogHist Scully:  02977552 A F001 06921140 00 0D BD A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:23 3: LogHist Scully:  02978075 A F001 06921664 00 0D BE A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:23 3: LogHist Scully:  02978920 A F001 06922508 00 0D BF A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:23 3: LogHist Scully:  02980078 A F001 06923664 00 0D C0 A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:23 3: LogHist Scully:  02980141 A F001 06923728 00 0F 25 8610 787FA4 000000 0AA8D20F1700 -46dB
2024.09.19 18:46:23 3: LogHist Scully:  358704                 As 10 26 A001 250258 787FA4 03055802250107
2024.09.19 18:46:23 3: LogHist Scully:  02980848 A F103 06924416 01 09 25 A112 250258 787FA4  _CCAdly:4 _dhmSt:688
2024.09.19 18:46:23 3: TSCUL_ParseTsHM: Scully HM repeat failed to 787FA4/th_Schlafzimmer:  02981087 A F109 06924676 00 09 25 A112 250258 787FA4  _sfail _noAnsw
2024.09.19 18:46:24 3: LogHist Scully:  02977280 A F001 06920868 00 0D BC A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02977552 A F001 06921140 00 0D BD A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02978075 A F001 06921664 00 0D BE A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02978920 A F001 06922508 00 0D BF A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02980078 A F001 06923664 00 0D C0 A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02980141 A F001 06923728 00 0F 25 8610 787FA4 000000 0AA8D20F1700 -46dB
2024.09.19 18:46:24 3: LogHist Scully:  358704                 As 10 26 A001 250258 787FA4 03055802250107
2024.09.19 18:46:24 3: LogHist Scully:  02980848 A F103 06924416 01 09 25 A112 250258 787FA4  _CCAdly:4 _dhmSt:688
2024.09.19 18:46:24 3: LogHist Scully:  02981087 A F109 06924676 00 09 25 A112 250258 787FA4  _sfail _noAnsw
2024.09.19 18:46:24 3: LogHist Scully:  02981121 A F103 06924684 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:956
2024.09.19 18:46:24 3: LogHist Scully:  02981389 A F103 06924952 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:1224
2024.09.19 18:46:24 3: LogHist Scully:  02981496 A F101 06925084 00 0D C1 A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02981657 A F103 06925220 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:1492
2024.09.19 18:46:24 3: TSCUL_ParseTsHM: Scully HM repeat failed to 787FA4/th_Schlafzimmer:  02981895 A F109 06925484 00 10 26 A001 250258 787FA4 03055802250107 _sfail _noAnsw
2024.09.19 18:46:25 3: LogHist Scully:  02980141 A F001 06923728 00 0F 25 8610 787FA4 000000 0AA8D20F1700 -46dB
2024.09.19 18:46:25 3: LogHist Scully:  358704                 As 10 26 A001 250258 787FA4 03055802250107
2024.09.19 18:46:25 3: LogHist Scully:  02980848 A F103 06924416 01 09 25 A112 250258 787FA4  _CCAdly:4 _dhmSt:688
2024.09.19 18:46:25 3: LogHist Scully:  02981087 A F109 06924676 00 09 25 A112 250258 787FA4  _sfail _noAnsw
2024.09.19 18:46:25 3: LogHist Scully:  02981121 A F103 06924684 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:956
2024.09.19 18:46:25 3: LogHist Scully:  02981389 A F103 06924952 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:1224
2024.09.19 18:46:25 3: LogHist Scully:  02981496 A F101 06925084 00 0D C1 A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:25 3: LogHist Scully:  02981657 A F103 06925220 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:1492
2024.09.19 18:46:25 3: LogHist Scully:  02981895 A F109 06925484 00 10 26 A001 250258 787FA4 03055802250107 _sfail _noAnsw
2024.09.19 18:46:25 3: LogHist Scully:  361145                 As 0D 27 A001 250258 787FA4 03080510
2024.09.19 18:46:25 3: LogHist Scully:  02982614 A F103 06926176 01 0D 27 A001 250258 787FA4 03080510 _CCAdly:4 _dhmSt:2448
2024.09.19 18:46:25 3: LogHist Scully:  02982878 A F103 06926444 01 0D 27 A001 250258 787FA4 03080510 _CCAdly:4 _dhmSt:2716
2024.09.19 18:46:25 3: LogHist Scully:  02983146 A F103 06926712 01 0D 27 A001 250258 787FA4 03080510 _CCAdly:4 _dhmSt:2984
2024.09.19 18:46:25 3: TSCUL_ParseTsHM: Scully HM repeat failed to 787FA4/th_Schlafzimmer:  02983387 A F109 06926976 00 0D 27 A001 250258 787FA4 03080510 _sfail _noAnsw
Hinweis: 48FAD6 ist ein in der Zwischenzeit hinzugekommender Fensterkontakt, der aber keinerlei Probleme bereitet. Alle anderen hier auftauchenden Geräte gehören nicht zu mir.

ist beim RT ein set clear msgEvents damit die Befehls Queue geleert wird und dann ein getConfig. Und warten, bis der RT seinen Status an broadcast sendet

probiert? Ergebnis? Log? List?

Wie oben dargelegt, habe ich ausschließlich den aus dem ELV-Forum übernommenen umständlichen Pairing-Weg gewählt. Dieser hat zum Erfolg geführt (wie auch im CUL-Listing ersichtlich). Dadurch sind die Fragen entbehrlich.

Ein list vom CUL wäre noch interessant.

habe ich auch nicht grundlos geschrieben.

Dieser Ton ist arrogant und gefällt mir nicht. Das CUL-Listing befindet sich im Anhang.


Ich möchte keinerlei Schärfe einbringen und das auf sachlicher Ebene weiterführen. Seit ich den Forumspost vorhin abgeschickt habe (19:53 Uhr), habe ich mein FHEM-System nicht mehr angefasst und auch nicht beobachtet. Beim Erstellen des Listing des CUL ist mir folgendes aufgefallen:

Readings des th_Schlafzimmer_WindowRec

Code Auswählen Erweitern

RegL_01.                 00:00 08:00 2024-09-19 20:52:15
RegL_03.vfk_Schlafzimmer 00:00 04:32 2024-09-19 20:52:21
RegL_07.vfk_Schlafzimmer 00:00 05:10      2024-09-19 20:52:21
cfgState                 updating         2024-09-19 20:49:28
peerList                 vfk_Schlafzimmer 2024-09-19 20:52:15
state                    peered           2024-09-19 20:52:15

Vom Absetzen des "set vfk_Schlafzimmer peerChan 0 th_Schlafzimmer_WindowRec single set" bis sich das Peering in den Readings niederschlug, sind ~2 Stunden vergangen. Ist das ein normales Verhalten?

Gruß
Holger

[holmexx]

Nachtrag:

Der weiter oben angemahnte Befehl

Code Auswählen Erweitern

set th_Schlafzimmer_WindowRec regSet winOpnTemp 8 vfk_Schlafzimmer

hat jetzt scheinbar funktioniert. Scheinbar deshalb, weil es einerseits keine Fehlermeldung gab, andererseits mir eine Möglichkeit zum Überprüfen fehlt. Einen Hinweis darauf, ob das Rücklesen vielleicht gar nicht möglich ist, oder sich der Wert in den hexadezimalen Reg-Listings befindet, konnte ich im Wiki nicht finden.

Noch eine Beobachtung, da es zeitlich mit dem offenbar erfolgreichen Peering des WindowRec-Channels korreliert: es hat seit 20:49 Uhr keine "_sfail _noAnsw"-Nachricht des th-Schlafzimmer mehr gegeben (Stand 23:53 Uhr).

[noansi]

Hallo Holger,

48FAD6 ist ein in der Zwischenzeit hinzugekommender Fensterkontakt, der aber keinerlei Probleme bereitet. Alle anderen hier auftauchenden Geräte gehören nicht zu mir.

Nun, in ... hat er kurz davor gequasselt und damit indirekt zu _sfail _noAnsw beigetragen.

Code Auswählen Erweitern

2024.09.19 18:46:23 3: LogHist Scully:  02980141 A F001 06923728 00 0F 25 8610 787FA4 000000 0AA8D20F1700 -46dBIst ein Status an "alle", also nicht an deine Zentrale gerichtet.

Code Auswählen Erweitern

2024.09.19 18:46:23 3: LogHist Scully:  02980848 A F103 06924416 01 09 25 A112 250258 787FA4  _CCAdly:4 _dhmSt:688Kommt zu spät. Der RT ist wohl wieder eingeschlafen.
Das ist nicht das eingangs gezeigte Problem.

Dadurch sind die Fragen entbehrlich.

Das Einrichten einer VCCU hat dazu geführt, mehr Infos über Deine Umgebung zu liefern und einen Vergleich mit/ohne VCCU zu ermöglichen. Meine Vergleichsumgebung läuft schon lange mit VCCU, da kann die Variante ohne VCCU nicht betrachtete Code Schwächen aufzeigen.

List vom CUL zeigt mit scF dass Deine "CUL Clock" leicht vorgeht, damit also effektiv delays etwas kürzer ausführt, im Vergleich zu meinen IOs, die etwas "nachgehen". Wenn der RT etwas langsamer wäre und die Toleranz in Summe zu knapp wären, wären im ausführlichen Log häufiger überhörte CUL Antworten erkennbar. Ansatz wäre dann eine Firmware mit etwas mehr Antwort-Delay zu kompilieren.

Gelesene Register sind die Basis für Einstellungsänderungen. Von batteriebetriebenen devices können die nur gelesen werden, wenn sie wach sind, also nicht gerade strom sparen.

hat jetzt scheinbar funktioniert. Scheinbar deshalb, weil es einerseits keine Fehlermeldung gab, andererseits mir eine Möglichkeit zum Überprüfen fehlt. Einen Hinweis darauf, ob das Rücklesen vielleicht gar nicht möglich ist, oder sich der Wert in den hexadezimalen Reg-Listings befindet, konnte ich im Wiki nicht finden.

Code Auswählen Erweitern

cfgState  okIst meist ein gut verständlicher Hinweis, das alle Register gelesen wurden. Den muss man aber erst mal zu sehen bekommen haben.
Mit dem Attribut expert auf defReg,allReg,rawReg bekommst Du mehr von Registern zu sehen.

Wenn Dein Problem nur das "Fluten" des Logs darstellt, beim CUL kannst Du mit dem Attribut hmLogLev eindämmen, ab welchem verbose die kurze LogHist ins Log geschrieben werden soll default ist 3.

Gruß, Ansgar.

[holmexx]

Die meisten Meldungen sind ja von Geräten des Nachbars. Die Leute sind neu im Haus und ich weiß (noch) nicht viel. Ich habe bisher 22 Fremdgeräte identifiziert. Frage: da der CUL der 1%-Regel unterworfen ist, kann das ein Problem sein und vielleicht noch schlimmer werden, da ich alle meine MAXe (4 Thermostate und 5 Fensterkontakte) eigentlich auf HomeMatic umstellen wollte?

Zwischen Absetzen des Befehls und der sichtbaren Reaktion in den Readings (siehe obiger Post, letzte Zeilen) sind 2 Stunden vergangen. Frage: muss ich tatsächlich solange warten?


Seit dem erfolgreichen Pairing gestern tauchte eine "sfail _noAnsw"-Meldung vom th_Schlafzimmer bis jetzt (also gut 19 Stunden) nur ein einziges Mal auf. Das mag wohl dann dem ungünstigen Timing geschuldet sein. Der virtuelle Fensterkontakt ist nun eingebunden und funktioniert -> das Thermostat reagiert.

Das ist nicht das eingangs gezeigte Problem.

Welches ist denn das anfängliche Problem? Ich dachte, dass wäre das nicht erfolgreiche Pairing gewesen.

"cfgState ok" habe ich bei diesem Thermostat noch nie gesehen. Auch heute, jetzt, steht da cfgState updating". Allerdings, wie ich gerade feststelle, auch beim Fensterkontakt. Da dieses Konstrukt ja offenbar funktioniert (sprich das Thermostat regelt runter und wieder rauf passend zum Status des Fensterkontaktes), kann ich die ganzen Meldungen, nicht passenden Status etc. einfach ignorieren? Ich meine, das Heruntersetzen der Verbosity beseitigt ja eventuelle Probleme nicht.

Etwas ketzerisch: ist HomeMatic tatsächlich so schwierig? eq-3 wird sicherlich nicht sooo glücklich sein, dass nicht ihre Zentrale benutzt wird, sondern alles in einer betriebsfremden Umgebung betrieben wird. Was ich sagen will ist: muss ich mich, wenn ich HomeMatic mit FHEM benutzen will darauf einstellen, dass möglicherweise nicht alles rund läuft?

Gruß
Holger

[holmexx]

Ich lasse mir das alles gerade noch mal durch den Kopf gehen, u.a. CUL Clock. Ich betreibe FHEM exklusiv auf einem RaspPI 3B+ im Dauerbetrieb, der mitsamt seinem "originalen" Netzteil zig Jahre alt ist. Wie alt genau kann ich nicht mehr sagen. Der CUL (4 Jahre alt, allerdings bis vor Kurzem ungenutzt) sitzt direkt am USB-Port des RaspPI. Der RaspiPI selbst ist mit einem load von ~0,21 und ~0,8 GB von 4 GB RAM-Nutzung im Langeweile-Bereich. Könnte die Stromversorgung und/oder das allgemeine Alter des Ganzen eine Rolle spielen? Beherrscht Perl auf einem Raspbian Multi-Threading? Kann zu vieles Schreiben in die Logs auf eine vergleichsweise langsame SD-Karte zu Problemen führen?

Nur so allgemeine Gedanken.

[noansi]

Hallo Holger,

hier https://forum.fhem.de/index.php?msg=1320574 gibts den neueren Firmwarestand VTS0.42 nebst aktualiserten Modulen.
Wurde eh mal Zeit dafür.

Da Du beim CUL das Attribut hmForceLzyCfg nicht gesetzt hattest, ist der CUL_HM Code nicht passend gewesen, da der von gesetztem Attribut ausgeht.
getConfig zu einem RT läuft damit sauber durch (keine Störungen dur Zwischengeplapper vorraus gesetzt) mit CULV3 mehrfach wiederholt getestet.
Ich habe das Attribut nun aus TSCUL entfernt. Wakup und Lazy-Config verschleißen mehr das EEPROM. Und damit muss ein CULV3 oder nanoCUL Nutzer vorher überlegen wie viele EEPROM Zugriffe seine automatisierten Umkonfigurationsen von Wakeup und Lazy-Config devices verursachen. Reserve CUL parat zu haben kann nicht schaden.

Deine anderen roten Punkte habe ich auch gefixt, denke ich.

Gruß, Ansgar.

[noansi]

Hallo Holger,

durch den Kopf gehen, u.a. CUL Clock

Hat mein CULV3 genauso. Normal. Modell oder Serienstreuung.

Gruß, Ansgar.

[noansi]

Hallo Holger,

Frage: da der CUL der 1%-Regel unterworfen ist, kann das ein Problem sein und vielleicht noch schlimmer werden

Mit den Nachbarn redet der CUL nicht, wenn Du ihn nicht dazu aufforderst, verschwendet daher auch kein Sendebudget darauf.
Deine credits kannst Du jederzeit beim CUL anschauen. Bursts sind "teuer" und sollten daher sparsam verwendet werden. Dein virtueller Fensterkontakt muss die RTs mit Burst aufwecken, um den Öffnungsstatus übermitteln zu können. Fensterwedeln wäre ungünstig.

Mehr Sorgen würde mir das unerwartete geisterhafte Pairen ungepairter Geräte mit einer Nachbarzentrale machen.

Frage: muss ich tatsächlich solange warten?

Probier die neue Version aus.

Welches ist denn das anfängliche Problem?

Eine unerwartete Protokollmerkwürdigkeit beim Pairen im Vergleich zu Aufwachen mit wach halten hast Du eingangs präsentiert.

Was ich sagen will ist: muss ich mich, wenn ich HomeMatic mit FHEM benutzen will darauf einstellen, dass möglicherweise nicht alles rund läuft?

Meine Testumgebung umfasst u.a. 2 RTs die mit virtuellem TH Sensor und virtuellem Fensterkontakt laufen, jedoch mit CUNX oder SCC als HM IO, somit ohne EEPROM Verschleiß. Mein CULV3 läuft normalerweise an langem Kabel abgesetzt als RFR und spielt mittlerweile nach Abgleich auch Temperatursensor.
Läuft ganz gut, nur ab und zu haben die RTs besseres zu tun und antworten mit NACK statt ACK.
In größerer Entfernung gibt es wohl einen Nachbarn, von dem ab und zu leise ein HM Paket empfangen wird.
Probleme können andere FHEM Module mit langen Rechenzeiten bereiten, so dass Antworten von FHEM verzögert werden und damit insbesondere batteriebetriebene Gräte wieder einschlafen zum Strom sparen.

Funk kann generell Ärger bereiten.
Wie sind Deine Erfahrungen mit MAX?

Gruß, Ansgar.

[holmexx]

Hallo Ansgar,

der CUL ist neu geflasht und die neuen Perl-Module sind eingespielt. Alles verlief völlig unspektakulär. Die ersten 30 Minuten sehen gut aus, keine der vorher in Massen aufgetretenen Meldungen im Log (_sfail _noAnsw/NAME undef for did). Lediglich gleich nach dem Neustart hat mich PERL ein einziges Mal beschimpft:

Code Auswählen Erweitern

PERL WARNING: Use of uninitialized value $1 in addition (+) at ./FHEM/10_CUL_HM.pm line 2086.
Aber nach einem Neustart ist PERL wohl immer etwas aufgeregt. Danke für Arbeit!!

Ich hatte mal 5 MAX-Thermostate und 2 MAX-Fensterkontakte in Betrieb, anfangs an einem originalen MAX-Cube. Diesen hatte ich alsbald zu einem CUL umgeflasht. Elektrisch hat diese Mini-Umgebung zusammen mit FHEM nie Probleme bereitet. Dieses MAX-Alzheimer habe ich nie beobachtet. Mechanisch sieht es da ganz anders aus. Die MAX-Thermostate halten nicht allzulange durch. Relativ schnell schafft es der Motor nicht mehr, das Ventil zu schließen. Ich hatte Eines, das nur eine einzige Saison durchgehalten hat. Aber da ich mal eine ganze Kiste für das sprichwörtliche "Appel und Ei" erworben hatte, hat mich das nicht gestört. Nun sind sie alle.

Mehr Sorgen würde mir das unerwartete geisterhafte Pairen ungepairter Geräte mit einer Nachbarzentrale machen.

Kannst du das mal noch etwas näher erläutern, bitte? Ich habe noch nicht so viel Kontakt mit dem Nachbarn, aber möglicherweise hat er ja auch Probleme? Ich weiß auch nicht, in welcher Umgebung seine Geräte laufen.

Gruß
Holger

[noansi]

Hallo Holger,

Lediglich gleich nach dem Neustart hat mich PERL ein einziges Mal beschimpft:

Das gibt sich, kleine Umstellungsbeschwerde bestehender Readings... dafür kannst Du jetzt bei den unknowns in der VCCU sehen, wie oft und mit welchem RSSI die rein kommen, nebst letztem Ziel und Länge der message.

Ein getConfig zum RT endet nun im cfgState ok nach updating, nachdem die CMDs_pending abgearbeitet sind?

Kannst du das mal noch etwas näher erläutern, bitte?

Franks Feststellung https://forum.fhem.de/index.php?msg=1320458.
Selbst könntest Du es nur gewesen sein, wenn Du da mal das Attribut hmId beim CUL gelöscht und dann gepaired hättest.

Gruß, Ansgar.

[holmexx]

Hallo Ansgar,

Ein getConfig zum RT endet nun im cfgState ok nach updating, nachdem die CMDs_pending abgearbeitet sind?

Ich befürchte, leider nicht (der Neustart war gegen 14:16 Uhr):

Code Auswählen Erweitern

CommandAccepted yes                                                                                       2024-09-21 14:36:12
D-firmware      1.5                                                                                       2024-09-19 17:23:11
D-serialNr      TEQ0440385                                                                                2024-09-19 17:23:11
PairedTo        0x250258                                                                                  2024-09-21 14:16:30
RegL_00.        00:00 01:01 02:01 09:01 0A:25 0B:02 0C:58 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 2024-09-21 14:16:30
RegL_07.                                                                                                  2024-09-21 14:28:09
battery         ok                                                                                        2024-09-21 17:06:25
batteryLevel    3                                                                                         2024-09-21 17:06:25
cfgState        updating                                                                                  2024-09-21 14:16:29
commState       CMDs_done                                                                                 2024-09-21 14:54:24
motorErr        ok                                                                                        2024-09-21 17:06:25
powerOn         2024-09-18 15:20:52                                                                       2024-09-18 15:20:52
recentStateType info                                                                                      2024-09-18 15:20:52
state           CMDs_done                                                                                 2024-09-21 14:54:24
time-request    -                                                                                         2024-09-21 14:54:24
Lt. Log wurde um 14:34:02 "getConfig" für 787FA4/th_Schlafzimmer abgesetzt. Seitdem wurde nichts mehr geloggt.

Selbst könntest Du es nur gewesen sein, wenn Du da mal das Attribut hmId beim CUL gelöscht und dann gepaired hättest.

Au Mann, ich glaube, ich habe da einen bösen Fehler gemacht. Ich habe FHEM jetzt 3 Mal neu aufgesetzt; die ersten 2 Male allerdings nur die fhem.cfg und alle Log-Dateien weg geworfen. Ich denke, die fhem.save habe ich übersehen. Jetzt, beim 3. Mal, hatte ich kurzerhand den gesamten RaspPi neu aufgesetzt - inkl. neu formatierter SD-Karte. Und Franks Beobachtung ist vor dem kompletten Neumachen entstanden. Asche über mein Haupt.

Gruß
Holger

[holmexx]

... ach, so den Fensterkontakt haben wir ja auch noch:

Code Auswählen Erweitern

PairedTo  0x250258                      2024-09-18 19:28:16
RegL_00.
RegL_01.  00:00 08:01 20:9C 21:00 30:06 2024-09-21 15:18:56
aesKeyNbr 00                            2024-09-18 19:28:15
alive     yes                           2024-09-21 17:05:48
battery   ok                            2024-09-21 17:05:48
cfgState  updating                      2024-09-21 15:18:55
commState CMDs_done                     2024-09-21 17:05:48

Frage: müsste ein entprechendes "getConfig" im Log zu sehen sein, oder passiert das - da anderes Perl-Modul - hier stumm? Die Frage impliziert, dass nämlich kein entsprechender Log-Eintrag da ist. Grrr, das muss ich zurück nehmen. Die SSH-Verbindung zum Pi war unterbrochen.

[noansi]

Hallo Holger,

hast Du ein HMinfo definiert?
Wenn nicht, dann bleibt es bei updating, da die Überprüfung der config nur darin läuft.

Gruß, Ansgar.

[holmexx]

Sorry, immer noch kein Profi. Diese Neuinstallation hat noch kein HMInfo. Wirkt das rückwirkend?

[holmexx]

Meine Frage ist Unsinn, glaube ich. HMinfo ist eingerichtet, ein getConfig für den Fensterkontakt ausgelöst (18:05 Uhr) ...

[noansi]

Hallo Holger,

ein getConfig für den Fensterkontakt ausgelöst (18:05 Uhr) ...

Fensterkontakt -> nicht in Untätigkeit vor dem Rechner verharren, denn dann passiert nichts, weil der Fensterkontakt schläft. -> Fenster Öffnen oder Schließen triggert erst das Abarbeiten wartender Kommandos.

Gruß, Ansgar.

[holmexx]

Oh, danke für den Tipp ...

Fenster geöffnet, geschlossen, das ist der Fensterkontakt:

Code Auswählen Erweitern

cfgState  updating  2024-09-21 18:05:17
commState CMDs_done 2024-09-21 18:21:57

Das ist das Thermostat nach getConfig um 18:17 Uhr:

Code Auswählen Erweitern

cfgState  updating  2024-09-21 18:17:38
commState CMDs_done 2024-09-21 18:19:30

Da ich wieder Auslassungen gemacht habe: ich traue mich mittlerweile einzuschätzen, dass die jeweils anderen Readings plausibel/i.O. sind.

Gruß
Holger

[holmexx]

... auch die VCCU ist i.O. Alle unbekannten Geräte habe ich bereits gesehen; vorhin war mal "XmitOpen 1" zu sehen, was ich als "ein offener Burst" interpretiert habe (vom Fensterkontakt initiiert). Das ist aber jetzt auch nicht mehr da. Das Log ist völlig sauber.

[noansi]

Hattest Du fhem nach der HMinfo Definition neu gestartet?

[holmexx]

Ja, hatte ich

[holmexx]

Hallo Ansgar,

würde es mit dieser Huckepack-Platine für den RaspPi (SCC) besser werden (unabhängig vom EEPROM-Verschleiß)? Eigentlich wollte ich bei busware.de zwar nie wieder etwas bestellen (wegen des nicht vorhandenen Kundenservices, Bestellbestätigung, voraussichtliche Lieferzeit ...), aber wenn's hilft.

Ich frage deshalb, weil in Punkto cfgState tut sich nichts. Alles andere kommt aber rein. Ich habe mal mit dem Handrädchen am Thermostat gespielt, Auto/Manuell umgeschaltet; das ist alles in FHEM zu sehen.

Gruß
Holger

[noansi]

Hallo Holger,

würde es mit dieser Huckepack-Platine für den RaspPi (SCC) besser werden (unabhängig vom EEPROM-Verschleiß)?

Das wäre die Alternative, wenn Du den CULV3 durch hast. Mit abgesetzter Antenne am besten.
Aber das dürfte aktuell nicht das Problem sein.

Was sagt HMinfo, wenn Du damit einen configCheck und einen peerCheck ausführst?

Gruß, Ansgar.

[holmexx]

Hallo Ansgar,

get hm configCheck ärgert sich etwas:

Code Auswählen Erweitern

configCheck done:

 IOgrp: missing or incomplete for virtual device
    vdev_Schlafzimmer: IOgrp: Mulder

 templist mismatch
    th_Schlafzimmer_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory

Zur IOgrp des virtuellen Schlafzimmer-CUL_HM: da hatte ich gestern oder vorgestern in einem anderen Thread nachgefragt, ob man bei Verwendung einer VCCU auch konsequenterweise IOgrp auf dem virtuellen Gerät setzen muss. Antwort: Ja. Ergo set vdev_Schlafzimmer attr IOgrp Mulder durchgeführt (Mulder ist die VCCU).

Falls die zweite Mahnung mit Wochenplänen zusammenhängt: habe ich bisher nicht wieder erstellt.

peerCheck --> freut sich, keine Meldungen.

Gruß
Holger

[holmexx]

... oh, war sogar schon vor 3 Tagen. Franks Antwort dazu:

mit vorhandener vccu nutzt man natürlich am besten das attribut IOgrp, damit diese das io "verwaltet/handelt".
es sollte aber auch attr IODev funktionieren.
beide attribute zusammen, sollten mit aktuellem fhem, verhindert werden.

Wir müssen mal zusammenlegen und Frank eine neue Tastatur kaufen. Da ist die Shift-Taste kaputt, beide sogar

[noansi]

Hallo Holger,

bei den virtuellen devices wird auch ein Vorzugsio gefordert. Also IOgrp Mulder:Scully bei Dir.
Hintergrund ist, dass die automatische IO Zuteilung bei mehreren HM-IOs nach RSSI bei diesen nicht sinnvoll funktioniert. Deswegen ist das in meiner HMinfo Variante so, dass es angemeckert wird.

Erstell mindestens eine leere tempList.cfg im fhem Verzeichnis.

Nee, nee, am Ende kann Frank mit funktionierenden Shift Tasten die HM messages sniffes nicht mehr lesen und was machen wir dann? No change in a running system!

Gruß, Ansgar.

[holmexx]

Hallo Ansgar,

die Datei habe ich angelegt

Code Auswählen Erweitern

-rw-r--r--  1 fhem dialout      0 21. Sep 21:52 tempList.cfg

aber

get hm configCheck schimpft immer noch mit mir. Fehlen da Schreibrechte für die Gruppe?

Code Auswählen Erweitern

th_Schlafzimmer_Clima: th_Schlafzimmer_Clima not found in file ./tempList.cfg

Gruß
Holger

[holmexx]

... die andere Mahnung ist natürlich weg

[holmexx]

Ich beantworte meine Frage selbst: nö, fehlen nicht. rw-rw-r-- ändert nichts.

/opt/fhem/FHEM/tempList.cfg ist es auch nicht. Seufz.

[noansi]

in HMinfo set tempList save

[holmexx]

Viel besser ! Alles gut jetzt.

[holmexx]

Das habe ich ganz aus den Augen verloren: 22:46 Uhr, beide Geräte: cfgState ok. Ich glaube, der CUL braucht anderes Futter, oder?

[holmexx]

Ich möchte eine Zusammenfassung geben:

Seit dem Aufspielen der Firmware v0.42 vor ~48 Stunden gab es nur noch 2 Mal eine "_sfail _noAnsw"-Meldung im Log. Das dürfte dann wohl ungünstigem Zusammentreffen von Toleranzen geschuldet sein. Es hat auch keine Auswirkungen auf die Gesamtfunktionalität. Die "NAME undef for did"-Meldungen sind gar nicht mehr aufgetreten. Was richtig lange dauert (2 Stunden oder mehr), ist, bis cfgState ok nach einem getConfig in den Readings auftaucht. Darauf muss ich mich einstellen. Ich denke, dass ein zu frühes peering (hier Fensterkontakt) dann nicht auf Anhieb erfolgreich ist; oder es scheint nur so, da halt cfgState noch nicht ok ist und in den Readings z.B. des WindowRec-Channels RegL_01 und RegL_07 fehlt.

Vielen Dank an Ansgar für das kurzfristige Erstellen der neuen Firmware und für die Geduld mit mir.

Gruß
Holger.

[noansi]

Hallo Holger,

mit HMinfo kannst Du noch nützliche Infos sammeln, z.B. Batterie ok oder Motor Fehler. siehe Attribute sumERROR und sumStatus.

Dann gibt es noch automatisches Speichern der mühsam ergatterten Registerzustände in HM_Info_Save.dat.
bei HMInfo habe ich mir die Attribute
autoArchive auf 1
autoLoadArchive auf 1_load
configDir auf /opt/fhem
configFilename auf HM_Info_Save.dat
autoUpdate auf 08:00
gesetzt. Dann holt sich fhem bei Reboot die Register aus HM_Info_Save.dat.

autoUpdate bewußt auf 8 Stunden, damit es nicht stört und so viel ändert sich auch nicht, dass man es öfter bräuchte.

Gruß, Ansgar.

[frank]

Hinweis: 48FAD6 ist ein in der Zwischenzeit hinzugekommender Fensterkontakt, der aber keinerlei Probleme bereitet. Alle anderen hier auftauchenden Geräte gehören nicht zu mir.

das sieht aber nicht so aus.

Code Auswählen Erweitern

2024.09.19 18:46:24 3: LogHist Scully:  02977280 A F001 06920868 00 0D BC A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02977552 A F001 06921140 00 0D BD A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02978075 A F001 06921664 00 0D BE A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02978920 A F001 06922508 00 0D BF A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02980078 A F001 06923664 00 0D C0 A610 48FAD6 250258 06010000 -50dB
...
2024.09.19 18:46:24 3: LogHist Scully:  02981496 A F101 06925084 00 0D C1 A610 48FAD6 250258 06010000 -50dB
das sieht für mich eigentlich danach aus, dass der fk keine antwort von der zentrale bekommt und daher die message wiederholt.
allerdings ist es seltsam, dass die wiederholungen fortlaufende message nummern haben.
das kenne ich so nicht.


zeig mal ein "get list full" vom fk.

[noansi]

Hallo Holger,

hier https://forum.fhem.de/index.php?msg=1321390 gibt es eine aktualisierte Version.
Ich habe den SPI Zugriff auf den Tranceiver korrigiert, sollte besser funktionieren, als der Stand, den Du jetzt hast.

Gruß, Ansgar.