[gelöst] HM-CC-VD Batterietest --> LowBat - Anzeige Bug?

Begonnen von Billy, 29 Januar 2013, 14:55:07

Vorheriges Thema - Nächstes Thema

Billy

Hallo,

nachdem ich der Meinung bin, dass eine funktionierende Heizung einen höheren Stellenwert
in der Beobachtung von Störungen hat, habe ich mit Messaufbau in Anlage den Umschaltpunkt
von der Anzeige Battery - ok zu Battery low ausgemessen. --> bei 2,4V siehe Anlage (Messanordnung)

(siehe Anhang / see attachement)

Überaschenderweise musste ich feststellen, dass trotz der Battery - low Anzeige auf den Devices
TC und VD in FHEM battery - ok angezeigt wurde!

(siehe Anhang / see attachement)

Der Event Manager --> 2013-01-29 14:45:49 CUL_HM UG_WS_HK battery: ok

--> Bug? siehe Anlage (Screenshot_Readings VD.png)

Als ich die Batteriespannung weiter reduziert habe, kam auf dem VD die Anzeige F4 + Battery low.
In diesem Fall zeigte dann FHEM auch im Event Manager "battery low" an.
Das wäre m.E. jedoch deutlich zu spät!

Vielleicht kann noch jemand das Verhalten reproduzieren?
Die Bilder habe ich übrigens mit meinem NEXUS 10 erstellt.

Gruss Billy

FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

martinp876

wenn ich es richtig verstehe kommt ein batlow alarm - nur der Level ist nicht ok.
Damit waere die Anzeige in FHEM entsprechend den von HM gemeldeten Daten.

Du gehst also von einem Bug in HM aus, nicht in FHEM - korrekt? FHEM bekommt nur einen status gut/schlecht, keine Messwerte

Billy

Hallo Martin,

Zitatwenn ich es richtig verstehe kommt ein batlow alarm - nur der Level ist nicht ok.
nach meinem Verständnis kommt der bat-low alarm über FHEM eben nicht bzw. zu spät!
Der bat-low Alarm über FHEM sollte ja eigentlich m.E. signalisiert werden wenn das Batteriesymbol in den Devices erscheint,
was nicht der Fall ist. Siehe: --> Der Event Manager --> 2013-01-29 14:45:49 CUL_HM UG_WS_HK battery: ok
und nicht erst wenn im Display des VD die Fehlermeldung F4+Batteriesymbol angezeigt wird.

ZitatDu gehst also von einem Bug in HM aus, nicht in FHEM - korrekt?
Ich stecke nicht tief genug in der Materie um beurteilen zu können wo genau das Problem liegt?

Gruss Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

martinp876

Ich kann nicht beurteilen, wann HM den Bat-zustand meldet. FHEM kann die Messages auswerten. Wenn hier ein Bug drin ist koennen wir etwas machen. Ich habe verstanden, dass der BAtterieEvent gemeldet wird, wenn auch zu spät fuer dich.... leider

FHEM scheint also richtig auszuwerten - was auch immer HM sendet.

Du kannst gerne noch einmal raw-messages schicken mit der Beschreibung wie der aktuelle Zustand  der Batterie ist. Wenn mehr Info in der MEssage ist sollte wir die finden koennen. Wenn nicht musst du dich an HM wenden.
Einstellbar ist es meines wissens nicht - und das Batteriesymbol kann man nicht auslesen.

Gruss
Martin

Billy

Hallo Martin, danke für die Antwort.

Zitat von: martinp876 schrieb am Mi, 30 Januar 2013 17:50FHEM kann die Messages auswerten. Wenn hier ein Bug drin ist koennen wir etwas machen.
Das glaube ich auch!
ZitatIch habe verstanden, dass der BAtterieEvent gemeldet wird, wenn auch zu spät fuer dich.... leider
Das müsste m.E. eigentlich alle treffen, merkt man ja nicht unbedingt.
ZitatDu kannst gerne noch einmal raw-messages schicken mit der Beschreibung wie der aktuelle Zustand  der Batterie ist. Wenn mehr Info in der MEssage ist sollte wir die finden koennen.
Ich bin mir fast sicher, dass da was zu machen ist. Der HM-CC-VD schickt ja schon bei der Stufe 1 (nur Batteriesymbol) Daten zum TC,
sonst könnte dort ja nicht das Batteriesymbol angezeigt werden? Wie gesagt habe es heute morgen nochmals verifiziert der lowbat Alarm
und damit auch die Alarm Mails kommen erst bei der Stufe 2 wenn das Batteriesymbol zusammen mit F4 auf der VD Anzeige erscheint.

Ich nehme an du benötigst nur die RAW Daten des VD'? (Oder auch des TC ?)
Ich würde dir zum Vergleich gerne die Daten auf der Basis:
Batterie voll,
Batterie leer (Stufe 1)
Batterie leerer (Stufe2) Zusenden!
Wenn du mir bitte den notwendigen Befehl oder die Befehle nennen könntest.
Bei UG_WS_HK regRaw bekomme ich die Meldung  "outdated - use regBulk with changed format"
Aber vielleicht war das ja der falsche Befehl?

Grüsse Billy

FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Billy

So sieht übrigens die Anzeige Stufe 2 aus wenn der LowBat Alarm kommt.


(siehe Anhang / see attachement)


Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

martinp876

ja, raw traces

attr global mseclog 1
attr global verbose 1
attr <hmlan> hmProtocolEvents 1
attr <hmlan> loglevel 1

Ist das Batterie-symbol des TC auf den VD bezogen? hatte gedacht es betrifft den TC und dessen Batterie

wir werden sehen (hoffe ich:-))

Gruss
Martin

Billy

Hi Martin,
Danke für die Antwort!
Zitat von: martinp876 schrieb am Mi, 30 Januar 2013 22:35ja, raw traces
OK Bin nicht sicher ob ich das bis morgen Abend noch schaffe mit den raw traces, bin ausser Haus! (Dienstreise)
ZitatIst das Batterie-symbol des TC auf den VD bezogen? hatte gedacht es betrifft den TC und dessen Batterie
Das hatte ich auch gedacht, ist aber nicht so, der TC an sich hat m.E. keine eigene Batterieüberwachung!
Da hilft wohl nur regelmässiger Batteriewechsel?
Siehe auch meine Antworten in: Batteriewarnung HM-TC-CC? [Beitrag #55572]
Deswegen habe ich ja auch die detaillierten Messungen unternommen. Diese haben das jetzt bestätigt.
Deswegen bin ich auch überzeugt, dass der VD die Stufe 1 meldet.
Gruss
Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Billy

Hallo Martin,

anbei die raw traces. --> es geht immer um den UG_WS_HK DEF   1DA3DD  serialNr JEQ0555778

um ca. 6:45 ging es los mit Voller Batterie!
um ca. 6:56 ging er auf stufe 1 mit 43% bei 2,39V Batteriespannung

um ca. 7:57 ging er auf Stufe 2  bei 2,28V Batteriespannung
    --> die erste lowbat Meldung kam um 7:59 --> FHEM Batteriewarnung UG_WS_HK battery: low'
    Da scheint dann der TC auch zu piepsen?

Um ca. 8:04 wieder volle Batteriespannung und Normalbetrieb!

Hoffe das wars und hilft.

Gruss Billy


FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

dougie


@Billy

Sauberer Versuchsaufbau! Gute Arbeit! :-)

VG
Ralf

martinp876

Hallo Billy

wirklich gut.

Ich habe den VD erraten, glauben ich. Ist der 1DA3DD - richtig?
Da wird zur Beschriebenen Zeit 0x80 gesetzt. und später 0x88.
Die x08 ist beschrieben, die 0x80 nicht.
Kann ich einbauen. Mal prüfen ob dies auch für andere Typen gilt.

Dann brauchen wir noch einen level - 'low' und 'critical' - andere Vorschläge?

Da werden noch mehr Bits gesetzt...
ist noch etwas passiert?
Gruss
Martin


Billy

Zitat von: martinp876 schrieb am Do, 31 Januar 2013 22:57Hallo Billy

wirklich gut.

Ich habe den VD erraten, glauben ich. Ist der 1DA3DD - richtig?
Ja, hatte ich auch oben im letzten Beitrag erwähnt.
ZitatDa wird zur Beschriebenen Zeit 0x80 gesetzt. und später 0x88.
Die x08 ist beschrieben, die 0x80 nicht.
Kann ich einbauen. Mal prüfen ob dies auch für andere Typen gilt.
Super, aber vor endgültiger Freigabe sollte ich das testen!
ZitatDann brauchen wir noch einen level - 'low' und 'critical'
Das passt, d.h. Stufe 1 (nur Batterieanzeige) -->low; Stufe 2 (F4+Batterieanzeige) --> critical, da kurz vor dem Aussteigen.

ZitatDa werden noch mehr Bits gesetzt... ist noch etwas passiert?
Ja, hatte zuerst die Batteriespannung zu schnell reduziert, dann ging er von Stufe1 gleich auf F4 d.h. Fehlermeldung,
dann bin ich wieder auf volle Batteriespannung und langsamer runter bis zur Stufe 2.
Deswegen sollte ich die erste Implementierung der Stufe 2 testen.

Freut mich dass du weiterkommst
Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

martinp876

Hi,

habe noch einmal nachgesehen - die Bits sind alle klar. Das ist die Motorsteuerung
motor:opening
motor:closing
motor:stop

dann noch die Fehlermeldungen (die kommen wohl auch im Display als F nummern)
1 motorErr:blocked                
2 motorErr:loose                  
3 motorErr:adjusting range too small
4 battery:low                

und die Normale Batterie-warnung

das kann ich direkt einstellen. Es ist eigentlich nur, dass zur bekannten Batterie-warnung - wie bei anderen auch - die critical dazu kommt. Leider fehlt dies in XML. Ist eben nicht vollständig

steht bereit

Billy

Hallo Martin, toll schnell wie immer

mein Vorschlag war ja das umzudrehen?
Zitat von: martinp876 schrieb am Fr, 01 Februar 2013 07:46Hi,
und die Normale Batterie-warnung
Es ist eigentlich nur, dass zur bekannten Batterie-warnung - wie bei anderen auch - die critical dazu kommt.
steht bereit
Super, kann aber erst am Montag testen, da ich übers Wochenende fortfahre.
Anregung:
Die bisherige Warnung zu Critical, die neue zu low.
Grund: Die bisherige low ist zu nahe am Ausfall und m.E. deshalb viel kritischer als die neue Batterie Warnung (Nur Batteiesymbol).
Der Benutzer merkt von der Umstellung m.E. ja nichts, da LowBat nur etwas früher kommt und man mehr Reaktionszeit zum Austausch der Batterien hat. Was hältst du davon?

Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

martinp876

Namensgebung...
Batterieueberwachung...
und das Verhalten der HM devices.

Bekannt ist bei einigen devices, dass sie eine batLow melden, das ist auch implementiert.
Hier wird immer das gleich Bit ueberwacht und es gibt bat "low" event. Was ich nicht weiss ist, wie der jeweilige level deviniert ist.
Daher sehe ich folgendes als gegeben:
- die 0x80 ist "low" - so wie bei allen HM devices, die dies melden, da sollten wir nicht aendern.
- der VD ist der einzige mit der erweiterten Option - daher koennen/muessen wir hier einen weiteren Level einbauen. In der aktuellen Version habe ich "critical" dafuer drin, kann aber noch geaendert werden, da bin ich (fast) leidenschaftslos. Es sollte nur "schlimmer" bedeuten als "low".

Besondere devices in Hinsicht Batterie sind noch sec_sfa = da kann man die Limits sogar einstellen und ein paar "ba" devices. Ob die das auch im "status" wert schicken muss ich nachsehen.