Open sjampeter opened 2 months ago
Er is niets meer aan de software op dit onderdeel veranderd sinds de introductie. Maar er kan best nog een foutje in de software zitten. Ik wil graag het probleem reproduceren en zien wat er fout gaat. Daarvoor heb ik nodig:
Dag Corneel. uiteraard wil ik dit sturen, geen enkel probleem tevens enkele screenshots van voorbeeld situatie van gisteren.
situatie om 08:00: wp aan berekent op 12:45
situatie om 09:00, wp aan is verdwenen. waarde staat echter vast in "calculated_start_warmtepomp"
situatie om 13:20, het eerste moment dat er nieuwe prijzen binnen zijn. te zien is dat er voor de volgende dag al een tijdstip berekent wordt voor de wp. deze wordt ook al doorgezet naar "calculated_start_warmtepomp" . dit doorzetten mag volgens mij enkel gebeuren na "end_window_warmtepomp" . doordat het al eerder doorgezet wordt, raakt de verder aansturing (via node-red) behoorlijk in de war.
zie hier de import node "calculated_start_warmtepomp" van node-red. hier wordt heel de toko op aangestuurd. deze is van vandaag, net voor 13:00 uur. deze van 13:22. ik dacht dat deze tijd pas na end window warmtepomp doorgegeven werd, echter is dit dus niet zo.
ik kan het trouwens, nu ik het probleem wat beter in beeld heb, oplossen via node-red. vraag blijft of dit gewenst gedrag is?
dit zijn de entiteiten.
het vreemde is dat het spul probleemloos gedraaid heeft.
Dank voor de heldere beschrijving van het issue. Ik heb ernaar gekeken en het is een fout die er al vanaf het begin in zit. Ik ga een en ander aanpassen en als het klaar is komt er een nieuwe versie van de de software.
kijk aan. blij dat ik heb kunnen bijdragen aan deze software. waarom het hiervoor probleemloos draaide, heb ik nog geen idee van. in ieder geval zal straks het probleem vanuit de software niet meer aanwezig zijn. ik duik nog even in mijn eigen aansturing van de wp. bedankt.
Ik heb op de develop-branche (de naam van die branche is addon
) een aanpassing gezet, die de fout zou moet oplossen.
Ik heb het hier lokaal getest en daar werkt ie probleemloos.
Zou jij deze develop-versie willen testen.
Daarvoor ga je - naast de productie versie - een tweede versie installeren.
Dat werkt als volgt:
https://github.com/corneel27/day-ahead#addon
(je zet er dus #addon
achter)Toevoegen
Laat je me weten of dit werkt? Ik hoor het graag .
Let op: als de tweede (develop) addon goed werkt kun je het beste de eerste addon (productie) tijdelijk even stopzetten, anders gaan die twee elkaar in de weg zitten. Als het allemaal goed werkt zet ik alles door naar productie en kun je de test/develop versie weer verwijderen.
dag Corneel. bedankt voor je inzet. ik ga er nu even mee aan de slag en laat het weten.
update : ondertussen draait de develop versie. morgen rond 13 uur weet ik meer. keep you posted
Er zit nog een klein foutje in: de in een vorige berekening ingeplande inzet van een apparaat (bij jou je wp/sww) die niet meer kan worden gewijzigd (omdat het begintijdstip van de berekening voorbij het begintijdstip van de inzet ligt, wordt niet meegenomen in de rapportages grafieken en tabellen. Dat ben ik nu aan het herstellen. Wellicht kan ik dit samen met jouw opmerkingen/suggesties meenemen in een volgende versie. Groeten van Cees
hmm. dat deed ie in de vorige versies toch ook al niet? opzich geen drama, maar voor de volledigheid wel zo mooi inderdaad
mijn end_window_warmtepomp staat op 19:59. toch wordt om exaxt 18:00 de nieuwe startwaarde doorgegeven. lijkt dus nog niet helemaal te kloppen. om 17:00 nog geen calculatie voor start warmtepomp. om 18:00 dus wel. hier de instelling van het end_window. waar die 18:00 vandaan komt, geen idee.
oude calculated_start blijft staan tot 13:00 (dan wordt de nieuwe berekening voor de volgende 24 uur gestart) om 13:00 is ie weg.
Dank voor je testen en feedback! Ik heb versie 2024.8.7.dev_b in de addon-branche gepubliceerd. Hierin zijn een aantal correcties doorgevoerd. Ook bovenstaande fouten zouden weg moeten zijn. Of ik die laatste fout heb iopgelost heb ik nog mijn twijfels, wat is de begintijd van je window dan kan ik het beter testen. Je kunt (als je de addon-versie nog heb staan) deze gewoon updaten.
versie 2024.8.7.dev_b draait ondertussen.
mijn end_window_warmtepomp staat op 19:59. toch wordt om exaxt 18:00 de nieuwe startwaarde doorgegeven. lijkt dus nog niet helemaal te kloppen.
deze 18:00 komt overigens van de calulated_stop_warmtepomp. opzich ook best logisch
Dus de functionaliteit kwa schakel-berekening komt nu overeen met jouw wensen of mag hij pas voor de volgende dag berekenen als de eindtijd van het window voor de huidige dag is verstreken? Ik heb nu dev_c klaar staan met een nieuwe berekening van de rapportages, waarbij het resultaat ook wordt meegenomen in de berekening van consumption en cost. Ik wacht nog even met het pushen van deze update tot ik zeker weet dat jij tevreden bent met versie dev_b wat betreft "schakelgedrag".
feitelijk zou je zeggen dat ie pas een nieuwe berekening mag pushen nadat het end_window_warmtepomp voorbij is. volgens mij zou deze voor de exacte berekening wel al meegenomen moeten worden in de nieuwe berekening op het moment dat de nieuwe prijzen bekend zijn. in mijn geval zou dat rond 13:00 uur tot 13:20 zijn, echter mag ie pas "gepushed" worden na end_window_warmtepomp. am i right?
nu doet ie dit als het calculated_end_warmtepomp gepaseerd is, wat opzich bij mijn verdere aansturing geen problemen geeft.
voor mij is het prima werkbaar nu, echter denk ik dat we er in theorie nog net niet zijn.
Ik ben het helemaal met je eens. Ik heb versie 2024.8.7.dev_c gepushed naar de addon branche. Daarin zijn deze aanpassingen doorgevoerd (zie changelog). Deze versie draait bij mij al een paar dagen probleemloos. Wil jij hem nog even testen? Bij akkoord zal ik een nieuwe versie (wordt waarschijnlijk 2024.10.0) doorzetten naar de main-branche.
ik zet hem erop. ik laat mijn bevindingen weten.
nog een kleinigheidje tussendoor, maar ik krijg nog wat bijzondere grafieken te zien. volgens mij is dit gekomen sinds er wat gesleuteld is aan de weerdata? onderstaand de instellingen : onderstaand het resultaat.
doet het script eigenlijk steeds op deze tijdstippen. foutje in het script? of ligt het bij mij (meteo data komt wel binnen namelijk)
Ik heb deze fout ook gehad. Het probleem zit bij Meteoserver. Ik heb een paar emails naar hun gestuurd, maar geen reactie. Ik heb het eindelijk opgelost door het tijdstip van het ophalen van de meteodata te verschuiven:
"0430": "get_meteo_data",
"1030": "get_meteo_data",
"1630": "get_meteo_data",
"2230": "get_meteo_data",
Ik zal dit bij de volgende grote update meenemen als extra mededeling in de changelog.
ik heb dezelfde "get_meteo_data" tijdstippen ingesteld, echter veranderd er niks. voor mij geen probleem hoor.
versie c draait stabiel bij mij. wel blijft hij consequent om 18:00 de nieuwe calculated_start_warmtepomp door geven.
dit is nog steeds gebaseerd op de calculated_stop_warmtepomp lijkt het.
zou feitelijk pas na het end_window_warmtepomp mogen gebeuren. ik dacht dat je dit getracht had te bereiken in versie c?
voor mij niet al te groot probleem, en als het voor jou ook goed is, kun je hem wat mij betreft doordrukken naar de main.
Dank voor de terugkoppeling.
zou feitelijk pas na het end_window_warmtepomp mogen gebeuren. ik dacht dat je dit getracht had te bereiken in versie c? Er zit nu iemand te wachten op een update die niet een "showstopper" repareert. Dus vandaag komt er een nieuwe main-versie waarin jouw melding nog niet is gerepareerd. Ik ga jou melding in een volgende test-versie oplossen, dus stay tuned op de "addon" branche.
zou het kunnen dat er met een nieuwe update, er iets veranderd is met betrekking tot start en end window voor "machines"? ik stuur mijn warmtepomp via node-red aan om op het juiste moment te gaan verwarmen.
mijn start en end window staan op 08:00 tot 20:00. dat wil zeggen dat de warmtepomp in dit window een run kan doen.
het vreemde is, en dit was volgens mij vroeger niet zo, dat rond 13 uur nieuwe prijzen binnen komen. zodra dit gebeurt wordt er al voor de volgende dag (dus volgend window) een optimum gecalculeerd. mijn besturing raakt hier behoorlijk van in de war.
volgens mij was het bij eerdere versies zo dat er pas een nieuw tijdstip berekend werd na (in mijn geval) 20:00.
kan iemand dit bevestigen?