HMCCUDEV LOWBAT wird nicht aktualisiert

[Wolle02]

Hallo zusammen,

ich habe per HMCCUDEV einen Außenthermostat (HM-WDS10-TH-O) eingebunden. Grundsätzlich funktioniert alles; nur leider wird mein battery-Reading nicht aktualisiert; lediglich nach einem "get <device> update" wird das Reading aktualisert. Die Readings "temperature" und "humidity" werden brav regelmäßig aktualisiert.
Das I/O-device MyCCU3 ist angelegt und der RPC-Server für BidCos-RF läuft.

Hier sind mal ein paar Lists:

Außentemperatursenor:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        TH_Sensor_aussen
   IODev      MyCCU3
   NAME       TH_Sensor_aussen
   NR         84824
   STATE      T:22.3° H:48%
   TYPE       HMCCUDEV
   ccuaddr    JEQ0016279
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    TH_Sensor_aussen
   ccutype    HM-WDS10-TH-O
   channels   2
   firmware   1.2
   statevals  devstate
   OLDREADINGS:
   READINGS:
     2018-09-25 14:21:27   battery         ok
     2018-09-27 14:36:01   humidity        48
     2018-09-27 14:36:01   humidity_avg_day 75.0
     2018-09-27 14:36:01   humidity_avg_month 63.2
     2018-09-27 14:36:01   humidity_cum_day 3943404
     2018-09-27 14:36:01   humidity_cum_month 150697303
     2018-09-27 07:01:45   humidity_max_day 85.0
     2018-09-25 09:16:51   humidity_max_month 89.0
     2018-09-27 14:33:42   humidity_min_day 47.0
     2018-09-26 15:33:24   humidity_min_month 38.0
     2018-09-27 14:36:01   temperature     22.3
     2018-09-27 14:36:01   temperature_avg_day 10.3
     2018-09-27 14:36:01   temperature_avg_month 22.2
     2018-09-27 14:36:01   temperature_cum_day 543872.1
     2018-09-27 14:36:01   temperature_cum_month 52933507.6
     2018-09-27 14:28:21   temperature_max_day 22.3
     2018-09-23 15:29:14   temperature_max_month 24.4
     2018-09-27 06:31:27   temperature_min_day 5.8
     2018-09-26 07:21:19   temperature_min_month 1.8
   hmccu:
     devspec    TH_Sensor_aussen
     dp:
       0.CONFIG_PENDING:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       0.LOWBAT:
         OSVAL      ok
         OVAL       false
         SVAL       ok
         VAL        false
       0.RSSI_DEVICE:
         OSVAL      1
         OVAL       1
         SVAL       1
         VAL        1
       0.RSSI_PEER:
         OSVAL      190
         OVAL       190
         SVAL       190
         VAL        190
       0.STICKY_UNREACH:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       0.UNREACH:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       1.HUMIDITY:
         OSVAL      47
         OVAL       47
         SVAL       48
         VAL        48
       1.TEMPERATURE:
         OSVAL      22.3
         OVAL       22.300000
         SVAL       22.3
         VAL        22.300000
   powerMap:
   readingsDesc:
     pM_consumption:
       rtype      w
     pM_energy:
       rtype      whr
Attributes:
   IODev      MyCCU3
   alexaName  freien
   alias      Außentemperatur/-luftfeuchte
   ccureadingfilter (^LOWBAT|^HUMIDITY|^TEMPERATURE)
   ccureadingname ^(.+\.)?LOW_?BAT$:battery;1.TEMPERATURE:temperature;1.HUMIDITY:humidity
   genericDeviceType thermometer
   group      Wetterübersicht
   powerMap_noEnergy 1
   room       Wetter,Wohnung,alexa
   stateFormat T:temperature° H:humidity%
   stripnumber 1
   substitute LOWBAT!(0|false):ok,(1|true):low

Das List von I/O Device ist zu lang. Kann ich hier nicht posten.

Fehlermeldungen im FHEM-Log habe ich keine gesehen.

Über die Suchfunktion habe ich mehrere Threads von Leuten gefunden, die das gleiche/ähnliche Problem haben. Leider habe ich eine Lösung nirgends gesehen.

Habe ich etwas falsch eingestellt? Diverse Neustarts von FHEM, CCU3 und RPC-Server habe ich bereits erfolglos ausprobiert.

Gruß
Wolle

[zap]

Hat sich denn der Batterie-Status geändert (von OK zu low/leer)? Falls nicht, warum sollte die CCU den aktualisieren, wenn er wie bisher "OK" ist?

Und selbst wenn die CCU eine Aktualisierung wieder mit dem gleichen Wert schickt, wirst Du ihn nur mitbekommen, wenn Du event-on-update-reading entsprechend setzt.

[Wolle02]

Nein, der Status hat sich nicht geändert, aber genau das war meine beabsichtigte Frage. Sorry wenn es mal wieder etwas umständlich rüber kam.
Wird denn nur im Channel 0 der Wert bei einer Änderung übertragen? Ich frage deshalb, weil ich noch einen optischen Tür-Fenstersensor (HM-Sec_SCo) eingebunden habe. Dieser hat die Datenpunkte LOWBAT sowohl im Channel 0 als auch im Channel 1. Im Channel 1 wird LOWBAT bei jeden öffnen und schließen mitübertragen; im Channel 0 nicht. Ist das so gewollt?

Ich habe dich aber schon richtig verstanden, dass auch im Channel 0 ein Update erfolgt, wenn sich der Status tatsächlich auf low ändert?

[zap]

Wird denn nur im Channel 0 der Wert bei einer Änderung übertragen? Ich frage deshalb, weil ich noch einen optischen Tür-Fenstersensor (HM-Sec_SCo) eingebunden habe. Dieser hat die Datenpunkte LOWBAT sowohl im Channel 0 als auch im Channel 1. Im Channel 1 wird LOWBAT bei jeden öffnen und schließen mitübertragen; im Channel 0 nicht. Ist das so gewollt?

Die Frage musst Du dem Hersteller EQ-3 stellen. HMCCU empfängt nur die Ereignisse der CCU. Jedenfalls funktioniert bei mir die Benachrichtigung im Kanal 0, wenn sich der Batteriestatus ändert. Ggf. wird dann auch UNREACH = true.

Ich habe dich aber schon richtig verstanden, dass auch im Channel 0 ein Update erfolgt, wenn sich der Status tatsächlich auf low ändert?

Ja.

[Wolle02]

Alles klar, dann schau ich mal in 2 Jahren, wenn die Batterie leer ist

Danke erstmal.

[martinp876]

Der batteriestatus wird vom device zur ccu sicher wie bei den nicht-ip auch in einigen kanalbezogenen messages übertragen. In der ccu wird er dann natürlich dem kanal 0 zugewiesen ( das device in meiner nomenklatur). Alles andere macht keinen sinn.

Was mir nun in der fhem-ccu kommunikaton unklar ist, ist der updatemechanismus. Event-on-change ist m.E. ein muss. Ein upgedateter batStatus mit gleichem wert darf keinen trigger (event) erzeugen. Allerdings ist das reading zu aktualisieren. Ich muss am zeitstempel sehen, wann die letzte meldung kam und damit wie alt die info ist.
Weiter ist mir unklar, was nach einem neustart von fhem passiert.   Fhem könnte asynchron zur  ccu werden. Wann werden die werte aktualisiert? Bei neustart? Bei änderung - ist klar. Bei update? Auf Anfrage: kann ich also eine synchronisation ( erneutes lesen aller werte) erzwingen?

[zap]

Der batteriestatus wird vom device zur ccu sicher wie bei den nicht-ip auch in einigen kanalbezogenen messages übertragen. In der ccu wird er dann natürlich dem kanal 0 zugewiesen ( das device in meiner nomenklatur). Alles andere macht keinen sinn.

Ist so wie du schreibst. Einige Devices haben zusätzlich noch ein LOWBAT in einem anderen Kanal. Kommt aber selten vor.

Was mir nun in der fhem-ccu kommunikaton unklar ist, ist der updatemechanismus. Event-on-change ist m.E. ein muss. Ein upgedateter batStatus mit gleichem wert darf keinen trigger (event) erzeugen. Allerdings ist das reading zu aktualisieren. Ich muss am zeitstempel sehen, wann die letzte meldung kam und damit wie alt die info ist.

HMCCU aktualisiert die Readings, sobald die CCU ein Event schickt. Dazu werden die Standard FHEM ReadingUpdates verwendet. Die Attribute event-on-... werden also berücksichtigt. Meine Vermutung: Die CCU schickt ein Event für LOWBAT nur, wenn sich der Status ändert (oder vielleicht noch beim Neustart).

Weiter ist mir unklar, was nach einem neustart von fhem passiert.   Fhem könnte asynchron zur  ccu werden. Wann werden die werte aktualisiert? Bei neustart? Bei änderung - ist klar. Bei update? Auf Anfrage: kann ich also eine synchronisation ( erneutes lesen aller werte) erzwingen?

Beim Start von FHEM (genauer beim Start der HMCCU RPC Server) wird ein "get update" auf alle in FHEM definierten CCU Devices ausgeführt. Dadurch haben alle Devices den gleichen Stand wie in der CCU. Dabei wird die Homematic Script Methode Value() verwendet. Bedeutet: Die CCU liefert die Werte, die sie im Speicher hat. Außer Value() wird noch die Methode State() angeboten (kann per Attribut in HMCCU aktiviert werden). State() zwingt die CCU dazu, die Werte direkt beim jeweiligen Gerät abzufragen. Das ist für einzelne Geräte ok, für ein Update aller Geräte-Werte aber zu zeitintensiv.