Guten Tag zusammen,
in allen meinen batteriebetriebenen HMCCU-Komponenten existiert das Reading "battery" (und weitere), welches aber in allen Komponenten nicht mehr automatisch aufgefrischt geupdated wird.
EDIT: Sprich, es werden nur Änderungen des Readings von ok auf low und umgekehrt gemeldet. Ist das so gewollt von HMCCU?
Ich habe bisher nichts gefunden, was das verhindern könnte. Bisher sollte das Reading zyklisch ca. alle 3 Minuten (je nach Gerät) mitgeliefert werden.
Hat irgendjemand einen Tipp? Vermute, dass ich da etwas Grundsätzliches nicht begriffen habe.
Gruß,
Friedhelm
Hier ein Beispielgerät:
Internals:
DEF XXXX:1
FUUID 61ee7160-f33f-26cd-057e-fc2590c308b3dfc1
IODev d_ccu
NAME PIRA1
NR 1161
STATE motion
TYPE HMCCUCHN
ccuaddr XXXX:1
ccudevstate active
ccuif BidCos-RF
ccuname PIRA1:1
ccurolestate MOTION_DETECTOR
ccusubtype HM-Sen-MDIR-O
ccutype HM-Sen-MDIR-O
chntype ?
firmware 1.5
readonly no
READINGS:
2022-02-18 18:40:19 AES_KEY off
2022-02-18 18:40:19 CONFIG_PENDING false
2022-02-19 11:01:37 INSTALL_TEST 1
2022-02-19 10:40:29 IODev d_ccu
2022-02-18 18:40:19 LOWBAT ok
2022-02-18 18:40:19 NEXT_TRANSMISSION 281
2022-02-18 18:40:19 R-AES_ACTIVE 0
2022-02-18 18:40:19 R-BRIGHTNESS_FILTER 7
2022-02-18 18:40:19 R-CAPTURE_WITHIN_INTERVAL 0
2022-02-18 18:40:19 R-EVENT_FILTER_NUMBER 1
2022-02-18 18:40:19 R-EVENT_FILTER_PERIOD 1.0
2022-02-18 18:40:19 R-LED_ONTIME 0.0
2022-02-18 18:40:19 R-MIN_INTERVAL 4
2022-02-18 18:40:19 RSSI_DEVICE N/A
2022-02-18 18:40:19 RSSI_PEER -92
2022-02-18 18:40:19 STICKY_UNREACH false
2022-02-18 18:40:19 UNREACH alive
2022-02-18 18:40:19 activity alive
2022-02-18 18:40:19 battery ok
2022-02-19 11:01:37 brightness 182
2022-02-19 11:01:37 devstate ok
2022-02-19 11:01:37 hmstate motion
2022-02-19 11:01:37 motion motion
2022-02-18 18:40:19 rssidevice N/A
2022-02-18 18:40:19 rssipeer -92
2022-02-18 18:40:19 sign off
2022-02-19 11:01:37 state motion
hmccu:
channels 1
detect 1
devspec XXXX:1
nodefaults 1
role 1:MOTION_DETECTOR
setDefaults 0
cmdlist:
get
set
control:
dp:
1.BRIGHTNESS:
VALUES:
NVAL 182
ONVAL 182
OSVAL 182
OVAL 182
SVAL 182
VAL 182
1.INSTALL_TEST:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
1.MOTION:
VALUES:
NVAL 1
ONVAL 1
OSVAL motion
OVAL 1
SVAL motion
VAL 1
roleCmds:
get:
set:
state:
chn 1
dpt MOTION
Attributes:
alias PIRA1 (Terrasse)
ccuflags showMasterReadings,showDeviceReadings
devStateIcon motion:people_sensor noMotion:message_presence
event-on-change-reading state
event-on-update-reading battery.*
group motionDetector
Hat hier keiner einen Tipp für mich? Es muss etwas ganz "Einfaches" sein.
Die Readings battery und LOWBAT werden nur bei FHEM-Neustarts aufgefrischt, wahrscheinlich auch bei Änderungen, aber das reicht nicht für eine sichere Batterieüberwachung.
Hier als weiteres Gerät:
Internals:
DEF MEQ0089257:2
FUUID 61ea74cc-f33f-26cd-f28a-b7cd0df0a9c51c60
IODev d_ccu
NAME Wohnzimmerthermostat
NR 1110
STATE Ist: 21.4 °C AUTO
TYPE HMCCUCHN
ccuaddr MEQ0089257:2
ccudevstate active
ccuif BidCos-RF
ccuname HM-TC-IT-WM-W-EU MEQ0089257:2
ccurolectrl THERMALCONTROL_TRANSMIT
ccurolestate THERMALCONTROL_TRANSMIT
ccusubtype HM-TC-IT-WM-W-EU
ccutype HM-TC-IT-WM-W-EU
firmware 1.4
readonly no
receiver ccu:HT_Wohnzimmer_mitte,ccu:HT_Kueche,ccu:HT_Wohnzimmer_links,ccu:HT_Wohnzimmer_rechts
sender Melder_Wohnzimmer_rechts,Melder_Kueche_Fenster,Melder_Kueche_Tuer,Melder_Wohnzimmer_links
READINGS:
2022-04-02 09:13:39 ACTUAL_HUMIDITY 57.0
2022-04-02 09:13:39 ACTUAL_TEMPERATURE 21.4
2022-04-01 17:06:22 AES_KEY off
2022-04-02 09:06:00 BATTERY_STATE 2.7
2022-04-02 09:06:00 BOOST_STATE 0
2022-04-02 09:06:00 COMMUNICATION_REPORTING false
2022-04-01 17:06:22 CONFIG_PENDING false
2022-04-02 09:06:00 CONTROL_MODE AUTO
2022-04-01 17:06:22 DEVICE_IN_BOOTLOADER false
2022-04-01 17:06:22 INHIBIT false
2022-03-29 22:19:19 IODev d_ccu
2022-04-01 17:06:22 LOWBAT ok
2022-04-02 09:06:00 LOWBAT_REPORTING false
2022-04-02 09:06:00 PARTY_START_DAY 1
2022-04-02 09:06:00 PARTY_START_MONTH 1
2022-04-02 09:06:00 PARTY_START_TIME 00:00
2022-04-02 09:06:00 PARTY_START_YEAR 0
2022-04-02 09:06:00 PARTY_STOP_DAY 1
2022-04-02 09:06:00 PARTY_STOP_MONTH 1
2022-04-02 09:06:00 PARTY_STOP_TIME 00:00
2022-04-02 09:06:00 PARTY_STOP_YEAR 0
2022-04-02 09:06:00 PARTY_TEMPERATURE 5.0
2022-04-01 17:06:22 RSSI_DEVICE N/A
2022-04-01 17:06:22 RSSI_PEER -32
2022-04-02 09:13:39 SET_TEMPERATURE 21.5
2022-04-01 17:06:22 STICKY_UNREACH false
2022-04-01 17:06:22 UNREACH alive
2022-04-01 17:06:22 UPDATE_PENDING false
2022-04-02 09:06:00 WINDOW_OPEN_REPORTING closed
2022-04-01 17:06:22 activity alive
2022-04-01 17:06:22 battery ok
2022-04-02 09:13:39 control 21.5
2022-04-02 09:13:39 desired-temp 21.5
2022-04-02 09:13:59 devstate ok
2022-04-02 09:13:59 hmstate 21.4
2022-04-02 09:13:39 humidity 57.0
2022-04-02 09:13:59 humidityInt 57
2022-04-02 09:13:39 measured-temp 21.4
2022-04-01 17:06:22 rssidevice N/A
2022-04-01 17:06:22 rssipeer -32
2022-04-01 17:06:22 sign off
2022-04-02 09:13:39 state 21.4
hmccu:
channels 1
detect 1
devspec MEQ0089257:2
nodefaults 1
role 2:THERMALCONTROL_TRANSMIT
setDefaults 0
cmdlist:
get week-program:"WEEK#PROGRAM#1","WEEK#PROGRAM#2","WEEK#PROGRAM#3"
set off:noArg on:noArg week-program:"WEEK#PROGRAM#1","WEEK#PROGRAM#2","WEEK#PROGRAM#3" manu boost:noArg auto:noArg desired-temp toggle:noArg
control:
chn 2
dpt SET_TEMPERATURE
dp:
0.AES_KEY:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL 0
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL 0
0.DEVICE_IN_BOOTLOADER:
VALUES:
NVAL 0
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL 0
0.INHIBIT:
VALUES:
NVAL 0
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL 0
0.LOWBAT:
VALUES:
NVAL 0
ONVAL false
OSVAL ok
OVAL false
SVAL ok
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL N/A
ONVAL -255
OSVAL -255
OVAL 1
SVAL N/A
VAL -65535
0.RSSI_PEER:
VALUES:
NVAL -32
ONVAL -32
OSVAL -32
OVAL 224
SVAL -32
VAL -32
0.STICKY_UNREACH:
VALUES:
NVAL 0
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL 0
0.UNREACH:
VALUES:
NVAL 0
ONVAL false
OSVAL alive
OVAL false
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL 0
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL 0
2.ACTUAL_HUMIDITY:
VALUES:
NVAL 57.000000
ONVAL 57.000000
OSVAL 57.0
OVAL 57.000000
SVAL 57.0
VAL 57.000000
2.ACTUAL_TEMPERATURE:
VALUES:
NVAL 21.400000
ONVAL 21.400000
OSVAL 21.4
OVAL 21.400000
SVAL 21.4
VAL 21.400000
2.BATTERY_STATE:
VALUES:
NVAL 2.700000
ONVAL 2.700000
OSVAL 2.7
OVAL 2.700000
SVAL 2.7
VAL 2.700000
2.BOOST_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
2.COMMUNICATION_REPORTING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
2.CONTROL_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL AUTO
OVAL 0
SVAL AUTO
VAL 0
2.LOWBAT_REPORTING:
VALUES:
NVAL 0
ONVAL 0
OSVAL false
OVAL 0
SVAL false
VAL 0
2.PARTY_START_DAY:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
2.PARTY_START_MONTH:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
2.PARTY_START_TIME:
VALUES:
NVAL 00:00
ONVAL 00:00
OSVAL 00:00
OVAL 0
SVAL 00:00
VAL 0
2.PARTY_START_YEAR:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
2.PARTY_STOP_DAY:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
2.PARTY_STOP_MONTH:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
2.PARTY_STOP_TIME:
VALUES:
NVAL 00:00
ONVAL 00:00
OSVAL 00:00
OVAL 0
SVAL 00:00
VAL 0
2.PARTY_STOP_YEAR:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
2.PARTY_TEMPERATURE:
VALUES:
NVAL 5.000000
ONVAL 5.000000
OSVAL 5.0
OVAL 5.000000
SVAL 5.0
VAL 5.000000
2.SET_TEMPERATURE:
VALUES:
NVAL 21.500000
ONVAL 21.500000
OSVAL 21.5
OVAL 21.500000
SVAL 21.5
VAL 21.500000
2.WINDOW_OPEN_REPORTING:
VALUES:
NVAL 0
ONVAL 0
OSVAL closed
OVAL 0
SVAL closed
VAL 0
roleCmds:
get:
week-program:
channel d
role THERMALCONTROL_TRANSMIT
subcount 1
syntax D:WEEK_PROGRAM_POINTER:#program:HMCCU_DisplayWeekProgram
usage week-program {WEEK PROGRAM 1,WEEK PROGRAM 2,WEEK PROGRAM 3}
subcmd:
000:
args WEEK PROGRAM 1,WEEK PROGRAM 2,WEEK PROGRAM 3
dpt WEEK_PROGRAM_POINTER
fnc HMCCU_DisplayWeekProgram
max 2
min 0
parname program
partype 1
ps MASTER
scn 000
unit
look:
WEEK PROGRAM 1 0
WEEK PROGRAM 2 1
WEEK PROGRAM 3 2
set:
auto:
channel 2
role THERMALCONTROL_TRANSMIT
subcount 1
syntax V:AUTO_MODE:1
usage auto
subcmd:
000:
args 1
dpt AUTO_MODE
fnc
max 1
min 0
parname AUTO_MODE
partype 3
ps VALUES
scn 000
unit
boost:
channel 2
role THERMALCONTROL_TRANSMIT
subcount 1
syntax V:BOOST_MODE:1
usage boost
subcmd:
000:
args 1
dpt BOOST_MODE
fnc
max 1
min 0
parname BOOST_MODE
partype 3
ps VALUES
scn 000
unit
desired-temp:
channel 2
role THERMALCONTROL_TRANSMIT
subcount 1
syntax V:SET_TEMPERATURE:?temperature
usage desired-temp temperature
subcmd:
000:
args
dpt SET_TEMPERATURE
fnc
max 30.500000
min 4.500000
parname temperature
partype 2
ps VALUES
scn 000
unit �C
manu:
channel 2
role THERMALCONTROL_TRANSMIT
subcount 1
syntax V:MANU_MODE:?temperature=20
usage manu [temperature]
subcmd:
000:
args 20
dpt MANU_MODE
fnc
max 30.500000
min 4.500000
parname temperature
partype 2
ps VALUES
scn 000
unit �C
off:
channel 2
role THERMALCONTROL_TRANSMIT
subcount 1
syntax V:MANU_MODE:4.5
usage off
subcmd:
000:
args 4.5
dpt MANU_MODE
fnc
max 30.500000
min 4.500000
parname MANU_MODE
partype 3
ps VALUES
scn 000
unit �C
on:
channel 2
role THERMALCONTROL_TRANSMIT
subcount 1
syntax V:MANU_MODE:30.5
usage on
subcmd:
000:
args 30.5
dpt MANU_MODE
fnc
max 30.500000
min 4.500000
parname MANU_MODE
partype 3
ps VALUES
scn 000
unit �C
week-program:
channel d
role THERMALCONTROL_TRANSMIT
subcount 1
syntax D:WEEK_PROGRAM_POINTER:#program
usage week-program {WEEK PROGRAM 1,WEEK PROGRAM 2,WEEK PROGRAM 3}
subcmd:
000:
args WEEK PROGRAM 1,WEEK PROGRAM 2,WEEK PROGRAM 3
dpt WEEK_PROGRAM_POINTER
fnc
max 2
min 0
parname program
partype 1
ps MASTER
scn 000
unit
look:
WEEK PROGRAM 1 0
WEEK PROGRAM 2 1
WEEK PROGRAM 3 2
state:
chn 2
dpt ACTUAL_TEMPERATURE
Attributes:
ccuflags showMasterReadings,showLinkReadings,showDeviceReadings
cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
group Wohnzimmer
icon hc_wht_regler
room Heizung
sortby 99
stateFormat Ist: measured-temp °C CONTROL_MODE
substexcl desired-temp
substitute CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST
userReadings humidityInt {round(ReadingsVal($name,"humidity",0),0)}
webCmd desired-temp:auto:manu:boost:on:off
widgetOverride desired-temp:on,off,4.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,30.5
Noch ein Versuch:
Ist es standardmäßig so, dass in HMCCU das Reading LOWBAT (und damit einhergehend auch "battery") grundsätzlich nicht geupdatet wird und nur bei Änderungen von ok nach low und umgekehrt aktualisiert wird?
Ich frage, weil das korrespondierende Reading BATTERY_STATE immer geupdatet wird, auch wenn die Spannung sich nicht geändert hat.
Ich würde mich freuen, wenn mir jemand etwas dazu mitteilen würde!
Bitte einmal nur kurz nachsehen, ob die Readings-Uhrzeit bei "battery" frisch oder uralt ist!
Vielen Dank!
Das battery Reading wird aktualisiert, wenn die CCU LOWBAT aktualisiert. Wieso reicht das nicht aus?
Das ist insofern ein anderes Verhalten ggü. CUL_HM, wo das battery-Reading immer geupdatet wurde.
Meine Batterie-Warnungs-DOIFs senden eine E-Mail bei leerer Batterie pro Tag. Nun kommt es vor, dass ich die Mails lösche, da die Batterien ja nicht gleich am 1. Tag komplett leer sind oder ich erst in ein paar Tagen dazu komme, die Batterien zu wechseln. Wenn die Batteriemeldungsupdates nicht kommen, kommen dann auch keine Erinnerungsmails mehr.
Die DOIFs kann ich ja anpassen, das ist nicht das Problem. Aber kann es nicht vorkommen, dass das Low-Battery-Event durch Neustarts oder andere Überschneidungen einmal nicht registriert wird und verlorengeht?
Oder kurz gesagt: Wichtige Warnungen wie die Batteriemeldung sollten regelmäßig gesendet werden. Finde ich wichtiger als das regelmäßige Update der Batteriespannung.
Aber wenn es aus der CCU heraus schon nur einmalig gesendet wird, ist das Verhalten jetzt eben anders, da kann HMCCU nichts dafür und ich muss meine DOIFs anpassen.
Ich wollte nur wissen, ob das tatsächlich so ist oder ob ich irgendwie das Reading LOWBAT/battery weggefiltert hatte.
Danke Dir!
Hallo und guten Tag,
ich muss leider dieses Thema noch einmal auffrischen, da ich immer noch Probleme mit nicht erscheinenden Batteriemeldungen in meinen HM-Thermostaten (und zwar wohl nur dort) habe.
In der CCU-Oberfläche wird "Batterie leer" gemeldet.
In Erweiterung der Lists von oben steht diesmal ein FAULT_REPORTING an.
Wie man aus diesen Daten (s. auch weiter unten das komplette List) sieht, ist die Batterie leer:
FAULT_REPORTING LOWBAT 2022-10-20 17:31:29
Diese Fehlermeldung wird immer geupdatet, alle 3 Minuten, soweit so gut.
Das Reading LOWBAT steht dabei auf "ok"!?? und dementsprechend auch mein wichtiges Reading "battery" auf "ok".
Nach dem, was weiter oben steht, ist das dann ein Fehler der CCU (= Debmatic)?
Bei meinen HM-Fenstersensoren funktioniert die Batteriemeldung z. B. perfekt, da wird ja "battery" auf "low" gesetzt, deshalb bitte noch einmal meine Frage:
Wo liegt der Fehler, muss ich den Debmatic-Entwickler fragen?
Vielen Dank!
Gruß,
Friedhelm
Internals:
DEF QEQ1462321:4
FUUID 61f3d4f6-f33f-26cd-87a6-a381f8c39c595026
IODev d_ccu
NAME HT_Flur_Gaeste_WC
NR 1156
STATE Ist: 18.8 °C Ventil: 12 % AUTO
TYPE HMCCUCHN
ccuaddr QEQ1462321:4
ccudevstate active
ccuif BidCos-RF
ccuname HT_Flur_Gaeste_WC_4
ccurolectrl CLIMATECONTROL_RT_TRANSCEIVER
ccurolestate CLIMATECONTROL_RT_TRANSCEIVER
ccusubtype HM-CC-RT-DN
ccutype HM-CC-RT-DN
eventCount 2967
firmware 1.5
readonly no
READINGS:
2022-10-20 17:41:17 ACTUAL_TEMPERATURE 18.8
2022-10-15 18:35:27 AES_KEY off
2022-10-20 17:41:17 BATTERY_STATE 2.2
2022-10-20 17:41:17 BOOST_STATE 0
2022-10-15 18:35:27 CONFIG_PENDING false
2022-10-20 17:41:17 CONTROL_MODE AUTO
2022-10-15 18:35:27 DEVICE_IN_BOOTLOADER false
2022-10-20 17:41:17 FAULT_REPORTING LOWBAT
2022-10-15 18:35:27 INHIBIT false
2022-10-15 18:34:37 IODev d_ccu
2022-10-15 18:35:27 LOWBAT ok
2022-10-20 17:41:17 PARTY_START_DAY 1
2022-10-20 17:41:17 PARTY_START_MONTH 1
2022-10-20 17:41:17 PARTY_START_TIME 00:00
2022-10-20 17:41:17 PARTY_START_YEAR 0
2022-10-20 17:41:17 PARTY_STOP_DAY 1
2022-10-20 17:41:17 PARTY_STOP_MONTH 1
2022-10-20 17:41:17 PARTY_STOP_TIME 00:00
2022-10-20 17:41:17 PARTY_STOP_YEAR 0
2022-10-20 17:41:17 PARTY_TEMPERATURE 5.0
2022-10-15 18:35:27 RSSI_DEVICE -255
2022-10-15 18:35:27 RSSI_PEER -56
2022-10-20 17:41:17 SET_TEMPERATURE 18.5
2022-10-15 18:35:27 STICKY_UNREACH false
2022-10-15 18:35:27 UNREACH alive
2022-10-15 18:35:27 UPDATE_PENDING false
2022-10-20 17:41:17 VALVE_STATE 12
2022-10-15 18:35:27 activity alive
2022-10-15 18:35:27 battery ok
2022-10-20 17:41:17 control 18.5
2022-10-20 17:41:17 desired-temp 18.5
2022-10-20 17:41:17 devstate ok
2022-10-20 17:41:17 hmstate 18.8
2022-10-20 17:41:17 measured-temp 18.8
2022-10-15 18:35:27 rssidevice -255
2022-10-15 18:35:27 rssipeer -56
2022-10-15 18:35:27 sign off
2022-10-20 17:41:17 state 18.8
hmccu:
channels 1
detect 1
devspec QEQ1462321:4
nodefaults 1
role 4:CLIMATECONTROL_RT_TRANSCEIVER
setDefaults 0
cmdlist:
get
set off:noArg boost:noArg desired-temp auto:noArg on:noArg manu toggle:noArg
control:
chn 4
dpt SET_TEMPERATURE
dp:
0.AES_KEY:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.INHIBIT:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.LOWBAT:
VALUES:
NVAL false
ONVAL false
OSVAL ok
OVAL false
SVAL ok
VAL false
0.RSSI_DEVICE:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.RSSI_PEER:
VALUES:
NVAL -56
ONVAL -56
OSVAL -56
OVAL 200
SVAL -56
VAL 200
0.STICKY_UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
4.ACTUAL_TEMPERATURE:
VALUES:
NVAL 18.800000
ONVAL 18.800000
OSVAL 18.8
OVAL 18.800000
SVAL 18.8
VAL 18.800000
4.BATTERY_STATE:
VALUES:
NVAL 2.200000
ONVAL 2.200000
OSVAL 2.2
OVAL 2.200000
SVAL 2.2
VAL 2.200000
4.BOOST_STATE:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.CONTROL_MODE:
VALUES:
NVAL 0
ONVAL 0
OSVAL AUTO
OVAL 0
SVAL AUTO
VAL 0
4.FAULT_REPORTING:
VALUES:
NVAL 6
ONVAL 6
OSVAL LOWBAT
OVAL 6
SVAL LOWBAT
VAL 6
4.PARTY_START_DAY:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PARTY_START_MONTH:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PARTY_START_TIME:
VALUES:
NVAL 00:00
ONVAL 00:00
OSVAL 00:00
OVAL 0
SVAL 00:00
VAL 0
4.PARTY_START_YEAR:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.PARTY_STOP_DAY:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PARTY_STOP_MONTH:
VALUES:
NVAL 1
ONVAL 1
OSVAL 1
OVAL 1
SVAL 1
VAL 1
4.PARTY_STOP_TIME:
VALUES:
NVAL 00:00
ONVAL 00:00
OSVAL 00:00
OVAL 0
SVAL 00:00
VAL 0
4.PARTY_STOP_YEAR:
VALUES:
NVAL 0
ONVAL 0
OSVAL 0
OVAL 0
SVAL 0
VAL 0
4.PARTY_TEMPERATURE:
VALUES:
NVAL 5.000000
ONVAL 5.000000
OSVAL 5.0
OVAL 5.000000
SVAL 5.0
VAL 5.000000
4.SET_TEMPERATURE:
VALUES:
NVAL 18.500000
ONVAL 18.500000
OSVAL 18.5
OVAL 18.500000
SVAL 18.5
VAL 18.500000
4.VALVE_STATE:
VALUES:
NVAL 12
ONVAL 12
OSVAL 12
OVAL 12
SVAL 12
VAL 12
roleCmds:
get:
set:
auto:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:AUTO_MODE:1
usage auto
subcmd:
000:
args 1
dpt AUTO_MODE
fnc
max 1
min 0
parname AUTO_MODE
partype 3
ps VALUES
scn 000
unit
boost:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:BOOST_MODE:1
usage boost
subcmd:
000:
args 1
dpt BOOST_MODE
fnc
max 1
min 0
parname BOOST_MODE
partype 3
ps VALUES
scn 000
unit
desired-temp:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:SET_TEMPERATURE:?temperature
usage desired-temp temperature
subcmd:
000:
args
dpt SET_TEMPERATURE
fnc
max 30.500000
min 4.500000
parname temperature
partype 2
ps VALUES
scn 000
unit �C
manu:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:MANU_MODE:?temperature=20
usage manu [temperature]
subcmd:
000:
args 20
dpt MANU_MODE
fnc
max 30.500000
min 4.500000
parname temperature
partype 2
ps VALUES
scn 000
unit �C
off:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:MANU_MODE:4.5
usage off
subcmd:
000:
args 4.5
dpt MANU_MODE
fnc
max 30.500000
min 4.500000
parname MANU_MODE
partype 3
ps VALUES
scn 000
unit �C
on:
channel 4
role CLIMATECONTROL_RT_TRANSCEIVER
subcount 1
syntax V:MANU_MODE:30.5
usage on
subcmd:
000:
args 30.5
dpt MANU_MODE
fnc
max 30.500000
min 4.500000
parname MANU_MODE
partype 3
ps VALUES
scn 000
unit �C
state:
chn 4
dpt ACTUAL_TEMPERATURE
Attributes:
ccuflags showMasterReadings,showLinkReadings,showDeviceReadings
cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
event-on-change-reading measured-temp,CONTROL_MODE
event-on-update-reading VALVE_STATE,desired-temp,battery,FAULT_REPORTING
eventMap /datapoint 4.MANU_MODE 20.0:manu/datapoint 4.AUTO_MODE 1:auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/
group Flur
icon sani_heating
room Heizung
stateFormat Ist: measured-temp °C Ventil: VALVE_STATE % CONTROL_MODE
substexcl desired-temp
substitute CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST
webCmd desired-temp:auto:manu:boost:on:off
widgetOverride desired-temp:on,off,4.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,30.5
Nimm mal LOWBAT in das Attribut event-on-update-reading auf.
Hallo zap,
das hat nichts gebracht. LOWBAT steht ja auch schon seit 6 Tagen auf "ok". Das einzige, was auf die leere Batterie hinweist ist (implizit) BATTERY_STATE 2.2 und FAULT_REPORTING LOW_BAT.
Beide werden alle 3 Minuten aufgefrischt.
"battery" und "LOWBAT" sind uralt und falsch. In der CCU-Webansicht steht beim Thermostaten "Batterie leer".
Hier ein aktueller Auszug:
2022-10-21 16:57:38 BATTERY_STATE 2.2
2022-10-21 16:57:38 FAULT_REPORTING LOWBAT
2022-10-15 18:35:27 LOWBAT ok
2022-10-15 18:35:27 activity alive
2022-10-15 18:35:27 battery ok
Attributes:
ccuflags showMasterReadings,showLinkReadings,showDeviceReadings
cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
event-on-change-reading measured-temp,CONTROL_MODE
event-on-update-reading VALVE_STATE,desired-temp,battery,FAULT_REPORTING,LOWBAT
eventMap /datapoint 4.MANU_MODE 20.0:manu/datapoint 4.AUTO_MODE 1:auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/
Im Nachhinein bringt das nichts, da die CCU das Lowbat nur einmal schickt (Vermutung!). Um es zu testen: neue Batterien rein, auf Aktualisierung der Readings warten, alte wieder rein.
Hat etwas länger gedauert, musste schlussendlich noch das Labornetzgerät anschließen, um "vernünftige leere Batterien" zu simulieren.
Nach einer Spannung von 2,7 V habe ich auf 2.4 V reduziert (Grenze ist bei 2,5 V eingestellt).
Dabei erscheint in der HM-CCU-Web-UI die Fehlermeldung um 16:41, 16:43, 16:46 usw. "Leere Batterie". Diese Meldung wird ständig aufgefrischt, zu sehen an der Uhrzeit.
In den FHEM-Readings wird FAULT_REPORTING ebenfalls zeitlich synchron aufgefrischt, Inhalt "LOWBAT"
ABER: Die beiden Readings "LOWBAT" und "battery" kümmern sich überhaupt nicht darum, die sind und waren NIE auf "low"! Deren Zeitstempel stammt noch von 16:11, als eine "volle Batterie" da war. (Und sind es jetzt immer noch um 16:50).
Internals:
DEF QEQ1462321:4
FUUID 61f3d4f6-f33f-26cd-87a6-a381f8c39c595026
IODev d_ccu
NAME HT_Flur_Gaeste_WC
NR 1156
STATE Ist: 20.7 °C Ventil: 0 % AUTO
TYPE HMCCUCHN
ccuaddr QEQ1462321:4
ccudevstate active
ccuif BidCos-RF
ccuname HT_Flur_Gaeste_WC_4
ccurolectrl CLIMATECONTROL_RT_TRANSCEIVER
ccurolestate CLIMATECONTROL_RT_TRANSCEIVER
ccusubtype HM-CC-RT-DN
ccutype HM-CC-RT-DN
eventCount 4148
firmware 1.5
readonly no
READINGS:
2022-10-22 16:33:30 ACTUAL_TEMPERATURE 20.7
2022-10-15 18:35:27 AES_KEY off
2022-10-22 16:33:30 BATTERY_STATE 2.4
2022-10-22 16:33:30 BOOST_STATE 0
2022-10-15 18:35:27 CONFIG_PENDING false
2022-10-22 16:33:30 CONTROL_MODE AUTO
2022-10-15 18:35:27 DEVICE_IN_BOOTLOADER false
2022-10-22 16:33:30 FAULT_REPORTING LOWBAT
2022-10-15 18:35:27 INHIBIT false
2022-10-15 18:34:37 IODev d_ccu
2022-10-22 16:11:41 LOWBAT ok
2022-10-22 16:33:30 PARTY_START_DAY 1
2022-10-22 16:33:30 PARTY_START_MONTH 1
2022-10-22 16:33:30 PARTY_START_TIME 00:00
2022-10-22 16:33:30 PARTY_START_YEAR 0
2022-10-22 16:33:30 PARTY_STOP_DAY 1
2022-10-22 16:33:30 PARTY_STOP_MONTH 1
2022-10-22 16:33:30 PARTY_STOP_TIME 00:00
2022-10-22 16:33:30 PARTY_STOP_YEAR 0
2022-10-22 16:33:30 PARTY_TEMPERATURE 5.0
2022-10-15 18:35:27 RSSI_DEVICE -255
2022-10-15 18:35:27 RSSI_PEER -56
2022-10-22 16:33:30 SET_TEMPERATURE 14.0
2022-10-15 18:35:27 STICKY_UNREACH false
2022-10-15 18:35:27 UNREACH alive
2022-10-15 18:35:27 UPDATE_PENDING false
2022-10-22 16:33:30 VALVE_STATE 0
2022-10-15 18:35:27 activity alive
2022-10-22 16:11:41 battery ok
2022-10-22 16:33:30 control 14.0
2022-10-22 16:33:30 desired-temp 14.0
2022-10-22 16:33:30 devstate ok
2022-10-22 16:33:30 hmstate 20.7
2022-10-22 16:33:30 measured-temp 20.7
2022-10-15 18:35:27 rssidevice -255
2022-10-15 18:35:27 rssipeer -56
2022-10-15 18:35:27 sign off
2022-10-22 16:33:30 state 20.7
Attributes:
ccuflags showMasterReadings,showLinkReadings,showDeviceReadings
cmdIcon auto:sani_heating_automatic manu:sani_heating_manual boost:sani_heating_boost on:general_an off:general_aus
event-on-change-reading measured-temp,CONTROL_MODE
event-on-update-reading VALVE_STATE,desired-temp,battery,FAULT_REPORTING,LOWBAT
eventMap /datapoint 4.MANU_MODE 20.0:manu/datapoint 4.AUTO_MODE 1:auto/datapoint 4.BOOST_MODE 1:Boost/datapoint 4.MANU_MODE 4.5:off/datapoint 4.MANU_MODE 30.5:on/
5
Hallo zap,
endlich habe ich den Fehler gefunden!
Als jetzt wieder ein HM-CC-RT-DN mit leerer Batterie in der CCU sichtbar war, fiel es mir wie Schuppen von den Augen:
Im Kanal 4 des Thermostaten war als Name in der CCU noch die Homematic-Bezeichnung mit Seriennr. angegeben.
Ich habe dann in der CCU diesen Kanal auf die sprechende Bezeichnung in FHEM hin geändert, und siehe da: sofort kommt eine Batteriewarnmeldung!
Dass die Kanäle auch alle im Namen angepasst werden müssen, war mir bisher nicht klar, ist das so gewollt?
Im FHEM-Device steht ja immerhin der Original CCU-Name, und man könnte den ja für die Identifizierung verwenden.
Das hieße im Umkehrschluss: sobald man in FHEM ein Homematic-Gerät umbenennt, bekommt man keine Batteriewarnungen mehr.
Gruß
Friedhelm
Die Änderung des Namens in der CCU hat das Update der Daten in Richtung FHEM getriggert. Das wäre auch passiert, wenn Du "xyz" eingetragen hättest. HMCCU nutzt die Device- und Kanaladressen, nicht die Namen.
Hallo zap,
stimmt, die Umbenennung hat nur ein kurzes Update gebracht.
Ich suche immer noch nach der fehlenden Batteriemeldung.
Dabei ist mir folgendes aufgefallen:
Laut eQ3 kennt ein HM-CC-RT-DN gar keinen Datenpunkt "LOWBAT" oder "LOW_BAT", die gelten nur für z. B. Fensterkontakte etc.
https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HM-Script_4-Datenpunkte.pdf
Ein HM-CC-RT-DN kann nur durch den Datenpunkt FAULT_REPORTING eine schwache Batterie melden:
Parameter FAULT_REPORTING
Typ: option
Zugriffsart: lesend über Ereignisse
Werteliste: 0 = NO_FAULT (Standard)
1 = VALVE_TIGHT
2 = ADJUSTING_RANGE_TOO_LARGE
3 = ADJUSTING_RANGE_TOO_SMALL
4 = COMMUNICATION_ERROR
6 = LOWBAT
7 = VALVE_ERROR_POSITION
Bei meinem HM-CC-RT-DN wird FAULT_REPORTING mit Inhalt "LOWBAT" alle 3 Minuten aufgefrischt. Die CCU meldet also die leere Batterie.
Ich bin nicht so fit in Perl, aber in den HMCCU-Modulen kommt m. M. nur der Zugriff auf LOWBAT vor, es wird nicht auf FAULT_REPORTING geachtet.
# Datapoints to be converted to new readings
my %newReadings = (
'AES_KEY' => 'sign',
'RSSI_DEVICE' => 'rssidevice',
'RSSI_PEER' => 'rssipeer',
'LOW_BAT' => 'battery',
'LOWBAT' => 'battery',
'OPERATING_VOLTAGE' => 'voltage',
'UNREACH' => 'activity',
'SABOTAGE' => 'sabotage',
'ERROR_SABOTAGE' => 'sabotage'
);
Kannst Du das bestätigen, oder irre ich mich?
Gruß,
Friedhelm