Hallo Martin,
kannst Du bitte den Batteriestatus beim Temperaursensor HM-WDS10-TH-O ebenfalls einbauen.
In $p steckt das Bit dafür nach meinen Messungen am Anfang drin (Firmware 1.2 des Sensors).
Folgender Codeschnippsel bei den THSensoren (Zeile 1144 nach letztem Update im Humidity Bereich) tut es.
if ($md eq "HM-WDS10-TH-O") {#here low battery bit is know at least for Firmware V1.2
push @event, "battery:".(hex(substr($p,0,2))&0x80?"low":"ok");
}
Folgendes habe ich zu dem entsprechenden Bit ermittelt:
Einschalten 3.3V
2014-02-16 14:44:15 A0D008410206B070000000600000018 No:00 - t:10 s:206B07 d:000000 06000000
erste Message 3.3V
2014-02-16 14:47:00 A0C018670206B0700000000CA351F No:01 - t:70 s:206B07 d:000000 00CA35
2014-02-16 14:49:31 A0C028670206B0700000000CC3220 No:02 - t:70 s:206B07 d:000000 00CC32
erste Message 2.4V
2014-02-16 14:51:47 A0C038670206B0700000000C43120 No:03 - t:70 s:206B07 d:000000 00C431
2014-02-16 14:53:49 A0C048670206B0700000080C33121 No:04 - t:70 s:206B07 d:000000 80C331 das Bit der 80 in d: muss Low Bat sein
erste Message 2.0V
2014-02-16 14:56:40 A0C058670206B0700000083E86422 No:05 - t:70 s:206B07 d:000000 83E864 (100°C, 100%) das Bit der 80 in d: muss Low Bat sein
2014-02-16 14:59:17 A0C068670206B0700000083E86422 No:06 - t:70 s:206B07 d:000000 83E864 (100°C, 100%) das Bit der 80 in d: muss Low Bat sein
erste Message 3.3V
2014-02-16 15:01:39 A0C078670206B0700000080C83124 No:07 - t:70 s:206B07 d:000000 80C831 (20.0°C, 49%) das Bit der 80 in d: muss Low Bat sein
2014-02-16 15:03:47 A0C088670206B0700000000C8312A No:08 - t:70 s:206B07 d:000000 00C831 (20.0°C, 49%)
2014-02-16 15:06:45 A0C098670206B0700000000C83021 No:09 - t:70 s:206B07 d:000000 00C830 (20.0°C, 48%)
erste Message 2.5V
2014-02-16 15:09:28 A0C0A8670206B0700000000C33026 No:0A - t:70 s:206B07 d:000000 00C330 (19.5°C, 48%)
erste Message 2.4V
2014-02-16 15:11:56 A0C0B8670206B0700000080C23021 No:0B - t:70 s:206B07 d:000000 80C230 (19.4°C, 48%) das Bit der 80 in d: muss Low Bat sein
2014-02-16 15:14:11 A0C0C8670206B0700000080C23021 No:0C - t:70 s:206B07 d:000000 80C230 (19.4°C, 48%) das Bit der 80 in d: muss Low Bat sein
erste Message 3.3V
2014-02-16 15:17:14 A0C0D8670206B0700000080C83017 No:0D - t:70 s:206B07 d:000000 80C830 (20.0°C, 48%) das Bit der 80 in d: muss Low Bat sein
2014-02-16 15:20:04 A0C0E8670206B0700000000C7301C No:0E - t:70 s:206B07 d:000000 00C730 (19.9°C, 48%)
2014-02-16 15:22:39 A0C0F8670206B0700000000C730F9 No:0F - t:70 s:206B07 d:000000 00C730 (19.9°C, 48%)
Wenn das Bit allgemeiner den Batteriestatus für THSensoren angibt, dann macht es natürlich Sinn, es allgemeiner einzubauen, statt auf den HM-WDS10-TH-O zu beschränken.
Auf jeden Fall eine nützliche Zusatzinfo, statt zu warten, bis nichts mehr vom Sensor kommt. Ich kann Sie gut gebrauchen.
Nebenbei fällt auch die Temperaturabhängigkeit der Meeswerte von der Batteriespannung auf... ;)
Außerdem habe ich bei den Temperatursensoren bemerkt, dass
attr Raumx autoReadReg 0_off
die Batterien doch erheblich schont.
Mit autoReadReg = 4 waren innerhalb von ca. 2 Wochen die Batterien meiner HM-WDS10-TH-O (Firmware V1.2) und HM-WDS30-OT2-SM (Firmware V1.0) leer (Empfangsverhältnisse sind auch nicht so gut). Bei neu eingestzten hatte ich die Spannung mal gemessen und gemerkt, wie die Batteriespannung bei autoReadReg = 4 recht flott runter ging. Bei 0 war das nicht so.
Im Status der Sensoren in FHEM waren mir damals bei autoReadReg = 4 auch ausstehende Requests (oder so) aufgefallen (hat der CUL dann vielleicht ständig Requests gesendet und damit die Sensoren "wach" gehalten?).
Vielen Dank für alle tolle FHEM Arbeit!
Ansgar.
Hi Ansgar,
lowbat baue ich allgemein ein - es betrifft zumindest mehrere Sensoren, sicher zumindest die Meisten.
Zu autoReadReg - das sollte natuerlich nicht der Fall sein.
Kannst du einmal aufzeichnen, was da passiert? Aufgrund der temp-meldung sollte kein request stattfinden... waere interessant zu wissen, was getriggert wird,
Ausserdem - nach dem Update bitte einmal negative temperaturen messen. Insbesonderen bei lowbat sollte es Probleme gegeben haben.
Gruss Martin
Zitat von: martinp876 am 18 Februar 2014, 09:54:09Zu autoReadReg - das sollte natuerlich nicht der Fall sein.
8) mir wollte das ja seinerzeit bei Einführung des autoReadReg niemand glauben. Endlich hat das mal jemand bestätigt. Deshalb stehen bei mir die meisten HM-Geräte maximal auf aRR=3, die Sensoren aber alle auf 0.
verstehe ich jetzt nicht.
temp-sensoren senden temperaturen. Diese messages sollten keine weitere Abfrage nach sich ziehen.
Wenn dem so ist brauche ich die Unterstuetzung, die Ursache zu finden. Das muss deshalb nicht das ganze feature kippen, es muss nur getunt werden. Bei mit steht aRR=5 ueberall.
falls also jemand den Fall THsensorenfuer mich loggen koennte - geht auch selektiv mit logIDs... dann sollte es zu beheben sein.
Gruss Martin
Vielleicht kann das "Problem" damit zusammenhängen, dass der Sensor auch im gepairten Zustand sämtliche Nachrichten an "broadcast" schickt?
Mein Sensor läuft übrigens mit Firmware 1.3
da wird kein request ausgeloest. Jedenfalls sehe ich den nicht - daher bitte die logs. Grund gibt es hier keinen.
==> daher die Frage nach den logs - damit ich es verstehen kann.
Daher verstehe ich auch nicht den Batterieverbrauch. das Device ist burstfaehig - wenn man dies einschaltet wird es bei jedem burst-"hallowach" -EGAL FUER WEN- wachgeruettelt. das kostet batterie. Schaltet man das ab sollte es eine deutliche Verbesserung sein - insbesondere wenn man andere burst-devices gelegentlich entsprechend bedient.
broadcast hat damit nichts zu tun
Hallo Martin,
schon mal danke für den battery Status. :)
Zu AutoReadReg, da war auf jeden Fall was mit CMDs pending im Status, so weit ich mich erinnere (Im Dezember ist es mir aufgefallen). Ich bin mir aber nicht sicher, ob das nur bei den WDS30 oder auch bei den WDS10 so war. Die Batterien wurden aber bei allen diesen Sensoren leer gesaugt. Andere HM Geräte habe ich noch nicht.
Ich muss mir erst mal frische Batterien besorgen und dann kann ich mal am Wochenende versuchen, was zu loggen.
Hast Du passende Log Einstellungen für mich, damit Du auch was sinnvolles sehen kannst? Damt habe ich mich noch nicht wirklich beschäftigt.
Und das mit den negativen Temperaturen werd ich mal testen und schauen, was da kommt. Ich hoffe, die Sensoren senden aus dem Gefrierschrank raus noch kräftig genug. Das mit dem Netzteil wird dann wohl auch spannender. ;)
Grüße, Ansgar.
Hallo Ansgar
zum loggen
attr global verbose 1
attr global mseclog 1
attr <hmlan> logIDs all,sys
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848
oder bei logIDs die ID der zu loggenden Devices statt all
Gruss Martin
Hallo Martin,
nun der Test aus dem Gefrierschrank. Die gute Nachricht, der WDS10 sendet aus dem Gefrierschrank. :)
Die schlechte, Deine Befürchtung bewahrheitet sich bei negativen Temperaturen.
Der Status zeigt:
Message 3.2V
2014-02-21 23:52:17 A0C098670206B070000007FB6202F No:09 - t:70 s:206B07 d:000000 7FB620 (-7.4°C, 32%)
Message 2.4V
2014-02-22 00:02:34 A0C0B8670206B07000000FF921F2F No:0B - t:70 s:206B07 d:000000 FF921F (3265.8°C, 32%) Battery Bit macht Temperatur kaputt
Die Temperatur ist also keine integer 16Bit Zahl sondern nur eine integer 15Bit Zahl. Das führt zu der Code Korrektur:
ab Zeile 1122:
my $t = hex(substr($p,0,4) & 0x7fff;
$t -= 0x8000 if($t & 0x4000);
$t = sprintf("%0.1f"m $t/10);
Dann zeigt der Status:
mit Korrektur 2.4V
2014-02-22 00:20:39 A0C128670206B07000000FF5C202F No:12 - t:70 s:206B07 d:000000 FF5C20 (-16.4°C, 32%)
mit Korrektur 3.3V
2014-02-22 00:25:47 A0C148670206B070000007F5E2030 No:14 - t:70 s:206B07 d:000000 7F5E20 (-16.2°C, 32%)
mit Korrektur 2.4V
2014-02-22 00:20:39 A0C128670206B07000000FF5C202F No:12 - t:70 s:206B07 d:000000 FF5C20 (-16.4°C, 32%) Battery low
mit Korrektur 3.3V
2014-02-22 00:25:47 A0C148670206B070000007F5E2030 No:14 - t:70 s:206B07 d:000000 7F5E20 (-16.2°C, 32%)
mit Korrektur 3.3V
2014-02-22 00:38:41 A0C198670206B0700000000294532 No:19 - t:70 s:206B07 d:000000 002945 (4.1°C, 69%)
mit Korrektur 2.4V
2014-02-22 00:43:39 A0C1B8670206B07000000804B4A32 No:1B - t:70 s:206B07 d:000000 804B4A (7.5°C, 74%) Battery low
also so stimmt es damit zumindest beim WDS10. Und Bit 15 ist low Battery.
Zu autoReadReg später mehr.
Grüße, Ansgar.
Hallo Martin,
hier nun auch das AutoReadReg Experiment:
zwei IDs mit AutoReadReg 4:
WDS10 206B07
WDS30 2156E2
2014.02.22 01:37:23.687 4: CUL_Parse: CUL_0 A 0C 62 8670 206A4E 000000 00545314 -64
2014.02.22 01:37:31.211 4: CUL_Parse: CUL_0 A 0C 0F 8670 206B07 000000 00913F13 -64.5
2014.02.22 01:37:31.313 4: CUL_send: CUL_0As 09 01 A112 F11034 206B07
2014.02.22 01:38:30.064 4: CUL_Parse: CUL_0 A 16 9B 8653 2156E5 000000 0041005942005743000244FFFEF6 -79
2014.02.22 01:38:45.292 4: CUL_Parse: CUL_0 A 0C 94 8670 2070A0 000000 00A43639 -45.5
2014.02.22 01:38:51.725 4: CUL_Parse: CUL_0 A 16 86 8653 2156E2 000000 0041000F42008A43FF8544007B2D -51.5
2014.02.22 01:38:51.827 4: CUL_send: CUL_0As 09 02 A112 F11034 2156E2
2014.02.22 01:38:51.987 4: CUL_Parse: CUL_0 A 0A 02 8002 2156E2 F11034 002D -51.5
2014.02.22 01:38:52.090 4: CUL_send: CUL_0As 0B 03 A001 F11034 2156E2 0103
2014.02.22 01:38:52.247 4: CUL_Parse: CUL_0 A 0E 03 A010 2156E2 F11034 01000000002D -51.5
2014.02.22 01:38:52.309 4: CUL_send: CUL_0As 0A 03 8002 F11034 2156E2 00
2014.02.22 01:38:52.700 4: CUL_Parse: CUL_0 A 0E 03 A010 2156E2 F11034 01000000002D -51.5
2014.02.22 01:38:52.762 4: CUL_send: CUL_0As 0A 03 8002 F11034 2156E2 00
2014.02.22 01:38:53.133 4: CUL_Parse: CUL_0 A 0E 03 A010 2156E2 F11034 01000000002C -52
2014.02.22 01:38:53.195 4: CUL_send: CUL_0As 0A 03 8002 F11034 2156E2 00
2014.02.22 01:38:58.847 4: CUL_Parse: CUL_0 A 16 2F 8653 2157C8 000000 004100D04200BE43001244FFEE12 -65
2014.02.22 01:39:51.597 4: CUL_Parse: CUL_0 A 16 AD 8653 2156E4 000000 0041008742005C43002B44FFD5EB -84.5
2014.02.22 01:39:51.728 4: CUL_Parse: CUL_0 A 0C 10 8670 206B07 000000 00913F12 -65
2014.02.22 01:39:51.830 4: CUL_send: CUL_0As 09 04 A112 F11034 206B07
2014.02.22 01:40:23.941 4: CUL_Parse: CUL_0 A 0C 63 8670 206A4E 000000 00545314 -64
2014.02.22 01:41:07.544 4: CUL_Parse: CUL_0 A 0C 95 8670 2070A0 000000 00A43638 -46
2014.02.22 01:41:23.816 4: CUL_Parse: CUL_0 A 16 9C 8653 2156E5 000000 0041005942005743000244FFFEF6 -79
2014.02.22 01:41:33.473 4: CUL_Parse: CUL_0 A 16 87 8653 2156E2 000000 0041000F42008A43FF8544007B2D -51.5
2014.02.22 01:41:33.575 4: CUL_send: CUL_0As 09 05 A112 F11034 2156E2
2014.02.22 01:41:33.727 4: CUL_Parse: CUL_0 A 0A 05 8002 2156E2 F11034 002C -52
2014.02.22 01:41:33.829 4: CUL_send: CUL_0As 0B 06 A001 F11034 2156E2 0203
2014.02.22 01:41:33.985 4: CUL_Parse: CUL_0 A 0E 06 A010 2156E2 F11034 01000000002D -51.5
2014.02.22 01:41:34.047 4: CUL_send: CUL_0As 0A 06 8002 F11034 2156E2 00
2014.02.22 01:41:34.429 4: CUL_Parse: CUL_0 A 0E 06 A010 2156E2 F11034 01000000002C -52
2014.02.22 01:41:34.491 4: CUL_send: CUL_0As 0A 06 8002 F11034 2156E2 00
2014.02.22 01:41:34.872 4: CUL_Parse: CUL_0 A 0E 06 A010 2156E2 F11034 01000000002C -52
2014.02.22 01:41:34.938 4: CUL_send: CUL_0As 0A 06 8002 F11034 2156E2 00
2014.02.22 01:41:43.300 4: CUL_Parse: CUL_0 A 16 30 8653 2157C8 000000 004100DA4200BE43001C44FFE412 -65
2014.02.22 01:41:57.966 4: CUL_Parse: CUL_0 A 0C 11 8670 206B07 000000 00913F12 -65
2014.02.22 01:41:58.068 4: CUL_send: CUL_0As 09 07 A112 F11034 206B07
2014.02.22 01:42:22.098 4: CUL_Parse: CUL_0 A 16 AE 8653 2156E4 000000 0041008742005C43002B44FFD5E9 -85.5
2014.02.22 01:43:09.695 4: CUL_Parse: CUL_0 A 0C 64 8670 206A4E 000000 00545314 -64
2014.02.22 01:43:15.295 4: CUL_Parse: CUL_0 A 0C 96 8670 2070A0 000000 00A43638 -46
2014.02.22 01:44:00.723 4: CUL_Parse: CUL_0 A 16 88 8653 2156E2 000000 0041000F42008A43FF8544007B2D -51.5
2014.02.22 01:44:00.825 4: CUL_send: CUL_0As 09 08 A112 F11034 2156E2
2014.02.22 01:44:00.978 4: CUL_Parse: CUL_0 A 0A 08 8002 2156E2 F11034 002D -51.5
2014.02.22 01:44:01.080 4: CUL_send: CUL_0As 0B 09 A001 F11034 2156E2 0303
2014.02.22 01:44:01.236 4: CUL_Parse: CUL_0 A 0E 09 A010 2156E2 F11034 01000000002C -52
2014.02.22 01:44:01.298 4: CUL_send: CUL_0As 0A 09 8002 F11034 2156E2 00
2014.02.22 01:44:01.679 4: CUL_Parse: CUL_0 A 0E 09 A010 2156E2 F11034 01000000002C -52
2014.02.22 01:44:01.741 4: CUL_send: CUL_0As 0A 09 8002 F11034 2156E2 00
2014.02.22 01:44:02.123 4: CUL_Parse: CUL_0 A 0E 09 A010 2156E2 F11034 01000000002D -51.5
2014.02.22 01:44:02.185 4: CUL_send: CUL_0As 0A 09 8002 F11034 2156E2 00
2014.02.22 01:44:03.067 4: CUL_Parse: CUL_0 A 16 9D 8653 2156E5 000000 0041005942005743000244FFFEF6 -79
2014.02.22 01:44:15.051 4: CUL_Parse: CUL_0 A 16 31 8653 2157C8 000000 004100E04200C043002044FFE011 -65.5
WDS30: CMDs_done
WDS10: erst CMDs pending dann Status
internals
CUL_0_MSGCNT 4
CUL_0_RAWMSG A0C128670206B0700000000913E12
CUL_0_RSSI -65
CUL_0_TIME 2014-02-22 01:44:53
DEF 206B07
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 4
NR 297
STATE MISSING ACK
TYPE CUL_HM
lastMsg No:12 - t:70 s:206B07 d:000000 00913E
protCmdDel 3
protLastRcv 2014-02-22 01:44:53
protResnd 3 last_at:2014-02-22 01:42:02
protResndFail 1 last_at:2014-02-22 01:44:57
protSnd 4 last_at:2014-02-22 01:44:53
protState CMDs_done_Errors:1
rssi_at_CUL_0 avg:-64.87 min:-65 max:-64.5 lst:-65 cnt:4
Readings
Activity alive 2014-02-22 01:36:28
D-firmware 1.2 2014-02-16 17:40:09
D-serialNr KEQ0054137 2014-02-16 17:40:09
battery ok 2014-02-22 01:44:53
humidity 62 2014-02-22 01:44:53
PowerOn - 2014-02-22 00:59:07
recentStateType info 2014-02-22 00:59:07
state MISSING ACK 2014-02-22 01:44:57
temperature 14.5 2014-02-22 01:44:53
Ich hoffe das hilft und reicht. WDS10 scheint probleme zu machen?
Ich hab erst mal wieder umgestellt auf 0.
Gruß, Ansgar
Hallo Ansgar,
der WDS10 sollte beim temperatur senden aufwachen - was er aber nicht macht, reagiert nicht. Dass dies Batterie kostet ist seltsam, da es ja bedeuten wuerde, er reagiert - sendet aber keine message. Dennoch werde ich ihm das Attribut wakeup absprechen - geht ja nicht.
der WDS30 ist anders. Es ist wohl ein HM-WDS30-OT2-SM, kein HM-WDS30-T-O
kannst du hier ein getConfig durchfuehren, wenn du das neuste 00_CUL eingespielt hast (seit gestern um update)
Hier stimmt etwa mit dem Timing nicht.
Ich sehen im Log, dass 3 von 5 channels befragt wurden - es fehlen noch 2. Dann sollte FHEM alles gelesen haben und ruhe geben - der Log war also zu kurz.
Sind protokollfehler alarmiert worden?
Hallo Martin,
das update habe ich ausgeführt. Die low Battery Änderung und Temperaturinterpretation hast Du ja schon eingebaut. Super, vielen Dank! :)
Hier das neue Log vom WDS30-OT2:
IDs mit AutoReadReg 4:
WDS30-OT2 2156E2 ein GetConfig dabei
2014.02.22 11:52:29.811 4: CUL_Parse: CUL_0 A 16 9F 8653 2156E4 000000 0041008442005943002B44FFD5E8 -86
2014.02.22 11:52:32.604 4: CUL_Parse: CUL_0 A 0C 22 8670 206B07 000000 00BA332D -51.5
2014.02.22 11:52:42.199 4: CUL_Parse: CUL_0 A 0C 55 8670 206A4E 000000 00515314 -64
2014.02.22 11:53:14.999 4: CUL_Parse: CUL_0 A 0C 86 8670 2070A0 000000 00B63339 -45.5
2014.02.22 11:53:35.394 5: CUL_HM Eingang7b_ER protEvent:CMDs_pending pending:1
2014.02.22 11:53:35.398 5: CUL_HM Eingang7b_ER protEvent:CMDs_pending pending:2
2014.02.22 11:53:35.402 5: CUL_HM Eingang7b_ER protEvent:CMDs_pending pending:3
2014.02.22 11:53:35.405 5: CUL_HM Eingang7b_ER protEvent:CMDs_pending pending:4
2014.02.22 11:53:35.409 5: CUL_HM Eingang7b_ER protEvent:CMDs_pending pending:5
2014.02.22 11:53:35.412 5: CUL_HM Eingang7b_ER protEvent:CMDs_pending pending:6
2014.02.22 11:53:35.413 2: CUL_HM set Eingang7b_ER getConfig
2014.02.22 11:54:27.866 4: CUL_Parse: CUL_0 A 16 8E 8653 2156E5 000000 0041005742005643000144FFFFF3 -80.5
2014.02.22 11:54:34.594 4: CUL_Parse: CUL_0 A 0C 23 8670 206B07 000000 00BA332D -51.5
2014.02.22 11:54:37.733 4: CUL_Parse: CUL_0 A 16 23 8653 2157C8 000000 004100BF4200BC43000344FFFD11 -65.5
2014.02.22 11:54:58.756 4: CUL_Parse: CUL_0 A 16 79 8653 2156E2 000000 0041003942009343FFA644005A2E -51
2014.02.22 11:54:58.859 4: CUL_send: CUL_0As 09 01 A112 F11034 2156E2
2014.02.22 11:54:58.874 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:6
2014.02.22 11:54:59.051 4: CUL_Parse: CUL_0 A 0A 01 8002 2156E2 F11034 002D -51.5
2014.02.22 11:54:59.153 4: CUL_send: CUL_0As 10 02 A001 F11034 2156E2 00040000000000
2014.02.22 11:54:59.169 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:5
2014.02.22 11:54:59.319 4: CUL_Parse: CUL_0 A 1A 02 A010 2156E2 F11034 02010002010AF10B100C34110018001B032E -51
2014.02.22 11:54:59.421 4: CUL_send: CUL_0As 0A 02 8002 F11034 2156E2 00
2014.02.22 11:54:59.435 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:5
2014.02.22 11:54:59.437 5: CUL_HM Eingang7b_ER sent ACK:2
2014.02.22 11:54:59.575 4: CUL_Parse: CUL_0 A 0C 03 8010 2156E2 F11034 0200002D -51.5
2014.02.22 11:54:59.677 4: CUL_send: CUL_0As 0B 03 A001 F11034 2156E2 0103
2014.02.22 11:54:59.693 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:4
2014.02.22 11:54:59.856 4: CUL_Parse: CUL_0 A 0E 03 A010 2156E2 F11034 01000000002D -51.5
2014.02.22 11:54:59.958 4: CUL_send: CUL_0As 0A 03 8002 F11034 2156E2 00
2014.02.22 11:54:59.972 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:4
2014.02.22 11:54:59.974 5: CUL_HM Eingang7b_ER sent ACK:2
2014.02.22 11:54:59.977 4: CUL_send: CUL_0As 0B 04 A001 F11034 2156E2 0203
2014.02.22 11:54:59.993 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:3
2014.02.22 11:55:00.138 4: CUL_Parse: CUL_0 A 0E 04 A010 2156E2 F11034 01000000002D -51.5
2014.02.22 11:55:00.240 4: CUL_send: CUL_0As 0A 04 8002 F11034 2156E2 00
2014.02.22 11:55:00.255 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:3
2014.02.22 11:55:00.256 5: CUL_HM Eingang7b_ER sent ACK:2
2014.02.22 11:55:00.260 4: CUL_send: CUL_0As 0B 05 A001 F11034 2156E2 0303
2014.02.22 11:55:00.275 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:2
2014.02.22 11:55:00.421 4: CUL_Parse: CUL_0 A 0E 05 A010 2156E2 F11034 01000000002D -51.5
2014.02.22 11:55:00.523 4: CUL_send: CUL_0As 0A 05 8002 F11034 2156E2 00
2014.02.22 11:55:00.538 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:2
2014.02.22 11:55:00.539 5: CUL_HM Eingang7b_ER sent ACK:2
2014.02.22 11:55:00.543 4: CUL_send: CUL_0As 0B 06 A001 F11034 2156E2 0403
2014.02.22 11:55:00.558 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:1
2014.02.22 11:55:00.704 4: CUL_Parse: CUL_0 A 0E 06 A010 2156E2 F11034 01000000002D -51.5
2014.02.22 11:55:00.806 4: CUL_send: CUL_0As 0A 06 8002 F11034 2156E2 00
2014.02.22 11:55:00.821 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:1
2014.02.22 11:55:00.823 5: CUL_HM Eingang7b_ER sent ACK:2
2014.02.22 11:55:00.826 4: CUL_send: CUL_0As 0B 07 A001 F11034 2156E2 0503
2014.02.22 11:55:00.841 5: CUL_HM Eingang7b_ER protEvent:CMDs_processing... pending:0
2014.02.22 11:55:00.987 4: CUL_Parse: CUL_0 A 0E 07 A010 2156E2 F11034 01000000002D -51.5
2014.02.22 11:55:01.090 4: CUL_send: CUL_0As 0A 07 8002 F11034 2156E2 00
2014.02.22 11:55:01.104 5: CUL_HM Eingang7b_ER protEvent:CMDs_done
2014.02.22 11:55:01.105 5: CUL_HM Eingang7b_ER sent ACK:2
2014.02.22 11:55:04.366 4: CUL_Parse: CUL_0 A 16 A0 8653 2156E4 000000 0041008442005943002B44FFD5EC -84
2014.02.22 11:55:37.953 4: CUL_Parse: CUL_0 A 0C 56 8670 206A4E 000000 00515314 -64
2014.02.22 11:55:47.252 4: CUL_Parse: CUL_0 A 0C 87 8670 2070A0 000000 00B63439 -45.5
2014.02.22 11:57:04.983 4: CUL_Parse: CUL_0 A 16 24 8653 2157C8 000000 004100BF4200BC43000344FFFD11 -65.5
2014.02.22 11:57:17.117 4: CUL_Parse: CUL_0 A 16 8F 8653 2156E5 000000 0041005742005643000144FFFFF4 -80
2014.02.22 11:57:26.597 4: CUL_Parse: CUL_0 A 0C 24 8670 206B07 000000 00BA332E -51
2014.02.22 11:57:30.366 4: CUL_Parse: CUL_0 A 16 A1 8653 2156E4 000000 0041008442005943002B44FFD5EC -84
2014.02.22 11:57:36.005 4: CUL_Parse: CUL_0 A 16 7A 8653 2156E2 000000 0041003942009143FFA84400582D -51.5
2014.02.22 11:58:05.003 4: CUL_Parse: CUL_0 A 0C 88 8670 2070A0 000000 00B6343B -44.5
2014.02.22 11:58:19.206 4: CUL_Parse: CUL_0 A 0C 57 8670 206A4E 000000 00515315 -63.5
2014.02.22 11:59:17.734 4: CUL_Parse: CUL_0 A 16 25 8653 2157C8 000000 004100BF4200BC43000344FFFD11 -65.5
2014.02.22 11:59:41.867 4: CUL_Parse: CUL_0 A 16 A2 8653 2156E4 000000 0041008442005943002B44FFD5EA -85
2014.02.22 11:59:51.869 4: CUL_Parse: CUL_0 A 16 90 8653 2156E5 000000 0041005742005643000144FFFFF4 -80
2014.02.22 11:59:58.754 4: CUL_Parse: CUL_0 A 16 7B 8653 2156E2 000000 0041003742009143FFA644005A2D -51.5
2014.02.22 12:00:04.350 4: CUL_Parse: CUL_0 A 0C 25 8670 206B07 000000 00BA332F -50.5
2014.02.22 12:00:08.254 4: CUL_Parse: CUL_0 A 0C 89 8670 2070A0 000000 00B63439 -45.5
2014.02.22 12:00:46.209 4: CUL_Parse: CUL_0 A 0C 58 8670 206A4E 000000 00515314 -64
2014.02.22 12:02:07.254 4: CUL_Parse: CUL_0 A 16 7C 8653 2156E2 000000 0041003942009143FFA84400582D -51.5
2014.02.22 12:02:12.120 4: CUL_Parse: CUL_0 A 16 91 8653 2156E5 000000 0041005742005643000144FFFFF2 -81
2014.02.22 12:02:19.985 4: CUL_Parse: CUL_0 A 16 26 8653 2157C8 000000 004100BF4200BC43000344FFFD11 -65.5
2014.02.22 12:02:27.603 4: CUL_Parse: CUL_0 A 0C 26 8670 206B07 000000 00BA332F -50.5
2014.02.22 12:02:42.867 4: CUL_Parse: CUL_0 A 16 A3 8653 2156E4 000000 0041008442005943002B44FFD5EB -84.5
2014.02.22 12:03:01.257 4: CUL_Parse: CUL_0 A 0C 8A 8670 2070A0 000000 00B6343B -44.5
2014.02.22 12:04:18.121 4: CUL_Parse: CUL_0 A 16 92 8653 2156E5 000000 0041005742005643000144FFFFF4 -80
2014.02.22 12:04:36.355 4: CUL_Parse: CUL_0 A 0C 27 8670 206B07 000000 00BA332F -50.5
2014.02.22 12:05:05.252 4: CUL_Parse: CUL_0 A 16 7D 8653 2156E2 000000 0041003942009343FFA644005A2E -51
2014.02.22 12:05:07.736 4: CUL_Parse: CUL_0 A 16 27 8653 2157C8 000000 004100BF4200BC43000344FFFD11 -65.5
2014.02.22 12:05:29.617 4: CUL_Parse: CUL_0 A 16 A4 8653 2156E4 000000 0041008442005943002B44FFD5EA -85
2014.02.22 12:05:39.759 4: CUL_Parse: CUL_0 A 0C 8B 8670 2070A0 000000 00B6343A -45
2014.02.22 12:06:00.715 4: CUL_Parse: CUL_0 A 0C 5A 8670 206A4E 000000 00515315 -63.5
2014.02.22 12:07:13.622 4: CUL_Parse: CUL_0 A 16 93 8653 2156E5 000000 0041005742005643000144FFFFF2 -81
2014.02.22 12:07:34.858 4: CUL_Parse: CUL_0 A 0C 28 8670 206B07 000000 00BA3328 -54
2014.02.22 12:07:41.236 4: CUL_Parse: CUL_0 A 16 28 8653 2157C8 000000 004100BF4200BC43000344FFFD11 -65.5
2014.02.22 12:07:48.751 4: CUL_Parse: CUL_0 A 16 7E 8653 2156E2 000000 0041003942009343FFA644005A2D -51.5
2014.02.22 12:08:01.867 4: CUL_Parse: CUL_0 A 16 A5 8653 2156E4 000000 0041008442005943002B44FFD5EC -84
2014.02.22 12:08:03.761 4: CUL_Parse: CUL_0 A 0C 8C 8670 2070A0 000000 00B63439 -45.5
2014.02.22 12:08:48.219 4: CUL_Parse: CUL_0 A 0C 5B 8670 206A4E 000000 00515315 -63.5
2014.02.22 12:09:54.624 4: CUL_Parse: CUL_0 A 16 94 8653 2156E5 000000 0041005742005643000144FFFFF5 -79.5
2014.02.22 12:10:00.238 4: CUL_Parse: CUL_0 A 16 29 8653 2157C8 000000 004100BF4200BC43000344FFFD11 -65.5
2014.02.22 12:10:13.512 4: CUL_Parse: CUL_0 A 0C 8D 8670 2070A0 000000 00B63439 -45.5
2014.02.22 12:10:18.001 4: CUL_Parse: CUL_0 A 16 7F 8653 2156E2 000000 0041003942009143FFA84400582D -51.5
2014.02.22 12:10:18.862 4: CUL_Parse: CUL_0 A 0C 29 8670 206B07 000000 00BA3328 -54
2014.02.22 12:10:19.618 4: CUL_Parse: CUL_0 A 16 A6 8653 2156E4 000000 0041008442005943002B44FFD5EB -84.5
2014.02.22 12:12:04.739 4: CUL_Parse: CUL_0 A 16 2A 8653 2157C8 000000 004100BF4200BC43000344FFFD11 -65.5
2014.02.22 12:12:21.375 4: CUL_Parse: CUL_0 A 16 95 8653 2156E5 000000 0041005742005643000144FFFFF5 -79.5
2014.02.22 12:12:23.117 4: CUL_Parse: CUL_0 A 16 A7 8653 2156E4 000000 0041008442005943002B44FFD5EC -84
2014.02.22 12:12:32.750 4: CUL_Parse: CUL_0 A 16 80 8653 2156E2 000000 0041003942009343FFA644005A2D -51.5
2014.02.22 12:12:48.364 4: CUL_Parse: CUL_0 A 0C 2A 8670 206B07 000000 00BA3328 -54
2014.02.22 12:13:12.765 4: CUL_Parse: CUL_0 A 0C 8E 8670 2070A0 000000 00B63439 -45.5
Brauchst Du noch weiteres Logging?
Gruß, Ansgar.
Hallo Martin,
hier noch mal ein Log zum WDS-10, nachdem ich den Sensor neu gepaired habe. Vielleicht hat es da gehapert?
WDS10 206B07 ein GetConfig:
2014.02.22 15:56:25.508 5: CUL_HM Dusche7b protEvent:CMDs_pending pending:1
2014.02.22 15:56:25.511 5: CUL_HM Dusche7b protEvent:CMDs_pending pending:2
2014.02.22 15:56:25.513 2: CUL_HM set Dusche7b getConfig
2014.02.22 15:56:48.559 4: CUL_Parse: CUL_0 A 16 83 8653 2157C8 000000 004100B54200B243000344FFFD11 -65.5
2014.02.22 15:56:54.253 4: CUL_Parse: CUL_0 A 0C B5 8670 206A4E 000000 00505314 -64
2014.02.22 15:56:56.383 4: CUL_Parse: CUL_0 A 16 3B 8653 2156E2 000000 0041004442008E43FFB644004A1F -58.5
2014.02.22 15:57:45.987 4: CUL_Parse: CUL_0 A 16 EE 8653 2156E5 000000 0041005742005643000144FFFFF6 -79
2014.02.22 15:58:21.454 4: CUL_Parse: CUL_0 A 0C 09 8670 206B07 000000 00AF340F -66.5
2014.02.22 15:58:21.557 4: CUL_send: CUL_0As 09 01 A112 F11034 206B07
2014.02.22 15:58:21.571 5: CUL_HM Dusche7b protEvent:CMDs_processing... pending:2
2014.02.22 15:58:21.707 4: CUL_Parse: CUL_0 A 0A 01 8002 206B07 F11034 0010 -66
2014.02.22 15:58:21.809 4: CUL_send: CUL_0As 10 02 A001 F11034 206B07 00040000000000
2014.02.22 15:58:21.824 5: CUL_HM Dusche7b protEvent:CMDs_processing... pending:1
2014.02.22 15:58:21.973 4: CUL_Parse: CUL_0 A 1A 02 8010 206B07 F11034 020100020105000AF10B100C340F00000010 -66
2014.02.22 15:58:22.075 4: CUL_send: CUL_0As 0B 03 A001 F11034 206B07 0103
2014.02.22 15:58:22.089 5: CUL_HM Dusche7b protEvent:CMDs_processing... pending:0
2014.02.22 15:58:22.229 4: CUL_Parse: CUL_0 A 0E 03 A010 206B07 F11034 01000000000F -66.5
2014.02.22 15:58:22.332 4: CUL_send: CUL_0As 0A 03 8002 F11034 206B07 00
2014.02.22 15:58:22.344 5: CUL_HM Dusche7b protEvent:CMDs_done
2014.02.22 15:58:22.346 5: CUL_HM Dusche7b sent ACK:2
2014.02.22 15:58:32.624 4: CUL_Parse: CUL_0 A 16 00 8653 2156E4 000000 0041008442005B43002944FFD7EC -84
2014.02.22 15:59:00.685 4: CUL_Parse: CUL_0 A 0C E7 8670 2070A0 000000 00B53338 -46
2014.02.22 15:59:09.256 4: CUL_Parse: CUL_0 A 0C B6 8670 206A4E 000000 00505316 -63
2014.02.22 15:59:31.882 4: CUL_Parse: CUL_0 A 16 3C 8653 2156E2 000000 0041004442008E43FFB644004A1F -58.5
2014.02.22 15:59:39.061 4: CUL_Parse: CUL_0 A 16 84 8653 2157C8 000000 004100B54200B243000344FFFD10 -66
2014.02.22 15:59:54.488 4: CUL_Parse: CUL_0 A 16 EF 8653 2156E5 000000 0041005742005643000144FFFFF6 -79
2014.02.22 16:01:02.373 4: CUL_Parse: CUL_0 A 16 01 8653 2156E4 000000 0041008442005B43002944FFD7E9 -85.5
2014.02.22 16:01:04.458 4: CUL_Parse: CUL_0 A 0C 0A 8670 206B07 000000 00AF350E -67
2014.02.22 16:01:10.008 4: CUL_Parse: CUL_0 A 0C B7 8670 206A4E 000000 00505314 -64
2014.02.22 16:01:41.937 4: CUL_Parse: CUL_0 A 0C E8 8670 2070A0 000000 00B43337 -46.5
2014.02.22 16:01:52.884 4: CUL_Parse: CUL_0 A 16 3D 8653 2156E2 000000 0041004442008E43FFB644004A1F -58.5
2014.02.22 16:02:15.061 4: CUL_Parse: CUL_0 A 16 85 8653 2157C8 000000 004100B54200B043000544FFFB11 -65.5
Gruß, Ansgar.
Hallo Ansgar,
Das timing ist jetzt ok (wie erwartet).
Seltsam ist noch, dass beim WDS10 immer noch wakeup 'macht'. Hast du keinen kompletten update gemacht? oder war es noch nicht drin?
was steht in helper->rxt des WDS10?
Wenn es doch funktioniert ist es super und ich werden wieder zurückaendern.
Ich gehe schliesslich davon aus, dass ein autoReadReg keinen erhöhten Batterieverbrauch generiert. Nach einem Neustart wird einmal gelesen(maximal), dann ist schluss.
Ggf. kannst du es eine definierte Zeit laufen lassen (1 Tag) und die send-counter im Dervice (oder HMInfo) mit und ohne autoReadReg vergleichen.
Gruss Martin
Hallo Martin,
ich hatte update in der fhem Komandozeile eingegeben, nachdem Du es mir mitgeteilt hattest.
Bei dem WDS-10 Sensor steht in Helper->rxType 140 drin (Neustart definitv, sogar mehrmals). Ich nehme an, Du meinst das?!?
Auch beim WDS-30-OT2 Sensor steht da 140 drin.
Danke, dass Du mich indirekt auf das list Kommando aufmerksam gemacht hast. :)
Ich mach nochmal einen Update. Und probier mal weiter. -> Update sagt "Nothing to do..."
Ich habe noch eine schwache Idee zum erhöhten Energieverbrauch. Wird bei autoReadReg = 4 beim Neustart nicht automatisch ein getConfig ausgeführt? Bei häufigem Neustart von fhem, z.B. weil man Änderungen an Modulen testet ;), würde der auch häufig ausgeführt. Wenn das nicht recht klappt, wird das auch entsprechend häufig nochmal versucht.
Bei autoReadReg 0 wird getConfig nicht ausgeführt.
Gruß, Ansgar.
Hallo Ansgar,
der getConfig beim Restart wird nur gemacht, wenn die Register fehlen.
Register stehen in Readings und werden vom Kernal beim runterfahren oder save im statefile gespeichert. Beim Hochfahren werden die Werte wieder gelesen.
Nur wenn die Register nicht da sind wird gelesen.
Dass ein Lesen bei Reboot die Batterie erheblich belastet würde aber sehr viele reboots voraussetzen.
Das statefile ist nicht zuverlässig - kommt immer wieder vor, dass viel gelesen wird, nach reboot. Daher habe ich in HMInfo eine eigene Speicherung vorgesehen. Mit Archive kannst du gelesene Register werte automatisch speichern lassen. Beim Reboot kannst du dann aus dem File lesen lassen - und zwar nur, was nicht im statefile lag.
Ich würde daher immer autoReadReg 5 setzen und das archive des HMInfo einschalten.
Dann habe ich ein UserConfig, das nach Initialize ausgeführt wird. In dem kann ich ein loadConfig (HMInfo) vorsehen, in dem aus dem Archive die devices nachgeladen werden. Das nutze ich aber nur für ausgewählte Devices - kann man mit der filteroption einschränken.
Es ist nun einmal mein Ziel immer alle Configdaten in FHEM zu haben und das möglichst aktuell. Das ganze einfach zu handhaben und Performance-schonend.
Man kann auch alles abschalten
Gruss Martin
Hallo Martin,
nun, da meine Batterien immer noch Leben, obwohl ich bei allen Devices
das Attribut autoReadReg auf 5_readMissing
eingestellt habe, möchte ich eine positive Rückmeldung geben. Es funktioniert so, wie erwartet, ohne die Batterien leer zu saugen.
Das Löschen der fhem.save Datei habe ich mir damit auch abgewöhnt und entferne alte Leichen nun von Hand, um ein unerwünschtes erneutes Lesen der Register nicht auszulösen und die Batterien entsprechend zu schonen.
Mit meinem löschenden Nutzerverhalten konntest Du so nicht rechnen. ;)
Danke!
Ansgar.
Hi Ansgar,
vielleicht hast du schon HMInfo bemerkt. Ich will es noch etwas verbessern, aber aktuell kann ich in deinem Zusammenhang empfehlen
- autoArchieve einschalten
- nach FHEM-booten ein loadConfig zu starten.
Da sollten alle Register wieder gesetzt werden. Du solltest immer den letzten mit FHEM gelesenen stand der Register haben. Zusammen mit AutoReadReg 5 sollte es eine recht gute Abdeckung haben - register immer aktuell, so die Idee. Wirklich lesen nur sehr selten, aber bei jeder Änderung der Register.
Gruss Martin
Hallo Martin,
danke nochmal für den Hinweis auf HMInfo. Ich benutze es schon, um den gesammelten Status der Geräte zu sehen.
Das Archiv habe ich noch nicht benutzt, da ich auch noch damit kämpfe, dass die USB/seriell Verbindung zu meinem CUL und USB-WDE1 Empfänger gelegentlich auf dem Raspberry Pi auszusetzen scheint.
Und da wollte ich nicht zwingend notwendige periodische Zusatzlast erst mal vermeiden, da ich den Eindruck habe, dass ein wiederholter Neuaufbau von Web-Ansichten mit vielen Graphen das USB-Problem zu verschärfen scheint.
Bei den Sensoren sehe ich in den Graphen dann Datenaussetzer von bis zu 2 Stunden bei allen Sensoren. Erholt sich dann aber wieder?! Der USB-WDE1 meledet schon mal unmotivierte disconnects.
Mit dem Senden über den CUL an meinen Dimmer HM-LC-DIM2L-SM habe ich auch Sendeschwierigkeiten beobachtet, sprich es wird nichts gesendet.
Neustart FHEM hilft in allen Fällen.
Gruss, Ansgar.