Nieuwe migratie-gerelateerde bug: zonvoorspelling in het laadplan lijkt fors te hoog t.o.v. de live Solcast-meting, waardoor de accu’s vandaag agressief op vol vermogen laden terwijl er van dat vermogen maar een fractie echt door de zon gedekt wordt.
Context: 3 sept ben ik gemigreerd naar een Homey Pro (2026, 4GB) i.v.m. chronisch vol geheugen op de oude Homey Pro (Early 2023). Sindsdien is opnieuw gekoppeld via een verse API-key, alles werkt weer, maar vandaag (6 sept) valt op dat de accu’s al de hele ochtend op bijna vol vermogen laden (~2200W per Sessy x3 = ~6,5kW) terwijl de Solcast-app (“Forecast.Solar”) live maar ~2,4kW aan zonproductie meet.
In het Laadplan zelf zie ik dat de “Zon”-kolom voor vandaag onrealistisch hoog staat: 10:30 = 1,81 kWh/kwartier (gemiddeld 7,2 kW), 10:45 = 1,64 kWh (6,6 kW), terwijl de live meting op dat moment rond de 2,4 kW schommelde. Actie “Zon-laden” wordt hierdoor ingezet op basis van een veel te optimistische zonvoorspelling, met als gevolg dat het merendeel van dat laadvermogen gewoon van het net komt (prijs nu €0,136-0,138, dus niet gratis) i.p.v. van de zon.
Mogelijk gerelateerd: in het diagnostiekscherm staan 50 recente foutmeldingen, allemaal om 00:16:20 vannacht gelogd, “[ProcessManager2.0] Invalid quarter data” met consumption/totalWh = null, voor circa 13 kwartieren vandaag (10:00-12:30) en bijna de hele dag morgen (01:30-12:30). Dat lijkt hetzelfde ProcessManager2.0-onderdeel te raken als de zonvoorspelling, dus vermoed ik één onderliggende oorzaak, mogelijk iets dat na de migratie opnieuw moet worden opgebouwd (leerdata/verbruiksmodel?).
Ik heb zelf voor nu een eigen “Boost laden bij lage prijs”-flow aangepast (extra voorwaarde “geen onbenut zonoverschot”) om te voorkomen dat mijn eigen automatisering bovenop dit probleem nog eens extra boost, maar dat lost de onderliggende te-hoge zonvoorspelling natuurlijk niet op. Herkent iemand dit, en is er een manier om de zonvoorspelling/rooftop-configuratie te forceren te verversen na een Homey-migratie?
