Frage zu Homematic-Protokoll-Handling

imh · 06 Januar 2016, 02:54:25

Hallo,
ich bin schon eine ganze Weile mit FHEM unterwegs und bin bisher -wenn auch nicht ganz ohne Schwierigkeit- mit der Dokumentation zurechtgekommen!
Jetzt habe ich aber ein Problem, bei dem ich nicht weiterkomme:
Ich versuche eine bestehende Flurschaltung mit einem Eltako Stromstoßrelais um einen Homematic-Bewegungsmelder mit FHEM zu ergänzen.
Um die Kosten für den Umbau des Sicherungskastens durch einen Elektriker zu sparen, habe ich einen der Taster durch einen Homematic HM-LC-Sw1PBU-FM ersetzt.
Natürlich war ich mir über die Problematik im Klaren, wie sie in dem Dokument "HomeMatic®-Know-how Teil 5" beschrieben ist, dass man den Status des Lichtes nicht ermitteln kann, da zum Schalten ja der Befehl "set Flur_Licht on-for-timer 0.5" verwendet wird und so der Schalter immer ausgeschaltet ist!
Daher habe ich ein Dummy definiert, in dem ich mir den Schalt-Status sorgfältig merke!
Das Ganze funktioniert meistens problemlos, manchmal gerät das ganze leider aus dem Tritt!
Als Ursache vermute ich, dass aus irgendwelchen Gründen ein Funktelegramm oder ein ACK nicht ankommt! Ein evt. Resend bewirkt dann, dass der Status nicht mehr stimmt.
Für mich ergeben sich folgende Fragen:
1. Wie kann man Protokoll Fehler abfangen, geht das überhaupt?
2. Leider sehe ich in den Protokollfiles keinen Hinweis auf solche Unregelmäßigkeiten beim Protokollablauf, kann man da etwas einschalten?
3. Was passiert eigentlich bei Paket-Kollisionen auf der Funkschnittstelle? Z.B. wenn ein ACK-Paket verloren geht. Ich fürchte, dass das Paket dann erneut gesendet wird, worauf das Licht dann gleich wieder aus-/eingeschaltet wird!
Vielen Dank für jede Hilfe
Ingo

martinp876 · 06 Januar 2016, 11:04:25

Ein hmlan wiederholt 3mal automatisch on top kann man msgrepeat einstellen. Dann wiederholt fhem 0 vor 1000mal. Das geht dann auch bei einer cul.
Ein aktor sollte das abkoennen und die Wiederholung als solche erkennen.
Du solltest hminfo protoevents nutzen und clear Protocol um eine Übersicht zum erhalten, was wiederholt wird.

frank · 06 Januar 2016, 12:50:29

ZitatUm die Kosten für den Umbau des Sicherungskastens durch einen Elektriker zu sparen, habe ich einen der Taster durch einen Homematic HM-LC-Sw1PBU-FM ersetzt.
Natürlich war ich mir über die Problematik im Klaren, wie sie in dem Dokument "HomeMatic®-Know-how Teil 5" beschrieben ist, dass man den Status des Lichtes nicht ermitteln kann, da zum Schalten ja der Befehl "set Flur_Licht on-for-timer 0.5" verwendet wird und so der Schalter immer ausgeschaltet ist!

besser wäre natürlich der austausch des eltako mit einem homematic aktor.
entweder sw1-fm oder der sw1-dr im hutschienen gehäuse. dann gibt es auch den status.

martinp876 · 06 Januar 2016, 13:37:40

Und teurer wird es auch kaum

imh · 06 Januar 2016, 16:41:15

Vielen Dank für die schnelle Antwort!
Bin mir schon im Klaren, dass ein anderer Aktor besser wäre, werde ich wohl auch demnächst umstellen! (Wollte mir, wie gesagt, die Kosten für den Elektriker sparen!)
Trotzdem finde ich es unbefriedigend, dass man nicht selber genau feststellen kann, ob ein Schaltvorgang geklappt hat oder nicht! Schön wäre es, wenn man nach dem "set on-for-timer 0.5" abfragen könnte, ob er geklappt hat oder nicht!
Dass das Teil einfach den Schaltvorgang wiederholt, ohne zu wissen, ob bereits geschaltet wurde, finde ich unbefriedigend!
Mit hminfo protoevents hatte ich schon rumgespielt aber da sieht man doch nur eine Zusammenfassung und nicht für jeden Vorgang, warum er nicht funktioniert hat und was zur Behebung unternommen wurde! (... oder habe ich da etwas übersehen?)
Es gibt wohl von EQ-3 keine Beschreibung, wie genau der Protokollablauf im Fehlerfalle ist?
Ich verwende den HM-CFG-USB-2 mit (zusammen mit hmcfgusb mit der VERSION "0.097-git), nehme an, dass der auch immer 3 Mal wiederholt?
Es ist ja dann wohl grundsätzlich sinnvoll, msgrepeat auf 0 zu setzen, denn dass die Übertragung 3 Mal nicht funktioniert aber beim 4. Mal schon, ist doch wohl eher unwahrscheinlich, oder?!
Vielen Dank noch einmal Gruß Ingo

frank · 06 Januar 2016, 16:50:31

ZitatTrotzdem finde ich es unbefriedigend, dass man nicht selber genau feststellen kann, ob ein Schaltvorgang geklappt hat oder nicht! Schön wäre es, wenn man nach dem "set on-for-timer 0.5" abfragen könnte, ob er geklappt hat oder nicht!

das solltest du aber erkennen können. der status am sw1pbu muss doch kurz "on" oder level=100 melden. ebenso sollte timedOn kurz "running" melden.

imh · 06 Januar 2016, 17:04:32

... wo soll ich diese Meldungen finden? im Logfile fhem-yyyy-mm.log jedenfalls nicht!
Vielleicht sieht man das im Web-Interface, wenn man es offen hat ... ist schwierig, weil ich ja nicht weiß, wann das Problem auftritt. Ich merke es ja erst später, wenn die Helligkeit mit der Schalterstellung nicht stimmt!
... wie gesagt wäre schön, wenn das detailliert im Logfile dokumentiert würde.

frank · 06 Januar 2016, 17:21:11

Zitat... wo soll ich diese Meldungen finden? im Logfile fhem-yyyy-mm.log jedenfalls nicht!

hm...., das ist aber eine absolute fhem-anfänger frage! also einsteiger.doc benutzen und events verstehen lernen.
auf events kannst du dann mit notify, watchdog, logfile, ... etc reagieren.

du kannst auch verbose hochdrehen. da sollte einiges zu sehen sein.

ZitatIch merke es ja erst später, wenn die Helligkeit mit der Schalterstellung nicht stimmt!

welche schalterstellung? ich denke, es gibt nur taaster?

imh · 06 Januar 2016, 18:39:55

... habe die Doku natürlich durchaus gelesen und ich kenne natürlich auch Events und benutze auch mehrere notifys für die Schaltung der Bewegungsmelder. Natürlich habe ich auch mehrere Logfiles z.B. auch für den Schalter angelegt ... sehe gerade nach ... tatsächlich gibt es dort Einträge mit level: 0 und level: 100. Habe ich bisher nicht verstanden, was der level bedeutet ... wo ist das erklärt? ... ich schaue die Doku noch einmal durch!
Sorry

martinp876 · 06 Januar 2016, 22:12:45

Es ist in der tat ( bei weitem)nicht alles erklärt. Einiges halte ich für intuitiv, auch wenn man kurz nachdenken muss. Es natürlich (ehrlich) möglich, dass es nicht jedem so schnell klar wird. Fhem hm hat keine durchgängige Dokumentation von vorne bis hinten und von ganz oben bis ganz unten. Falls das jemand in angriff nimmt ist es nur eine Frage der Zeit. Jeder bemängelt, dass etwas anders fehlt. Zu recht, also auf!!!
Dass jemand in der lage ist events zu beobachten und readings zu lesen die sowieso immer kommen (level beim Schalter) halte ich für eine leichtere Übung, als es verbal wasserdicht zu beschreiben. Dass man bei level 0 zeitgleich zu off und 100 zu on würde ich erwarten, dass man es sich herleiten kann. Muss man das wirklich beschreiben? Sieht man das mit etwas gutem willen nicht?
Die Frage ist ehrlich gemeint, da mich dieses Niveau immer wieder einmal verblüfft. Klar kann jeder etwas über sehen haben.......

imh · 06 Januar 2016, 23:00:42

Ich gebe euch völlig recht, dass wenn man sich überlegt, was das "level:" bedeutet, man schon darauf kommen kann, dass es für 100% also "on" steht!! Das Problem war hier, dass ich die Einträge "level: 100/0" in den Log-Files gar nicht wahrgenommen habe!! Denn sie sind ja redundant, oder?
Interessiert hat mich bisher nur der Eintrag "Flur_Licht off/on"! Mit meinem zugegebener beschränkten Verständnis ist es ohnehin verwirrend, dass in dem Logfile /s.u.) 5 Einträge sind, obwohl eigentlich nur einer interessiert! Es wäre natürlich toll, wenn es irgendwo eine genaue Beschreibung der einzelnen Logeinträge gäbe ... könnte man dran arbeiten, aber man brauchte natürlich einen Input! Hilft es eigentlich in die Perl-Source hineinzuschauen?
Aber nichts für ungut, ich bin sehr froh, dass es FHEM gibt ... allerdings ist die Lernkurve nicht wirklich steil ...

2016-01-06_22:31:33 Flur_Licht deviceMsg: on (to hmusb)
2016-01-06_22:31:33 Flur_Licht level: 100
2016-01-06_22:31:33 Flur_Licht pct: 100
2016-01-06_22:31:33 Flur_Licht on
2016-01-06_22:31:33 Flur_Licht timedOn: running

martinp876 · 07 Januar 2016, 07:46:55

Redundant nur bedingt. 100 kann ich ggf zum rechnen nutzen, besonders bei Dimmer und blind. On ist besser für eine Darstellung. PCT braucht man für die Darstellung der slider. Devicemessage ist ein Artefakt das einige in ihren script nutzen, da hier die destination mit drin ist.
Wenn man es nicht findet hat man wohl nicht aufgepast. Wäre das beim lesen besser?
Aber noch einmal: ran ans Werk! Wenn man das braucht und dir klar ist dass man es beschreiben muss und was man dazu schreiben muss um es zum verstehen und sich der Aufwand lohnt, dann mach es doch. Davon lebt die community.