HM-CC-RT-DN immer wieder getconfig

[sylvester]

Hallo,

ich betreibe mehrere HM-CC-RT-DN Funk-Heizkörperthermostate. Bei einem Thermostat wird immer mal wieder in unregelmäßigen Abständen der Weather-Kanal abgefragt:

Code Auswählen Erweitern


2016.05.25 15:59:14 3: CUL_HM set Bewaesserung_Weather getConfig
...
...
2016.05.25 22:13:37 3: CUL_HM set Bewaesserung_Weather getConfig
2016.05.25 22:47:10 3: CUL_HM set Bewaesserung_Weather getConfig
2016.05.26 01:15:18 3: CUL_HM set Bewaesserung_Weather getConfig
2016.05.26 01:46:23 3: CUL_HM set Bewaesserung_Weather getConfig
2016.05.26 02:15:55 3: CUL_HM set Bewaesserung_Weather getConfig
2016.05.26 02:47:06 3: CUL_HM set Bewaesserung_Weather getConfig
...
...
2016.05.26 05:35:43 3: CUL_HM set Bewaesserung_Weather getConfig
...
2016.05.26 05:46:31 3: CUL_HM set Bewaesserung_Weather getConfig
2016.05.26 06:17:13 3: CUL_HM set Bewaesserung_Weather getConfig


Das Device ist folgendermaßen definiert:

Code Auswählen Erweitern


define Bewaesserung_Main CUL_HM xxxxxx
attr Bewaesserung_Main IODev HMLAN_OG
attr Bewaesserung_Main IOgrp HM_VCCU:HMLAN_OG
attr Bewaesserung_Main actCycle 000:10
attr Bewaesserung_Main actStatus unknown
attr Bewaesserung_Main autoReadReg 4_reqStatus
attr Bewaesserung_Main event-min-interval actuator:180
attr Bewaesserung_Main event-on-change-reading actuator,measured-temp
attr Bewaesserung_Main expert 2_full
attr Bewaesserung_Main firmware 1.4
attr Bewaesserung_Main icon sani_sprinkling
attr Bewaesserung_Main model HM-CC-RT-DN
attr Bewaesserung_Main serialNr LEQ1520531
attr Bewaesserung_Main subType thermostat
attr Bewaesserung_Main webCmd getConfig:clear msgEvents:burstXmit
attr Bewaesserung_Main autoReadReg 5_readMissing

define Bewaesserung_Weather CUL_HM xxxxxx01
attr Bewaesserung_Weather model HM-CC-RT-DN
attr Bewaesserung_Weather peerIDs 11111102,
...


Kann mir jemand einen Tipp geben, wie ich die Ursache herausfinden kann?
Ein Reset des Thermostaten und neues pairen hat keinen Erfolg gebracht.

Was in diesem Zusammenhang noch auffällt:
Der Thermostat empfängt die Temperatur von einem virtuellen Homematic-Sensor. Bei diesem wird die Temperatur alle 2min auf 21°C gesetzt.
Trotzdem nimmt der Thermostat immer mal wieder den eigenen Sensor.

Code Auswählen Erweitern


define Bewaesserung_Temp_Sensor1 CUL_HM 11111102
attr Bewaesserung_Temp_Sensor1 model virtual_24
attr Bewaesserung_Temp_Sensor1 peerIDs 3578BB01,
attr Bewaesserung_Temp_Sensor1 room 39_System
attr Bewaesserung_Temp_Sensor1 verbose 0
attr Bewaesserung_Temp_Sensor1 webCmd virtTemp:virtHum

define Bewaesserung_set_Temp at +*00:02 {if (Value("Automatik_Bewaesserung") =~ /[Oo]n/) {fhem("set Bewaesserung_Temp_Sensor1 virtTemp 21.0")}}

define FalscheTemp_Notify_Bewaesserung notify Bewaesserung_Main:measured-temp.* {if(ReadingsNum("Bewaesserung", "measured-temp", 0) != 21.0) {fhem("set Bewaesserung_Temp_Sensor1 peerChan 0 Bewaesserung_Weather single;; set Bewaesserung_Temp_Sensor1 virtTemp 21.0")}}


Code Auswählen Erweitern


2016-05-24_12:15:43 Bewaesserung_Main measured-temp: 16.3
2016-05-24_12:17:43 Bewaesserung_Main measured-temp: 21.0
...
2016-05-24_13:33:55 Bewaesserung_Main measured-temp: 16.6
2016-05-24_13:35:56 Bewaesserung_Main measured-temp: 16.8
2016-05-24_13:38:47 Bewaesserung_Main measured-temp: 21.0
...
2016-05-25_01:04:56 Bewaesserung_Main measured-temp: 15.7
2016-05-25_01:07:08 Bewaesserung_Main measured-temp: 15.8
2016-05-25_01:10:09 Bewaesserung_Main measured-temp: 15.7
2016-05-25_01:12:56 Bewaesserung_Main measured-temp: 21.0
...
2016-05-25_10:47:40 Bewaesserung_Main measured-temp: 16.9
2016-05-25_10:50:32 Bewaesserung_Main measured-temp: 17.1
2016-05-25_10:55:33 Bewaesserung_Main measured-temp: 21.0
...
2016-05-25_13:27:02 Bewaesserung_Main measured-temp: 17.9
2016-05-25_13:29:42 Bewaesserung_Main measured-temp: 21.0
...
2016-05-25_15:56:54 Bewaesserung_Main measured-temp: 18.8
2016-05-25_15:59:14 Bewaesserung_Main measured-temp: 21.0
...
2016-05-25_22:10:55 Bewaesserung_Main measured-temp: 17.5
2016-05-25_22:13:37 Bewaesserung_Main measured-temp: 21.0
...
2016-05-26_01:12:51 Bewaesserung_Main measured-temp: 15.4
2016-05-26_01:15:19 Bewaesserung_Main measured-temp: 21.0
...
2016-05-26_05:33:29 Bewaesserung_Main measured-temp: 14.3
2016-05-26_05:35:43 Bewaesserung_Main measured-temp: 21.0


Viele Grüße

Stephan

[Linef]

Ich habe derzeit testweise zwei RTs mit einem Eigenbau Temperatursensor gepeert.
In der Regel folgen beide RTs exakt den Temperaturvorgaben des Sensors. Es gibt aber Zeitpunkte (so alle 1-2 Tage), da gehen beide RTs gleichzeitig (!!) auf ihre internen Sensoren.
Sendeprobleme des Temperatursensors kann ich dabei ausschließen, da die Sendetelegramme zu den betreffenden Zeitpunkten in FHEM normal mitprotokolliert werden (mitgesnifft).

Ich versteh's auch noch nicht ganz...

Martin

[martinp876]

der Sensor muss ein präzises Timing einhalten. Das kannst du nicht kontrollieren. Ich nehme an, das ist der Grund des Problems.

[Linef]

Durch Tests habe ich herausgefunden, daß der RT nach der Wartezeit, die sich aufgrund der Message-ID und der "speziellen Formel" berechnet, 10 Sekunden lang auf Empfang geht und auf Daten vom gepeerten Sensor wartet.
Die neue Wartezeit berechnet sich dann erst wieder ab dem empfangenen Telegramm.

Da ich erst 2 Sekunden nach Beginn des 10-Sekunden-Fensters sende, bin ich mir recht sicher, das Empfangsfenster auch zu treffen.

So weit zur Theorie...

[martinp876]

Das glaube ich nicht.
Das mit der Berechnung ist korrekt. Ist in cul_hm implementiert um virtuelle Aktoren zu unterstützen, als Sender.
Der RT hat erst einmal ein recht kurzes Fenster, definitiv unter einer sec. Wenn nichts kommt gilt die message als verloren, der RT schläft und wacht nach der erneuten berechnung wieder auf. Bleibt dann etwas länger wach. Wenn es wieder nichts ist geht es weiter, bis er im disconnected mode wohl 10sec wach bleibt. Dann doch wieder schläft, wegen der bat. Das ist dann der resync mode wenn die Verbindung verloren ist. Zu diesen Zeitpunkt wird sicher ein Ersatzwert gesetzt.

Ohne präzise Berechnung kannst du es vergessen. Alles schon probiert und implementiert.

[Linef]

Die Berechnung der Abstände der einzelnen Sendezeitpunkte (=Empfangsfenster-Abstand) habe ich ebenso wie in cul_hm (nur mit der Originalformel aus dem Homegear-Projekt) realisiert.
Mit FHEM sniffe ich mir dann die gesendeten Telegramme mit (Protokollierung der absoluten Zeitpunkte).

Zum Vergleich hatte ich in FHEM auch einen virtuellen Sensor realisiert und mit dem RT gepeert. Obwohl die Telegramme hier mit max. 300ms Zeitdifferenz (zur Sollzeit) verschickt werden, verliert auch hier der RT immer mal wieder den Sync mit dem virtuellen Sensor.

Mit dem Eigenbau-Sensor kann ich die Telegramme relativ exakt rausschicken. Ich habe auch zusätzlich ein ACK vom Sensor angefordert.

Die ACKs vom RT kamen nur dann, wenn das Telegramm vom Sensor innerhalb dieses 10-Sekunden-Fensters gesendet wurde.

Das 10-Sekunden-Fenster ist definitiv bei jeder einzelnen Übertragung offen und nicht erst, wenn der RT den Sync für verloren hält.
Ich konnte über viele Stunden hinweg die Telegramme z.B. am Ende dieses 10-Sek-Fensters absetzen und jeder einzelne Meßwert wurde vom RT akzeptiert (da er ihn ja selbst auch wieder rausschickt).

[martinp876]

wenn du das weist ist es wohl so.
Bei unseren Versuchen konnten wir leider nie ein 10sec fenster sehen - was wäre ja dann einfach.  Wenn ich alle 3 sec sende und der RT ach 3 sec ein 10sec Antwortfenster aufmacht brauch ich garnciht mehr rechnen.
Du kannst gerne ein ACK anfordern. HM hatte sicher einen Grund hier die Msg last zu drosseln. Bei deinem System musst du diesem Trand nicht folgen - deine Entscheidung.

Wenn du also recht hast verstehe ich dein Problem nicht. Timing ist hier nicht wirklich gefragt - 10 s sind selbst für FHEM keine Herusforderung. Da ist nix präzise gefordert. Die 300ms Zeitdifferenz ist dan nicht mehr als lächerlich.

[Linef]

ACK hatte ich nur testweise angefordert. Im Normalbetrieb läuft der Sensor ohne ACK-Anforderung.

Nein, ohne Rechnen geht's nicht. Laut der Formel wartet der RT ja pseudozufällig zwischen 120 und 183 sec nach einer erfolgreichen Telegrammübertragung. Während dieser Zeit ist er nicht empfangsbereit. Anschließend geht er für max. 10 Sek. auf Empfang. Das zu treffen ist kein Problem.

Das Verfahren funktioniert ja auch - der RT bekommt ja über Stunden (auch 1-2 Tage) hinweg jeden Temperaturwert des Sensors mit. Dann aber steigt der RT aus und synchronisiert sich neu (dauert 0,5-3 Std). Das ist mein Problem.
Und das passiert auch, wenn ich einen virtuellen FHEM-Sensor statt meinem Eigenbau nehme...

[sylvester]

Hallo,

kann ich die getconfig Meldung im Logfile unterdrücken?

Viele Grüße

Stephan