HM-WDS30-OT2-SM steigt immer wieder aus / Plötzlich keine Funktion

[NoKi]

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

[A.Harrenberg]

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.

[frank]

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...

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.

[A.Harrenberg]

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.

[Bennemannc]

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

[martinp876]

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.

[sash.sc]

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 !

Code Auswählen Erweitern

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

[sash.sc]

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

[sash.sc]

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

[noansi]

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.

[sash.sc]

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

[sash.sc]

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

[noansi]

Hallo Sascha,

Kannst 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

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.

[schwatter]

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:

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.

[Otto123]

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