Vragen mbt optimalisatie resultaten

[soeter01]

Ik heb je add-on geïnstalleerd want precies waar ik naar op zoek was! Ben aardig op weg - dankzij de goede documentatie! - maar heb nog wel een paar vragen/opmerkingen die ik niet in de andere discussies heb kunnen vinden:

• de kosten berekening is me niet duidelijk. Runnen met debug laat het optimale resultaat zien met daarbij de kosten en profit. Wanneer ik deze bij elkaar optel is het resultaat anders dan in hetzelfde overzicht (zie bijgaand voorbeeld vd.txt). Mis ik hier wat?
• pv ac bij het vandaag report staat in Wh terwijl de HA entity die in config staat vermeld toch echt in kWh staat. Heb ik ook hier iets gemist?
• krijg regelmatig zwart scherm met melding: internal server error. Met name als optimalisatie strategie "minimaliseer consumptie" wordt gekozen. Soms door wat instellingen te veranderen draait de run wel. Weet iemand waardoor dit komt?

[corneel27]

Kosten berekening
Goed punt!
Uit jouw logging: Geoptimaliseerd, kosten met day ahead tarieven: -3.64
In deze berekening worden ook de "afschrijvingskosten" per kWh laden/ontladen meegenomen.
Verklaart dat het verschil?
Ik zal er nog een keer aan rekenen en verduidelijken in de documentatie.

pv ac in Wh
Kun je mij verduidelijken wel rapport je bedoelt.
Bij mij staat ie wel in kWh:

internal server error
Ook een goed punt!
Ik zie dit delaatste tijd ook regelmatig voorbij komen.
Waarschijnlijk is de default wait-time van mijn applicatiete kort om te wachten op de langer durende berekening bij "minimize consumption". Die laatste berekening gaat in twee stappen en kost dus extra rekentijd en overschrijdt dan de default wait-time.
Deze staat nu op 30 sec.
Ik zal deze in de volgende versie ophogen naar 120 sec (is in ieder geval lang genoeg).

[soeter01]

Hallo Cees, dank voor je snelle antwoord. Ik heb de cycle cost op 0 staan in de config (neem aan dat dit de afschrijvingskosten beïnvloed) dus denk niet dat dit het verschil kan verklaren.

Mbt de pv ac in Wh (zie Maar.. als ik de entity in de config even aanpas naar die van de accu, dan is alles wel in kWh. Ik ga nog even kritisch naar de entity voor de pv kijken...

Tenslotte nog iets waarover ik nadenk: feitelijk rekent het programma optimale inzet batterij uit binnen de randvoorwaarden, en schakelt te schakelen belastingen optimaal. Ik zorg er dan ook voor dat in mijn victron ems+batterij het ess setpoint zodanig wordt ingesteld dat de batterij het grid_feedin volgt dat je programma uitrekent. Echter het daadwerkelijke zonne vermogen schommelt nogal en als deze bv hoger is dan voorspelt, dan wordt er ongepland teruggeleverd. Zou het in dergelijke situaties zinvol zijn om dan het exces zon vermogen in de batterij te stoppen? Eea kan denk ik in HA worden gerealiseerd maar vraag me af of dit zinvol is. Wat vind jij?

mvg, Ronald

[corneel27]

Ja, de laatste versie van Home Assistant gaat heel slim om met de dimensie van de entities. Zo slim is DAO nog niet.
Ik ga ervanuit dat de dimensie van de entities in de rapportage-module altijd op kWh staat.

Ik heb nog geen tijd gehad om de berekening van de kosten/opbrengsten na te lopen, dus dat hou je nog van me tegoed!

Als je als strategie kiest "minimal consumption" dan zal DAO vaak berekenen dat er in een uur geen inkoop en geen teruglevering plaatsvindt.
Ik heb daarvoor expres een entity voorzien: "entity balance switch", die wordt in deze situatie op "on" gezet.
Ik heb er een helper (input boolean) aan gekoppeld.
Je kunt daar zelf een automation aan hangen (die getriggerd wordt als de state naar "on" gaat.
Als je je inkoopmeter in Victron hebt geconfigureerd dan kun je het door het ESS van Victron laten oplossen.
Ik heb een P1-reader aan mijn slimme meter hangen en die geeft alle info iedere seconde door aan HA.
De belangrijkste sensor daarvan is het momentane vermogen dat de slimme meter meet, want dat moet dan steeds naar nul worden geregeld door meer of minder uit de accu te halen.
Mijn automation ziet er als volgt uit:

alias: Balanceer feedin
description: ""
mode: single
triggers:
  - entity_id:
      - sensor.grid_power
    trigger: state
conditions:
  - condition: state
    entity_id: input_boolean.balanceer_grid
    state: "on"
actions:
  - data:
      entity_id: input_number.dao_setpoint_feedin_ess
      value: >-
        {{ (states('sensor.ess_vermogen_setpoint') | float(0) -
        (states('sensor.grid_power')|float(0) * 1) )| int(0) }}
    action: input_number.set_value

Kun je hiermee verder?

ps: In de nieuwe versie die nu op github staat heb ik de timeout op 60 sec gezet (was 30). Ik las verhalen op internet dat te hoge timeout weer andere problemen kan veroorzaken. Ik hoor graag als deze waarde nog te laag voor jou is.

[soeter01]

Het probleem met de omvormer eenheid is opgelost. Bleek dat hij in Wh in de HA dbase stond. Iets uit het verleden kennelijk waar je in bv HA's energiedashboard niets van merkt. Opgelost dmv nieuwe sensor.

Het verhogen van de timeout heeft geholpen. Geen zwarte schermen meer gehad! Dank.

Ik stuur het Victron ESS aan door vanuit HA het ESS setpoint te zetten. Als de entity balance switch aan staat zal dit set point 0 zijn en draait het ESS als normaal en automatisch terugleveren minimaliseren (er zit een victron energy meter in de meterkast die elke paar seconden het netto vermogen aan het ESS doorgeeft). Als deze switch uit staat wordt het ESS setpoint zodanig berekend dat de accu de door je dao add-on berekende grid_feedin volgt. Werkt prima en mijn accu volgt de SOC zoals door de add-on berekend. Vraag me alleen af wat te doen als de werkelijkheid anders is dan de voorspelling. Bij bv meer zon zal dan automatisch meer worden teruggeleverd. Zou de optimalisatie natuurlijk vaker kunnen uitvoeren of de berekening in HA zodanig aanpassen dat wanneer er meer zon is dan voorspelt, de accu sneller wordt opgeladen. Dit laatste ga ik eerst maar eens proberen.

Nog een paar ideeën. https://github.com/PetervVeen gebruikt in zijn add-on website energie.theexogent.nl om een meerdaagse prijsvoorspelling tot wel een week vooruit te krijgen. Wellicht kan dit worden gebruikt om de SOC aan het einde van de voorspelling te bepalen. Als de prijs trend omlaag is, een lage SOC en vice versa. E.e.a. kan dan dmv min/max soc_end_point in de optimalisatie worden meegenomen.

Een ander idee is ook afkomstig van https://github.com/PetervVeen: het gebruik van een zelflerend model om de basisconsumptie te voorspellen e.e.a. door gebruik te maken van de skforecast python library.

Ik ga zelf eens een poging wagen het eerste idee te implementeren in een local versie! Eerst mijn warmtepomp in de add-on aan de praat krijgen.

[corneel27]

Fijn dat de aanpassingen in 2024.10.4 voor jou ook werken!

Eerst een vraag om jouw situatie goed te begrijpen: Heb je je PV aangesloten via een mppt-controller op de dc-bar of zit je pv op ac achter de Victron op een AC-OUT?
Als DAO berekent dat het setpoint = 0 dan zal in beide gevallen het surplus aan pv-productie naar de accu gaan (zolang die niet vol is of een andere ingestelde ess-grens van Victron wordt bereikt. Mijn ervaring is dat de geprognoticeerde pv-productie bijna nooit meer dan 40% afwijkt van de werkelijke, maar meestal binnen de 10% afwijking blijft. Dus ik denk dat het in het algemeen wel zal meevallen. Je kunt het eerst even aankijken. Vanaf 22 maart volgend jaar gaan de day-ahead prijzen naar kwartier-waarden. Dat betekent dat de berekeningen ook ieder kwartier uitgevoerd gaan worden (in ieder geval het berekeningsinterval gaat naar een kwartier, ik ben dat nu aan het voorbereiden). Dan wordt een eventueel probleem makkelijker tussentijds bij te sturen.

Nog een paar ideeën. https://github.com/PetervVeen gebruikt in zijn add-on website energie.theexogent.nl om een meerdaagse prijsvoorspelling tot wel een week vooruit te krijgen. Wellicht kan dit worden gebruikt om de SOC aan het einde van de voorspelling te bepalen. Als de prijs trend omlaag is, een lage SOC en vice versa. E.e.a. kan dan dmv min/max soc_end_point in de optimalisatie worden meegenomen.

Het idee is prima, maar ik heb een tijdje theexogent.nl gevolgd en ben niet onder de indruk van de kwaliteit van de voorspellingen. Probleem is dat de prijzen van (over)morgen niet alleen afhankelijk zijn van het weer in NL(zoals hij aangeeft). Maar ook van het weer in de omringende landen, het aan/uit staan van goedkope kerncentrales in Frankrijk en de beschikbaarheid van interconnections naar buurlanden zijn allemaal van invloed.
Er zijn m.i. twee mogelijkheden:

1. Jij bouwt zelf iets in HA op basis van de voorspellingen van https://energie.theoxygent.nl/ en zet daarmee die "eind-entities"
2. DAO de prijzen van vandaag cq morgen naar morgen cq overmorgen en verlengt daarmee de planningshorizon naar 36 uur. Dit laatste is gebaseerd op de waarneming dat de prijzen een grote mate reproductie hebben (afgezien van het weekend).

Een ander idee is ook afkomstig van https://github.com/PetervVeen: het gebruik van een zelflerend model om de basisconsumptie te voorspellen e.e.a. door gebruik te maken van de skforecast python library.

Als je alle belangrijke en beinvloedbare componenten van je verbruik/productie meet en opslaat via het energy-dashboard van HA (grid, accu, pv, ev, wp/boiler, huishoudelijke apparatuur) kun je achteraf per uur je baseload berekenen (zie reports/balans).
Dat doet DAO ook met de berekening calc_baseload. Dan wordt per dag van de week over een instelbare periode bijv 8 weken) de gemiddelde baseload per uur berekend en opgeslagen (dan moet je natuurlijk die data wel in je ha-database hebben zitten). Als je nu in je instellingen zet "use_calc_baseload": "True", dan worden de berekende baseloads gebruikt. Ik heb met deze methodiek erg goede ervaringen, dus ik ben nog niet overtuigd om over te stappen op skforecast.

[soeter01]

De PV zit op AC-in. Tot nu toe heb ik het ESS setpoint elke 10s herberekend als de daadwerkelijke consumptie of PV productie anders zijn dan voorspelt door de add-on. Dan zorgt het ESS automatisch dat de batterij SOC de berekening uit de add-on volgt.

Ik ga dit nu wijzigen zdd het ESS setpoint alleen wordt aangepast als de add-on een nieuwe optimalisatie heeft gedaan (elk uur). Dan zorgt het ESS er automatisch voor dat als er meer zon is dan voorspelt het meerdere de accu in gaat en vice versa. Iets dergelijks geldt dan ook voor de consumptie. Laat nog even weten hoe dit werkt.

Je opmerkingen mbt theexogent.nl en consumptie forecasting snap ik en parkeer ik voorlopig. Eerst de wp aan de praat krijgen! Zie onderstaand.

[corneel27]

Wat betreft je wp: welk merk/type heb jij en hoe kun je beinvloeden vanuit HA?

[soeter01]

Ik heb Daikin Altherma wp gekoppeld aan vloerverwarming voor hele huis. Watertemperatuur is middels stooklijn aan buitentemp gekoppeld. Ik kan deze vanuit HA aan/uitzetten. Vermogen of stooklijn kan ik niet regelen vanuit HA. Ik heb op basis van historische data wat grafiekjes gemaakt

COP als functie van buitentemperatuur :

Vermogen als functie van buitentemperatuur:

COP als functie van vermogen:

Deze laatste grafiek heb ik in de config van de dao-addon gezet (stages). Heb ook nog een sensor toegevoegd die het reeds geleverde thermisch vermogen meet (moet denk ik in de config mogelijk zijn te specificeren?).

De add-on runt op zich zonder fouten maar geloof niet dat ik de wp aan/uit kan zetten (er is geen entity voor zo te zien).

Aangezien ik het vermogen niet kan regelen en ook geen stooklijn kan verschuiven zou in mijn geval de add-on op basis van de graaddagen benodigde thermische energie moeten berekenen (gebeurt al denk ik) en dan op basis van de voorspelde buitentemperatuur kunnen bepalen wat het vermogen en COP worden. Dan kan de benodigde elektrische energie worden berekend en hoe lang de wp moet draaien.

Is dit in huidige implementatie al mogelijk? Hoe zie jij dit?

[corneel27]

Je hebt je huiswerk grondig gemaakt.
Ik zou bijna zeggen dit moet gaan werken ( misschien moet ik net wat meer berekeningsresultaten naar entities sturen).
Ik kan nu helaas niks uitzoeken want mijn laptop wordt gerepareerd ( tot eind deze week, weekend).
Kun je zolang wachten?

[soeter01]

Zeker! Ga inmiddels je code bestuderen om te zien hoe het nu eigenlijk werkt!

[soeter01]

Ik heb inmiddels de warmtepomp incl. de optimalisatie toegevoegd aan de geforkte versie van je add-on. Voorspelde buitentemp wordt gebruikt om vermogen en cop te voorspellen. De optimalisatie vergelijkingen zijn ook aangepast. Zo te zien werkt het behalve dat het niet koud genoeg is om echt te testen... Ik zal hier nog wat verder aan optimaliseren: de uitvoer naar HA heb ik nog niet aangepast en zal ik binnenkort doen. Kijk maar even of je het wat vindt.

[corneel27]

Inmiddels is mijn laptop weer gerepareerd en weer thuis.

Eerst (en wellicht ten overvloede) heb je deze HA-integratie gezien: https://github.com/jwillemsen/daikin_onecta

Ik heb je fork bekeken, maar deze is zo specifiek voor jouw installatie, die kan nooit zo worden "gemerged" met de main-branche.

Als je zelf alleen verder wil gaan met de fork: prima, maar dat heeft wel als nadeel dat het overnemen van toekomstige aanpassingen en bugfixes in de main-branche niet makkelijk is.

Het beste alternatief is dat we samen kijken hoe we jouw aanpassingen kunnen integreren in de main-branche.
Dan kunnen meer wp-eigenaren gebruik maken van deze tool.
Hoe kijk jij daar tegenaan?

Ik kan wel eenvoudig meer berekende resultaten naar een HA-entity sturen. Bijvoorbeeld aan/uit van de wp (input_boolean) of nog beter het berekende vermogen van de wp voor het eerstkomende uur (input_number) zetten.

De add-on runt op zich zonder fouten maar geloof niet dat ik de wp aan/uit kan zetten (er is geen entity voor zo te zien).

Zoals gezegd dit is eenvoudig te maken.

Aangezien ik het vermogen niet kan regelen en ook geen stooklijn kan verschuiven zou in mijn geval de add-on op basis van de graaddagen benodigde thermische energie moeten berekenen (gebeurt al denk ik) en dan op basis van de voorspelde buitentemperatuur kunnen bepalen wat het vermogen en COP worden. Dan kan de benodigde elektrische energie worden berekend en hoe lang de wp moet draaien.

Dit heb je nu in je fork geimplementeerd.
Mijn idee zou zijn:
Die formules verplaatsen we naar een of meer template-sensoren in HA. De input voor de formules komt beschikbaar via dao in input_numbers en/of rest-api-sensoren (nader in overleg te bepalen)
De waarde van de template sensor(en) in HA worden door DAO gebruikt voor de optimalisatieberekening.
Het resultaat gaat terug naar HA

Ben benieuwd naar je mening.

[soeter01]

Inmiddels is mijn laptop weer gerepareerd en weer thuis.

Fijn dat je PC het weer doet!

Eerst (en wellicht ten overvloede) heb je deze HA-integratie gezien: https://github.com/jwillemsen/daikin_onecta

Helaas heeft mijn daikin lucht-water wp geen onecta interface. Er zit gewoon een relais 'in serie' met de thermostaat die de wp aanstuurt. Alle sensor waarden komen direct uit de serie interface naar HA.

Ik heb je fork bekeken, maar deze is zo specifiek voor jouw installatie, die kan nooit zo worden "gemerged" met de main-branche.

Ja, goed punt en goed idee om meer algemener te maken. Ik heb nu wel al entiteiten gemaakt die 1) optimalisatie uitvoeren als er überhaupt warmte vraag is (thermostaat status wordt ingelezen vanuit HA) en 2) de warmtepomp in HA daadwerkelijk aanzetten. middels een input_boolean helper. Dat werkt op zich prima.

Inderdaad kunnen de COP en vermogen formule's in HA worden geïmplementeerd. Moet nog wel de voorspelde buitentemperatuur uit de add-on worden gehaald of direct HA worden bepaald.

Heb de boel in m'n fork inmiddels wat opgeruimd zdd het wat leesbaarder is. De config is nu ook aangepast (de coëfficiënten staan nu in de config):

"heating": {
"heater present": "True",
"degree days factor": 4.34,
"cop coeff": [0.0136, 0.0859, 3.5],
"power coeff": [-0.002, -0.0885, 1.9524],
"entity hp switch": "input_boolean.hp", #HA zet de wp aan als de optimalisatie dat nodig vindt
"entity hp enabled":"sensor.warmtepomp_enable", #HA entity die bepaald of er warmtevraag is
"entity hp heat produced": "sensor.daily_heat_production_heating" #HA entity met de sensor voor warmte al geproduceerd
},

Met de coëfficiënten voor de formules in de config is het iets algemener hoop ik, als tenminste de warmtepomp van anderen ook op een vast vermogen draait als functie van de buitentemperatuur (zou je op zich wel verwachten). Anders kunnen we wellicht verschillende typen warmtepompen definiëren. Een lucht-lucht warmtepomp heeft ook een COP als functie van de buitentemperatuur maar ziet er iets anders uit (= andere coefficienten).

Ik ga komende tijd eens kijken of het überhaupt lekker werkt (geloof dat het wat kouder wordt zodat de wp weer eens aan gaat!). No doubt zijn verdere verbeteringen nodig. Misschien het meenemen van de solar radiation voorspelling bij het berekenen van de energie die de warmtepomp moet leveren. Immers bij veel zon is er minder van de warmtepomp nodig. Iets dergelijks geldt voor windsnelheid/richting... Maar dat maakt het wel wellicht erg specifiek/moeilijk inregelbaar.

Lang verhaal maar prima om samen nog wat verder te ontwikkelen zodat het ook voor anderen bruikbaar is!

[corneel27]

Ik denk en zie dat we er wel samen uit gaan komen.
Wel goed om eerst ook de koudere dagen af te wachten en kijken of jouw insteek lekker loopt.
In afwachting daarvan ga ik sowieso de volgende elementen van jou overnemen:

• sensor/entity die aangeeft of de wp aan/uit staat
• graaddag berekening uitsplitsen in twee delen:
  • ophalen en berekenen gemiddelde temperatuur
  • berekening graaddagen (met gem temperatuur als parameter)

Overigens heat produced zit er al in : heat_produced = float(self.get_state("sensor.daily_heat_production_heating").state)

Verder zullen er dan - denk ik - twee routes komen:

1. de bestaande route die ook optimaliseert met modulerend vermogen
2. een nieuwe route met een berekend vermogen (jouw voorstel)

[corneel27]

Overigens heat produced zit er al in : heat_produced = float(self.get_state("sensor.daily_heat_production_heating").state)

Sorry, het zit er "hard coded" in, moet nog wel via een instelbare entity.

[corneel27]

Ik heb inmiddels het eerste stuk van de heatpump-code aangepast met jouw code:

        if self.heater_present:
            entity_hp_enabled = self.config.get(["entity hp enabled"], self.heating_options, None)
            hp_enabled = ((entity_hp_enabled is None) or
                          (self.get_state(entity_hp_enabled).state == "on"))
            if not hp_enabled:
                logging.info("Geen warmtepomp vraag - warmtepomp wordt niet ingepland")
        else:
            hp_enabled = False
        if not hp_enabled:
            c_hp = [model.add_var(var_type=CONTINUOUS, lb=0, ub=0)
                    for _ in range(U)]  # elektriciteitsverbruik in kWh/h
            p_hp = None
            h_hp = None
        else:
            logging.info(f"Warmtepomp wordt ingepland")
            degree_days = self.meteo.calc_graaddagen(weighted=True)
            if U > 24:
                degree_days += self.meteo.calc_graaddagen(
                    date=dt.datetime.combine(dt.date.today() + dt.timedelta(days=1),
                                             dt.datetime.min.time()),
                    weighted=True)
            logging.info(f"Gewogen graaddagen: {degree_days:.1f} K.day")   # heat factor kWh th / K.day
            degree_days_factor = self.heating_options["degree days factor"]
            entity_heat_produced = self.config.get(["entity hp heat produced"],
                                                   self.heating_options,
                                                   None)
            if entity_heat_produced is not None:
                heat_produced = float(self.get_state(entity_heat_produced).state)
            else:
                heat_produced = 0
            heat_needed = max(0.0, degree_days * degree_days_factor - heat_produced)  # heat needed
            logging.info(f"Reeds geproduceerde warmte: {heat_produced:.1f} kWh")
            logging.info(f"Benodigde warmte: {heat_needed:.1f} kWh")

Hiermee ben ik nu op het punt waar onze wegen zich "splitsen".
Zal ik daar een instelling van maken?
Bijvoorbeeld : "adjustment" : met keuze uit "on/off" / "power" / "heating curve"
Dan hang ik jouw code onder de instelling "on/off"

Verder stel ik voor om de avg_temp weg te schrijven naar een (instelbare) input_number in HA en dan de cop te berekenen met een template sensor:

{% set outside_temp = states('input_number.avg_temp') | float %} 
"{{min(max(0.0136*outside_temp*outside_temp+0.0859*outside_temp+3.5,3.25),6)}}"

Zal ik een branche aanmaken waar we alletwee al onze aanpassingen bij onderbrengen.
Zodra we alletwee akkoord zijn met alle aanpassingen kunnen deze branche weer pushen/mergen met de main-branche.

Ik hoor graag wat je hiervan vindt.

[soeter01]

Dat lijkt me helemaal goed. Dank je alvast. Neem aan dat je de cop en power dan als input vanuit HA opneemt? Kijk ook even naar de gewogen graaddagen berekening aub. Zat een bugje in dacht ik (april-sep periode: or waar het and moest zijn en dacht dat een compensatie van 0.8 (ipv 0.9) gebruikelijker was). In mijn versie had ik dat reeds aangepast.

Als je het hebt aangepast ga ik het testen in mijn situatie en zien hoe goed het in de praktijk werkt.

Zal off-line ook kijken of het verstandig is minimale duur van de warmtepomp als constraint op te nemen. Nu kan in theorie de warmtepomp elk uur worden aan/uitgeschakeld. Lijkt me niet een groot praktisch probleem. Maar als in 2025 naar kwartier prijzen wordt overgeschakeld lijkt het me sowieso nodig. Een warmtepomp per kwartier in/uitschakelen lijkt me niet verstandig!

[corneel27]

Ik heb je uitgenodigd als "Collaborator" voor mijn repository
Ik heb een branche "develop" gemaakt, daar staan mijn wijzigingen tot nu toe in.
Je kunt deze lokaal clonen en aanpassen. Ik moet nog wel een paar regels maken/uitvinden zodat we elkaars werk reviewen voordat het wordt gemerged met de develop branche.

[corneel27]

Ik moet nog wel een paar regels maken/uitvinden zodat we elkaars werk reviewen voordat het wordt gemerged met de develop branche.

Het wordt toch iets anders; zowel jij als ik maken van de develop-branche eigen develop-branche bijv. develop_soeter (kan evt ook als fork onder jouw account) en develop_cees. Die klonen we lokaal, maken daar onze aanpassingen in en pushen onze aanpassingen naar onze eigen develop-branche. Als we "klaar" zijn of vinden dat het gereviewed moet worden maken we een pull-request naar de develop-branche die dan door de ander gereviewd en approved moet worden voordat deze wordt gemerged met de develop-branche.
Kan jij hiermee leven?

[soeter01]

Ik heb je uitgenodigd als "Collaborator" voor mijn repository

Dank en aanvaard

Niet zo bekend met github... Als ik het goed begrijp:

• ik maak een develop branch onder mijn eigen account en vul die in 1e instantie met jouw develop versie (of zal ik de laatste release nemen?)
• ik maak ook een develop_ronald onder mijn eigen account en vul die in 1e instantie met dezelfde versie. Hierin maak ik aanpassingen om mee te testen. Als ik tevreden ben, dan push naar mijn eigen develop branche en dan kun jij reviewen voordat hij naar jouw develop branche gaat en vandaar naar de main release

Heb ik dat zo'n beetje goed begrepen?

Mijn huidige aanpassingen vwb de warmtepomp lijken goed te werken. Ik blijf nog even testen.

Ik zie de warmtepomp aanpassingen nog niet in je develop versie zitten. Zal ik die aanbrengen en testen in mijn locale develop_ronald versie conform wat we eerder besproken hebben?

[corneel27]

Leuk dat je mee wilt werken op deze manier!
Er is maar een develop-branche voor jou nodig, of "develop_ronald" onder mijn account, of de fork die je al hebt onder je eigen account. Je mag zelf kiezen.
In beide gevallen moet je eerst de huidige aanpassingen in de (wat ik maar even noem) hoofd-develop-branche (dit is de branche met de naam develop onder mijn account) mergen naar die develop-branche van jou.
Als je - voorlopig - klaar bent met je aanpassingen kun je een pull-request doen naar de develop-branche. Die aanpassingen worden dan door mij gereviewd en na goedkeuring gemerged met de develo-branche.
Omgekeerd, mijn aanpassingen in develop_cees stuur ik ook met een pull request naar develop en die moeten dan door jou worden gereviewed.
Stuur wel een email of een bericht in deze discussie zodat we weten dat er een pr (pull request) wacht.
Als alles klaar is en goed werkt zet ik het of in de addon-branche (hier testen nog een paar mensen alles) of ik zet het gelijk in de main-branche.
Alle aanpassingen van versie 2024.11.0 heb ik al in mijn lokale versie van develop_cees staan.
Ik heb nog niks van onze aanpassingen in de develop gezet. Ik wou eerst een reactie van jou dat je akkoord bent met mijn voorgestelde aanpak.

[soeter01]

ok ik ga het proberen! Heb de komende week wel even tijd om te kijken of me dit lukt.

[corneel27]

Prima!
Nou dan ga ik vanavond of morgen mijn aanpassingen in "develop_cees" zetten. Ik maak dan een pull_request naar "develop" en dan krijg jij een verzoek om een review te doen op mijn aanpassingen.
Pas als jij mijn aanpassingen hebt goedgekeurd wordt de pull request gehonoreerd (tenminste zo heb ik het ingesteld) en wordt mijn code gemerged/doorgezet naar "develop".
Schroom niet om op- of aanmerkingen op mijn code te maken. We moeten het samen eens zijn.

[soeter01]

Ik probeer de optimalisatie mbt de accu te begrijpen. Ook omdat ik soms negatieve kosten krijg terwijl er niets wordt teruggeleverd.

In de cost functie zie ik: ... (opt_low_level[b] - soc_low[b][u]) * 0.0025 ... - lijkt ervoor te zorgen dat de soc_low in de buurt blijft van de 'optimale soc low'. Maar begrijp niet waarom dit nodig is? Ook de vaste prijs van 0.0025 begrijp ik niet

Ook zie ik in de cost functie: .. (soc_mid[b][0] - soc_mid[b][U]) * one_soc[b] * eff_bat_to_dc[b]* avg_eff_dc_to_ac[b] * p_bat

Kun je hier ook wat licht op schijnen? Wat betekent soc_mid? En de prijs van de batterijstroom is bv toch niet perse de gemiddelde inkoop prijs? Enfin, hoop dat je dit kunt toelichten - wil het ook graag begrijpen! Alvast dank.

[corneel27]

Hier kom ik later vandaag of morgen op terug.
Ik ben af en toe een beetje druk.

[corneel27]

In de cost functie zie ik: ... (opt_low_level[b] - soc_low[b][u]) * 0.0025 ... - lijkt ervoor te zorgen dat de soc_low in de buurt blijft van de 'optimale soc low'. Maar begrijp niet waarom dit nodig is? Ook de vaste prijs van 0.0025 begrijp ik niet

Hier was ik een jaar of wat terug mee aan het experimenteren, omdat bij mij onder "optimale soc low" de spanning van de cellen uit elkaar begon te lopen. Dus alleen als het heel voordelig was mocht hij daaronderkomen. Het is allemaal niet goed uitontwikkeld. Bij mij staan beide waarden nu op 17,5% en dat werkt goed. Ik denk dat ik dat stuk code er maar een keer uit ga gooien. Volgens mij werkt niemand ermee.

Ook zie ik in de cost functie: .. (soc_mid[b][0] - soc_mid[b][U]) * one_soc[b] * eff_bat_to_dc[b]* avg_eff_dc_to_ac[b] * p_bat

Dit is wel een essentieel stuk code.
Om goed zicht te krijgen op de totale kosten/opbrengsten moet je de toename/afname van de energieinhoud van de accu meenemen. Waardeer je die te laag: dan gaat hij hem snel leegtrekken en niet vullen bij lage prijzen. Waardeer je die te hoog dan gaat hij hem opladen en niet gebruiken bij hoge prijzen.
Uiteindelijk bleek de gemiddelde inkoopprijs een goede maat om de inhoud van de accu te waarderen.

soc_mid is de inhoud van de accu in procenten gemeten vanaf soc_low:

        for b in range(B):
            for u in range(U + 1):
                model += soc[b][u] == soc_low[b][u] + soc_mid[b][u]
            model += soc[b][0] == start_soc[b]

Als ik de code weer eens ga opschonen kan ie er waarschijnlijk uit.
Want bijvoorbeeld in de cost functie wordt de eindwaarde van de begin-waarde afgetrokken,
dus kun je net zo goed met soc[b][u] rekenen.
Dat krijg je dus met "oude" code.

[soeter01]

Hier was ik een jaar of wat terug mee aan het experimenteren, omdat bij mij onder "optimale soc low" de spanning van de cellen uit elkaar begon te lopen. Dus alleen als het heel voordelig was mocht hij daar onderkomen. Het is allemaal niet goed uitontwikkeld. Bij mij staan beide waarden nu op 17,5% en dat werkt goed. Ik denk dat ik dat stuk code er maar een keer uit ga gooien. Volgens mij werkt niemand ermee.

Ja dat maak het wellicht wat duidelijker.

Om goed zicht te krijgen op de totale kosten/opbrengsten moet je de toename/afname van de energieinhoud van de accu meenemen.

Ja dat is zo. Maar zie toch soms dat de optimalisatie naar lage soc of hoge soc streeft.

Overweeg om de waarde van de batterij energie uit te rekenen en die te gebruiken. Dat lijkt op eerste gezicht niet zo makkelijk - je hebt al snel een niet lineaire vergelijking. Ook heb je te maken met zonneopslag die de waarde van de energie van de batterij verminderd. Enfin, hier ga ik eens verder over nadenken. Ik heb inmiddels een stand-alone python programmaat je op de pc draaien met de optimalisatie vergelijkingen uit je add-on zodat ik makkelijk kan experimenteren. Respect voor je code, het zit knap in elkaar! Mocht ik toch nog wat 'slims' bedenken dan laat ik je het weten.

[corneel27]

Je kunt natuurlijk altijd zelf spelen met deze twee instellingen:

     "entity min soc end opt": "input_number.min_soc_einde_opt",
     "entity max soc end opt": "input_number.max_soc_einde_opt",

Ik heb ook alles geinstalleerd (gekloond) op een linux-laptop (ik heb geen windows).
Ik werk met PyCharm als ide (de gratis versie).
Daar ben ik heel tevreden mee.
Maar je kunt natuurlijk ook kiezen voor iets anders (VS-code schijnt populair te zijn).

[corneel27]

Ik heb al mijn aanpassingen gepushed naar "develop_cees" en ik heb een pull request gemaakt naar "develop".
Die wacht nu op een review van jou (er staan er twee, maar die tweede is een kleine test van mijn zoon Stijn).
Het gaat om deze:

[soeter01]

ok dan zal ik hiervan een copy maken in develop_ronald onder mijn eigen account. eens kijken of me dit lukt.

[soeter01]

ik heb nu een copy van jouw develop_cees onder soeter01/develop_ronald. Kun je even checken of dit zo goed is gegaan? Dan zal ik eventuele wijzigingen daar aanbrengen.

[soeter01]

correctie: ik heb je develop branch gekopieerd naar develop_ronald

[soeter01]

correctie: ik heb je develop branch gekopieerd naar develop_ronald

pull request approved.. zodra je develop hebt aangepast (of gaat dat automatisch?) zal ik mijn code in minn develop branche toevoegen zodat jij kunt kijken.

[corneel27]

Ik zie dat je de PR hebt goedgekeurd.
De "normale" gang van zaken is nu dat jij "develop" pulled naar develop_ronald op jouw account (zo te zien heb je dat gedaan, maar met de versie voor de merge met de PR).
Dus je kunt het beste de branche develop_ronald verwijderen en een nieuwe aanmaken vanuit develop.
Dan kun jij daarin jouw wijzigingen/aanvullingen aanbrengen en een PR naar develop doen.
Ik merge jouw commentaar in develop naar develop_cees en ga er mee aan de gang.
Als ik daarmee klaar ben doe ik ook een PR.
Dit kunnen we eventueel een paar keer herhalen tot we het eens zijn en dan gaat "develop" naar "main" of "addon" (Ton van Boven test ook altijd een nieuwe addon-branche voordat er iets naar main gaat).
Akkoord?

[soeter01]

OK

[corneel27]

Er was toch nog iets fout gegaan.
Jij had de pull requets "approved" en daarna "closed", maar deze was nog niet gemerged met "develop".
Ik heb zojuist de PR opnieuw geopend en toen de door jou goedgekeurde wijzigingen in "develop_cees" gemerged met "develop".
Nu kun jij een nieuwe branche/fork maken van de develop-branche.

[corneel27]

Dank voor het melden.
Je mag zelf kiezen of je een issue wil aanmaken of niet.

Ik heb het even getest:
http://192.168.178.36:5000/api/report/cost/deze_maand
Ik kreeg geen foutmelding:

{ "message":"Success", "recorded": [{"time":"2024-11-01 00:00","value":2.9177308588},{"time":"2024-11-02 00:00","value":2.1411242466},{"time":"2024-11-03 00:00","value":3.5530767944},{"time":"2024-11-04 00:00","value":2.839934873},{"time":"2024-11-05 00:00","value":6.3515328031},{"time":"2024-11-06 00:00","value":8.4631861977},{"time":"2024-11-07 00:00","value":7.4632977871},{"time":"2024-11-08 00:00","value":4.0252623633},{"time":"2024-11-09 00:00","value":4.6513873525},{"time":"2024-11-10 00:00","value":2.9267449547},{"time":"2024-11-11 00:00","value":3.2763508634},{"time":"2024-11-12 00:00","value":6.1520058089},{"time":"2024-11-13 00:00","value":5.4675827712},{"time":"2024-11-14 00:00","value":5.6737153344},{"time":"2024-11-15 00:00","value":5.0632511545}], "expected" : [] }

Wil je het nog eens proberen en dan de laatste paar honderd regels (vanaf het begin van de fotmelding) van het add-on logboek kopieren ? Het logboek is bereikbaar via Instellingen,Add-ons/DAO-add-on en dan rechts boven op de informatiepagina, of op je mobiel onderaan.
Krijg je wel een grid-maandrapport via het dashboard?

[soeter01]

Wil je het nog eens proberen en dan de laatste paar honderd regels (vanaf het begin van de fotmelding) van het add-on logboek kopieren ? Het logboek is bereikbaar via Instellingen,Add-ons/DAO-add-on en dan rechts boven op de informatiepagina, of op je mobiel onderaan.

Helaas werkt niet. Log:
2024-11-17 11:57:26,250 ERROR dao.webserver.app MainThread : Exception on /api/report/cost/deze_maand [GET]
Traceback (most recent call last):
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1473, in wsgi_app
response = self.full_dispatch_request()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 882, in full_dispatch_request
rv = self.handle_user_exception(e)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 880, in full_dispatch_request
rv = self.dispatch_request()
^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 865, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/webserver/../../dao/webserver/app/routes.py", line 389, in api_report
result = report.get_api_data(fld, periode, cumulate=cumulate)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/webserver/../../dao/prog/da_report.py", line 1397, in get_api_data
df = df_grid[['time', field, "datasoort"]].copy()
~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4108, in getitem
indexer = self.columns._get_indexer_strict(key, "columns")[1]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/base.py", line 6200, in _get_indexer_strict
self._raise_if_missing(keyarr, indexer, axis_name)
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/base.py", line 6252, in _raise_if_missing
raise KeyError(f"{not_found} not in index")
KeyError: "['datasoort'] not in index"

[corneel27]

Ik ben eerst maar eens diep in de rapportage-code gedoken.
Het lijkt erop dat ik in een situatie ben vergeten om de "datasoort" toe te voegen.
Voordat ik het ga aanpassen wil ik graag bij jou checken of die situatie zich bij jou voordoet:
Klopt het dat je geen klant van Tibber bent of dat je niet dagelijks de verbruiks/productiedata bij Tibber ophaalt?
Als dat zo is dan ik deze fout waarschijnlijk makkelijk herstellen.
Ben benieuwd naar je reactie.
ps. uiterlijk vanavond kijk ik naar je pull-request.

[soeter01]

Wel klant tibber maar ik haal geen tibber data op.

[soeter01]

ps. uiterlijk vanavond kijk ik naar je pull-request.

Geen haast!

[corneel27]

Nog even een gedachte..: in dat geval geeft een maand/jaar overzicht niet meer makkelijk het daadwerkelijke verbruik etc tot nu aan. Maw als je alleen naar recorded kijkt zie je de gegevens t/m gisteren. Kan ook, net als tibber laat zien.

Dan probeer ik het zo te maken dat voor deze versie als interval != "uur" alleen "recorded" data worden getoond bij de api-call.
Maar dezelfde function (get_grid_data) wordt ook gebruikt voor "reports" in het dashboard en daar moet ie ook blijven werken (dat doet ie niet met jouw eerste oplossing):

[soeter01]

Wat mij betreft hou je het simpel: api en via dashboard zelfde info. Wel zo duidelijk! Had je trouwens start met documentatie gemaakt? Zal ik het on/off wp deel dan documenteren. Heb maandag pas weer tijd… Op vr 6 dec 2024 om 00:04 schreef Cees van Beek ***@***.***>

…

Nog even een gedachte..: in dat geval geeft een maand/jaar overzicht niet meer makkelijk het daadwerkelijke verbruik etc tot nu aan. Maw als je alleen naar recorded kijkt zie je de gegevens t/m gisteren. Kan ook, net als tibber laat zien. Dan probeer ik het zo te maken dat voor deze versie als interval != "uur" alleen "recorded" data worden getoond bij de api-call. Maar dezelfde function (get_grid_data) wordt ook gebruikt voor "reports" in het dashboard en daar moet ie ook blijven werken (dat doet ie niet met jouw eerste oplossing): afbeelding.png (view on web) <https://github.com/user-attachments/assets/30384ebb-0d44-4f6b-90fe-8da60ede4092> — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BIJIAGMUUOCLEVYB7UBT2EDLZBAVCNFSM6AAAAABP7LYGTWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBXHA3TMMI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[soeter01]

Liep nog tegen een bugje aan denk ik. Als ik de balans rapporteer staan er geen waarden voor uur 0 gerapporteerd voor de accu, wp en ev. Hierdoor is de baseload op uur 0 en de baseload berekening ook niet correct. De totalen kloppen dan ook niet. ha energy dashboard en de relevante entities laten wel de goede waarden zien. Verbruik en productie gaan wel helemaal goed. Herken je dit? Of heb ik dat zelf aangericht met mijn aanpassing in da_report? [image: 05818e68-9019-4e3a-a4a9-8cc801067a3f.png] Op vr 6 dec 2024 om 00:04 schreef Cees van Beek ***@***.***>:

…

Nog even een gedachte..: in dat geval geeft een maand/jaar overzicht niet meer makkelijk het daadwerkelijke verbruik etc tot nu aan. Maw als je alleen naar recorded kijkt zie je de gegevens t/m gisteren. Kan ook, net als tibber laat zien. Dan probeer ik het zo te maken dat voor deze versie als interval != "uur" alleen "recorded" data worden getoond bij de api-call. Maar dezelfde function (get_grid_data) wordt ook gebruikt voor "reports" in het dashboard en daar moet ie ook blijven werken (dat doet ie niet met jouw eerste oplossing): afbeelding.png (view on web) <https://github.com/user-attachments/assets/30384ebb-0d44-4f6b-90fe-8da60ede4092> — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BIJIAGMUUOCLEVYB7UBT2EDLZBAVCNFSM6AAAAABP7LYGTWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBXHA3TMMI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[corneel27]

Nee, herken ik niet! Bij mij (met jouw versie als rc3) gaat alles goed, dus het kan niet aan jouw wijzigingen liggen.
Als je bij jou de wijzigingen aan da_report terugzet. Gaat het dan ook fout?
Ik zie niet zo snel waarom het bij jou fout zou kunnen gaan
Welke database engine gebruik jij?

[soeter01]

Ik gebruik de standaard ha database. Ga nog even spitten... Op za 7 dec 2024 om 16:31 schreef Cees van Beek ***@***.***>:

…

Nee, herken ik niet! Bij mij (met jouw versie als rc3) gaat alles goed, dus het kan niet aan jouw wijzigingen liggen. Als je bij jou de wijzigingen aan da_report terugzet. Gaat het dan ook fout? Ik zie niet zo snel waarom het bij jou fout zou kunnen gaan Welke database engine gebruik jij? — Reply to this email directly, view it on GitHub <#130 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BIJMSRMKT7CXMEMRFZYD2EMIEZAVCNFSM6AAAAABP7LYGTWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBZGQ3DKNA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[corneel27]

Ik hoor graag of de nieuwe versie bij jou nog problemen veroorzaakt. Zo ja dan ga ik een kopie maken van de HA-database naar Sqlite en daarmee testen/debuggen.

[soeter01]

Ik ga testen! Heb wel het probleem gevonden mbt de rapportage van de balans waarbij ik op uur 0 geen waarden van de ev, wp en accu kreeg. Dat leek te maken te hebben met het feit dat ik kWh entiteiten gebruikte die dagelijks werden gereset (kwamen uit utility meter in ha met dagelijkse cycle). Dat werkt goed in ha energy dashboard maar kennelijk niet in de add-on. Ik heb deze nu vervangen door de relevante totale (en dus altijd stijgende) kWh waarden en nu lijkt het wel te werken. Ik test nog even en dan laat ik je het weten. Wellicht goed om dit in de documentatie op te nemen. Op ma 9 dec 2024 om 22:27 schreef Cees van Beek ***@***.***>:

…

Ik hoor graag of de nieuwe versie bij jou nog problemen veroorzaakt. Zo ja dan ga ik een kopie maken van de HA-database naar Sqlite en daarmee testen/debuggen. — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BIJKPKC7JSMFBUY7U44T2EYDMJAVCNFSM6AAAAABP7LYGTWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJRGMZTKOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[corneel27]

Fijn dat je dat gevonden hebt.
Ik vind eigenlijk dat DAO daar ook goed mee moet om gaan.
Ik ga nog een keer een testomgeving opzetten met een utilty-meter met cycle daily en daar dan het verbruik van opvragen in DAO (zet ik die sensor tijdelijk in een van de report-sensors.
Misschien kan ik het wel oplossen.

[soeter01]

Draai nu paar dagen de rc3 versie zonder problemen! Zit beetje krap in tijd nu maar zal als eerste de docs aanpassen. Op ma 9 dec 2024 om 22:27 schreef Cees van Beek ***@***.***>

…

Ik hoor graag of de nieuwe versie bij jou nog problemen veroorzaakt. Zo ja dan ga ik een kopie maken van de HA-database naar Sqlite en daarmee testen/debuggen. — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BIJKPKC7JSMFBUY7U44T2EYDMJAVCNFSM6AAAAABP7LYGTWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJRGMZTKOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[corneel27]

Ik heb nog een onderwerp waar ik graag nog even op wil terugkomen.
Het gaat over heat_demand == False
Bij de regeling "on/off" wordt in de dat geval de warmtepomp helemaal niet ingepland (ook al moet er volgens de berekening toch warmte worden opgewekt).
Bij de andere twee regelingen (curve, power) wordt alleen in het eerste uur de warmtepomp niet ingepland.
Ik vind dat eigenlijk ook voor de on/off regeling beter omdat je daarmee een beter beeld krijgt van de totale elektriciteitsvraag over een planningsperiode. Dit is nu nog niet zo wezenlijk (omdat we nog kunnen salderen), maar vanaf 1-1-2027 wordt het goed inplannen van de totale elektriciteitsvraag over de dag en het aansturen op het zoveel mogelijk verbruiken van eigen opgewekte elektriciteit wel belangrijk. Daar kunnen we nu met een goede regeling al veel van leren.
Hoe kijk je hier tegen aan als je dit zo leest?
We hoeven het niet in deze versie aan te passen, maar (als we het eens zijn) mogeliik in een volgende update.

[corneel27]

Zou het jou lukken om jouw aanvullingen in DOCS.md na het weekend klaar te hebben.
Dan kunnen we mogelijk a.s. maandag de versie gaan vrijgeven.

[soeter01]

Ik ga mijn best doen. Weekend is druk. Heb denk ik maandag wat tijd. Dinsdag zeker! Ik hou je op de hoogte. Op do 12 dec 2024 om 19:28 schreef Cees van Beek ***@***.***>

…

Zou het jou lukken om jouw aanvullingen in DOCS.md na het weekend klaar te hebben. Dan kunnen we mogelijk a.s. maandag de versie gaan vrijgeven. — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BIJOOYZQW7BGEWOEQQK32FHIUHAVCNFSM6AAAAABP7LYGTWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJUG44DGOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[corneel27]

Ga je niet haasten!
Dat gaat ten koste van de kwaliteit.
Dinsdag is ook prima!

[soeter01]

Ik heb DOCS.md aangepast: het stukje tekst bij 'heating'' en de tabel met de instellingen. Verder heb ik 2 grafieken aan de images directory toegevoegd. Overigens heb ik bij de adjustment opties power en heating curve geen tekst toegevoegd. Weet niet precies hoe je dat bedoeld hebt.. Kijk maar even. Als ok maak ik PR request naar je develop. Op do 12 dec 2024 om 19:28 schreef Cees van Beek ***@***.***>:

…

Zou het jou lukken om jouw aanvullingen in DOCS.md na het weekend klaar te hebben. Dan kunnen we mogelijk a.s. maandag de versie gaan vrijgeven. — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BIJOOYZQW7BGEWOEQQK32FHIUHAVCNFSM6AAAAABP7LYGTWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJUG44DGOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[corneel27]

Ik heb nu alles doorgezet naar de branche "addon", die wordt ook getest door Ton van Boven.
Wil jij dit ook nog testen?
Als alles goed gaat, gaat morgen in de loop van de dag alles door naar "main".

[soeter01]

Super! Ik zal v12 ook installeren en meteen testen. Op wo 18 dec 2024 om 16:40 schreef Cees van Beek ***@***.***>:

…

Ik heb nu alles doorgezet naar de branche "addon", die wordt ook getest door Ton van Boven. Wil jij dit ook nog testen? Als alles goed gaat, gaat morgen in de loop van de dag alles door naar "main". — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BIJLRUYLMGC6XFPFF2FL2GGJPFAVCNFSM6AAAAABP7LYGTWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRQG4ZDAOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[soeter01]

V12.0 draait nu paar dagen zonder problemen. Je hebt weer mooi werk geleverd! Fijne dagen. Op wo 18 dec 2024 om 16:40 schreef Cees van Beek ***@***.***>

…

Ik heb nu alles doorgezet naar de branche "addon", die wordt ook getest door Ton van Boven. Wil jij dit ook nog testen? Als alles goed gaat, gaat morgen in de loop van de dag alles door naar "main". — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BIJLRUYLMGC6XFPFF2FL2GGJPFAVCNFSM6AAAAABP7LYGTWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRQG4ZDAOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[soeter01]

Geloof dat ik toch nog bugje heb gevonden: bij rapportage in dashboard komen er geen voorspellingen als je morgen gebruikt… Op wo 18 dec 2024 om 16:40 schreef Cees van Beek ***@***.***>

…

Ik heb nu alles doorgezet naar de branche "addon", die wordt ook getest door Ton van Boven. Wil jij dit ook nog testen? Als alles goed gaat, gaat morgen in de loop van de dag alles door naar "main". — Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BIJLRUYLMGC6XFPFF2FL2GGJPFAVCNFSM6AAAAABP7LYGTWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRQG4ZDAOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[corneel27]

De prijzen van morgen komen pas na 12:45 binnen. Zolang de prijzen niet binnen zijn is de voorspelling voor morgen leeg. Dat is geen bugje maar een feature 😊.

[soeter01]

Haha inderdaad mooie feature! Op vr 20 dec 2024 om 13:02 schreef Cees van Beek ***@***.***>

…

De prijzen van morgen komen pas na 12:45 binnen. Zolang de prijzen niet binnen zijn is de voorspelling voor morgen leeg. Dat is geen bugje maar een feature 😊. — Reply to this email directly, view it on GitHub <#130 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL7BIJN6TVC342G77FOIPEL2GQBOBAVCNFSM6AAAAABP7LYGTWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRSHAYDEMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[corneel27]

Het kan natuurlijk wel mooier door er een adequate melding neer te zetten ipv een lege tabel.