59_Weather, DarkSky und OpenWeatherMap API Bugfixes

[CoolTux]

Nur das ganze Modul stillgelegt, aber ich gehe davon aus, dass es das ist (und warum evtl niemand anderes das Problem hat).

DarkSky ist bei mir aktuell bis zT auf die Minute. Die stündlichen Vorhersagen (besonders was Wind und Regen angeht) helfen deutlich in einem Bio-Landwirtschaftlichen Betrieb. Das zur Erklärung warum mir das hourly so wichtig ist.

Aber: wie kann Weather fhem, resp. andere Verbindungen zu fhem blockieren? Egal wie lange es braucht um Daten zu holen ...

In diesem Fall wird es nicht das holen der Daten sein, das ist definitiv nonBlocking sondern das verarbeiten der Daten. Bei Gelegenheit werde ich versuchen das irgendwie nonBlocking zu setzen.

[holle75]

...

Bei Gelegenheit werde ich versuchen das irgendwie nonBlocking zu setzen.

Danke dir

[herrmannj]

Tschuldigung, habe gerade mitgelesen. Ich halte es offen gestanden für eher weniger wahrscheinlich das die Verarbeitung der Daten hier nennenswerte Verzögerungen hervorruft.

Ich habe das versucht im thread zu finden, haber es aber übersehen. Frage @holle: über welche "Verzögerung" reden wir denn eigentlich? So in Sekunden. Etwa. Mit welcher Hardware basis. (raspi 1..4, oder ...)

[holle75]

.... raspi 3b mit Buster, fhem aktuell.

Ich weiß nicht wirklich wie groß die Verzögerung ist. Sie muß mindestens ein wenig länger als das KeepAlive des Hm-Lan und der MQTT2 Devices sein.... bzw. nicht unbedingt wenn ich es mir recht überlege. fhem muß ja nur blockieren wenn die Message erwartet/gesendet wird?

Wie lange gewartet wird oder was genau der Mechanismus hinter diesen KeepAlives ist, weiß ich nicht.

fhem läuft auf einem Raspi3b der außer beim fhem-Neustart (ca 25% für 10 Sekunden) bei 1-4% CPU Last herumdümpelt. Auch wird die Systemauslastung kontinuierlich geloggt und da gibt es keine Auffälligkeiten.

Ja, ich könnte (und werde) mal die Anzahl der Vorhersagen reduzieren, aber generell scheint es ja ein Problem zu geben. Ich weiß nicht, ob ein solcher Workaround (falls es denn dann funktioniert) dann eine Problemlösung oder Problemherumnavigation ist.

[Beta-User]

@holle75: Schau' mal bitte bei der Gelegenheit nach, was da auf den ESP's so eingestellt ist. Evtl. wird da ziemlich traffic erzeugt, der dann das ganze Netzwerk lahm macht...
(So interpretiere ich jedenfalls das, was ich bisher zum Thema MQTT2-IO und v.a. shelly (? mit default-Einstellungen) gelesen habe).

Und ganz allgemein gibt es massenweise Threads zu WLAN und (un-) passenden Access-Points. Ist evtl. auch einen Blick wert...

[holle75]

Hallo Beta, hab mittlerweile (noch im Test) meine "eigenen" Nodemcu´s programmiert (keine ESP´s mehr) .... lausche auch die Konversationen zwischen den einzelnen Nodes/fhemServer mit und der Traffic ist miniminiminimal. Das Problem ist auch schon alt (HM-LAN disconnects) und wird jetzt über die Disconnects der MQTT2 Devices nur deutlicher.

[CoolTux]

Teste erstmal bitte das entfernen der Extension

[herrmannj]

.... raspi 3b mit Buster, fhem aktuell.

Ich weiß nicht wirklich wie groß die Verzögerung ist. Sie muß mindestens ein wenig länger als das KeepAlive des Hm-Lan und der MQTT2 Devices sein.... bzw. nicht unbedingt wenn ich es mir recht überlege. fhem muß ja nur blockieren wenn die Message erwartet/gesendet wird?

Wie lange gewartet wird oder was genau der Mechanismus hinter diesen KeepAlives ist, weiß ich nicht.

https://wiki.fhem.de/wiki/HM-CFG-LAN_LAN_Konfigurations-Adapter#KeepAlive
Der HMLAN hat einen Intervall von 30Sekunden mit 5 Sekunden Reserve. Ne, das mag ich nicht glauben Hier brauchts jetzt Datenlage und weniger Vermutungen

@cooltux, wie kann man die Verarbeitungszeit (59_Weather) messen? Im Zweifel sollten da doch einige Logeinträge helfen.

[CoolTux]

Ja das kann man in der Tat machen. Dann allerdings sowohl im API Modul als auch im Weather Modul. Im API Modul werden die Daten vom Weathermodul abgerufen. Im Weather Modul werden dann die Daten (Hash) durch eine Schleife gejagt und in Readings gesetzt.

[herrmannj]

Ja das kann man in der Tat machen. Dann allerdings sowohl im API Modul als auch im Weather Modul. Im API Modul werden die Daten vom Weathermodul abgerufen. Im Weather Modul werden dann die Daten (Hash) durch eine Schleife gejagt und in Readings gesetzt.

Das sollte doch passen. Das holen ist non-blocking. Da muss man bei der Interpretation aufpassen. Dort ist verstrichene Zeit ist ungleich Rechenzeit, da blockiert nichts.

Wichtiger ist sicher die Schleife, evtl noch $data nach JSON.

[holle75]

Teste erstmal bitte das entfernen der Extension

wird gemacht.

Wenn wir jetzt bei Timings sind, nur um es erwähnt zu haben: Ich jage die gefühlten 5000 Werte auch nochmal durch eine Funktion in myUtils und dann durch ein Logproxy in einen Plot. Allerdings geschieht das wohl nur, wenn ich den Plot aufrufe .... sollte also nichts mit dem Problem zu tun haben.

[herrmannj]

wird gemacht.

Wenn wir jetzt bei Timings sind, nur um es erwähnt zu haben: Ich jage die gefühlten 5000 Werte auch nochmal durch eine Funktion in myUtils und dann durch ein Logproxy in einen Plot. Allerdings geschieht das wohl nur, wenn ich den Plot aufrufe .... sollte also nichts mit dem Problem zu tun haben.

so, so

Na dann nimm die Funktion in myUtils doch mal testweise raus. Wie kommen die da rein ? notify? DOIF?

[holle75]

und noch zur Verdeutlichung, warum ich das Problem überhaupt wahrnehme (weil eine direkte Auswirkung hat es wenn nur ganz kurz und ab und zu. ZB Schalter drücken wenn HM-LAN gerade disconnected):

logauszug:

Code Auswählen Erweitern


2020.03.31 01:11:06 1: HMLAN_Parse: HM_LAN_FUNK new condition disconnected
2020.03.31 01:12:06 1: HMLAN_Parse: HM_LAN_FUNK new condition init
2020.03.31 01:12:06 1: 192.168.10.36:1000 reappeared (HM_LAN_FUNK)
2020.03.31 01:12:06 1: HMLAN_Parse: HM_LAN_FUNK new condition ok
2020.03.31 02:11:16 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.10.43_56368/MultiSensor1 left us (keepalive check)
2020.03.31 03:11:26 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.10.43_63222/MultiSensor1 left us (keepalive check)
2020.03.31 04:11:35 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.10.43_61739/MultiSensor1 left us (keepalive check)
2020.03.31 04:11:35 1: 192.168.10.36:1000 disconnected, waiting to reappear (HM_LAN_FUNK)
2020.03.31 04:11:35 1: HMLAN_Parse: HM_LAN_FUNK new condition disconnected
2020.03.31 04:12:35 1: HMLAN_Parse: HM_LAN_FUNK new condition init
---------------------------------
2020.03.31 06:11:53 1: 192.168.10.36:1000 disconnected, waiting to reappear (HM_LAN_FUNK)
2020.03.31 06:11:53 1: HMLAN_Parse: HM_LAN_FUNK new condition disconnected
2020.03.31 06:12:53 1: HMLAN_Parse: HM_LAN_FUNK new condition init
2020.03.31 06:12:53 1: 192.168.10.36:1000 reappeared (HM_LAN_FUNK)
------------------------------------------------------------------------------------
2020.03.31 08:12:12 1: 192.168.10.36:1000 disconnected, waiting to reappear (HM_LAN_FUNK)
2020.03.31 08:12:12 1: HMLAN_Parse: HM_LAN_FUNK new condition disconnected
2020.03.31 08:12:12 1: HMLAN_Parse: HM_LAN_FUNK new condition init
2020.03.31 08:12:12 1: 192.168.10.36:1000 reappeared (HM_LAN_FUNK)
2020.03.31 08:12:13 1: HMLAN_Parse: HM_LAN_FUNK new condition ok
------------------------------------------------------------------------------------------------
2020.03.31 14:13:04 3: MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.10.43_57871/MultiSensor1 left us (keepalive check)
2020.03.31 14:13:04 1: 192.168.10.36:1000 disconnected, waiting to reappear (HM_LAN_FUNK)
2020.03.31 14:13:04 1: HMLAN_Parse: HM_LAN_FUNK new condition disconnected
2020.03.31 14:13:04 1: HMLAN_Parse: HM_LAN_FUNK new condition init
2020.03.31 14:13:04 1: 192.168.10.36:1000 reappeared (HM_LAN_FUNK)
2020.03.31 14:13:04 1: HMLAN_Parse: HM_LAN_FUNK new condition ok


Das Intervall von weather ist eine Stunde und im Moment werden immer so gegen xx:12 Daten in die Readings geschrieben. Bedeutet aber auch, dass sich der ganze Holen/Wandeln Prozess doch ordentlich Zeit lässt.

Interessant auch, dass sich die Fehlermeldungen tatsächlich nur ab und zu und an bestimmten Tagen häufen oder überhaupt auftreten. Deswegen ging ich ursprünglich von der Tagesform der Internetverbindung aus.

[herrmannj]

so, so

Na dann nimm die Funktion in myUtils doch mal testweise raus. Wie kommen die da rein ? notify? DOIF?

[holle75]

Na dann nimm die Funktion in myUtils doch mal testweise raus.

Ich kann logproxy auch falsch verstehen, aber ich denke, die Funktion in myUtils wird nur bei Anzeige des Plots aufgerufen. Da gibts keine Probleme.
Aber klar, ich kann auch die mal rausnehmen

Wie kommen die da rein ? notify? DOIF?

Wie meinst du?