Hallo Jörg,
du hast recht! Warum auch immer hat Viessmann etwas an der Position der DeviceID geändert. Die Abfrage nach der Device ID im bisherigem Flow bzw. die Abfrage https://api.viessmann.com/iot/v1/equipment/installations/{{iid}}/gateways/{{gws}}/devices/ generiert eine Payload bestehend aus einem Array mit vier Elementen — msg.payload.data[0] bis data[3]. Bisher stand die Device ID in msg.payload.data[0].id, seit ca. Anfang 2024 steckt die DeviceID in msg.payload.data[1].id aber auch nicht bei allen Installationen. Das JSON Objekt von dir oben zeigt, dass bei dir die DeviceID an dritter Position steht also ...data[2].id
Bedeutet, man muss das JSON Objekt nach dem Wert deviceType: heating durchforsten. Das geht analog zum Suchen eines spezifischen Features in der Feature Abfrage mit Javascript findIndex und ist hier beschrieben.
Das fällt natürlich nur denjenigen auf, die sich die drei statischen Parameter regelmäßig aus der API ziehen. Hardcoded gibt es das Problem nicht, da die deviceID ja in der Regel "0" ist. Die einfachste Lösung wäre also, hier generell eine 0 für die deviceID anzunehmen.
Mir ist das auch erst aufgefallen, nachdem mich ein Leser meines Blogs darauf hingewiesen hat. Da ich die statischen Parameter nur alle ca. 180 Tage abfrage, war es bei mir noch nicht so weit, dass mein System in den Fehler gelaufen ist. Erst nachdem ich testweise einen Refresh des Refreshtokens und damit auch die statischen Parameter neu geladen hatte, ging nichts mehr.
Ich habe einen entsprechenden Hinweis in mein Blog aufgenommen.
@MichaelHanna: Eigentlich ein NoGo, strukturelle Änderungen an der API "einfach so" durchzuführen. Könnt ihr mal euren Programmieren sagen, dass solche Änderungen, wenn sie denn schon sein müssen, unbedingt im Change Log nachgezogen und vorher angekündigt werden müssen. Sonst tappen eure Fans im Dunkeln.
VG
Chris
