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:
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
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.
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?
Zitat von: Wolle02 am 30 September 2018, 16:49:48
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.
Zitat
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.
Alles klar, dann schau ich mal in 2 Jahren, wenn die Batterie leer ist ;-)
Danke erstmal.
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?
Zitat von: martinp876 am 01 Oktober 2018, 19:43:50
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.
Zitat
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).
Zitat
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.