Netatmo Modul - 38_netatmo.pm (Support)

Begonnen von Markus M., 17 Mai 2016, 12:37:34

Vorheriges Thema - Nächstes Thema

KyleK

Ich denke auch das Problem ist nicht so sehr NetAtmo und deren API, sondern eher die Tatsache dass das FHEM-Modul in die Jahre gekommen ist und eine Generalüberholung benötigt.
Die Art und Weise wie aktuell die Authentifizierung bei Netatmo im Modul implementiert ist, ist so schon lange nicht mehr vorgesehen.

Jemand mit Erfahrung mit OAuth 2.0 könnte hier vielleicht wertvollen Input liefern.
FHEM on Futro S940
CUL868
7x MAX! Thermostat, 8x MAX! Fensterkontakte
Conbee II + deConz, TradFri Lampen, Osram Smart+ Steckdosen

flydd

Ich hoffe, ich konnte das "delayed update"-Problem lösen, nachdem es mich ebenfalls seit einem Jahr genervt hat. Für mich funktioniert es. Wer mag, kann es gerne ausprobieren. Es ist nun zudem ein Watchdog im Modul eingebaut. Dieser kann mittels
attr xxxx watchdog_delay_secs 3600
attr xxxx watchdog_interval   300
eingestellt werden (Check-Interval und maximal erlaubter Verzug für Updates)/Users/MT_1/38_netatmo.pm.zip

kwirk

bei mir funktioniert es. Dankeschön...

BroPi

Vielen Dank für die Überarbeitung.
10 Tage läuft es jetzt bei mir ohne Probleme. Ich hoffe, dass jetzt das das "delayed update"-Problem damit gelöst ist. Langzeittests müssen jetzt folgen. 

aski71

Bei mir funktioniert es auch, mit gelegentlichen Aussetzern.

Heute habe ich aber ein seltsames Phänomen:
Die Temperaturanzeige des Außenmoduls ist plötzlich falsch.

Zeigt 13,1 Grad statt 2,5. 🤔

Hatte jemand sowas schon mal?

tomcat.x

Das hatte ich nach Neustarts, dass ein alter Wert angezeigt wurde. Dauert einen Moment ....
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

tomcat.x

@flydd

Danke! Das funktioniert bei mir jetzt auch schon ein paar Wochen ohne Probleme.

Eine Frage noch zum Watchdog: Ich habe da nichts eingestellt, ziehen dann Defaults-Werte? Und was genau bewirkt der Watchdog, also was passiert wenn er auslöst?

Viele Grüße
Thomas
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

flydd

#1702
Schön, dass das Modul auch bei euch funktioniert. Für mich ist es die Rettung meiner in die Jahre gekommenen FHEM-Installation.

Der WD überprüft in der Default-Einstellung (ohne attr) alle 5 Minuten den Netatmo-Account. Wenn der Account länger als 1 Stunde nicht ,,ok" ist oder ein Gerät so lange auf ,,delayed update" festhängt, startet der WD ein Soft-Recover.

Soft-Recover heißt: Timer zurücksetzen, Tokens neu holen (API & App), interne Caches leeren und einen schnellen Re-Poll anstoßen – praktisch wie ein FHEM-Neustart, aber nur für Netatmo.

Im Normalfall wird aber einfach das App- und API-Token frühzeitig erneuert (ca. 10 Min vor Ablauf).

Außerdem warten Geräte mit IODev nicht ok jetzt kürzer (Back-off nur 5–15 Min statt stundenlang).

Bei ,,Operation is forbidden" stößt das Modul automatisch ein Re-Auth an und pollt kurz danach erneut.

Nebenbei wurde ein kleiner Bug in setRoomMode gefixt.