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

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