home-assistant-zonneplan-one icon indicating copy to clipboard operation
home-assistant-zonneplan-one copied to clipboard

Connect call failed

Open tieskuh opened this issue 9 months ago • 12 comments

Alle sensoren van de integratie worden soms unavailable. In het logboek is de volgende error te vinden:

Error requesting zonneplan_one data: Cannot connect to host app-api.zonneplan.nl:443 ssl:default [Connect call failed ('52.18.96.60', 443)]

Lijkt dus een connectiefout te zijn. Wellicht iets bij Zonneplan. De sensors blijven echter unavailable tot ik de integratie herlaad (of ik ben niet geduldig genoeg).

Is er iets in te bouwen dat de integratie zichzelf herstelt na een connectiefout? Ik hoor het graag als ik iets meer aan kan leveren.

tieskuh avatar May 04 '24 19:05 tieskuh

Heb ik ook idd. Het is ook om de zoveel minuten wel data, geen data, wel data etc.

Paul1865 avatar May 04 '24 19:05 Paul1865

Inderdaad. Als je langer wacht herstelt de integratie zichzelf wel. Mogelijk is dit dan een non-issue. Het probleem zit duidelijk bij Zonneplan. De retry interval zou echter iets korter kunnen wellicht.

tieskuh avatar May 04 '24 20:05 tieskuh

Dit probleem heb ik inderdaad ook al langer. Zou top zijn als dit gefixed kan worden.

rootadmin1 avatar May 05 '24 06:05 rootadmin1

Vanochtend is de gasprijs unavailable. Ik gok dat tijdens het updaten (gebeurt op een vast tijdstip toch?) de connectie met Zonneplan niet luktte. Deze sensor blijft echter unavailable totdat ik de integratie herlaad. Wellicht ook daarvoor een retry inbouwen?

image

tieskuh avatar May 05 '24 07:05 tieskuh

Bij mij hetzelfde probleem. Ik heb een melding ingesteld wanneer de stroomprijs negatief c.q. weer positief wordt, en die ging vannacht zo ongeveer elk uur af (blijkbaar triggert de voorwaarde "wordt hoger dan 0" ook als hij uit "unavailable" komt). Het is echt iets van de laatste dag(en) dus.

mvzut avatar May 05 '24 09:05 mvzut

Er zit een retry in maar pas bij de volgende interval (willen Zonneplan ook niet overbelasten want anders gaan ze ons verder limiteren). Als goed is wordt pas bij de 2de mislukte poging de sensor op unavailable gezet, kunnen jullie dit terug zien in de logs?

fsaris avatar May 05 '24 10:05 fsaris

Er zit een retry in maar pas bij de volgende interval (willen Zonneplan ook niet overbelasten want anders gaan ze ons verder limiteren). Als goed is wordt pas bij de 2de mislukte poging de sensor op unavailable gezet, kunnen jullie dit terug zien in de logs?

Ik zal er even op letten of dat zo is. Het leek al te gebeuren bij de eerste mislukte poging. Kom ik op terug. Maar de retry lijkt verder inderdaad prima te werken. Behalve voor de gasprijssensor. Ik geloof dat je die maar 1x per dag bijwerkt toch? Het lijkt erop dat als op dat moment de connectie niet lukt, hiervoor geen retry is. Klopt dat? Hij bleef bij mij unavailable totdat ik de integratie herstartte.

tieskuh avatar May 05 '24 10:05 tieskuh

Toevallig gaan de sensoren precies nu op unavailable. Ik zie de connection error maar één keer in het logboek staan. Ze lijken dus al direct op unavailable te gaan bij een mislukte poging. Als dat pas bij de tweede of derde poging zou gebeuren zou dit inderdaad beter zijn.

Het probleem is dan mijns inziens tweeledig:

  • Retry op de gasprijs (of wellicht gewoon wat vaker ophalen dan 1x per dag?)
  • Sensors niet direct unavailable als er een call mislukt

tieskuh avatar May 05 '24 10:05 tieskuh

Er zit een retry in maar pas bij de volgende interval (willen Zonneplan ook niet overbelasten want anders gaan ze ons verder limiteren). Als goed is wordt pas bij de 2de mislukte poging de sensor op unavailable gezet, kunnen jullie dit terug zien in de logs?

Waarom eigenlijk zoveel intervallen? Je hebt in de forecast al alle prijzen voor de hele dag, dus je kunt adh daarvan dan de actuele stroomprijs bepalen. 1x per uur zou meer dan genoeg zijn denk ik. Op zich doe ik dat nu ook al omdat de current_electricity_tariff te vaak op unavailable staat :) .

(via automation): variables: current_hour: "{{ utcnow().strftime('%Y-%m-%dT%H:00:00.000000Z') }}" new_price: > {% for entry in state_attr('sensor.zonneplan_current_electricity_tariff_last_valid', 'forecast') %} {% if entry.datetime == current_hour %} {{ entry.electricity_price / 10000000 }} {% endif %} {% endfor %}

die sensor.zonneplan_current_electricity_tariff_last_valid wordt alleen gevuld als sensor.zonneplan_current_electricity_tariff bechikbaar is en de forecast is gevuld. En met die last_valid doe ik dan weer alles.

Paul1865 avatar May 05 '24 21:05 Paul1865

Waarom zo vaak? Ik denk omdat ook het actuele verbruik etc. gelogd wordt. Zelf gebruik ik dat niet, ik heb een kabeltje naar de P1 poort van m'n meter. Maar anderen gebruiken deze info wellicht.

Bij het voor de eerst keer instellen van de Zonneplan integratie zou het op zich geen gek idee zijn om al die real-time verbruiksdata te kunnen disablen. Je kunt er op die manier voor kiezen om alleen entities voor de energieprijzen te laten maken, en die hoeven inderdaad lang niet zo vaak geüpdatet te worden.

Overigens, als het je echt alleen om de stroomprijzen gaat kan je ook overwegen om de Nordpool plugin te gebruiken, met een formule (percentage) voor de extra kosten die Zonneplan rekent. Helaas geeft Nordpool geen gasprijzen, anders had ik de Zonneplan plugin er waarschijnlijk al lang af gegooid.

mvzut avatar May 06 '24 11:05 mvzut

Even een vraag.. waar komen de api's vandaan. Ik kan nergens documentatie vinden. Ik zit er aan te denken om gewoon api calls te maken in node red en vanuit daar enkele sensoren met de benodigde info in HA. Dan kan ik zelf per api call instellen wat de interval kan zijn. Daarnaast mis ik nu een hoop info. Ik wil de info per uur eruit halen en in een array zetten zodat ik het systeem op voorhand kan laten checken wanner de gunstige uren zijn en aan de hand daarvan kan laten bepalen samen met de voorspelde zonuren van mijn zonnepanelen wat het verstandigste is om te doen. Met hoog en laag tarief weet je nog niks.

De integratie moet eigenlijk een sensor "tarief" hebben met als waarde de op dat moment geldende prijs en in de attribute table zouden dan de 16 uur daarna per uur moeten worden opgeslagen. Dan kun je met een script de waardes er zo uithalen. Dan kun je vervolgens laten uitrekenen door HA wanneer je accus die op dat moment nog bijvoorbeeld 5 kwh moeten laden met 800 watt per uur moeten gaan laden om volledig binnen de laagste tarieven te blijven. Dit icm met forecast.solar integratie kun je dan een mooie voorspelling maken met wat de meest gunstige prijs is om te gaan laden.

Ik kan echter nergens info vinden over de api's.

Ik denk daarnaast dat het uitlezen van de slimme meter niet echt meerwaarde heeft in deze integratie. Er zijn 100den opties die dit al doen. Ik zou dit los koppelen van de huidige integratie dan zit je misschien ook niet te kloten met die update tijd van de sensoren. Iedere 10 seconden is echt veel te vaak voor een api call die ieder uur maar veranderd.

Hmm ik zie nu dat de api's sowieso niet public zijn voor de uurstarieven.

sygys avatar Oct 07 '24 06:10 sygys

Er is geen openbare documentatie van de api. Ik heb de reverse engineerd op basis van het verkeer van de officiële app.

De integratie moet eigenlijk een sensor "tarief" hebben met als waarde de op dat moment geldende prijs en in de attribute table zouden dan de 16 uur daarna per uur moeten worden opgeslagen. Dan kun je met een script de waardes er zo uithalen.

De forecast is momenteel al aanwezig als attribuut van de huidige tarief sensor

Zie readme https://github.com/fsaris/home-assistant-zonneplan-one#zonneplan-energy-contract-related

Current Zonneplan Electricity tariff: €/kWh . The full Electricity forecast is available as a forecast attribute of this sensor

Zie ook voor een voorbeeld om dit als grafiek weer te geven #47 of als tabel #41.

Ik denk daarnaast dat het uitlezen van de slimme meter niet echt meerwaarde heeft in deze integratie. Er zijn 100den opties die dit al doen. Ik zou dit los koppelen van de huidige integratie dan zit je misschien ook niet te kloten met die update tijd van de sensoren. Iedere 10 seconden is echt veel te vaak voor een api call die ieder uur maar veranderd

Normaal gesproken update je p1 data wel iedere x seconden. maar de api zal je sowieso maar iedere 5min een update geven. Voor de zonneplan klanten die alleen de p1 lezer van zonneplan hebben is dit natuurlijk een makkelijke manier om dit in HA te krijgen.

Begrijp je opmerking over 10sec niet helemaal. Api wordt iedere 5 min aangeroepen

Dan kun je vervolgens laten uitrekenen door HA wanneer je accus die op dat moment nog bijvoorbeeld 5 kwh moeten laden met 800 watt per uur moeten gaan laden om volledig binnen de laagste tarieven te blijven. Dit icm met forecast.solar integratie kun je dan een mooie voorspelling maken met wat de meest gunstige prijs is om te gaan laden.

Misschien goed om de verschillende discussie topics eens door te lezen, je bent niet de eerste met dit idee https://github.com/fsaris/home-assistant-zonneplan-one/discussions

fsaris avatar Oct 08 '24 16:10 fsaris