Hallo Zusammen,
ich wollte fragen ob es eine Möglichkeit gibt den Battery Status/Level vom Temperatursensor HM-WDS10-TH-O zu erhalten?
Ich habe eine Readingsgroup die mir alle Devices mit Battery Status und den Volt Level anzeigt, leider taucht der HM-WDS10-TH-O dort nicht auf weil keine solche Readings vorhanden.
Jemand einen Tipp?
Danke.
Internals:
DEF 50310C
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 86281
NAME HM_50310C
NOTIFYDEV global
NR 84
NTFY_ORDER 50-HM_50310C
STATE <span style="color:green">Temperatur: 16.9 °C </span><br><span style="color:blue"> Feuchtigkeit: 65 %</span><br><span style="color:black">Taupunkt: 10.3 °C<br>Abs. Feuchte: 9.3 g/m3</span>
TYPE CUL_HM
lastMsg No:5C - t:10 s:50310C d:424242 0100000000
myHmUART_MSGCNT 86281
myHmUART_RAWMSG 050100565CA01050310C4242420100000000
myHmUART_RSSI -86
myHmUART_TIME 2018-10-12 20:50:20
protLastRcv 2018-10-12 20:50:20
protSnd 4 last_at:2018-10-12 20:50:20
protState CMDs_done
rssi_at_myHmUART lst:-86 cnt:86281 min:-91 max:-69 avg:-78.77
Helper:
DBLOG: Activity: dbLogMaria: TIME 1539370857.84055
VALUE dead
absFeuchte: dbLogMaria: TIME 1539370219.59875 VALUE 9.3
battery: dbLogMaria: TIME 1539369874.60392 VALUE ok
dewpoint: dbLogMaria: TIME 1539370219.59875 VALUE 10.3
humidity: dbLogMaria: TIME 1539369267.82037 VALUE 65
state: dbLogMaria: TIME 1539370219.59875 VALUE T: 16.9 H: 65
temperature: dbLogMaria: TIME 1539370219.59875 VALUE 16.9
READINGS: 2018-10-12 21:00:57
Activity dead 2018-10-12 20:50:19
CommandAccepted yes 2017-01-05 17:49:57
D-firmware 1.3 2017-01-05 17:49:57
D-serialNr NEQ1380900 2018-10-12 20:50:20
PairedTo 0x424242 2017-01-05 17:51:40
R-burstRx off 2017-01-05 17:51:40
R-pairCentral 0x424242 2018-10-12 20:50:19
absFeuchte 9.3 2018-10-12 20:50:19
battery ok 2018-10-12 20:50:19
dewpoint 10.3 2018-10-12 20:50:19
humidity 65 2018-10-12 20:50:19
state T: 16.9 H: 65 2018-10-12 20:50:19
temperature 16.9
helper: HM_CMDNR 92
PONtest 1
cSnd 0142424250310C00040000000000,0142424250310C0103
mId 003D
peerIDsRaw ,00000000
rxType 140
supp_Pair_Rep 0
expert: def 1
det 1
raw 0
tpl 0
io: newChn +50310C,00,00,00
nextSend 1539370220.68128
prefIO rxt 2
vccu p: 50310C 00 00 00
mRssi: mNo 5C
io: myHmUART -84
prt: bErr 0 sProc 0
rspWait:
q: qReqConf qReqStat
role: chn 1 dev 1
rpt: IO myHmUART flg A ts 1539370220.38779
ack: HASH(0x1c2a590) 5C800242424250310C00
rssi: at_myHmUART: avg -78.7730323014333 cnt 86281 lst -86 max -69 min -91
shadowReg:
Attributes:
IODev myHmUART actCycle 000:10
actStatus dead
alias Aussen Temperatur
autoReadReg 4_reqStatus
comment
event-min-interval .*:3600
event-on-change-reading .*
expert 1_allReg
firmware 1.3
group Dash_temp
homebridgeMapping CurrentRelativeHumidity=humidity CurrentTemperature=temperature,minValue=-20,subtype=Temperatur CurrentTemperature=dewpoint,minValue=-20,subtype=Taupunkt
icon scene_summerhouse
model HM-WDS10-TH-O
peerIDs 00000000,
room Aussen,Homekit
serialNr NEQ1380900
stateFormat <span style="color:green">Temperatur: temperature °C </span><br><span style="color:blue"> Feuchtigkeit: humidity %</span><br><span style="color:black">Taupunkt: dewpoint °C<br>Abs. Feuchte: absFeuchte g/m3</span> subType THSensor
Wie sieht denn die readingsGroup aus?
Also meine beiden haben ein "battery" Reading...
...also battery ok bzw. low.
Aber KEIN batteryLevel.
Das haben nur wenige HomeMatic Geräte (Wandthermostat, Heizkörperthermostat / sonst kenne/habe ich keine).
Gruß, Joachim
Moin,
ich habe ein userReading nach dieser Anleitung gemacht. Funktioniert soweit ganz gut.
https://wiki.fhem.de/wiki/Batterie%C3%BCberwachung
battery { return "ok" if ( (time_str2num(ReadingsTimestamp($NAME,"state","0")) - time_str2num(OldTimestamp($NAME))) < 600 ); return "low" }
Gruss
Enno
Hallo Joachim,
ich hab mich etwas vertan sehe ich gerade...
Es gibt zwar "nur" ein Reading "battery" mit Status ok
aber mein Readingsgroup zeigt ein grünes Symbol für Batterie ok. Vermutlich da mein Gerät ausgefallen ist ohne battery low als letztes zu senden. ???
Gibt es keine Möglichkeit eine Art Watchdog zu setzen der den letzen Status der Batterien prüft und dann irgendwann auf low setzt.
Mir ist erst jetzt aufgefallen dass die Aussentemperatur immer noch 17.9 Grad beträgt ;D
Die andere Readingsgroup zeigt nur alle Heizkörper das ist richtig. Schön mit Battery Level usw.
Das userReading von Enno schau ich mir an...sieht besser aus als das was ich habe:
NAME battStatus
DEF .*:[Bb]attery
TYPE readingsGroup
mapping %ALIAS
valueIcon: {battery.ok' => 'batterie', 'battery.low' => 'batterie@red'}
....
Danke !!
Zitat von: Steffen@Home am 27 November 2018, 09:46:09
aber mein Readingsgroup zeigt ein grünes Symbol für Batterie ok. Vermutlich da mein Gerät ausgefallen ist ohne battery low als letztes zu senden. ???
Gibt es keine Möglichkeit eine Art Watchdog zu setzen der den letzen Status der Batterien prüft und dann irgendwann auf low setzt.
JA: heißt Action Detector und sollte bei HomeMatic eigentlich automatisch aktiv sein. (dazu muss es im Device ein Attribut actCycle geben).
Ich habe ein Notify auf "dead" und setze dann eine Nachricht ab und ändere auch das Icon in der readingsGroup.
(bzw. habe ich eine indirekte Anzeige über einen Batterie-Sammel-Dummy und die beeinflusse ich bei "dead")
Hatte ich auch schon, dass kein low kam...
...aber dann wurde er "dead" gemeldet und ich hab die Batterien gewechselt...
Evtl. musst du den automatisch angelegten/eingestellten Wert bei actCycle etwas "tunen" ;)
Aber ich würde ihn erst mal lassen!
Gruß, Joachim
Das Attribut ist da:
actCycle 000:10
was bewirkt dieser Action Detector dann genau ?
Duckduckgo (ich nehme an google schafft das auch ;) ) liefert folgendes:
https://wiki.fhem.de/wiki/HomeMatic
https://wiki.fhem.de/wiki/HomeMatic#Action_Detector
https://forum.fhem.de/index.php?topic=10465.0
Prüft und schaut, ob im Zeitraum actCycle schon mal wieder was vom Gerät "gehört" wurde...
...also mal ganz grob.
Gruß, Joachim
Hallo Joachim, danke.
Wäre schön wenn der ActionDetector eine Funktion zur Informationsweitergabe besitzen würde falls sich der status irgendeines HM Gerätes ändert, wo man z.B. ein telegram message oder eine andere Option eintragen kann.
Workaround wären dann wohl notify´s...
Geht sowas hier ?...
define n_state_chk notify ActionDetector:status_.*:dead { if ($EVENT !~ m/ok/ ) {fhem "set d_Alarm on;set telebotdevice message $NAME: Batteriewarnung $EVENT"}}oder was aus dem netz...
defmod n_state_chk notify .*:dead|.*:[Bb]attery:.* {
if($EVENT !~ m/ok/ ) {
{ fhem ("msg FHEM Batteriewarnung, $NAME: $EVENT:\nBatterien sollten demnächst gewechselt werden!");;
Log 3, "$NAME: Batteriewarnung $EVENT";; \
}
}
}EDIT:
Anscheinend kann HMInfo sowas...muss ich mich mal schlau machen.
Zitat von: betateilchen am 15 Januar 2015, 23:23:06
Ich würde das einfach über HMinfo lösen, da gibt es einen event, sobald ein Device als "dead" erkannt wird. Und man kann einfach auslesen, um welches Gerät es sich handelt.
(Dass ich mal HMinfo empfehlen würde, hätte ich auch nie gedacht...)
Zitat von: Steffen@Home am 28 November 2018, 07:10:51
Wäre schön wenn der ActionDetector eine Funktion zur Informationsweitergabe besitzen würde falls sich der status irgendeines HM Gerätes ändert, wo man z.B. ein telegram message oder eine andere Option eintragen kann.
Widerspricht (ein wenig) der fhem-Philosopie...
Es ist (eher) Event-getrieben...
Das Notify aus dem Netz sollte gehen.
Allerdings ist es nicht sonderlich "Resourcenschonend", da es auf jedes Event von jedem angekegten Gerät "aktiviert" wird und prüft, ob etwas mit "dead" oder "battery" etc. "drin steht"...
Ich habe (zusätzlich zur "normalen" Batterieüberwachung) noch folgendes Notify:
define nSignalDeadDevice ActionDetector.status_.*:.* {my_SignalDeadDevice($EVENT)}In der Sub prüfe ich gewisse Dinge bzw. setze eben in meinem Batteriestatus-Dummy ein bestimmtes Icon und schicke eine Nachricht, dass eben GerätX "dead" bzw. "unknown" ist.
Bei "alive" setze ich das Icon im Dummy wieder zurück...
Zitatdefine n_state_chk notify ActionDetector:status_.*:dead { if ($EVENT !~ m/ok/ ) {fhem "set d_Alarm on;set telebotdevice message $NAME: Batteriewarnung $EVENT"}}
Ist dem ähnlich, allerdings glaube ich, dass da kein "ok" kommt sondern "alive" (wenn alles "ok" ist)...
Bzw. ist die Abfrage eh unnötig, das Event triggert ja nur auf "dead"...
Es gibt aber auch noch "unknown" (und vielleicht noch weitere "Zustände")...
Der Eventmonitor hilft... ;)
Zur "normalen" Batterieüberwachung habe ich (in etwa) folgendes im Einsatz:
https://forum.fhem.de/index.php/topic,82637.0.html
Gruß, Joachim
Hallo Joachim,
kannst du erklären worin der Unterschied liegt ob man mit einem Notify auf eine Statusänderung vom ActionDetector reagiert oder dieser selbst auf seinen eigenen Event etwas auslöst?
Mit dem Notify hast du natürlich vollkommen recht, bei :dead kann ich mir die IF Abfrage sparen!
define n_state_chk notify ActionDetector:status_.*:dead { fhem "set d_Alarm on;set telebotdevice message $NAME: Batteriewarnung: $EVENT"}
oder für alle Benachrichtigungen...
define n_state_chk notify ActionDetector:status_.* { fhem "set d_Alarm on;set telebotdevice message $NAME: Zustand: $EVENT"}}
Wenn der ActionDetector (oder egal welches Modul) etwas tun soll aufgrund bestimmter Dinge/Ereignisse, dann muss das im Modul vorgesehen sein und evtl. sogar vom Anwender beeinflusst werden können...
Wenn etwas wie Nachrichten versenden geschehen soll entstehen dadurch dann evtl. (feste) Abhängigkeiten zu anderen Modulen, unschön...
Die Philosophie bei fhem ist halt (eigentlich) anders: es geschieht etwas (ein Gerät wird als "dead" eingestuft oder ein Messwert eines Sensors wird "empfangen", ...), darauf wird ein Reading bei einem dafür zuständigen "fhem-Device" gesetzt was einen Event auslöst...
Wenn andere Module oder der Anwender an dem Ereignis (z.B. "dead") interessiert ist kann er das dem System (fhem) "sagen" und auch "mitteilen" was dann geschehen soll (z.B. anlegen eines entsprechenden/passenden Notify, DOIF, ...).
Dadurch gibt es nur lose Kopplungen und nur, wenn dies auch gewünscht/benötigt wird.
Einziges "Risiko": es kommt nie ein Event der passt... ;)
D.h. selbst wenn die "Gegenseite" gelöscht würde, würde es keinen Fehler bzgl. nicht (mehr) vorhandener Abhängigkeit geben...
Es würde halt (nat.) nur nichts mehr entsprechendes passieren... ;)
D.h. Module können deutlich flexibler und robuster unabhängig voneinander entwickelt werden...
...und trotzdem bei Bedarf interagieren...
So, lange Rede...
...kurz: der Action Detector hat nichts vorgesehen, weil nicht implementiert. Wenn gewünscht/unbedingt notwendig: Wunsch an Modulautor (inkl. patch)
Und: die "Philosophie" von fhem ist halt eigentlich anders...
Gruß, Joachim
P.S.: es ist open source -> ändere was dir nicht gefällt... ;)
Hallo Joachim,
Danke, sehr gut erklärt! ;)