Integrere strømpriser fra amsleser i Home Assistant?

[thoralex]

Med tanke på problemene med entso-e i det siste og at gutta i utilitech jobber med en fallback for leserne sine så vurderer jeg å bytte over til å bruke data fra min pow-u+. Home assistant får jo allerede inn prisene, men hvordan bruker jeg dem? Har brukt både nordpool- og entso-e-integrasjonene før og begge fikser jo det meste for meg med litt templater og kode fra forumet her for å få sensorene jeg trenger. Det jeg trenger er:
- priser med og uten nettleie (og kode for å få det inn i apexcharts)
- sensorer for billigste/dyreste x antall timer i visse perioder

Er det noen som har laget noe slikt og kan dele så en amatør som meg også kan få det til?

[stigvi]

Jeg ser at amsleser gjør samme "feilen" som Nordpool integrasjonen. De sletter historiske data etterhvert som tiden går. Når en ønsker å lade en bil på de X billigste timer i løpet av en natt så er historiske data helt vesentlig. Klokken tre om natten er det greit å vite om bilen har ladet i 3 eller 5 timer allerede.

Så for å løse dette må en ta vare på data i Home Assistant. Det er fullt mulig, men det føles unødvendig tungvint i forhold til hvordan det er løst i entso-e integrasjonen. Der er det en tabell med alle tilgjengelige priser dette og neste døgn og hvilken time den gjelder for. Denne kan en sortere på pris og en finner lett X billigste timer. Hvis amsleser i fremtiden tilbyr prisene noe ala dette, så skal jeg vurdere å kikke på det. Men når amsleser sletter all historikk så blir det bare masse ekstra arbeid å ta vare på den. Home Assistant sine templates er begrenset i bruk og de er vanskelige å bruke til å ta vare på historikk som dette.

 

Feilen i helgen lå hos Entso-e. Dette er ikke noe amsleser kan gjøre noe med utenom at de må hente data fra andre kilder. Nordpool_diff integrasjonen kan lese prisdata både fra entso og nordpool og nordpool brukes som en reserve. Det kan også være en løsning. 

Endret 30. mai 2023 av stigvi

[thoralex]

Slik jeg har forstått et par diskusjoner på githuben til amsleser så er planen å bruke et api fra en dansk tjeneste som backup, den kan i motsetning til nordpool brukes uten å bryte vilkårene.

Det er ikke første gang entso-e har problemer, så jeg savner en reserveløsning. Har prøvd å lage en enkel nødløsning som bare lar vvb stå på når data mangler, men så langt har jeg ikke fått det til å fungere.

Endret 30. mai 2023 av thoralex

[Kim123]

stigvi skrev (På 30.5.2023 den 13.20):

Jeg ser at amsleser gjør samme "feilen" som Nordpool integrasjonen. De sletter historiske data etterhvert som tiden går. Når en ønsker å lade en bil på de X billigste timer i løpet av en natt så er historiske data helt vesentlig. Klokken tre om natten er det greit å vite om bilen har ladet i 3 eller 5 timer allerede.

hvorfor er det vesentlig å vite historisk data? Hvis en skal vite hvor lenge du har ladet er det andre enkle løsninger. 
 

thoralex skrev (På 30.5.2023 den 17.40):

Det er ikke første gang entso-e har problemer, så jeg savner en reserveløsning. Har prøvd å lage en enkel nødløsning som bare lar vvb stå på når data mangler, men så langt har jeg ikke fått det til å fungere.

se på staten i developer tools når du mangler data. Ofte så er staten unavailable

[stigvi]

Kim123 skrev (8 timer siden):

hvorfor er det vesentlig å vite historisk data? Hvis en skal vite hvor lenge du har ladet er det andre enkle løsninger. 

Finn de 5 billigste timene mellom 21:00 og 06:00 uten å vite noe om historikk. Med entso-e integrasjonen som tar vare på historikk er dette superenkelt og en gjør det med en mal-sensor uten å installere noe nytt i HA.

Endret 2. juni 2023 av stigvi

[Kim123]

Ser fortsatt ikke poenget i å vite historisk data? Lag en automasjon som putter de forskjellige timene i en hjelper når de er tilgjengelig og se om de stemmer opp mot nåværende time? 

[thoralex]

9 hours ago, Kim123 said:

se på staten i developer tools når du mangler data. Ofte så er staten unavailable

De gamle dataene blir liggende helt til det kommer nye, så de blir stående på siste kjente state.

[stigvi]

Kim123 skrev (1 time siden):

Ser fortsatt ikke poenget i å vite historisk data? Lag en automasjon som putter de forskjellige timene i en hjelper når de er tilgjengelig og se om de stemmer opp mot nåværende time? 

Da har du allerede gjort det mye mer komplisert. Du må lage en automasjon som gjør jobben og du må lage en eller flere hjelpere. I motsetning til en malsensor som er forholdsvis kort og enkel.

Men som du nevner, det er fullt mulig å få til. Det er bare unødvendig komplisert pga ams-leser sin iver i å slette data så snart timen er ferdig.

Data med nye priser er tilgjengelig en gang i døgnet og da kan en lese inn de neste 24 timene og kvitte seg med de 24 eldste timene. På den måten har en tilgjengelig to døgn med priser. Det er slik entso-e integrasjonen virker. Det er ingen god grunn for å slette data hver time slik som ams-leser gjør eller ved midnatt slik nordpool integrasjonen gjør. Begge disse to krever at en må lage automasjoner og hjelpere for å ta vare på informasjon som er helt unødvendig å slette fram til nye priser er tilgjengelig. Mener nå jeg.

Endret 2. juni 2023 av stigvi

[Kim123]

thoralex skrev (37 minutter siden):

De gamle dataene blir liggende helt til det kommer nye, så de blir stående på siste kjente state.

 

Da kan du lage en automasjon/trigger hvis sensoren ikke har endret seg på 24 timer feks. Typ noe som under. 

trigger: 
  - platform: state
    entity_id: sensor.strompriser
    for: "24:00:00"
action: 
  - service: switch.turn_on
 	entity_id: switch.bereder

 

 

stigvi skrev (38 minutter siden):

Da har du allerede gjort det mye mer komplisert. Du må lage en automasjon som gjør jobben og du må lage en eller flere hjelpere. I motsetning til en malsensor som er forholdsvis kort og enkel.

Men som du nevner, det er fullt mulig å få til. Det er bare unødvendig komplisert pga ams-leser sin iver i å slette data så snart timen er ferdig.

Data med nye priser er tilgjengelig en gang i døgnet og da kan en lese inn de neste 24 timene og kvitte seg med de 24 eldste timene. På den måten har en tilgjengelig to døgn med priser. Det er slik entso-e integrasjonen virker. Det er ingen god grunn for å slette data hver time slik som ams-leser gjør eller ved midnatt slik nordpool integrasjonen gjør. Begge disse to krever at en må lage automasjoner og hjelpere for å ta vare på informasjon som er helt unødvendig å slette fram til nye priser er tilgjengelig. Mener nå jeg.

 

Ser den, greit med ting som allerede er på plass, men er det ikke bedre å lage en sånn automasjon enn at systemet failer på en måte. Det hadde hvertfall jeg gjort, en work-around, selv om det kanskje ikke er beste løsning 

 

 

 

 

 

 

 

 

 

 

[thoralex]

49 minutes ago, Kim123 said:

 

Da kan du lage en automasjon/trigger hvis sensoren ikke har endret seg på 24 timer feks. Typ noe som under. 

trigger: 
  - platform: state
    entity_id: sensor.strompriser
    for: "24:00:00"
action: 
  - service: switch.turn_on
 	entity_id: switch.bereder

Takk, det skal jeg teste ut.
Edit: Hadde ikke tenkt på at jeg kunne bruke state sånn uten å spesifisere attributt eller tilstand, har lagt det til til noe nå så får vi se hva som skjer neste gang.

Endret 2. juni 2023 av thoralex