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

Begonnen von ext23, 19 Juli 2013, 09:31:03

Vorheriges Thema - Nächstes Thema

ext23

Hallo,

ich habe mal eine Frage zu folgendem Log. 18.07. hat alles richtig geschaltet, heute aber nicht. Kann mir das einer erklären woran das liegt? Das habe ich öfter mal.

2013-07-18_07:00:00 bz_Handtuchtrockner set_on-for-timer 14400
2013-07-18_07:00:00 bz_Handtuchtrockner CommandAccepted: yes
2013-07-18_07:00:00 bz_Handtuchtrockner level: 100 %
2013-07-18_07:00:00 bz_Handtuchtrockner deviceMsg: on (to HMLAN1)
2013-07-18_07:00:00 bz_Handtuchtrockner on
2013-07-18_11:00:41 bz_Handtuchtrockner level: 0 %
2013-07-18_11:00:41 bz_Handtuchtrockner deviceMsg: off (to broadcast)
2013-07-18_11:00:41 bz_Handtuchtrockner off

2013-07-19_07:00:00 bz_Handtuchtrockner set_on-for-timer 14400
2013-07-19_07:00:00 bz_Handtuchtrockner CommandAccepted: yes
2013-07-19_07:00:00 bz_Handtuchtrockner level: 0 %
2013-07-19_07:00:00 bz_Handtuchtrockner deviceMsg: off (to HMLAN1)
2013-07-19_07:00:00 bz_Handtuchtrockner off

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

martinp876

leider kann ich nichts erkennen.
Wie war der Zustand vor anschalten?
Ist es reproduzierbar?

ext23

leider kann ich nichts erkennen.
--> das kann ich verstehen.

Wie war der Zustand vor anschalten?
--> Aus

Ist es reproduzierbar?
--> Wenn ich mir das Log der letzte Tage so anschauen kommt es alle 2 Wochen ca 1 mal vor. Und das Teil schaltet jetzt Tag 1 mal.

Aber ich verstehe auch FHEM nicht, ich hätte gedacht der sendet das nochmal wenn er merkt die Dose ist aus. Also wenn ich ein set_on-for-timer 14400 mache und kurz danach kommt ein off zurück ist ja was nicht normale. Dann könnte man das Kommando doch nochmal senden.

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

martinp876

Hallo Daniel,

ZitatAber ich verstehe auch FHEM nicht, ich hätte gedacht der sendet das nochmal wenn er merkt die Dose ist aus
nein, macht es nicht. Es bekommt von Device eine Quittung, dass die Nachricht angekommen ist. Wenn keine Quittung kommt wird wiederholt.
Was nicht gemacht wird, ist den Status prüfen. Geht auch ganz schlecht. Selbst bei onForTimer könntest du 1 sec einstellen - da kommt als Status off weil die1 sec zu langsam ist. Wäre sehr komplex.

Was enttäuschend ist, dass HM eine message quittiert und nicht bearbeitet. HM MUSS diesen Level bringen. Wenn eine Nachricht ordnungsgemäß gesendet und quittiert wurde muss auch entsprechend agiert werden. Das ist ja der Witz der Quittung
Evtl kannst du loglevel 1 bei HMLAN einstellen. Dann kann ich beim nächsten Auftreten schauen, ob irgendetwas seltsam ist.

Gruss Martin

ext23

-->Selbst bei onForTimer könntest du 1 sec einstellen - da kommt als Status off weil die1 sec zu langsam ist. Wäre sehr komplex.

Naja stimmt schon, aber gerade wenn sowas passiert würde sich das ja lohnen umzusetzen, aber vermutlich bin ich der einzige mit diesem Problem ;-)

Ich mach das mal und melde mich wenn die Sache wieder auftritt.

Viele Grüße
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

Also das Problem habe ich jetzt immer häufiger, jetzt mal mit Loglevel 1:

2013-08-03_10:00:00 bz_Handtuchtrockner set_on-for-timer 14400
2013-08-03_10:00:00 bz_Handtuchtrockner level: 0 %
2013-08-03_10:00:00 bz_Handtuchtrockner deviceMsg: off (to HMLAN1)
2013-08-03_10:00:00 bz_Handtuchtrockner off

2013.08.03 09:59:56 1: HMLAN_Parse: HMLAN1 R:E1D259A   stat:0000 t:AF9A16EF d:FF r:FFA7     m:6F A410 1D259A 23FF23 06022600000000
2013.08.03 09:59:59 1: HMLAN_Send:  HMLAN1 I:K
2013.08.03 09:59:59 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:AF9A221E IDcnt:0006
2013.08.03 10:00:00 2: CUL_HM set bz_Handtuchtrockner on-for-timer 14400
2013.08.03 10:00:00 1: HMLAN_Send:  HMLAN1 I:+19C753,00,00,
2013.08.03 10:00:00 1: HMLAN_Send:  HMLAN1 S:S4330B54F stat:  00 t:00000000 d:01 r:4330B54F m:01 A011 23FF23 19C753 0201C800008CA7
2013.08.03 10:00:00 1: HMLAN_Parse: HMLAN1 R:R4330B54F stat:0001 t:AF9A2588 d:FF r:FFC3     m:01 8002 19C753 23FF23 010100003A
2013.08.03 10:00:24 1: HMLAN_Send:  HMLAN1 I:K
2013.08.03 10:00:24 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:AF9A83D4 IDcnt:0006
2013.08.03 10:00:41 3: Bodenfeuchtemessung: value 90.547263681592
2013.08.03 10:00:41 3: Timer_ba_Wassertonne: status 0

Vielleicht kannst du hier noch was erkennen, ansonsten würde ich die Steckdose mal Stromlos machen.

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

martinp876

hm, mal sehen.

Kannst du mir einmal einen log schicken, wenn es klappt? Mich interessiert die Antwort des Device.
Es reicht ein
set bz_Handtuchtrockner on-for-timer 5

Mal sehen, ob mir etwas einfällt

Gruss Martin

Nachtrag: Ich denke, ich habe gesehen wie man erkennen kann dass der Zustand Temporär ist, also dass ein interner Timer läuft. Das könnte in ein Reading ausgegeben werden. Somit könntest du es mit einem Notify überwachen. Ob ich eine Generelle Lösung in CUL_HM einbaue ist mir noch nicht klar.
Ich warte auf deine Logs

Gruss Martin

ext23

Gerne doch:

2013-08-03_14:05:36 bz_Handtuchtrockner set_on-for-timer 7200
2013-08-03_14:05:37 bz_Handtuchtrockner level: 100 %
2013-08-03_14:05:37 bz_Handtuchtrockner deviceMsg: on (to HMLAN1)
2013-08-03_14:05:37 bz_Handtuchtrockner on

2013.08.03 14:05:36 2: CUL_HM set bz_Handtuchtrockner on-for-timer 7200
2013.08.03 14:05:36 1: HMLAN_Send:  HMLAN1 S:S44119351 stat:  00 t:00000000 d:01 r:44119351 m:05 A011 23FF23 19C753 0201C800008CA6
2013.08.03 14:05:37 1: HMLAN_Parse: HMLAN1 R:R44119351 stat:0001 t:B07B0B9A d:FF r:FFC4     m:05 8002 19C753 23FF23 0101C8403B

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

Also ich hab dasselbe Problem bei einer anderen Steckdose auch:

2013-08-11_16:46:41 sz_Giessanlage set_on-for-timer 400
2013-08-11_16:46:41 sz_Giessanlage level: 0 %
2013-08-11_16:46:41 sz_Giessanlage deviceMsg: off (to HMLAN1)
2013-08-11_16:46:41 sz_Giessanlage off
2013-08-11_16:46:41 sz_Giessanlage timedOn: off

Scheint also nicht an der Steckdose zu liegen...
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

martinp876

es gibt das "neue" event 'timedOn'. kannst du prüfen, ob dies 'normal' gesetzt wird? Es sollte auf "on" stehen, wenn du "on-for-timer" nutzt.

Also kommt es immer wenn es klappt und bleibt aus, wenn es fehlschlägt?

Gruss Martin

ext23

Hi Martin,

mhh das habe ich jetzt nicht so ganz verstanden was du wissen möchtest.

Also es stimmt, in dem letzten Log von mir bei der anderen Dose gibt es diese neue Log Meldung, da hat es nicht funktioniert und timedOn steht auf off.

Jetzt habe ich es mal manuell gemacht und dann steht es auf:

2013-08-19_20:54:00 bz_Handtuchtrockner set_on-for-timer 7200
2013-08-19_20:54:00 bz_Handtuchtrockner level: 100 %
2013-08-19_20:54:00 bz_Handtuchtrockner deviceMsg: on (to HMLAN1)
2013-08-19_20:54:00 bz_Handtuchtrockner on
2013-08-19_20:54:00 bz_Handtuchtrockner timedOn: running

Das ist im Update vom 08.06. dazugekommen diese Logmeldung ja? Echt ein blöder Fehler den ich da habe, das ist zwar reproduzierbar aber nur sporadisch...

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

martinp876

Also nach meinen Erkenntnissen muss der Kanal signalisieren, wenn er nur "temporär" an ist. Das stelle ich in "timedOn" dar. Es sollte auch kommen wenn man einen treppenhausschalter realisiert, also nur für eine "Zeit" einschaltet und es ohne weiteren trigger wieder dunkel werden wird. Ich hoffe, dass alle Devices dies so machen - deines offensichtlich.
Lange habe ich es noch nicht eingebaut - stimmt.

So - was uns jetzt weiter bringt ist, dass im Fehlerfall (ein von ein versuch) timerdOn NICHT auf running steht. Stellt sich die Frage warum. Könnte sein, dass das Device den letzten Teil nicht empfangen hat - oder ignoriert.

In deinem Fall könnte man prüfen, dass auch timedOn kommt. Ist keine generelle Lösung, daher kann ich es nicht einbauen.

Lösung a)
du prüfst nach dem on-for-timer 3 sec später ab, ob timedOn aktiv ist oder nicht. Wenn nicht, noch einmal schicken.

Lösung b)
du verknüpfst mit einem virtuellen Button. Der schaltet dann ein wie ein Treppenhausschalter. Die message ist "einfacher" und sollte m.E. besser funktionieren. Im Gegensatz zu einer"onForTimer" ist das 'Ende' nicht optional. Wenn die Message also bestätigt wird sollte sie auch korrekt sein.
Gruss Martin

ext23

Mhh ok aber was ist der Unterschied zwischen "deviceMsg" und "timerdOn" ?!? Ich meine klar, man kann das natürlich abchecken nach dem schalten ja, das wäre zumindest ein workaround.

"du verknüpfst mit einem virtuellen Button. Der schaltet dann ein wie ein Treppenhausschalter" das habe ich jetzt auch nicht ganz verstanden?!? Meinst du das FHEM dann die Dose abschaltet oder wie? Das möchte ich ja eigentlich nicht, das ist mir zu unsicher falls meins Server abschmiert und dann in meinem Fall die Heizung ballert oder die Gießanlage aufn Balkon läuft ohne Ende ;-)

Gruß
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

martinp876

das Problem, dass ich bisher hatte ist(zu meinem Verständniss), dass eine messageankommt oder nicht. Wenn ich es hier richtig sehe bekommt das device nur den ersten Teil. Die Message "on" sieht fast wie die onfortimer aus. Nur dass die Ontime "angehängt" wird. So wie ich das Problem jetzt sehe verarbeitet das Device die Ontime nicht (empfängt sie nicht,... keine Ahnung, schneidet sie ab). Es gibt keine Prüfsumme über die gesamte Message, kein Anfangs oder Endeflag (jedenfalls auf diesem Level...)

Will sagen wenn bei der onfortimer die "time" abgekackt wird ist es eine korrekte "on" message. Und so sieht es für mich (jetzt) aus.

Die deviceMsg ist noch mal das gleiche wie "state" incl sender. Eigentlich duplicate, wird aber gerne zum Notify verwendet da State etwas komplex ist.
Wenn du also wissen willst ob der Timer auch verarbeitet wurde kannst du es nur an timedOn sehen.
deviceMsg sagt den Zustand des Lichts JETZT
timedOn erlaubt eine Prognose der Zukunft.

Fix einbauen kann ich jetzt jedenfalls noch nichts, da ich erst einmal sehen muss was bei onForTimer 0.5 passiert...


Wenn du immer das gleiche machen willst, also keine variablen Zeiten brauchst kann man virtuelle Buttons nutzen. Oder den physikalischen!!
Das Prinzip ist dann
erstelle einen virtuellen Button und peere ihn
define vb CUL_HM 112233
set vb virtual 1
set vb_Btn1 peerChan 0 bz_Handtuchtrockner single set


jetzt sollte ein "toggel" button gepeert sein. Du solltest also ein/ausschalten können mit
set vb_Btn1 press

jetzt musst du den "peer" des bz_Handtuchtrockner timen, also automatisch ausschalten
set bz_Handtuchtrockner regSet shOnTime 14400 vb_Btn1

Nach dem ersten "press" sollte der Trockner angehen und nach 14400 ausgehen. Solltest du vorher noch einmal "press" schicken geht er sofort aus (kann man natürlich aendern).

Nach meinem Dafürhalten sollte dies dein Problem lösen. m.E. wird diese Message (press) empfangen oder nicht. Wenn nicht wird sie wiederholt.

Nicht vergessen, nach dem "peeren" zu "saven". Der Handtuchtrockner speichert zwar alles, der virtuelle Button aber erst mit "save" im fhem.cfg.

Die Variante, den internen Button zu verwenden können wir auch durchsprechen... ist -fast- identisch dem virtuellen - nur ohne virtuell ;-)
Gruss Martin

ext23

Hallo Martin,

danke erst mal für die ausführliche Ausführung! Das werde ich mal ausprobieren.

Allerdings:
ZitatWill sagen wenn bei der onfortimer die "time" abgekackt wird ist es eine korrekte "on" message. Und so sieht es für mich (jetzt) aus.
Das kann ja auch nicht sein, weil die Steckdose bleibt ja aus wenn dieser Fehler auftritt. Würde der Zeitstempel "abgeschnitten" werden und nur der erste Teil verarbeitet, also das "on" Kommando, dann wäre die Dose doch dauerhaft an oder?

Gruß und Danke
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)