HM-WDS100-C6-O Wetterstation ==> "Einfrieren" und notify Problem

[jhs]

Hallo Martin,

die Logs mit sniffing habe ich erzeugt und schicke Dir die gezippten files via dropbox und Dropbox-Link (pm', OK ?) Leider - Murphy's Law - bekomme ich von der Dropbox die Meldung:
> Dropbox is under maintenance.

# wetterstation_local 123456 # model HM-WDS100-C6-O
# logging set to sys,wetterstation_local
#
# # HMLAN
attr global verbose 1
attr global mseclog 1
attr LAN_0 logIDs 123456,sys
# # CUL
attr global verbose 1
attr global mseclog 1
attr CUL_0 verbose 4

Aus dem GesamtLog von heute - relevanter Anteil ab "Sniffing ON" - aufgeteil in 4 Logs

# log 1 OK mit
# $Id: 10_CUL_HM.pm 9474 2015-10-17 09:27:25Z martinp876 $

# log 2 mit
# # $Id: 10_CUL_HM.pm 9904 2015-11-15 14:05:15Z martinp876 $
# console 'update'

# log 3 mit
# $Id: 10_CUL_HM.pm 9904 2015-11-15 14:05:15Z martinp876 $

# log 4 bis WDS100 'dead' (nach ein < 30 Minuten)
#   Der erwartete 'dead' Moment nach 'update' und 'shutdown restart' mit der Version
Wetterstation Activity unknown 2015-11-21 18:10:34
Wetterstation Activity dead    2015-11-21 18:20:35

fhem und LOGGING STOPPED
backup wieder eingespielt (FHEM_2015-10-19_1_OK.d,)

# mit RestorDir FHEM_2015-10-19-1.d/*  ALLES OK
# $Id: 10_CUL_HM.pm 9474 2015-10-17 09:27:25Z martinp876 $
           incl. aktueller 99_my_utils.pm von heute

Auch die funktionierende 10_CUL_HM.pm kann die Wetterstation nicht zum Leben erwecken, also "rauf auf den Mast ..."

Gruss
jhs

[jhs]

Nachtrag

nach der  fhem-2015-11.log --Session von vorhin und  dann nach Wiedereinspielen der bis dahin tagelang funktionierenden Alt-Version

# $Id: 10_CUL_HM.pm 9474 2015-10-17 09:27:25Z martinp876 $

hat sich die Wetterstation HM-WDS100-C6-O leider doch wieder abgemeldet:

Activity dead 2015-11-22 00:18:33

(Mehrfach, nach Reanimation PowerOff, reset-button ... das ist kein toller Winter-Job)
Die Aussage zum  Zusammenhang von Status "dead" und dieser Version von 10_CUL_HM.pm muss dann neu bewertet werden.

jhs

[Bennemannc]

Hallo,

ich lese hier schon eine ganze Weile mit. Ich habe auch diese Wetterstation - und wenn ich nicht mit zwei fhem-Installationen parallel arbeite, läuft das Teil sauber durch (bis die Batterien leer sind). Ich habe es mit fhem gepairt und mit dem Wetterdisplay gepeert.
Kann es sein, das die Wetterstation irgendwie komisch reagiert, wenn sie keinen peer hat ? Sind die FW Versionen der Wetterstation gleich (habe 1.4) oder hat HM da mal etwas geändert ? Irgendwie muss ma da doch mal hinter kommen was da nicht läuft. Wenn ich nicht soviel HM Geraffel hätte, könnte ich ja nur den Funkverkehr von der Wetterstation und dem Wetterdisplay mitschneiden.
@Martin Geht das ?

Gruß Christoph

[martinp876]

klar geht das.
http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen

attr global verbose 1
attr global mseclog 1
attr <hmlan> logIDs all,sys

also einfach anstatt "all" eine Liste der IDs eintragen (natürlich nur die Liste der Devices!!!, keine Channels).
sys koennte auch interessant sein.

Code Auswählen Erweitern

attr myHmlan 123456,222222,01BEEF,sys,AABBCC

[Bennemannc]

Hallo Martin,

ok - also die ID vom Sensor, Display - muss die ID vom HMLAN auch mit rein oder kommen die Antworten von fhem mit sys ?

Gruß Christoph

[jhs]

Hallo,

Reanimation der WDS100: Status 'alive' (nach 'dead') nur per power-on-reset an der WDS100 möglich.

Nochmals per cmd abgesetz, um das peering sicher zu stellent:

set wetterstation_local peerChan 1 VCCU_HM_Btn3 single set
set wetterstation_local regSet stormUpThresh  39  VCCU_HM_Btn3

(# reset button an der wds100 gedrückt zur Übergabe =nicht vergessen)

Wie vorher:

R-VCCU_HM_Btn3-stormLowThresh 25 2015-11-22 10:07:00
R-VCCU_HM_Btn3-stormUpThresh 39  2015-11-22 10:07:00
peerList VCCU_HM_Btn3,           2015-11-22 00:00:54

Attributes
IODev LAN_0
IOgrp VCCU_HM:CUL_0
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 1.4
model HM-WDS100-C6-O
peerIDs 00000000,<HM_ID>

und dann als Ergebnisa leider: Activity dead 2015-11-22 10:18:41

Leider wie schon gesagt nun auch der 'dead' Effekt mit der "bisher funktionierenden" Version  10_CUL_HM.pm 9474 2015-10-17 09:27:25Z.
D.h. "Zurück auf Start", oder ?


Aber die Anmerkungen zu den Batterien hat mich in eine andere Richtung suchen lassen
das erste 'dead' Erlebnis mit der WDS-100: Ende 08/2015 installiert und schon Ende 10/2015 die (mitgelieferten) Batterien leer; (auf diese Ursache bin ich auch nicht sofort gekommen.)
Ersetzt, und heute auf Verdacht daher nochmals nachgeprüft (Ansmann Checker): nur noch  30% (nach nur 3 Wochen Betrieb!)
Suchen wir da vielleicht in die falsche Richtung ? HW-defekt, oder zuviel Traffic-cycle?, d.h. Ursache für 'dead' ist Batterie (schon wieder) leer und kein Fehler in 10_CUL_HM.pm ?
Und kann die Ursache für die schnelle Entladung in falscher Konfig liegen ?
Einen Alarm auf Batterie LOW habe ich meines Wissens von der WDS100 nicht erhalten (oder nicht bemerkt).

jhs

[jhs]

Hallo,

nach dem unterwartet notwendigem 2.ten Wechseln der - nach 2 Monaten bzw. nach <1 Monat schon wieder schwachen - Batterien hat die WDS100 mit den frischen Batterien immerhin schon 2h durchgehalten und auch das 'update' und 'shutdown restart' überlebt, siehe unten.
(Batterien: bei Zimmertemp. immerhin wieder statt draussen bei Kälte 30% jetzt erwartungsgemäss zwischen 40-50%)

Um die Richtung "Energieverbrauchs-Problem, bedingt durch SW/HW?"  mal zu verfolgen habe ich soeben ein Fhem 'update' eingespielt:
Ob wir dann die erst vermutete Ursache auf Unterschiede in den o.g. Versionen von 10_CUL_HM.pm ausschliessen könnnen, wird sich bald herausstellen

Bliebe dann die Frage, wo kommt der hohe Energieverbrauch der WDS100 her ?

jhs

[Bennemannc]

Hallo,

ein Grund könnte wiederholtes Senden sein - also ein Reichweitenproblem. Bei mir halten die Batterien auch nicht lange (gefühlsmäßig 6 Monate), aber 2 Monate ist schon sehr wenig.

Gruß Christoph

[frank]

ich würde mal den antennendraht der wetterstation nach aussen führen und spezielle batterien für niedrige temperaturen einsetzen.
bei manchen devices kann man die wiederholung der messages des devices über register konfigurieren. aber batterien sparen durch verringerung der wiederholungen wegen schlechter funkstrecke wiederspricht sich natürlich.

[jhs]

Hallo,

da seit seit über 30 Minuten die WDS100 auch nach dem update und absichtlichen rereadcfg noch läuft, schliesse ich nun daraus, dass nicht die Unterschiede in den o.g. Versionen von 10_CUL_HM.pm die Ursache für 'dead'  der WDS sind.

Gemessen an meinen RSSI-Infos und Entfernung der WDS dürfte hier gute Antennen-Verhältnisse vorliegen.  Jetzt - im Unterschied Betriebsstandort (Mast, noch näher am CUL) und  Test-Standort (WDS drinnen in der Garage) - hat sich die Funkentfernung nur um ca. 2m verschoben, von CUL_0 in Richtung LAN_0, also von der Funkstreckenlänge nicht besonders relevant:

CUL_0_MSGCNT 30
CUL_0_RSSI -49
CUL_0_TIME 2015-11-22 13:13:17
IODev CUL_0
LAN_0_MSGCNT 30
LAN_0_RSSI -51
LAN_0_TIME 2015-11-22 13:13:18
LASTInputDev LAN_0
...
actCycle 000:10

Ich meine, das sind doch gute Werte, die keine Modifikation an der Antenne erfordern, oder ?
Beim actCycle ist doch auch mit dieser default Einstellung nicht so oft mit Senden.

Bleibt eigentlich nach Euren Anmerkungen nur übrig, die Anlage "fremd" mit Energie zu versorgen, wenn man nicht ständig auf den Mast will. Irgendwie finde ich das Design der Hardware bzgl. Energieverbrauch und -Quelle nicht ganz angemessen und nachvollziehbar, bei dem üblichen nicht ganz leicht zugänglichen Montageort, zum Beispiel im Vergleich zu einem hm_cc_rt_dn. Und es scheint ja nicht nur meine WDS100 diese Stromfresser-Eigenschaft zu haben.
Ein Readings "battery: ok' ist mir auch nicht bei der WDS100 aufgefallen.

Vielleicht gibt es so ein wetterfestes kleines Solar-Popwerpack, das man noch gut am Mast anbringen könnte.

jhs

[frank]

Beim actCycle ist doch auch mit dieser default Einstellung nicht so oft mit Senden.

das attr nimmt keinen einfluss auf den funkverkehr. es wird vom actiondetector benutzt.
es gibt dem actiondetektor ein zeitfenster vor, in welchem eine message vom device erkannt werden muss, damit der actiondetektor kein dead meldet.

die rssi sagen nichts über die funkqualität aus. auch die reine entfernung kannst du nicht vergleichen. wer weiss, wie überlagernde störfelder an anderen positionen aussehen. ausserdem die ausrichtungen beider antennen zueinander nehmen einfluss. zudem haben die antennen eine räumliche charakteristik. ausserdem zeigt dein rssi eintrag nur den letzten wert an. es muss auch ein eintrag mit min, max, avg, cnt geben.

häufige wiederholungen können auch an schlechtem timing liegen (cul). die einzig sinnvolle analyse ist, rawmessages zu sniffen. dann sieht man genau, was empfangen und gesendet wird. dann auch mit beiden io's, um die ack's vom hmlan zu sehen.

[jhs]

... soweit habe ich das verstanden.

peerList VCCU_HM_Btn3
protLastRcv 2015-11-22 16:00:15
protSnd 5 last_at:2015-11-22 13:22:58
protState CMDs_done
rssi_at_CUL_0 avg:-52.25 min:-53.5 max:-51.5 lst:-52.5 cnt:68
rssi_at_LAN_0 avg:-49.82 min:-51 max:-49 lst:-50 cnt:68

An Martin habe ich gestern via dropbox die angeforderten Logs geschickt; hoffentlich in dem Format, wie es gebraucht wird.
Sicherlich, Funk-Störnebel kann auch vorhanden sein, aber keines der vielen anderen Devs im gleichen Umkreis macht diese Probleme, auch nicht mein Selbstbau-Pyrometer auf Basis hm_wds30_ot2 auf demselben Mast, unterhalb der WDS100.

rssi_at_CUL_0 avg:-58.42 min:-59 max:-58 lst:-58.5 cnt:65
rssi_at_LAN_0 avg:-64.76 min:-68 max:-63 lst:-64 cnt:65

Den Energiebedarf der WDS100 bei 3xAAA Zellen und das im Vergleich zu aktiven Heizkörperventilen (hm_cc_rt_dn: Funk-Protokoll + Motor, und das nur mit 2xAA) kann ich deshalb auch nicht nachvollziehen.
Ich hoffe nur, meine Diagnosemöglichkeiten, zusammen mit der Hilfe des Forums reichen aus, eine Lösung für das Problem zu finden, auch für die anderen, bei denen sich das Problem ähnlich anhört.

jhs

[martinp876]

du hast alles der CUL geloggt, nicht aber alle des HMLAN.

[jhs]

Hallo,
meine WS100 ist  nach aktuellem 'update', aber mit frischen Batterien schon seit etlichen Stunden 'alive'.
Frage daher eher, was saugt die Batterien so schnell leer. Der unterwartet frühe, "zappelnde"  langsame Übergang der Batterien in den too-low-Zustand wird wohl die Ursache für die  bisher nicht erklärbaren 'dead's gewesen sein, oder ?

Nun der 2.te Versuch, ein ausführliches Log zu erzeugen

# # HMLAN
attr global verbose 1
attr global mseclog 1
attr LAN_0 verbose 4
attr LAN_0 logIDs 123456,sys
#
# # CUL
attr global verbose 1
attr global mseclog 1
attr CUL_0 verbose 4

Logging läuft. Und Logfile geht dann wie gewünscht per dropbox an Martin. Viel wird sich nicht ändern an den Messwerten der WDS während des Loggings, da ich die Station abgenommen und das Teil während der Testphase drinnen steht.

Frage noch zum Thema nebenbei: im Wiki findet man die Aussage: Übermittlung des Batteriestatus
http://www.fhemwiki.de/wiki/HM-WDS100-C6-O_Funk-Kombi-Sensor_OC3
Ich habe da bisher nichts dergleichen gefunden. Andere Forumsbesucher suchten auch danach schon vergebens. Die Funktion wäre echt nützlich.

http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Kombisensor-OC-3_83346_Produktdatenblatt.pdf
Dieses Datenblatt sagt auch nichts von "Übermittlung Batteriestatus",  sondern spricht von ca. 2 Jahren Batterielebensdauer (nur 1 Monat mit Markenbatterien/Ansmann ist dann doch eine grosse Abweichung)

http://forum.fhem.de/index.php?topic=38390.0
In diesem  thread bittet Martin um logging bei 'battery low'. Ist so etwas schon vorhanden, ansonsten, "zufällig" habe ich hier gerade ein paar solcher Batterien rumliegen und mit denen setze ich nun das logging fort. Hoffentlich stellt sich dann erwartungsgemäss  das "battery low" und "dead"  ein , zusammen mit verbünftigen LOG-Daten.

jhs

[martinp876]

Habe noch keine batlow logs.