[37_echodevice] Amazon Echo Modul (nicht Alexa)

[michael.winkler]

Guten Morgen zusammen.
Ich habe ein Problem mit der Moduldatei 37_echodevice.pm.
Seit Anfang des Jahres ist die Datei ja mit im FHEM-Repo, sodass Aktualiserungen per Fhem Update passieren. Mir ist gestern aufgefallen, dass meine Datei immer noch auf dem alten Stand 0.0.59 war.
Ich habe dann den Befehl "update 37_echodevice.pm" durchgeführt, was aber dazu führte, dass die Datei aus dem FHEM-verzeichnis gelöscht wurde.
Nach Recherche habe ich nichts gefunden, was das auslösen könnte. Ein erneutes Update hat auch nichts geholfen.
Muss ein bestimmter Befehl eingegeben werden, wenn man Module neue Module in FHEM aktivieren will?

Ich habe auch schon einmal ein "update force" durchgeführt. Dies hat zwar auch nicht dazu geführt, dass die Modul-Datei heruntergeladen wurde, allerdings hatte danach das update der Moduls geklappt und ich konnte erfolgreich Amazon und die Echos verbinden.
Nach einem Fhem Crash gestern abend (andere Geschichte) wurde aber dann die Moduldatei "37_echodevice.pm" beim Booten wieder gelöscht... Ich verstehe nicht, warum.

Im Log steht dazu nichts. Nur eben dass er die ganze echodevices nicht finden konnte, weil sie aufgrund des fehlenden Moduls nicht mehr geladen werden können.

Noch ein Hinweis. Ich benutzte configDB und hatte die echodevice-Moduldatei als fileimport in die DB importiert.

Ich bin mir nicht ganz sicher, ob das tatsächlich ein Thema ist, was direkt mit diesem Modul zu tun hat, aber bisher hatte ich solche Probleme mit anderen Modulen nicht.
Danke schonmal.

lösche mal das Modul aus Deinem FHEM Verzeichnis. Danach direkt ein Update durchführen.

[michael.winkler]

die Dreambox war aber auch immer im Spiel. Vielleicht einen separaten Thread eröffnen und das freeze-log posten ? 
Ok, was ich meinte sind die bei mir vorhandenen freezes

Code Auswählen Erweitern

2020.04.17 18:58:55 3: [Freezemon] freezedetect: possible freeze starting at 18:58:55, delay is 0.62 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_WWL)
2020.04.17 18:59:55 3: [Freezemon] freezedetect: possible freeze starting at 18:59:55, delay is 0.391 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(RPi_OW_VL) tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-statistics_PeriodChange(stat_wr) tmr-statistics_PeriodChange(stat_sl)
2020.04.17 19:02:55 3: [Freezemon] freezedetect: possible freeze starting at 19:02:55, delay is 0.948 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina)
2020.04.18 11:01:29 3: [Freezemon] freezedetect: possible freeze starting at 11:01:29, delay is 0.892 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius)
2020.04.18 21:04:49 3: [Freezemon] freezedetect: possible freeze starting at 21:04:49, delay is 0.323 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina)
2020.04.19 18:18:34 3: [Freezemon] freezedetect: possible freeze starting at 18:18:34, delay is 0.485 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius)
2020.04.19 18:35:35 3: [Freezemon] freezedetect: possible freeze starting at 18:35:35, delay is 0.474 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_KS)


Komisch, dass meine Nina immer dabei ist. Ne Idee warum dessen blocking call in die Ausführung des echodevice funkt ?

Code Auswählen Erweitern

[Freezemon] freezedetect: possible freeze starting at 18:35:35, delay is 0.474 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_KS)
2020.04.19 18:35:34.332 5: [echomaster] [echodevice_GetSettings] start refresh settings
2020.04.19 18:35:34.332 4: [echomaster] [echodevice_SendCommand] [getnotifications] START
2020.04.19 18:35:34.333 4: [echomaster] [echodevice_SendCommand] [getnotifications] PushToCmdQueue SendURL =https://layla.amazon.de/api/notifications
2020.04.19 18:35:34.333 4: [echomaster] [echodevice_SendCommand] [getnotifications] PushToCmdQueue SendData=
2020.04.19 18:35:34.334 4: [echomaster] [echodevice_HandleCmdQueue] [getnotifications] send command=https://layla.amazon.de/api/notifications Data=
2020.04.19 18:35:34.335 5: HttpUtils url=https://layla.amazon.de/api/notifications
2020.04.19 18:35:34.335 5: HttpUtils request header:
GET /api/notifications HTTP/1.1
Host: layla.amazon.de
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Accept-Language: de,en-US;q=0.7,en;q=0.3
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cookie:meinCokie
csrf: -642580457
Content-Type: application/json; charset=UTF-8

2020.04.19 18:35:34.336 4: [echomaster] [echodevice_SendCommand] [alarmvolume] START
2020.04.19 18:35:34.336 4: [echomaster] [echodevice_SendCommand] [alarmvolume] PushToCmdQueue SendURL =https://layla.amazon.de/api/device-notification-state?_=1587314134
2020.04.19 18:35:34.336 4: [echomaster] [echodevice_SendCommand] [alarmvolume] PushToCmdQueue SendData=
2020.04.19 18:35:34.337 4: [echomaster] [echodevice_SendCommand] [bluetoothstate] START
2020.04.19 18:35:34.338 4: [echomaster] [echodevice_SendCommand] [bluetoothstate] PushToCmdQueue SendURL =https://layla.amazon.de/api/bluetooth?cached=true&_=1587314134
2020.04.19 18:35:34.338 4: [echomaster] [echodevice_SendCommand] [bluetoothstate] PushToCmdQueue SendData=
2020.04.19 18:35:34.339 4: [echomaster] [echodevice_SendCommand] [getdnd] START
2020.04.19 18:35:34.339 4: [echomaster] [echodevice_SendCommand] [getdnd] PushToCmdQueue SendURL =https://layla.amazon.de/api/dnd/device-status-list?_=1587314134
2020.04.19 18:35:34.339 4: [echomaster] [echodevice_SendCommand] [getdnd] PushToCmdQueue SendData=
2020.04.19 18:35:34.340 4: [echomaster] [echodevice_SendCommand] [wakeword] START
2020.04.19 18:35:34.341 4: [echomaster] [echodevice_SendCommand] [wakeword] PushToCmdQueue SendURL =https://layla.amazon.de/api/wake-word?_=1587314134
2020.04.19 18:35:34.341 4: [echomaster] [echodevice_SendCommand] [wakeword] PushToCmdQueue SendData=
2020.04.19 18:35:34.341 4: [echomaster] [echodevice_SendCommand] [listitems_task] START
2020.04.19 18:35:34.342 4: [echomaster] [echodevice_SendCommand] [listitems_task] PushToCmdQueue SendURL =https://layla.amazon.de/api/todos?size=100&startTime=&endTime=&completed=false&type=TASK&deviceSerialNumber=&deviceType=&_=1587314134
2020.04.19 18:35:34.342 4: [echomaster] [echodevice_SendCommand] [listitems_task] PushToCmdQueue SendData=TASK
2020.04.19 18:35:34.343 4: [echomaster] [echodevice_SendCommand] [listitems_shopping] START
2020.04.19 18:35:34.343 4: [echomaster] [echodevice_SendCommand] [listitems_shopping] PushToCmdQueue SendURL =https://layla.amazon.de/api/todos?size=100&startTime=&endTime=&completed=false&type=SHOPPING_ITEM&deviceSerialNumber=&deviceType=&_=1587314134
2020.04.19 18:35:34.343 4: [echomaster] [echodevice_SendCommand] [listitems_shopping] PushToCmdQueue SendData=SHOPPING_ITEM
2020.04.19 18:35:34.344 4: [echomaster] [echodevice_SendCommand] [getdevicesettings] START
2020.04.19 18:35:34.344 4: [echomaster] [echodevice_SendCommand] [getdevicesettings] PushToCmdQueue SendURL =https://layla.amazon.de/api/device-preferences
2020.04.19 18:35:34.344 4: [echomaster] [echodevice_SendCommand] [getdevicesettings] PushToCmdQueue SendData=
2020.04.19 18:35:34.345 4: [echomaster] [echodevice_SendCommand] [getisonline] START
2020.04.19 18:35:34.345 4: [echomaster] [echodevice_SendCommand] [getisonline] PushToCmdQueue SendURL =https://layla.amazon.de/api/devices-v2/device?cached=true&_=1587314134
2020.04.19 18:35:34.345 4: [echomaster] [echodevice_SendCommand] [getisonline] PushToCmdQueue SendData=
2020.04.19 18:35:34.346 4: [echomaster] [echodevice_SendCommand] [devicesstate] START
2020.04.19 18:35:34.347 4: [echomaster] [echodevice_SendCommand] [devicesstate] PushToCmdQueue SendURL =https://layla.amazon.de/api/devices-v2/device?cached=true&_=1587314134
2020.04.19 18:35:34.347 4: [echomaster] [echodevice_SendCommand] [devicesstate] PushToCmdQueue SendData=
2020.04.19 18:35:34.347 4: [echomaster] [echodevice_SendCommand] [account] START
2020.04.19 18:35:34.348 4: [echomaster] [echodevice_SendCommand] [account] PushToCmdQueue SendURL =https://alexa-comms-mobile-service.amazon.com/accounts
2020.04.19 18:35:34.348 4: [echomaster] [echodevice_SendCommand] [account] PushToCmdQueue SendData=
2020.04.19 18:35:34.349 4: [echomaster] [echodevice_SendLoginCommand] [cookielogin6]
2020.04.19 18:35:34.350 5: HttpUtils url=https://layla.amazon.de/api/bootstrap
2020.04.19 18:35:34.350 4: IP: layla.amazon.de -> 99.84.157.56
2020.04.19 18:35:34.352 5: [echomaster] [echodevice_GetSettings] refresh voice command
2020.04.19 18:35:34.352 4: [echomaster] [echodevice_SendCommand] [activities] START
2020.04.19 18:35:34.352 4: [echomaster] [echodevice_SendCommand] [activities] PushToCmdQueue SendURL =https://layla.amazon.de/api/activities?startTime=&size=50&offset=1&_=1587314134
2020.04.19 18:35:34.352 4: [echomaster] [echodevice_SendCommand] [activities] PushToCmdQueue SendData=
2020.04.19 18:35:34.353 4: [echomaster] [echodevice_SendCommand] [getbehavior] START
2020.04.19 18:35:34.354 4: [echomaster] [echodevice_SendCommand] [getbehavior] PushToCmdQueue SendURL =https://layla.amazon.de/api/behaviors/automations?limit=100
2020.04.19 18:35:34.354 4: [echomaster] [echodevice_SendCommand] [getbehavior] PushToCmdQueue SendData=
2020.04.19 18:35:34.354 4: [echomaster] [echodevice_SendCommand] [getsettingstraffic] START
2020.04.19 18:35:34.355 4: [echomaster] [echodevice_SendCommand] [getsettingstraffic] PushToCmdQueue SendURL =https://layla.amazon.de/api/traffic/settings
2020.04.19 18:35:34.355 4: [echomaster] [echodevice_SendCommand] [getsettingstraffic] PushToCmdQueue SendData=
2020.04.19 18:35:34.356 4: [echomaster] [echodevice_GetSettings] Timer INTERVAL = 60
2020.04.19 18:35:34.380 4: BlockingCall (Nina_Run): created child (16938), uses telnetForBlockingFn_1586790614 to connect back
2020.04.19 18:35:34.422 4: Connection accepted from telnetForBlockingFn_1586790614_127.0.0.1_40506
2020.04.19 18:35:34.426 5: Cmd: >{BlockingRegisterTelnet($cl,247973)}<
2020.04.19 18:35:35.424 5: HttpUtils request header:
GET /api/bootstrap HTTP/1.1
Host: layla.amazon.de
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: Close
Cookie: meinCookie
bzw. warum der request eine s später kommt ?

Und warum die freeze-Dauer so gar nicht passt frag ich mal Oli

Die Funktion "get_settings" kann eigentlich keinen Freeze verursachen. Hier werden nur ganz normal Dinge abgearbeitet. Alle Anfragen an Amazon werden in eine Queue gelegt. Diese Queue wird dann nonblocking ausgeführt.

Mich würde mal interessieren auf was für einer Hardware Ihr den jeweiligen FHEM Server betreibt?

[cs-online]

die Dreambox war aber auch immer im Spiel. Vielleicht einen separaten Thread eröffnen und das freeze-log posten ? 

Das stimmt, ist mir in der Tat noch gar nicht aufgefallen und es ist auch tatsächlich immer die Dreambox im Schlafzimmer drin, wenn die Freezezeit hoch ist. Ich hatte erst gedacht, das könnte vielleicht daran liegen, dass die komplett ausgeschaltet war und die Vermutung dabei, dass, wenn die nicht antwortet, zu der Freezezeit führen könnte. Aber nun läuft die schon den ganzen Tag, genau wie die im Wohnzimmer (gleiches Modell, gleiches Flash) und die regelmäßigen Freezes bleiben wie vorher. Um aber ganz sicher zu sein, werde ich die mal aus der Config nehmen, dann schauen wir mal weiter...

PS: Ich habe FHEM auf einem Raspi 4, 4GB mit Buster

Grüße

Christian

[KölnSolar]

Hi Michael,

Mich würde mal interessieren auf was für einer Hardware Ihr den jeweiligen FHEM Server betreibt?

bei mir ist es ein gelangweilter RPi3. Sonstige Freezes > 0,3 s habe ich nicht(selten).

Vielleicht ist das ja auch gar kein freeze. Ich hab Oli ja schon dazu angeregt sich das mal anzusehen.

Was ist das denn, dass nach dem

Code Auswählen Erweitern

2020.04.19 18:35:34.356 4: [echomaster] [echodevice_GetSettings] Timer INTERVAL = 60eine Sek. später nochmal ein httputils-Zugriff

Code Auswählen Erweitern

2020.04.19 18:35:35.424 5: HttpUtils request header:
GET /api/bootstrap HTTP/1.1
Host: layla.amazon.de
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: Close
Cookie: meinCookie erfolgt ? Ist die Sek. Absicht oder macht da nur das nonblockingget noch etwas und echodevice ist schon längst beendet  ? Der Zeitunterschied ist immer so 0,7-0,9 Sek.

Grüße Markus

[michael.winkler]

Hi Michael,bei mir ist es ein gelangweilter RPi3. Sonstige Freezes > 0,3 s habe ich nicht(selten).

Vielleicht ist das ja auch gar kein freeze. Ich hab Oli ja schon dazu angeregt sich das mal anzusehen.

Was ist das denn, dass nach dem

Code Auswählen Erweitern

2020.04.19 18:35:34.356 4: [echomaster] [echodevice_GetSettings] Timer INTERVAL = 60eine Sek. später nochmal ein httputils-Zugriff

Code Auswählen Erweitern

2020.04.19 18:35:35.424 5: HttpUtils request header:
GET /api/bootstrap HTTP/1.1
Host: layla.amazon.de
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: Close
Cookie: meinCookie erfolgt ? Ist die Sek. Absicht oder macht da nur das nonblockingget noch etwas und echodevice ist schon längst beendet  ? Der Zeitunterschied ist immer so 0,7-0,9 Sek.

Grüße Markus

Hmm naja, was ist ein gelangweilter RPi3? Für mich ist ein RPixx nicht wirklich geeignet für eine Haussteuerung. Wer weiß schon was hier ein eventueller Flaschenhals ist. Schon das LOG schrieben auf die SD Karte könnte hier ein Faktor sein.

[Sascha_F]

Hi zusammen,

vielleicht hilft es - vielleicht nicht 

Bei mir läuft FHEM auf einem RPI4 (und vorher auf einem RPI3) mit Echodevice völlig problemlos. Ich denke, ich habe FHEM auch nicht mit zu wenig Last am laufen: "Server started with 399 defined entities" mit den diversesten Modulen. SD ist ne SanDisk Extreme (A1 C10 V30 UHS-I U3) mit 32 GB.

Einzige Ausnahme (habe ich irgendwo auf den vorherigen Seiten geschrieben): Es gab einen Zeitraum, an welchem die Echos nicht richtig wollten. Auf einigen "Down"-Seiten stand, dass die Amazon-Server scheinbar Probleme haben. Auch Anfragen an die Echo-Devices wurde immer wieder mal mit "Ich habe leider Probleme..." beantwortet. Mein Internet selbst lief durchgehend - ggf. gab es aber vielleicht größere Latenzen --> das war in der Anfangszeit der HomeOffice-Corona-Phase. Hier hatte ich auch massive Freezes.

DBLog am Laufen? Vielleicht viel zu viele Datensätze in der Datenbank? Da hatte ich mal nicht aufgepasst damals und schwupps waren da 35 Mio Datensätze drin... Da ging es auch alles etwas "schwerer"

Viele Grüße
Sascha

[KölnSolar]

Hmm naja, was ist ein gelangweilter RPi3?

Sachlich ausgedrückt ein RPi3, der in der Regel unter 10% CPU-Last hat. Und so gut wie keine freezes > 0,3 Sek. hat auch kaum jemand. Ich aber leider  mit dem echodevice. Nicht mit anderen devices.

Für mich ist ein RPixx nicht wirklich geeignet für eine Haussteuerung.

Die Meinung darfst Du haben. Die Praxis ist, dass der überwiegende User-Anteil FHEM auf einem Rpi fährt. Manche sogar auf einem Rpi Zero.

Wer weiß schon was hier ein eventueller Flaschenhals ist. Schon das LOG schrieben auf die SD Karte könnte hier ein Faktor sein.

Sorry, aber das ist jetzt ziemlicher Nonsens. Ein allgemeines Problem lässt sich ja eindeutig ausschließen. Ich wiederhol dann mal mein ungekürztes Log bzgl. freezemon

Code Auswählen Erweitern

2020.04.17 18:58:55 3: [Freezemon] freezedetect: possible freeze starting at 18:58:55, delay is 0.62 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_WWL)
2020.04.17 18:59:55 3: [Freezemon] freezedetect: possible freeze starting at 18:59:55, delay is 0.391 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(RPi_OW_VL) tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-statistics_PeriodChange(stat_wr) tmr-statistics_PeriodChange(stat_sl)
2020.04.17 19:02:55 3: [Freezemon] freezedetect: possible freeze starting at 19:02:55, delay is 0.948 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina)
2020.04.18 11:01:29 3: [Freezemon] freezedetect: possible freeze starting at 11:01:29, delay is 0.892 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius)
2020.04.18 21:04:49 3: [Freezemon] freezedetect: possible freeze starting at 21:04:49, delay is 0.323 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina)
2020.04.19 18:18:34 3: [Freezemon] freezedetect: possible freeze starting at 18:18:34, delay is 0.485 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius)
2020.04.19 18:35:35 3: [Freezemon] freezedetect: possible freeze starting at 18:35:35, delay is 0.474 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_KS)

Wäre prima, wenn Du mir meine Fragen beantworten würdest. Vielleicht kommen wir ja sogar zu der Erkenntnis, dass sich freezemon nur "fälschlicherweise" meldet

Was ist das denn, dass nach dem
Code: [Auswählen]

2020.04.19 18:35:34.356 4: [echomaster] [echodevice_GetSettings] Timer INTERVAL = 60

eine Sek. später nochmal ein httputils-Zugriff
Code: [Auswählen]

2020.04.19 18:35:35.424 5: HttpUtils request header:
GET /api/bootstrap HTTP/1.1
Host: layla.amazon.de
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: Close
Cookie: meinCookie

erfolgt ? Ist die Sek. Absicht oder macht da nur das nonblockingget noch etwas und echodevice ist schon längst beendet  ? Der Zeitunterschied ist immer so 0,7-0,9 Sek.

[michael.winkler]

Sachlich ausgedrückt ein RPi3, der in der Regel unter 10% CPU-Last hat. Und so gut wie keine freezes > 0,3 Sek. hat auch kaum jemand. Ich aber leider  mit dem echodevice. Nicht mit anderen devices. Die Meinung darfst Du haben. Die Praxis ist, dass der überwiegende User-Anteil FHEM auf einem Rpi fährt. Manche sogar auf einem Rpi Zero.Sorry, aber das ist jetzt ziemlicher Nonsens. Ein allgemeines Problem lässt sich ja eindeutig ausschließen. Ich wiederhol dann mal mein ungekürztes Log bzgl. freezemon

Code Auswählen Erweitern

2020.04.17 18:58:55 3: [Freezemon] freezedetect: possible freeze starting at 18:58:55, delay is 0.62 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_WWL)
2020.04.17 18:59:55 3: [Freezemon] freezedetect: possible freeze starting at 18:59:55, delay is 0.391 possibly caused by: tmr-GPIO4_DeviceUpdateLoop(RPi_OW_VL) tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-statistics_PeriodChange(stat_wr) tmr-statistics_PeriodChange(stat_sl)
2020.04.17 19:02:55 3: [Freezemon] freezedetect: possible freeze starting at 19:02:55, delay is 0.948 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina)
2020.04.18 11:01:29 3: [Freezemon] freezedetect: possible freeze starting at 11:01:29, delay is 0.892 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius)
2020.04.18 21:04:49 3: [Freezemon] freezedetect: possible freeze starting at 21:04:49, delay is 0.323 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina)
2020.04.19 18:18:34 3: [Freezemon] freezedetect: possible freeze starting at 18:18:34, delay is 0.485 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius)
2020.04.19 18:35:35 3: [Freezemon] freezedetect: possible freeze starting at 18:35:35, delay is 0.474 possibly caused by: tmr-echodevice_GetSettings(echomaster) tmr-Nina_Start(myNina) tmr-USBWRF_GetUpdate(Fronius) tmr-GPIO4_DeviceUpdateLoop(RPi_OW_KS)

Wäre prima, wenn Du mir meine Fragen beantworten würdest. Vielleicht kommen wir ja sogar zu der Erkenntnis, dass sich freezemon nur "fälschlicherweise" meldet

Speziell zu dem Logeintrag habe ich tatsächlich noch etwas gefunden. Hier schein noch kein Keepalive aktiviert gewesen zu sein. Ab morgen wird eine Version verteilt, in welche Keepalie dort auch aktiviert ist.

Bezüglich RPix magst Du ja recht haben, dass sehr viele Benutzer sowas einsetzen. Möglich das es sogar welche gibt die einen Zero einsetzen. Hier aber über Performance zu sprechen, fällt mir sehr schwer! Eine SD Karte ist kein Vergleich zu einer SSD Festplate, und WLAN auch keiner zu einer Gigabit Anbindung.

Deswegen sind 0,5 Sekunden, unter Umständen, ganz normal.

[KölnSolar]

Speziell zu dem Logeintrag habe ich tatsächlich noch etwas gefunden. Hier schein noch kein Keepalive aktiviert gewesen zu sein. Ab morgen wird eine Version verteilt, in welche Keepalie dort auch aktiviert ist.

Danke. Rennt schon produktiv bei mir.

[cs-online]

ähm, mein RPI4 hat gewöhnlich eine Last um die 7-8%, bei ca. 500 Entities beim Start, da hängt alles dran, Heizung, Rolläden, Alexa, 5 Echos bzw. Echo-Dots, Sonoffs, Sommerpoolsteuerung, Aussenwhirlpoolsteuerung, Licht und so weiter. Selbst der RPI2B, der da vorher dran war, lag immer unter 15%. Alle Logs ausser FHEM-Log sind auf DB-Log auf nem NAS am laufen. In meinem Gewächhaus läuft FHEM (für FHEM2FHEM) auf nem RPIzeroW, der fragt im Prinzip nur 4 MiFloras ab und einen Helligkeitssensor. Last unter 10%. Ich akzeptiere ja auch Freezes im Bereich 1-2s, das ist bei der Menge, was dort läuft "normal" und das stellt für mich kein Problem dar, aber mich nerven halt Dinge, die ich nicht verstehe, z.B. warum regelmäßig eben Peaks von 5-6s entstehen. Die Dreambox kann es nun nicht mehr sein, die config zur Dreambox wird nicht mehr geladen. Bleibt nach derzeitigem Erkenntnisstand nur irgendwas mit dem Echo-Modul, evtl. ist es ja auch auf Amazon-Seite, dass da regelmäßig die Antworten verzögern ? Ich hätt es nur gern verstanden und möglichst dann auch abgestellt.

Grüße

Christian

[michael.winkler]

ähm, mein RPI4 hat gewöhnlich eine Last um die 7-8%, bei ca. 500 Entities beim Start, da hängt alles dran, Heizung, Rolläden, Alexa, 5 Echos bzw. Echo-Dots, Sonoffs, Sommerpoolsteuerung, Aussenwhirlpoolsteuerung, Licht und so weiter. Selbst der RPI2B, der da vorher dran war, lag immer unter 15%. Alle Logs ausser FHEM-Log sind auf DB-Log auf nem NAS am laufen. In meinem Gewächhaus läuft FHEM (für FHEM2FHEM) auf nem RPIzeroW, der fragt im Prinzip nur 4 MiFloras ab und einen Helligkeitssensor. Last unter 10%. Ich akzeptiere ja auch Freezes im Bereich 1-2s, das ist bei der Menge, was dort läuft "normal" und das stellt für mich kein Problem dar, aber mich nerven halt Dinge, die ich nicht verstehe, z.B. warum regelmäßig eben Peaks von 5-6s entstehen. Die Dreambox kann es nun nicht mehr sein, die config zur Dreambox wird nicht mehr geladen. Bleibt nach derzeitigem Erkenntnisstand nur irgendwas mit dem Echo-Modul, evtl. ist es ja auch auf Amazon-Seite, dass da regelmäßig die Antworten verzögern ? Ich hätt es nur gern verstanden und möglichst dann auch abgestellt.

Grüße

Christian

Mache morgen mal ein Update vom Modul. Wenn es dann nicht besser wird müssen wir es genauer analysieren. Eventuell kann der Kollege vom Freeze-Modul hier weiterhelfen.

[cs-online]

Hallo Michael,

danke dir, habe das Update gerade gezogen, ich schau mal, wie sich das entwickelt und melde mich. Danke dir für die Arbeit !!!

Grüße

Christian

[cs-online]

...das war es leider auch nicht, hier der letzte Freezewert nach dem Update:

Code Auswählen Erweitern

2020-04-21_20:54:15 myfreezemon s:20:54:10 e:20:54:15 f:5.267 d:tmr-echodevice_LoginStart(Echos)
2020-04-21_20:54:15 myfreezemon freezeTime: 5.267
2020-04-21_20:54:15 myfreezemon fcDay: 27
2020-04-21_20:54:15 myfreezemon ftDay: 95.289
2020-04-21_20:54:15 myfreezemon freezeDevice: tmr-echodevice_LoginStart(Echos)

Echos ist bei mir übrigens das Account Device, falls das was hilft....

[KölnSolar]

Hi Christian,
mach doch

Vielleicht einen separaten Thread eröffnen und das freeze-log posten ?

Möglicherweise beißt sich ja was anderes(auch wenn es die dreambox schon mal nicht ist  )
Grüße Markus

[cs-online]

Hallo Markus,

in welchem Forum würdest du da vorschlagen ?

Grüsse Christian

PS: Ich habe jetzt mal testweise eine ältere Fassung des Moduls zurückgespielt und lass das mal ein paar Stunden laufen um auszuschließen, dass es an was anderem liegt. Melde mich später dann mit dem Ergebnis.