Module für pilight (Senden und Empfangen)

[anfichtn]

So, etwas zum lesen.

Code Auswählen Erweitern

Internals:
   API        6.0
   DEF        localhost:5000
   DeviceName localhost:5000
   FD         19
   NAME       pilight
   NR         126
   NTFY_ORDER 50-pilight
   PARTIAL
   RETRY_INTERVAL 60
   STATE      opened
   TYPE       pilight_ctrl
   CHANGETIME:
   Helper:
     Dblog:
       State:
         Mydblog:
           TIME       1433966333.92752
           VALUE      DISCONNECTED
   Readings:
     2015-06-10 21:58:21   rcv_raw         0
     2015-06-10 22:31:23   state           opened
   Helper:
     CON        connected
     LAST_RCV_PROTOCOL clarus_switch
     LAST_RCV_RAW {"message":{"id":"F15","unit":63,"state":"off"},"origin":"receiver","protocol":"clarus_switch","uuid":"0000-98-3b-16-e96c5c","repeats":1}
     sendQueue:
     whiteList:
       intertechno_switch:15742938
Attributes:
   ContactAsSwitch 15742938
   brands     arctech:intertechno
   ignoreProtocol *
   room       99_System
   verbose  5


Unter readings steht ein kleines state... derzeit mit "opened".

Wegen Verbose 5... ist jetzt auch bei alle 3 definierten Switches gesetzt.

Es schalten weder der state vom Switch noch die Hardware.

Ich helf dir gern wo ich nur kann.

Aber: das System muss funktionieren Ich bin irgendwie dagegen, dass kleine Kinder nachts fernsehen ^^

Grüße

anfichtn

[NeckCheck]

Du verwendest nicht mein Modul. Hier geht es um pilight_ctrl und pilight_switch!!

Risiko

Ich habe nicht gemerkt dass es da mehrere Pilight Module gibt. Ich habe deins probiert, aber ich bekomme diese blöde Fehlermeldung " cannot load module ". Dann habe ich bisschen im Internet gesucht und das andere gefunden.

Eine Idee, was es mit der Fehlermeldung zu tun haben kann. Wie gesagt die ganzen Perl Pakete sind installiert.

[Risiko]

Hallo anfichtn,

leider kann ich hier auch nicht viel erkennen.
rcv_raw  ist 0, und das Reading state ist zeitlich neuer. Gab es einen Verbindungsabbruch zum daemon?

Könntest du mal das device aus DB_Log raus nehmen?

Wegen Verbose 5... ist jetzt auch bei alle 3 definierten Switches gesetzt.

Hast du hier auch noch Logs?

Risiko

[Risiko]

Eine Idee, was es mit der Fehlermeldung zu tun haben kann. Wie gesagt die ganzen Perl Pakete sind installiert.

Nein habe ich nicht. Ich denke immer noch, dass da was fehlt.
Du kannst ja auch keine weiteren Infos liefern.

Risiko

[anfichtn]

Hallo anfichtn,

leider kann ich hier auch nicht viel erkennen.
rcv_raw  ist 0, und das Reading state ist zeitlich neuer. Gab es einen Verbindungsabbruch zum daemon?

Könntest du mal das device aus DB_Log raus nehmen?
Hast du hier auch noch Logs?

Risiko

Derzeit nicht.
Liefere ich aber beim nächsten auftreten.

Grüße

anfichtn

[FunkOdyssey]

Ich hatte nun auch wieder das Problem, dass ich den FHEM-Service neu starten musste.
Im State des CTRL-Device stand im State auch "0". Nach dem Reset ging dieser auf "Open". Aber dennoch wurden keine Geräte eingeschaltet. Die GUI reagierte nun aber.

Sieht auch für mich danach aus, als wäre die Verbundung zum Pilight-Daemon verloren gegangen.

[Risiko]

Hallo.
Habe heut nochmal alles nachgesehen. state wird im Modul selbst nicht verwendet. Allein DevIo setzt ihn auf open oder disconnected. Keine Ahnung wo die 0 herkommen soll. Verwendest du auch Dblog?
Wenn die Verbindung zum daemon verloren geht, sollte das auch im Log zu sehen sein

Komme da leider nicht weiter, da ich den Fehler nicht habe und alle bisherigen Logs ok waren.

Risiko

[FunkOdyssey]

Ich hab jetzt mal ein Log für das CTRL-Device angelegt und werde es mal beobachten. Im globalen FHEM-Log konnte ich auf die Schnelle (mittels Smartphone) nichts finden.

Ich nutze übrigens kein DbLog.

Inwiefern könnte ich dir helfen?

[Risiko]

Eigenes Log, sehr gut.
Es wäre wichtig, wenn man irgend wie mit bekommt, wann es passiert.
State mit 0 ist aktuell der einzige Anhaltspunkt. Könnte ne Version mit speziellen Logs zur Verfügung stellen, wo der state überwacht wird.

Risiko

[FunkOdyssey]

Klaro. Her damit.
Ich hab schon "verbose" auf "5".

[anfichtn]

Ich helfe auch gerne.

Btw: hast du den Empfänger über den Bandpass - AtTiny laufen? Wenn ja,  an 5V oder an 3,3V angeschlossenen?

Grüße

[FunkOdyssey]

@anfichtn: Falls du mich meinst: ich habe keinen Empfänger angeschlossen.



Nachtrag
Kleines Update. Ich stelle gerade fest, dass im pi_ctrl-Device wieder der Status "0" steht.
Im dazugehörigen Log finde ich jedoch absolut gar nichts. Trotz "vebose:5".
Ist aber, glaube ich, auch total egal.
Und zwar war die Statusänderung zu einem Zeitpunkt, wo FHEM neu gestartet wurde. Beim Neustart von FHEM wird also höchstwahrscheinlich dieser Status gesetzt.

Aber auch das ist scheinbar egal:
Denn meine pi_switche laufen wunderbar. Egal wie der Status von pi_ctrl aussieht, ich kann die Zwischenstecker problemlos schalten.

Ich denke somit, dass wir in der falschen Richtung suchen.

---

Nichtsdestotrotz kann ich natürlich gerne ein Debug-Log anlegen. Denn irgendetwas führt halt sporadisch dazu, dass das Fhem-Pilight-Modul die (vermutlich) Verbindung zum pilight-daemon verliert und nur ein Neustart des Fhem-Services weiterhilft.

Könnten das evtl. durchgeführte Updates oder Neustarts (shutdown restart) sein?

[Risiko]

Btw: hast du den Empfänger über den Bandpass - AtTiny laufen? Wenn ja,  an 5V oder an 3,3V angeschlossenen?

Ja. An 5V

[anfichtn]

Danke. Ich hab das dann mal ebenso gemacht. Bisher läuft es. Deutlich weniger CPU-Last Kann ich zwar nicht feststellen, aber okay.

[Risiko]

Kleines Update. Ich stelle gerade fest, dass im pi_ctrl-Device wieder der Status "0" steht.
Im dazugehörigen Log finde ich jedoch absolut gar nichts. Trotz "vebose:5".
Ist aber, glaube ich, auch total egal.
Und zwar war die Statusänderung zu einem Zeitpunkt, wo FHEM neu gestartet wurde. Beim Neustart von FHEM wird also höchstwahrscheinlich dieser Status gesetzt.

Nicht ganz. Ich lösche eigentlich explizit das Reading state im CTRL-Device, da nur das interne STATE benötigt wird.

Aber auch das ist scheinbar egal:
Denn meine pi_switche laufen wunderbar. Egal wie der Status von pi_ctrl aussieht, ich kann die Zwischenstecker problemlos schalten.

Wie gesagt, state sollte es nicht geben. Wenn aber das interne STATE auf disconnected steht, dann ist die Verbindung zum daemon unterbrochen.

Ich denke somit, dass wir in der falschen Richtung suchen.

Könnte sein. Würde es aber noch nicht ausschließen wollen.

Könnten das evtl. durchgeführte Updates oder Neustarts (shutdown restart) sein?

Damit habe ich auch noch nie Probleme gehabt.

Ich versuche am WE eine neue Version mit mehr Log's zu erstellen und hoffentlich finde ich dann den Fehler.

Risiko