Hallo Zusammen,
ich will mir ein Teleggram schicken lassen, wenn ein Reading nicht aktualisiert wird, da dann vermutlich die Verbindung ausgefallen ist. Irgendwie klappt das aber nicht. Könnte mich jemand in die richtige Richtung schubsen?
List vom DOIF
Internals:
DEF ([Aussen:humidity]) (set telegram message Achtung \nJeeLink Ausfall) DOELSE
FUUID 5c472d1a-f33f-2776-d4fc-a4458db9dbxxxxx
MODEL FHEM
NAME JeelinkAusfallDOIF
NR 112
NTFY_ORDER 50-JeelinkAusfallDOIF
STATE cmd_1
TYPE DOIF
VERSION 18890 2019-03-13 18:56:41
READINGS:
2019-03-29 10:52:39 Device Aussen
2019-03-17 10:12:15 cmd 1
2019-03-17 10:12:15 cmd_event Aussen
2019-03-17 10:12:15 cmd_nr 1
2019-03-29 10:51:43 e_Aussen_humidity 68
2019-01-24 12:52:02 mode enabled
2019-03-17 10:12:15 state cmd_1
2019-03-29 10:51:43 wait_timer 29.03.2019 11:51:43 cmd_1 Aussen
Regex:
accu:
attr:
wait:
0:
3600
condition:
0 ::ReadingValDoIf($hash,'Aussen','humidity')
devices:
0 Aussen
all Aussen
do:
0:
0 set telegram message Achtung \nJeeLink Ausfall
1:
0
helper:
globalinit 1
last_timer 0
sleeptimer -1
itimer:
perlblock:
readings:
0 Aussen:humidity
all Aussen:humidity
uiState:
uiTable:
Attributes:
do resetwait
room 6_DOIF,Telegram
wait 3600
List vom Device
Internals:
DEF 00
FUUID 5c472d15-f33f-2776-0f6b-375b19fb0xxxxxxx
IODev myJeeLink
NAME Aussen
NR 74
STATE T: 14.5 H: 68
TYPE LaCrosse
addr 00
corr1 0
corr2 0
READINGS:
2019-03-29 10:56:03 battery ok
2019-03-29 10:56:03 humidity 68
2019-03-29 10:55:40 state T: 14.5 H: 68
2019-03-29 10:56:03 temperature 14.5
2019-03-12 14:44:38 windDirectionDegree 247.5
2019-03-12 14:44:38 windDirectionText WSW
2019-03-12 14:44:38 windGust 80.9
2019-03-12 14:44:38 windSpeed 48.6
Attributes:
DbLogExclude state,battery
DbLogInclude temperature|humidity
IODev myJeeLink
alias 1 Aussen
event-min-interval temperature:900,humidity:900,state:900,battery:43200
event-on-change-reading humidity:3,temperature:1
fp_1_OG 191,875,1,Aussen,
fp_2_EG 119,290,1,Aussen,
fp_3_Keller 121,251,1,Aussen,
icon icoKLIMA
room 2_Temperaturen
suppressReading rain
Zitat von: Tungsten am 02 April 2019, 08:34:05Irgendwie klappt das aber nicht.
Was davon klappt denn nicht?
es wird kein Telegram verschickt. Telegram an sich funktioniert aber mit anderen DOIFs, sollte somit funktionieren.
Somit vermute ich den Fehler im DOIF, das erkennen soll wenn sich das Reading des Sensors nicht geändert hat in einem Zeitraum.
Zitat von: Tungsten am 02 April 2019, 12:07:17
es wird kein Telegram verschickt. Telegram an sich funktioniert aber mit anderen DOIFs, sollte somit funktionieren.
Somit vermute ich den Fehler im DOIF, das erkennen soll wenn sich das Reading des Sensors nicht geändert hat in einem Zeitraum.
laut list hat DOIF aber die Anweisung um 10:12:15 Uhr ausgeführt:
2019-03-17 10:12:15 cmd 1
ja, aber das war am 17.3.
das Device hat die Readings zuletzt am 29.3. aktualisiert. Da wurde der Pi auch einmal neu gestartet.
Damit hätte am 29.3. das DOIF schalten müssen, hat es aber nicht... :-(
2019-03-29 10:56:03 humidity 68
Sensor
2019-03-29 10:56:03 humidity 68
DOIF
2019-03-29 10:51:43 wait_timer 29.03.2019 11:51:43 cmd_1 Aussen
Sieht für mich aus, als geht es. War nur noch nicht so weit (11:51:43 sollte Telegram zuschlagen).
ja, aber heute ist der 2.4. und es ist nichts passiert, angekommen. also funktioniert es nicht. weiß aber nicht warum....
wenn ich manuell cmd_1 setze kommt die Nachricht an aber nicht im Live Betrieb.
Setz das DOIF mal zurück und fang von vorn an.
Zitat von: Tungsten am 02 April 2019, 13:50:12
ja, aber heute ist der 2.4. und es ist nichts passiert, angekommen. also funktioniert es nicht. weiß aber nicht warum....
Du postest heute Lists, die aber schon paar Tage alt sind:
2019-03-29 10:51:43 wait_timer 29.03.2019 11:51:43 cmd_1 AussenDieser Eintrag wird entweder verlängert mit aktuellem Datum oder verschwindet, wenn er abläuft (nach 3600 Sekunden). Beides passt hier nicht zu heute.
nein, beide lists sind heute morgen frisch gezogen. es hätte am 29.3. ein Telegram geschickt werden sollen. Wurde es aber nicht. Seit dem sind die Readings nicht aktualisiert worden, da das Device nicht ansprechbar ist. Genau deshalb soll ja das Telegram geschickt werden, damit ich in den Kellere gehe und es einmal aus und wieder einstecke. Leider hat der Stick am Pi kein FTDI so dass nach Pi Restart der Stick einmal neu eingesteckt werden muss. Da ich dies immer vergesse habe ich das DOIF angelegt. Das scheint aber nicht zu funktionieren.
Zitat von: Tungsten am 02 April 2019, 14:49:22
nein, beide lists sind heute morgen frisch gezogen. es hätte am 29.3. ein Telegram geschickt werden sollen. Wurde es aber nicht. Seit dem sind die Readings nicht aktualisiert worden, da das Device nicht ansprechbar ist. Genau deshalb soll ja das Telegram geschickt werden, damit ich in den Kellere gehe und es einmal aus und wieder einstecke. Leider hat der Stick am Pi kein FTDI so dass nach Pi Restart der Stick einmal neu eingesteckt werden muss. Da ich dies immer vergesse habe ich das DOIF angelegt. Das scheint aber nicht zu funktionieren.
wait-Timer überleben keinen Neustart. Mit DOIFtools kannst Du vor einem Neustart abfragen, ob noch wait-Timer laufen, s. https://wiki.fhem.de/wiki/DOIFtools#Laufende_Wait-Timer_anzeigen
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...
Zitat von: Tungsten am 02 April 2019, 14:49:22
nein, beide lists sind heute morgen frisch gezogen. es hätte am 29.3. ein Telegram geschickt werden sollen. Wurde es aber nicht. Seit dem sind die Readings nicht aktualisiert worden, da das Device nicht ansprechbar ist. Genau deshalb soll ja das Telegram geschickt werden, damit ich in den Kellere gehe und es einmal aus und wieder einstecke. Leider hat der Stick am Pi kein FTDI so dass nach Pi Restart der Stick einmal neu eingesteckt werden muss. Da ich dies immer vergesse habe ich das DOIF angelegt. Das scheint aber nicht zu funktionieren.
Dann muss auch dein DOIF stehen ;) , denn
dieser Eintrag
2019-03-29 10:51:43 wait_timer 29.03.2019 11:51:43 cmd_1 Aussen
kann so nicht sein . Ob dein Device etwas sendet oder nicht, es können hier keine Zeiten stehen, die älter als deine gesetzten 3600 Sekunden sind.
was soll ich sagen, so habe ich es heute morgen ausgelesen.... :-(
Zitat von: Tungsten am 02 April 2019, 15:32:13
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.
Zitat von: Tungsten am 02 April 2019, 16:02:47
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.
Zitat von: Damian am 02 April 2019, 17:53:39
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.
Zitat2019.04.02 18:02:33.164 0: Server shutdown
Zitatwait_timer 02.04.2019 18:32:12 cmd_1 FS 2019-04-02 18:02:12
Das Reading existiert wie erwartet auch nach vermeintlichem Ablauf des Timers noch
Zitatwait_timer 02.04.2019 18:32:12 cmd_1 FS 2019-04-02 18:02:12
Zitat von: Ellert am 02 April 2019, 18:20:17
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:
([Aussen:humidity] or [global:"^INITIALIZED$"]) (set telegram message Achtung \nJeeLink Ausfall)und alles ist gut.
PS.: DOELSE ist hier überflüssig
Danke Euch!
DOELSE am Ende habe ich mir mal angewöhnt... ::)
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?
Zitat von: Tungsten am 02 April 2019, 18:52:54
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.
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:
ZitatInternals:
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:
ZitatInternals:
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
okay, das beantwortet glaube ich meine Frage.
https://forum.fhem.de/index.php?topic=66389.0
Zu schnell geschrieben und noch nicht gesucht... ;-)
Hast Du schon versucht das USB-Device by-path einzubinden, ich meine gelesen zu haben, dass damit die Zuordnungsprobleme behoben werden.
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?
Zitat von: Tungsten am 03 April 2019, 08:54:32
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.
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.
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.
Vielleicht noch ein paar Anmerkungen zur eindeutigen Adressierung von USB-Geräten: Grundsätzlich haben alle USB-Geräte eine Minimal-ID, anhand der das OS die ganzen Zuordnungen macht. Also auch die CHG34x-e. udev bringt einen da nur begrenzt weiter, denn der hat auch keine erweiterten Erkenntnismöglichkeiten (und wird afaik bei debian-Systemen üblicherweise verwendet, um "by-id" und "by-path" abzuleiten).
Das Problem bei den CHG34x ist nur, dass die alle DIESELBE ID haben, weswegen "by-id" dann nicht funktioniert, wenn man MEHRERE im Einsatz hat. Bei einem (dieses Typs, andere Typen sind schnurz) klappt das by-id nach meinem Kenntnisstand immer; hat man mehrere von denen, sollte man die betreffenden IO's ALLE by-path definieren. Alle anderen (nicht-CHG34x) können auch by-id sein, das ich grundsätzlich vorziehen würde, weil das auch dann klappt, wenn man mal Sticks abzieht und andersherum einsteckt.
MaW: was ist sonst noch an seriellen Geräten an USB eingebunden?