Problem mit HM-CC-RT-DN und externem Temperatursensor

Begonnen von vbs, 24 Januar 2017, 12:18:36

Vorheriges Thema - Nächstes Thema

vbs

Hi Ihrs!

ich habe im Bad einen neuen HM-CC-RT-DN (ARR-Bausatz) ohne den Wandthermostat. Zusätzlich habe ich jedoch ein Oregon Scientific THGR 228N Thermometer welches ich auch gerne als Quelle für die Ist-Temperatur des HM-CC-RT-DN nutzen würde.

Ich habe dafür wie im Wiki beschrieben (https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat) ein virtuelles Device mit einem Kanal angelegt und diesen Kanal mit dem Weather-Kanal des HM-CC-RT-DN gepeert. Das sieht in hminfo auch erstmal gut aus:
peerXref done:
x-ref list
    bd_hmRtWeather => bd_hmVirtualWeather
    bd_hmVirtualWeather => bd_hmRtWeather


Jetzt sind mir zwei Sachen aufgefallen, die ich für einen Fehler halte:
1. Im virtuellen Wetter-Kanal wird die externe Temperatur korrekt angezeigt, aber sie wird offenbar nicht immer korrekt zum HM-CC-RT-DN weiter gereicht. Die beiden Werte haben normalerweise so ca. 2 K Abweichungen und im Webinterface sieht man oft (nicht immer!), dass die Werte unterschiedlich sind. Sprich: der RT zeigt offenbar oft seinen internen Wert an. Ich würde erwarten, dass sowohl das RT-Device als auch sein Weather-Kanal und auch der virtuelle Weather-Kanal immer die gleich Ist-Temperatur anzeigen, wenn sie gepeert sind?
2. Mir ist aufgefallen, dass im Display des RT das Antennensymbol am Blinken ist. Deutet ja vermtl. auf ein Kommunikationsproblem hin.

Ich würde jetzt mal mutmaßen, dass das Blinken des Antennensymbols nicht auf ein Problem mit der Kommunikation zu FHEM zurückzuführen ist. Ich kann aus FHEM heraus wunderbar Register und co. abfragen und auch desired-temp setzen. Ich denke, dass das RT der Meinung ist, Probleme mit der Kommunikation zu dem Weather-Peer zu haben, der ja virtuell ist.
Das würde dann auch erklären, dass der virtuelle Weather-Peer und der RT im Webinterface unterschiedliche Ist-Temperaturen anzeigen. Offenbar wird der Wert des virtuellen Devices nicht korrekt dem RT übergeben.
Macht das Sinn? Und wenn ja, was kann man da machen? Danke euch!

Hier noch die Listings:
Internals:
   DEF        F16789
   IODev      HMLAN0
   NAME       bd_hmVirtual
   NOTIFYDEV  global
   NR         554
   NTFY_ORDER 50-bd_hmVirtual
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 bd_hmVirtualWeather
   protSnd    348 last_at:2017-01-24 12:12:33
   protState  CMDs_done
   Readings:
     2017-01-24 12:12:33   state           CMDs_done
   Helper:
     HM_CMDNR   1
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       prefIO
       vccu
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       vrt        1
     Tmpl:
Attributes:
   IODev      HMLAN0
   expert     2_raw
   model      virtual_1
   msgRepeat  0
   room       Bad
   subType    virtual
   webCmd     virtual

Internals:
   DEF        F1678901
   NAME       bd_hmVirtualWeather
   NOTIFYDEV  global
   NR         558
   NTFY_ORDER 50-bd_hmVirtualWeather
   STATE      set_virtTemp 22.3
   TYPE       CUL_HM
   chanNo     01
   device     bd_hmVirtual
   peerList   bd_hmRtWeather,
   Readings:
     2017-01-23 23:25:28   peerList        bd_hmRtWeather,
     2017-01-24 12:01:05   state           set_virtTemp 22.3
     2017-01-24 12:01:05   temperature     22.3
   Helper:
     fkt        virtThSens
     virtTC     00
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
       vrt        1
     Tmpl:
     Vd:
       cmd        8670F16789000000
       idh        2067931
       idl        35072
       msgCnt     92
       msgRed     0
       next       1485256479.28203
       nextM      1485256479.28203
       typ        2
       val        00DF
       vin        22.3
Attributes:
   model      virtual_1
   peerIDs    519F9601,
   room       Bad
   verbose    0
   webCmd     press short:press long


Hm-RT:
Internals:
   CHANGED
   DEF        519F96
   HMLAN0_MSGCNT 513
   HMLAN0_RAWMSG E519F96,0000,56E73296,FF,FFCA,358610519F960000000A78CD0B0040
   HMLAN0_RSSI -54
   HMLAN0_TIME 2017-01-24 12:12:18
   IODev      HMLAN0
   LASTInputDev HMLAN0
   MSGCNT     513
   NAME       bd_hmRt
   NOTIFYDEV  global
   NR         547
   NTFY_ORDER 50-bd_hmRt
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 bd_hmRtWeather
   channel_02 bd_hmRtClimate
   channel_03 bd_hmRtWindowRec
   channel_04 bd_hmRtClima
   channel_05 bd_hmRtClimaTeam
   channel_06 bd_hmRtRemote
   lastMsg    No:35 - t:10 s:519F96 d:000000 0A78CD0B0040
   protCmdDel 3
   protCondBurst on
   protLastRcv 2017-01-24 12:12:18
   protNack   1 last_at:2017-01-23 23:24:58
   protResnd  1 last_at:2017-01-23 23:14:42
   protSnd    149 last_at:2017-01-24 09:04:50
   protState  CMDs_done
   rssi_HMLAN0 cnt:20 max:-54 min:-56 lst:-54 avg:-55.15
   rssi_at_HMLAN0 avg:-56.44 lst:-54 cnt:513 min:-63 max:-52
   Helper:
     Dblog:
       Actuator:
         Bendblog:
           TIME       1485243546.15745
           VALUE      0
       Desired-temp:
         Bendblog:
           TIME       1485245029.65872
           VALUE      15.0
   Readings:
     2017-01-23 23:21:36   Activity        alive
     2017-01-24 09:04:45   CommandAccepted yes
     2017-01-23 23:21:36   D-firmware      1.4
     2017-01-23 23:21:36   D-serialNr      NEQ1491381
     2017-01-24 09:04:01   PairedTo        0xF15544
     2017-01-23 23:22:10   R-backOnTime    10 s
     2017-01-24 08:19:31   R-btnLock       off
     2017-01-23 23:22:10   R-burstRx       on
     2017-01-23 23:22:10   R-cyclicInfoMsg on
     2017-01-23 23:22:10   R-cyclicInfoMsgDis 0
     2017-01-23 23:22:10   R-globalBtnLock off
     2017-01-23 23:22:10   R-localResDis   off
     2017-01-23 23:22:10   R-lowBatLimitRT 2.1 V
     2017-01-23 23:22:10   R-modusBtnLock  off
     2017-01-23 23:22:10   R-pairCentral   0xF15544
     2017-01-24 12:12:18   actuator        0
     2017-01-24 12:12:18   battery         ok
     2017-01-24 12:12:18   batteryLevel    2.6
     2017-01-24 12:12:18   desired-temp    15.0
     2017-01-24 12:12:18   measured-temp   20.5
     2017-01-24 12:12:18   motorErr        ok
     2017-01-23 23:14:47   powerOn         2017-01-23 23:14:47
     2017-01-23 23:14:47   recentStateType info
     2017-01-24 09:04:50   state           CMDs_done
     2017-01-23 23:22:07   time-request    -
   Helper:
     HM_CMDNR   53
     PONtest    0
     cSnd       01F15544519F960603,01F15544519F9606040000000001
     mId        0095
     rxType     140
     supp_Pair_Rep 0
     Expert:
       def        1
       det        1
       raw        0
       tpl        0
     Io:
       newChn     +519F96,00,00,00
       nextSend   1485256338.38069
       rxt        2
       vccu       VCCU
       p:
         519F96
         00
         00
         00
       prefIO:
         HMLAN0
     Mrssi:
       mNo        35
       Io:
         HMLAN0     -52
     Prt:
       awake      0
       bErr       0
       brstWu     1
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       prs        1
     Rssi:
       Hmlan0:
         avg        -55.15
         cnt        20
         lst        -54
         max        -54
         min        -56
       At_hmlan0:
         avg        -56.4463937621832
         cnt        513
         lst        -54
         max        -52
         min        -63
     Shregw:
       07         04
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLAN0
   IOgrp      VCCU:HMLAN0
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   burstAccess 1_auto
   event-min-interval actuator:86400
   event-on-change-reading (battery|actuator|desired-temp)
   expert     1_allReg
   firmware   1.4
   group      System
   model      HM-CC-RT-DN
   room       Bad
   serialNr   NEQ1491381
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit

Internals:
   CHANGED
   DEF        519F9601
   NAME       bd_hmRtWeather
   NOTIFYDEV  global
   NR         548
   NTFY_ORDER 50-bd_hmRtWeather
   STATE      20.5
   TYPE       CUL_HM
   chanNo     01
   device     bd_hmRt
   peerList   bd_hmVirtualWeather,
   Readings:
     2017-01-21 01:41:30   R-sign          off
     2017-01-24 12:15:03   measured-temp   20.5
     2017-01-24 09:04:01   peerList        bd_hmVirtualWeather,
     2017-01-24 12:15:03   state           20.5
   Helper:
     peerIDsRaw ,F1678901,00000000
     Expert:
       def        1
       det        1
       raw        0
       tpl        0
     Role:
       chn        1
     Shadowreg:
     Tmpl:
Attributes:
   event-on-update-reading 1
   model      HM-CC-RT-DN
   peerIDs    00000000,F1678901,
   room       Bad

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

vbs

#2
Ok, danke, mach ich. Scheint auf jeden Fall exakt auf mein Problem zu passen!

Hat sich jetzt überschnitten, aber ich hab mal versucht zu loggen, wie es aussieht, wenn ich die Temperatur im (virtuellen) Temperaturgeber ändere. Auffällig (vermutlich aber unabhängig von meinem Problem) fand ich, dass es 52 Sekunden dauert von der Änderungen der Temperatur (12:52:39) bis dann das Kommando in der Send-Queue landet (12:53:31). Daraufhin wird es aber zumindest sofort versendet.


2017-01-24 12:52:39 CUL_HM bd_hmVirtualWeather temperature: 8.0
2017.01.24 12:52:43 0 : HMLAN_Parse: HMLAN0 R:E0B69DC stat:0000 t:570C35B5 d:FF r:FFB2 m:80 A270 0B69DC F15544 00115A27C300042EF10A28
2017.01.24 12:52:49 0 : HMLAN_Send: HMLAN0 I:K
2017.01.24 12:52:49 0 : HMLAN_Parse: HMLAN0 V:03C7 sNo:LEQ0659500 d:2CC53A O:F15544 t:570C4CEE IDcnt:001F L:5 %
2017.01.24 12:53:14 0 : HMLAN_Send: HMLAN0 I:K
2017.01.24 12:53:14 0 : HMLAN_Parse: HMLAN0 V:03C7 sNo:LEQ0659500 d:2CC53A O:F15544 t:570CAE6E IDcnt:001F L:5 %
2017.01.24 12:53:17 0 : HMLAN_Parse: HMLAN0 R:E261725 stat:0000 t:570CB786 d:FF r:FFC4 m:5A 865A 261725 000000 68BF1E
2017-01-24 12:53:31 CUL_HM bd_hmVirtual CMDs_pending
2017.01.24 12:53:31 0 : HMLAN_Send:  HMLAN0 S:+000000,00,00,002017.01.24 12:53:31 0 : HMLAN_Send:  HMLAN0 S:SD052EA09 stat:  00 t:00000000 d:01 r:D052EA09 m:6C 8670 F16789 000000 00502017-01-24 12:53:31 CUL_HM bd_hmVirtual CMDs_done
2017.01.24 12:53:31 0 : HMLAN_Parse: HMLAN0 R:RD052EA09 stat:0002 t:00000000 d:FF r:7FFF m:6C 8670 F16789 000000 0050
2017.01.24 12:53:33 0 : HMLAN_Parse: HMLAN0 R:E3BD485 stat:0000 t:570CF78C d:FF r:FFCC m:DB 8653 3BD485 000000 0001FF18000005

martinp876

Logisch dauert es so lange. Es wird eingehalten. Kann auch länger dauern. Es sollte alle 3min eingehalten werden.

vbs

Ok, umso besser. Aber so richtig einleuchten tut mir ehrlich gesagt noch nicht, warum Änderungen von desired-temp sofort per Burst versendet werden, aber Änderungen von measured-temp nur alle 3 min im Homematic-Raster versendet werden können.

Linef

Zitat von: vbs am 24 Januar 2017, 21:52:07
Ok, umso besser. Aber so richtig einleuchten tut mir ehrlich gesagt noch nicht, warum Änderungen von desired-temp sofort per Burst versendet werden, aber Änderungen von measured-temp nur alle 3 min im Homematic-Raster versendet werden können.

Bei seltenen Config-Änderungen kann man es sich leisten, per Burst zu versenden (Burst weckt alle (!) Devices auf, was einen erhöhten Batterieverbrauch nach sich zieht). Bei regelmäßigen 3-Min-Sendungen macht man das deshalb nicht.

Martin
fhem auf cubietruck, HM-USB-CFG-2, CUL-V3, 6x HM-CC-RT-DN, 5x HM-SEC-SD, 2x HM-SEC-SCo, 5x HM Eigenbausensoren, AVR-Heizungsgateway