HM-LC-SW1-PL - Steckdose schaltet manchmal nicht, liefert off zurück

[martinp876]

Hall Daniel,

weil die Steckdose bleibt ja aus wenn dieser Fehler auftritt.

das hatte ich falsch verstanden. Ich dachte sie bleibt endlos an, da der Status "on" kommt. Das ist SEHR unschön, ein falscher status!

Könnte dennoch klappen.

falls du den optionalen Taster nicht nutzt es ok/gewünscht ist ihn einem onTimer zu hinterlegen (also aus nach x sec) kann man das "press" ohne virtuellen Taster realisieren.

Gruss Martin

[ext23]

das hatte ich falsch verstanden. Ich dachte sie bleibt endlos an, da der Status "on" kommt

Nee der Status on kommt ja gerade nicht, das ist es ja, der meldet alles richtig, siehste ja in meinen Logs, der sagt 0% und off als Rückgabe... deswegen meinte ich ja, eigentlich müsste FHEM sowas abfangen, ich meine wenn ich sage Dose geh an und sie antwortet mit ich bin aus, dann ist ja irgend was falsch gelaufen. Dann könnte man ja quasi das Paket nochmal wiederholen.

Gruß
Daniel

[martinp876]

Hallo Daniel,

das ist ein komplett neuer Level der Überwachung. Ich bin etwas vorsichtig. Es gibt da VIELE Varianten. Im SunnyDayScenarion klappt dies. Aber es gibt auch die hässlichen:
dimmer set 100%, ramp 20sec, nach 10 sec drückt jemand am lokalen schalter Stop. Es kommt NIE 100% zurück - was nun? Overrule den lokalen Bediener?
Bei onForTimer kann die Zeot so kurz sein, das kein ON kommt sondern nur stop
Rollos können beim Fahren jederzeit lokal und ohne sichtbare Meldung gestoppt werden.

=> FHEM ist nicht die einzige Steuerquelle
=> nicht alle Schaltkommandos sind sichtbar, z.B. lokale Taster
=> selbst sichtbare trigger können nicht (nur schwer) einem Device zugeordnet werden. Ein trigger muss nicht zwingend die Destination addresse beinhalten!!!

Aus diesen Gründen, die mit so auf die Schnelle einfallen kann ich dies auf keinen Fall generell einbauen. Nachdem du eh OnForTimer nutzt ist dies noch komplexer. Soll das Ausschalten auch überwacht werden? Müsste dann wohl - wenn man überwacht dann richtig. Sonst weiss keiner, was FHEM nun eigentlich treibt und welchen Level wir überwachen.

Zu deinem Problem: es tritt ausschliesslich bei on-for-timer auf - korrekt. Dann können wir hier evtl ansetzen.

Gruss Martin

[ext23]

Genau nur bei on-for-timer. Naja ich werd mir da was in Perl basteln was das selber überwacht, ist ja nicht so dramatisch, nur eben unschön. Wäre ja nur mal interessant zu wissen wo hier der Fehler liegt. Nun habe ich zwei Steckdosen und bei beiden sporadisch das Problem, das find ich schon komisch.

Gruß
Daniel

[martinp876]

ich werde auch noch einmal nachdenken.
Die Überwachung von On kann ich nicht einbauen. Aber bei on-for-timer überlege ich, ob ich timedOn überwachen kann. Das ist ein erheblich kleinerer Brocken. Und man kann erkennen, dass das Kommando nicht korrekt übertragen wurde, gleich im ACK. Das ist eine gnz andere Baustelle, klingt machbar.

Wenn ich etwas habe melde ich mich.

Gruss Martin

[martinp876]

Hi,

probier einmal die Datei im Anhang. Wenn es einen Fehler gibt kommt ein Eintrag im Logfile. Ausserdem sollte wiederholt werden.

Ausserdem werden fehler/wiederholungen in protTimedOn addiert.
Bitte ausführlich testen. Es ist allgemein eingebaut. Nach SVN kommt es erst nach der Testphase.

Gruss Martin

[ext23]

Alles klar, danke, ich werd es testen. Das dauert aber ein bissel, die Fehler treten ja nur sporadisch auf. Ich werde das Schaltinervall bzw. die Anzahl der Schaltvorgänge etwas anpassen um somit mehr von diesen Fehlern zu provozieren.

Gruß
Daniel

[martinp876]

gut.
wie gesagt, sollte FHEM noch einmal senden, kann man es in den proto... variablen nachlesen, und im Log.
Gruss Martin

[ext23]

Guten Morgen,

so heute war wohl mal wieder so ein Tag wo es nicht funktioniert:

automatisch via AT getriggert:
2013-08-25_10:00:00 bz_Handtuchtrockner set_on-for-timer 14400
2013-08-25_10:00:00 bz_Handtuchtrockner NACK
2013-08-25_10:00:05 bz_Handtuchtrockner NACK
2013-08-25_10:00:08 bz_Handtuchtrockner MISSING ACK

dann manuell über FHEM:
2013-08-25_12:24:23 bz_Handtuchtrockner set_on-for-timer 7200
2013-08-25_12:24:24 bz_Handtuchtrockner level: 100 %
2013-08-25_12:24:24 bz_Handtuchtrockner deviceMsg: on (to HMLAN1)
2013-08-25_12:24:24 bz_Handtuchtrockner on
2013-08-25_12:24:24 bz_Handtuchtrockner timedOn: running

[martinp876]

Hi,

war die neue SW schon drin?
Das sieht aber nach einem anderen Fehler aus.
Zum einen NACK: Das device hat das Kommand empfangen aber nicht akzeptiert.
2. missing ACK: FHEM hat seine 3 Versuche gemacht, aber nie eine Antwort erhalten (die NACKS sind als "no answer" nicht wirklich korrekt berücksichtigt)

Das ganze ist nicht das gleiche wie bei den vorigen Problemen.
Sonst hat das Device das Kommando akzeptiert, aber mit "falschem" on-timer.

Ich nehme an, das sind alle logs -also war es nicht das missing-timer event.

Gruss Martin

[ext23]

Ich kann dir noch die Debug Ausgabe vom gloaben Log geben in diesem Zeitbereich (wenn das Hilft):
Kann natürlich sein das hier parallel noch nen anderes Problem bestand...

2013.08.25 10:00:00 2: CUL_HM set bz_Handtuchtrockner on-for-timer 14400
2013.08.25 10:00:00 1: HMLAN_Send:  HMLAN1 I:+19C753,00,00,
2013.08.25 10:00:00 1: HMLAN_Send:  HMLAN1 S:SB47C9D50 stat:  00 t:00000000 d:01 r:B47C9D50 m:05 A011 23FF23 19C753 0201C800008CA7
2013.08.25 10:00:00 1: HMLAN_Parse: HMLAN1 R:RB47C9D50 stat:0001 t:20EA22A6 d:FF r:FFBF     m:05 8002 19C753 23FF23 010100003F
2013.08.25 10:00:00 1: General missed timedOn for bz_Handtuchtrockner
2013.08.25 10:00:02 1: HMLAN_Send:  HMLAN1 S:SB47CA60E stat:  00 t:00000000 d:01 r:B47CA60E m:05 A011 23FF23 19C753 0201C800008CA7
2013.08.25 10:00:02 1: HMLAN_Parse: HMLAN1 R:RB47CA60E stat:0001 t:20EA2B62 d:FF r:FFBF     m:05 8002 19C753 23FF23 010100003F
2013.08.25 10:00:05 1: HMLAN_Send:  HMLAN1 S:SB47CB0DB stat:  00 t:00000000 d:01 r:B47CB0DB m:05 A011 23FF23 19C753 0201C800008CA7
2013.08.25 10:00:05 1: HMLAN_Parse: HMLAN1 R:RB47CB0DB stat:0001 t:20EA362F d:FF r:FFC1     m:05 8002 19C753 23FF23 010100003C
2013.08.25 10:00:05 1: General missed timedOn for bz_Handtuchtrockner
2013.08.25 10:00:09 1: HMLAN_Parse: HMLAN1 R:E1D2544   stat:0000 t:20EA48E9 d:FF r:FFBE     m:EF 8670 1D2544 000000 00FC30
2013.08.25 10:00:15 1: HMLAN_Send:  HMLAN1 I:K
2013.08.25 10:00:15 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:20EA5CAA IDcnt:0006

/Daniel

[martinp876]

Hallo Daniel,

in diesem Log ist klar zu sehen, dass der Timer nicht akzeptiert ist. Das Kommando wird 2-mal wiederholt, ohne Änderung.
Das flag "timedOn" kommt nicht

Stellt sich die Frage ob es generell funktioniert. Hast du einmal einen "gutfall"?
also kannst du einmal

set bz_Handtuchtrockner on-for-timer 1440
absetzen? danach kannst du wieder "off" schicken und es noch einmal probieren

Ein Problem 'könnte' sein, dass die messagenummer nicht hochgezählt wird und der Aktor das 2.Kommando zwar noch einmal beantwortet, aber nicht verarbeitet. Da müsste ich noch nachbessern.

Schicke einmal einen gutfall für die Akten

Gruss Martin

[ext23]

Gerne, das ist von heute morgen wo es mal wieder funktioniert hat (via AT job):

2013-08-26_07:00:00 bz_Handtuchtrockner set_on-for-timer 14400
2013-08-26_07:00:00 bz_Handtuchtrockner level: 100 %
2013-08-26_07:00:00 bz_Handtuchtrockner deviceMsg: on (to HMLAN1)
2013-08-26_07:00:00 bz_Handtuchtrockner on
2013-08-26_07:00:00 bz_Handtuchtrockner timedOn: running

global log:

2013.08.26 07:00:00 2: CUL_HM set bz_Handtuchtrockner on-for-timer 14400
2013.08.26 07:00:00 1: HMLAN_Send:  HMLAN1 I:+19C753,00,00,
2013.08.26 07:00:00 1: HMLAN_Send:  HMLAN1 S:SB8FE2DCF stat:  00 t:00000000 d:01 r:B8FE2DCF m:05 A011 23FF23 19C753 0201C800008CA7
2013.08.26 07:00:00 1: HMLAN_Parse: HMLAN1 R:RB8FE2DCF stat:0001 t:256BDCBE d:FF r:FFC2     m:05 8002 19C753 23FF23 0101C8403B
2013.08.26 07:00:00 1: HMLAN_Parse: HMLAN1 R:E1D259A   stat:0000 t:256BDCDC d:FF r:FFB8     m:47 8670 1D259A 000000 00F028
2013.08.26 07:00:09 1: HMLAN_Send:  HMLAN1 I:K
2013.08.26 07:00:09 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:256C01BD IDcnt:0007
2013.08.26 07:00:20 1: HMLAN_Parse: HMLAN1 R:E1D259A   stat:0000 t:256C2AFF d:FF r:FFB8     m:47 A258 1D259A 1D22C4 0000
2013.08.26 07:00:20 1: HMLAN_Parse: HMLAN1 R:E1D22C4   stat:0000 t:256C2B83 d:FF r:FFC2     m:47 8202 1D22C4 1D259A 010100003E
2013.08.26 07:00:34 1: HMLAN_Send:  HMLAN1 I:K
2013.08.26 07:00:34 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:256C636C IDcnt:0007

[martinp876]

ok, also generell liefert der Trockner schon zurück, dass wir im timer-mode sind. Dachte es so gesehen zu haben.
Ich werde eine Version bauen, in der die Message-nummer geaendert wird... mal sehen, ob das den Tockner beieindurckt.

Jedenfalls ist die Erkennung schon einmal ok - die Protokoll-events sollten zu sehen gewesen sein.

Gruss Martin

[martinp876]

probier einmal den Anhang. Mal sehen, ob sich der Trockner überreden lässt

Gruss Martin