Hallo in die Runde,
das Reading pulseTimeIncrement meines Hour Counters macht Probleme. Es kommt mehrmals am Tag vor das das Reading aus dem Tritt kommt. Im Anhang lege ich mal einen Plot wie sich das bemerkbar macht. So gegen 18:30 sieht man es sehr gut.
Meine Anlagenkonstellation ist wie folgt.
Am Ölbrenner ist am Kontakt B4 (Betriebsstundenzähler) parallel ein 230V Koppelrelais (Marke Finder mit Stecksockel) angeschlossen. An dem Relais-Schließer hängt ein Homematic Kontaktinterface HM-SCI-3-FM welches die Schaltvorgänge registriert.
Da das Kontaktinterface nur toggelt mache ich mit einem Notify aus dem toggeln ein 0/1 Zustand.
BrennerStat:trigger.* {
my $bno = $1 if (ReadingsVal("BrennerStat", "trigger", 0) =~ m/(\d+)/);
if ($bno & 1) {fhem ("set dmyBrennerStat 1");}
else{fhem ("set dmyBrennerStat 0")}}
Mein HourCounter hört dann auf den Dummy BrennerStat.
Die Events gegen 18:00 vom Kontaktinterface sind meiner Meinung nach sauber:
2015-03-21_17:50:00 CUL_HM_HM_SWI_3_FM_2F3132 battery: ok
2015-03-21_17:50:00 CUL_HM_HM_SWI_3_FM_2F3132 BrennerStat toggle (to broadcast)
2015-03-21_18:29:44 CUL_HM_HM_SWI_3_FM_2F3132 battery: ok
2015-03-21_18:29:44 CUL_HM_HM_SWI_3_FM_2F3132 BrennerStat toggle (to broadcast)
2015-03-21_18:38:06 CUL_HM_HM_SWI_3_FM_2F3132 battery: ok
2015-03-21_18:38:06 CUL_HM_HM_SWI_3_FM_2F3132 BrennerStat toggle (to broadcast)
2015-03-21_19:05:27 CUL_HM_HM_SWI_3_FM_2F3132 battery: ok
2015-03-21_19:05:27 CUL_HM_HM_SWI_3_FM_2F3132 BrennerStat toggle (to broadcast)
Das Reading dagegen sieht so aus:
2015-03-21_17:50:00 0
2015-03-21_18:00:00 600
2015-03-21_18:29:43 2383
2015-03-21_18:29:44 2384
2015-03-21_18:38:06 2886
2015-03-21_19:05:27 0
2015-03-21_19:13:31 484
Genau um 18:00 wird das pulseTimeIncrement Reading geschrieben, obwohl es im Log vom Kontaktinterface keine Flanke (negative) gibt. Um 15:00 und 15:42 passiert genau das Gleiche
2015-03-21_14:55:49 0
2015-03-21_15:00:00 251
2015-03-21_15:04:06 496
2015-03-21_15:42:33 0
2015-03-21_15:42:34 1
2015-03-21_15:50:46 493
2015-03-21_16:28:27 0
2015-03-21_16:28:28 1
2015-03-21_16:36:51 504
2015-03-21_17:08:24 0
Im FHEM Log habe ich nur ein Eintrag am 21. welcher meiner Meinung nach nichts damit zu tun haben kann.
2015.03.21 14:21:36 1: PERL WARNING: Argument "8.1 H" isn't numeric in sprintf at ./FHEM/98_SVG.pm line 1946.
Hat jemand eine Idee, warum das Reading aus dem Tritt kommt?
Danke und Grüße
Ich habe da ein echtes Verständnisproblem. Erstens scheinst Du ein SWI zu verwenden - diese toggeln (Message "short"), ein SCI sendet den echten Kontaktzustand (Messages "open" und "closed"), da bräuchtest du keinen Dummy zwischenzuschalten. SCI und toggle-Dummy sorgen dann für ganz unklare Verhältnisse ;D
Zweitens zählt pulseTimeIncrement doch die Gesamtdauer des aktuellen Pulses hoch. An Deinen beiden violetten Bergen ist die Einschaltdauer auch entsprechend deutlich länger als bei den sonstigen Pulsen. Das Diagramm sieht also für mich ganz normal aus...?
Hallo Pfriemler,
danke für den Hinweis und Sorry für die Verwirrung. Ich habe ein SWI im Einsatz und der toggelt (wie im Log Auszug zu sehen). Daher ist meiner Meinung nach der dummy Pflicht. Oder hast Du eine bessere Lösung?
ZitatZweitens zählt pulseTimeIncrement doch die Gesamtdauer des aktuellen Pulses hoch
Sehe ich auch so.
ZitatDas Diagramm sieht also für mich ganz normal aus...?
Das wiederum sehe ich nicht so. Meines Erachtens nach machen die "Stufen" in Graph "Dauer" (gegen 18:00) keinen Sinn. Da ja kein Schaltvorgang vom Interface registriert wurde, müsste aus meiner Sicht der Graph horizontal reitegeschrieben werden.
Danke und Grüße
hab mir mal das Log vom dummy angeschaut, welcher vom notify gefüttert wird um aus dem toggle Signal ein 0/1 Signal zu erstellen.
2015-03-21_17:16:46 0
2015-03-21_17:16:46 0
2015-03-21_17:50:00 1
2015-03-21_17:50:00 1
2015-03-21_18:29:44 1
2015-03-21_18:29:44 1
2015-03-21_18:38:06 0
2015-03-21_18:38:06 0
2015-03-21_19:05:27 1
2015-03-21_19:05:27 1
2015-03-21_19:13:31 0
2015-03-21_19:13:31 0
Ich denke da liegt das Problem. Um 18:29 kommen Zwei Einsen. Da vorher um 17:50 bereits Zwei Einsen kamen, hätten ergo Zwei Nullen kommen müssen. Also liegt das Problem beim dummy welcher vom notify gefüttert wird. Das notify sieht so aus
BrennerStat:trigger.* {
my $bno = $1 if (ReadingsVal("BrennerStat", "trigger", 0) =~ m/(\d+)/);
if ($bno & 1) {fhem ("set dmyBrennerStat 1");}
else{fhem ("set dmyBrennerStat 0")}}
Kann mir bitte jemand weiterhelfen?
Danke und Grüße
1. Mit dem SWI kommst Du um einen Dummy zum Ent-Toggeln kaum drumrum.
2. Ich habe aber eben eine Weile gebraucht, um Dein Notify zu entschlüsseln.
Wenn ich das richtig interpretiere, liest Du die Nummer des Triggers vom SWI aus (wird fortlaufend hochgezählt) und schaltest den Dummy je nachdem, ob der Counter ungerade oder gerade ist. Das ist an sich sehr geschickt, weil es den echten Zustand auch transportiert, wenn ein Telegramm vom SWI verlorengegangen ist, etwa durch Funkprobleme. Jedes verlorengegange "Ausschalttelegramm" aber lässt deinen Brennerdummy in FHEM virtuell weiterlaufen, und der nächste Einschalter aktualisiert dann den pulseTimeIncrement, was zu den Sprüngen führt. Bei verlorenen Einschalt-Telegrammen fällt das hingegen gar nicht auf. Außer dass der Brenner scheinbar eine Pause einlegt.
Falls Du die Telegramme des SWI in einem FileLog speicherst, müsstest Du dort Aussetzer sehen. Außerdem weiß ich nicht, von wo nach wo der Counter zurücksetzt. Wenn der etwa von 200 auf 0 springt, würde der Zustand plötzlich gespiegelt ...
Ich würde auf die Kröten sch... und einen SCI kaufen, fertig. ;D
Hallo Pfriemler,
vielen dank für den Hinweis mit den "verlorenen Telegrammen". Mit dem Hinweis habe ich mal den Trigger vom SWI ausgelesen und siehe da, es fehlen dann an den jeweiligen Stellen Triggerwerte hier ein exemplarischer Auszug:
2015-03-21_16:36:51 Short_150
2015-03-21_17:08:24 Short_151
2015-03-21_17:16:45 Short_152
2015-03-21_17:50:00 Short_153
2015-03-21_18:29:43 Short_155
2015-03-21_18:38:06 Short_156
2015-03-21_19:05:26 Short_157
Wieder ein Schritt weiter um dem Problem auf die Schliche zu kommen :)
Funkproblem würde ich so spontan ausschließen, da der RSSI im Durchschnitt bei -69 liegt. Ich denke das sind genung Reserven sodass die Telegramme durchkommen müssten.
Und zum Tipp mit dem Umstieg auf ein SCI, da hätte ich doch bei "verlierenden Telegrammen" (Funkprobleme) die selben Auswirkungen. Oder macht ein SCI die Übertragung grundsätzlich anders als ein SWI?
Werde mich mal weiter auf die Fehlersuche begeben.
Nochmal vielen Dank und Grüße
Na, das nenne ich doch Volltreffer.
Abgesehen von der noch ungelösten Frage, von wo der Counter zurückspringt und ob es da eine Störung im Ablauf "gerade-ungerade" gibt, gibt es im Verhalten eines SCI keine zu erwartende Unterschiede - wenn dessen Telegramme verlorengehen, sieht es im Endefeffekt genauso aus. RSSI geht aber an sich völlig in Ordnung.
Wie man die Telegramme sicherer macht? Keine Ahnung.
Könnte es sein, dass Dein Empfang teilweise gestört ist, etwa durch temporär hängende Prozesse im FHEM? Beobachtest Du auch an anderen Stellen teilweise Hänger?
Ach so, hatte ich vergessen, der Counter springt von 255 auf 0 zurück. Dürfte an der Stelle also keine Probleme geben.
Ansonsten läuft FHEM ohne Probleme, kurze Hänger oder Aussetzer habe ich bis dato noch nicht bemerkt. Und wie in meiner Signatur zu sehen ist, hängt schon etwa dran am FHEM.
Was eventuell die Ursache sein kann ist, das der SWI derzeit mit dem Koppelrelais zusammen in einer kleinen Installationsdose hängt, und in der Dose ist nicht viel Platz. Vielleicht ist die elektromagnetische Strahlung der Relaisspule nicht so bekömmlich für den Kleinen. Werde die Tage den SWI mal aus der Dose befreien.
Melde mich dann hier nochmal ob es Verbesserungen gibt.
Danke und Grüße