HM-LC-SW1-PL2 ungehorsam...

[mergat]

Hi all,

ein Hallo in die Runde von einem neuen Neuling... 

ich habe ein Verständnisproblem mit einem HM-LC-SW1-PL2.

Generell läuft das System (FHEM,FB7390,CUL) mit mehreren Devices recht gut. Nur der eine Schalter erweist sich als etwas unzuverlässig. Um 17:54 wurden einige Lampen per CUL eingeschaltet und um 23:55 wieder aus. Die o.a. eine Lampe war aber noch an, die anderen haben reagiert.
Daraufhin habe ich sie einmal direkt Hardwareseitig ausgeschaltet (00:29) und testweise noch einmal über die Weboberfläche (00:37).

Im FHEM Log war schön zu sehen das der Befehl raus ging. Im Log des Schalters ist der "set_off" auch angekommen. Aber frech antwortet das Ding mit "on".
Wer kann mir diesen "Ungehorsam" erklären? 


2014-01-31_17:54:55 og_flur_stehlampe set_on
2014-01-31_17:54:55 og_flur_stehlampe level: 100 %
2014-01-31_17:54:55 og_flur_stehlampe deviceMsg: on (to CUL_0)
2014-01-31_17:54:55 og_flur_stehlampe on
2014-01-31_17:54:55 og_flur_stehlampe running: -
2014-01-31_23:55:00 og_flur_stehlampe set_off
2014-01-31_23:55:00 og_flur_stehlampe level: 100 %
2014-01-31_23:55:00 og_flur_stehlampe deviceMsg: on (to CUL_0)
2014-01-31_23:55:00 og_flur_stehlampe on
2014-01-31_23:55:00 og_flur_stehlampe running: -
2014-02-01_00:29:52 og_flur_stehlampe level: 0 %
2014-02-01_00:29:52 og_flur_stehlampe deviceMsg: off (to broadcast)
2014-02-01_00:29:52 og_flur_stehlampe off
2014-02-01_00:29:52 og_flur_stehlampe running: -
2014-02-01_00:36:49 og_flur_stehlampe set_on
2014-02-01_00:36:49 og_flur_stehlampe level: 100 %
2014-02-01_00:36:49 og_flur_stehlampe deviceMsg: on (to CUL_0)
2014-02-01_00:36:49 og_flur_stehlampe on
2014-02-01_00:36:49 og_flur_stehlampe running: -
2014-02-01_00:37:09 og_flur_stehlampe set_off
2014-02-01_00:37:09 og_flur_stehlampe level: 0 %
2014-02-01_00:37:09 og_flur_stehlampe deviceMsg: off (to CUL_0)
2014-02-01_00:37:09 og_flur_stehlampe off
2014-02-01_00:37:09 og_flur_stehlampe running: -


Vielen Dank,

Mergat

[martinp876]

Hi Mergat,

sollte nicht sein. Die Lampe war auch noch an? Ist also kein Fehler in der Darstellung?
ist es reproduzierbar?
Möglich wäre es, wenn jemand lokal gedrückt hat - zeitgleich - aber das ist sehr unwahrscheinlich.  Alles andere sollten wir sehen.
So es reproduzierbar ist, bitte die rohmessages aufzeichnen.

Gruss Martin

[mergat]

Hallo Martin,

gezielt reproduzierbar ist es leider nicht. Generell funktioniert alles wie gewünscht. Aber 2-3 mal habe ich dieses Verhalten schon beobachtet. Kann das ggfs eine Funkstörung sein oder würde der Aktor bei "unvollständigen" Nachrichten garnicht reagieren?

Ja, die Lampe war noch an als wäre nichts gewesen... 

Ich habe mir schon etwas Sorgen gemacht, das dieses Verhalten u.U. systembedingte und zu tolerierende "Unschärfen" wären die durch Statusnachfragen gelöst werden müssten.

Ich behalte das im Auge und werde raw loggen wenn es mir wieder auffällt.

Vielen Dank,

Mergat

[martinp876]

Hallo Mergat,

ja, bitte verfolgen. Soche Dinge stellen die Zuverlässigkeit in Frage und sind somit wichtig.
Hierzu behalten auch die protocoll-events im Auge. Am einfachsten (mein ich jedenfalls) mit HMInfo:

define hm HMInfo
set hm protoEvents short

löschen/neu starten mit
set hm clear msgStat

Filter sind auch möglich. Alle Devices mit "licht" im Namen löschen:
set hm -f licht clear msgStat

Gruss Martin

[hdo]

Hallo,

genau dieses Verhalten konnte ich heute morgen auch beobachten.
Ich schalte meine Aussenlampen per 'at'-Befehl und heute morgen waren die Lampen noch an,
obwohl die gestern um 23:xx Uhr ausgehen sollten.

Im Log ist auffällig, dass nach einem 'set_off' Befehl der Level noch auf 100% steht, obwohl es eigenltich 0% sein sollte.
Um 06:45 Uhr habe ich die Lampen dann manuell ausgeschaltet. Dort waren die Level nach dem 'set_off' Befehl
korrekterweise 0%.

Code Auswählen Erweitern


2014-03-05_23:11:24 SW.AUSSEN.SEITEN set_off
2014-03-05_23:11:24 SW.AUSSEN.SEITEN level: 100 %
2014-03-05_23:11:24 SW.AUSSEN.SEITEN deviceMsg: on (to HMLAN1)
2014-03-05_23:11:24 SW.AUSSEN.SEITEN on
2014-03-05_23:11:24 SW.AUSSEN.SEITEN running: -
2014-03-06_06:46:22 SW.AUSSEN.SEITEN set_off
2014-03-06_06:46:22 SW.AUSSEN.SEITEN level: 0 %
2014-03-06_06:46:22 SW.AUSSEN.SEITEN deviceMsg: off (to HMLAN1)
2014-03-06_06:46:22 SW.AUSSEN.SEITEN off
2014-03-06_06:46:22 SW.AUSSEN.SEITEN running: -


2014-03-05_23:11:24 SW.AUSSEN.TERASSE set_off
2014-03-05_23:11:24 SW.AUSSEN.TERASSE level: 100 %
2014-03-05_23:11:24 SW.AUSSEN.TERASSE deviceMsg: on (to HMLAN1)
2014-03-05_23:11:24 SW.AUSSEN.TERASSE on
2014-03-05_23:11:24 SW.AUSSEN.TERASSE running: -
2014-03-06_06:46:18 SW.AUSSEN.TERASSE set_off
2014-03-06_06:46:18 SW.AUSSEN.TERASSE level: 0 %
2014-03-06_06:46:18 SW.AUSSEN.TERASSE deviceMsg: off (to HMLAN1)
2014-03-06_06:46:18 SW.AUSSEN.TERASSE off
2014-03-06_06:46:18 SW.AUSSEN.TERASSE running: -


hdo

[martinp876]

hallo hdo,

- du hast eine sehr neue Version am Laufen? Dann sollte ein resend automatisch erfolgen
- der resend sollte im generellen logfile dokumentiert werden so du verbose auf 3 laufen hast

=> kannst du im log nachsehen, ob um 23:11 eintraegen zu finden sind?

Gruss Martin

p.s.
kannst du die rohmessages eine schaltens wie im at befehl verwendet aufzeichnen? Nur zur Kontrolle ob der mechanismus greifen wuerde

[Deudi]

Hallo,

wollte nur mal bestätigen, dass ich das Problem auch schon hatte. Einmal mit einem Zwischenstecker (Schalter), einmal mit einem Unterputz-Schalter. Daher habe ich eine zeitverzögerte Prüfung implementiert, die nach 10 Sekunden kontrolliert und ggf. nachbessert. Siehe: http://forum.fhem.de/index.php/topic,20809.0.html
Reproduzierbar ist es nicht. Hatte es zweimal innerhalb von 6 Monaten.

Gruß Deudi

[martinp876]

Hi Deudi,

FHEM prueft es sofort - wenn der Endzustand erreicht ist. Ein Test nach 10 sec ist also eigentlich nicht erforderlich.
Beruecksichtigt werden timedOn und dimmer/rollo fahrzeiten/rampen.
Sollte es noch schief gehen bitte im Log nachsehen und die Events melden.

Gruss Martin

[Deudi]

Wenn es passiert, bekomme ich derzeit eine Mail. Seit meinem letzten Update (8.2.) ist es nicht mehr vorgekommen.
Reicht dir grundsätzlich die Information falls das noch vorkommt (ich mache nochmal ein Update) oder brauchst du einen bestimmten Loglevel bzw. Rohmessages?

Zwar hattest du das Verhalten HMLAN/FHEM bzgl. Resend etc. schon mal irgendwo geschrieben, aber vielleicht kannst du mal gaaanz kurz das Verhalten am Beispiel Lichtschalter schreiben (kontrolle auf Ack, auf state oder ...).

1000 Dank und Gruß
Deudi

[martinp876]

Hi Deudi,

Es gibt verschiedene resends. Der Allgemeine reagiert auf ACKs - aber in dem speziellen Fall sendet das device ein ACK und macht es trotzdem falsch.

Das ist also eine Ebene hoeher. Beim Setzen eines Levels (on/off ist auch ein Level) wird dieser gespeichert. Voraussetzung ist, dass es nicht mit timern hinterlegt ist (on-for-timer...) .
Beim Empfangen wird dann geprueft, ob der Endzustand erreicht ist (dimmer koennten eine Rampe fahren, Rollos 'rolloen'...). So autoReadReg eingeschaltet ist wird in jedem Fall auf einen Endzustand gewartet (Ruhezustand = dimmerRampe fertig, Rollo steht, kein Timer im Aktor am Laufen). Jetzt sollte der gesetzte Level dem gemeldeten entsprechen. Ist dem nicht so wird das Set wiederholt und ein logeintrag (level 3) geschrieben. Sollte der Zustand nach dem Senden immer noch nicht erreicht werden wird ein Reading
levelMissed:desired:<value>
gesetzt.
Es gibt nur eine Wiederholung. Man kann den Fehler provozieren, wenn man vor Beendigung der Aktion einen trigger aud einer gepeerten remote schickt und gegensteuert. Kommandos aus der Zentrale werden beruecksichtigt.

Mehr als ein Wiederholung ist fahrlaessig - insbesondere bei Rollos:
set Rollo runter=> faehrt
=> press Button Rollo Hoch => faehrt hoch
+ stop oben => check = false, automatic senden 'runter' => Rollo faehrt runter


Gruss Martin

[hdo]

Hallo Martin,

vielen Dank für dein Feedback. Ich bin noch sozusagen Neuling im Bereich FHEM.

Ich habe die Version 5.5 (von der Webpage)  auf einem RPi laufen. Ich habe auch noch keine Updates gemacht.

- der resend sollte im generellen logfile dokumentiert werden so du verbose auf 3 laufen hast

=> kannst du im log nachsehen, ob um 23:11 eintraegen zu finden sind?

Hmm, ich habe alles im Standard gelassen gehabt, da die Installation noch neu ist.
Ich muss mir mal anschauen, wie ich das Log-Level umstellen kann.

p.s.
kannst du die rohmessages eine schaltens wie im at befehl verwendet aufzeichnen? Nur zur Kontrolle ob der mechanismus greifen wuerde

Wie zeichne ich denn die Rohdaten auf?

Das Problem ist mir bisher nur einmal aufgefallen, da ich die Installation noch recht frisch habe.
Ich habe die Lampen mit dem 'at'-Befehl im Zusammenspiel mit 'sunset(0,"17:00","22:00")' angeschaltet was auch
funktioniert hat.

Die Lampen habe ich dann versucht mit 'at *00:15:00' auszuschalten. Mittlerweile lasse ich die Lampen mit 'sunset() + offset' ausschalten.

2 Weitere Anregungen/Probleme sind mir noch aufgefallen:

1). Es wäre schön, wenn die Erweiterung '99_TimeUtils.pm' im Standard mit aufgenommen werden würde

2). Bei der 'sunset()' Funktion ist mir aufgefallen, dass ein 'modulo 24' fehlt, denn ich hatte zwischenzeitlich "42:41:15" erhalten. Dieser
Wert wird korrekt von 'at' verabeitet, aber bei '99_TimeUtils.pm' wird ein Fehler ausgegeben.

hdo

[martinp876]

Ich habe auch noch keine Updates gemacht

dann wird es höchste Zeit - mache einmal einen und wir sehen weiter...

Rohdaten wie in
http://forum.fhem.de/index.php/topic,16563.0.html

Gruss Martin