Hallo,
ich habe 2 mehr oder weniger identische JsonMod-Definitionen, die einmal täglich eine Abfrage machen.
Für eine Weile funktionieren die beiden devices wie erwartet, aber dann hören sie auf sich zu aktualisieren.
Ein normaler Blick aufs Device zeigt keinerlei Fehler oder ähnliches. Ein reread führt zu folgender Fehlermeldung:
request already pending
Das einzige was hilft, ist auf DEF zu klicken und ohne Änderungen zu speichern.
Damit wird die interne Variable IN_REQUEST zurückgesetzt und es funktioniert wieder.
Nur: Das Device nutzt 3 "secrets", die für die HTTP-Abfrage wichtig sind, und es scheint ein Klicken auf DEF inklusive Speichern ohne Änderung setzt die Secrets zurück.
Danach muss ich alle 3 Secrets neu setzen, damit eine Abfrage wieder funktioniert.
Hier ist das List von einem Device:
Internals:
DEF https://bestellung-rest.gourmetta.de/users/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx/order?from=[today]&to=[tomorrow]
FUUID 63224849-f33f-9ecb-d3ba-af3ace033ae605fa
NAME web.gourmetta.Emma
NEXT 2022-10-12 01:00:00
NR 447
SECRETS today, tomorrow, token
STATE Kräuterquark mit Salzkartoffeln, dazu bunter Blattsalat mit Zitronendressing
SVN 24783 2021-07-21 22:37:12 UTC
TYPE JsonMod
eventCount 267
CONFIG:
IN_REQUEST 1
SOURCE https://bestellung-rest.gourmetta.de/users/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx/order?from=[today]&to=[tomorrow]
SECRET:
READINGS:
2022-10-10 01:00:00 meal_2022-10-10_0 Kräuterquark mit Salzkartoffeln, dazu bunter Blattsalat mit Zitronendressing
2022-10-10 01:00:00 meal_2022-10-11_0 Hähnchengeschnetzeltes, dazu Gemüse & Beilage nach Wahl
2022-10-10 01:00:00 meal_today Kräuterquark mit Salzkartoffeln, dazu bunter Blattsalat mit Zitronendressing
2022-10-10 01:00:00 meal_tomorrow Hähnchengeschnetzeltes, dazu Gemüse & Beilage nach Wahl
2022-10-10 01:00:00 today 2022-10-10
2022-10-10 01:00:00 tomorrow 2022-10-11
Attributes:
httpHeader Authorization: Bearer [token]
interval 0 1 * * *
readingList multi(jsonPath('$.orderDays[0].orderedMeals[?(@.quantity==1)]'), sprintf('meal_%s_%s', property('meal.date'), count()), sprintf('%s %s', property('meal.name'), property('meal.description')));
multi(jsonPath('$.orderDays[1].orderedMeals[?(@.quantity==1)]'), sprintf('meal_%s_%s', property('meal.date'), count()), sprintf('%s %s', property('meal.name'), property('meal.description')));
single(jsonPath('$.from'), 'today', 'n/a');
single(jsonPath('$.to'), 'tomorrow', 'n/a');
room System->Gourmetta
stateFormat meal_today
userReadings meal_today {
ReadingsVal("$name",'meal_'.ReadingsVal('di.gourmetta.Date','today','').'_0', '')
},
meal_tomorrow {
ReadingsVal("$name",'meal_'.ReadingsVal('di.gourmetta.Date','tomorrow','').'_0', '')
}
verbose 3
Hat jemand eine Idee was das Problem sein könnte?
kannst du es reproduzieren mit verbose 5 und ggf stacktrace und den log-Auszug hier teilen sodass herrmannj eine Chance zur Analyse hat?
Ggf auch ein list, wenn das Device "hängt".
Das oben gepostete list ist im "hängenden" Zustand, siehe internal variable "IN_REQUEST".
Ich schraub mal das log level hoch.
Stack Trace ist in den globals aktiviert, aber in den Logs taucht hierzu nichts auf.
Ich habe in den Logs entdeckt, dass mein FHEM immer genau um 00:05 Uhr abgestürzt ist und von systemd neu gestartet wurde.
In den Logs ist keinerlei Hinweis warum es abgestürzt ist.
Um 00:05 Uhr läuft bei mir ein DOIF, welches am JsonMod-Device zuerst 2x set secret <key> <secret> aufruft, und im Anschluss set myJsonMod reread triggert.
Ich vermute stark dass der Absturz in letzterem Call passiert, bekomme es aber auf eine Testinstanz nicht nachgestellt.
Ich habe jetzt den set reread ... Call aus dem DOIF entfernt, und nutze das interval im JsonMod-Device direkt.
Seither kein Abstürz, und auch kein hängendes JsonMod.
Ich markiere das Topic als gelöst.