Mahlzeit!
Habe vor wenigen Tagen Home Connect eingerichtet und es sieht prinzipiell gut aus. Ärgerlicherweise treten leider vermehrt Freezes auf:
freezemon s:00:07:08 e:00:07:09 f:1.717 d:tmr-HomeConnect_Timer(EG.KU.Backofen)
freezemon s:03:12:39 e:03:12:43 f:4.697 d:cmd-set EG.KU.Geschirrspueler init(N/A) cmd-set EG.KU.Backofen init(N/A) cmd-set EG.KU.Kochfeld init(N/A) fn-SetFn(EG.KU.Geschirrspueler) fn-SetFn(EG.KU.Backofen) fn-SetFn(EG.KU.Kochfeld) tmr-HomeConnectConnection_RefreshTokenTimer(homeconnect)
Patrick
Ich hänge mich hier mal mit rein - wenn ich zum Test das Homeconnect-Device mit attr geschirrspueler disable 1 außer Gefecht setze, sind die 2-3 Sekunden langen, nervigen Freezes sofort weg ...
Hänge mich hier auch an, weil ich das Problem jetzt auch habe :-(
hat hier evtl schon jemand eine Lösung gefunden?
Cheers,
Pula
Zitat von: pula am 26 Mai 2020, 09:32:06
Hänge mich hier auch an, weil ich das Problem jetzt auch habe :-(
hat hier evtl schon jemand eine Lösung gefunden?
Nein, aber Module, die Freezes erzeugen, kommen erstmal auf eine separate FHEM-Instanz. So wie es aussieht, wird HomeConnect da für immer bleiben.
Patrick
Von unterwegs gesendet.
Danke für die rasche Antwort. Mit dem Gedanken hatte ich auch schon ein wenig gespielt. Werde mir mal fhem2fhem ansehen...
Cheers,
Pula
Würde es inzwischen nicht mehr mit FHEM2FHEM machen sondern mit MQTT_GENERIC_BRIDGE.
Von unterwegs gesendet.
Danke für den Tip. Das muss ich mir erst mal ansehen...
Cheers,
Pula
Hi!
Ein kleines Update, damit alle planen können. Der Bug auf Github wurde gerade mit Won't Fix geschlossen.
/Edit:
https://github.com/sw-home/FHEM-HomeConnect/issues/2
Patrick
Danke für den Bugreport + die Info darüber. Ich hatte letztens auch mal wieder so nen Freeze und danach ne offizielle WAF-Beschwerde der Klasse 3 (d.h. mit diversen Flüchen). Jetzt ist Homeconnect als Notbehelf erstmal komplett rausgeflogen.
Was ich hier in diesem Thema vermisse: konkrete Hinweise was verbessert werden muss. Oder idealerweise ein pull request. Irgendwie klingt es eher so als wäre ich hier der Dienstleister. Ich glaub open source funktioniert anders.
Zitat von: swhome am 04 Juni 2020, 09:33:57
Was ich hier in diesem Thema vermisse: konkrete Hinweise was verbessert werden muss. Oder idealerweise ein pull request. Irgendwie klingt es eher so als wäre ich hier der Dienstleister. Ich glaub open source funktioniert anders.
Also erstmal ein grosses Danke für das Modul.
Aber ich tu mich schwer, genauere Hinweise als "es kommt häufig zu Freezes" zu geben. Mir fällt nur auf, daß bei aktiviertem homeconnect in fhem häufig freezes auftreten (was sich dann bei mir zb so äußert, dass man einen Schalter betätigt und erst geraume Zeit später - bis zu 30 Sekunden - zb das entsprechende Licht angeht).
Leider sind wir nicht alle perl-Profis und tun uns (in diesem Fall als Anwender) schwer, genauere Hinweise zu geben.
Cheers,
Pula
Yup, problem ist dass ich auch kein Perl Profi bin, sondern lediglich eine Integration aller Devices in mein FHEM anstrebe. Perl ist ist hier ein unwillkommener Nebeneffekt. Und dass das ganze FHEM anscheinend in nur einem Thread abläuft ist mir ein Graus.
Meine Antwort zu den Freezes (die bei mir so selten auftreten dass es keine Quelle für Beschwerden ist) war: Laut den Angaben des Thread Erstellers passieren sie beim Token Refresh. Dieser Refresh geschieht aber nur einmal am Tag. Wie schlimm kann also die Belastung sein?
Nun gibt es bei anderen Anwendern anscheinend häufigere Beschwerden. Daher liegt nahe dass es noch eine zweite Ursache gibt - etwas das öfters abläuft. Dazu habe ich aber leider noch keine Anhaltspunkte.
Lieber swhome,
Zitat von: swhome am 04 Juni 2020, 09:33:57
Was ich hier in diesem Thema vermisse: konkrete Hinweise was verbessert werden muss.
das geht unmissverständlich aus der Github-Issue hervor. Sie enthält direkt im Startposting zwei Freezes, von denen nur einer RefreshTokenTimer ist. Die letzte Antwort in der Issue weist erneut auf den zweiten Freeze-Typ hin.
Angesichts des Umgangs mit der Issue kann man meines Erachtens nicht wirklich eine Mitarbeit erwarten. Das Schließen der Issue mit won't fix und dem Hinweis, der Fix sei ein zu hoher Aufwand, ist auch schwerlich als offene Aufforderung zur gemeinsamen Arbeit an dem Problem zu interpretieren.
Zitat von: swhome am 04 Juni 2020, 09:33:57
Oder idealerweise ein pull request. Irgendwie klingt es eher so als wäre ich hier der Dienstleister. Ich glaub open source funktioniert anders.
Ich gehe davon aus, dass Du freie Software meinst. Tatsächlich ist es dort eher unüblich, dass jemand ein Projekt initiiert, online stellt, Issues ignoriert und nach 6 Monaten Sendepause auf Github gleichzeitig das Problem für nichtig erklärt und sich nach 9 Monaten Sendepause in in diesem Forum beschwert, dass noch kein anderer die Software gefixt hat.
Nichts für ungut.
Patrick
Lieber Patrick, meine erste Idee einer Antwort war zu unflätig um sie hier einzustellen. Meine Empfehlung für Dich: drück den Fork Button in github und mach's besser. Oder lass mich fortan in Frieden.
Beste Grüße, Stefan