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
leider kann ich nichts erkennen.
Wie war der Zustand vor anschalten?
Ist es reproduzierbar?
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
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
-->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
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, 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
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
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...
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
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
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
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
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
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
Hall Daniel,
Zitatweil 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
Zitatdas 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
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
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
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
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
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
gut.
wie gesagt, sollte FHEM noch einmal senden, kann man es in den proto... variablen nachlesen, und im Log.
Gruss Martin
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
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
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
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
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
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
probier einmal den Anhang. Mal sehen, ob sich der Trockner überreden lässt
Gruss Martin
Kleiner Zwischenbericht:
Bis jetzt haben die beiden Steckdosen immer geschaltet, ich beobachte weiter...
ABER:
Ich hab so ein HM LED Dimmer, und der spinnt jetzt aber mit dieser Version. Ich bekomm jetzt immer ein Missing Ack beim abschalten der LED's
Anschalten (Soft on) set sz_SchrankLED 100 3600 0.5 :
2013-08-29_08:28:55 sz_SchrankLED level: set_100
2013-08-29_08:28:55 sz_SchrankLED set_100
2013-08-29_08:28:56 sz_SchrankLED level: 0.5 %
2013-08-29_08:28:56 sz_SchrankLED deviceMsg: 0.5 % (to HMLAN1)
2013-08-29_08:28:56 sz_SchrankLED 0.5 %
2013-08-29_08:28:56 sz_SchrankLED timedOn: running
2013-08-29_08:28:56 sz_SchrankLED dim: up:0.5 %
2013-08-29_08:28:56 sz_SchrankLED overload: off
2013-08-29_08:28:56 sz_SchrankLED overheat: off
2013-08-29_08:28:56 sz_SchrankLED reduced: off
2013-08-29_08:28:59 sz_SchrankLED level: 100 %
2013-08-29_08:28:59 sz_SchrankLED deviceMsg: on (to HMLAN1)
2013-08-29_08:28:59 sz_SchrankLED on
2013-08-29_08:28:59 sz_SchrankLED timedOn: running
2013-08-29_08:28:59 sz_SchrankLED dim: stop:on
2013-08-29_08:28:59 sz_SchrankLED overload: off
2013-08-29_08:28:59 sz_SchrankLED overheat: off
2013-08-29_08:28:59 sz_SchrankLED reduced: off
Ausschalten (soft off) set sz_SchrankLED 0 3600 0.5 :
2013-08-29_08:29:22 sz_SchrankLED level: set_0
2013-08-29_08:29:22 sz_SchrankLED set_0
2013-08-29_08:29:23 sz_SchrankLED NACK
2013-08-29_08:29:26 sz_SchrankLED level: 0 %
2013-08-29_08:29:26 sz_SchrankLED deviceMsg: off (to HMLAN1)
2013-08-29_08:29:26 sz_SchrankLED off
2013-08-29_08:29:26 sz_SchrankLED timedOn: off
2013-08-29_08:29:26 sz_SchrankLED dim: stop:off
2013-08-29_08:29:26 sz_SchrankLED overload: off
2013-08-29_08:29:26 sz_SchrankLED overheat: off
2013-08-29_08:29:26 sz_SchrankLED reduced: off
2013-08-29_08:29:28 sz_SchrankLED NACK
2013-08-29_08:29:30 sz_SchrankLED NACK
2013-08-29_08:29:32 sz_SchrankLED MISSING ACK
2013-08-29_08:29:33 sz_SchrankLED level: 0 %
2013-08-29_08:29:33 sz_SchrankLED deviceMsg: off (to HMLAN1)
2013-08-29_08:29:33 sz_SchrankLED off
2013-08-29_08:29:33 sz_SchrankLED timedOn: off
2013-08-29_08:29:33 sz_SchrankLED dim: stop:off
2013-08-29_08:29:33 sz_SchrankLED overload: off
2013-08-29_08:29:33 sz_SchrankLED overheat: off
2013-08-29_08:29:33 sz_SchrankLED reduced: off
Hängt das irgendwie zusammen mit deinen Änderungen?
Gruß
Daniel
Hallo Daniel,
haben wir schon einen Kandidaten, der die Änderung nicht verträgt?
kannst du mir folgendes schicken
roh-messages wenn du dimmst:
set sz_SchrankLED on
set sz_SchrankLED off
set sz_SchrankLED 100 30 0.5
immer etwas warten zwischenden Kommandos
Und ein List des sz_SchrankLED
Gruss Martin
Hi,
klar. War die Tage im Urlaub, daher die Verspätung...
"set sz_SchrankLED on"
2013-09-02_09:58:08 sz_SchrankLED set_on
2013-09-02_09:58:08 sz_SchrankLED level: 100 %
2013-09-02_09:58:08 sz_SchrankLED deviceMsg: on (to HMLAN1)
2013-09-02_09:58:08 sz_SchrankLED on
2013-09-02_09:58:08 sz_SchrankLED timedOn: off
2013-09-02_09:58:08 sz_SchrankLED dim: stop:on
2013-09-02_09:58:08 sz_SchrankLED overload: off
2013-09-02_09:58:08 sz_SchrankLED overheat: off
2013-09-02_09:58:08 sz_SchrankLED reduced: off
Debug:
2013.09.02 09:58:08 2: CUL_HM set sz_SchrankLED on
2013.09.02 09:58:08 1: HMLAN_Send: HMLAN1 S:SDDADC9F3 stat: 00 t:00000000 d:01 r:DDADC9F3 m:33 A011 23FF23 1A6224 0201C80000
2013.09.02 09:58:08 1: HMLAN_Parse: HMLAN1 R:RDDADC9F3 stat:0001 t:4A1CCBC0 d:FF r:FFBA m:33 8002 1A6224 23FF23 0101C80042EC
"set sz_SchrankLED off"
2013-09-02_09:59:41 sz_SchrankLED set_off
2013-09-02_09:59:41 sz_SchrankLED level: 0 %
2013-09-02_09:59:41 sz_SchrankLED deviceMsg: off (to HMLAN1)
2013-09-02_09:59:41 sz_SchrankLED off
2013-09-02_09:59:41 sz_SchrankLED timedOn: off
2013-09-02_09:59:41 sz_SchrankLED dim: stop:off
2013-09-02_09:59:41 sz_SchrankLED overload: off
2013-09-02_09:59:41 sz_SchrankLED overheat: off
2013-09-02_09:59:41 sz_SchrankLED reduced: off
Debug:
2013.09.02 09:59:41 2: CUL_HM set sz_SchrankLED off
2013.09.02 09:59:41 1: HMLAN_Send: HMLAN1 S:SDDAF3412 stat: 00 t:00000000 d:01 r:DDAF3412 m:34 A011 23FF23 1A6224 0201000000
2013.09.02 09:59:41 1: HMLAN_Parse: HMLAN1 R:RDDAF3412 stat:0001 t:4A1E35EB d:FF r:FFBA m:34 8002 1A6224 23FF23 0101000042EC
"set sz_SchrankLED 100 30 0.5"
2013-09-02_10:00:39 sz_SchrankLED level: set_100
2013-09-02_10:00:39 sz_SchrankLED set_100
2013-09-02_10:00:40 sz_SchrankLED level: 0.5 %
2013-09-02_10:00:40 sz_SchrankLED deviceMsg: 0.5 % (to HMLAN1)
2013-09-02_10:00:40 sz_SchrankLED 0.5 %
2013-09-02_10:00:40 sz_SchrankLED timedOn: running
2013-09-02_10:00:40 sz_SchrankLED dim: up:0.5 %
2013-09-02_10:00:40 sz_SchrankLED overload: off
2013-09-02_10:00:40 sz_SchrankLED overheat: off
2013-09-02_10:00:40 sz_SchrankLED reduced: off
2013-09-02_10:00:43 sz_SchrankLED level: 100 %
2013-09-02_10:00:43 sz_SchrankLED deviceMsg: on (to HMLAN1)
2013-09-02_10:00:43 sz_SchrankLED on
2013-09-02_10:00:43 sz_SchrankLED timedOn: running
2013-09-02_10:00:43 sz_SchrankLED dim: stop:on
2013-09-02_10:00:43 sz_SchrankLED overload: off
2013-09-02_10:00:43 sz_SchrankLED overheat: off
2013-09-02_10:00:43 sz_SchrankLED reduced: off
2013-09-02_10:01:13 sz_SchrankLED level: 0 %
2013-09-02_10:01:13 sz_SchrankLED deviceMsg: off (to HMLAN1)
2013-09-02_10:01:13 sz_SchrankLED off
2013-09-02_10:01:13 sz_SchrankLED timedOn: off
2013-09-02_10:01:13 sz_SchrankLED dim: stop:off
2013-09-02_10:01:13 sz_SchrankLED overload: off
2013-09-02_10:01:13 sz_SchrankLED overheat: off
2013-09-02_10:01:13 sz_SchrankLED reduced: off
Debug:
2013.09.02 10:00:39 2: CUL_HM set sz_SchrankLED 100 30 0.5
2013.09.02 10:00:39 1: HMLAN_Send: HMLAN1 S:SDDB01931 stat: 00 t:00000000 d:01 r:DDB01931 m:35 A011 23FF23 1A6224 0201C800A02580
2013.09.02 10:00:40 1: HMLAN_Parse: HMLAN1 R:RDDB01931 stat:0001 t:4A1F1B13 d:FF r:FFBA m:35 8002 1A6224 23FF23 01010150416C
2013.09.02 10:00:43 1: HMLAN_Parse: HMLAN1 R:E1A6224 stat:0000 t:4A1F270D d:FF r:FFBA m:36 A410 1A6224 23FF23 0601C84080C8
2013.09.02 10:01:13 1: HMLAN_Parse: HMLAN1 R:E1A6224 stat:0000 t:4A1F9DCF d:FF r:FFBA m:37 A410 1A6224 23FF23 060100008000
"set sz_SchrankLED 0 30 0.5" --> Sobald der erste Parameter eine 0 ist kommt immer das Missing ACK
2013-09-02_10:08:08 sz_SchrankLED level: set_0
2013-09-02_10:08:08 sz_SchrankLED set_0
2013-09-02_10:08:08 sz_SchrankLED NACK
2013-09-02_10:08:11 sz_SchrankLED NACK
2013-09-02_10:08:11 sz_SchrankLED NACK
2013-09-02_10:08:14 sz_SchrankLED level: 0 %
2013-09-02_10:08:14 sz_SchrankLED deviceMsg: off (to HMLAN1)
2013-09-02_10:08:14 sz_SchrankLED off
2013-09-02_10:08:14 sz_SchrankLED timedOn: off
2013-09-02_10:08:14 sz_SchrankLED dim: stop:off
2013-09-02_10:08:14 sz_SchrankLED overload: off
2013-09-02_10:08:14 sz_SchrankLED overheat: off
2013-09-02_10:08:14 sz_SchrankLED reduced: off
2013-09-02_10:08:15 sz_SchrankLED MISSING ACK
Debug:
2013.09.02 10:08:08 2: CUL_HM set sz_SchrankLED 0 30 0.5
2013.09.02 10:08:08 1: HMLAN_Send: HMLAN1 S:SDDB6F1BD stat: 00 t:00000000 d:01 r:DDB6F1BD m:3C A011 23FF23 1A6224 02010000A02580
2013.09.02 10:08:08 1: HMLAN_Parse: HMLAN1 R:RDDB6F1BD stat:0001 t:4A25F3DE d:FF r:FFBA m:3C 8002 1A6224 23FF23 0101C72041EC
2013.09.02 10:08:08 1: General missed timedOn for sz_SchrankLED
2013.09.02 10:08:10 1: HMLAN_Send: HMLAN1 S:SDDB6F857 stat: 00 t:00000000 d:01 r:DDB6F857 m:3D A011 23FF23 1A6224 02010000A02580
2013.09.02 10:08:11 1: HMLAN_Parse: HMLAN1 R:RDDB6F857 stat:0001 t:4A25FA79 d:FF r:FFBA m:3D 8002 1A6224 23FF23 01010000416C
2013.09.02 10:08:11 1: General missed timedOn for sz_SchrankLED
2013.09.02 10:08:11 1: HMLAN_Send: HMLAN1 S:SDDB6FDFC stat: 00 t:00000000 d:01 r:DDB6FDFC m:3E A011 23FF23 1A6224 02010000A02580
2013.09.02 10:08:11 1: HMLAN_Parse: HMLAN1 R:RDDB6FDFC stat:0001 t:4A26001E d:FF r:FFBA m:3E 8002 1A6224 23FF23 0101000042EC
2013.09.02 10:08:11 1: General missed timedOn for sz_SchrankLED
2013.09.02 10:08:14 1: HMLAN_Parse: HMLAN1 R:E1A6224 stat:0000 t:4A2609AB d:FF r:FFBA m:3F A410 1A6224 23FF23 060100008000
2013.09.02 10:08:16 1: HMLAN_Send: HMLAN1 I:K
2013.09.02 10:08:16 1: HMLAN_Parse: HMLAN1 V:03C1 sNo:IEQ0062180 d:1399AF O:23FF23 t:4A261069 IDcnt:0006
2013.09.02 10:08:17 1: HMLAN_Parse: HMLAN1 R:E1D2544 stat:0000 t:4A2615FD d:FF r:FFBD m:BF A258 1D2544 1A2BCA 0000
2013.09.02 10:08:17 1: HMLAN_Parse: HMLAN1 R:E1A2BCA stat:0000 t:4A26167F d:FF r:FFB5 m:BF 8202 1A2BCA 1D2544 010100003A
List:
Internals:
CFGFN /etc/fhem/Schlafzimmer.cfg
DEF 1A6224
EVENTS 57
HMLAN1_MSGCNT 58
HMLAN1_RAWMSG E1A6224,0000,4A1F9DCF,FF,FFBA,37A4101A622423FF23060100008000
HMLAN1_RSSI -70
HMLAN1_TIME 2013-09-02 10:01:13
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 58
NAME sz_SchrankLED
NR 320
STATE off
TYPE CUL_HM
lastMsg No:37 - t:10 s:1A6224 d:23FF23 060100008000
protLastRcv 2013-09-02 10:01:13
protResnd 16 last_at:2013-08-30 06:00:55
protResndFail 8 last_at:2013-08-30 06:00:59
protSnd 22 last_at:2013-09-02 10:00:39
protState CMDs_done_events:46
protTimedOn 22 last_at:2013-08-30 06:00:56
rssi_HMLAN1 avg:-61.59 min:-66 max:-58 lst:-65 cnt:37
rssi_at_HMLAN1 avg:-66.05 min:-71 max:-63 lst:-70 cnt:58
Readings:
2013-09-02 10:00:40 CommandAccepted yes
2013-09-02 10:01:13 deviceMsg off (to HMLAN1)
2013-09-02 10:01:13 dim stop:off
2013-09-02 10:01:13 level 0 %
2013-09-02 10:01:13 overheat off
2013-09-02 10:01:13 overload off
2013-09-02 10:01:13 reduced off
2013-09-02 10:01:13 state off
2013-09-02 10:01:13 timedOn off
2013-03-31 23:43:23 virtLevel set_0
Helper:
burstEvtCnt 46
rxType 1
Respwait:
Role:
chn 1
dev 1
Rssi:
Hmlan1:
avg -61.5945945945946
cnt 37
lst -65
max -58
min -66
At_hmlan1:
avg -66.051724137931
cnt 58
lst -70
max -63
min -71
Attributes:
expert 2_full
firmware 2.2
fp_Wohnung 240,1140,1,Schrank
model HM-LC_Dim1PWM-CV
peerIDs
room Schlafzimmer
serialNr JEQ0186867
subType dimmer
webCmd on:off:toggle:statusRequest
nun, du schickst ein
set sz_SchrankLED 0 30 0.5
bedeutet: regle in 0.5s nach '0', bleiben dort für 30s, gan gehe nach '0'
Das Problem ist sicher die '0' Schalte ein auf level '0' geht wohl nicht.
Ist ein seltener Befehl, aber ich werden es abprüfen.
Gibt es sonst noch Probleme? Alles andere sieht ok aus für mich
Gruss Martin
Hi,
OK da hast du recht ja. original habe ich ja 3600 stehen, da der Befehl ohne die Angabe einer Laufzeit damals nie funktioniert hat. Oder man sollte eien 0 eintragen damit das dauerhaft an bleibt, aber das hat bei mir nicht funktioniert, der hat kurz aufgedimmt und ist gleich aus gegangen. Kann es das es mittlerweile behoben ist, also egal, Fakt ist ich hatte das beim Hochdimmen so machen müssen und hab es beim Runterdimmen natürlich so übernommen ;-) Daher ist das natürlich etwas sinnig ja. Ich kann es natürlich mal ohne diesen Wert versuchen. Da hatte ich damals nicht weiter drüber nachgedacht ja.
Was das andere Problem angeht, bis jetzt schaltet alles zuverlässig, jeden mrgen um 7 Uhr. Also ich kann im Log nichts festellen, aber ich sehe auch nicht das er irgend wann mal etwas wiederholt hat. Das kann natürlich auch sein das es die letzten Tage einfach funktioniert hat. Wie gesagt das trat ja immer sehr sporadisch auf. Also ich würde das schon noch gerne ein paar Tage beobachten. An der anderen Steckdose ist die Gießanlage für den Balkon, nur die läuft dank des Wetters im Moment eher selten. Ich kann natürlich mal jede Stunde die Dose einmal schalten lassen ohne Last und schauen ob da nochmal dieser Fehler auftritt.
/Daniel
So eben mal probiert mit einer "0":
define FB_FS20_01_Taste_01_off notify Fernbedienung01_Taste01:off set sz_SchrankLED 0 0 0.5
da kommen auch diese NACK's
ich glaube, wir haben uns nicht verstanden.
set sz_SchrankLED <level> <ontime> <ramptime>
dein Level ist '0'. Das ist ausschalten. Es gibt aber kein "off-or-timer", was sollte danach passieren? ok, es gibt lösungen, auch in HM. Aber es gibt kein Kommando "off-for-timer"
Also: setze Level auf etwas grösser "0", damit es auch ein ON-for-timer wird!!!
Korrekt ist aber, dass bei einer Zeit "0" ein dauer-an kommt und somit kein Timed-on geprüft werden darf.
Baue ich ein
Gruss Martin
Mhh,
zum anschalten der LED's benutze ich "set sz_SchrankLED 100 3600 0.5" heißt er soll in 0,5 Sekunden auf 100% hoch dimmen und dort für 3600 Sekunden verbleiben (ersetze ich die 3600 durch eine 0 geht es nicht, ich möchte eigentlich das er auf Dauer an bleibt aber egal, ist ein Workaround womit ich leben kann). Das läuft alles.
Jetzt zum soft off, sprich runter dimmen beim Ausschalten. Da benutze ich "set sz_SchrankLED 0 3600 0.5" heißt also er soll in 0,5 Sekunden auf 0% dimmen, da verbleibt er 3600 Sekunden und geht dann aus, was er aber schon ist, klar. Aber ich kann die 3600 nicht einfach weg lassen, dann geht es nicht, mit einer 0 passiert dasselbe ...
Aber was ist daran jetzt falsch, wie soll ich denn sonst ein soft off realisieren, und funktionieren tut es ja. Also ich verstehe schon das Problem, aber da der zweite Parameter mandatory ist, kann ich den ja schlecht weg lassen, dann benutzt der meine ramp time als ontime und ich habe keine ramp mehr ...
Gruß
Daniel
Hallo Daniel.
Zitatzum anschalten der LED's benutze ich "set sz_SchrankLED 100 3600 0.5" heißt er soll in 0,5 Sekunden auf 100% hoch dimmen und dort für 3600 Sekunden verbleiben (ersetze ich die 3600 durch eine 0 geht es nicht, ...
warum? Sollte schon - jedenfalls mit den letzten fixes bei mir... hat dein dimmer etwas dagegen? hast du roh-messages?
ZitatJetzt zum ... Ausschalten. Da benutze ich "set sz_SchrankLED 0 3600 0.5" heißt also er soll in 0,5 Sekunden auf 0% dimmen, da verbleibt er 3600 Sekunden und geht dann aus, was er aber schon ist, klar. Aber ich kann die 3600 nicht einfach weg lassen, dann geht es nicht, mit einer 0 passiert dasselbe ...
auch das sollte gehen, siehe oben.
ZitatAber was ist daran jetzt falsch, wie soll ich denn sonst ein soft off realisieren, und funktionieren tut es ja. Also ich verstehe schon das Problem, aber da der zweite Parameter mandatory ist, kann ich den ja schlecht weg lassen, dann benutzt der meine ramp time als ontime und ich habe keine ramp mehr ...
warte einmal auf die naechste Version Dann sollte
set licht 100 0 30
set licht 0 0 20 funktionieren
oder hol dir die 3 files aus
Link (http://forum.fhem.de/index.php?topic=14601.msg93311#msg93311)
(achtung, CUL_HM ist 2-mal drin)
da sollte es funktionieren
Gruss Martin
OK mit der 0 geht es jetzt wirklich! Aber dafür kommt beim soft on und off jetzt das NACK, vorher passiert das nur beim soft off.
2013-09-04_19:43:21 sz_SchrankLED level: set_100
2013-09-04_19:43:21 sz_SchrankLED set_100
2013-09-04_19:43:21 sz_SchrankLED NACK
2013-09-04_19:43:24 sz_SchrankLED level: 100 %
2013-09-04_19:43:24 sz_SchrankLED deviceMsg: on (to HMLAN1)
2013-09-04_19:43:24 sz_SchrankLED on
2013-09-04_19:43:24 sz_SchrankLED timedOn: off
2013-09-04_19:43:24 sz_SchrankLED dim: stop:on
2013-09-04_19:43:24 sz_SchrankLED overload: off
2013-09-04_19:43:24 sz_SchrankLED overheat: off
2013-09-04_19:43:24 sz_SchrankLED reduced: off
2013-09-04_19:43:26 sz_SchrankLED NACK
2013-09-04_19:43:29 sz_SchrankLED level: 100 %
2013-09-04_19:43:29 sz_SchrankLED deviceMsg: on (to HMLAN1)
2013-09-04_19:43:29 sz_SchrankLED on
2013-09-04_19:43:29 sz_SchrankLED timedOn: off
2013-09-04_19:43:29 sz_SchrankLED dim: stop:on
2013-09-04_19:43:29 sz_SchrankLED overload: off
2013-09-04_19:43:29 sz_SchrankLED overheat: off
2013-09-04_19:43:29 sz_SchrankLED reduced: off
2013-09-04_19:43:31 sz_SchrankLED NACK
2013-09-04_19:43:33 sz_SchrankLED level: 100 %
2013-09-04_19:43:33 sz_SchrankLED deviceMsg: on (to HMLAN1)
2013-09-04_19:43:33 sz_SchrankLED on
2013-09-04_19:43:33 sz_SchrankLED timedOn: off
2013-09-04_19:43:33 sz_SchrankLED dim: stop:on
2013-09-04_19:43:33 sz_SchrankLED overload: off
2013-09-04_19:43:33 sz_SchrankLED overheat: off
2013-09-04_19:43:33 sz_SchrankLED reduced: off
2013-09-04_19:43:35 sz_SchrankLED MISSING ACK
2013-09-04_19:44:50 sz_SchrankLED level: set_0
2013-09-04_19:44:50 sz_SchrankLED set_0
2013-09-04_19:44:51 sz_SchrankLED NACK
2013-09-04_19:44:53 sz_SchrankLED level: 0 %
2013-09-04_19:44:53 sz_SchrankLED deviceMsg: off (to HMLAN1)
2013-09-04_19:44:53 sz_SchrankLED off
2013-09-04_19:44:53 sz_SchrankLED timedOn: off
2013-09-04_19:44:53 sz_SchrankLED dim: stop:off
2013-09-04_19:44:53 sz_SchrankLED overload: off
2013-09-04_19:44:53 sz_SchrankLED overheat: off
2013-09-04_19:44:53 sz_SchrankLED reduced: off
2013-09-04_19:44:54 sz_SchrankLED NACK
2013-09-04_19:44:56 sz_SchrankLED NACK
2013-09-04_19:44:57 sz_SchrankLED MISSING ACK
2013-09-04_19:44:58 sz_SchrankLED level: 0 %
2013-09-04_19:44:58 sz_SchrankLED deviceMsg: off (to HMLAN1)
2013-09-04_19:44:58 sz_SchrankLED off
2013-09-04_19:44:58 sz_SchrankLED timedOn: off
2013-09-04_19:44:58 sz_SchrankLED dim: stop:off
2013-09-04_19:44:58 sz_SchrankLED overload: off
2013-09-04_19:44:58 sz_SchrankLED overheat: off
2013-09-04_19:44:58 sz_SchrankLED reduced: off
Mit den anderen Dateien lass ich erstmal, da warte ich bis was neues kommt und ich habe ja im Moment ehe diese Spezialversion von dir am Start. Nach einem Update überschreibe ich die immer wieder, ich will ja wissen ob das mit den Steckdosen jetzt stabil läuft.
Gruß
Daniel
Hallo Daniel,
liegt daran, dass bei "Duration=0" , also forever, kein timed-on abgefragt werden darf. Ist in der neuen Version behoben - die erst kommen wird, wenn ich Daten über das "experiment" habe
Gruss Martin
Hi,
so ich habe über Nacht mal alle 5 Minuten eine Steckdose für 30 on-for-timer Sekunden und auch hier habe ich nicht einen Aussetzer gehabt. Bis jetzt scheint das also alles zu laufen, ich denke bei der Anzahl von Schaltvorgängen hätte das ja mindestens einmal vorkommen müssen.
Gruß
Daniel
Hi,
schau dir einmal die protokol-events an. Besonders "protoTimedOn". hier wird gezählt, wie oft wir wiederhohlen mussten. Danach sollte alles passen...
Gruss Martin
OK, wo finde ich die? Im Device Log der Steckdose und im Debug Log finde ich die Info nicht. Aber genau sowas suche ich ja. Oder reicht da Loglevel 1 nicht aus?
/Daniel
die stehen im web-interface oder im List <dev>. Da sind Einträge mit protState, protSnd, protNack,... . Nur wenn es ein event gegeben hat existiert der entsprechende Eintrag. Ein paar sind immer im Device, channels haben keine solchen einträge. Sollte also kein entsprechendes protTimedOnt existieren ist auch keines aufgetreten.
Gruss Martin
Mhh ahh ok, naja gut, müsste man zur Kontrolle also in eine Datei umlenken, sonst bekomme ich das ja nicht mit.
OK dann werf ich da mal ein Auge drauf.
Gruß
Daniel
musst du dies mitbekommen? Hier werden die Wiederholungen gezählt. Es ist also kein "Error", nur "Info" oder "Warning"
Der Zähler bleibt stehen bis du ihn löschst oder das System neu startest.
Gruss Martin
Naja ich möchte ja mitbekommen ob es jetzt funktioniert. Also wenn ich sehe das er jetzt ab und an etwas wiederholt ist das ja ok.
Aber OK wenn der Zähler nicht gelöscht wird sehe ich das ja. Ich dachte jetzt der wird nur pro event gezählt und dann zurückgesetzt.
Gruß
Daniel
alle protokoll-zähler akkumulieren. Rückgesetzt werden sie bei neustart/restart sowie mit dem Kommando clear msgEvents.
Das ist ja die Idee, dass ich irgendwann, wenn ich einmal vorbei schaue, sehen kann ob mein System Probleme hatte. Du siehst den Zählerstand sowie das Datum des letzten Events dieser Art.
Nur im protoState steht das Ergebniss der letzten Transaktion, hier wird NICHT akkumuliert.
Und immer mein Hinweis auf HMInfo. Hier gibt es set protoEvents (eigentich ein get...) zeigt dir alle Devices in einer Tabelle an. Ich will dies noch etwas verfeinern - die Tabelle ist etwas breit.... Mal sehen, vielleicht gibt es bald optionen dazu: schmall/breit/errorOny/all...
Hallo,
so also ich hab das mal die Tage jetzt beobachtet aber es ist nie ein "protoTimedOn" aufgetaucht unter list. Auf beiden Steckdosen die ich habe nicht, und ich habe im 5 Minuten Takt geschaltet: protSnd 639 last_at:2013-09-10 13:43:37 das ist von 2 Tagen ...
Also aus meine Sicht ist nach wie vor alles schick.
Gruß
Daniel
Aha jetzt habe ich mal ein protResndFail ...
protLastRcv 2013-09-10 19:14:09
protResnd 2 last_at:2013-09-10 19:08:16
protResndFail 1 last_at:2013-09-10 19:08:18
protSnd 705 last_at:2013-09-10 19:13:37
protState CMDs_done_events:3
rssi_HMLAN1 avg:-65.31 min:-74 max:-62 lst:-65 cnt:706
rssi_at_HMLAN1 avg:-67.18 min:-75 max:-63 lst:-69 cnt:1408
Es ist also etwas schief gegangen.
Du kannst mit HMInfo einen Trigger auslösen, falls du eine email oder sonstiges willst.
Was ist alles um 19:08:15-18 passiert?
Gruss Martin
Passiert ist das:
2013-09-10_19:08:09 sz_Giessanlage set_on-for-timer 30
2013-09-10_19:08:10 sz_Giessanlage set_on-for-timer 30
2013-09-10_19:08:18 sz_Giessanlage MISSING ACK
2013-09-10_19:08:19 sz_Giessanlage level: 100 %
2013-09-10_19:08:19 sz_Giessanlage deviceMsg: on (to HMLAN1)
2013-09-10_19:08:19 sz_Giessanlage on
2013-09-10_19:08:19 sz_Giessanlage timedOn: running
2013-09-10_19:08:19 sz_Giessanlage level: 100 %
2013-09-10_19:08:19 sz_Giessanlage deviceMsg: on (to HMLAN1)
2013-09-10_19:08:19 sz_Giessanlage on
2013-09-10_19:08:19 sz_Giessanlage timedOn: running
2013-09-10_19:08:20 sz_Giessanlage level: 100 %
2013-09-10_19:08:20 sz_Giessanlage deviceMsg: on (to HMLAN1)
2013-09-10_19:08:20 sz_Giessanlage on
2013-09-10_19:08:20 sz_Giessanlage timedOn: running
2013-09-10_19:08:38 sz_Giessanlage set_on-for-timer 30
2013-09-10_19:08:39 sz_Giessanlage level: 100 %
2013-09-10_19:08:39 sz_Giessanlage deviceMsg: on (to HMLAN1)
2013-09-10_19:08:39 sz_Giessanlage on
2013-09-10_19:08:39 sz_Giessanlage timedOn: running
2013-09-10_19:09:12 sz_Giessanlage level: 0 %
2013-09-10_19:09:12 sz_Giessanlage deviceMsg: off (to broadcast)
2013-09-10_19:09:12 sz_Giessanlage off
2013-09-10_19:09:12 sz_Giessanlage timedOn: off
Da kam wohl ein Befehl nicht an, warum der jetzt aber um 19:08:38 nochmal ein set gemacht hat wundert mich etwas aber nunja.
So ich werd jetzt mal ein Update machen und die aktuelle CUL_HM wieder benutzen.
Gruß
Daniel
hallo Christian,
nun, alte Versionen habe ich nicht im kopf, ist der zu klein....
passiert ist, dass das Kommando 2 mal gesendet wurde, aber kein ack gesehen wurde. Dennoch ist das kommando ausgeführt worden, wahrscheinlich sogar 3 mal.
das mit der langen verzögerung ist, denke ich, die testversion (noch einmal nachdenken...)
dass kein ack gesehen wird ist ein Problem - das muss kommen. Es könnte sein, dass das ack erst nach 10 sec gekommen ist, so lange warte ich nicht.
kannst du einmal die register-readings schicken? komplett, expert=2!
vielleicht ist hier eine lange Karenzzeit einstellbar?
Ansonsten ist nur noch die aktuelle Version relevant
Gruss Martin