hi hab es gefunden Refresh Token musste erneuert werden 
danke nochmals für das tolle modul
Hallo,
ich bekomme in regelmäßigen Abständen im Log lila Einträge vom Modul:
21.11.2023, 12:57:44 | NetatmoSecurityCamera | GetPictureUrl4Filename: no url available
Das Kamerabild kann ich leider auch nicht mehr abrufen.
So richtig weiss ich leider nicht, wo ich schauen soll.
Kann hier jemand helfen?
Gruß
Christian
hmm, bedeutet, das er ein Bild / Video nicht mehr findet.
Je nachdem, ob du das lokal speicherst (in Netatmo-Konfig → FTP) oder nur direkt vom der Kamera holst sind die Gründe unterschiedlich
- Wenn du das von der Kamera holst könnte es bedeuten, das die Löschzeiten in Netatmo kürzer sind als im IPS konfiguriert
- Wenn du das per FTP douplizierst und das im IPS auch so eingerichtet hast, müssten die Löschintervalle in der Kamera-Instanz-Konfig überprüft werden.
welche modulversion hast du im Einsatz (Instanz-Konfig → Information) ?
Hallo,
ich habe die 1.35.1 (Beta) im Einsatz.
Habe jetzt alles neu eingerichtet, aber ich bin scheinbar zu blöd für diese Kamera.
Wenn ich in der Kamera-Instanz alles einrichte scheint der Webhhok falsch eingerichtet zu werden.
Zumindest bekomme ich ein „File not found“ in der „Bild“ Variablen.
Korrigiere ist den Webhook auf das Script „ProcessStreamURL“ bekomme ich folgende Meldung:
Warning: Undefined array key „InstanceID“ in /var/lib/symcon/scripts/processStreamURL.php on line 24 Warning: Undefined array key „_SERVER“ in /var/lib/symcon/scripts/processStreamURL.php on line 29 Fatal error: Uncaught TypeError: json_decode(): Argument #1 ($json) must be of type string, null given in /var/lib/symcon/scripts/processStreamURL.php:29 Stack trace: #0 /var/lib/symcon/scripts/processStreamURL.php(29): json_decode(NULL, true) #1 {main} thrown in /var/lib/symcon/scripts/processStreamURL.php on line 29
Ich denke in der Konfiguration stimmt etwas nicht, aber ich verstehe es leider nicht mehr.
Gruß
Christian
ok, am besten schickst du mir mal deine konfiguration dann kann ich mir das morgen anschauen.
unter welchen umständen kommt denn der dokumentierte script-fehler, rufst du das script von hand auf?
Habe gerade gesehen, wenn ich alles „einrichten lasse“ also den Webhhok, der eingerichtet wurde nicht anpasse kommt ja „File not found“ in der Variablen.
Im Log kommt dann folgende Meldung:
21.11.2023, 21:28:24 | NetatmoSecurityCamera | GetLiveVideoUrl: no url available
21.11.2023, 21:30:40 | NetatmoSecurityCamera | GetLiveSnapshotUrl: no url available
Und regelmäßig kommen die Meldungen
21.11.2023, 12:57:44 | NetatmoSecurityCamera | GetPictureUrl4Filename: no url available
Der Script Fehler kommt, wenn ich es von Hand aufrufe (ist klar) und wenn ich das Script im Webhook manuell eintrage.
Was genau brauchst Du von mir?
naja,
- die gesamte Konfiguration der IO- und Kamera-Instanz (gerne auch als PN)
- dann die Frage, welche Aufbewahrungsdauer in der Netatmo-App eingetragen ist - die Dauern im IPS geht ja aus (1) hervor
- die Variable(n) mit den HTML-code
- die Scripte, die konfiguriert sind (Die ersten Zeilen reichen üblicherweise, um zu ernennen, welches Script verwendet wurde
Das ein Feher kommt, wenn man ein Script aufruft, das von einer Instanz aufgerufen werden solle, ist klar, die Variable _IPS wird ja kontext-sensitiv gefüllt
weitere Fragen ergeben sich sicherlich
Die smarte Video-Türklingel wäre auch noch ein Security Produkt von Netatmo.
Ist eine Integration ins Modul geplant oder kann ich Daten liefern, um dies zu tun?
Können wir gerne in Angriff nehmen.
Schick mir doch zum Einstieg mal ein Debug als PN mit einen kompletten Statusabruf, weil du ja noch kein Device erstellen könntest, von der IO-Instanz.
Ich schaue es mir dann mal an. Bin mir nicht sicher, ob es eine Variante innerhalb des Kameramoduls wird oder was eigenes.
Hallo, wieder einmal zickt meine Camera’s wieder
hab das Modul erneut installiert , alle Einstellung nochmals neu eingegeben, neuen refresch_tocken generiert und eingegeben.
bekomme den Fehler nicht weg!
Im debug, kommt:
wo gibt man den Access_token ein!!! ich finde es nicht 
den access_token kann man nicht eingeben, der ist ja auch nur kurz gültig, bei manchen Anbindungen (ich habe nicht im Kopf, wie lange bei Netatmo) nur 1h.
Die Gültigkeit wird in API mit dem access_token zurück gegeben.
Mit Hilfe des refresh_token kann man den access_token immer wieder generieren.
Erst hat Netatmo das Login per OAuth so verändert, das es nicht für eine kontinuierlich steigende Anzahl von Konten nicht mehr funktionierte und @paresy es nicht mehr zu funktionieren gebracht hat. Der -Support hat es nur (nach etlichen Wochen Bearbeitungszeit) mit einem ihrer Testkonten probiert und - oh Wunder - es ging; also war das für sie kein Problem; zu weitergehender Analyse sahen sie keinen Anlass.
Dann haben sie die Loginvarinate von Entwicklerschlüssel+Username/Passwort gestrichen, sodass nur OAuth überblieb (was ja nicht mehr gängig ist).
Und so habe ich auf die Schnelle eine Umgehung dieser unsäglichen Situation mit Eingabe des auf der Netatmo-Webseite generierten refresh_token programmiert.
Funktioniert jetzt seid langen …
Den von dir beobachtete Fehler (invalid grant) hat mir vor einigen Tagen @Mavision gemeldet (für NetatmoWeather, ist aber die gleiche API). Anlässlich dieser Meldung habe ich meine Implementierung nochmal geprüft - sie entspricht genau der Dokumentation von Netatmo und auch dem OAuth-Standard.
Vom Netatmo-Support ist leider auch nichts zu erwarten, war früher mal gut, jetzt aber mit „wenig Luft nach unten“.
Und da sich Netatmo zudem auf der Produktseite seit vielen Jahren keine Weiterentwicklung macht (Wetterstation hat immer noch die gleichen Schwächen und die Kameras sind weder besonders zuverlässig noch leistungsfähig) … ich werde da auf jeden Fall keine neuen Produkte mehr kaufen.
D.h. ich kann Dir leider nicht viel Hoffnung machen, das ich das aktuelle Problem lösen kann.
Ich hatte anlässlich der Meldung von @Mavision bei mir die Eingabe des refresh_token nochmal durchgetestet und das funktioniert (bei NetatmoWeather und NetatmoSecurity) ohne Probleme.
Zu deinem Debug:
die Meldung „Hook is used“ besagt nur, das dieser Hook bereits in dem WebHook-Kernelmodul eingetragen ist - völlig normale Meldung und kommt bei jedem Start.
Die Meldung connection-type not set bedeutet, das der Typ der Verbindung (OAuth via. IPS-Connect oder Entwicklerschlüssel) aktuell nicht zur Erzeugung eines access_token gedient hat. Die Eingabe des refresh_token ist im Debug nicht zu sehen (vielleicht ist die Limitierung des Debug auf dem Default von 100 Zeilen?) - gehe aber davon aus, das das korrekt gemach5 wurde unter Angabe der in der Instant angegebenen scopes.
Da das (zur Zeit) nur bei ganz wenigen Konten rumzickt und nich5 bei mir kann ich Dir nur auch den Vorschlag machen, das mal mit deinen Zugangsdaten zu testen - eventuell gibt es noch irgendetwas, was dann zu sehen ist.
Hi,
Kann es sein das es daran lag, dass bei „Netatmo Zugangsdaten“ ein Eintrag drin stand (Rest von damals)?
Ich habe das Modul vor ein paar Tagen komplett gelöscht und neu konfiguriert.
Dabei ist mir aufgefallen das ich die Altlast von damals „Zugangsdaten für https://my.netatmo.com per Mail und Passwort“ nicht mehr drin steht.
Ich nutze nur den Entwicklerschlüssel und den Refresh-Token.
Seit der Neu-Installation scheint es zu funktionieren.-
Ich beobachte das mal und gebe Dir ein Feedback.
Bin mir nicht sicher, ob die Angabe von Username/Passwort noch möglich ist bzw. abgeprüft wird.
Ich habe primär die Eingabe des RefreshToken ermöglicht und das in interne Handlung angepasst
Werde ich mal checken und ggfs anpassen, ist ja sinnlos geworden.
Hi,
Und jetzt habe ich den Fehler wieder und auch einen Dump davon.
Ich werde aber daraus nicht schlau.
Interessant wird es heute um 8:49 Uhr.
dump-IPS-01082024.txt (327 KB)
HEX: 01.08.2024, 08:49:39 | UpdateData |
TXT: 01.08.2024, 08:49:39 | do_HttpRequest | http-GET: url=https://api.netatmo.net/api/getstationsdata?access_token=588b9108f54595047f8b50c7|5e6936d3efd5e0f27a362d5c3be6ea2b
TXT: 01.08.2024, 08:49:47 | do_HttpRequest | => errno=7, httpcode=0, duration=8,01s
TXT: 01.08.2024, 08:49:47 | do_HttpRequest | cdata=
TXT: 01.08.2024, 08:49:47 | do_HttpRequest | statuscode=213, err=got curl-errno 7 (Failed to connect to api.netatmo.net port 443 after 8013 ms: Couldn't connect to server)
TXT: 01.08.2024, 08:49:47 | do_HttpRequest | data=
TXT: 01.08.2024, 08:49:47 | MaintainTimer | timer=UpdateData(522), interval=5m, next=08:54:47
TXT: 01.08.2024, 08:49:47 | UpdateData | got curl-errno 7 (Failed to connect to api.netatmo.net port 443 after 8013 ms: Couldn't connect to server)
TXT: 01.08.2024, 08:49:47 | MaintainStatus | change status to 213(Instance is inactive (server error))
das besagt, das der Netatmo-Server nicht erreichbar war
TXT: 01.08.2024, 08:50:43 | CheckModuleConfiguration | "Netatmo_User" is needed
TXT: 01.08.2024, 08:50:43 | CheckModuleConfiguration | "Netatmo_Password" is needed
TXT: 01.08.2024, 08:50:43 | MaintainTimer | timer=UpdateData(522), interval=-
TXT: 01.08.2024, 08:50:43 | MaintainStatus | change status to 203(Instance is inactive (invalid configuration))
und das besagt, das die Konfiguration der Instanz ungültig ist (fehlender user&pw)
das - hatte ich ja vorhin geschrieben - muss ich nochmal rausnehmen.
sorgt aber jetzt erstmal dafür, das die IO-Instanz inaktiv ist (steht auch so in der Kopfzeile und die Instanz ist entsprechend markiert) und keine zyklischen Updates macht. warum er das zwischenzeitlich (am Anfang des Logs) gemacht hat, wäre interessant, sollte eigentlich komplett nichts tun.
Hi,
Eigentlich sollte der Dienst nach einem Server-Interrupt wieder mit dem Refresh-Token aufsetzen und nicht mit einer User-ID/Kennwort Kombination.
Den Fehler bekommt man ggf. In den Griff (nicht zu 100%) wenn man das Abfrage-Intervall erhöht.
Aber dann macht Wetter keinen Spass mehr 
Er setzt ja auch damit auf, User/PW wird funktionell ignoriert, war nur noch konfigurierbar.
Weil das damals Hals über Kopf zum Thema wurde, hatte ich erstmal nur Funktion hinzugefügt.
Aber wenn die Instanz nicht vollständig konfiguriert ist, wird sie nie IS_ACTIV sein, dafür sorgt eine entsprechende Modulspzifische Prüfung bei allen meine Modulen.
Wie gesagt, die wird verschwinden.
Die spannende Frage ist, warum er zu dem „invalid_grant“ kommt. Vermutlich ist der refresh_token irgendwie ungültig geworden. Der wird bei jedem Abruf eines access_token neu generiert (der alte refresh_token ist damit ungültig) und in der Instanz gespeichert. Die Speicherung ist ja permanent (mit dem Speicherintervall von IP von typischerweise 10m) - bleibt also auch über in Neustart von IPS erhalten.
Daher war meine Frage nach einem vollständigen Debüt - inklusive der Eingabe des refresh_token bis zum ersten invalid_grant. In der Hoffnung, das ich irgendwie sehen kann, wann der Token ungültig wird.
Für die Beachtung von Username/PW kommt demnächst ein Update, bis dahin müsstest du diese Felder schon ausfüllen.
in wie fern sollte das helfen?
Ich habe eine neue Beta eingereicht, damit entfällt die Eingabe von Username7Passwort und die Überprüfung dessen. Funktionell ist das Handling in der API unverändert.
Na ja ich dachte wenn der Intervall grösser ist dann sinkt die Wahrscheinlich in ein Serverproblem mit der Netatmo API zu laufen oder ist das falsch gedacht.
Mit freundlichen Grüßen
Hans-Jürgen Martini
Gerleinsstrasse 18
D-74736 Hardheim
Mobil: +49 1715320475
E-Mail: hjmartini@t-online.de
Ich glaube nicht, das es ein Serverproblem bei Netatmo ist, da würde ich eher andere Fehle erwarten (zB HTTP-Error 500). Das „riecht“ eher nach einem Netzwerkproblem. Ist aber nur eine reine Annahme.
Arbeitshypothese: aus irgendeinem Grund gibt es eine Unterbrechung während des Refresh des AccessToken - Call geht raus und wird auf Netatmo-Seite verarbeitet (damit ist der alte RefreshTocken ungültig), die Antwort erreicht aber nicht das IPS (das dann noch den alten RefreshToken hat). IPS versucht dann ein erneutes Refresh, das aber abgeleht wird, weil der RefreshToken ungültig ist.
Das ist für mich derzeit die einzige Idee, die einzige Lücke, wie der RefreshToken ungültig werden könnte.
Im Debug würde man das gut sehen können, ich würde ein API-Call zu RegreshToken erwarten, der dann in ein Timeout läuft