DOIF - Telegram bei Ausfall

[Ellert]

hm, dann hab ich ein grundsätzliches design problem. wie löse ich das problem? ich schaue doch vor einem neustart nicht in FHEM nach wait timern, sonst könnte ich ja auch dran denken in den keller zu laufen und den stick raus und reinzustecken. vergesse ich aber immer wieder...

Es gibt ein globales Initialisierungsereignis nach einem Neustart, darauf könntest Du triggern.

[Damian]

was soll ich sagen, so habe ich es heute morgen ausgelesen....

Tja, ich habe noch nicht erlebt, dass ein Timer verloren geht. Du kannst die wait-Zeitspanne auf ein paar Sekunden setzen und das Modul durch ein Event künstlich antriggern und schauen, ob nach Ablauf der Zeitspanne (ohne weitere Trigger) das wait_timer-Reading auf "no timer" wechselt, ansonsten stimmt mit deinem System etwas nicht.

Nach einem Neustart wird das Reading wait_timer gelöscht und erst mit dem ersten Trigger gesetzt.

[Ellert]

Nach einem Neustart wird das Reading wait_timer gelöscht und erst mit dem ersten Trigger gesetzt.

Das kann ich nicht nachvollziehen. Ich habe save und shutdown restart ausgeführt, danach wird der Timer weiterhin angezeigt. Die Readings werden nach der Initialisierung aus fhem.save restauriert, der laufende Timer natürlich nicht.

Wenn kein save ausgeführt wird, dann existiert das Reading nach Neustart nicht.

2019.04.02 18:02:33.164 0: Server shutdown

wait_timer  02.04.2019 18:32:12 cmd_1 FS   2019-04-02 18:02:12

[Ellert]

Das Reading existiert wie erwartet auch nach vermeintlichem Ablauf des Timers noch

wait_timer  02.04.2019 18:32:12 cmd_1 FS   2019-04-02 18:02:12

[Damian]

Das kann ich nicht nachvollziehen. Ich habe save und shutdown restart ausgeführt, danach wird der Timer weiterhin angezeigt. Die Readings werden nach der Initialisierung aus fhem.save restauriert, der laufende Timer natürlich nicht.

Wenn kein save ausgeführt wird, dann existiert das Reading nach Neustart nicht.

Ok. Dann erklärt das einiges. Den Fall habe ich so offenbar noch nicht getestet. Das Reading, wie viele andere, werden, wie ich gerade nachgeschaut habe, nur bei defmod zur Laufzeit gelöscht.

Es ist sicherlich ein Schönheitsfehler, den ich beheben könnte, auf der anderen Seite weiß man jetzt, dass das System, vor dem Ablauf des Timers heruntergefahren wurde.

Dann braucht man nur zu definieren:

Code Auswählen Erweitern

([Aussen:humidity] or [global:"^INITIALIZED$"]) (set telegram message Achtung \nJeeLink Ausfall)

und alles ist gut.

PS.: DOELSE ist hier überflüssig

[Tungsten]

Danke Euch!

DOELSE am Ende habe ich mir mal angewöhnt... 

[Tungsten]

eine Frage noch die mir gerade gekommen ist.
Ich frage hier ja umständlich ein Reading ab um zu prüfen um ein Stick arbeitet. Könnte man auch direkt auf das USB Devices am Pi prüfen, ob es da ist?

[Damian]

eine Frage noch die mir gerade gekommen ist.
Ich frage hier ja umständlich ein Reading ab um zu prüfen um ein Stick arbeitet. Könnte man auch direkt auf das USB Devices am Pi prüfen, ob es da ist?

Dahinter verbirgt sich sicherlich ein USB-Device, welches in FHEM definiert ist und seinen aktuellen Zustand anzeigt, den man nach dem Hochfahren abfragen kann. Wie es geht, habe ich in meinem letzten Post aufgezeigt.

[Tungsten]

sorry, evtl habe ich mich nicht klar ausgedrückt. Das device was ich aktuell abfrage ist ein Lacross Funksensor. Kein USB Device. Ich versuche jedoch darüber, dass das Device keine neuen Readings erzeugt heraus zu finden ob der JeeLink USB Stick arbeitet.

Habe mal ein list auf das JeeLink device gemacht.

Nach einem Neustart des Pi fehlen ein paar Internals und werden erst nach einen Aus und Einstecken des JeeLink gesetzt. Wenn ich auf diese prüfen kann, wüsste ich dass der Stick nicht arbeitet.
Das einzige Reading ist State und das bleibt immer auf initialized.

Die Frage ist also eher ob ich auch auf Internals prüfen kann, ob vorhanden oder nicht?

Nach Neustart des Pi:

Internals:
   Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
   FD         19
   FUUID      5c472d14-f33f-2776-105c-8f08dac8ac011ab9
   NAME       myJeeLink
   NR         53
   PARTIAL   
   STATE      initialized
   TYPE       JeeLink
   initMessages
   model      LaCrosseITPlusReader.10.1q
   settings   (RFM12 f:868300 r:17241)
   MatchList:
     1:PCA301   ^\S+\s+24
     2:EC3000   ^\S+\s+22
     3:RoomNode ^\S+\s+11
     4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     5:AliRF    ^\S+\s+5
     6:EMT7110  ^OK\sEMT7110\s
     7:KeyValueProtocol ^OK\sVALUES\s
   READINGS:
     2019-04-02 19:13:00   state           initialized
Attributes:
   flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
   initCommands 0m 0r 0t 6M 2R 20T 868300f 60h 0a v
   room       LaCrosse

Nach Aus und Einstecken des Jeelink am Pi:

Internals:
   Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
   FD         64
   FUUID      5c472d14-f33f-2776-105c-8f08dac8ac011ab9
   NAME       myJeeLink
   NR         53
   PARTIAL   
   RAWMSG     OK 9 44 1 4 184 45
   STATE      initialized
   TYPE       JeeLink
   initMessages
   model      LaCrosseITPlusReader.10.1q
  myJeeLink_MSGCNT 87
  myJeeLink_TIME 2019-04-02 19:25:51
   settings   (RFM12 f:868300 r:17241)
   MatchList:
     1:PCA301   ^\S+\s+24
     2:EC3000   ^\S+\s+22
     3:RoomNode ^\S+\s+11
     4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     5:AliRF    ^\S+\s+5
     6:EMT7110  ^OK\sEMT7110\s
     7:KeyValueProtocol ^OK\sVALUES\s
   READINGS:
     2019-04-02 19:25:51   state           initialized
Attributes:
   flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
   initCommands 0m 0r 0t 6M 2R 20T 868300f 60h 0a v
   room       LaCrosse

[Tungsten]

okay, das beantwortet glaube ich meine Frage.
https://forum.fhem.de/index.php?topic=66389.0

Zu schnell geschrieben und noch nicht gesucht...

[Ellert]

Hast Du schon versucht das USB-Device by-path einzubinden, ich meine gelesen zu haben, dass damit die Zuordnungsprobleme behoben werden.

[Tungsten]

nein, was genau meinst du damit?

Mein Gedanke auf eins der Internals zu prüfen scheint nicht zu gehen, da das Internal ja gar nicht da ist. Was ich bisher gelesen habe kann man nur auf den Wert eines Internals prüfen, aber nicht ob das Internal überhaupt da ist, oder?

[Ellert]

nein, was genau meinst du damit?

Du hast das USB-Device in FHEM eingebunden und wenn Du Dir die Listings ansiehst, dann siehst Du in der Zeile, die mit DEF beginnt, das es by-id eingebunden ist.
Da der CH340 keine ID hat, gibt es Zuordnungsprobleme. Wenn Du es by-path einbindest, soll es die Probleme nicht geben. Einen Link zu einer Anleitung habe ich nicht parat, da müsstest Du Dich selbst bemühen, die Stichworte sind hier schon gefallen.

Es ist immer sinvoller die Ursachen eines Problems zu bekämpfen, als die Symptome, aber Du könntest auch auf das nicht vorhanden sein eines Internals prüfen, über den Defaultwert.

[Tungsten]

habe es jetzt mal so eingebunden:

/dev/serial/by-path/platform-3f980000.usb-usb-0:1.2.4:1.0-port0@57600

Leider wird nach einem Restart des Pi auch in diesem Fall der Stick nicht eingebunden.
Ich muss wieder erst den Stick abziehen und wieder neu verbinden.
Schade, hatte gehofft dies mit deinem Hinweis nicht mehr machen zu müssen.

[Ellert]

Kann sein, dass andere USB-Geräte (falls vorhanden) auch by-path eingebunden werden müssen, damit der Pfad nicht weggeschnapt wird.

Dann gibt es noch die Möglichkeit Geräte über eine udev-Regel eindeutig einzubinden, ein erster Einstieg https://wiki.ubuntuusers.de/udev/ , dass wurde hier auch schon mal diskutiert.