Vraag over installeren

[harryboer]

Ik heb volgens mij alle stappen gevolgd om het te installeren. Als ik nu met debug de berekening uitvoer werkt het zonder foutmeldingen. Als ik nu zonder debug uitvoer krijg ik dit onderaan te zien:

Result - Optimal solution found Objective value: 3.0295401833 Enumerated nodes: 0 Total iterations: 31 Time (CPU seconds): 0.110642 Time (Wallclock seconds): 0.122427 Total time (CPU seconds): 0.110824 (Wallclock seconds): 0.122986 Traceback (most recent call last): File "/root/dao/webserver/../prog/day_ahead.py", line 1697, in <module> main() File "/root/dao/webserver/../prog/day_ahead.py", line 1662, in main day_ah.calc_optimum() File "/root/dao/webserver/../prog/day_ahead.py", line 1265, in calc_optimum self.select_option(self.battery_options[b]["entity set operating mode"], new_state) File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py", line 49, in select_option return self.call_service("select_option", entity_id=entity_id, option=option) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py", line 28, in call_service self._post( File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 61, in _post return self._process_response( ^^^^^^^^^^^^^^^^^^^^^^^ File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 82, in _process_response self._raise_error(response.status_code, response.url) File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 87, in _raise_error raise error(f"{status_code} status code returned from {url}",) # type: ignore ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ hassapi.exceptions.InternalServerError: 500 status code returned from https://xxxxxxxxx.duckdns.org:8123/api/services/input_select/select_option

Heb ik ergens nog iets fout staan of over het hoofd gezien?
Mijn setup is met Zonnepanelen, 3 Sessy accu's (15kWh), geen EV, geen boiler, wel WP maar die heb ik nog niet ingevuld.

[corneel27]

Waarschijnlijk ontstaat de foutmelding omdat het programma de batterij(en) aan of uit wil zetten met de entity "entity set operating mode". Dit moet een input_select zijn (helper) met minimaal de opties "Aan" of "Uit".
Deze entity gaat in een van de volgende versies vervallen, maar helaas heb jij daar nu niks aan.
Oplossing: maak zo'n helper (of eventueel per sessy een) in HA aan en geef de naam van de entity op bij "entity set operating mode".
Je kunt een automation maken die bij een wijziging van deze input_select de sessy daadwerkelijk aan of uit zet, zodat je geen stilstandsverliezen hebt als hij uit moet staan.
Succes!

[harryboer]

Aha, ik had al wel een helper aangemaakt maar wist niet goed met welke opties. De foutmelding is nu weg! Echter volgens de grafiek zou om 18:00 de batterij moeten ontladen maar er gebeurde niks. De status vd helper bleef op 'uit'...

[corneel27]

Je kunt het het best instellen en testen in twee stappen:
Stap 1: maak een helper input_number van bijv -3000 tot +3000 in stappen van 1 bijv. input_number.dao_feedin_sessy1
Maak een automatisering die reageert op een wijziging van de state van deze input_number en die de nieuwe waarde doorzet naar Sessy1. Jij weet zelf wel welke entity in de sessy-integration daar voor staat. Test deze stap door zelf handmatig deze waarde aan te passen. Als de Sessy hierop goed reageert ben je op de goede weg.
Stap 2 zet deze input_number in je instellingen bij sessy 1 bij "entity set power feedin": "input_number.dao_feedin_sessy1"
Nu zou het moeten werken.
Succes!
Groeten van Cees

[harryboer]

Over de duckdns: Ik had in de config file van DAO bij homeassistant het adres ingevuld van de duckdns omdat het anders niet werkte. Het lokale IP adres http of https werkte beide niet, dan kreeg ik melding ‘home assistant api not running’. Met de duckdns ingevuld lukte het wel maar niet stabiel. Maar nu met NGINX kan ik wel gewoon het lokale ip adres invullen en werkt dus perfect.

over de WP: ik kan mijn stooklijn dus per 1 graad verschuiven. Wat zijn ong de verschuivingen die ik vanuit DAO nu kan verwachten. Ik zag soms 0.1 of 0.6. Maar dat werkt voor mij niet zo. Dus ik kan er een factor aan geven of naar boven afronden, of kan er een groter heel getal ui DAO komen?

Sessy: ik hoop dat er een oplossing vanuit Sessy komt want anders wordt het wel een heel gekunstelde oplossing, maar ik zat ook al aan jou voorstel te denken. Ik ga er mee aan de slag.

[harryboer]

Sessy heeft een oplossing gevonden voor de SoC, dus dat werkt nu goed. Ik heb nog 1 verzoek os om de max vermogen voor laden en ontladen apart in te kunnen stellen. De Sessy bijv heeft max 2200W laad en max 1700 ontlaad.

[corneel27]

Dag Harry,
Dat laat zich eenvoudig oplossen. Zowel voor laden maar ook voor ontladen geef je een range aan vermogens op met voor ieder vermogen de omzet efficiency. Die range is tegelijkertijd de vermogensrange die beschikbaar is voor laden en ontladen.
Bijvoorbeeld (als je 1 Sessy hebt):

    "charge stages" : [
        {"power": 0.0, "efficiency": 1},
        {"power": 30.0, "efficiency": 0.949},
        {"power": 60.0, "efficiency": 0.950},
        {"power": 90.0, "efficiency": 0.951},
        {"power": 150.0, "efficiency": 0.952},
        {"power": 300.0, "efficiency": 0.953},
        {"power": 600.0, "efficiency": 0.954},
        {"power": 1200.0, "efficiency": 0.955},
        {"power": 2200.0, "efficiency": 0.949}
    ],
     "discharge stages" : [
        {"power": 0.0, "efficiency": 1},
        {"power": 30.0, "efficiency": 0.949},
        {"power": 60.0, "efficiency": 0.950},
        {"power": 90.0, "efficiency": 0.951},
        {"power": 150.0, "efficiency": 0.952},
        {"power": 300.0, "efficiency": 0.953},
        {"power": 600.0, "efficiency": 0.954},
        {"power": 1200.0, "efficiency": 0.955},
        {"power": 1700.0, "efficiency": 0.949}
    ],

Let op:

• De hier opgenomen efficiencies heb ik zelf verzonnen, volgens mij staan de juiste goed beschreven op de website van Charged of het tweakersforum.
• Je kunt zoveel stappen toevoegen als je zelf zinvol vindt.
• Dit zijn in principe de efficiencies van de omvormer AC->DC (laden) of omgekeerd.
• Je kunt daarnaast nog de efficiency opgeven van DC->BAT en van BAT-> DC. (vooral van belang als je zonnepanelen met MPTT op de accu aansluit) bijvoorbeeld:

     "dc_to_bat efficiency" : 0.98,
     "bat_to_dc efficiency": 0.98,

De overall-effiency is steeds het product van beide stappen.
In jouw geval kun je DC->BAT en BAT->DC op 1 zetten.

[corneel27]

Ik heb begrepen dat de Sessy bij lage vermogens een slechte efficiency heeft. Daarvoor heb ik als oplossing de instelling:

    "minimum power" : 300,
     "entity stop victron": "input_datetime.stop_victron",

Als er in een bepaald uur bijvoorbeeld maar 0,2 kWh moet worden geladen gaat het programma toch laden met 300 W en zet het de eindtijd (dus 40 minuten verder) in de entity stop victron (sorry voor de naam). De bedoeling is dat jij daar dan een automatisering aan hangt die getriggerd wordt als dat tijdstip wordt bereikt en dan het laden (of ontladen) stopt.

[harryboer]

Ik had de efficiëncies inderdaad aangepast maar wist niet zeker dat dat dan ook het max vermogen is, dan heb ik al goed ingesteld. Ik meet de werkelijke efficiëncies wel lager liggen dan die op website/tweakers staan, dus ik extrapoleer deze naar meer werkelijke waarden. Ik had nog niet door wat die eindtijd betekende, maar helder nu. Dank weer voor de antwoorden, kan ik weer verder.

Zag dat ze bij Frank energie nu ook onbalans handelen vaan aanbieden voor bepaalde type batterijen (waaronder sessy). Maar dan wordt het een handelsapparaat en niet zozeer eigen gebruik optimaliseren.

[harryboer]

Het werkt nu allemaal behoorlijk goed nu de SoC beter werkt. Om precies op bij bijvoorbeeld 2% uit te komen blijft wel uitdaging voor een Sessy. Het berekende wattage van DAO om na een uur op 2% uit te komen levert nog wel eens op dat het naar een waarde in de buurt van 2% met het gevolg dat soms weer moet worden bijgeladen om de minimum SoC te halen, dit gaat dan wel tegen een hoge prijs. Is dit specifiek voor Sessy of gaat dit bij Victron ook zo.
Wat is trouwens precies het verschil tussen 'lower limit' en 'optimal lower limit'

Ik heb nog een verzoek. Is het ook mogelijk om in DAO andere apparaten toe te voegen zoals bijv wasmachine of vaatwasser. Ik stel normaal gesproken de wasmachine in met 'uitgesteld einde' om de eerstvolgende laagste prijs te benutten. Dus 's avonds wil ik het laagste prijs in de komende nacht gebruiken en kan 's ochtends de laasgste prijs overdag gebruiken. het zou mooi zijn als ik met een druk op een knop in HA een berekening trigger om te weten wat de 'uitgesteld einde' moet zijn (gaat per uur). Dan zijn dus tijdsduur van het programma van belang en de tijd van laagste prijs. De vaatwasser is weer een ander verhaal omdat dat met uitgestelde start werkt wat weer veel makkelijker is. Is hier iets wat vanuit DAO aangeleverd kan worden, mat name het tijdstip tot laagste prijs.

En zijn andere energie leveranciers ook te gebruiken, of zijn de werkelijke gebruiksgegevens niet zo belangrijk?

[corneel27]

Mooi dat het nu goed werkt.
Misschien een idee om hier iets over te melden in het sessy forum en/of tweakers?

Die twee instellingen zijn precies bedoeld uit te komen in die marge. Je zou bijvoorbeeld als lower limit 2% op kunnen geven en als optimum lower limit 3%. Als hij dan daar tussen uitkomt doet hij meestal niks. Een andere oplossing zou kunnen zijn om een helper (input_number) aan te maken die de gemeten SoC kopieert en afrondt op hele procenten en dat je dan stuurt op die helper.

Jouw verzoek om andere apparaten toe te voegen vind ik wel heel interessant. Wil je met mij erover meedenken hoe ik dat vorm kan geven? Ik doe alvast een voorzet:
Bij de instellingen komt een hoofdstuk "Other devices", waarin 0, 1 of meer devices (apparaten) kunnen worden gedefinieerd.
Ieder apparaat krijgt dan de volgende eigenschappen:

• naam
• vermogen in W
• duur
• entity in HA met tijdstip waarop hij klaar moet zijn, als deze op 00:00 staat wordt er niet ingepland
• entity in HA waarin het berekende begintijdstip wordt gepubliccerd (als deze "leeg" is of afwezig wordt er niet gepubliceerd)
• entity in HA waarin het berekende eindtijdstip wordt gepubliceerd (als deze "leeg" is of afwezig wordt er niet gepubliceerd)
  Graag jouw commentaar hierop.

Het programma is niet meer afhankelijk van Tibber.
Je kunt dus ook andere leveranciers gebruiken.
Wat je moet doen is:

• het ophalen van data bij Tibber uit de scheduler halen
• zorgen dat bij report, de entities voor consumption en production zijn ingevuld. Bijvoorbeeld:

    "entities grid consumption": [
      "sensor.grid_consumption_low",
      "sensor.grid_consumption_high"
    ],
    "entities grid production": [
      "sensor.grid_production_low",
      "sensor.grid_production_high"
    ],

[harryboer]

Ik heb even over wat scenario's nagedacht en het hangt er dan van af of DAO aangeeft wanneer een apparaat aangezet moet worden met een bepaalde uitgesteld einde/start of dat de gebruiker op een bepaald moment een apparaat aan wil zetten en wil weten welk uitgesteld einde/start moet worden ingesteld. De 2e lijkt mij gebruiksvriendelijker. Dan is het nog de vraag hoe de informatie tot de gebruiker komt. Normaal gesproken berekend DAO per uur, maar daar houd een gebruiker zich natuurlijk niet aan.
Ik heb het even gevisualiseerd wat voor het voor mij wat makkelijker maakt.

In het bovenste scenario besluit de gebruiker om 19:40 het apparaat in te stellen. Op dat moment pakt hij/zij HA erbij en stelt duur en wanneer het klaar moet zijn in, drukt hij op een knop in HA en er komt het optimale uitgestelde einde uitrollen: 10 uur

Het onderste scenario berekend DAO elk uur een optimaal scenario wat voor dat uur geld op basis van vooringestelde default waarde (het is 's avonds dus het moet voor 9u morgen klaar zijn en programma dat normaal wordt gebruikt is 2:30). Wat komt er dan uit... 10uur of 11uur? Aan het begin vh uur zou ik zeggen 11 uur en richting het einde vh uur 10 uur.

Verder heb ik het vermogen van een wasmachine run bekeken:

Hier is duidelijk te zien dat het begin het belangrijkste deel is qua vermogen, dit kan voor andere apparaten weer anders zijn. Ik zal eens de vaatwasser en droger gaan meten.

Ik denk dat een druk op de knop in HA het beste resultaat zal geven, het bovenste scenario dus. Maar het moet wel zo gebruiksvriendelijk mogelijk anders weet ik niet of iedereen in mijn huishouden het gaat gebruiken...

Waar ik in eerste instantie aan zat te denken om zo'n e ink infolabel te gebruiken die dan naast de wasmachine/ vaatwasser komen te hangen en die geven dan altijd de optimale uitgestelde tijd weer voor dat apparaat op dat moment (op basis van de default waarde). Dan hoef je HA er helemaal niet bij te pakken. Maar weet niet of dat gaat lukken, het onderste scenario zou dan weer beter zijn alleen heb je dan denk ik meerdere berekeningen per uur nodig. Misschien een DAO berekening per uur en dan een automatisering die in het lopende uur op basis van goedkoopste uur uit DAO berekening het advies bijv per 5 minuten bijstelt of zoiets?

[corneel27]

Interessant allemaal.
Op basis van jouw informatie heb ik mijn voorstel iets verder aangepast en uitgewerkt:

Ieder apparaat krijgt dan de volgende eigenschappen:

• naam, bijvoorbeeld wasmachine
• een lijst met programma's (minimaal 1) met voor ieder programma een naam (bijvoorbeeld "30 graden bont") en een lijst met kwartieren en per kwartier het vermogen, de duur in uren is dan het aantal kwartieren gedeeld 4
• entity in HA waarmee het gekozen programma kan worden ingesteld, kan ook op "uit" staan, dan wordt er niet ingepland
• entity in HA met tijdstip (per kwartier instelbaar) waarop hij klaar moet zijn
• entity in HA waarmee een tussentijdse DAO berekening kan worden gestart (functionaliteit is er al)
• entity in HA waarin na de berekening het berekende begintijdstip wordt gepubliceerd (als deze "leeg" is of afwezig wordt er niet gepubliceerd). Het aantal uur vanaf "nu" kan door HA eenvoudig worden berekend als extra sensor en dit kan worden weergegeven op het instel/berekeningscherm
• entity in HA waarin het berekende eindtijdstip wordt gepubliceerd (als deze "leeg" is of afwezig wordt er niet gepubliceerd) . Ook hier geldt: het aantal uur vanaf "nu" tot aan het berekende uiteindstip kan door HA eenvoudig worden berekend als extra sensor en dit kan worden weergegeven op het instel/berekeningscherm.

Al deze info kan ook beschikbaar worden gemaakt via een e-inkt display (aanstuurbaar met een esp), maar dat ligt buiten de invloedssfeer van DAO.
Tenslotte: voor ieder apparaat kan de laatste instelling (meestal default) blijven staan en hiermee wordt 24 uur later weer een nieuwe "run" ingepland.

Zou dit zowel voor jou maar ook generiek kunnen werken?

[harryboer]

Denk dat we zo een heel eind moeten komen. Dat idee van keuze van verschillende programma's lijkt me ook een goed idee! Ik zat nog wel te bedenken dat veel nieuwe apparaten ook een slimme koppeling hebben waarbij via API ook een programma gestart kan worden. Mijn droger zou dat theoretisch kunnen maar krijg het nog niet aan de praat in HA. Zou dit misschien nog een toevoeging kunnen zijn. Optie om aan te geven of je smart aansturing hebt.

[harryboer]

Hier nog het verloop van de droger, dit is meer geleidelijk dan bij de wasmachine.

[corneel27]

Die slimme koppeling is volgens mij eenvoudig mogelijk met Home Assistant. Als het startmoment van een apparaat door DAO wordt weggeschreven naar een entity dan kan op het moment dat dat tijdstip worden bereikt in HA daarmee een automatisering worden getriggerd die die API aanroept.
Voorbeeld: ik heb zo'n automatisering (maar dan andersom). Die zet het laden/ontladen van mijn thuisaccu uit als een door DAO ingestelde tijd worden bereikt:

description: ""
trigger:
  - platform: time
    at: input_datetime.stop_victron
condition: []
action:
  - service: input_number.set_value
    data:
      value: 0
    target:
      entity_id: input_number.dao_setpoint_feedin_ess
  - service: input_select.select_option
    data:
      option: Uit
    target:
      entity_id: input_select.ess_operating_mode
  - service: input_datetime.set_datetime
    data:
      datetime: "2000-01-01 00:00:00"
    target:
      entity_id: input_datetime.stop_victron
mode: single

Dus DAO hoeft niet te worden of er "smart" wordt aangestuurd. Dat kun je dan zelf in HA regelen.
Ik ga alvast iets maken (zal wel een week of zo duren) en dan zet ik een testversie in de addon-branche.
Zodra die er is stuur ik jou en Ton van Boven een bericht en kunnen jullie testen.

[harryboer]

Top, ik ben benieuwd!

[harryboer]

Even een andere vraag, mijn DAO geeft sinds gistermiddag geen resultaat meer, en de log geeft dit weer:

Logging van bewerking "Optimaliseringsberekening zonder debug": Day Ahead Optimalisering versie: 2024.3.1 Day Ahead Optimalisering gestart op: 05-04-2024 09:21:43 Traceback (most recent call last): File "/root/dao/webserver/../prog/day_ahead.py", line 1906, in <module> main() File "/root/dao/webserver/../prog/day_ahead.py", line 1855, in main day_ah = DayAheadOpt("../data/options.json") ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/root/dao/webserver/../prog/day_ahead.py", line 80, in __init__ self.set_last_activity() File "/root/dao/webserver/../prog/day_ahead.py", line 96, in set_last_activity self.call_service("set_datetime", entity_id=self.last_activity_entity, File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py", line 27, in call_service return StateList( ^^^^^^^^^^ File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/models/state.py", line 45, in __init__ super().__init__(State(**s) for s in states) File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/models/state.py", line 45, in <genexpr> super().__init__(State(**s) for s in states) ^^^^^^^^^^ TypeError: State.__init__() got an unexpected keyword argument 'last_reported'

MariaDB draait, maar in de log zie ik dit:

2024-04-05 9:19:13 1131 [Warning] Aborted connection 1131 to db: 'homeassistant' user: 'homeassistant' host: '172.30.32.1' (Got an error reading communication packets)
2024-04-05 9:19:13 1129 [Warning] Aborted connection 1129 to db: 'day_ahead' user: 'day_ahead' host: '172.30.32.1' (Got an error reading communication packets)
2024-04-05 9:19:13 1153 [Warning] Aborted connection 1153 to db: 'homeassistant' user: 'homeassistant' host: '172.30.32.1' (Got an error reading communication packets)
2024-04-05 9:19:13 1151 [Warning] Aborted connection 1151 to db: 'day_ahead' user: 'day_ahead' host: '172.30.32.1' (Got an error reading communication packets)
2024-04-05 9:19:13 1136 [Warning] Aborted connection 1136 to db: 'homeassistant' user: 'homeassistant' host: '172.30.32.1' (Got an error reading communication packets)
2024-04-05 9:19:13 1134 [Warning] Aborted connection 1134 to db: 'day_ahead' user: 'day_ahead' host: '172.30.32.1' (Got an error reading communication packets)
2024-04-05 9:19:13 1157 [Warning] Aborted connection 1157 to db: 'homeassistant' user: 'homeassistant' host: '172.30.32.1' (Got an error reading communication packets)
2024-04-05 9:19:13 1015 [Warning] Aborted connection 1015 to db: 'day_ahead' user: 'day_ahead' host: '172.30.32.1' (Got an error reading communication packets)
2024-04-05 9:19:13 1017 [Warning] Aborted connection 1017 to db: 'homeassistant' user: 'homeassistant' host: '172.30.32.1' (Got an error reading communication packets)
2024-04-05 9:19:13 1155 [Warning] Aborted connection 1155 to db: 'day_ahead' user: 'day_ahead' host: '172.30.32.1' (Got an error reading communication packets)

Ik heb HA opnieuw opgestart ed maar geen succes. Enig idee wat dit zou kunnen zijn?

[corneel27]

zie het volgende issue:
#83
Ik ben er mee bezig, vandaag komt een fix.
Als je niet wilt/kunt wachten: tijdelijk HA downgraden

[harryboer]

Die had ik nog niet gezien, dank. Ik wacht het af.

[corneel27]

Er staat een nieuwe versie op github versie 2024.3.2, die het probleem oplost.

[harryboer]

Dat is snel! Er is ook een probleem met Entsoe prijzen, die worden ook niet geupdate. Zie dat dat ook gemeld wordt bij Entsoe integratie.

[corneel27]

Ik gebruik nordpool.
Zet in de instellingen:

...

  "prices": {
    "source day ahead" : "nordpool",

...

[harryboer]

Trouwens, zie nu dat dit alleen de dag van morgen is, vandaag ontbreekt.

[corneel27]

Sorry crosspost

[corneel27]

Ik zal binnenkort de "run" faciliteit uitbreiden zodat je bij het ophalen van de prijzen ook een start datum (met terugwerkende kracht) kunt instellen

[harryboer]

aha als dat het is, geen probleem, dan zal het vanaf morgen weer goed moeten staan.

[harryboer]

Ik zal m morgen nog wel in de gaten houden, wordt een mooie dag morgen op meerdere fronten!

[corneel27]

Dus de prijzen van morgen heb je binnen, maar de prijzen van vandaag mis je nog.

[corneel27]

Je kunt beter de prijzen bij Nordpool ophalen. Die zijn (bijna altijd) om 12:55 beschikbaar, maar helaas alleen van dezelfde dag.
Soms als de biedingentermijn wordt verlengd een of twee uur later, daarme ook altijd de prijzen ophalen om 13:55 , 14:55enz (zie voorbeeld bestand).

[corneel27]

Versie 2024.3.4 is uit.
Introductie van mogelijkheid om prijzen uit het verleden op te halen, zoals afgelopen week toen prijzen bij entsoe niet beschikbaar waren,
Zie CHANGELOG.md en DOCS.md

[corneel27]

Sorry het is versie 2024.3.3

[corneel27]

Versie 2024.3.7 staat als test klaar in de branche "addon".
Hierin is functionaliteit opgenomen om huishoudelijke apparatuur in te plannen (zie DOCS.md).
Je kunt deze installeren naast je productieversie om een en ander te testen.
Voeg een nieuwe addon toe en geeft als url mee: https://github.com/corneel27/day-ahead#addon
Als je nog vragen hebt hoor ik het graag.

[corneel27]

Je kunt het beste bij de instellingen in de addon die 5000 laten staan, maar op de addon-pagina van de addon kun jedan een andere poort instellen. Bij mij werkt dat uitstekend.
Dus:

En bij de "Config" van je instellingen blijft:
"dashboard": { "port": 5000 },

[harryboer]

Zo heb ik het ook gedaan, maar dat werkte dus niet, opnieuw geïnstalleerd maar bog steeds zelfde melding. Ook als ik de productieversie stopzet en de beta op poort 5000 zet wil het niet dus denk dat er iets anders aan de hand is? Ik heb trouwens soms wel eens dat als ik in de productieversie handmatig de optimalisatie berekening uitvoer dat na 15 sec ongeveer die melding ook komt.

[corneel27]

Dan denk ik dat er iets fout staat in je instellingen.
Heb je al in de logging van de addon zelf gekeken, dus op Instellingen/Add-ons/ en dan de addon- pagina en dan bij "logboek".

[harryboer]

Heb inmiddels geüpdatet naar versie 2024.3.8 en dat werkt, ik ga het testen!

[harryboer]

Dag Cees,

Al weer even geleden, maar ik loop tegen iets aan, er lijkt iets niet goed te gaan. Ik krijg geen resultaten meer, had het eerst niet door dus weet niet hoe lang dit al gaande is. Enig idee waar het mis gaat?

[corneel27]

Dank voor het melden van de fout.
Er zat inderdaad een fout die alleen optreedt als je meer dan 1 thuisbatterijen hebt (zoals bij jou).
Sorry: niet goed getest, ik neem het op in de CI (test-straat).
Binnenkort (morgen of overmorgen) komt er een nieuwe versie uit, waarin dit is opgelost.

[harryboer]

Ah top, dank!

…

On 4 Oct 2024, 00:08 +0200, Cees van Beek ***@***.***>, wrote: Dank voor het melden van de fout. Er zat inderdaad een fout die alleen optreedt als je meer dan 1 thuisbatterijen hebt (zoals bij jou). Sorry: niet goed getest, ik neem het op in de CI (test-straat). Binnenkort (morgen of overmorgen) komt er een nieuwe versie uit, waarin dit is opgelost. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[corneel27]

Zo juist is de nieuwe versie (2024.10.0) gepubliceerd op GitHub.
Die moet jouw probleem oplossen.
Laat me weten als er nog problemen zijn.

[harryboer]

Het gaat nu al wel een stuk beter, maar de prijzen via entsoe gaan nog niet goed. Dezelfde prijs wordt bij alle tijden herhaald. Zelf haal ik ze ook binnen in HA en dat gaat wel goed.

[harryboer]

[corneel27]

Dag Harry, ik heb het hier even getest.
Ik krijg dezelfde fout als jij, allemaal dezelfde uur waarde "79.12".
Ik duik er nu verder in.
Je kunt het beste (voorlopig) overschakelen op "nordpool": dus "source day ahead" : "nordpool",
Voor nordpool heb je geen api-key nodig!

[corneel27]

Ik heb het opgezocht op github.
De fout zit in de python-module die de data ophaalt bij entsoe.
De foutmelding staat ook op github.
EnergieID/entsoe-py#346.
De personen die die module onderhouden zijn met vakantie....
Dus het duurt nog wel even.
Het schijnt al vanaf 4 oktober te spelen.
Je kunt via het dashboard met terigwerkende kracht (per dag) de data ophalen bij nordpool.

[harryboer]

Er is wat veranderd in de afgelopen dagen bij entsoe en hoe ze de data beschikbaar stellen meen ik. De HA integratie was gelukkig binnen 24 u weer gefixt.

Ik heb nordpool nu ingesteld maar bij ophalen van nieuwe prijzen krijg ik de melding: Day ahead data already present. Zal morgen bij de nieuwe prijzen wel weer werken

[corneel27]

Je kunt het ophalen forceren door in het eerste veld achter het commando de datum in te vullen.

[harryboer]

Het werkt weer, dank weer voor je hulp!

[pkleingu]

© 2024: Apache 2.0 Day Ahead Optimizer version: 2024.10.6

Ook een vraag over installeren.
iK ben nieuw met "DAY AHEAD OPTIMIZER"
Ik heb een standaard supervisor installatie zonder extra database van de add on onder homeasisstant.
Maar ik blijf de volgende foutmeldingen krijgen:

2024-11-01 16:58:55 info: Day Ahead Optimalisering versie: 2024.10.6
2024-11-01 16:58:55 info: Day Ahead Optimalisering gestart op: 01-11-2024 16:58:55
2024-11-01 16:58:55 info: Day Ahead Optimalisatie gestart: 01-11-2024 16:58:55 taak: get_tibber_data
2024-11-01 16:58:55 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 2280, in
2024-11-01 16:58:55 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 2265, in main
2024-11-01 16:58:55 fout: File: /root/dao/prog/da_base.py, line 436, in run_task_function
2024-11-01 16:58:55 fout: File: /root/dao/prog/da_base.py, line 238, in get_tibber_data
2024-11-01 16:58:55 fout: File: /root/dao/prog/utils.py, line 110, in get_tibber_data
2024-11-01 16:58:55 fout: File: /root/dao/prog/db_manager.py, line 72, in init
Traceback (most recent call last):
File "/root/dao/prog/da_base.py", line 432, in run_task_function
getattr(self, run_task["function"])()
File "/root/dao/prog/da_base.py", line 238, in get_tibber_data
get_tibber_data()
File "/root/dao/prog/utils.py", line 110, in get_tibber_data
db_da = DBmanagerObj(db_dialect=db_da_engine, db_name=db_da_name, db_server=db_da_server, db_port=db_da_port,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/prog/db_manager.py", line 72, in init
raise ConnectionAbortedError
ConnectionAbortedError

dus ik mis:

=> /root/dao/webserver/app/static/data exist
info:root:Table "variabel" met inhoud gecreeerd.
info:root:Table "values" gecreeerd.
info:root:Table "prognoses" gecreeerd.
info:root:Table "variabel" geupdated.

[corneel27]

Dank voor het melden van de fout.
Ik heb hem hersteld, wordt nu weer getest.
Morgen komt een update beschikbaar (versie 2024.11.0).
Tot die tijd misschien het ophalen van tibber-data uitzetten?

[pkleingu]

Dat is snelle service, ik ben benieuwd, ben niet begonnen Day ahead.Dus dat ik na installatie geen
=> /root/dao/webserver/app/static/data exist
info:root:Table "variabel" met inhoud gecreeerd.
info:root:Table "values" gecreeerd.
info:root:Table "prognoses" gecreeerd.
info:root:Table "variabel" geupdated.

Krijg is geen probleem of had je dat net verholpen?

[corneel27]

Die fout ontstaat alleen bij het ophalen van Tibber data.
De rest werkt volgens mij gewoon.
Als dat niet zo is dan hoor ik het graag.

[corneel27]

Versie 2024.11.0 staat op github.
Je kunt je huidige installatie updaten:

• ga in HA naar Instellingen/Add-ons
• klik rechtsonder op "add-on winkel"
• klik via het puntjesmenu rechtsboven op "Controleer op updates"
• ga een scherm terug met de pijl linksboven
• klik op de tegel van DAO en je krijgt een update aangeboden
• In het wijzigingsoverzicht staat:

• Day Ahead Optimizer
  [V2024.11.0]
  Fixed a db-error when getting Tibber-data with the default sqlite-db

[corneel27]

Overigens:

=> /root/dao/webserver/app/static/data exist
info:root:Table "variabel" met inhoud gecreeerd.
info:root:Table "values" gecreeerd.
info:root:Table "prognoses" gecreeerd.
info:root:Table "variabel" geupdated.

Krijg je alleen in de logboek van installatie de addon bij de eerste keer installeren.
Die eerste logging kun je alleen via HA met veel moeite terughalen.

[pkleingu]

Hoi Corneel, Het werk allemaal, super bedankt voor de snelle service mvg Peter Op vr 1 nov 2024, 21:30 schreef Cees van Beek ***@***.***>:

…

Die fout ontstaat alleen bij het ophalen van Tibber data. De rest werkt volgens mij gewoon. Als dat niet zo is dan hoor ik het graag. — Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARBXMOSTOYNF435SAUJH6X3Z6PQHVAVCNFSM6AAAAABDOEOH4WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMJSGU3TQMA> . You are receiving this because you commented.Message ID: ***@***.***>