FHEM Forum

Hallo leutz

Ich weis nicht ob ich mit dem Problem alleine da stehe, habe schon Stunden mit suchen sowohl im Netz als auch hier verbracht, aber keine Antwort gefunden.

meine HM-WDS30-OT2-SM Differenz Sensoren steigen immer wieder aus.

Es schaut so aus das ich Plötzlich keine werte mehr bekomme, und wenn ich an den HM-WDS30-OT2-SM gehe aufschraube und den Knopf drücke passiert gar nichts, erst wenn ich die Batterie entfernt habe eine gewisse zeit abwarte und die Batterien wieder einsetze Funktioniert der HM-WDS30-OT2-SM  wieder.

Ich habe auch 4 Stück Direkt mit Spannung aus dem Netzteil versorgt, hier kommt es auch sporadisch vor das mal einer ausfällt und keinen Mucks mehr macht, erst wenn ich Spannung trenne und wieder versorge geht der betreffende HM-WDS30-OT2-SM  wieder.

gibt es einen Trick ?
es liegt genügend Spannung an, mindestens 3 V , und nachdem die Spnnnung getrennt und wieder hergestellt wurde Funktionieren die ja auch wieder einwandfrei.

bin über jeden Tipp Dankbar, da die Sensoren an den unmöglichsten stellen sitzen muss ich bei jedem ausfall umständlich an die Sensoren.

viele Grüße

Hallo melveee, wie "alt" ist dein fhem? Ich hatte vor ca. einem Monat das Gleiche Problem mit den Diff. Temp. Sensoren (habe auch 3 Stk) im Einsatz. Ein update hat das Problem damals gelöst.

VG
Frank

wie alt ?
immer aktuell .... ich beobachte das ganze bereits paar monate , es ist lästig wenn man den dingern hinterher rennen muss .....wenn die Batterie zu schwach wir ok aber wenn Batterien ok sind und die einfach ausfallen ist das komisch.

PS: habe inzwischen 8 von den Dingern im Einsatz

Hallo melveee, probier es mal mit den 2 "alten" Dateien im Anhang. Damit habe ich keinerlei HM Probleme.

VG
Frank

Hallo
Danke
nur auf die schnelle weis ich nicht wohin damit, bin nicht so tief in Fhem drin, werde mich damit sofern ich heute noch zeit finde beschäftigen.

Auf einem "normalen" Linux System (nicht auf der Fritte) kommen die nach /opt/fhem/FHEM

VG
Frank

oki , werde das mal versuchen, habe einen banana am laufen

wenn ich die drüber bügel, werden die ja aber dann beim nächsten mal wenn ich update mache wieder ersetzt oder ?

normal sollte es ja eben da ich den neuesten stand bzw. updates drin habe ohne mucken funktionieren?

Das soll nur ein Test sein, beim nächsten update werden die wieder überschrieben, wenn du sie nicht vom update ausschließt.

P.S. bei mir funktioniert der Diff. Temp. Sensor nach einem update jetzt auch völlig fehlerfrei!

VG
Frank

Ja Funktionieren tut er ja auch einwandfrei
nur das der ein oder andere hier und da ausfällt, eventuell hängt es mit einem shutdown zusammen, bzw. wenn der HMLAN Overload hat wenn ich mal was teste dann schalte ich den mit einer FS20 für 10 Sekunden aus danach sofort wieder an, vielleicht mögen die HM-WDS30-OT2-SM das nicht besonders.

Es ist nur komisch das die dann keinen Mucks machen also selbst wenn ich vor ort den taster betätige tut die LED nichts, nur nach herrausnehmen der Batterien für mehrere Sekunden hilft, danach läuft er wieder ohne Probleme.

vielen Dank

Hallo zusammen,
hat sich hier eine Lösung ergeben?
Ich habe diese Woche den ersten HM-WDS30-OT2-SM im Einsatz, der zeigt exakt das gleiche Verhalten.
Das erste Anlernen hat sofort geklappt, aber irgendwann ist der Sensor scheinbar tot.
Aufschrauben, Taster drücken - nix.
Device in fhem löschen -> Batterie raus-rein -> neu anlernen -> alles gut.
Irgendwann wieder tot.

Gruß Roland

batterie rein raus verstehe ich. neu anlernen nicht. muss das sein oder geht es einfach so?
die Batterien sind sicher ok - oder?

kannst du einmal die rohmessages aufzeichnen? Vielleicht ist etwas zu sehen.

Hallo Martin,
neu anlernen muß nicht sein, es geht auch mit Batterie raus-rein. Neu anlernen habe ich gemacht wegen: http://forum.fhem.de/index.php/topic,37750.msg305769.html#msg305769 (http://forum.fhem.de/index.php/topic,37750.msg305769.html#msg305769)
... Batterien sind ok.
Heute habe ich ein paar mal Batterie raus-rein gemacht, momentan (seit ein paar Stunden) meldet er fleißig die Temperaturen.
Erklärung habe ich noch nicht, warum's jetzt geht, ich beobachte.

Viele Grüße
Roland

rohmesages nicht vergessen. Nicht, dass FHEM"heimlich" etwas sendet

Wie schon im ähnlichen Thread http://forum.fhem.de/index.php/topic,28168.0.html (http://forum.fhem.de/index.php/topic,28168.0.html) geschrieben vermute ich dass des Sendemodul zu hoch eingelötet ist und beim Zuschrauben des Deckels unter Druck gesetzt wird.
Solange das Gehäuse offen ist, läuft mein Sensor, wenn ich die Schrauben vorsichtig zudrehe, spüre ich einen Widerstand, wenn noch ca 1/2mm Spalt ist.
Ziehe ich sie etwas fester an, fällt der Sensor nach kurzer Zeit aus.
Jetzt habe ich gerade den Test laufen, ob bei ganz vorsichtig angezogenen Schrauben der Sensor stabil läuft.
Da ich ihn im Keller einsetze, macht es mir nichts, wenn er nicht ganz dicht ist.

Chipmunk

Sorry wegen der ausgebliebenen Rohmessages, ich war unterwegs....
Seit Samstag läuft er ohne Probleme, da macht die Aufzeichnung der Rohmessages wahrscheinlich keinen Sinn?
Ich habe außer mehrfach Batterien raus-rein (fast) nix gemacht, was den Umschwung "geht nicht" - "geht" erklären könnte.
Allerdings: Ich habe dann nachträglich bei ELV http://www.elv.de/temperatursensor-103at-2b-mit-kabel-mas10401.html (http://www.elv.de/temperatursensor-103at-2b-mit-kabel-mas10401.html) gelesen, daß der Temperatursensor doch nicht für das dauerhafte Eintauchen in Wasser geeignet ist. Ich meine, irgendwo mal das Gegenteil gelesen zu haben. Ich wollte damit eine Notabschaltung für die Aquarienheizung bauen.
Ich habe dem Temperatursensor nun einen anderen Zweck verpaßt, wo die Sensoren trocken liegen.
Ich kann mir aber nicht so recht vorstellen, daß DAS die Ursache war. Der Sensor ist nix anderes als ein Thermistor. Sollte in die Kapsel Wasser eindringen, ändert das zwar den elektrischen Widerstand und führt vielleicht zu Fehlmessungen, aber sollte das Funkmodul eigentlich unbeeindruckt lassen, oder?
Das Funkmodul habe ich bei mir mit reichlich Überstand eingelötet, das Metallgehäuse liegt fast auf der großen Platine auf.
Meiner hat anfangs auch im aufgeschraubten Zustand gezickt. Aber trotzdem gut zu wissen für meinen zweiten, der noch nicht zusammengebaut ist.

Gruß Roland

Hallo an alle,
ich möchte dieses Thema wieder aufgreifen. ich vermute der Ausfall des Sensors hängt mit dem Senden eines Befehls an den Sensor zusammen. Daher auch das Thema Sensorausfall nach Übertragung von nur einem Messwert. Falls ein Kommando ansteht und der Sensor tot ist, wird dieses nach dem Aufwecken durch Entfernen der Batterie gleich nach dem Senden des ersten Messwertes übermittelt. Dabei hängt sich der Temperatursensor wieder auf. Ein Recovery ist in der Firmware nicht enthalten. Stehen keine Kommandos an sendet der Sensor nach dem Trick mit der Batterie munter einen Wert nach dem anderen. Die Probleme habe ich beim Restart von Fhem und anstehenden Kommandos an den Temperatursensor beobachtet.
Frage: Wie und welche Kommandos werden an den Sensor übertragen und wie verarbeitet er diese.

Ich hoffe ein Experte greift dieses Thema auf.
Gruß

ZitatDie Probleme habe ich beim Restart von Fhem

Logge die RohMessage nach restart fhem
1.Beitag
http://forum.fhem.de/index.php/topic,16563.0.html (http://forum.fhem.de/index.php/topic,16563.0.html)

Wurden diese Art Probleme nicht unlängst durch Ändern von autoReadReg auf 0_off gelöst?

Das ging ja super schnell.
Der Tip mit autoReadReg scheint beim Restart zu helfen. Danach habe ich ein "set get config" abgesetzt. 6 pending commands. Nach dem Senden des nächsten Temp-Werts wurde 1 Kommando sauber abgearbeitet "Commandaccepted yes". Dann hat sich der Sensor wieder aufgehängt.
Anbei das Logfile:

2016.01.12 20:12:31.705 1: HMLAN_Parse: hmusb new condition ok
2016.01.12 20:25:27.685 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:76045DE1 d:FF r:FFB9     m:02 8653 374131 000000 0041001342001543FFFE440002
2016.01.12 20:25:33.270 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:25:33.287 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760473DA IDcnt:000B L:0 %
2016.01.12 20:25:47.500 0: HMLAN_Send:  hmusb I:+374131,02,01,00
2016.01.12 20:25:55.881 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:7604CC0F d:FF r:FFBD     m:E4 8610 2E8BA0 000000 0AB4F40E1600
2016.01.12 20:25:58.276 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:25:58.314 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7604D584 IDcnt:000B L:0 %
2016.01.12 20:26:23.296 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:26:23.310 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7605373E IDcnt:000B L:0 %
2016.01.12 20:26:48.301 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:26:48.336 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760598EC IDcnt:000B L:0 %
2016.01.12 20:27:13.313 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:27:13.365 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7605FAA0 IDcnt:000B L:0 %
2016.01.12 20:27:33.429 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:760648F2 d:FF r:FFC4     m:22 8610 2E8BBA 000000 0AB4F40E1A00
2016.01.12 20:27:38.319 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:27:38.359 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76065C4D IDcnt:000B L:0 %
2016.01.12 20:27:42.686 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:76066D38 d:FF r:FFB7     m:03 8653 374131 000000 02016.01.12 20:12:31.705 1: HMLAN_Parse: hmusb new condition ok
2016.01.12 20:25:27.685 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:76045DE1 d:FF r:FFB9     m:02 8653 374131 000000 0041001342001543FFFE440002
2016.01.12 20:25:33.270 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:25:33.287 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760473DA IDcnt:000B L:0 %
2016.01.12 20:25:47.500 0: HMLAN_Send:  hmusb I:+374131,02,01,00
2016.01.12 20:25:55.881 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:7604CC0F d:FF r:FFBD     m:E4 8610 2E8BA0 000000 0AB4F40E1600
2016.01.12 20:25:58.276 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:25:58.314 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7604D584 IDcnt:000B L:0 %
2016.01.12 20:26:23.296 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:26:23.310 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7605373E IDcnt:000B L:0 %
2016.01.12 20:26:48.301 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:26:48.336 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760598EC IDcnt:000B L:0 %
2016.01.12 20:27:13.313 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:27:13.365 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7605FAA0 IDcnt:000B L:0 %
2016.01.12 20:27:33.429 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:760648F2 d:FF r:FFC4     m:22 8610 2E8BBA 000000 0AB4F40E1A00
2016.01.12 20:27:38.319 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:27:38.359 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76065C4D IDcnt:000B L:0 %
2016.01.12 20:27:42.686 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:76066D38 d:FF r:FFB7     m:03 8653 374131 000000 0041001342001543FFFE440002
2016.01.12 20:27:42.770 0: HMLAN_Send:  hmusb S:S374EE3C1 stat:  00 t:00000000 d:01 r:374EE3C1 m:03 A112 117BAC 374131
2016.01.12 20:27:43.002 0: HMLAN_Parse: hmusb R:R374410A1 stat:0081 t:76066E2E d:FF r:FFB7     m:03 8002 374131 117BAC 00
2016.01.12 20:27:43.026 0: HMLAN_Send:  hmusb S:S374EE502 stat:  00 t:00000000 d:01 r:374EE502 m:04 A001 117BAC 374131 00040000000000
2016.01.12 20:27:43.030 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:27:43.354 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76066ED2 IDcnt:000B L:0 %
2016.01.12 20:27:43.387 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76066ED2 IDcnt:000B L:0 %
2016.01.12 20:27:43.413 0: HMLAN_Parse: hmusb R:R374EE502 stat:0001 t:76066EE2 d:FF r:FFB6     m:03 8002 374131 117BAC 00
2016.01.12 20:27:43.428 0: HMLAN_Parse: hmusb R:R374EE3C1 stat:0001 t:76066FAB d:FF r:FFB7     m:03 8002 374131 117BAC 00
2016.01.12 20:28:08.034 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:28:08.058 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7606D060 IDcnt:000B L:0 %
2016.01.12 20:28:33.038 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:28:33.054 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7607320B IDcnt:000B L:0 %
2016.01.12 20:28:48.203 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:76076CE8 d:FF r:FFBE     m:E5 8610 2E8BA0 000000 0AB4F50E1600
2016.01.12 20:28:58.044 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:28:58.081 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760793B8 IDcnt:000B L:0 %
2016.01.12 20:29:23.063 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:29:23.077 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7607F574 IDcnt:000B L:0 %
2016.01.12 20:29:48.069 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:29:48.103 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76085721 IDcnt:000B L:0 %
2016.01.12 20:30:05.385 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:76089AB2 d:FF r:FFC4     m:23 8610 2E8BBA 000000 0AB4F30E1A00
2016.01.12 20:30:13.079 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:30:13.098 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7608B8D2 IDcnt:000B L:0 %
2016.01.12 20:30:38.085 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:30:38.126 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76091A80 IDcnt:000B L:0 %
2016.01.12 20:31:03.090 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:31:03.121 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76097C2D IDcnt:000B L:0 %
2016.01.12 20:31:25.875 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:7609D51B d:FF r:FFBE     m:E6 8610 2E8BA0 000000 0AB4F70E1600
2016.01.12 20:31:28.097 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:31:28.115 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7609DDDB IDcnt:000B L:0 %
2016.01.12 20:31:53.115 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:31:53.143 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760A3F95 IDcnt:000B L:0 %
2016.01.12 20:32:18.125 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:32:18.139 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760AA146 IDcnt:000B L:0 %
2016.01.12 20:32:23.162 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:760AB4C8 d:FF r:FFC3     m:24 8610 2E8BBA 000000 0AB4F20E1A00
2016.01.12 20:32:43.131 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:32:43.165 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760B02F3 IDcnt:000B L:0 %
2016.01.12 20:33:06.175 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760B5CD5 d:FF r:FFB1     m:80 A410 374131 117BAC 06000000
2016.01.12 20:33:08.134 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:33:08.160 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760B649E IDcnt:000B L:0 %
2016.01.12 20:33:33.154 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:33:33.187 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760BC659 IDcnt:000B L:0 %
2016.01.12 20:33:49.157 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:760C04AC d:FF r:FFBE     m:E7 8610 2E8BA0 000000 0AB4F80E1600
2016.01.12 20:33:58.167 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:33:58.182 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760C280F IDcnt:000B L:0 %
2016.01.12 20:34:23.170 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:34:23.209 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760C89B9 IDcnt:000B L:0 %
2016.01.12 20:34:26.410 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:760C963B d:FF r:FFC2     m:25 8610 2E8BBA 000000 0AB4F20E1A00
2016.01.12 20:34:48.185 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:34:48.205 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760CEB71 IDcnt:000B L:0 %
2016.01.12 20:35:13.194 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:35:13.232 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760D4D21 IDcnt:000B L:0 %
2016.01.12 20:35:38.198 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:35:38.227 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760DAECC IDcnt:000B L:0 %
2016.01.12 20:35:48.884 0: HMLAN_Parse: hmusb R:E282518   stat:0000 t:760DD85E d:FF r:FFA6     m:45 A641 282518 117BAC 012000
2016.01.12 20:35:48.958 0: HMLAN_Send:  hmusb S:S37564EF9 stat:  00 t:00000000 d:01 r:37564EF9 m:45 8002 117BAC 282518 0101C800
2016.01.12 20:35:49.268 0: HMLAN_Parse: hmusb R:R37564EF9 stat:0002 t:00000000 d:FF r:7FFF     m:45 8002 117BAC 282518 0101C800
2016.01.12 20:35:53.492 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DEA5B d:FF r:FFB8     m:01 8653 374131 000000 0041001142001343FFFE440002
2016.01.12 20:35:53.564 0: HMLAN_Send:  hmusb S:S375660F5 stat:  00 t:00000000 d:01 r:375660F5 m:81 A112 117BAC 374131
2016.01.12 20:35:53.798 0: HMLAN_Parse: hmusb R:R37564EF9 stat:0081 t:760DEB51 d:FF r:FFB8     m:01 8002 374131 117BAC 00
2016.01.12 20:35:53.909 0: HMLAN_Parse: hmusb R:R375660F5 stat:0001 t:760DEC05 d:FF r:FFB7     m:81 8002 374131 117BAC 00
2016.01.12 20:35:53.991 0: HMLAN_Send:  hmusb S:S37566297 stat:  00 t:00000000 d:01 r:37566297 m:82 A001 117BAC 374131 00040000000000
2016.01.12 20:35:54.197 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DED1E d:FF r:FFB7     m:82 A010 374131 117BAC 02010002010A110B7B0CAC110018001B03
2016.01.12 20:35:54.292 0: HMLAN_Parse: hmusb R:R37566297 stat:0001 t:760DED23 d:FF r:FFB7     m:82 A010 374131 117BAC 02010002010A110B7B0CAC110018001B03
2016.01.12 20:35:54.421 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DEE13 d:FF r:FFB7     m:83 8010 374131 117BAC 020000
2016.01.12 20:35:54.517 0: HMLAN_Send:  hmusb S:S375664A8 stat:  00 t:00000000 d:01 r:375664A8 m:84 A001 117BAC 374131 0103
2016.01.12 20:35:54.708 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DEF21 d:FF r:FFB8     m:84 A010 374131 117BAC 0100000000
2016.01.12 20:35:54.805 0: HMLAN_Parse: hmusb R:R375664A8 stat:0001 t:760DEF26 d:FF r:FFB8     m:84 A010 374131 117BAC 0100000000
2016.01.12 20:35:54.821 0: HMLAN_Send:  hmusb S:S37566615 stat:  00 t:00000000 d:01 r:37566615 m:85 A001 117BAC 374131 0203
2016.01.12 20:35:55.220 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DF129 d:FF r:FFB8     m:85 A010 374131 117BAC 0100000000
2016.01.12 20:35:55.352 0: HMLAN_Parse: hmusb R:R37566615 stat:0001 t:760DF12E d:FF r:FFB8     m:85 A010 374131 117BAC 0100000000
2016.01.12 20:35:55.368 0: HMLAN_Send:  hmusb S:S37566838 stat:  00 t:00000000 d:01 r:37566838 m:86 A001 117BAC 374131 0303
2016.01.12 20:35:55.732 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DF331 d:FF r:FFB7     m:86 A010 374131 117BAC 0100000000
2016.01.12 20:35:55.864 0: HMLAN_Parse: hmusb R:R37566838 stat:0001 t:760DF336 d:FF r:FFB7     m:86 A010 374131 117BAC 0100000000
2016.01.12 20:35:55.880 0: HMLAN_Send:  hmusb S:S37566A38 stat:  00 t:00000000 d:01 r:37566A38 m:87 A001 117BAC 374131 0403
2016.01.12 20:35:56.277 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DF539 d:FF r:FFB8     m:87 A010 374131 117BAC 0100000000
2016.01.12 20:35:56.373 0: HMLAN_Parse: hmusb R:R37566A38 stat:0001 t:760DF53E d:FF r:FFB8     m:87 A010 374131 117BAC 0100000000
2016.01.12 20:35:56.390 0: HMLAN_Send:  hmusb S:S37566C35 stat:  00 t:00000000 d:01 r:37566C35 m:88 A001 117BAC 374131 0503
2016.01.12 20:35:56.789 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DF741 d:FF r:FFB8     m:88 A010 374131 117BAC 0100000000
2016.01.12 20:35:56.810 0: HMLAN_Send:  hmusb I:+374131,00,01,00
2016.01.12 20:35:56.885 0: HMLAN_Parse: hmusb R:R37566C35 stat:0001 t:760DF746 d:FF r:FFB8     m:88 A010 374131 117BAC 0100000000
2016.01.12 20:35:58.133 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:760DFC93 d:FF r:FFB7     m:E8 8610 2E8BA0 000000 0AB4FB0E1600
2016.01.12 20:36:03.203 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:36:03.222 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760E107A IDcnt:000B L:0 %
2016.01.12 20:36:28.208 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:36:28.218 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760E7226 IDcnt:000B L:0 %
2016.01.12 20:36:53.228 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:36:53.245 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760ED3E2 IDcnt:000B L:0 %
2016.01.12 20:37:18.239 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:37:18.271 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760F3595 IDcnt:000B L:0 %
2016.01.12 20:37:19.167 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:760F3909 d:FF r:FFC3     m:26 8610 2E8BBA 000000 0AB4F20E1A00
2016.01.12 20:37:43.244 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:37:43.268 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760F9741 IDcnt:000B L:0 %
2016.01.12 20:38:08.247 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:38:08.263 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760FF8ED IDcnt:000B L:0 %
2016.01.12 20:38:33.269 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:38:33.289 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76105AA9 IDcnt:000B L:0 %
2016.01.12 20:38:56.651 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:7610B5D5 d:FF r:FFC0     m:E9 8610 2E8BA0 000000 0AB4FC0E0E00
2016.01.12 20:38:58.275 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:38:58.445 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7610BCDD IDcnt:000B L:0 %
2016.01.12 20:39:23.283 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:39:23.311 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76111E07 IDcnt:000B L:0 %
2016.01.12 20:39:48.288 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:39:48.307 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76117FB4 IDcnt:000B L:0 %
2016.01.12 20:39:57.651 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:7611A42D d:FF r:FFC3     m:27 8610 2E8BBA 000000 0AB4F30E1A00
2016.01.12 20:40:13.294 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:40:13.334 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7611E160 IDcnt:000B L:0 %
2016.01.12 20:40:38.299 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:40:38.330 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7612430D IDcnt:000B L:0 %
2016.01.12 20:41:03.314 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:41:03.326 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7612A4C5 IDcnt:000B L:0 %
2016.01.12 20:41:28.324 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:41:28.351 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76130676 IDcnt:000B L:0 %
041001342001543FFFE440002
2016.01.12 20:27:42.770 0: HMLAN_Send:  hmusb S:S374EE3C1 stat:  00 t:00000000 d:01 r:374EE3C1 m:03 A112 117BAC 374131
2016.01.12 20:27:43.002 0: HMLAN_Parse: hmusb R:R374410A1 stat:0081 t:76066E2E d:FF r:FFB7     m:03 8002 374131 117BAC 00
2016.01.12 20:27:43.026 0: HMLAN_Send:  hmusb S:S374EE502 stat:  00 t:00000000 d:01 r:374EE502 m:04 A001 117BAC 374131 00040000000000
2016.01.12 20:27:43.030 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:27:43.354 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76066ED2 IDcnt:000B L:0 %
2016.01.12 20:27:43.387 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76066ED2 IDcnt:000B L:0 %
2016.01.12 20:27:43.413 0: HMLAN_Parse: hmusb R:R374EE502 stat:0001 t:76066EE2 d:FF r:FFB6     m:03 8002 374131 117BAC 00
2016.01.12 20:27:43.428 0: HMLAN_Parse: hmusb R:R374EE3C1 stat:0001 t:76066FAB d:FF r:FFB7     m:03 8002 374131 117BAC 00
2016.01.12 20:28:08.034 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:28:08.058 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7606D060 IDcnt:000B L:0 %
2016.01.12 20:28:33.038 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:28:33.054 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7607320B IDcnt:000B L:0 %
2016.01.12 20:28:48.203 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:76076CE8 d:FF r:FFBE     m:E5 8610 2E8BA0 000000 0AB4F50E1600
2016.01.12 20:28:58.044 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:28:58.081 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760793B8 IDcnt:000B L:0 %
2016.01.12 20:29:23.063 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:29:23.077 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7607F574 IDcnt:000B L:0 %
2016.01.12 20:29:48.069 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:29:48.103 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76085721 IDcnt:000B L:0 %
2016.01.12 20:30:05.385 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:76089AB2 d:FF r:FFC4     m:23 8610 2E8BBA 000000 0AB4F30E1A00
2016.01.12 20:30:13.079 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:30:13.098 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7608B8D2 IDcnt:000B L:0 %
2016.01.12 20:30:38.085 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:30:38.126 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76091A80 IDcnt:000B L:0 %
2016.01.12 20:31:03.090 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:31:03.121 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76097C2D IDcnt:000B L:0 %
2016.01.12 20:31:25.875 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:7609D51B d:FF r:FFBE     m:E6 8610 2E8BA0 000000 0AB4F70E1600
2016.01.12 20:31:28.097 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:31:28.115 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7609DDDB IDcnt:000B L:0 %
2016.01.12 20:31:53.115 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:31:53.143 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760A3F95 IDcnt:000B L:0 %
2016.01.12 20:32:18.125 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:32:18.139 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760AA146 IDcnt:000B L:0 %
2016.01.12 20:32:23.162 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:760AB4C8 d:FF r:FFC3     m:24 8610 2E8BBA 000000 0AB4F20E1A00
2016.01.12 20:32:43.131 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:32:43.165 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760B02F3 IDcnt:000B L:0 %
2016.01.12 20:33:06.175 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760B5CD5 d:FF r:FFB1     m:80 A410 374131 117BAC 06000000
2016.01.12 20:33:08.134 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:33:08.160 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760B649E IDcnt:000B L:0 %
2016.01.12 20:33:33.154 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:33:33.187 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760BC659 IDcnt:000B L:0 %
2016.01.12 20:33:49.157 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:760C04AC d:FF r:FFBE     m:E7 8610 2E8BA0 000000 0AB4F80E1600
2016.01.12 20:33:58.167 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:33:58.182 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760C280F IDcnt:000B L:0 %
2016.01.12 20:34:23.170 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:34:23.209 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760C89B9 IDcnt:000B L:0 %
2016.01.12 20:34:26.410 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:760C963B d:FF r:FFC2     m:25 8610 2E8BBA 000000 0AB4F20E1A00
2016.01.12 20:34:48.185 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:34:48.205 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760CEB71 IDcnt:000B L:0 %
2016.01.12 20:35:13.194 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:35:13.232 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760D4D21 IDcnt:000B L:0 %
2016.01.12 20:35:38.198 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:35:38.227 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760DAECC IDcnt:000B L:0 %
2016.01.12 20:35:48.884 0: HMLAN_Parse: hmusb R:E282518   stat:0000 t:760DD85E d:FF r:FFA6     m:45 A641 282518 117BAC 012000
2016.01.12 20:35:48.958 0: HMLAN_Send:  hmusb S:S37564EF9 stat:  00 t:00000000 d:01 r:37564EF9 m:45 8002 117BAC 282518 0101C800
2016.01.12 20:35:49.268 0: HMLAN_Parse: hmusb R:R37564EF9 stat:0002 t:00000000 d:FF r:7FFF     m:45 8002 117BAC 282518 0101C800
2016.01.12 20:35:53.492 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DEA5B d:FF r:FFB8     m:01 8653 374131 000000 0041001142001343FFFE440002
2016.01.12 20:35:53.564 0: HMLAN_Send:  hmusb S:S375660F5 stat:  00 t:00000000 d:01 r:375660F5 m:81 A112 117BAC 374131
2016.01.12 20:35:53.798 0: HMLAN_Parse: hmusb R:R37564EF9 stat:0081 t:760DEB51 d:FF r:FFB8     m:01 8002 374131 117BAC 00
2016.01.12 20:35:53.909 0: HMLAN_Parse: hmusb R:R375660F5 stat:0001 t:760DEC05 d:FF r:FFB7     m:81 8002 374131 117BAC 00
2016.01.12 20:35:53.991 0: HMLAN_Send:  hmusb S:S37566297 stat:  00 t:00000000 d:01 r:37566297 m:82 A001 117BAC 374131 00040000000000
2016.01.12 20:35:54.197 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DED1E d:FF r:FFB7     m:82 A010 374131 117BAC 02010002010A110B7B0CAC110018001B03
2016.01.12 20:35:54.292 0: HMLAN_Parse: hmusb R:R37566297 stat:0001 t:760DED23 d:FF r:FFB7     m:82 A010 374131 117BAC 02010002010A110B7B0CAC110018001B03
2016.01.12 20:35:54.421 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DEE13 d:FF r:FFB7     m:83 8010 374131 117BAC 020000
2016.01.12 20:35:54.517 0: HMLAN_Send:  hmusb S:S375664A8 stat:  00 t:00000000 d:01 r:375664A8 m:84 A001 117BAC 374131 0103
2016.01.12 20:35:54.708 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DEF21 d:FF r:FFB8     m:84 A010 374131 117BAC 0100000000
2016.01.12 20:35:54.805 0: HMLAN_Parse: hmusb R:R375664A8 stat:0001 t:760DEF26 d:FF r:FFB8     m:84 A010 374131 117BAC 0100000000
2016.01.12 20:35:54.821 0: HMLAN_Send:  hmusb S:S37566615 stat:  00 t:00000000 d:01 r:37566615 m:85 A001 117BAC 374131 0203
2016.01.12 20:35:55.220 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DF129 d:FF r:FFB8     m:85 A010 374131 117BAC 0100000000
2016.01.12 20:35:55.352 0: HMLAN_Parse: hmusb R:R37566615 stat:0001 t:760DF12E d:FF r:FFB8     m:85 A010 374131 117BAC 0100000000
2016.01.12 20:35:55.368 0: HMLAN_Send:  hmusb S:S37566838 stat:  00 t:00000000 d:01 r:37566838 m:86 A001 117BAC 374131 0303
2016.01.12 20:35:55.732 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DF331 d:FF r:FFB7     m:86 A010 374131 117BAC 0100000000
2016.01.12 20:35:55.864 0: HMLAN_Parse: hmusb R:R37566838 stat:0001 t:760DF336 d:FF r:FFB7     m:86 A010 374131 117BAC 0100000000
2016.01.12 20:35:55.880 0: HMLAN_Send:  hmusb S:S37566A38 stat:  00 t:00000000 d:01 r:37566A38 m:87 A001 117BAC 374131 0403
2016.01.12 20:35:56.277 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DF539 d:FF r:FFB8     m:87 A010 374131 117BAC 0100000000
2016.01.12 20:35:56.373 0: HMLAN_Parse: hmusb R:R37566A38 stat:0001 t:760DF53E d:FF r:FFB8     m:87 A010 374131 117BAC 0100000000
2016.01.12 20:35:56.390 0: HMLAN_Send:  hmusb S:S37566C35 stat:  00 t:00000000 d:01 r:37566C35 m:88 A001 117BAC 374131 0503
2016.01.12 20:35:56.789 0: HMLAN_Parse: hmusb R:E374131   stat:0000 t:760DF741 d:FF r:FFB8     m:88 A010 374131 117BAC 0100000000
2016.01.12 20:35:56.810 0: HMLAN_Send:  hmusb I:+374131,00,01,00
2016.01.12 20:35:56.885 0: HMLAN_Parse: hmusb R:R37566C35 stat:0001 t:760DF746 d:FF r:FFB8     m:88 A010 374131 117BAC 0100000000
2016.01.12 20:35:58.133 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:760DFC93 d:FF r:FFB7     m:E8 8610 2E8BA0 000000 0AB4FB0E1600
2016.01.12 20:36:03.203 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:36:03.222 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760E107A IDcnt:000B L:0 %
2016.01.12 20:36:28.208 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:36:28.218 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760E7226 IDcnt:000B L:0 %
2016.01.12 20:36:53.228 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:36:53.245 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760ED3E2 IDcnt:000B L:0 %
2016.01.12 20:37:18.239 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:37:18.271 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760F3595 IDcnt:000B L:0 %
2016.01.12 20:37:19.167 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:760F3909 d:FF r:FFC3     m:26 8610 2E8BBA 000000 0AB4F20E1A00
2016.01.12 20:37:43.244 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:37:43.268 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760F9741 IDcnt:000B L:0 %
2016.01.12 20:38:08.247 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:38:08.263 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:760FF8ED IDcnt:000B L:0 %
2016.01.12 20:38:33.269 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:38:33.289 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76105AA9 IDcnt:000B L:0 %
2016.01.12 20:38:56.651 0: HMLAN_Parse: hmusb R:E2E8BA0   stat:0000 t:7610B5D5 d:FF r:FFC0     m:E9 8610 2E8BA0 000000 0AB4FC0E0E00
2016.01.12 20:38:58.275 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:38:58.445 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7610BCDD IDcnt:000B L:0 %
2016.01.12 20:39:23.283 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:39:23.311 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76111E07 IDcnt:000B L:0 %
2016.01.12 20:39:48.288 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:39:48.307 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76117FB4 IDcnt:000B L:0 %
2016.01.12 20:39:57.651 0: HMLAN_Parse: hmusb R:E2E8BBA   stat:0000 t:7611A42D d:FF r:FFC3     m:27 8610 2E8BBA 000000 0AB4F30E1A00
2016.01.12 20:40:13.294 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:40:13.334 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7611E160 IDcnt:000B L:0 %
2016.01.12 20:40:38.299 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:40:38.330 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7612430D IDcnt:000B L:0 %
2016.01.12 20:41:03.314 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:41:03.326 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:7612A4C5 IDcnt:000B L:0 %
2016.01.12 20:41:28.324 0: HMLAN_Send:  hmusb I:K
2016.01.12 20:41:28.351 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110644 d:263683 O:117BAC t:76130676 IDcnt:000B L:0 %



Gruß

Hallo,

ich bin Anfänger - sowohl bei fhem als auch in diesem Forum.
Daher zunächst einmal vielen Dank an alle Aktiven, die uns Nutzern eine extrem wertvolle Hilfe sind!

Ich habe das gleiche Problem wie Mabula (und andere) und kann folgendes Verhalten reproduzierbar nachstellen:

Der Sensor sendet nach Werksreset und Pairen zunächst regelmäßig alle 2-3 min Messwerte für die Kanäle 1-4 (jeweils T: und temperature:). Er sendet keinen für Kanal 5. Dabei habe ich (außer rename) alle Settings belassen wie mit autocreate erstellt.

Wenn man aber einmal "set getConfig" gesendet hat, passiert reproduzierbar Folgendes:

   
• Es erscheinen zunächst 6 Einträge "CMDs_pending"
• Dann wird noch einmal ein Satz Messwerte geschickt, ca 5 sec später gefolgt von einem Eintrag "CMDs_pending"
• Danach kommen keine Meldungen mehr von Sensor
• Das Drücken der Taste am Sensor hat keinerlei Auswirkung (auch kein Blinken der LED am Sensor); der Sensor wirkt "tot".
• Durch Herausnehmen und Wiedereinsetzen der Batterie blinkt die LED; nach anschließendem Drücken der Taste am Sensor, gefolgt von Blinken der LED, wird der Sensor wieder zum Leben erweckt.
• Im Log erscheint nach "Power on" einmal "CMDs_pending", dann "CMDs_done"
• Danach sendet der Sensor wieder regelmäßig wie zu Beginn.
• .... bis zum nächsten Aufruf von "set getConfig".

Übrigens:

   
• Ich steige vom Betrieb an der HM-CCU2 auf fhem mit HM-LAN-Adapter und Raspberry um. Ich hatte daher diesen Sensor ca 3 Monate an der CCU im Einsatz - ohne jedes Problem. Einen Sensor-Defekt schließe ich daher aus.

   
• Ich hatte auch das von anderen in diesem Forum berichtete Problem der leeren Batterien. Die Batterien waren ca 3 Monate in diesem Sensor bei Betrieb an der CCU im Einsatz. Danach waren sie weniger als 1 Woche in diesem "tot"-Betrieb an dem LAN-Adapter im Einsatz - und danach absolut leer. Es ist zwar prinzipiell auch möglich, dass die Batterie nun zufällig gerade dann auch im normalen Betrieb leer geworden wäre. Mir (als Laie) scheint es aber wahrscheinlicher, dass der Sensor durch "set getConfig" in einen Modus versetzt wird, in dem er nicht mehr kommunizieren kann, aber nicht wirklich "tot" ist, sondern intern "beschäftigt" ist. Durch Herausnehmen / Wiedereinsetzen der Batterie und anschließendem Drücken der Taste wird er anscheinend aus diesem Mode wieder zurückgesetzt.

Kann jemand helfen? Habe ich noch etwas falsch gemacht / nicht berücksichtigt?

Ansonsten hilft die Information ja vielleicht bei der Analyse.
Wenn ich mit weiteren Informationen helfen kann, will ich das gerne versuchen.

Viele Grüße  Norbert

---

Auszüge aus dem Logfile des Sensors:

Normalbetrieb (nach Werksreset, pairen) alle 2-3 min:
2016-01-31_10:31:13 Loggia_T1_m_T2 T: 0.3
2016-01-31_10:31:13 Loggia_T1_m_T2 temperature: 0.3
2016-01-31_10:31:13 Loggia_T_Diff battery: ok
2016-01-31_10:31:13 Loggia_T_room T: 9.9
2016-01-31_10:31:13 Loggia_T_room temperature: 9.9
2016-01-31_10:31:13 Loggia_T_sun T: 9.6
2016-01-31_10:31:13 Loggia_T_sun temperature: 9.6
2016-01-31_10:31:13 Loggia_dT_sun T: -0.3
2016-01-31_10:31:13 Loggia_dT_sun temperature: -0.3

Nach "set getConfig":
2016-01-31_10:34:44 Loggia_T_Diff CMDs_pending
2016-01-31_10:34:44 Loggia_T_Diff CMDs_pending
2016-01-31_10:34:44 Loggia_T_Diff CMDs_pending
2016-01-31_10:34:44 Loggia_T_Diff CMDs_pending
2016-01-31_10:34:44 Loggia_T_Diff CMDs_pending
2016-01-31_10:34:44 Loggia_T_Diff CMDs_pending
2016-01-31_10:36:01 Loggia_T1_m_T2 T: -0.5
2016-01-31_10:36:01 Loggia_T1_m_T2 temperature: -0.5
2016-01-31_10:36:02 Loggia_T_Diff battery: ok
2016-01-31_10:36:02 Loggia_T_room T: 9.6
2016-01-31_10:36:02 Loggia_T_room temperature: 9.6
2016-01-31_10:36:02 Loggia_T_sun T: 10.1
2016-01-31_10:36:02 Loggia_T_sun temperature: 10.1
2016-01-31_10:36:02 Loggia_dT_sun T: 0.5
2016-01-31_10:36:02 Loggia_dT_sun temperature: 0.5
2016-01-31_10:36:07 Loggia_T_Diff CMDs_pending
... keine Meldungen mehr
2016-01-31_11:31:13 Loggia_T_Diff powerOn: 2016-01-31 11:31:13

Nach Batterie herausnehmen, wieder einsetzen, Taste drücken:
2016-01-31_11:31:13 Loggia_T_Diff powerOn: 2016-01-31 11:31:13
2016-01-31_11:31:20 Loggia_T_Diff Activity: alive
2016-01-31_11:31:20 Loggia_T_Diff D-firmware: 1.1
2016-01-31_11:31:20 Loggia_T_Diff D-serialNr: MEQ0203709
2016-01-31_11:31:20 Loggia_T_Diff CMDs_pending
2016-01-31_11:31:26 Loggia_T_Diff CMDs_done
2016-01-31_11:33:39 Loggia_T1_m_T2 T: -1.3
2016-01-31_11:33:39 Loggia_T1_m_T2 temperature: -1.3
2016-01-31_11:33:39 Loggia_T_Diff battery: ok
2016-01-31_11:33:39 Loggia_T_room T: 13.2
2016-01-31_11:33:39 Loggia_T_room temperature: 13.2
2016-01-31_11:33:39 Loggia_T_sun T: 14.5
2016-01-31_11:33:39 Loggia_T_sun temperature: 14.5
2016-01-31_11:33:39 Loggia_dT_sun T: 1.3
2016-01-31_11:33:39 Loggia_dT_sun temperature: 1.3
usw. alle 2-3 min

Hallo,

ich möchte nochmal nachfragen:

• Hat keiner der Experten eine Meinung dazu oder einen Tipp?
• Hat sonst jemand ähnliche Erfahrung oder kann das beschriebene Verhalten reproduzieren und kann noch Erkenntnisse beisteuern?

Ich denke nach wie vor, dass es bei dem Sensor ein grundsätzliches Problem mit dem Befehl "getConfig" gibt, das ich nicht lösen kann, sondern wo nur ein Experte helfen könnte. 
Falls es doch an meiner mangelnden Kenntnis liegt, bin ich aber natürlich auch für jeden Hinweis dankbar, was ich anders machen sollte.

Vielen Dank und viele Grüße    Norbert

Das eine getconfig scheint durch gelaufen. Da war ein zweites, das der aktor nicht beantwortet hat. Koennte sein, daß fhem zu schnell war. Oder der aktor antwortet nicht immer.

Hallo,

ich hatte zu Anfang auch Probleme mit dem Sensor. Zuerst habe ich dem eine feste Spannungsversorgung verpasst. Das hat nicht den gewünschten Effekt gebracht. Was mich etwas überrascht hat, ich habe von Dirk einen Universalsender gekauft - wenn ich den in der Nähe postiere, steigt der Diff-Sensor er aus !?!? Nachdem ich das herausgefunden habe, ist der Universalsensor ca. 2 Meter weiter gewandert - seit dem ist Ruhe ! (über ein halbes Jahr)
Ich schließe daraus, das der Sensor Probleme mit "Fremdsignalen" hat. Die Software auf dem Teil verstrickt sich so extrem, das nur ein Reset über Spannung weg hilft. Ein einfaches Drücken des Configknopfes hilft nicht. Das mit dem autoReadReg 0_off habe ich erst vor drei Wochen eingestellt, das kann es in meinem Fall nicht gewesen sein. Fhem ist immer nahezu aktuell (Wöchentlich).

Gruß Christoph

Hallo,

danke für eure Rückmeldungen!

@ Martin:

• Wichtig ist, dass das geschilderte Verhalten absolut reproduzierbar ist - es ergibt sich immer exakt der genau gleiche Ablauf.
• Der Sensor arbeitet ansonsten völlig einwandfrei - solange man nicht getConfig aufruft. (seit meinem ersten Post keine einziger Ausfall, da auch kein getConfig mehr gesendet)
• Den extremen Batterieverbrauch in dem nicht ansprechbaren Mode, den andere auch schon berichtet hatten (dafür an anderer Stelle auch wenig "abgebügelt" wurden), könnte ich mir auch nicht durch sporadische Fehler erklären. Wie schon geschildert vermute ich, dass der Sensor nach getConfig in einem sehr aktiven - aber nicht ansprechbaren Zustand hängt.
• Einen Aktor habe ich in dem Zusammenhang noch gar nicht einbezogen.

@ Christoph:

• Das Problem mit getConfig könnte auch erklären, warum in einigen Posts eine teilweise Änderung des geschilderten Verhaltens durch Ändern von autoReadReg auf 0_off erreicht wurde. Soweit ich das verstehe wird dadurch der Aufruf von getConfig beim Starten aktiviert bzw. deaktiviert.
• Der Sensor sitzt am "äußersten Ende" des Hauses - und wie gesagt, absolut problemloser Betrieb, bis man getConfig schickt. Daher scheinen mir externe Störungen als Ursache in meinem Fall extrem unwahrscheinlich.

Wenn jemand gewillt ist, den Sensor danach wieder aufzuschrauben, oder wenn ihn jemand sowieso offen hat und es mal probieren möchte: Einmal getConfig senden. Ich möchte wetten, es ergibt sich das gleiche Verhalten wie in meinem ersten Post hierzu beschrieben. Recovery aus diesem Mode steht ebenfalls dort.
Wäre interessant, das Ergebnis zu erfahren.

Nochmals Danke für eure Unterstützung und
Viele Grüße     Norbert

Hallo,
ich klinke mich auch einmal ein.

Ich kann NoKis Aussage bestätigen.
Nach dem Absetzen eines getConfig hängt sich der Mikrocontroller im Sensor auf und schläft dadurch nicht mehr ein.
Resultat sind nach ein paar Tagen leere Batterien.

Ich habe insgesamt 5 von den Differenz-Temperatur-Sensoren (HM-WDS30-OT2-SM) im Einsatz.
Zusätzlich habe ich einen Kombiwettersensor (HM-WDS100-C6-O).
Alle haben dasselbe Phänomen: nach einen getConfig hängt sich der Controller im Sensor auf.
Teilweise reicht ein cold-restart durch Entnahme der Batterien.
Manchmal musste ich aber den Sensor mit der Anlerntaste zurücksetzen, damit ich diesen wieder benutzen konnte.

Komisch ist, dass ich die Probleme bei der Inbetriebnahme einiger der Sensoren im Mai - Juli 2015 keine Probleme hatte.
Vermutlich hängt es mit Änderungen in der CUL_HM zusammen.
Ich respektiere und achte Martins Arbeit, dies sollte keine Kritik sein.

Das setzen des Attributs autoReadReg auf "0_off" behebt nur die Folgen, aber nicht die Ursache des Problems!

Meine persönliche Folgenbehebung ist folgende:  ;)
(1) Alle CUL/Homematic-Gateways deaktivieren.
(2) Funk-Gateway (HMUSB/HMLAN/CUL) mit der HomeMatic-Konfigurations-Software verbinden
(3) in FHEM bei den Sensoren das Attribut ,,dummy" auf 1 setzen, dann sendet FHEM keine Funkprotokolle mehr an die Sensoren
(4) Sensor auf Werkseinstellung zurücksetzen
(5) Sensoren per HMLAN/HMUSB (Achtung: müssen die gleiche HMid wie in FHEM besitzen) an die HomeMatic-Konfigurations-Software von eq3 anlernen
(6) Sensoren mit der Software konfigurieren, evt. untereinander peeren
(7) CUL/HomeMatic-Gateway wieder aktivieren
Neue Sensoren werden durch "autocreate" in FHEM erkannt. Daran denken dummy im neuen Device zu setzen.
Man kann anschließen ganz normal in FHEM die Events per Notify triggern oder die Messwerte loggen.

Solange die Ursache nicht behoben ist, wäre dies vorerst meine Problembehbung.
Ich würde mich bei der Problemsuche mit dem HM-WDS30-OT2-SM gern beteiligen.

Grüße Sascha

ZitatIch würde mich bei der Problemsuche mit dem HM-WDS30-OT2-SM gern beteiligen.

1. dann würde ich mit einem 2. gateway den funkverkehr sniffen, der bei der nutzung der eq3-sw auftritt. pairen, peeren, register einstellen, ....

2. die selben aktionen im normalen fhem betrieb sniffen.

3. den funkverkehr von 1. und 2. vergleichen und unterschiede feststellen.

am besten vor 1. und 2. jeweils ein werksreset, um gleiche startbedingungen zu haben.

Hallo zusammen,

ich hab gestern die Batterien bei mir getauscht und die gleichen Effekte mit nicht mehr sendendem Sensor gehabt. Ein getConfig hat keine Reaktion gebracht. Interessanterweise lebt der Sensor wieder, kurz bevor die Batterien (nach einer Nacht) auf "low" gegangen sind. Vielleicht ist das ein Hinweis für die Eingrenzung des Problems bzw. für eine Lösung?

Der Sensor springt um 6:05 auf "Activity unknown, kurz danach werden die pending CMDs abgearbeitet (7:51) und danach lebt der Sensor wieder (ab 7:54). Um 7:56 ist dann die Batterie auf "low".

Hier das komplette Log:

2016-02-29_17:52:52 HM_Sonnensensor powerOn: 2016-02-29 17:52:52
2016-02-29_17:52:52 HM_Sonnensensor CMDs_done
2016-02-29_17:55:56 HM_Sonnensensor battery: ok
2016-02-29_17:55:56 HM_Sonnensensor CMDs_pending
2016-02-29_17:55:56 HM_Sonnensensor_T1 T: 4.1
2016-02-29_17:55:56 HM_Sonnensensor_T1 temperature: 4.1
2016-02-29_17:55:56 HM_Sonnensensor_T1_T2 T: 0.2
2016-02-29_17:55:56 HM_Sonnensensor_T1_T2 temperature: 0.2
2016-02-29_17:55:56 HM_Sonnensensor_T2 T: 3.9
2016-02-29_17:55:56 HM_Sonnensensor_T2 temperature: 3.9
2016-02-29_17:55:57 HM_Sonnensensor_T2_T1 T: -0.2
2016-02-29_17:55:57 HM_Sonnensensor_T2_T1 temperature: -0.2
2016-02-29_17:55:57 HM_Sonnensensor battery: ok
2016-02-29_17:55:57 HM_Sonnensensor_T1 T: 4.1
2016-02-29_17:55:57 HM_Sonnensensor_T1 temperature: 4.1
2016-02-29_17:55:57 HM_Sonnensensor_T1_T2 T: 0.2
2016-02-29_17:55:57 HM_Sonnensensor_T1_T2 temperature: 0.2
2016-02-29_17:55:57 HM_Sonnensensor_T2 T: 3.9
2016-02-29_17:55:57 HM_Sonnensensor_T2 temperature: 3.9
2016-02-29_17:55:57 HM_Sonnensensor_T2_T1 T: -0.2
2016-02-29_17:55:57 HM_Sonnensensor_T2_T1 temperature: -0.2
2016-02-29_17:55:58 HM_Sonnensensor Activity: alive
2016-02-29_17:56:00 HM_Sonnensensor CMDs_done
2016-02-29_20:14:56 HM_Sonnensensor CMDs_pending
2016-02-29_20:14:56 HM_Sonnensensor CMDs_pending
2016-02-29_20:14:56 HM_Sonnensensor CMDs_pending
2016-02-29_20:14:56 HM_Sonnensensor CMDs_pending
2016-02-29_20:14:56 HM_Sonnensensor CMDs_pending
2016-02-29_20:14:56 HM_Sonnensensor CMDs_pending
2016-02-29_20:15:43 HM_Sonnensensor CMDs_pending
2016-02-29_20:15:43 HM_Sonnensensor CMDs_pending
2016-02-29_20:15:43 HM_Sonnensensor CMDs_pending
2016-02-29_20:15:43 HM_Sonnensensor CMDs_pending
2016-02-29_20:15:43 HM_Sonnensensor CMDs_pending
2016-02-29_20:15:43 HM_Sonnensensor CMDs_pending
2016-02-29_20:22:16 HM_Sonnensensor Activity: alive
2016-02-29_20:22:38 HM_Sonnensensor Activity: alive
2016-02-29_20:23:30 HM_Sonnensensor CMDs_pending
2016-02-29_20:23:30 HM_Sonnensensor set_reset
2016-02-29_20:25:14 HM_Sonnensensor Activity: alive
2016-03-01_06:05:15 HM_Sonnensensor Activity: unknown
2016-03-01_07:51:24 HM_Sonnensensor powerOn: 2016-03-01 07:51:24
2016-03-01_07:51:24 HM_Sonnensensor CMDs_done
2016-03-01_07:54:06 HM_Sonnensensor battery: ok
2016-03-01_07:54:06 HM_Sonnensensor CMDs_pending
2016-03-01_07:54:06 HM_Sonnensensor_T1 T: -3.7
2016-03-01_07:54:06 HM_Sonnensensor_T1 temperature: -3.7
2016-03-01_07:54:06 HM_Sonnensensor_T1_T2 T: -0.4
2016-03-01_07:54:06 HM_Sonnensensor_T1_T2 temperature: -0.4
2016-03-01_07:54:06 HM_Sonnensensor_T2 T: -3.3
2016-03-01_07:54:06 HM_Sonnensensor_T2 temperature: -3.3
2016-03-01_07:54:06 HM_Sonnensensor_T2_T1 T: 0.4
2016-03-01_07:54:06 HM_Sonnensensor_T2_T1 temperature: 0.4
2016-03-01_07:54:06 HM_Sonnensensor R-burstRx: off
2016-03-01_07:54:06 HM_Sonnensensor R-cyclicInfoMsgDis: 0
2016-03-01_07:54:06 HM_Sonnensensor R-pairCentral: 0x129AAC
2016-03-01_07:54:06 HM_Sonnensensor R-paramSel: T1_T2
2016-03-01_07:54:09 HM_Sonnensensor CMDs_done
2016-03-01_07:55:20 HM_Sonnensensor Activity: alive
2016-03-01_07:56:30 HM_Sonnensensor battery: low
2016-03-01_07:56:31 HM_Sonnensensor_T1 T: -3.5
2016-03-01_07:56:31 HM_Sonnensensor_T1 temperature: -3.5

Gruß,
Bernd

Hi,

ich wollte das Thema noch mal "pushen", ein von mir zusammengebauter Bausatz zeigt genau das beschriebene (Fehl-)Verhalten und weitere Postings zu dem Thema finde ich nicht...

Bestehen die Probleme bei euch auch noch oder habe ich eine Lösung verpasst/überlesen? (Außer kein get-Config zu senden...)
FHEM ist nicht ganz aktuell, aber jünger als 2 Wochen...

Danke,
Andreas.

Hallo,

warum sendet man dem überhaupt ein getConfig? Wenn die Daten einmal da sind, sendet der doch von sich aus regelmäßig Daten. "autoReadReg" auf "off" stellen und gut ist. Meiner ist seit geraumer Zeit nicht mehr ausgestiegen. Ich hatte damit früher auch Probleme. Was ich beobachtet habe, wenn einer von Dirk Universalsensoren in der Nähe war, ist der ausgestiegen - keine Ahnung warum. Jetzt ist er 2 Meter weg und gut ist.
Einige Sensoren (bei mir die Wetterstation) machen Probleme, wenn man ein "Aktivsystem" und ein "Testsystem" - also die gleichen HMID - zusammen betreibt. Da hängt sich der Wettersensor bei mir immer auf, weil er wohl mit den 2 AKC's nicht klar kommt.

Gruß Christoph

Hi Christoph,

Zitat von: Bennemannc am 22 August 2016, 22:15:23
"autoReadReg" auf "off" stellen und gut ist.

habe ich jetzt gemacht, das "get config" hatte ich gemacht um zu sehen was der dann sendet...

Aber das ist ja eher ein workaround das abzuschalten. Entweder wird bei get-config irgendwas gesendet was nicht richtig ist, oder das Ding hat ein Firmware-Bug, was ja bei der "Qualität" der Firmware der einzelnen Homematic- oder Q3-Produkten schon eher wahrscheinlich ist.

Aber so wie es ausschaut gibt es momentan wohl wirklich nur die Lösung autoReadReg auf Null zu stellen und manuell kein get config auszulösen.

Danke für die RM,
Andreas.

Hallo,

ich kenne auch nach wie vor keine andere Lösung oder anderen Workaround. Ich denke nach wie vor, dass es da noch einen Bug gibt.
Ohne getConfig läuft der Sensor bei mir seit Februar fehlerfrei und problemlos.

Viele Grüße   Norbert

Hallo Norbert,

ja, dann hoffe ich mal das der bei mir bei auch mit "autoReadReg = 0" problemlos weiterläuft. Ich hatte den erst "lose" neben die Heizung gelegt (ist in der Wohnung am weitesten vom USB-Stick entfernt) um zu sehen ob der überhaupt empfängt. Das ging zwei Tage gut, dann habe ich die Sensoren an den Leitungen befestigt und hatte dann beim weiteren Rumprobieren auf "get config" gedrückt um die Werte sofort lesen zu können und nicht zu warten, dabei ist das Ding dann wohl ausgestiegen...

Das Ding scheint ja wirklich einen Firmware-Bug zu haben, die Tatsache das der nicht mehr auf den Taster reagiert zeigt ja das der sich intern irgendwie verabschiedet. Die Frage wäre ob man das durch Anpassungen in FHEM verhindern könnte, wobei ich denke das man bei einem get config nicht so viel verkehrt machen kann und das Martin da schon weiß was er tut.

Gruß,
Andreas.

Zitathatte dann beim weiteren Rumprobieren auf "get config" gedrückt um die Werte sofort lesen zu können und nicht zu warten, dabei ist das Ding dann wohl ausgestiegen...

ich habe dieses device zwar nicht, aber dafür sollte doch eher ein statusRequest benutzt werden. es muss ja dafür nicht die ganze config und die peers ausgelesen werden. vielleicht ist das dann verträglicher.

Hi,

mag sein das dies "richtiger" gewesen wäre, ich wollte ja eigentlich nur (sofort) sehen ob das Ding nachdem ich es leicht anders neben der Heizung positioniert habe um die Sensoren befestigen zu können immer noch Empfang hat, und da war get config "einfacher", das ist ja als web cmd in der Leiste.
Das (nicht nur) dieses Device anscheinen einen Firmware Bug hat wusste ich ja noch nicht...

Gruß,
Andreas.

Hallo,

wir haben auf einem Anwendertreffen das mit dem AutoReadReg mal durchgesprochen. Das wird ja nur beim Start von fhem ausgeführt, um den aktuelle Zustand des Gerätes zu bekommen.
Für batteriebetriebene macht ein AutoReadReg keinen Sinn, da sie auf die Anforderung der Zentrale nicht antworten, weil sie gerade schlafen. Das betrifft Heizkörperthermostate, Fensterkontakte, Wettersensoren, ...
Für mich ist das kein Workaround - Zentrale fordert Daten, bekommt nichts, also bleiben die Kommandos im Spool. Wenn dann das Gerät sendet (aktuelle Daten) werden die Kommandos ggf. abgearbeitet, aber was will ich denn dann noch auslesen? Pairing, Peering - die habe ich ja schon, weil die in der FHEM.Save gespeichert werden und beim Start geladen werden. Bei neuen Peers, muss ich ohnehin die Configtaste drücken und fhem bekommt die Daten mit.
Also bringt mir eine andere Einstellung als "off" keinen Vorteil - nur eben den Nachteil, das durch den FW Bug das Device abschmiert.

Gruß Christoph

Batterie devices werden ggf. Aufgeweckt.
Register werden nur gelesen, wenn diese nicht vorliegen.
Im Kontext ist also das sichern der Register mit hminfo archConfig zu sehen, sowie dessen automatisches laden des selben nach reboot.
Ferner ist zu beachten, dass autoreadreg die Register nach einer Änderung derselben liest. Auch hier zu beachten, das automatische archivieren der Register.
Weiter sorgt autoreadreg für ein status lesen nach dem Reboot. Eine Funktion die ich zumindest in jedem Fall haben möchte.
Wenn die Funktion so verstanden wurde kann man Objektiv entscheiden ob man sie abschalten will. Das ist einfach möglich.

Hallo zusammen.

ich habe mir heute den 2. HM-WDS30-OT2-SM zusammen gelötet. Der 1. HM-WDS30-OT2-SM funktioniert ohne Probleme. Das anlernen an FHEM funktioniert bei dem 1. auch ohne Probleme.
Nur mit dem 2. gibt es Probleme, ganz massiv. Ich wollte jetzt erst einmal in die Runde fragen, ob jemand die gleichen Probleme hat.

Der 2. Sensor wurde komplett zusammen gelötet, jedenfalls das was da noch gelötet werden muss.
Batterien eingelegt, FHEM USB CUL für Hm in den Anlernmodus gebracht. und am Sensor die Config Taste 1x kurze gedrückt.
Timeout ist vergangen ohne das angelernt wurde. 2. x die Taste am Sensor gedrückt. Wieder keine anlernen erfolgt.
3. x die Taste gedrückt um dem Sensor anzulernen. Er fing nach ein paar Sekunden schneller an zu blinken, aber anstatt die grüne LED, für den bestätigten Anlernerfolg, ging die rote LED an.
Das Gerät wurde zwar angelegt, aber blieb permanet auf CMD-pendig hängen. Temperaturen wurden auch nicht übertragen.

Habe den Sensor wieder gelöscht und nach Anleitung in den Werkszustand resetet. Das ganze wiederholt, mit den anlernen. Manchmal funktionierte das anlernen erst nach dem 6x. Aber immer mit der Bestätigung der roten LED anstatt der grünen LED.

Weiß da jemand Abhilfe, ausser ELV Hotline ??

Gruß und Danke

Sascha

PS.: einen fehler von dem HM CUL (nanoCUL Selbstbau) schließe ich mal aus, da der Rest der HM Komponenten funktioniert !

CFGFN
   CUL868_MSGCNT 5
   CUL868_RAWMSG A0C0886704B44D40000007FFE64::-34.5:CUL868
   CUL868_RSSI -34.5
   CUL868_TIME 2016-11-19 18:34:20
   DEF        4B44D4
   IODev      CUL868
   LASTInputDev CUL868
   MSGCNT     5
   NAME       HM_4B44D4
   NOTIFYDEV  global
   NR         5753
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HM_4B44D4_T1
   channel_02 HM_4B44D4_T2
   channel_03 HM_4B44D4_T1_T2
   channel_04 HM_4B44D4_T2_T1
   channel_05 HM_4B44D4_Event
   lastMsg    No:08 - t:70 s:4B44D4 d:000000 7FFE64
   protCmdDel 5
   protCmdPend 6 CMDs_pending
   protLastRcv 2016-11-19 18:34:20
   protResnd  3 last_at:2016-11-19 18:32:04
   protResndFail 1 last_at:2016-11-19 18:34:25
   protSnd    5 last_at:2016-11-19 18:34:20
   protState  CMDs_pending
   rssi_at_CUL868 min:-36 cnt:5 avg:-34.79 max:-33.5 lst:-34.5
   Readings:
     2016-11-19 18:18:00   Activity        alive
     2016-11-19 18:17:55   CommandAccepted yes
     2016-11-19 18:17:55   D-firmware      1.1
     2016-11-19 18:17:55   D-serialNr      NEQ0533292
     2016-11-19 18:28:04   H               0
     2016-11-19 18:17:55   R-pairCentral   set_0xF10000
     2016-11-19 18:34:20   battery         ok
     2016-11-19 18:39:30   state           CMDs_pending
     2016-11-19 18:34:20   temperature     -0.2
     T:
   cmdStack:
     ++A001F100004B44D400040000000000
     ++A001F100004B44D40103
     ++A001F100004B44D40203
     ++A001F100004B44D40303
     ++A001F100004B44D40403
     ++A001F100004B44D40503
   Helper:
     HM_CMDNR   8
     cSnd       01F100004B44D400050000000000,01F100004B44D4000802010AF10B000C00
     mId        00A8
     rxType     140
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4B44D4,02,00,00
       nextSend   1479576860.85268
       prefIO
       rxt        2
       vccu
       p:
         4B44D4
         00
         00
         00
     Mrssi:
       mNo        08
       Io:
         CUL868     -32.5
     Prt:
       bErr       0
       sProc      2
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       At_cul868:
         avg        -34.8
         cnt        5
         lst        -34.5
         max        -33.5
         min        -36
     Shadowreg:
       RegL_00.    02:01 0A:F1 0B:00 0C:00
Attributes:
   IODev      CUL868
   actCycle   012:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.1
   model      HM-WDS30-OT2-SM
   room       99_neu
   serialNr   NEQ0533292
   subType    THSensor
   webCmd     getConfig:clear msgEvents

Habe das Teil nach ELV zurück geschickt, mit der Bitte um eine Reparatur. Ich bekam einen ganz neuen Sensor der erst zusammen gelötet werden musste.
Es traten die gleichen Probleme auf, wie vorher.
Habe ihn nach dem fehlerhaften anlernen komplett aus der config gelöscht und nen Neustart von Fhem gemacht. Danach ließ sich der Sensor ohne Probleme anlernen, mit grüner LED als Bestätigung.
Der Sensor lieferte aber nur 1 wert. Die einzelnen Kanäle waren mit Fragezeichen gefüllt.
Habe dann nochmal einen Neustart von fhem durchgeführt.

Bis jetzt scheint er zu funktionieren......

Kann sich das Verhalten einer erklären?

Gruß Sascha

So, ich bins nochmal.

Nachdem der 2. Temp.diff.sensor augenscheinlich funktioniert, habe ich festgestellt, dass der Sensor nur sporadisch sendet.
Teilweise Ausfälle von bis zu 45 Minuten, wo nix bei FHEM ankam. Habe dann mit ELV Technische Holtline telefoniert und denen das geschildert.
Darauf hin hieß es nur noch, dass Teil bitte zurück schicken. ELV hat es überprüft, und ich bekam es zurück mit dem Hinweis, dass es an einer CCU2 ohne Probleme funktioniert hat !  ::) Und es in Ordnung wäre.

Kann ich so nicht glauben. Ich habe ja diverse HM Komponenten, die ohne Probleme funktionieren. Unter anderem auch noch einen baugleichen Temp.diff.Sensor, der ohne Probleme empfangen wird.

Jemand noch eine Ahnung warum der 2. Sensor nicht richtig empfangen wird ????

Danke für die Hilfe !!!

Gruß
Sascha

Hallo Sascha und Leidgeplagte,

was das Batteriefressen nach getConfig angeht denke ich, es ist ein Firmware Bug im Sensor. Er schläft nach getConfig nicht immer ein, was ich am aufgenommen Strom messen konnte. Enmal konnte ich nach einem vollständig erfolgreich durchgelaufenen getConfig den Sensor durch händische Wiederholung der letzten Registerabfrage wieder aus dem Zustand herraus holen. Daher denke ich, er empfängt einfach zufällig den letzten ACK von FHEM nicht und bleibt dann wohl wach, bis die Batterie leer ist. Eigentlich sollte er in jedem Fall nach einem Timeout wiederholen oder die Kommunikation abbrechen und einschlafen bis zum nächsten Senden der Temperaturen.

Auf FHEM Seite macht man da nicht viel sinnvolles dran, außer automatisches Register Read abschalten und sinnloses händisches getConfig sein zu lassen. Wenn man mal die Registerwerte lesen muss, dann muss man danach ca. 6 Minuten beobachten, ob noch Werte kommen. Wenn nicht, Batterien raus und wieder rein oder neue bereit halten. ;)

Jemand noch eine Ahnung warum der 2. Sensor nicht richtig empfangen wird
Kommt darauf an, womit Du empfängst. Die Sende-/Empfangsbandbreite ist mit 101kHz nicht besonders groß. Da ist eine saubere Frequenzabstimmung von Bedeutung.
Bei meinen CULs ist mir gegenüber meinen Devices ein Frequenzoffset von etw 20kHz aufgefallen. Wenn Du also mit CUL und dem Sensor zufällig sehr schlecht liegst, dann kann das den Empfang schon sehr beeinträchtigen.
Daher kann man bei meiner Firmwarevariante auch den CUL Frequenzoffset für HM nachstellen, um das auf die Devices zu optimieren.
Was sagt denn der RSSI?

Die üblichen Verdächtigen mit Position und Empfangslage hast schon durch, nehme ich an und die Antenne ist im Sensor auch korrekt verlegt?!

Gruß, Ansgar.

Danke für deine Antwort.

Der RSSI Wert für den Sensor liegt bei -60. Der Sensor der funktioniert und im Keller liegt ist bei -82 und funktioniert ohne Probleme.
Ich habe einen Selbstbau nanoCUL für 868 MHz. Die anderen HM Devices funktionieren ohne große Probleme. Habe noch 2 weiter Jallo-UP Aktoren.
Habe auch geschaut. Aber die Frequenz oder Bandbreite lässt sich im HM Mode ja nicht ändern, leider.

Nach deiner Ausführung scheint es dann am Sende/Empfänger Modul des Sensors zu liegen !?!?!?
Bekommt man das Teil auch einzeln bei ELV. Ich glaub ich muss mal schauen !!!

Danke erst mal
Sascha

Zitat von: noansi am 17 Dezember 2016, 22:24:08
Hallo Sascha und Leidgeplagte,

was das Batteriefressen nach getConfig angeht denke ich, es ist ein Firmware Bug im Sensor. Er schläft nach getConfig nicht immer ein, was ich am aufgenommen Strom messen konnte. Enmal konnte ich nach einem vollständig erfolgreich durchgelaufenen getConfig den Sensor durch händische Wiederholung der letzten Registerabfrage wieder aus dem Zustand herraus holen. Daher denke ich, er empfängt einfach zufällig den letzten ACK von FHEM nicht und bleibt dann wohl wach, bis die Batterie leer ist. Eigentlich sollte er in jedem Fall nach einem Timeout wiederholen oder die Kommunikation abbrechen und einschlafen bis zum nächsten Senden der Temperaturen.

Auf FHEM Seite macht man da nicht viel sinnvolles dran, außer automatisches Register Read abschalten und sinnloses händisches getConfig sein zu lassen. Wenn man mal die Registerwerte lesen muss, dann muss man danach ca. 6 Minuten beobachten, ob noch Werte kommen. Wenn nicht, Batterien raus und wieder rein oder neue bereit halten. ;)

Jemand noch eine Ahnung warum der 2. Sensor nicht richtig empfangen wird
Kommt darauf an, womit Du empfängst. Die Sende-/Empfangsbandbreite ist mit 101kHz nicht besonders groß. Da ist eine saubere Frequenzabstimmung von Bedeutung.
Bei meinen CULs ist mir gegenüber meinen Devices ein Frequenzoffset von etw 20kHz aufgefallen. Wenn Du also mit CUL und dem Sensor zufällig sehr schlecht liegst, dann kann das den Empfang schon sehr beeinträchtigen.
Daher kann man bei meiner Firmwarevariante auch den CUL Frequenzoffset für HM nachstellen, um das auf die Devices zu optimieren.
Was sagt denn der RSSI?

Die üblichen Verdächtigen mit Position und Empfangslage hast schon durch, nehme ich an und die Antenne ist im Sensor auch korrekt verlegt?!

Gruß, Ansgar.

Kannst du mir bitte mal deine Firmware für den cul zu kommen lassen?

Gruß Sascha

Von mobil gesendet daher kurze Antwort

Hallo Sascha,

ZitatKannst du mir bitte mal deine Firmware für den cul zu kommen lassen?

Hier geht es zum Thread von TSCUL: https://forum.fhem.de/index.php/topic,24436.msg175466.html#msg175466 (https://forum.fhem.de/index.php/topic,24436.msg175466.html#msg175466)

Es ist allerdings mühsam, den hmFreqOffs zu optimieren, wenn man das Frequenzspektrum um 868.3MHz herum nicht sichtbar machen kann.
Denn dann muss man nach jeder Änderung des Offsets in HM-Info über einen etwas längeren Zeitraum alle RSSI Werte der devices auf Verbesserung und Verschlechterung hin untersuchen, um die optimale Mitte zu finden.

Gruß, Ansgar.

Hallo zusammen,

ich bin gerade erst in Heimautomatisierung eingestiegen. Benutze den Raspberry3 + HM-MOD-RPI-PCB.
Als Neuling hab ich mit RaspberryMatic angefangen. Image geflasht und der HM-WDS30-OT2-SM war ruckzuck eingebunden.

Da ich aber dachte, wenn ich mal mehr will, gleich eine 2te Karte zum testen für fhem. Nach den Tut's war auch da das Modul schnell
am laufen. Nach einer Weile bekam ich auch die Probleme, das der Sensor ausstieg. Jetzt zeigt er unter Fhem auch nur noch:

Zitat
ActionDetector
alive:1 dead:0 unkn:0 off:0
HM_4B439A_Event             T: -0.2
HM_4B439A_T1                  ???
HM_4B439A_T1_T2            ???
HM_4B439A_T2                  ???
HM_4B439A_T2_T1            ???

an...

Mittlerweile habe ich die 3 Hinweise beachtet:

1. Nicht "getConfig" drücken
2. unter HM_4B439A "autoReadReg" auf "0_off"
3. unter HM_4B439A "dummy" auf "1"

Leider ohne Besserung. Da ich nicht wusste das der Sensor so eine Ziege ist, habe ich ihn oft mit getConfig gequält. Batterien habe ich
natürlich auch getauscht.

Nutze ich aber meine erste SD-Card mit dem RaspberryMaticImage läuft er jedoch wieder  ::) Hat das mal jemand von Euch beobachtet?
Gibt es vielleicht eine Möglichkeit zu schauen was RaspberryMatic anders macht? Oder gibt es eine Möglichkeit, die Firmware erneut
zu schreiben um sie so zu nullen? Irgendwas passiert da ja mit dem Modul.

Hi,

also mein HM-WDS30-OT2-SM läuft seit einem Jahr in Standardkonfiguration eigentlich ohne Probleme - leider hat der Marder vor ein paar Wochen meine Sensoren abgebissen und zerkaut, deswegen habe ich keine sinnvollen Temperaturen mehr.  :'(
Gib doch mal ein list HM_4B439A in Codetags (# Taste über den Smily) vielleicht sieht man da was. Mit dem attr dummy 1 hast Du ihn nach meiner Ansicht abgeschaltet.

Dein FHEM ist aktuell?

Gruß Otto

Folgendes kommt bei list, und den dummy hab ich auf deinen Rat mal wieder entfernt. Hatte ich vorher auch nicht, stand
irgendwo im Forum. Man testet alles aus. Fhem ist aktuell, in den letzten Tag mehrfach den Raspi komplett neu eingerichtet
mit SD-Card formatieren. Dachte ich hab irgendwas verhauen, wer denkt denn gleich, der Sensor hat einen FW Bug...

Internals:
   DEF        4B439A
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     1
   NAME       HM_4B439A
   NOTIFYDEV  global
   NR         21
   NTFY_ORDER 50-HM_4B439A
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HM_4B439A_T1
   channel_02 HM_4B439A_T2
   channel_03 HM_4B439A_T1_T2
   channel_04 HM_4B439A_T2_T1
   channel_05 HM_4B439A_Event
   lastMsg    No:80 - t:10 s:4B439A d:000000 06000000
   myHmUART_MSGCNT 1
   myHmUART_RAWMSG 050000418084104B439A00000006000000
   myHmUART_RSSI -65
   myHmUART_TIME 2017-05-22 21:17:53
   protLastRcv 2017-05-22 21:17:53
   rssi_at_myHmUART cnt:1 max:-65 avg:-65 lst:-65 min:-65
   Readings:
     2017-05-22 21:16:21   Activity        alive
     2017-05-22 21:11:42   D-firmware      1.1
     2017-05-22 21:11:42   D-serialNr      NEQ0533627
     2017-05-22 21:15:10   battery         ok
     2017-05-22 21:17:53   powerOn         2017-05-22 21:17:53
     2017-05-22 21:17:53   recentStateType info
     2017-05-22 21:15:13   state           CMDs_pending
     2017-05-22 21:15:10   temperature     -0.1
   Helper:
     HM_CMDNR   128
     PONtest    0
     mId        00A8
     rxType     140
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4B439A,00,00,00
       nextSend   1495480674.0339
       prefIO
       rxt        2
       vccu
       p:
         4B439A
         00
         00
         00
     Mrssi:
       mNo        80
       Io:
         myHmUART   -63
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       At_myhmuart:
         avg        -65
         cnt        1
         lst        -65
         max        -65
         min        -65
     Tmpl:
Attributes:
   IODev      myHmUART
   actCycle   012:00
   actStatus  alive
   autoReadReg 0_off
   expert     2_raw
   firmware   1.1
   model      HM-WDS30-OT2-SM
   room       CUL_HM
   serialNr   NEQ0533627
   subType    THSensor
   webCmd     getConfig:clear msgEvents

Was genau war jetzt mit den Codetags?  :'(

Zitat von: Otto123 am 22 Mai 2017, 21:09:29
Gib doch mal ein list HM_4B439A in Codetags (# Taste über den Smily) vielleicht sieht man da was.

Du hast den Sensor nicht gepairt.
Ich habe kein reading temperature - woher das kommt?

Was zeigen denn die einzelnen Channels? stehen da sinnvolle Temperaturen drin?

Gruß Otto

Die Channels sind alle tot, bis auf event. Ich habe gerade noch das gefunden im Wiki:

ZitatEs gilt auch sicherzustellen, dass das zu pairende Gerät nicht bereits zuvor mit der Homematic Config Software gepairt wurde. Ist dies der Fall, so sollte das Pairing in der Homematic Config Software gelöscht und das Pairing in FHEM erneut durchgeführt werden.

Wenn ich denn Sensor länger als 4 sekunden drücke x 2 lösche ich doch das pairing? Gepairt war er allerdings bei mir mit RaspberryMatic.
Wie am besten vorgehen bei manuellen pairen?

gibst Du bitte ein list HM_4B439A_T1

Wie der Sensor auf Werkszustand zurückgesetzt wird steht im Handbuch. Aber das ist erstmal nicht das Thema, die Werte sendet er trotzdem und Du kannst Sie empfangen.

Gruß Otto

Internals:
   CFGFN
   DEF        4B439A01
   NAME       HM_4B439A_T1
   NOTIFYDEV  global
   NR         27
   STATE      ???
   TYPE       CUL_HM
   chanNo     01
   device     HM_4B439A
   Readings:
     2017-05-22 22:01:26   peerList
   Helper:
     getCfgListNo
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
     Tmpl:
Attributes:
   model      HM-WDS30-OT2-SM
   peerIDs

Wenn Du den Hinweis mit den Codetags weiter ignorierst bin ich raus!  :'(
Bei dem list fehlt praktisch alles, ein reading peerlist hat einen aktuellen Timestamp ist aber leer.
Also besser Du löschst das wirklich alles (Device und Channels) machst ein Werksreset und drückst nochmal neu die ConfigTaste dann sollte er alles neu anlegen ohne zu pairen, das sollte aber fürs erste auch reichen.

Zitat· Um den Sensor in den Auslieferungszustand zurückzusetzen,
drücken Sie die Konfigurationstaste für mindestens 4 s. Jetzt
blinkt die Geräte-LED langsam rot.
· Bei Bedarf können Sie jetzt das Zurücksetzen unterbrechen,
indem Sie die Konfigurationstaste kurz drücken oder 15 s ohne
Bedienung warten. In beiden Fällen stoppt das Blinken der
Geräte-LED.
· Zum Zurücksetzen des Gerätes halten Sie erneut die Konfigurationstaste
für mindestens 4 Sekunden gedrückt. Schnelles
rotes Blinken der Geräte-LED zeigt den Rücksetzvorgang an.
· Nach dem Loslassen der Konfigurationstaste wird das Zurückstellen
durch kurzes Aufleuchten der Geräte-LED in der
Farbfolge Rot-Grün-Orange angezeigt.

Gruß Otto

Ich ignorier dich doch nicht. Im Gegenteil, dein Blog hat mir schon sehr geholfen. Auch der Werksreset führt zu nichts. Muss
wohl einschicken. Dann bekomm ich von ELV bestimmt ein nettes: " Unter Homematic läufts" und ich kann das Ding entsorgen...

Hier ein Screenshot zu "list HM_4B439A_T1 " damit du mir glaubst. Und ja, ich sehe, der Timestamp weicht 10min ab jetzt
wo du es sagst...liegt aber nicht an mir, das kommt wenn ich "list HM_4B439A_T1 "...und das kommt meiner Meinung daher,
das sich der Sensor zu der Zeit aufgehängt hat.....

edit:ok der timestamp passt natürlich nicht zu deinem. Aber als ich ihn gemacht hatte war es schon 22:28Uhr...

edit2: Erneuter Werksreset, jetzt ist es 22:42. Bei "list HM_4B439A_T1 " steht 22:34...

edit3: 2017-05-22 22:42:59 CUL_HM HM_4B439A MISSING ACK

Das was Du jetzt berichtest klingt alles nicht danach:
Das Du wirklich einen Reset gemacht hast, die Blinkfolge kam wirklich? Nach dem Loslassen der Konfigurationstaste wird das zurückstellen durch kurzes Aufleuchten der Geräte-LED in der Farbfolge Rot-Grün-Orange angezeigt.
Du die existierenden Geräte /Channels gelöscht hast und alles durch drücken des ConfigTasters neu angelegt wurde.

Drücken des ConfigTasters meint das drücken der Konfigurationstaste am Sensor und nicht getConfig! getConfig wird er erst nach dem pairen beantworten.

Genau so,

1. Tastenkombi zum löschen, die LED hat genau so geleuchtet wie sie soll mit Bestätigung Rot-Grün-Orange.
2. Alles zum Sensor in Fhem gelöscht (log, Sensor, ActionDetector)
3. shutdown restart
4. Paringknopf am Sensor kurz (1sek.) gedrückt.
5. alles wie immer, kein pairing.

Und wenn Du ihn richtig pairst?

Hilf mir auf die Sprünge. Was verstehst du unter richtigem pairen?

edit:

Das "set HM_4B439A pair" führt z.B. bei mir zu dem --> Unknown argument pair, choose one of assignHmKey clear deviceRename fwUpdate getConfig getRegRaw raw regBulk regSet reset unpair

Zitat von: ertgwetz am 22 Mai 2017, 23:50:12
Hilf mir auf die Sprünge. Was verstehst du unter richtigem pairen?

set myHmUART hmPairForSec 60

EDIT2: oder mehr als 60, wenn du für das Drücken des "Anlern-Knopfes" (wie in der Anleitung beschrieben) länger als eine Minute brauchst...

und dann wie in der Anleitung beschrieben drücken was bei "Anlernen an Zentrale steht" (aber nur den Sensor-Teil / der Zentralen-Teil ist ja das pairForSec)

Nach dem Löschen und vor dem shutdown restart auch save config durchgeführt!?

EDIT: weil sonst ist nach shutdown restart nix mehr gelöscht... ;)

Und wie Otto schon gefühlt tausend mal "gefleht" hat:

list und code etc. in code-Tags, das '#' oben im "Menü"...
...also auch keine ScreenShots...

Gruß, Joachim

Hallo zusammen,

ersmal Entschuldigung wegen den codetags#. War gestresst...da ich schon seit Tagen probiert hatte, den Sensor
wiederzubeleben. Ich habe da gestern bei dem Durcheinander was missverstanden  ::) Demnächst wird der Text
vernünftig formatiert.

Das Gute, Otto hatte recht, der Sensor sendet noch. Gerade habe ich ihn endlich gepaired bekommen. Das löschen
des Sensors so wie auch das abspeichern/löschen der Config war von mir immer richtig ausgeführt.
Geholfen hat wie von euch empfohlen das "set myHmUART hmPairForSec 60". Dieses habe ich immer falsch
angewandt. Versuche über ssh sowie oben in der fhem Eingabezeile führten zu nix....ja jetzt hab ich bemerkt, direkt
unter myHmUART is die Option zum set.

Internals:
   CFGFN
   DEF        4B439A
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     18
   NAME       HM_4B439A
   NOTIFYDEV  global
   NR         29
   NTFY_ORDER 50-HM_4B439A
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_4B439A_T1
   channel_02 HM_4B439A_T2
   channel_03 HM_4B439A_T1_T2
   channel_04 HM_4B439A_T2_T1
   channel_05 HM_4B439A_Event
   lastMsg    No:07 - t:53 s:4B439A d:000000 004100D94200DC43FFFD440003
   myHmUART_MSGCNT 18
   myHmUART_RAWMSG 0500002B0786534B439A000000004100D94200DC43FFFD440003
   myHmUART_RSSI -43
   myHmUART_TIME 2017-05-23 17:48:50
   protLastRcv 2017-05-23 17:48:50
   protSnd    16 last_at:2017-05-23 17:36:44
   protState  CMDs_done
   rssi_at_myHmUART avg:-39.94 min:-43 max:-38 lst:-43 cnt:18
   Readings:
     2017-05-23 17:35:07   Activity        alive
     2017-05-23 17:36:41   CommandAccepted yes
     2017-05-23 17:35:02   D-firmware      1.1
     2017-05-23 17:35:02   D-serialNr      NEQ0533627
     2017-05-23 17:36:42   PairedTo        0x424242
     2017-05-23 17:36:42   R-burstRx       off
     2017-05-23 17:36:42   R-cyclicInfoMsgDis 0
     2017-05-23 17:36:42   R-pairCentral   0x424242
     2017-05-23 17:36:42   R-paramSel      T1_T2
     2017-05-23 17:36:42   RegL_00.          01:00 02:01 0A:42 0B:42 0C:42 11:00 18:00 1B:03  00:00
     2017-05-23 17:48:50   battery         ok
     2017-05-23 17:36:44   state           CMDs_done
   Helper:
     HM_CMDNR   7
     cSnd       014242424B439A0403,014242424B439A0503
     mId        00A8
     rxType     140
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4B439A,00,00,00
       nextSend   1495554530.30902
       prefIO
       rxt        2
       vccu
       p:
         4B439A
         00
         00
         00
     Mrssi:
       mNo        07
       Io:
         myHmUART   -41
     Prt:
       bErr       0
       sProc      0
       try        1
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       At_myhmuart:
         avg        -39.9444444444444
         cnt        18
         lst        -43
         max        -38
         min        -43
     Shadowreg:
     Tmpl:
Attributes:
   IODev      myHmUART
   actCycle   012:00
   actStatus  alive
   autoReadReg 0_off
   expert     2_raw
   firmware   1.1
   model      HM-WDS30-OT2-SM
   room       CUL_HM
   serialNr   NEQ0533627
   subType    THSensor
   userReadings T1 { ReadingsVal("HM_4B439A_T1","temperature",0)},
T2 { ReadingsVal("HM_4B439A_T2","temperature",0)},
T1_T2 { ReadingsVal("HM_4B439A_T1_T2","temperature",0)},
T2_T1 { ReadingsVal("HM_4B439A_T2_T1","temperature",0)}
   webCmd     getConfig:clear msgEvents


Benutzt ihr auch autoReadReg 0_off, um den Sensor stabil zu halten?
Und, ist das normal, das unter HM_4B439A_Event nur noch Fragezeichen kommen?
Ich meine, das war sonst nicht der Fall, auch wenn ich nur T1 und T2 benötige.

CUL_HM
ActionDetector
alive:1 dead:0 unkn:0 off:0
HM_4B439A_Event           ???
HM_4B439A_T1               T: 21.7
HM_4B439A_T1_T2         T: -0.4
HM_4B439A_T2               T: 22.1
HM_4B439A_T2_T1         T: 0.4


Zitat von: ertgwetz am 23 Mai 2017, 17:56:28
Und, ist das normal, das unter HM_4B439A_Event nur noch Fragezeichen kommen?

Hi,

ob das normal ist kann ich nicht sagen, ist bei mir auch so.

Ich habe wie gesagt an der Standardeinstellung nichts geändert, autoReadReg steht auf 4_reqStatus
Läuft stabil - wenn der Marder nicht gewesen wäre.

Gruß Otto

Zitat von: Otto123 am 23 Mai 2017, 20:49:29
Hi,

ob das normal ist kann ich nicht sagen, ist bei mir auch so.

Ich habe wie gesagt an der Standardeinstellung nichts geändert, autoReadReg steht auf 4_reqStatus
Läuft stabil - wenn der Marder nicht gewesen wäre.

Gruß Otto

Selbes bei mir...
...bis auf die Marder... ;)

Gruß, Joachim

angezeigt wird hier der STATE der entity. ??? besagt, dass dies nicht gesetzt ist. möglich, dass kein event aufgetreten ist. bin mir auch nicht sicher, was nach state ges hrieben wird, da ich kein device habe und aktuell den code nicht sehe. bei einem event Kanal ist es eh fraglich, was es Stunden nach einem Event noch sagen soll.
aber setzt es doch nach deinen Bedürfnissen.

ok, vielen dank allen nochmal. Läuft jetzt stabil  :)

Hallo teste auch schon einige zeit mit dem Teil aber immer nach mehreren Stunden kommt nicht mehr,
gibts jetzt schon eine bessere lösung habe das hier scon auf beiden Fhems getestet.
(einmal mit Raspberry und HMUARTLGW und einmal mit HM-CFG-LAN Adapter.
Internals:
   DEF        4BE14C01
   NAME       HM_4BE14C_T1
   NOTIFYDEV  global
   NR         45
   NTFY_ORDER 50-HM_4BE14C_T1
   STATE      T: 9.9
   TYPE       CUL_HM
   chanNo     01
   device     HM_4BE14C
   READINGS:
     2017-11-05 22:07:54   state           T: 9.9
     2017-11-05 22:07:54   temperature     9.9
   helper:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     tmpl:
Attributes:
   model      HM-WDS30-OT2-SM
   peerIDs    00000000,

Hier seht ihr was er seit dem peeren geschrieben hat was komisch ist das  der log länger geht als der Eintrag in der list
017-11-05_19:42:36 HM_4BE14C R-pairCentral: set_0x000000
2017-11-05_19:42:36 HM_4BE14C CMDs_pending
2017-11-05_19:42:36 HM_4BE14C CMDs_pending
2017-11-05_19:42:36 HM_4BE14C CMDs_pending
2017-11-05_19:42:49 HM_4BE14C powerOn: 2017-11-05 19:42:49
2017-11-05_19:43:19 HM_4BE14C Activity: alive
2017-11-05_19:43:19 HM_4BE14C D-firmware: 1.1
2017-11-05_19:43:19 HM_4BE14C D-serialNr: NEQ0534154
2017-11-05_19:43:19 HM_4BE14C R-pairCentral: set_0x1E9DF2
2017-11-05_19:43:19 HM_4BE14C CMDs_done_Errors:1
2017-11-05_19:43:19 HM_4BE14C CMDs_pending
2017-11-05_19:43:19 HM_4BE14C dummy
2017-11-05_19:44:39 HM_4BE14C Info_Cleared
2017-11-05_19:44:44 HM_4BE14C CMDs_pending
2017-11-05_19:44:44 HM_4BE14C set_reset
2017-11-05_19:44:54 HM_4BE14C battery: ok
2017-11-05_19:44:54 HM_4BE14C CMDs_done_Errors:1
2017-11-05_19:44:54 HM_4BE14C T: -9.3
2017-11-05_19:44:54 HM_4BE14C dummy
2017-11-05_19:44:54 HM_4BE14C temperature: -9.3
2017-11-05_19:47:49 HM_4BE14C battery: ok
2017-11-05_19:47:49 HM_4BE14C T: -9.5
2017-11-05_19:47:49 HM_4BE14C temperature: -9.5
2017-11-05_19:48:24 HM_4BE14C CMDs_pending
2017-11-05_19:48:24 HM_4BE14C set_reset
2017-11-05_19:48:29 HM_4BE14C R-pairCentral: set_0x000000
2017-11-05_19:48:29 HM_4BE14C CMDs_pending
2017-11-05_19:48:29 HM_4BE14C CMDs_pending
2017-11-05_19:48:29 HM_4BE14C CMDs_pending
2017-11-05_19:49:46 HM_4BE14C Activity: alive
2017-11-05_19:49:46 HM_4BE14C D-firmware: 1.1
2017-11-05_19:49:46 HM_4BE14C D-serialNr: NEQ0534154
2017-11-05_19:49:51 HM_4BE14C Activity: alive
2017-11-05_19:52:15 HM_4BE14C battery: ok
2017-11-05_19:52:15 HM_4BE14C CMDs_pending
2017-11-05_19:52:15 HM_4BE14C T: -9.6
2017-11-05_19:52:15 HM_4BE14C temperature: -9.6
2017-11-05_19:52:20 HM_4BE14C CMDs_pending
2017-11-05_19:54:56 HM_4BE14C battery: ok
2017-11-05_19:54:56 HM_4BE14C T: -9.6
2017-11-05_19:54:56 HM_4BE14C temperature: -9.6
2017-11-05_19:54:58 HM_4BE14C CMDs_pending
2017-11-05_19:57:47 HM_4BE14C set_reset
2017-11-05_19:58:05 HM_4BE14C ResndFail
2017-11-05_19:58:05 HM_4BE14C MISSING ACK
2017-11-05_19:58:10 HM_4BE14C R-pairCentral: set_0x000000
2017-11-05_19:59:10 HM_4BE14C Activity: alive
2017-11-05_19:59:10 HM_4BE14C D-firmware: 1.1
2017-11-05_19:59:10 HM_4BE14C D-serialNr: NEQ0534154
2017-11-05_19:59:15 HM_4BE14C Activity: alive
2017-11-05_20:00:58 HM_4BE14C battery: ok
2017-11-05_20:00:58 HM_4BE14C CMDs_pending
2017-11-05_20:00:58 HM_4BE14C T: -9.8
2017-11-05_20:00:58 HM_4BE14C temperature: -9.8
2017-11-05_20:01:00 HM_4BE14C CMDs_pending
2017-11-05_20:02:09 HM_4BE14C powerOn: 2017-11-05 20:02:09
2017-11-05_20:04:17 HM_4BE14C battery: ok
2017-11-05_20:04:17 HM_4BE14C CMDs_pending
2017-11-05_20:04:17 HM_4BE14C T: -9.8
2017-11-05_20:04:17 HM_4BE14C temperature: -9.8
2017-11-05_20:04:19 HM_4BE14C CMDs_pending
2017-11-05_20:05:54 HM_4BE14C powerOn: 2017-11-05 20:05:54
2017-11-05_20:08:02 HM_4BE14C battery: ok
2017-11-05_20:08:02 HM_4BE14C CMDs_pending
2017-11-05_20:08:02 HM_4BE14C T: -9.6
2017-11-05_20:08:02 HM_4BE14C temperature: -9.6
2017-11-05_20:08:05 HM_4BE14C CMDs_pending
2017-11-05_20:10:57 HM_4BE14C battery: ok
2017-11-05_20:10:57 HM_4BE14C T: -9.6
2017-11-05_20:10:57 HM_4BE14C temperature: -9.6
2017-11-05_20:11:02 HM_4BE14C ResndFail
2017-11-05_20:11:02 HM_4BE14C CMDs_done_Errors:1
2017-11-05_20:11:02 HM_4BE14C MISSING ACK
2017-11-05_20:13:37 HM_4BE14C battery: ok
2017-11-05_20:13:37 HM_4BE14C T: -9.6
2017-11-05_20:13:37 HM_4BE14C temperature: -9.6
2017-11-05_20:16:03 HM_4BE14C battery: ok
2017-11-05_20:16:03 HM_4BE14C T: -9.6
2017-11-05_20:16:03 HM_4BE14C temperature: -9.6
2017-11-05_20:18:14 HM_4BE14C battery: ok
2017-11-05_20:18:14 HM_4BE14C T: -9.6
2017-11-05_20:18:14 HM_4BE14C temperature: -9.6
2017-11-05_20:21:15 HM_4BE14C battery: ok
2017-11-05_20:21:15 HM_4BE14C T: -9.6
2017-11-05_20:21:15 HM_4BE14C temperature: -9.6
2017-11-05_20:24:02 HM_4BE14C battery: ok
2017-11-05_20:24:02 HM_4BE14C T: -9.8
2017-11-05_20:24:02 HM_4BE14C temperature: -9.8
2017-11-05_20:26:34 HM_4BE14C battery: ok
2017-11-05_20:26:34 HM_4BE14C T: -9.8
2017-11-05_20:26:34 HM_4BE14C temperature: -9.8
2017-11-05_20:28:52 HM_4BE14C battery: ok
2017-11-05_20:28:52 HM_4BE14C T: -9.6
2017-11-05_20:28:52 HM_4BE14C temperature: -9.6
2017-11-05_20:30:56 HM_4BE14C battery: ok
2017-11-05_20:30:56 HM_4BE14C T: -9.5
2017-11-05_20:30:56 HM_4BE14C temperature: -9.5
2017-11-05_20:33:49 HM_4BE14C battery: ok
2017-11-05_20:33:49 HM_4BE14C T: -9.5
2017-11-05_20:33:49 HM_4BE14C temperature: -9.5
2017-11-05_20:36:27 HM_4BE14C battery: ok
2017-11-05_20:36:27 HM_4BE14C T: -9.5
2017-11-05_20:36:27 HM_4BE14C temperature: -9.5
2017-11-05_20:38:51 HM_4BE14C battery: ok
2017-11-05_20:38:51 HM_4BE14C T: -9.5
2017-11-05_20:38:51 HM_4BE14C temperature: -9.5
2017-11-05_20:41:01 HM_4BE14C battery: ok
2017-11-05_20:41:01 HM_4BE14C T: -9.5
2017-11-05_20:41:01 HM_4BE14C temperature: -9.5
2017-11-05_20:44:00 HM_4BE14C battery: ok
2017-11-05_20:44:00 HM_4BE14C T: -9.5
2017-11-05_20:44:00 HM_4BE14C temperature: -9.5
2017-11-05_20:46:45 HM_4BE14C battery: ok
2017-11-05_20:46:45 HM_4BE14C T: -9.3
2017-11-05_20:46:45 HM_4BE14C temperature: -9.3
2017-11-05_20:49:16 HM_4BE14C battery: ok
2017-11-05_20:49:16 HM_4BE14C T: -9.5
2017-11-05_20:49:16 HM_4BE14C temperature: -9.5
2017-11-05_20:51:32 HM_4BE14C battery: ok
2017-11-05_20:51:32 HM_4BE14C T: -9.5
2017-11-05_20:51:32 HM_4BE14C temperature: -9.5
2017-11-05_20:53:34 HM_4BE14C battery: ok
2017-11-05_20:53:34 HM_4BE14C T: -9.5
2017-11-05_20:53:34 HM_4BE14C temperature: -9.5
2017-11-05_20:56:25 HM_4BE14C battery: ok
2017-11-05_20:56:25 HM_4BE14C T: -9.5
2017-11-05_20:56:25 HM_4BE14C temperature: -9.5
2017-11-05_20:59:02 HM_4BE14C battery: ok
2017-11-05_20:59:02 HM_4BE14C T: -9.3
2017-11-05_20:59:02 HM_4BE14C temperature: -9.3
2017-11-05_21:01:24 HM_4BE14C battery: ok
2017-11-05_21:01:24 HM_4BE14C T: -9.5
2017-11-05_21:01:24 HM_4BE14C temperature: -9.5
2017-11-05_21:03:32 HM_4BE14C battery: ok
2017-11-05_21:03:32 HM_4BE14C T: -9.3
2017-11-05_21:03:32 HM_4BE14C temperature: -9.3
2017-11-05_21:06:29 HM_4BE14C battery: ok
2017-11-05_21:06:29 HM_4BE14C T: -9.3
2017-11-05_21:06:29 HM_4BE14C temperature: -9.3
2017-11-05_21:09:12 HM_4BE14C battery: ok
2017-11-05_21:09:12 HM_4BE14C T: -9.3
2017-11-05_21:09:12 HM_4BE14C temperature: -9.3
2017-11-05_21:11:41 HM_4BE14C battery: ok
2017-11-05_21:11:41 HM_4BE14C T: -9.3
2017-11-05_21:11:41 HM_4BE14C temperature: -9.3
2017-11-05_21:13:55 HM_4BE14C battery: ok
2017-11-05_21:13:55 HM_4BE14C T: -9.3
2017-11-05_21:13:55 HM_4BE14C temperature: -9.3
2017-11-05_21:16:59 HM_4BE14C battery: ok
2017-11-05_21:16:59 HM_4BE14C T: -9.3
2017-11-05_21:16:59 HM_4BE14C temperature: -9.3
2017-11-05_21:19:49 HM_4BE14C battery: ok
2017-11-05_21:19:49 HM_4BE14C T: -9.3
2017-11-05_21:19:49 HM_4BE14C temperature: -9.3
2017-11-05_21:22:24 HM_4BE14C battery: ok
2017-11-05_21:22:24 HM_4BE14C T: -9.3
2017-11-05_21:22:24 HM_4BE14C temperature: -9.3
2017-11-05_21:24:44 HM_4BE14C battery: ok
2017-11-05_21:24:44 HM_4BE14C T: -9.1
2017-11-05_21:24:44 HM_4BE14C temperature: -9.1
2017-11-05_21:26:50 HM_4BE14C battery: ok
2017-11-05_21:26:50 HM_4BE14C T: -9.3
2017-11-05_21:26:50 HM_4BE14C temperature: -9.3
2017-11-05_21:29:46 HM_4BE14C battery: ok
2017-11-05_21:29:46 HM_4BE14C T: -9.5
2017-11-05_21:29:46 HM_4BE14C temperature: -9.5
2017-11-05_21:32:27 HM_4BE14C battery: ok
2017-11-05_21:32:27 HM_4BE14C T: -9.5
2017-11-05_21:32:27 HM_4BE14C temperature: -9.5
2017-11-05_21:34:54 HM_4BE14C battery: ok
2017-11-05_21:34:54 HM_4BE14C T: -9.5
2017-11-05_21:34:54 HM_4BE14C temperature: -9.5
2017-11-05_21:37:07 HM_4BE14C battery: ok
2017-11-05_21:37:07 HM_4BE14C T: -9.5
2017-11-05_21:37:07 HM_4BE14C temperature: -9.5
2017-11-05_21:40:09 HM_4BE14C battery: ok
2017-11-05_21:40:09 HM_4BE14C T: -9.6
2017-11-05_21:40:09 HM_4BE14C temperature: -9.6
2017-11-05_21:42:56 HM_4BE14C battery: ok
2017-11-05_21:42:56 HM_4BE14C T: -9.6
2017-11-05_21:42:56 HM_4BE14C temperature: -9.6
2017-11-05_21:44:39 HM_4BE14C Activity: alive
2017-11-05_21:44:39 HM_4BE14C D-firmware: 1.1
2017-11-05_21:44:39 HM_4BE14C D-serialNr: NEQ0534154
2017-11-05_21:45:03 HM_4BE14C powerOn: 2017-11-05 21:45:03
2017-11-05_21:47:44 HM_4BE14C R-pairCentral: set_0x000000
2017-11-05_21:48:29 HM_4BE14C Activity: alive
2017-11-05_21:48:29 HM_4BE14C D-firmware: 1.1
2017-11-05_21:48:29 HM_4BE14C D-serialNr: NEQ0534154
2017-11-05_21:48:34 HM_4BE14C Activity: alive
2017-11-05_22:06:40 HM_4BE14C Activity: alive
2017-11-05_22:06:40 HM_4BE14C D-firmware: 1.1
2017-11-05_22:06:40 HM_4BE14C D-serialNr: NEQ0534154
2017-11-05_22:06:40 HM_4BE14C CMDs_pending
2017-11-05_22:06:41 HM_4BE14C CMDs_done
2017-11-05_22:06:45 HM_4BE14C Activity: alive
2017-11-05_22:07:54 HM_4BE14C battery: ok
2017-11-05_22:07:54 HM_4BE14C CMDs_pending
2017-11-05_22:07:55 HM_4BE14C R-burstRx: off
2017-11-05_22:07:55 HM_4BE14C R-cyclicInfoMsgDis: 0
2017-11-05_22:07:55 HM_4BE14C R-pairCentral: 0x1E9DF2
2017-11-05_22:07:55 HM_4BE14C R-paramSel: T1_T2
2017-11-05_22:07:58 HM_4BE14C CMDs_done
2017-11-05_22:07:59 HM_4BE14C CMDs_done
2017-11-05_22:12:36 HM_4BE14C Activity: alive
2017-11-05_22:12:36 HM_4BE14C T1: 9.9
2017-11-05_22:12:36 HM_4BE14C T2: 19.7
2017-11-05_22:12:36 HM_4BE14C T1_T2: -9.8
2017-11-05_22:12:36 HM_4BE14C T2_T1: 9.8
2017-11-06_10:12:36 HM_4BE14C Activity: unknown
2017-11-06_10:12:36 HM_4BE14C T1: 9.9
2017-11-06_10:12:36 HM_4BE14C T2: 19.7
2017-11-06_10:12:36 HM_4BE14C T1_T2: -9.8
2017-11-06_10:12:36 HM_4BE14C T2_T1: 9.8
2017-11-06_10:22:36 HM_4BE14C Activity: dead
2017-11-06_10:22:36 HM_4BE14C T1: 9.9
2017-11-06_10:22:36 HM_4BE14C T2: 19.7
2017-11-06_10:22:36 HM_4BE14C T1_T2: -9.8
2017-11-06_10:22:36 HM_4BE14C T2_T1: 9.8

Gruß Otto

Hallo Otto,

meinst Du, wenn Du nicht "autoReadReg 0_off" für das device verwendest?

Dann kenn ich derzeit keine bessere Lösung, weil der Sensor häufig nach dem Register Read einfach nicht wieder einschläft und damit die Batterie messbar leer saugt.

Wenn Du also mit der Konfiguration für das Ding fertig bist, dann mit "autoReadReg 0_off" für künftige Ruhe sorgen.
So lange Du nichts an dem Sensor umstellen musst, benötigst Du die Registerwerte ja auch nicht.

Gruß, Ansgar.

Ok danke mach ich noch mal so .

Gruß otto

Ok habs prbiert aber nach  halben
Tag wieder vorbei ?
2017-11-07_20:45:48 HM_4BE14C powerOn: 2017-11-07 20:45:48
2017-11-07_20:45:48 HM_4BE14C CMDs_done
2017-11-07_20:45:48 HM_4BE14C T1: 9.9
2017-11-07_20:45:48 HM_4BE14C T2: 19.7
2017-11-07_20:45:48 HM_4BE14C T1_T2: -9.8
2017-11-07_20:45:48 HM_4BE14C T2_T1: 9.8
2017-11-07_20:47:56 HM_4BE14C battery: ok
2017-11-07_20:47:56 HM_4BE14C CMDs_pending
2017-11-07_20:47:56 HM_4BE14C T1: 9.9
2017-11-07_20:47:56 HM_4BE14C T2: 19.7
2017-11-07_20:47:56 HM_4BE14C T1_T2: -9.8
2017-11-07_20:47:56 HM_4BE14C T2_T1: 9.8
2017-11-07_20:47:59 HM_4BE14C CMDs_done
2017-11-07_20:47:59 HM_4BE14C T1: 9.2
2017-11-07_20:47:59 HM_4BE14C T2: 19.7
2017-11-07_20:47:59 HM_4BE14C T1_T2: -10.5
2017-11-07_20:47:59 HM_4BE14C T2_T1: 10.5
2017-11-07_20:48:13 HM_4BE14C sabotageAttack_ErrIoAttack cnt: 1
2017-11-07_20:48:13 HM_4BE14C T1: 9.2
2017-11-07_20:48:13 HM_4BE14C T2: 19.7
2017-11-07_20:48:13 HM_4BE14C T1_T2: -10.5
2017-11-07_20:48:13 HM_4BE14C T2_T1: 10.5
2017-11-07_20:50:51 HM_4BE14C battery: ok
2017-11-07_20:50:51 HM_4BE14C T1: 9.2
2017-11-07_20:50:51 HM_4BE14C T2: 19.7
2017-11-07_20:50:51 HM_4BE14C T1_T2: -10.5
2017-11-07_20:50:51 HM_4BE14C T2_T1: 10.5
2017-11-07_20:50:52 HM_4BE14C sabotageAttack_ErrIoAttack cnt: 4
2017-11-07_20:50:52 HM_4BE14C T1: 9.2
2017-11-07_20:50:52 HM_4BE14C T2: 19.7
2017-11-07_20:50:52 HM_4BE14C T1_T2: -10.5
2017-11-07_20:50:52 HM_4BE14C T2_T1: 10.5
2017-11-07_20:50:52 HM_4BE14C CMDs_done
2017-11-07_20:50:52 HM_4BE14C T1: 9.2
2017-11-07_20:50:52 HM_4BE14C T2: 19.7
2017-11-07_20:50:52 HM_4BE14C T1_T2: -10.5
2017-11-07_20:50:52 HM_4BE14C T2_T1: 10.5
2017-11-07_20:50:52 HM_4BE14C sabotageAttack_ErrIoAttack cnt: 5
2017-11-07_20:50:52 HM_4BE14C T1: 9.2
2017-11-07_20:50:52 HM_4BE14C T2: 19.7
2017-11-07_20:50:52 HM_4BE14C T1_T2: -10.5
2017-11-07_20:50:52 HM_4BE14C T2_T1: 10.5
2017-11-07_20:50:52 HM_4BE14C CMDs_done
2017-11-07_20:50:52 HM_4BE14C T1: 9.2
2017-11-07_20:50:52 HM_4BE14C T2: 19.7
2017-11-07_20:50:52 HM_4BE14C T1_T2: -10.5
2017-11-07_20:50:52 HM_4BE14C T2_T1: 10.5
2017-11-07_20:50:53 HM_4BE14C sabotageAttack_ErrIoAttack cnt: 6
2017-11-07_20:50:53 HM_4BE14C T1: 9.2
2017-11-07_20:50:53 HM_4BE14C T2: 19.7
2017-11-07_20:50:53 HM_4BE14C T1_T2: -10.5
2017-11-07_20:50:53 HM_4BE14C T2_T1: 10.5
2017-11-07_20:50:53 HM_4BE14C CMDs_done
2017-11-07_20:50:53 HM_4BE14C T1: 9.2
2017-11-07_20:50:53 HM_4BE14C T2: 19.7
2017-11-07_20:50:53 HM_4BE14C T1_T2: -10.5
2017-11-07_20:50:53 HM_4BE14C T2_T1: 10.5
2017-11-07_20:50:53 HM_4BE14C sabotageAttack_ErrIoAttack cnt: 7
2017-11-07_20:50:53 HM_4BE14C T1: 9.2
2017-11-07_20:50:53 HM_4BE14C T2: 19.7
2017-11-07_20:50:53 HM_4BE14C T1_T2: -10.5
2017-11-07_20:50:53 HM_4BE14C T2_T1: 10.5
2017-11-07_20:50:53 HM_4BE14C CMDs_done
2017-11-07_20:50:53 HM_4BE14C T1: 9.2
2017-11-07_20:50:53 HM_4BE14C T2: 19.7
2017-11-07_20:50:53 HM_4BE14C T1_T2: -10.5
2017-11-07_20:50:53 HM_4BE14C T2_T1: 10.5
2017-11-07_20:50:54 HM_4BE14C CMDs_done
2017-11-07_20:50:54 HM_4BE14C T1: 9.2
2017-11-07_20:50:54 HM_4BE14C T2: 19.7
2017-11-07_20:50:54 HM_4BE14C T1_T2: -10.5
2017-11-07_20:50:54 HM_4BE14C T2_T1: 10.5
2017-11-07_20:50:55 HM_4BE14C CMDs_done
2017-11-07_20:50:55 HM_4BE14C T1: 9.2
2017-11-07_20:50:55 HM_4BE14C T2: 19.7
2017-11-07_20:50:55 HM_4BE14C T1_T2: -10.5
2017-11-07_20:50:55 HM_4BE14C T2_T1: 10.5
2017-11-07_20:52:37 HM_4BE14C Activity: alive
2017-11-07_20:52:37 HM_4BE14C T1: 9.2
2017-11-07_20:52:37 HM_4BE14C T2: 19.7
2017-11-07_20:52:37 HM_4BE14C T1_T2: -10.5
2017-11-07_20:52:37 HM_4BE14C T2_T1: 10.5
2017-11-08_08:52:38 HM_4BE14C Activity: dead
2017-11-08_08:52:38 HM_4BE14C T1: 9.2
2017-11-08_08:52:38 HM_4BE14C T2: 19.7
2017-11-08_08:52:38 HM_4BE14C T1_T2: -10.5
2017-11-08_08:52:38 HM_4BE14C T2_T1: 10.5
aber woher kommen nun die :sabotageAttack_ErrIoAttack
hab ich seit gestern, nur "autoReadReg
0_off" gestellt.

Gruß otto

Hallo Otto,

ZitatOk habs prbiert aber nach  halben
Tag wieder vorbei ?

Zitathab ich seit gestern, nur "autoReadReg
0_off" gestellt.

Hast Du dem Sensor danach nochmal die Batterien entnommen und nach etwas Wartezeit wieder eingelegt?
Eventuell war er schon im Problemzustand.

Den List vom device HM_4BE14C solltest Du auch mal posten und nicht nur den vom Channel 01, in dem ist nur die temperatur 1 zu sehen.
Denn merkwürdig ist noch das "CMDs_done", da nach einer Temperaturmessage eigentlich nichts passieren sollte.
Vielleicht hast Du noch was im CMD Stack, was abgearbeitet werden will und FHEM dann bei jedem Temperatur-Telegramm versucht.

2017-11-05_21:47:44 HM_4BE14C R-pairCentral: set_0x000000
Das sieht merkwürdig aus.

2017-11-05_22:07:55 HM_4BE14C R-pairCentral: 0x1E9DF2
1E9DF2 ist auch Deine hmId?

Zitataber woher kommen nun die :sabotageAttack_ErrIoAttack

Das ist so wohl schwer zu sagen. Setz mal den verbose Level beim IO hoch, damit die Rohmessages im Log dazu zu sehen sind.

Gruß, Ansgar.

K.A. seit gestern läuft er wieder ohne Probleme durch das Teil hängt aktuell auch nur alleine
am Raspberry mit Funkmodul zum Testen wo die peerIDs
00000000 herkommt weis ich mom auch nicht kommt aber anscheinend von : ( ActionDetector CUL_HM 000000 )
habe ein Fhem installiert mit ein paar extras.

Gruß otto

Hallo Otto,

"pairID" set_000000 ist ein Zwischenzustand.
peerID 00000000 wäre der default Wert für "nix". Der ist immer da  :D

Gruß Otto

Hallo,
Da es hier um Probleme  mit HM-WDS30-OT2-SM geht versuche ich
hier eine Erklärung zu erhalten.
Ich habe 2 Sensoren, die ich für einen Bodenfeuchtemesser umrüsten möchte.
Dazu habe ich erst einmal beide komplett zusammen gebaut um zu sehen ob sie funktionieren.
Als erster Punkt erscheint mir das peering sehr ominös.
Nach 4 sek drücken blinkt die rote LED. Es kommt keine Verbindung zu Stande.
Nach erneutem drücken leuchtet die LED orange. Nach mehreren Versuche klappt es dann.
Beide Sensoren zeigen auf T1 und T2 unterschiedliche Temperaturen und zwar eine richtige T
und die zweite sehr weit darüber. Kanal 5 zeigt auf State ????.
Kann mir jemand an Hand der list´s sagen, wo das Problem liegt?
Internals:
   DEF        5C3708
   IODev      HMLAN1
   NAME       HM_5C3708
   NOTIFYDEV  global
   NR         182
   NTFY_ORDER 50-HM_5C3708
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_5C3708_T1
   channel_02 HM_5C3708_T2
   channel_03 HM_5C3708_T1_T2
   channel_04 HM_5C3708_T2_T1
   channel_05 HM_5C3708_Event
   READINGS:
     2018-04-29 08:01:13   Activity        dead
     2018-04-26 14:00:30   CommandAccepted yes
     2018-04-26 12:06:21   D-firmware      1.1
     2018-04-26 12:06:21   D-serialNr      OEQ0673599
     2018-04-26 14:00:32   PairedTo        0x2CD99B
     2018-04-26 12:08:55   R-burstRx       off
     2018-04-26 12:08:55   R-cyclicInfoMsgDis 0
     2018-04-26 12:08:55   R-pairCentral   0x2CD99B
     2018-04-26 12:08:55   R-paramSel      T1_T2
     2018-04-26 14:00:32   RegL_00.        01:00 02:01 0A:2C 0B:D9 0C:9B 11:00 18:00 1B:03  00:00
     2018-04-27 11:26:58   battery         ok
     2018-04-26 13:57:32   powerOn         2018-04-26 13:57:32
     2018-04-26 13:57:32   recentStateType info
     2018-04-26 14:00:34   state           CMDs_done
   helper:
     HM_CMDNR   122
     mId        00A8
     regLst     ,0
     rxType     140
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5C3708,00,00,00
       prefIO     
       rxt        2
       vccu       
       p:
         5C3708
         00
         00
         00
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   01,02,03,04,05
       qReqStat   
     role:
       dev        1
     tmpl:
Attributes:
   IODev      HMLAN1
   actCycle   012:00
   actStatus  dead
   autoReadReg 0_off
   expert     2_raw
   firmware   1.1
   model      HM-WDS30-OT2-SM
   room       CUL_HM
   serialNr   OEQ0673599
   subType    THSensor
   webCmd     getConfig:clear msgEvents 

  Internals:
   CFGFN     
   DEF        5C373F
   HMLAN1_MSGCNT 23
   HMLAN1_RAWMSG E5C373F,0000,02F9EEF1,FF,FFD0,0386535C373F000000004100DE4201D443FF0A4400F6
   HMLAN1_RSSI -48
   HMLAN1_TIME 2018-04-29 09:51:07
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     23
   NAME       HM_5C373F
   NOTIFYDEV  global
   NR         252
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_5C373F_T1
   channel_02 HM_5C373F_T2
   channel_03 HM_5C373F_T1_T2
   channel_04 HM_5C373F_T2_T1
   channel_05 HM_5C373F_Event
   lastMsg    No:03 - t:53 s:5C373F d:000000 004100DE4201D443FF0A4400F6
   protLastRcv 2018-04-29 09:51:07
   protResnd  1 last_at:2018-04-29 09:46:39
   protSnd    16 last_at:2018-04-29 09:47:29
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:23 min:-48 max:-40 avg:-42.34 lst:-48
   READINGS:
     2018-04-29 09:47:45   Activity        alive
     2018-04-29 09:47:24   CommandAccepted yes
     2018-04-29 09:47:45   D-firmware      1.1
     2018-04-29 09:47:45   D-serialNr      OEQ0673656
     2018-04-29 09:47:25   PairedTo        0x2CD99B
     2018-04-29 09:47:25   R-burstRx       off
     2018-04-29 09:47:25   R-cyclicInfoMsgDis 0
     2018-04-29 09:47:25   R-pairCentral   0x2CD99B
     2018-04-29 09:47:25   R-paramSel      T1_T2
     2018-04-29 09:47:25   RegL_00.          01:00 02:01 0A:2C 0B:D9 0C:9B 11:00 18:00 1B:03  00:00
     2018-04-29 09:51:07   battery         ok
     2018-04-29 09:47:29   state           CMDs_done
   helper:
     HM_CMDNR   3
     PONtest    1
     cSnd       012CD99B5C373F0403,012CD99B5C373F0503
     mId        00A8
     regLst     ,0
     rxType     140
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5C373F,00,00,00
       nextSend   1524988267.58998
       prefIO     
       rxt        2
       vccu       
       p:
         5C373F
         00
         00
         00
     mRssi:
       mNo        03
       io:
         HMLAN1:
           -40
           -40
     prt:
       bErr       0
       sProc      0
       try        1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rssi:
       at_HMLAN1:
         avg        -42.3478260869565
         cnt        23
         lst        -48
         max        -40
         min        -48
     shadowReg:
     tmpl:
Attributes:
   IODev      HMLAN1
   actCycle   012:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.1
   model      HM-WDS30-OT2-SM
   room       CUL_HM
   serialNr   OEQ0673656
   subType    THSensor
   webCmd     getConfig:clear msgEvents

Danke
Gruß Michael

Hallo Michael,

das er auf Kanal 5 als State ??? zeigt ist bei mir auch so. Ich hatte bisher keine Verwendung für diesen Kanal.
Wenn beide Sensoren im gleichen Wasserglas stecken sollte der Unterschied zwischen beiden Temperaturen im Bereich der Toleranz liegen

ZitatGenauigkeit:   ±3 K (2x ±1,5 K)

Was passiert wenn Du beide Sensoren mal vertauschst?

Zum Anlernen ein Zitat aus dem Handbuch  ;D

ZitatZum Anlernen halten Sie die Konfigurationstaste kurz (<4 s)
gedrückt. Dauerhaftes oranges Blinken der Geräte-LED signalisiert
den Anlernmodus.
·

Gruß Otto

Hallo Otto,
T1=28,5
T2=16,1
Das sind die aktuellen Werte im Gewächshaus beide Fühler nebeneinander.
Gruß Michael

Gesendet von meinem SM-G935F mit Tapatalk

Die Differenz ist zu groß. Bei mir beträgt die Differenz derzeit 0,1 K (18 grad C)
Das ist bei beiden Sensoren so?
Was ist wenn Du die Thermofühler A gegen B tauschst?

Gruß Otto

Zitat von: Otto123 am 29 April 2018, 20:36:22
Die Differenz ist zu groß. Bei mir beträgt die Differenz derzeit 0,1 K (18 grad C)
Das ist bei beiden Sensoren so?
Was ist wenn Du die Thermofühler A gegen B tauschst?

Gruß Otto

Umhören?

Gesendet von meinem SM-G935F mit Tapatalk

 Umhören? ???

Zitat von: Otto123 am 29 April 2018, 21:00:43
Umhören? ???

Oha🤣🤣🤣
umlöten

Gesendet von meinem SM-G935F mit Tapatalk

Ach ja stimmt - die sind ja angelötet. Naja zumindest kontrollieren ob die Lötstellen sauber sind.

Die Fühler sind ja bloß Widerstände aus meiner Sicht müsste der Fehler beim Tauschen mitwandern.

Was hast Du für Flussmittel verwendet?

Gruß Otto

Nur Lötzinn. Ich könnte aber die Widerstände messen, mit ausgebauten Batterien



Gesendet von meinem SM-G935F mit Tapatalk

Moin,

die Frage ist ja: Es betrifft zwei Geräte richtig? Beide zeigen die Abweichung? Du hast ja nur die Fühler angelötet, wenn es an denen nicht liegt (was ich auch nicht glaube) liegt es an den Leiterplatten. An denen hast Du nichts gemacht, wenn die falsch sind ist das ein Fall für Retoure. Dann sind diese eventuell im Werk falsch bestückt?

Du kannst auch optisch kontrollieren ob R8 und R9 wirklich denn gleichen Widerstandswert  haben.

Gruß Otto

Hallo Otto,
So ich habe jetzt die Temperaturfühler gemessen.
T1=10,9
T2=11,9
R8/9 3,8
soll 3,9, die Abweichung ist entweder mein
Multimeter oder eine Toleranz.
In °C gemessen im Wasserglas
T1=36,9°C
T2=28,2°C
Abweichung laut Datenblatt +-0,3
Bei der Abweichung könnte ich von der Sache her umtauschen.
Der zweite WDS ist ausgestiegen. Bei eingelegten Batterien blinkt die rote LED.
Der geht zurück.
Gruß Michael

Hallo Michael,

ich finde nur diese Angaben im Datenblatt:

ZitatGenauigkeit @ -30 bis +100 °C: ±4 K (2x ±2,0 K)
Genauigkeit @ 0 bis +80 °C: ±2 K (2x ±1,0 K)

Ich denke auch, Du solltest zurück schicken.

Gruß Otto

Mir fällt noch ein (habe ich früher bei gleichartigen Sensoren schon mal gelesen):
beim WDS30-TO habe ich diesen Hinweis gesehen:

Zitat*Hinweis: Der Sensor ist nicht für dauerhaftes eintauchen in Wasser geeignet.

Gruß Otto

Hallo Otto,
Die 0,3°C habe ich bei ELV HM.....Ersatzteil Datenblatt gefunden. Übrigens ist der niedere Wert zu einem Vergleichswert auch noch um 4°zu hoch.
Gruß Michael

Gesendet von meinem SM-G935F mit Tapatalk

Das die Abweichung viel zu hoch ist, ist keine Frage.
Allerdings finde ich auch diese Abweichung zu hoch:

ZitatT1=10,9
T2=11,9

Du könntest noch testen, ob das Modul an sich funktioniert indem Du einfach die Thermofühler durch zwei gleiche Widerstände (ca. 10 kOhm) ersetzt.

Gruß Otto

Was soll dann angezeigt werden?
Gruß Michael

Gesendet von meinem SM-G935F mit Tapatalk

Moin,

na auf alle Fälle auf beiden Kanälen die gleiche Temperatur und die Differenz nahe null.
Irgendetwas um die 25 °C

Die Fühler sind aus meiner Sicht kalibrierte  NTC 10 kOhm sonst wären sie ja nicht als Ersatzteil lieferbar und austauschbar.

Gruß Otto

Ich Depp, 🤣🤣🤣Hast Du natürlich Recht.
Gruß Michael

Gesendet von meinem SM-G935F mit Tapatalk

Ich will nochmal auf das Ursprungsproblem zurückkommen, was ich eben erst wahrgenommen habe:

Meine beiden Diff-Sensoren mit Firmware 1.1 laufen mit autoReadReg = 4_reqStatus gefühlt seit Jahren stabil. Zurücksetzen musste ich noch nie.
Ich hatte mal in einem ausgelaufene Batterien, allerdings hatte ich dort den battery Level = 0 mehr als einen Monat ignoriert, ohne dass das Gerät seine Funktion einstellte. Die Batterien taten auch noch, als sie suppten. Also schließe ich einen unbemerkten Aufhänger hier auch aus.

Jm2c

Hallo,
Es gibt aber auch nicht wenige Leute mit
Problemen. Oder denkst Du die sind hausgemacht. Was ich mir eigentlich nicht vorstellen kann. Auf alle Fälle geht erst mal ein Gerät zurück. Das andere bleibt zur Beobachtung.
Gruß Michael

Gesendet von meinem SM-G935F mit Tapatalk

mit welchem buchstaben fängt denn die seriennummer an? vielleicht alte b-ware.

edit: gerade gesehen, fangen mit O an. sollten zumindestens nicht sehr alt sein.

Natürlich gibt es genug Leute mit dem Problem, aber es betrifft eben auch nicht alle. Ich wollte nur Infos zu problemlosem Betrieb geben. Meiner Series beginnen mit LEQ und MEQ.

Hallo,
Meine Geräte fangen mit OEQ an.
Habe heute das Problem tel. geschildert.
Wie gesagt der tote Sensor geht zurück und
den anderen behalte ich noch etwas zur Beobachtung.
Gruß Michael