Hallo zusammen,
kann es sein, dass mit der aktuellen Version (2021-04-19 11:54:42 +0200 (Mon, 19 Apr 2021) irgendwas nicht rundläuft?
Mein FHEM (WEB) reagiert nicht mehr (ggf. komplett blocked?) - LOG-Einträge werden jedoch weiterhin erzeugt. Im Update waren nur die HttpUtils.pm und 98_ComfoAir.pm enthalten. Nachdem ich beide zurückgespielt habe, läuft es wieder einwandfrei. Auf HttpUtils.pm komme ich, da ich kein Device 98_ComfoAir.pm verwende...
Sofern irgendwelche detaillierten Infos benötigt werden, natürlich einfach nur eine kurze Info! :)
Viele Grüße
Sascha
Hallo
Kann mich da nur anschließen. Scheint was mit HttpUtils zu tun zu haben.
Im Log des Container sehen ich das alle http anfragen mit ein Time out enden und das Fhem komplett hängt.
VG Alex
2021.04.20 12:27:16.782 2: HUEBridge_0: http request failed: read from http://10.1.x.x:80 timed out
2021.04.20 12:27:16.783 2: HUEBridge_0: http request failed: read from http://10.1.x.x:80 timed out
2021.04.20 12:27:16.784 2: HUEBridge_0: http request failed: read from http://10.1.x.x:80 timed out
2021.04.20 12:27:16.785 2: HUEBridge_0: http request failed: read from http://10.1.x.x:80 timed out
2021.04.20 12:27:16.799 1: Timeout for FRITZBOX_API_Check_Run reached, terminated process 16820
2021.04.20 12:27:16.854 1: FRITZBOX MajestroBox: Readout_Aborted.1931 Error: Timeout when reading Fritz!Box data.
2021.04.20 12:27:16.994 2: HUEBridge_0: http request failed: write to http://10.1.x.x:80 timed out
2021.04.20 12:27:16.995 2: HUEBridge_0: http request failed: write to http://10.1.x.x:80 timed out
2021.04.20 12:27:16.996 2: HUEBridge_0: http request failed: read from http://10.1.x.x:80 timed out
2021.04.20 12:27:16.997 2: HUEBridge_0: http request failed: write to http://10.1.xx.xx:80 timed out
2021.04.20 12:27:16.998 2: HUEBridge_0: http request failed: write to http://10.1.xx.xx:80 timed out
2021.04.20 12:27:17.163 3: Netatmo_Acc: poll (ACCOUNT)
2021.04.20 12:27:17.166 2: HUEBridge_0: http request failed: write to http://10.1.xx.xx:80 timed out
2021.04.20 12:27:17.167 2: HUEBridge_0: http request failed: read from http://10.1.x.xx:80 timed out
2021.04.20 12:27:17.168 2: HUEBridge_0: http request failed: read from http://10.1.x.xx:80 timed out
2021.04.20 12:27:17.218 2: HUEBridge_0: http request failed: write to http://10.1.x.xx:80 timed out
Hab versucht gestern die HttpUtils.pm Variablen vor dem callback etwas aufzuraeumen (Forums-Thema-ID ist im SVN-Commit Kommentar hinterlegt), offensichtlich war ich zu mutig. Wenn ich eine Anleitung zum reproduzieren kriege, dann versuche ich es zu fixen, sonst drehe ich die Aenderung zurueck.
Hallo Rudi,
ich bin gern bereit Dir zuzuliefern, was Du benötigst - falls Du da etwas benennen kannst. Allerdings braucht man ja einen Aufsetzpunkt, um es reproduzieren zu können...
Was mir im Log aufgefallen ist:
--> Verbindung zu HomeBridge kann nicht hergestellt werden (läuft local) :
2021.04.20 10:38:36 2: HomeBridge: http request (http://192.168.1.10:8581/api/auth/login) failed: write to http://192.168.1.10:8581 timed out
Das ist 39_homebridge.pm (Testversionen, nicht über SVN) von "justme1968" aus dem thread: https://forum.fhem.de/index.php/topic,108715.0.html
--> Presence (lan-ping):
2021.04.20 10:38:36 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 3415
--> SYSMON (hier nur Log-Einträge, während die neue .pm "aktiv" war):
Timeout for SYSMON_blockingCall reached, terminated process 4379
Viele Grüße
Sascha
Nein, nicht Logs, sondern eine Anleitung zum Nachstellen brauche ich.
Am besten ohne "Zeugs" wie homebridge, was ich erst noch einrichten oder gar kaufen muss.
Kann leider nicht testen, aber funktioniert Weather mit einem API Key denn?
Ich kann ja leider so auch nicht eingrenzen woran es lag. Hatte gedacht, dass es ggf. schon mit einem PRESENCE-Device reproduzierbar ist, da die (mit Variante lan-ping) nur noch Fehler geliefert haben.
Mit den Log-Auszügen wollte ich nur zeigen, was bei mir "anders lief als sonst" - also potentielle Kandidaten zum testen - HomeBridge natürlich außen vor, daher hatte ich extra geschrieben, dass die .pm noch Teststatus besitzt und nicht im FHEM-Update enthalten
= out-of-scope ist.
Ich weiß leider nicht, wie ich sonst produktiv weiter etwas dazu beitragen kann --> ansonsten muss ich von euch an die Hand genommen werden --> also ganz einfach gesagt: Ich stehe bereit, bin aber planlos ;)
Edit: @CoolTux: Weather habe ich bei mir nicht im Einsatz. Testen kann ich vermutlich auch eher schlecht, denn sobald ich die HttpUtils.pm drin habe, ist WEB bei mit lahmgelegt...
Hast Du denn das Weather Device am Start und damit auch Probleme? Schau mal bitte. Bin leider noch on Tour
Zitat von: CoolTux am 20 April 2021, 16:28:20
Hast Du denn das Weather Device am Start und damit auch Probleme? Schau mal bitte. Bin leider noch on Tour
Da haben wir uns beide gerade überschnitten --> nee, Weather habe ich nicht im Einsatz. Könnte es natürlich hinzufügen, aber sobald die neue HttpUtils.pm drin ist, lädt WEB nicht mehr...
Zitat von: CoolTux am 20 April 2021, 16:03:43
Kann leider nicht testen, aber funktioniert Weather mit einem API Key denn?
Funktioniert bei mir problemlos (DarkSkyApi)
Und auch das Web-Frontend von FHEM ist hier problemlos erreichbar, trotz aktuellester HttpUtils.pm
Hi zusammen,
so, Homeoffice beendet = jetzt wieder "mehr dabei".
Im Log nach dem ersten Update heute früh konnte ich nichts entdecken. Das HomeBride-Device lief die ganze Zeit unauffällig bei mir - allerdings erst seit grob 4-5 Tagen glaube ich. Als ich es eben über FHEMWEB aufgerufen habe, ist mir FHEM abgeschmiert (mit der älteren HttpUtils).
Letzter Eintrag im Log: Undefined subroutine &main::homebridge_killLogWatcher called at ./FHEM/39_homebridge.pm line 590. [vielleicht Zufall, vielleicht nicht...]
Ich habe das Device jetzt in der cfg auskommentiert und FHEM-Update erneut durchgeführt. FHEMWEB braucht extrem lange für einen Raumwechsel, hat es aber so nach ca. 1-2 Minuten geschafft. Die Presence-Devices (mit lan-ping) stehen im state timeout - eines hat gerade doch noch auf "present" gewechselt. Im Log steht passend dazu "Timeout: process terminated".
Wechsel auf einen anderen Raum = dauert jetzt noch länger.
- Pushover-Device wechselt zwischen disconnected und connected
- Echodevice wechselt auch, steht mittlerweile aber auf connected but loginerror --> ist vermutlich durch zu viele Anmeldeversuche "hin".
Vielleicht hilfts - wenn nicht, einfach ignorieren ;) Ich gehe jetzt erstmal wieder auf die alte Version zurück, damit es bei mir weiterläuft.
Viele Grüße
Sascha
Hallo,
mit FRITZBOX, httpmod und OpenWeatherMap und weiteren ohne Probleme.
Grüße Jörg
Ich habe vor dem Einchecken auch etliche Tests gemacht, ganz kaputt ist das Modul nicht.
Ich habe es aber trotzdem zurueckgesetzt, bevor hier das Problem weitere Kreise zieht.
Kann jemand bitte die angehaengte Version testen, ob damit die Probleme auftreten?
Mache ich sofort - Feedback dann hier als Edit folgt
Bitte kein Edit, dafuer muss ich pollen.
Server war gem. Log um 18:13 wieder gestartet. Browser hat die Oberfläche erst um 18:19:25 laden/anzeigen können. Raumwechsel dauert auch noch sehr lange (zwischen 3-5 Minuten).
In meinem Fall ist das Verhalten (zumindest von dem, was ich sehen kann) unverändert zur ursprünglichen Update-Version.
Presence, Echodevice, ... sind jetzt auch wieder im Log mit "timeout" dann wieder connected und wieder connection lost
Das ist sehr merkwuerdig, ich war ueberzeugt, dass die Aenderung in der hier angehaengten Version nur kosmetisch ist.
Was ist die Nummer der funktionierenden Version?
Bei mir ist jetzt aktuell wieder die 24215 2021-04-11 drin, mit der alles läuft
ZitatBei mir ist jetzt aktuell wieder die 24215 2021-04-11 drin, mit der alles läuft
Wenn ich die Unterschiede zu dem hier angehaengten Modul betrachte, dann wundert mich das sehr.
Und wenn ich was zum Nachstellen kriege, dann wuerde ich mich das freuen.
Mir ist es nicht gelungen in meinem Testsystem ein Problem nachzustellen, weder mit der aktuellen SVN Version noch mit der oben angehängten...
Hi,
ich bin -wie gesagt- selbstverständlich gern bereit, Dinge zuzuliefern --> allerdings muss ich dazu wissen, was/wie/wo benötigt wird, falls das in irgendeiner Form helfen kann!
Oder was ich wie/wo tun oder einstellen soll, um aus irgendwelchen Logs, etc. Infos rausziehen kann, was in der Zeit passiert, in welcher FHEM bei mir quasi "steht"...
Viele Grüße
Sascha
Ich haette gerne eine Bestaetigung, dass mit dem hier im Forum angehaengten HttpUtils.pm Probleme gibt, am besten mit ein verbose 5 FHEM log vom Start.
Hi, bin dran - gestern war ich leider out-of-order.
Gibt's eigentlich keine Chance, Dir über das Forum das Log als Anlage einer PM oder Mail zu schicken?
Weiss nicht, meine Email-Adresse sollte aber an ziemlich vielen Stellen hinterlegt sein, z.Bsp. im Impressum.
Ja, manchmal kann es so einfach sein. Hatte nur bei PM und "per Mail" geschaut - Mail ist gerade raus.
Ich habe jetzt die 7MB durchgekaemmt, bin nicht sicher, ob ich nichts uebersehen habe.
Ich sehe zwei Durchlaeufe, der Erste durch Shutdown beendet, der Zweite vmtl. aufgehaengt.
Der Erste startet 330 HttpUtils Aufrufe, der Zweite 109. Womoeglich mehr, da ja einige Geraete mit eigenen verbose < 4 laufen.
Es gibt immer wieder Faelle (12 + 9), wo das eingeplante Timeout nicht reicht, weil FHEM dazwischen blockiert wurde (extending ... timeout)
Teilweise sind 40 ausstehende HttpUtils Requests zu beobachten, leider wird im Log das blocking noch nicht gekennzeichnet. Das habe ich jetzt geaendert.
Abgesehen davon, dass das ein stark belastetes System ist (was keine Begruendung fuer das Aufhaengen sein darf), faellt mir nichts auf.
Bist Du 100% sicher, dass im zweiten Lauf die HttpUtils.pm Datei aus meinem Forums-Anhang hier genommen wurde?
Die HttpUtils-Version des funktionierenden Laufs wuerde ich auch gerne wissen.
Wie ist die CPU-Auslatung im Aufhaenge-Fall?
Kannst Du die "strace -tt -p <FHEM-PID>" Ausgabe (auch nur beim aktiven Haenger) hier anhaengen? Hochstens 100 Zeilen sollten reichen.
Hi, ja, das war schon nicht wenig im Log...
Die hier angehängte HttpUtils.pm hatte ich extra direkt vorher noch einmal heruntergeladen, um nicht mit verschiedenen Versionen durcheinander zu kommen.
Version bei mir im (problemlosen) Einsatz: # $Id: HttpUtils.pm 24215 2021-04-11 09:07:25Z rudolfkoenig $
Version für Trace: # $Id: HttpUtils.pm 24280 2021-04-19 09:54:42Z rudolfkoenig $
Ich muss sagen, dass ich Richtung Trace/Debug komplett blank bin und daher nicht sicher weiß, ob ich den richtigen Ausschnitt nehmen würde. Ich füge daher doch zur Sicherheit (wieder) eine größere Datei bei. Der Trace lief knapp 8 Minuten - FHEMWEB konnte bis zum Ende des Trace nicht aufgerufen werden.
Wenn Du weitere oder andere Dinge benötigst, sag einfach Bescheid.
Viele Grüße
Sascha
Hallo und guten Morgen zusammen,
kurzes Update:
Hatte mir das regelmäßige Update die letzten Tage verkniffen, es heute aber durchgeführt, da einiges im Update vorhanden war. Mit dem Update wurde Version
# $Id: HttpUtils.pm 24338 2021-04-26 19:38:26Z rudolfkoenig $
eingespielt. Gedanklich war ich schon beim zurückspielen der 24215 --> FHEM hängt mit der 24338 aber nicht mehr.
Viele Grüße
Sascha
Das waere auch ein Wunder, da ich meine Aenderungen wegen deiner Fehlermeldung komplett zurueckgedreht habe.
Auch wenn ich die Probleme nicht erklaeren kann.
Ach ok, ich wusste nicht, ob Du komplett zurückgedreht hattest oder nur Teile.
Ich habe auch gerade gesehen, dass ich leider übersehen hatte, dass Du auch nach der CPU-Auslastung gefragt hattest . Sofern noch relevant bzw. interessant, kann ich die Version aus dem Forum-Beitrag hier natürlich noch mal schnell übernehmen. Gib mit einfach einen kurzen Ping.
Ja, die CPU Auslastung waere wichtig.
Hab dein strace Log irgendwie uebersehen.
Von hinten betrachtet:
- es wird ueber FD 39 mit einem Rechner im cloud (layla.amazon.de) verschluesselt kommuniziert (lesen/schreiben), und danach exklusiv von diesem Rechner auf Daten gewartet, mit 10s timeout. Keine Ahnung, wo das passiert, ich vermute im SSL Bibliothek. Sollte nicht fuer dein Lockup verantwortlich sein, da es nie mit timeout zurueckkommt (das exklusive Warten kommt oefters vor).
- light_light_dim_00.svg wird ein paar Dutzend-mal gelesen, ohne damit was zu machen. Das ist mehr als komisch (=> Bug), ist aber auch nicht fuer das Problem verantwortlich, da nach 0.25s wieder im globalen select gelandet sind. Wuesste gerne, wie man das ausloest.
- 0.2s vor dem Schluss wird noch mit einem CUL_HM via CUL Protokoll kommuniziert (wenn ich mich nicht irre), scheint also alles ok zu sein.
Laut strace war das Programm zum Zeitpunkt des Abbruchs im Kernel (via _newselect), d.h. es darf keine Endlosschleife sein:
eine Endlosschleife produziert im strace keine Ausgabe, da strace nur Systemcalls (Kommunikation mit dem Kernel) verzeichnet.
Bin ratlos.
Mit der HttpUtils aus dem Beitrag hier liegt die CPU-Last (RPi 4) zwischen 3 % und 28 % - nach Start von FHEM über sytemctl beginnend bei 28 % und dann abfallend. (HttpUtils hier aus dem Beitrag). Unterschied zum letzten Test ist, dass das gesamte System auf heutigem Update-Stand ist (natürlich mit Ausnahme der HttpUtils).
Aufgefallen ist mir (über das Homebride-Log), dass die Verbindung zum MQTT2-SERVER nach ca. 1 Minute (auto-retry) wieder hergestellt wird. (während WEB noch nicht wieder erreichbar ist). Einige Zeit danach stand WEB zur Verfügung und ich konnte Räume mit normaler Geschwindigkeit wechseln. Dabei ist mir aufgefallen, dass PUSHOVER und ECHODEVICE nicht connected waren. ECHODEVICE hat sich dann aber quasi sofort connected - nach Auswahl des PUSHOVER-Devices hing FHEM wieder einige Minuten. Anschließend war auch PUSHOVER connected. ECHODEVICE scheint scheint ggf. aber auch Probleme zu haben - konnte nur sehen, dass das devstateicon immer wieder mal für einen Sekundenbruchteil zwischen disconnected (o.ä.) und connected gewechselt hat.
Zwischendurch kann ich immer mal wieder mit normaler Geschwindigkeit zwischen Räumen/Devices wechseln, aber dann hängt es wieder.
Bei ECHODEVICE weiß ich, dass es eine Verbindung zu "https://layla.amazon.de" aufbaut. Ich kopiere hier mal die Blöcke aus dem FHEM-Log rein:
2021.05.01 14:18:38 3: [AlexaEchoDevice] [echodevice_SendCommand] [13] IGNORIERE Command=account Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=getnotifications Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=alarmvolume Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=bluetoothstate Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=getdnd Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=wakeword Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=listitems_task Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=listitems_shopping Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=getdevicesettings Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=getisonline Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=devices Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=namedListsIDs Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=devicesstate Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=account Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:19:42 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=getbehavior Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=getnotifications Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=alarmvolume Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=bluetoothstate Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=getdnd Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=wakeword Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=listitems_task Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=listitems_shopping Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=getdevicesettings Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=getisonline Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=devices Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=namedListsIDs Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=devicesstate Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=account Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=getbehavior Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_SendCommand] [16] IGNORIERE Command=getsettingstraffic Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_LostConnect] connection error = read from https://layla.amazon.de:443 timed out / set loginerror to 1
2021.05.01 14:22:03 3: [AlexaEchoDevice] [echodevice_setState] to connected but loginerror
2021.05.01 14:22:47 3: [AlexaEchoDevice] [echodevice_LostConnect] connection error = read from https://layla.amazon.de:443 timed out / set loginerror to 2
2021.05.01 14:23:39 3: [AlexaEchoDevice] [echodevice_LoginStart] connected but loginerror
2021.05.01 14:23:41 3: [AlexaEchoDevice] [echodevice_ParseAuth] reset loginerror from 2 to 0
2021.05.01 14:23:41 3: [AlexaEchoDevice] [echodevice_setState] to connected
2021.05.01 14:26:23 3: [AlexaEchoDevice] [echodevice_LostConnect] connection error = read from https://layla.amazon.de:443 timed out / set loginerror to 1
2021.05.01 14:26:23 3: [AlexaEchoDevice] [echodevice_setState] to connected but loginerror
2021.05.01 14:27:02 3: [AlexaEchoDevice] [echodevice_LoginStart] connected but loginerror
2021.05.01 14:27:02 3: [AlexaEchoDevice] [echodevice_ParseAuth] reset loginerror from 1 to 0
2021.05.01 14:27:02 3: [AlexaEchoDevice] [echodevice_setState] to connected
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=alarmvolume Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=bluetoothstate Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=getdnd Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=wakeword Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=listitems_task Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=listitems_shopping Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=getdevicesettings Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=getisonline Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=devices Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=namedListsIDs Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=devicesstate Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:30:39 3: [AlexaEchoDevice] [echodevice_SendCommand] [14] IGNORIERE Command=account Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=getnotifications Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=alarmvolume Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=bluetoothstate Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=getdnd Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=wakeword Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=listitems_task Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=listitems_shopping Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=getdevicesettings Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=getisonline Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=devices Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=namedListsIDs Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=devicesstate Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=account Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:32:12 3: [AlexaEchoDevice] [echodevice_SendCommand] [15] IGNORIERE Command=getbehavior Abfrage in CMD_Queue schon vorhanden!
2021.05.01 14:33:35 3: [AlexaEchoDevice] [echodevice_LostConnect] connection error = read from https://layla.amazon.de:443 timed out / set loginerror to 1
2021.05.01 14:33:35 3: [AlexaEchoDevice] [echodevice_setState] to connected but loginerror
2021.05.01 14:33:36 3: [AlexaEchoDevice] [echodevice_LoginStart] connected but loginerror
2021.05.01 14:33:38 3: [AlexaEchoDevice] [echodevice_ParseAuth] reset loginerror from 1 to 0
2021.05.01 14:33:38 3: [AlexaEchoDevice] [echodevice_setState] to connectedGeht alexa-fhem (über Connector) ggf. auch über layla? Wenn hier ein Problem bestehen würde, würde das aber sicher deutlich mehr Anwender betreffen, denke ich.
Im nächsten Step kann ich natürlich auch alle ECHODEVICE-Devices und PUSHOVER auskommentieren - komme nur leider heute nicht mehr dazu. Danach fällt mir allerdings auch nicht mehr viel ein.
Ich liste unten mal alle Module aus
fheminfo auf - es sind auch welche dabei, welche nicht im FHEM-Repository enthalten sind. Ich hoffe, ich habe wirklich alle erwischt (rot). Ich habe beim Folgetest alle Devices in der fhem.cfg auskommentiert, welche Module verwenden, die nicht im offiziellen FHEM-Repository enthalten sind:
- AptToDate
- AutoShuttersControl
- CUL
- CUL_HM
- DOIF
- DOIFtools
- DbLog
- DbRep
- ENIGMA2
- FB_CALLLIST
- FB_CALLMONITOR
- FHEMWEB
- FileLog
- HMCCU
- HMCCUDEV
- HMCCURPCPROC
- HMinfo
- HTTPMOD (für hm-firmware-update)
- HUEBridge
- HUEDevice
- HomeConnect
- HomeConnectConnection
- Hyperion
- HyperionNG
- IPCAM
- Installer
- KODI
- MQTT2_DEVICE
- MQTT2_SERVER
- NUKIBridge
- NUKIDevice
- NotifyAndroidTV
- PRESENCE (lan-ping)
- Pushover
- RESIDENTS
- ROOMMATE
- SVG
- SoftliqCloud
- Unifi
- UnifiClient
- UnifiProtect
- UnifiSwitch
- WifiLight
- alexa
- allowed
- autocreate
- cmdalias
- dummy
- echodevice
- eventTypes
- holiday
- homebridge
- homekitDevice
- km200
- notify
- npmjs
- readingsGroup
- structure
- telnet
- watchdog
- weblink
Sag Bescheid, wenn Dir noch etwas einfällt oder ich etwas tun kann - oder ggf. auch willst, dass ich aufhöre...
Wenn Du eine Konfiguration zum Nachstellen bauen kannst, dann werde ich versuchen selbst zu debuggen, bin aber unsicher, ob sowas einfach herstellen laesst. Sonst faellt mir nichts Sinnvolles mehr zum eingrenzen des Problems ein => Ich schlage vor es erstmal zu den Akten zu legen.