measured-temp Peering Universalsensor HB-UW-Sen-THPL-I mit HM-CC-RT-DN

[tpm88]

Hallo,

ich habe Dirks Universalsensor (Firmware 0.12) mit einem HM-CC-RT-DN (Firmware 1.3) gepeered, um die Ist-Raumtemperatur des THPL an den RT-DN zu geben. Das Reading measured-temp des RT-DN entspricht ja dann der übergebenen Temperatur vom Sensor und nicht mehr dem direkt am RT-DN gemessenen Wert. Das funktioniert auch recht gut - bis auf folgende "Aussetzer":

Siehe Screenshot unten.

In unregelmässigen Abständen scheint der RT-DN plötzlich die übergebenen Temperatur zu vergessen und seine selbst gemessene im Reading measured-temp zurückzugeben. Das sind die Drops bei measured-temp im Graph. Der RT-DN am Heizkörper befindet sich direkt über dem Fußboden und direkt neben der Terrassentür - darum ist der am Thermostat gemessene Wert (bei ausgeschalteter Heizung) stets gut ein Grad niedriger als der Wert vom Universalsensor. Gut zu sehen ist das im Graph auch um 07:30 - da stand die Terrassentür eine Weile offen...

Hier meine Fragen
- Hat jemand schon ähnliches beobachtet?
- Sendet der THPL jeden Temperaturwert (also ca alle 3min) via burst wakeUp an den RT-DN? Oder nur bei Änderungen?

Code Auswählen Erweitern


2014-10-16_10:20:33 wz_Sensor T: 21.3 H: 61 L: 153 P: 949.9 P-NN: 1011.2
2014-10-16_10:23:04 wz_Sensor T: 21.3 H: 61 L: 156 P: 949.8 P-NN: 1011.1
2014-10-16_10:25:20 wz_Sensor T: 21.4 H: 61 L: 159 P: 949.8 P-NN: 1011.1
2014-10-16_10:28:30 wz_Sensor T: 21.4 H: 61 L: 164 P: 949.9 P-NN: 1011.2
2014-10-16_10:31:25 wz_Sensor T: 21.4 H: 61 L: 166 P: 950.0 P-NN: 1011.3
2014-10-16_10:34:04 wz_Sensor T: 21.4 H: 61 L: 173 P: 949.9 P-NN: 1011.2


Code Auswählen Erweitern

2014-10-16_10:20:57 wz_Thermostat_Clima T: 21.3 desired: 18.0 valve: 0
2014-10-16_10:23:54 wz_Thermostat_Clima T: 21.3 desired: 18.0 valve: 0
2014-10-16_10:26:37 wz_Thermostat_Clima T: 21.3 desired: 18.0 valve: 0
2014-10-16_10:29:06 wz_Thermostat_Clima T: 21.3 desired: 18.0 valve: 0
2014-10-16_10:31:20 wz_Thermostat_Clima T: 20.3 desired: 18.0 valve: 0
2014-10-16_10:34:24 wz_Thermostat_Clima T: 21.4 desired: 18.0 valve: 0
2014-10-16_10:37:13 wz_Thermostat_Clima T: 21.4 desired: 18.0 valve: 0


- Wieso liefert der RT-DN um 10:29:06 noch 21.3 Grad zurück, obwohl beim Sensor schon um 10:25:20 die Temperatur auf 21.4Grad gestiegen war?

Häufig - aber nicht immer - sehe ich so einen Drop der measured-temp unmittelbar nach einer Änderung der Temperatur vom Sensor (siehe Zeitstempel 10:29 - 10:34 am RT-DN).

Danke & Gruß
Tobias

PS: Bevor ich den THPL Sensor von Dirk erhalten habe, habe ich einen Peer mit einem virtuellen HM-Sensor (1wire Temperatursensor) als Feed für den RT-DN genutzt. Dort habe ich die Temperatur des virtuellen Sensor alle 5min per at gesetzt. Drops bei der measured-temp des RT-DN habe ich in dem Szenario auch gesehen - allerdings deutlich seltener...

Anhang (HMinfo peerXref, list wz_Sensor, list wz_Thermostat_Clima, list wz_Thermostat_Weather):

Code Auswählen Erweitern


fhem> set hm peerXref

peerXref done:
x-ref list
    wz_Sensor => wz_Thermostat_Weather
    wz_Thermostat_Weather => wz_Sensor

fhem> list wz_Sensor

Internals:
   DEF        EDEA24
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     7275
   NAME       wz_Sensor
   NR         270
   STATE      T: 21.5 H: 61 L: 112 P: 949.5 P-NN: 1010.8
   TYPE       CUL_HM
   hmusb_MSGCNT 7275
   hmusb_RAWMSG EEDEA24,0000,17A21010,FF,FFD2,47A270EDEA2421F22000D73D251700002BD70B68
   hmusb_RSSI -46
   hmusb_TIME 2014-10-16 12:32:46
   lastMsg    No:47 - t:70 s:EDEA24 d:21F220 00D73D251700002BD70B68
   peerList   wz_Thermostat_Weather,
   protCmdDel 1
   protErrIoAttack 1 last_at:2014-10-13 12:51:59
   protLastRcv 2014-10-16 12:32:46
   protResnd  3 last_at:2014-10-13 12:24:48
   protResndFail 1 last_at:2014-10-13 12:24:54
   protSnd    813 last_at:2014-10-13 12:51:58
   protState  CMDs_done
   rssi_at_hmusb avg:-46.69 min:-80 max:-41 lst:-46 cnt:7275
   Readings:
     2014-10-13 12:51:58   Activity        alive
     2014-10-13 12:29:20   CommandAccepted yes
     2014-10-13 12:51:58   D-firmware      0.12
     2014-10-13 12:51:58   D-serialNr      UWS8818132
     2014-10-13 12:29:20   PairedTo        0xF11034
     2014-10-13 12:29:20   R-burstRx       off
     2014-10-13 12:29:20   R-pairCentral   0xF11034
     2014-10-13 12:29:20   RegL_00:          01:00 02:01 0A:F1 0B:10 0C:34 00:00
     2014-10-16 12:32:43   batVoltage      2.92
     2014-10-16 12:32:43   battery         ok
     2014-10-16 12:32:43   humidity        61
     2014-10-16 12:32:43   luminosity      112
     2014-10-13 12:29:20   peerList        wz_Thermostat_Weather,
     2014-10-16 12:32:43   pressure        949.5
     2014-10-16 12:32:43   pressure-nn     1010.8
     2014-10-13 12:51:59   sabotageAttack  ErrIoAttack cnt:1
     2014-10-16 12:32:43   state           T: 21.5 H: 61 L: 112 P: 949.5 P-NN: 1010.8
     2014-10-16 12:32:43   temperature     21.5
   Helper:
     cSnd       01F11034EDEA240103
     mId        F101
     peerIDsRaw ,21F22001,00000000
     rxType     132
     Io:
       newChn     +EDEA24,00,01,00
       nextSend   1413455566.76267
       prefIO     hmusb
       rxt        0
       vccu       vccu
       p:
         EDEA24
         00
         01
         00
     Mrssi:
       mNo        47
       Io:
         hmusb      -44
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmusb:
         avg        -46.6971821305843
         cnt        7275
         lst        -46
         max        -41
         min        -80
Attributes:
   IODev      hmusb
   IOgrp      vccu:hmusb
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   event-on-change-reading battery
   event-on-update-reading ^((?!battery).)*$
   expert     2_full
   firmware   0.12
   model      HB-UW-Sen-THPL-I
   peerIDs    00000000,21F22001,
   room       WoZi
   serialNr   UWS8818132
   subType    THPLSensor

fhem> list wz_Thermostat_Clima

Internals:
   DEF        21F22004
   NAME       wz_Thermostat_Clima
   NR         223
   STATE      T: 21.6 desired: 18.0 valve: 0
   TYPE       CUL_HM
   chanNo     04
   device     wz_Thermostat
   Readings:
     2014-10-15 22:09:04   CommandAccepted yes
     2014-07-08 20:28:37   R-boostPeriod   5 min
     2014-07-08 20:28:37   R-boostPos      80 %
     2014-10-13 12:09:17   R-btnNoBckLight off
     2014-07-08 20:28:37   R-dayTemp       21 C
     2014-10-13 12:09:17   R-daylightSaveTime on
     2014-10-13 12:09:17   R-decalcTime    11:00
     2014-10-13 12:09:17   R-decalcWeekday Sat
     2014-10-13 12:09:17   R-modePrioManu  all
     2014-10-13 12:09:17   R-modePrioParty all
     2014-07-08 20:28:37   R-nightTemp     17 C
     2014-10-13 12:09:17   R-noMinMax4Manu off
     2014-10-13 12:09:17   R-regAdaptive   on
     2014-10-13 12:09:17   R-reguExtI      18
     2014-10-13 12:09:17   R-reguExtP      33
     2014-10-13 12:09:17   R-reguExtPstart 45
     2014-10-13 12:09:17   R-reguIntI      18
     2014-10-13 12:09:17   R-reguIntP      33
     2014-10-13 12:09:17   R-reguIntPstart 43
     2014-10-13 12:09:17   R-showInfo      time
     2014-10-13 12:09:17   R-showWeekday   off
     2014-10-13 12:09:13   R-sign          off
     2014-07-08 20:28:37   R-tempMax       30.5 C
     2014-07-08 20:28:37   R-tempMin       4.5 C
     2014-10-13 12:09:17   R-tempOffset    0.0K
     2014-07-08 20:28:37   R-valveErrPos   15 %
     2014-07-08 20:28:37   R-valveMaxPos   100 %
     2014-07-08 20:28:37   R-valveOffsetRt 0 %
     2014-10-13 12:09:17   R-winOpnBoost   off
     2014-07-08 20:28:37   R-winOpnDetFall 1.4 K
     2014-10-13 12:09:17   R-winOpnMode    on
     2014-07-08 20:28:37   R-winOpnPeriod  15 min
     2014-07-08 20:28:37   R-winOpnTemp    12 C
     2014-10-15 21:29:45   R_0_tempListSat  08:00 18.0 10:00 21.0 18:00 18.0 22:30 21.0 24:00 18.0
     2014-10-15 21:29:45   R_1_tempListSun  08:00 18.0 10:00 21.0 18:00 18.0 22:00 21.0 24:00 18.0
     2014-10-15 21:29:45   R_2_tempListMon  06:00 18.0 07:30 20.0 18:00 18.0 22:00 21.0 24:00 18.0
     2014-10-15 21:29:45   R_3_tempListTue  06:00 18.0 07:30 20.0 18:00 18.0 22:00 21.0 24:00 18.0
     2014-10-15 21:29:45   R_4_tempListWed  06:00 18.0 07:30 20.0 18:00 18.0 22:00 21.0 24:00 18.0
     2014-10-15 21:29:45   R_5_tempListThu  06:00 18.0 07:30 20.0 18:00 18.0 22:00 21.0 24:00 18.0
     2014-10-15 21:29:45   R_6_tempListFri  06:00 18.0 07:30 20.0 18:00 18.0 22:30 21.0 24:00 18.0
     2014-10-15 21:29:45   R_tempList_State verified
     2014-10-16 12:33:32   ValvePosition   0
     2014-10-16 12:33:32   boostTime       -
     2014-10-16 12:33:32   controlMode     auto
     2014-10-16 12:33:32   desired-temp    18.0
     2014-10-16 12:33:32   measured-temp   21.6
     2014-10-16 12:33:32   motorErr        ok
     2014-10-16 12:33:32   partyEnd        -
     2014-10-16 12:33:32   partyStart      -
     2014-10-16 12:33:32   partyTemp       -
     2014-10-15 22:09:04   recentStateType ack
     2014-10-16 12:33:32   state           T: 21.6 desired: 18.0 valve: 0
   Helper:
     peerIDsRaw ,00000000
     Prt:
       brstWu     1
     Role:
       chn        1
     Shregr:
       07         00
     Shadowreg:
Attributes:
   event-on-change-reading desired-temp,measured-temp,mode,motorErr,ValvePosition,partyEnd,partyStart,partyTemp
   event-on-update-reading state
   expert     1_on
   group      WZ_Thermostat
   model      HM-CC-RT-DN
   peerIDs    00000000,
   room       WoZi

fhem> list wz_Thermostat_Weather

Internals:
   DEF        21F22001
   NAME       wz_Thermostat_Weather
   NR         220
   STATE      21.6
   TYPE       CUL_HM
   chanNo     01
   device     wz_Thermostat
   peerList   wz_Sensor,
   Readings:
     2014-10-13 12:09:10   R-sign          off
     2014-10-15 21:29:39   RegL_01:          08:00 00:00
     2014-10-16 12:33:32   measured-temp   21.6
     2014-10-15 21:29:39   peerList        wz_Sensor,
     2014-10-16 12:33:32   state           21.6
   Helper:
     peerIDsRaw ,EDEA2401,00000000
     Role:
       chn        1
     Shadowreg:
Attributes:
   expert     2_full
   model      HM-CC-RT-DN
   peerIDs    00000000,EDEA2401,
   room       hidden



Edit: Typos

[Dirk]

Hi Tobias,

- Hat jemand schon ähnliches beobachtet?

Ja, Thorsten hat ein ähnliches Verhalten berichtet.
Wir sind da an der Analyse. Daher ist es nicht schlecht wenn noch jemand solche Beobachtung gemacht hat.
Aktuell habe ich die Berechnung des nächsten Sendezeitpunktes in Verdacht.
Wegen fehlendem RT bei mir bin ich bei der Lösung da auf etwas mithilfe angewiesen.

- Sendet der THPL jeden Temperaturwert (also ca alle 3min) via burst wakeUp an den RT-DN? Oder nur bei Änderungen?

Der Sensor sendet ca. alle 2-3 Min. Aber keinen Burst, sondern genau im Zeitraster wenn ein gepeerter RT aufwacht.
Das tut dieser auch alle 2-3 min.

Gruß
Dirk

[tpm88]

Wir sind da an der Analyse. Daher ist es nicht schlecht wenn noch jemand solche Beobachtung gemacht hat.
Aktuell habe ich die Berechnung des nächsten Sendezeitpunktes in Verdacht.
Wegen fehlendem RT bei mir bin ich bei der Lösung da auf etwas mithilfe angewiesen.

Werde ich gern nach Kräften unterstützen. Notfalls schicke ich dir einen RT... 

Der Sensor sendet ca. alle 2-3 Min. Aber keinen Burst, sondern genau im Zeitraster wenn ein gepeerter RT aufwacht.
Das tut dieser auch alle 2-3 min.

Ok - das würde auch erklären, warum der RT Änderungen manchmal erst etwas später mitbekommt - dann nämlich, wenn das Zeitraster gerade wieder einmal passt??

Gruß
Tobias

[Dirk]

Werde ich gern nach Kräften unterstützen. Notfalls schicke ich dir einen RT... 

Wenn du einen RT für ein paar Wochen "übrig" hast / entbehren kannst, währ das Klasse. Da kann ich deutlich besser debugen.

Gruß
Dirk

[tpm88]

Wenn du einen RT für ein paar Wochen "übrig" hast / entbehren kannst, währ das Klasse. Da kann ich deutlich besser debugen.

ist unterwegs...

Gruß
Tobias

[martinp876]

Die Kommunikation zwischen TC-IT und RT ist nicht auf burst bassierend sondern auf timing. Das ist kompliziert (etwas zumindest). Wir hatten dies bei der Kommunikation zwischen TC und VD.

Der TC sendet zu bestimmten Zeiten in denen der RT wach ist. Diese Zeiten sind nciht stabil sondern ein RT muss diese errechnen aus der messagenummer und der ID.
Der Sensor muss sich genau an diese Zeit halten - und den Termin zum nächsten Senden errechnen.

Verliert der RT die Synchronisation zum TC wird er sicher die eigenen Werte wieder senden - ausserdem wird er sein zeitfenster vergrößern, in dem er wach ist. Damit wird er irgendwann wieder synchron. kostet nebenbei Batterie.

Wichtig ist also, dass ein tempsensor genau in den Abständen sendet, welche er nach dem Algorythmus errechnet hat.