Mitsubishi Ecodan warmtepomp uitlezen via cn105 + esp32

[Johnny_Hasselt]

@xoror al 2 dagen na mekaar heeft ODIN een heel raar uur uitgekozen om een DHW run te doen.

Mijn setpoint is 51 heb 10 graden differentieel dus bij 41 start die een run op de normale manier.

Mijn DHW om 3 uur was nog steeds 44 graden en persoonlijk vind ik het een waste of energy om dan mijn DHW op te warmen... Neemt 10% van mijn batterij weg. Tegen 7 a 8 uur smorgens is die al wat warmte kwijt.

Kan je ODIN de nachtelijke uren tussen 0 en 6 uur niet laten selecteren aub want die uren zijn echt zinloos naar mijn mening.

En ik wil geen prohibited gebruiken op DHW tussen 0 en 6 omdat die dan altijd een run start bij het uitzetten onafhankelijk van de temperatuur. Ik vind dat ODIN dit zou moeten kunnen via software of instelling.

[ Voor 8% gewijzigd door Johnny_Hasselt op 27-08-2026 21:51 ]

[TSE]

Hi, ik ben dit project een beetje uit het oog verloren. Vorig jaar oktober voor het eerst geinstalleerd, nadien geen updates gedaan. (don't fix what ain't broken...)
Mogelijks wil ik wel gaan ontdekken wat er in de nieuwe updates zit...

Is het "veilig" om gewoon van 2025.20.17.3 naar de laatste versie te updaten ?

[xoror]

@Johnny_Hasselt
Met jouw voorbeeld:
setpoint: 51, max drop: 10
dus forced start: 41

Odin werkt dan als volgt: Stel je stelt 8 graden threshold in, dan gaat hij vanaf forced start + threshold zoeken (dus vanaf 49c). Vanaf dat moment schat hij 0.5c stilstand verlies per uur.

Dus om 03:00 was het 44c, en ik weet niet wat je threshold was, maar hij had dus geen goedkoper punt kunnen vinden tussen 03:00 - 09:00. Want om 09:00 is volgens de schatting de forced start.

kijk de volgende 2 zaken even na:
- gebruik je aparte tank of cylinder unit ? Kijk of je temp sensor goed staat op de bovenste. Als je gemiddeld van 2 sensoren hebt, dan krijg je soms te snelle forced trigger.
- kijk aan de hand van de uitleg hierboven of je threshold dan wel goed staat. In het ideale geval moet Odin iets van 10h vooruit kunnen kijken. Dan kan hij meestal zien/schatten of hij de nacht doorkomt

In een volgende Asgard zie je vanaf welk punt hij gaat zoeken:


Mijn settings:
setpoint: 45, max drop: 15
dus forced start: 30



Huidige tank temp: 36.5c om 24:00h, dus hij heeft nog 13 uren om een goedkoop punt te vinden, in dit geval is dat morgen om 11:00, voldoende pv, en dus gratis.

Ik heb de dhw temp sensor (boven) afgelopen week getest, en bij 33.5 had ik nog goed gewoon warm water. Dus experimenteer nu met deze settings

Verder valt mij op dat jouw stilstand verliezen zo hoog zijn. Zo te zien verlies je 1c per uur. Bij mij is dat minder dan 0.5c per uur. Zijn je verliezen altijd zo?

Als ik jouw tank temp door trek met die van 03:00h, dan kom ik rond 7 a 8 uur uit. Je moet dan de kosten even tussen 03:00 - 08:00 bekijken. Ik zie 2x dhw per dag, is dat normaal altijd zo ?

Ik heb de ruwe prijzen van BE erbij gehaald:


Om 03:00 is echt het goedkoopste punt dus ik geef hem daar geen ongelijk. Aan jouw grafiek met pv opbrengst te zien is er vanaf een uur of 10:00 pas voldoende gratis pv. Dat punt haalt hij dus niet met je huidige settings.

Als je jouw constraint gaat toepassen (geen dhw tussen 00:00-06:00) ga je dus krijgen dat hij voor 00:00 gaat verwarmen (want hij mag niet later), en dan zit je de volgende ochtend met nog meer verlies. Gaat hij na 06:00 dan heb je kans op koude douche in de ochtend. Verder zit je nog met het probleem van de forced start, als die tussen 00:00-06:00 komt, gaat het toch weer af.

Als laatste nog het vermeende 10% verbruik van de batterij. Ik zie iets van 0.7kWh per dhw sessie 'werkelijk' verbruik. Volgens mij had je iets van 50 kWh aan batterijen?

[ Voor 44% gewijzigd door xoror op 28-08-2026 01:28 ]

[xoror]

Gezien het feit dat de stilstand verliezen zo anders zijn heb ik een aanpassing gemaakt in Odin zodat hij deze als een gemiddelde leert. Dan stappen we af van de (dacht ik) conservatieve 0.5c/uur daling.

Verder nog handling voor de dhw secondary tank sensor toegevoegd, voor de mensen die triggeren met top+bottom sensor

In Odin settings komen dan 2 velden bij:


Je kan nu het volume ook opgeven zodat Odin beter het verwachtte verbruik kan schatten voor DHW.

@Johnny_Hasselt @tromphakvoort Even uitproberen en kijken of het beter gaat?
Installeer dan het volgende:
Asgard >= 2026-08-28.01
Odin >= 1.0.7.01

Hij zal nog steeds 0.5c/h aanhouden als er geen data is, maar na een paar uur weet hij wel wat je tank ongeveer verliest.

[DucoT]

Hallo,

Sinds een paar maanden woon ik in een nieuwbouwhuis voorzien van een Ecodan met een ERST20D-VM2E binnen- en een QUHZ-W40VA buitenunit. Omdat ik graag het elektraverbruik van de Ecodan wil monitoren en bij voorkeur wil invoeren in Domoticz ben ik ermee begonnen dat voor elkaar te krijgen en dat viel/valt niet mee.

Eerst heb ik een MAC 597 Wifi adapter van Mitsubishi gekocht en die aangesloten op een aangemaakt MelCloudHome account. Dat werkt allemaal prima, maar toen bleek dat het verschil tussen MelCloud en Melcloudhome zo groot is dat de Melcloud plug-in voor Domoticz niet werkt en er nog geen Melcloudhome plug-in is. Vervolgens gekeken of een overstap naar Home Assistent soelaas zou kunnen bieden, Voor HA is er sinds kort wel een MelCloudHome plug-in. Na dit werkend gekregen te hebben bleek de nieuwe plug-in geen elektra info te leveren.

Vervolgens de MQTT weg ingeslagen en een AtomS-3 gekocht om de https://github.com/F1p/Home-Assistant-Mitsubishi-CN105-to-MQTT constructie uit te proberen. Ook dat was zonder veel problemen werkend te krijgen, zelfs samen met MelCloudHome. Vervolgens kon ik (met MQTT-Explorer) zien dat de Ecodan heel veel info levert waaronder ook vermogens info. Ook de combinatie met HA werkte goed.

Maar toen ik de data van het elektraverbruik goed ging bekijken bleek mij dat er grote verschillen zaten tussen het aantal kWh's dat de WP gebruikt voor één SWW opwarming gemeten met de drie wegen die ik had: MelCloudHome, MQTT (HA) en de info die ik met Domoticz uit mijn P1 haal. Ook bleek dat de MQTT info nogal wat merkwaardigheden (fouten?) bevat. Ik ga ervan uit de het verbruik van een dag (DCHW_TD) de volgende dag met dezelfde waarde bij DCHW_YD te zien zal zijn maar dat was niet zo.

Lezing van de vele info op dit forum leerde mij dat de Ecodan geen elektra verbruik gegevens meet maar alleen berekent uit temperatuurverschillen en debieten.

Mijn vraag is of anderen deze ervaringen ook hebben opgedaan en of zij wel een goede methode hebben gevonden om het elektraverbruik te bepalen.

[xoror]

@DucoT Je kan hier https://github.com/F1p/Mi...otocol-Decode/discussions vragen, maar ik weet dat hij een schatting bedacht had voordat ik de teller van melcloud had gevonden. Hij kan je wel uitleggen wat hij allemaal bedacht had.

De teller die ik hier gebruik voor de mensen zonder meter, komt wel overeen met de melcloud aantallen aan het einde van de dag.

Maar alles blijft natte vingerwerk, enige wat echt werkt is een energie meter op je wp groep.

[Quitoo]

Super update! Mijn tank verloor de afgelopen nacht slechts 3 graden in 12 uur, dus dit geeft Odin een stuk meer bewegingsruimte! Waar kan ik de Odin update downloaden?

Ik heb zelf nog een automation toegevoegd die wellicht ook interessant is voor mensen met zonnepanelen. Ik laat Odin gewoon bepalen wanneer het beste moment is om een DHW run te starten, als hij dan 2 graden onder target temp is bekijkt hij of ik stroom teruglever. In dat geval verhoogt hij de target temp naar 55 graden om de tank te vullen met gratis zonnestroom. Na de run zet hij hem weer netjes terug naar target (50 bij mij)

[ Voor 3% gewijzigd door Quitoo op 28-08-2026 21:02 ]

[Johnny_Hasselt]

Quitoo schreef op vrijdag 28 augustus 2026 @ 20:50:
Super update! Mijn tank verloor de afgelopen nacht slechts 3 graden in 12 uur, dus dit geeft Odin een stuk meer bewegingsruimte! Waar kan ik de Odin update downloaden?

Ik heb zelf nog een automation toegevoegd die wellicht ook interessant is voor mensen met zonnepanelen. Ik laat Odin gewoon bepalen wanneer het beste moment is om een DHW run te starten, als hij dan 2 graden onder target temp is bekijkt hij of ik stroom teruglever. In dat geval verhoogt hij de target temp naar 55 graden om de tank te vullen met gratis zonnestroom. Na de run zet hij hem weer netjes terug naar target (50 bij mij)

https://github.com/gekkekoe/heatpump-optimizer/releases/tag/1.0.7.01

https://github.com/gekkekoe/esphome-ecodan-hp/releases/tag/2026-08-28.01

[Johnny_Hasselt]

xoror schreef op donderdag 27 augustus 2026 @ 23:56:
@Johnny_Hasselt
Met jouw voorbeeld:
setpoint: 51, max drop: 10
dus forced start: 41

Odin werkt dan als volgt: Stel je stelt 8 graden threshold in, dan gaat hij vanaf forced start + threshold zoeken (dus vanaf 49c). Vanaf dat moment schat hij 0.5c stilstand verlies per uur.

Dus om 03:00 was het 44c, en ik weet niet wat je threshold was, maar hij had dus geen goedkoper punt kunnen vinden tussen 03:00 - 09:00. Want om 09:00 is volgens de schatting de forced start.

kijk de volgende 2 zaken even na:
- gebruik je aparte tank of cylinder unit ? Kijk of je temp sensor goed staat op de bovenste. Als je gemiddeld van 2 sensoren hebt, dan krijg je soms te snelle forced trigger.
- kijk aan de hand van de uitleg hierboven of je threshold dan wel goed staat. In het ideale geval moet Odin iets van 10h vooruit kunnen kijken. Dan kan hij meestal zien/schatten of hij de nacht doorkomt

In een volgende Asgard zie je vanaf welk punt hij gaat zoeken:
[Afbeelding]

Mijn settings:
setpoint: 45, max drop: 15
dus forced start: 30

[Afbeelding]

Huidige tank temp: 36.5c om 24:00h, dus hij heeft nog 13 uren om een goedkoop punt te vinden, in dit geval is dat morgen om 11:00, voldoende pv, en dus gratis.

Ik heb de dhw temp sensor (boven) afgelopen week getest, en bij 33.5 had ik nog goed gewoon warm water. Dus experimenteer nu met deze settings

Verder valt mij op dat jouw stilstand verliezen zo hoog zijn. Zo te zien verlies je 1c per uur. Bij mij is dat minder dan 0.5c per uur. Zijn je verliezen altijd zo?
[Afbeelding]
Als ik jouw tank temp door trek met die van 03:00h, dan kom ik rond 7 a 8 uur uit. Je moet dan de kosten even tussen 03:00 - 08:00 bekijken. Ik zie 2x dhw per dag, is dat normaal altijd zo ?

Ik heb de ruwe prijzen van BE erbij gehaald:
[Afbeelding]

Om 03:00 is echt het goedkoopste punt dus ik geef hem daar geen ongelijk. Aan jouw grafiek met pv opbrengst te zien is er vanaf een uur of 10:00 pas voldoende gratis pv. Dat punt haalt hij dus niet met je huidige settings.

Als je jouw constraint gaat toepassen (geen dhw tussen 00:00-06:00) ga je dus krijgen dat hij voor 00:00 gaat verwarmen (want hij mag niet later), en dan zit je de volgende ochtend met nog meer verlies. Gaat hij na 06:00 dan heb je kans op koude douche in de ochtend. Verder zit je nog met het probleem van de forced start, als die tussen 00:00-06:00 komt, gaat het toch weer af.

Als laatste nog het vermeende 10% verbruik van de batterij. Ik zie iets van 0.7kWh per dhw sessie 'werkelijk' verbruik. Volgens mij had je iets van 50 kWh aan batterijen?

Enkele snelle feedback:

DHW tank is appart, 200 liter.. groter ging niet door zolder trap.

Sensor staat op top

Treshold staan beide op 10 graden

Ja, verliezen zijn altijd zo geweest. Alles is geïsoleerd, incl leidingen en heb zelfs de DHW tank extra met isolatie voorzien. Tank staat op zolder wat geen koude omgeving is. Is wel maar 200 l.

Batterij is 10 kWh.

2 maand geleden is de VVW aangesloten, onderstaande foto is van ervoor 😄



Greetz, J

[ Voor 6% gewijzigd door Johnny_Hasselt op 29-08-2026 07:09 ]

[Djvdb]

DucoT schreef op vrijdag 28 augustus 2026 @ 17:01:
Hallo,

Sinds een paar maanden woon ik in een nieuwbouwhuis voorzien van een Ecodan met een ERST20D-VM2E binnen- en een QUHZ-W40VA buitenunit. Omdat ik graag het elektraverbruik van de Ecodan wil monitoren en bij voorkeur wil invoeren in Domoticz ben ik ermee begonnen dat voor elkaar te krijgen en dat viel/valt niet mee.

Eerst heb ik een MAC 597 Wifi adapter van Mitsubishi gekocht en die aangesloten op een aangemaakt MelCloudHome account. Dat werkt allemaal prima, maar toen bleek dat het verschil tussen MelCloud en Melcloudhome zo groot is dat de Melcloud plug-in voor Domoticz niet werkt en er nog geen Melcloudhome plug-in is. Vervolgens gekeken of een overstap naar Home Assistent soelaas zou kunnen bieden, Voor HA is er sinds kort wel een MelCloudHome plug-in. Na dit werkend gekregen te hebben bleek de nieuwe plug-in geen elektra info te leveren.

Vervolgens de MQTT weg ingeslagen en een AtomS-3 gekocht om de https://github.com/F1p/Home-Assistant-Mitsubishi-CN105-to-MQTT constructie uit te proberen. Ook dat was zonder veel problemen werkend te krijgen, zelfs samen met MelCloudHome. Vervolgens kon ik (met MQTT-Explorer) zien dat de Ecodan heel veel info levert waaronder ook vermogens info. Ook de combinatie met HA werkte goed.

Maar toen ik de data van het elektraverbruik goed ging bekijken bleek mij dat er grote verschillen zaten tussen het aantal kWh's dat de WP gebruikt voor één SWW opwarming gemeten met de drie wegen die ik had: MelCloudHome, MQTT (HA) en de info die ik met Domoticz uit mijn P1 haal. Ook bleek dat de MQTT info nogal wat merkwaardigheden (fouten?) bevat. Ik ga ervan uit de het verbruik van een dag (DCHW_TD) de volgende dag met dezelfde waarde bij DCHW_YD te zien zal zijn maar dat was niet zo.

Lezing van de vele info op dit forum leerde mij dat de Ecodan geen elektra verbruik gegevens meet maar alleen berekent uit temperatuurverschillen en debieten.

Mijn vraag is of anderen deze ervaringen ook hebben opgedaan en of zij wel een goede methode hebben gevonden om het elektraverbruik te bepalen.

Lekker een kwh meter van homewizard kopen. Heb je daarnaast gekeken of de dipswitch standen overeenkomen met het vermogen van het backup element? Anders klopt het verbruik ook voor geen meter.

[xoror]

@Quitoo ik zou niet teveel micro optimalisaties doen. De hogere dhw tank is ook extra slijtage, ik denk niet dat het waard is eerlijk gezegd.

@Johnny_Hasselt jij heb denk ik een probleem met je stilstand verliezen. Dat hoort niet zo hoog te zijn, de 0.5c/h is al voor een slecht geïsoleerde tank. @Quitoo heeft ook 200L tank en die verliest 0.25C / h. Dat is gebruikelijk voor een geïsoleerde tank. Ik zou dat eerst onderzoeken en wellicht kunnen ze in het algemene topic meer hulp bieden. De AI zegt iig het volgende:

"De reflecterende folie-wrap om de tank werkt waarschijnlijk niet zoals bedoeld. Reflecterende/foil-isolatie heeft een luchtspouw nodig aan de reflecterende zijde om te functioneren — als die folie strak tegen de tankwand is gewikkeld (wat het hier lijkt te zijn), verlies je het grootste deel van de R-waarde. Dit is een veelgemaakte fout bij dit soort naisolatie-wraps; ze werken totaal anders dan massieve PU-schuim of minerale wol."

en

"Mogelijk thermosifon via de primaire leiding tussen Ecodan en tank. De leidingen tussen de warmtepomp-unit en de tank (koper/zwarte mantelbuis, linksonder in beeld) zien er niet volledig geïsoleerd uit over de hele lengte. Als er geen terugslagklep in dat primaire circuit zit, kan warm water via zwaartekracht continu circuleren richting de (koelere) warmtewisselaar van de Ecodan — een klassieke, vaak over het hoofd geziene sluipverlies-route die volledig los staat van de tankisolatie zelf."

Wat ook voorkomt is dat de 3-wegsklep lekt of verkeerd om is geïnstalleerd.

[SebastiaanPs]

@Johnny_Hasselt welk type tank is het, heb je het warmteverlies volgens de specs? Het warmteverlies is zo enorm dat ik vermoed dat het optie 2 is in de post van @xoror hierboven.

[kimjansen]

xoror schreef op woensdag 12 augustus 2026 @ 20:21:

@kimjansen Asgard is gemaakt om voor zoveel mogelijk mensen te werken. Jij bent de eerste die hierom vraagt. Als de meerderheid het graag wilt hebben, dan kan ik ernaar kijken, maar ik kan niet voor iedereen alles op maat maken. Dit moet ook onderhouden worden etc.

Wat probeer je eigenlijk op te lossen? Iets van nadraai tijd van je pomp regelen? Als dat zo is, doet dit het misschien al voor je

Dankjewel voor je reactie. Ik schreef in mijn eerdere berichtjes al eens wat, maar het komt er op neer bij retrofit waar je de aansturing van groepen van VVW of de 'radiatorthermostaten' niet wilt of kunt vervangen en een 'vraag'-contact hebt. Lees: Honeywell/Danfoss/etc.

Die 'vraag' aan het verwarmingstoestel wordt nogaleens een beetje als PWM gestuurd, wel waar de schakelmomenten minuten ver uit elkaar liggen, maar toch meermaals per uur 'even' de kachel uitgezet wordt. Bij een warmtepomp wil je dat niet en het is zelfs in 99% van de gevallen niet eens nodig, die regelt zelf terug zolang er een groep open blijft staan of er een buffer is. Omdat de Ecodan geen OpenTherm heeft die dit zou kunnen ondervangen, dacht ik: mooie USP voor jou. Of de meerderheid dit wil: dat zal vast niet, maar dat geldt voor meer functies die je bouwt... Wat ik nog wel mee wil geven is dat het nog erg op de 'tweakers' is gericht en je met zoiets ook de mogelijkheden biedt om ruimtes individueel te regelen met de bestaande actuatoren en sensoren (en ja: dat werkt met een warmtepomp ook goed). Dat zou een heel ander publiek aan kunnen spreken, want er zijn er zat die hun eigen weekprogramma willen houden bijvoorbeeld of die tegen andere zaken aanlopen.

Het gedrag dat je dan zoekt is dat je niet direct van stal gaat zodra er warmtevraag komt (via een potentiaalvrij contact):
- optioneel, een minimale duur van de vraag (zodat je zeker weet dat het geen korte puls is of een thermostaat die zich bedenkt)
- een minimale looptijd na de eerst geregistreerde vraag en daadwerkelijk inschakelen warmtepompo
- keuze, het gedrag bij het wegvallen van de vraag ná de minimale looptijd; A.) direct uit, B.) minimale nalooptijd
- een minimale dode tijd nadat de vraag weg viel (en compressor stopte) tegen pendelen

Wat een Honeywell bijvoorbeeld kan doen tijdens een koude winterdag:

Met een paar timertjes trek ik dit vlak naar 'aan'/warmtevraag en pas als de pulsjes een tijdje wegblijven gaat de Ecodan uit. Ik heb VVW groepen altijd open en de warmtepomp kan toch ver genoeg terugregelen en zijn capaciteit tijdens de naloop dus kwijt, maar direct uit als aan looptijd voorwaarden is voldaan is een optie. Zo hou je het regelgedrag van ruimteregelingen in stand en de warmtepomp een beetje koest.

De Asgards hebben voor mij nu geen meerwaarde (er zitten nu ClimaControls op en dat werkt ook uitstekend) en de stevige prijs van het Odin printje maakt dat ik ook daar maar even vanaf zie als ik er zelf nog wat omheen moet blijven bouwen.

(verder natuurlijk al wel een heel mooie oplossing!)

[xoror]

@kimjansen Ah nu valt het kwartje PWM thermostaat. Honeywell heeft niet z'n goede reputatie icm warmtepompen. Lees het algemene topic erop na. Je oplossingsrichting is denk ik ook verkeerd. Met Asgard kan je de virtual thermostat hiervoor gebruiken, je voedt het met de temp van je honeywell (of elke willekeurige sensor). Je heb dan instelbare hysteresis, en als je handig bent kan je zelf min. draai tijden configureren.

Als Climacontrol goed werkt, dan moet je dat blijven gebruiken, maar Asgard is qua features veel uitgebreider en volledig open source. Er zijn hier ook overstappers die je wat meer over kunnen vertellen.

Wat betreft Odin. De prijs voor Odin wordt voornamelijk bepaald door de solver software (lokaal model predictive control met specifieke huis parameters). Ik heb veel prijzen bekeken en gezien de terug verdientijd en de werking is het aan de lage kant zelfs (volgens de grote AI's).

@TSE Je hebt een jaar development gemist, er is flink wat bij gekomen, dus ik zou het wel flashen. Als het niet bevalt kan je altijd terug.

[kimjansen]

xoror schreef op zaterdag 29 augustus 2026 @ 12:40:
@kimjansen Ah nu valt het kwartje PWM thermostaat. Honeywell heeft niet z'n goede reputatie icm warmtepompen. Lees het algemene topic erop na. Je oplossingsrichting is denk ik ook verkeerd. Met Asgard kan je de virtual thermostat hiervoor gebruiken, je voedt het met de temp van je honeywell (of elke willekeurige sensor). Je heb dan instelbare hysteresis, en als je handig bent kan je zelf min. draai tijden configureren.

De problematiek is me bekend, vandaar ook de vraag en suggestie. Ik wil geen cloud diensten van derden gebruiken en bij voorkeur ook geen draadloze koppelingen, dat geeft alleen maar kans op storingen.

Ik heb 1 contact, afhankelijk van de vraag van diverse ruimtes, dus jouw suggestie gaat alleen werken als jij Honeywell lokaal betrouwbaar uit kunt lezen en de ruimtes individueel kunt filteren en daarvan dan de temperatuur+vraag uitlezen. Of als alternatief de temperatuur per ruimte uitlezen, de warmtepomp regelen en de actuatoren individueel aansturen. Kan dat dan wel? Dat lijkt mij juist extra complexiteit in code en lastiger te troubleshooten.

PS als alternatief zou je misschien nog kunnen interfacen met Opentherm ipv het droge contact ondersteunen

[ Voor 4% gewijzigd door kimjansen op 29-08-2026 13:56 ]

[DucoT]

Djvdb schreef op zaterdag 29 augustus 2026 @ 07:53:
[...]

Lekker een kwh meter van homewizard kopen. Heb je daarnaast gekeken of de dipswitch standen overeenkomen met het vermogen van het backup element? Anders klopt het verbruik ook voor geen meter.

Ga ik doen. Heb wel twee kWh meters nodig: een 1-fase en een 3-fase. Mijn buitenunit heeft een 3 fasen voeding en mijn binnenunit een 1 fase.

[Djvdb]

DucoT schreef op zaterdag 29 augustus 2026 @ 13:57:
[...]

Denk dat die 1 fase van de binnenunit alleen de booster heater is? Gezien je een CO2 warmtepomp hebt wordt die denk ik nooit gebruikt?

[usain]

@xoror zou het kunnen dat Odin/Asgard de vakantiemodus overschrijft? Ik ben op vakantie maar zie in homewizard duidelijk de SWW runs plaatsvinden ondanks pomp in vakantiemodus…

[xoror]

@usain Even threshold op 0, of prohibit dhw aan. Blijkbaar heeft die gewoon voorrang tijdens holiday mode. Legionella blijft ook altijd doorgaan.

@kimjansen De meeste mensen lezen de kamer temps uit in HA, en aggregeren het tot 1 temp, en sturen die door naar de virtual thermostat. Tijdens het aggregeren kan je met je eigen regels bepalen wanneer er verwarmd wordt. Je wilt niet dat een kleine kamer bijv demand vraagt etc.

De virtual thermostats dienen dan als een instelbare aan/uit thermostaat die de in1/in6 dry contacts aansturen. Allemaal lokaal en geen cloud. Je kan ook de virtual thermostat bypassen door deze op OFF te zetten en zelf via HA in1/in6 aan/uit te zetten, dan heb je 100% controle. Dit is mogelijk omdat de virtual thermostat op OFF staan, dan je de manual switch bedienen in HA

[ Voor 89% gewijzigd door xoror op 30-08-2026 11:35 ]

[Breud]

xoror schreef op donderdag 27 augustus 2026 @ 11:03:
@Breud Hoe had jij thermostaten uitgelezen in HA ? Jij had toch ook Watts ? @xchrisnl heeft hetzelfde namelijk

Ik lees de Watts thermostaten uit via een custom integratie in HA.

[xoror]

Breud schreef op zondag 30 augustus 2026 @ 18:43:
[...]

Ik lees de Watts thermostaten uit via een custom integratie in HA.

Had je de gateway daarvoor geinstalleerd?

[Breud]

xoror schreef op zondag 30 augustus 2026 @ 18:52:
[...]


Had je de gateway daarvoor geinstalleerd?

Niets geïnstalleerd. Was fairly plug and play met de custom integratie

https://github.com/pwesters/watts_vision

[xchrisnl]

Breud schreef op zondag 30 augustus 2026 @ 19:54:
[...]

Niets geïnstalleerd. Was fairly plug and play met de custom integratie

https://github.com/pwesters/watts_vision

Ik verwacht dat je 1 wifi thermostaat hebt denk ik ? Wij hebben alleen "Domme" Thermostaten van Watts hier. Voor nu een Shelly besteld, nog even wachten tot die binnen is voor ik alles (Asgard + ODIN) ga aansluiten.

[Breud]

De 10 thermostaten die wij hebben zijn dom, maar we hebben ook een Watts central unit met wifi.

https://www.watts.eu/nl/p...s/central-unit-bt-ct03-rf

Alle thermostaten synchroniseren over RF met deze unit. Die ik vervolgens uitlees in HA

[ Voor 82% gewijzigd door Breud op 30-08-2026 20:31 ]

[xoror]

Ja volgens mij als je maar 1 iets RF hebt, kan je gratis account aanmaken.
@xchrisnl als je nergens een RF unit hebt, is de externe temp sensor het goedkoopst.

[xchrisnl]

Ja alles is bedraad hier geen rf en ook geen centrale wifi gateway helaas. Als het goed is word de shelly morgen geleverd, doen we het lekker op die manier.

[kimjansen]

xoror schreef op zondag 30 augustus 2026 @ 08:08:

@kimjansen De meeste mensen lezen de kamer temps uit in HA, en aggregeren het tot 1 temp, en sturen die door naar de virtual thermostat. Tijdens het aggregeren kan je met je eigen regels bepalen wanneer er verwarmd wordt. Je wilt niet dat een kleine kamer bijv demand vraagt etc.

De virtual thermostats dienen dan als een instelbare aan/uit thermostaat die de in1/in6 dry contacts aansturen. Allemaal lokaal en geen cloud. Je kan ook de virtual thermostat bypassen door deze op OFF te zetten en zelf via HA in1/in6 aan/uit te zetten, dan heb je 100% controle. Dit is mogelijk omdat de virtual thermostat op OFF staan, dan je de manual switch bedienen in HA

Ik begrijp denk ik wel wat je product kan, het ging me er meer over wat het níet kan en dacht een mooie makkelijk te implementeren USP te hebben voor de mensen die een ruimte regeling hebben. Ik kon het tenslotte ook met 2 ouderwetse Finder timertjes 😅. Als het bij mij ergens te koud wordt of het setpoint is vanwege het weekprogramma verhoogd dan moet de verwarming gewoon aan gaan, daar zie ik geen enkele andere oplossing voor die niet ten koste gaat van comfort of de energierekening 😉. Mijn afgiftesysteem inclusief warmtepomp is daar ook prima op ingericht/afgestemd.

Maar ik zal het maar even laten voor wat het is...

[xoror]

Voor 2 zone systemen wordt het mogelijk om per zone de boel aan te sturen via odin
preview:

[xoror]

Voor de mensen met multi zone en meng ventiel probeer de pre-releases:

Asgard >= 2026.09.03-01
Odin >= 1.0.7-02
Documentation: https://github.com/gekkekoe/heatpump-optimizer

Dan kan je evt 2 zones aansturen, report issues als je ze tegenkomt.

[Quitoo]

xoror schreef op zaterdag 29 augustus 2026 @ 10:40:
@Quitoo ik zou niet teveel micro optimalisaties doen. De hogere dhw tank is ook extra slijtage, ik denk niet dat het waard is eerlijk gezegd.

@Johnny_Hasselt jij heb denk ik een probleem met je stilstand verliezen. Dat hoort niet zo hoog te zijn, de 0.5c/h is al voor een slecht geïsoleerde tank. @Quitoo heeft ook 200L tank en die verliest 0.25C / h. Dat is gebruikelijk voor een geïsoleerde tank. Ik zou dat eerst onderzoeken en wellicht kunnen ze in het algemene topic meer hulp bieden. De AI zegt iig het volgende:

"De reflecterende folie-wrap om de tank werkt waarschijnlijk niet zoals bedoeld. Reflecterende/foil-isolatie heeft een luchtspouw nodig aan de reflecterende zijde om te functioneren — als die folie strak tegen de tankwand is gewikkeld (wat het hier lijkt te zijn), verlies je het grootste deel van de R-waarde. Dit is een veelgemaakte fout bij dit soort naisolatie-wraps; ze werken totaal anders dan massieve PU-schuim of minerale wol."

en

"Mogelijk thermosifon via de primaire leiding tussen Ecodan en tank. De leidingen tussen de warmtepomp-unit en de tank (koper/zwarte mantelbuis, linksonder in beeld) zien er niet volledig geïsoleerd uit over de hele lengte. Als er geen terugslagklep in dat primaire circuit zit, kan warm water via zwaartekracht continu circuleren richting de (koelere) warmtewisselaar van de Ecodan — een klassieke, vaak over het hoofd geziene sluipverlies-route die volledig los staat van de tankisolatie zelf."

Wat ook voorkomt is dat de 3-wegsklep lekt of verkeerd om is geïnstalleerd.

Bedankt voor de tip, ik heb de temperatuurverhoging uitgezet!

Soms hebben we wat meer verbruik en draait hij savonds een SWW run terwijl er de volgende dag ruim voldoende zon is. Zou het een idee zijn om in dat geval niet helemaal naar target termperatuur te verwarmen, maar naar een lagere temperatuur?

Ik zag dit weekend dat hij een SWW run 2 uur voor mijn legionella run had gedaan waardoor hij 2x vlak achter elkaar ging verwarmen. Zou het een idee zijn om de dag/tijdstip van de legionalla run als input te kunnen geven (of dat hij hem zelf leert) zodat hij daar rekening mee kan houden?

[xoror]

@Quitoo Ik ben al een tijdje bezig met de boel te herschrijven om weer warmte pompen te ondersteunen, en een van de zaken is legionella plannen (groene uren in de grafiek). Het komt eraan... Odin kan dan een soort legionella emuleren. We kunnen helaas het echte legionella niet triggeren, maar iets vergelijkbaars draaien





Ik moet nog een stukje erover schrijven maar een beetje weinig tijd voor gehad.

[Ben(V)]

@Quitoo
Vlak voor de legionella run SWW draaien is natuurlijk geen enkel probleem, die legionella run wordt dan gewoon korter omdat hij sneller zijn ingesteld temperatuur bereikt.

Sterker nog, het gebeurd regelmatig dat de legionella run helemaal op de booster gaat draaien en dat is het zelfs slim om tevoren een SWW run te doen alleen op de warmtepomp.

[Quitoo]

@Ben(V) Dat snap ik, maar het is zonde om proactief een SWW te plannen, waarna alles afkoelt om vervolgens een uur later weer te gaan draaien. Dan kan hij beter een uurtje wachten en de SWW run starten zodat hij op de legionella tijd tegen de 60 graden is en dit in slechts 1 run kan doen.

@xoror Legionella draait bij mij iedere zondag om 1 uur, lijkt me eenvoudig in te leren en kan gebruikt worden om niet onnodig extra SWW runs te hebben. Ik ben benieuwd naar de nieuwe feature!

[Ben(V)]

Binnen een uur koelt de boiler nauwelijks af.
Als we hier geen warm water gebruiken heeft hij 7 uur nodig om een graad in temperatuur te dalen.

[_RRM_]

Ben(V) schreef op maandag 7 september 2026 @ 18:30:
Binnen een uur koelt de boiler nauwelijks af.
Als we hier geen warm water gebruiken heeft hij 7 uur nodig om een graad in temperatuur te dalen.

@Quitoo Afkoelen gaat inderdaad niet zo snel. Ook al voelt het dubbel en is het niet één run de warmte blijft wel even opgeslagen.

Als je het verbruik van SWW/legionella afzet tegen verwaming dan is bij mij het een relatief klein deel. De winst zal voor mij beperkt blijven. Optimalisering voor verwarmen mag voor mij wat hoger op de lijst blijven staan. (ook al heb ik ook een SWW run in HA staan in de 2 uur voor LPP)

[xoror]

Bij mij is dhw ook maar 10% van totaal, maar ging mij eigenlijk om de legionella, dat hakt er wel in als hij 3.5 uur even niet kan verwarmen in de winter.

@tromphakvoort kan je deze build https://github.com/gekkek...eleases/tag/2026-09-07.01 testen ? Het blijkt dat bij een cylinder unit de dhw tank temp probes omgekeerd zijn, daardoor triggert de 'bovenste' te snel via Odin. Bij gemiddeld merk je het niet.

[Loonen138]

Ik wil graag, vanuit home assistant, het stroom verbruik monitoren van de Ecodan.
Wat is het verschil tussen deze 3 sensoren? Pump is DHW en output power is verwarmen\koelen?

sensor.ecodan_heatpump_pump_consumption
sensor.ecodan_heatpump_estimated_output_power
sensor.ecodan_heatpump_output_power

[xoror]

Loonen138 schreef op maandag 7 september 2026 @ 21:44:
Ik wil graag, vanuit home assistant, het stroom verbruik monitoren van de Ecodan.
Wat is het verschil tussen deze 3 sensoren? Pump is DHW en output power is verwarmen\koelen?

sensor.ecodan_heatpump_pump_consumption
sensor.ecodan_heatpump_estimated_output_power
sensor.ecodan_heatpump_output_power

sensor.ecodan_heatpump_pump_consumption : water pomp verbruik
sensor.ecodan_heatpump_estimated_output_power: actueel opgewekt vermogen door mij berekend
sensor.ecodan_heatpump_output_power: getal hierboven, maar dan door de WP geschat

voor consumption wil je kijken naar:
sensor.ecodan_heatpump_reported_total_daily_energy_consumption

Dat is het geschatte opgenomen vermogen volgens de WP gedurende de dag. Dat zou je nog op moeten splitsen per mode. In dit topic staan er wel scripts voor.

Maar dat kan soms wel 15% afwijken. Het is wel een goede indicatie. Een echte meter is natuurlijk het beste.

[bilgy_no1]

Vandaag iets mafs. Ik schrok enorm van het hoge verbruik vandaag in huis. Bij de warmtepomp zag ik dat de Legionella had gedraaid. Op zich niet raar, maar het viel me op dat de booster daarna nog bijna 3 uur heeft gedraaid daarvoor. Dat heb ik nog niet eerder zo lang gezien.



Ik zie in Asgard nu ook Legionella opties staan. Die heb ik nog niet aangepast. Heeft het wellicht daarmee te maken?

Ik zie overigens in de Monitor nooit echt verbruiksdata en een COP. Moet daar wel bij zeggen dat de Heating en Cooling allebei op Prohibit staan, dus alleen de SWW draait nu.

[ Voor 10% gewijzigd door bilgy_no1 op 08-09-2026 22:03 ]

[xoror]

@bilgy_no1
Legionella bij Ecodan is niet so 'slim'. Het bestaat uit 2 delen
1. verwarm t/m huidige dhw setpoint (!)
2. doe de rest t/m legionella setpoint op de booster

Ws zag je 2 hier aan het werk. De feature die je kan aanvinken in Asgard, is om automatisch tot bijv 56 (of wat je ingesteld hebt) te doen en alleen het laatste stukje op de booster.

[Ben(V)]

Fijn dat het nu in de Asgard zit.
Kan mijn HA automatisering er weer uit.

[bilgy_no1]

xoror schreef op dinsdag 8 september 2026 @ 22:48:
@bilgy_no1
Legionella bij Ecodan is niet so 'slim'. Het bestaat uit 2 delen
1. verwarm t/m huidige dhw setpoint (!)
2. doe de rest t/m legionella setpoint op de booster

Ws zag je 2 hier aan het werk. De feature die je kan aanvinken in Asgard, is om automatisch tot bijv 56 (of wat je ingesteld hebt) te doen en alleen het laatste stukje op de booster.

Ja, dat klopt. Maar hij heeft dus zo te zien 3 uur lang de booster gedraaid als ik de grafiek goed begrijp. En daarvoor zie je de spike van het verwarmen met de wp tot de SWW setpoint.

Dat het nog 3 uur duurt om met de booster van 50°C naar 60°C te geraken heb ik nog niet eerder gezien.

Maar dat heeft dus niet met die nieuwe instelling te maken? Want als ik jouw uitleg begrijp doet hij dan precies wat er gisteren is gebeurd: eerst met wp verwarmen tot setpoint en daarna met booster tot legionella setpoint.

Het lijkt er wel op dat Odin de SWW goed had ingepland op het goedkope moment, alleen die 3 uur Booster er achteraan werd best wel duur.

[Ben(V)]

Kijk eens naar de "duration of max temp".
Is die misschien op een vage manier op 3 uur komen te staan?
Die kun je alleen in de MRC instellen.

[xoror]

@bilgy_no1 Nee de nieuwe instelling als je niet expliciet aanzet doet hij niets. De nieuwe instelling voorkomt juist te lange booster run.

Wat ik me net bedacht is dat ik met de laatste Asgard voor cylinder units nu de dhw tank temp had gefixed. Ik pakt de verkeerde als top sensor, maar als je gemiddeld top+bottom gebruikt had je er ook nooit last van.

even mededeling voor Odin gebruikers: bij entsoe gaat het niet helemaal lekker deze week met upgrades. Ik zal proberen voor NL weer een json te maken en zal die hier plaatsen
https://transparency.ents...90-4f53-a4c4-4cad6af81319

[ Voor 23% gewijzigd door xoror op 09-09-2026 12:54 ]

[bilgy_no1]

xoror schreef op woensdag 9 september 2026 @ 12:14:
@bilgy_no1 Nee de nieuwe instelling als je niet expliciet aanzet doet hij niets. De nieuwe instelling voorkomt juist te lange booster run.

Wat ik me net bedacht is dat ik met de laatste Asgard voor cylinder units nu de dhw tank temp had gefixed. Ik pakt de verkeerde als top sensor, maar als je gemiddeld top+bottom gebruikt had je er ook nooit last van.

even mededeling voor Odin gebruikers: bij entsoe gaat het niet helemaal lekker deze week met upgrades. Ik zal proberen voor NL weer een json te maken en zal die hier plaatsen
https://transparency.ents...90-4f53-a4c4-4cad6af81319

Ik zie uit de boiler 1 draad van temp. sensor naar de binnenunit lopen. Die ziet op ongeveer 2/3 hoogte. Er is nog een poort op ongeveer 1/3, maar daar is geen draad aangesloten.

In Asgard zie ik nu 57,5°C staan bij "SWW Huidige temperatuur". Via Home Assistant lees ik ook uit "SWW 2e temp sensor" met als waarde 25.0°C.

Kan het zijn dat bij de Legionella gisteren deze twee waarden zijn gemiddeld en daardoor zo lang de booster werd gebruikt?

Voor de gewone SWW run heb ik dit probleem niet geconstateerd. In Asgard bij Settings staat ook gewoon die 57,5°C. En die staat na SWW gewoon op 52°C (setpoint 50°C + een kleine overshoot).

Ik zie nu een update staan bij Odin. Als ik die doe, dan instellen op 1 temp sensor en dan de bovenste?

[xoror]

Hmm dan heb je een losse dhw tank, dan ging dat altijd al goed. Heb je legionella setting op Top of average staan? Maar die change is alleen voor cylinder units. Jij moet Top instellen, want jij hebt geen 2e sensor aangesloten

Kijk tot hoever hij op de compressor heeft verwarmd, komt dat overeen met je dhw setpoint? Dan is het een reguliere legionella run. Dat heeft altijd zo gewerkt. Asgard/Odin kan ook geen legionella run triggeren helaas.

van 52c -> 60c kost wel een goed aantal uren. Als er dan ook iemand tijdens doucht of en bad neemt, dan duurt dat alleen nog maar langer...

[ Voor 5% gewijzigd door xoror op 09-09-2026 14:51 ]

[bilgy_no1]

xoror schreef op woensdag 9 september 2026 @ 14:48:
Hmm dan heb je een losse dhw tank, dan ging dat altijd al goed. Heb je legionella setting op Top of average staan? Maar die change is alleen voor cylinder units. Jij moet Top instellen, want jij hebt geen 2e sensor aangesloten

Kijk tot hoever hij op de compressor heeft verwarmd, komt dat overeen met je dhw setpoint? Dan is het een reguliere legionella run. Dat heeft altijd zo gewerkt. Asgard/Odin kan ook geen legionella run triggeren helaas.

van 52c -> 60c kost wel een goed aantal uren. Als er dan ook iemand tijdens doucht of en bad neemt, dan duurt dat alleen nog maar langer...

Ja het is een losse DHW tank inderdaad van 300L. Op de grafiek zie ik dat hij met de compressor is verwarmd tot:

• Feed: 57,5
• Return: 49,0
• DHW setpoint is 50° meestal na een DHW run is het 52° als die klaar is.
• Daarna in een gestage lijn opgewarmd tot 63,0° Feed en 61,5° Return. Dit duurde dus 3 uur op de Booster.

Ik was niet thuis toen de Legionella draaide. Weet niet of er precies tijdens dat moment iemand ging douchen. Misschien wel, want de temperatuur van Feed en Return dipte na die compressor run weer naar 50°C om vanaf daar weer op te lopen terwijl de Booster draaide. Ik zal het eens vragen. Zou wel heel toevallig zijn en bovendien was het om 14:30 uur, niet echt een normaal douche tijdstip hier.



Die Legionella setting is in de binnenunit toch? Ik zal dat morgen even nakijken.

[xoror]

Moet je anders even vorige legionella runs nakijken en vergelijken. Want van 50-52 -> naar 60c duurt meestal wel een tijdje.

[Ben(V)]

Ik heb maar een 200L boiler, maar op de booster duurt het hier maar een uur om van 45^o naar 60^o te komen.
De booster trekt wel 2kW als hij daarmee bezig is.

Ik zou toch maar eens kijken of die 3 uur niet de instelling is dat hij de boiler op legionella temperatuur moet houden.

[bilgy_no1]

Ben(V) schreef op donderdag 10 september 2026 @ 09:59:
Ik heb maar een 200L boiler, maar op de booster duurt het hier maar een uur om van 45^o naar 60^o te komen.
De booster trekt wel 2kW als hij daarmee bezig is.

Ik zou toch maar eens kijken of die 3 uur niet de instelling is dat hij de boiler op legionella temperatuur moet houden.

Ja dat heb ik eerder inderdaad ook niet zo lang gezien. Ik heb helaas geen data van eerdere runs opgeslagen om te vergelijken.

Maar ik heb ook niet in dat menu zitten pielen en dat verandert niet uit zichzelf... Maar ik check het wel eventjes. In elk geval ben ik blij dat hij niet vanavond om 19h45 begon...

[Ben(V)]

Ik heb het hier een keer gehad dat instellingen uit zichzelf weg waren, kreeg pas terug toen ik de Ecodan een tijdje helemaal uitgezet had (dus uit en dan van de spanning af) voor de boel weer normaal werkte.
Dus ik kijk nergens meer van op.

[hesselbeertje]

Ik heb vanmiddag mijn Asgard gekregen en aangesloten, ziet er echt super uit! Heb de virtuele thermostaat gebruikt, die stuurt de WP keurig aan als ik aanpas via het dashboard.

Ik probeer nu de settemp van Z1 aan te passen via een CURL commando, als ik post gaat dat goed, als ik vervolgens via GET opvraag krijg ik ook de nieuwe waarde, maar de Asgard doet er niets mee. Is ook niet in het dashboard zichtbaar dat er iets wijzigt.

Wat doe ik fout?

[ Voor 12% gewijzigd door hesselbeertje op 12-09-2026 20:49 ]

[xoror]

@hesselbeertje Welk commando stuur je? Ik vermoed dat je de virtual thermostat nog moet vertellen welke bron hij moet gebruiken. Ik gok dat je punt 2 https://github.com/gekkek.../main/asgard/sa-config.md moet instellen?

[hesselbeertje]

xoror schreef op zaterdag 12 september 2026 @ 20:55:
@hesselbeertje Welk commando stuur je? Ik vermoed dat je de virtual thermostat nog moet vertellen welke bron hij moet gebruiken. Ik gok dat je punt 2 https://github.com/gekkek.../main/asgard/sa-config.md moet instellen?

Voor de sensor gebruik ik (nu nog even) de Mitsu thermostaat. Digitale sensor komt er nog aan. Maar het gaat mij om het wijzigen van het setpoint.

Ik stuur bijvoorbeeld curl -X POST "http://ecodan-heatpump.local/number/Virtual%20Thermostat%20Input%20z1/set?value=21.5" -d ""

Als ik daarna curl -X GET "http://ecodan-heatpump.local/number/Virtual%20Thermostat%20Input%20z1" stuur, krijg ik ook steeds de daarvoor ingestelde waarde terug.

Echter, het setpoint van de Virtual Thermostat doet er niets mee.

Of begrijp ik verkeerd? Met deze opdrachten zou je toch het setpoint aan moeten kunnen passen?

[ Voor 4% gewijzigd door hesselbeertje op 12-09-2026 21:00 ]

[xoror]

die post is voor "current" dus je temp sensor. Je digitale sensor koppel je daar aan. Dat is je huidige zone temp.

Als je setpoint (dus gewenste zone temp) wilt instellen, dan moet je de z1 climate aansturen.

code:

curl -X POST "http://ecodan-heatpump.local/climate/Virtual%20Thermostat%20z1/set?target_temperature=21.5" -d ""

# haal alle attributen op
curl -X GET "http://ecodan-heatpump.local/climate/Virtual%20Thermostat%20z1"

Zie esphome hoe je alles kan instellen, ik had alleen voorbeelden gegeven om de temperatuur sensor te linken. Je moet niet current_temerature direct via de climates gaan zetten, maar altijd via die input velden zoals in het voorbeeld

[ Voor 10% gewijzigd door xoror op 12-09-2026 21:09 ]

[hesselbeertje]

xoror schreef op zaterdag 12 september 2026 @ 21:08:
die post is voor "current" dus je temp sensor. Je digitale sensor koppel je daar aan. Dat is je huidige zone temp.

Als je setpoint (dus gewenste zone temp) wilt instellen, dan moet je de z1 climate aansturen.

code:

curl -X POST "http://ecodan-heatpump.local/climate/Virtual%20Thermostat%20z1/set?target_temperature=21.5" -d ""

# haal alle attributen op
curl -X GET "http://ecodan-heatpump.local/climate/Virtual%20Thermostat%20z1"

Zie esphome hoe je alles kan instellen, ik had alleen voorbeelden gegeven om de temperatuur sensor te linken

Ah dank je, dat werkt inderdaad!

Ik ga er nog maar eens even verder mee puzzelen. Dank voor je snelle hulp!

[John.S]

Ik krijg voor vandaag geen nieuwe prijzen binnen vanuit Entso-e. Als ik hem overzet naar energy charts blijft Odin een melding geven dat hij geen API key heeft voor Entso-e (want Energy charts is actief), en zie hem vervolgens niet zoeken naar Energy charts. Hebben meerdere nog last van de Entso-e storing en dit Odin gedrag ?

Na even gewacht te hebben, en Entso-e teruggezet te hebben als bron.. zie ik hem wel zoeken naar Energy charts… echter een 404.

Beide bronnen werken nu niet. Entso-e is te verklaren. Energy charts echter nog niet voor mij (geeft een 404 terug).

JSON:

W (209900896) [2026-09-13 06:46:39.423] FETCH: ENTSO-E: host=external-api.tp.entsoe.eu low count (0). Payload: <?xml version="1.0" encoding="UTF-8"?>
<Acknowledgement_MarketDocument
    xmlns="urn:iec62325.351:tc57wg16:451-1:acknowledgementdocument:7:0">
    <mRID>2d42bc14-bf1a-4</mRIDE (209900916) [2026-09-13 06:46:39.446] FETCH: ENTSO-E: both hosts failed for BZN=NL
W (209900926) [2026-09-13 06:46:39.455] FETCH: ENTSO-E retry failed — trying Energy-Charts fallback
I (209900936) [2026-09-13 06:46:39.464] FETCH: Energy-Charts URL: https://api.energy-charts.info/price?bzn=NL&start=2026-09-13&end=2026-09-14
I (209902146) [2026-09-13 06:46:40.668] esp-x509-crt-bundle: Certificate validated
E (209902686) [2026-09-13 06:46:41.213] FETCH: Energy-Charts fetch failed! HTTP status: 404

[ Voor 62% gewijzigd door John.S op 13-09-2026 07:21 ]

[xoror]

@John.S Onafhankelijk van wat je kiest, proberen we altijd ook de andere optie als de gekozen optie faalt. Etnso-e is bezig met een migratie en dat lijkt niet lekker te gaan.

Energy charts haalt ook uiteindelijk data bij de 'bron' Entso-e, dus die gaat ook geen data geven...

Je kan als je geen prijzen hebt, even deze workaround gebruiken: https://github.com/gekkekoe/heatpump-optimizer/issues/1

[ Voor 15% gewijzigd door xoror op 13-09-2026 08:57 ]

[John.S]

xoror schreef op zondag 13 september 2026 @ 08:48:
@John.S Onafhankelijk van wat je kiest, proberen we altijd ook de andere optie als de gekozen optie faalt. Etnso-e is bezig met een migratie en dat lijkt niet lekker te gaan.

Energy charts haalt ook uiteindelijk data bij de 'bron' Entso-e, dus die gaat ook geen data geven...

Je kan als je geen prijzen hebt, even deze workaround gebruiken: https://github.com/gekkekoe/heatpump-optimizer/issues/1

@xoror bedankt voor de uitleg! Vanuit EVCC maak ik ook gebruik van Energy charts, en die heeft wel data gekregen, maar ook niet voor alles zie ik nu (feed in niet).

[John.S]

@xoror is het misschien een idee om epexprijzen.nl als optie toe te voegen? Die lijkt een andere bron te hebben, want die hebben in het algemeen geen issues wanneer entso-e dat wel heeft. Dan heb je daadwerkelijk een fallback en ook nog per energieleverancier.

[xoror]

@John.S Ik moet uitzoeken of dat mag van de voorwaarden. Vaak is dat niet toegestaan. Of tegen exorbitante kosten (nordpool)

"De brondata komt van ENTSO-e en wordt verkregen via https://transparency.entsoe.eu/."
;-)

[ Voor 37% gewijzigd door xoror op 13-09-2026 10:47 ]

[Udouble]

Sinds gisteren draait Asgard hier op een Mitsubishi Ecodan PUZ-SWM100YAA met ERST30F-YM9EE boiler, FTC-regelaar en twee kringen. Tweezone-programmatuur, kring 2 geeft nu eindelijk kloppende waarden. Dank daarvoor.
Paar vragen:

• Mijn buitenvoeler hangt in de zon en leest daardoor structureel een graad of zeven te hoog. In Home Assistant heb ik wel een betrouwbare buitentemperatuur uit het weerbericht. Kan ik die van buitenaf aan Asgard doorgeven, zoals dat met de kamertemperatuur kan via de virtuele thermostaat? Ik vind geen instelpunt voor de buitentemperatuur. Zo niet: hoe gevoelig zijn auto-adaptief en ODIN voor een afwijking van die orde?
• Vandaag zet mijn eigen sturing bij verwarmen de werkstand op Verwarmen Ruimte. Werkt auto-adaptief in die stand, of moet dat Verwarmen Flow zijn?
• Bij koelen laat ik de watertemperatuur meeschuiven met het dauwpunt in huis. Zo blijft het koelen draaien op een drukkende dag in plaats van stil te vallen. Asgard kent het vocht binnen niet. Als ik de minimale aanvoertemperatuur koelen vanuit Home Assistant laat meeschuiven met het dauwpunt, respecteert auto-adaptief die ondergrens dan altijd? Of stuurt ze in bepaalde gevallen toch lager?

[ Voor 32% gewijzigd door Udouble op 13-09-2026 11:33 ]

[John.S]

xoror schreef op zondag 13 september 2026 @ 10:44:
@John.S Ik moet uitzoeken of dat mag van de voorwaarden. Vaak is dat niet toegestaan. Of tegen exorbitante kosten (nordpool)

"De brondata komt van ENTSO-e en wordt verkregen via https://transparency.entsoe.eu/."
;-)

Dan snap ik wel dat ze zo nu en dan wat uitdaging in het schalen hebben… veel lijkt afhankelijk van hen

[xoror]

@Udouble Welkom!

- auto adaptive koelen: https://github.com/gekkek...ecodan-hp/discussions/356
- De ruimte regeling is een mitsubishi regeling, daar werkt mijn auto adaptive niet mee. Het moet dus echt cool flow zijn
- Auto adaptive heeft vrij weinig last van de buiten temp sensor. Het enige moment waar je last van hebt, is bij defrost, maar daar onthou ik wat de temp was. Mijn auto adaptive werkt op ruimte temperatuur. Odin kijkt naar actuele weer op je gps locatie, dus dat is niet van toepassing. Niet te druk om maken dus, mijn unit staat ook vol in de zon.

[ Voor 7% gewijzigd door xoror op 13-09-2026 12:02 ]

[xoror]

Update over de komende Odin:
- Ik heb de legionella emulatie getest op mijn R410a unit en het lijkt best redelijk te werken.
- trigger was om 13.00 (was goedkoopste punt gisteren, omdat legionella gisteren moest plaats vinden)
- tank temp werd van 40c naar 61c gebracht, en stond meer dan 15 m op tenminste 60c. Dus de emulatie lijkt te werken. Straks kan je kiezen tussen de legionella van het systeem als mijn eigen. Het voordeel is dat we nu weten hoeveel tijd wegvalt voor de legionella in de planning.
- Ik had verwacht dat hij de booster wel nodig zou hebben, maar hij heeft het alleen op de compressor gedaan

[John.S]

xoror schreef op maandag 14 september 2026 @ 10:15:
Update over de komende Odin:
- Ik heb de legionella emulatie getest op mijn R410a unit en het lijkt best redelijk te werken.
- trigger was om 13.00 (was goedkoopste punt gisteren, omdat legionella gisteren moest plaats vinden)
- tank temp werd van 40c naar 61c gebracht, en stond meer dan 15 m op tenminste 60c. Dus de emulatie lijkt te werken. Straks kan je kiezen tussen de legionella van het systeem als mijn eigen. Het voordeel is dat we nu weten hoeveel tijd wegvalt voor de legionella in de planning.
- Ik had verwacht dat hij de booster wel nodig zou hebben, maar hij heeft het alleen op de compressor gedaan

[Afbeelding]

[Afbeelding]

Klinkt heel goed. Zou het misschien ook kunnen als optie: gebruik het element vanaf temperatuur x ? Daarmee voorkom je ook een stuk slijtage op de compressor.

[xoror]

@John.S We hebben geen invloed op de booster, en ik ben aan het uitzoeken of het echt wel zo slecht is als we denken: xoror in "Mitsubishi Electric Ecodan Lucht/Water Warmtepompen"

[xoror]

Wat meer info gepost over Odin 2.0
https://github.com/gekkek...ecodan-hp/discussions/408

[ReseT]

Vandaag iets wat ik niet kan verklaren. Waarom start mijn WP met verwarmen met Auto Adaptive als de target 2 graden lager is dan de kamer temperatuur?

• Begon beetje dezelfde tijd toen mijn PAR-WT60R-E error 3 gaf. Denk batterijen leeg, dus die zijn aan het opladen. Thermostaat is dus disconnected. Error J1 op de FTC7.
• Ik draai de esp32s3-proxy2-z1-en-2026-09-08-01

[xoror]

@ReseT Ik stuur demand niet aan als je geen virtual thermostats gebruikt.

Je wireless thermostaat ligt eruit, ik weet niet wat het systeem dan doet. Ws valt hij terug op de MRC, maar who knows.

[ReseT]

Bedoel je met MRC de FTC7 of de PAC? 

Ik denk dat ik je howto niet snap. Met als de MRC (mitsu remote controller) niet de PAC (een mitsu wireless thermostat) is, dacht ik ook deze stappen te kunnen skippen.

https://github.com/gekkekoe/esphome-ecodan-hp/blob/main/docs/auto-adaptive.md#step-2-set-up-the-temperature-feedback-loop

Waar haalt esphome de temp feedback loop op en wat zou dan room temperature source moeten zijn?

Mijn huidige atomations halen de PAC temperature op en synct ze met: number.ecodan_heatpump_auto_adaptive_current_room_temperature_feedback_z1

Opvallend is dat de PAC ook geen feedback geeft dat de WP in heating mode staat.

Nu ook de operating mode heat target temperature gezet, dat gaf weer controle over het systeem.

[xoror]

feedback loop is puur voor AA om te weten wat je ruimte temp is. Als je geen virtual thermostat gebruikt, dan bepaalt de FTC demand. Dus zonder virtual thermostat is de FTC verantwoordelijk voor het demand signaal.

Als je een wireless thermostat heb geïnstalleerd, dan zorgt die voor demand. Als die weg valt weet ik niet wat er dan gekozen wordt. MRC = hoofd bediening, dat scherm wat meestal op je binnen unit zit. Daar zit ook een temp sensor in.

Bij target temp (AA regeling van mitsu) gebruikt hij MRC of wireless. Ws valt hij dan terug op je MRC. Misschien staat er wat over in de documentatie.

[xoror]

De monthly overview begint ook vorm te krijgen in Odin 2.0

[HeJ]

Goedendag,
na een zomer met solar only cooling, dank aan ODIN!!, begint de kamertemperatuur te dalen en willen we terug naar heating.
Die wordt echter niet geactiveerd, ODIN blijft 'coasting' ondanks dat de gewenste range niet gehaald wordt.
Asgard: heat flow temperature / prohibit control uit op Z1 heating, aan op Z1 cooling
ODIN: fixed rate stroom (0.251) / 'cheap' Threshold: 0.05 / Stop Price: 0 / min.solar coverage: 75 / kwh penalty: 0.5
Wat heb ik fout ingesteld?
(ps: ik ben dag/nacht stroom, maar dat krijg ik niet ingesteld. Is dat wel mogelijk?)
Thx,
Hein

[xoror]

@HeJ Moet je even debug.json doorsturen. Maar als ik het zo moet gokken schat hij dat je temp binnen 3 uur in de bandbreedte valt, en dan zal hij niet overgaan tot verwarmen (immers binnen 3 uur is het hersteld). Dit is denk ik je eerste seizoen verwarmen? Dan moet hij even een paar dagen verwarming zien en leren.

Wat betreft bandbreedte, die is best smal, tenzij je heel goed geïsoleerde woning hebt, zal dat niet zo'n goede bandbreedte zijn.

Hier zijn we nog aan het koelen, maar dat zal binnenkort ook wel naar verwarmen gaan:

*Ook leuk om te zien dat zo om 13:00 de legionella emulatie is ingepland

Voor dag en nachtstroom, kan je dat via de api uploaden. zie https://github.com/gekkek...--pushing-prices--weather dan kan je gewoon per uur definiëren wat de prijzen zijn. Zoiets moet het worden https://github.com/gekkekoe/heatpump-optimizer/issues/1
Je moet voor nu even een automation maken die dit elke dag upload, omdat manual api prijzen dagelijks zijn. In de toekomst kan er evt een vinkje worden toegevoegd dat het prijs schema voor elke dag geldt.

[ Voor 33% gewijzigd door xoror op 20-09-2026 12:19 ]

[HeJ]

xoror schreef op zondag 20 september 2026 @ 12:11:
@HeJ Moet je even debug.json doorsturen. Maar als ik het zo moet gokken schat hij dat je temp binnen 3 uur in de bandbreedte valt, en dan zal hij niet overgaan tot verwarmen (immers binnen 3 uur is het hersteld). Dit is denk ik je eerste seizoen verwarmen? Dan moet hij even een paar dagen verwarming zien en leren.

Wat betreft bandbreedte, die is best smal, tenzij je heel goed geïsoleerde woning hebt, zal dat niet zo'n goede bandbreedte zijn.

Voor dag en nachtstroom, kan je dat via de api uploaden. zie https://github.com/gekkek...--pushing-prices--weather dan kan je gewoon per uur definiëren wat de prijzen zijn. Zoiets moet het worden https://github.com/gekkekoe/heatpump-optimizer/issues/1
Je moet voor nu even een automation maken die dit elke dag upload, omdat manual api prijzen dagelijks zijn. In de toekomst kan er evt een vinkje worden toegevoegd dat het prijs schema voor elke dag geldt.

Bedankt voor snelle reactie.
Is inderdaad eerste seizoen verwarmen, maar speelt al langer:
Hoe krijg ik de Debug gedeeld, ik zie niet hoe ik een bestand kan aanhangen. Hele content copy / paste?
Tav bandbreedte, zal ik eens aanpassen naar -0,5 / +1,5, zoals in manual.
Voor dag / nachtstroom zal ik eens gaan puzzelen, ben geen HA 'held'

[xoror]

Je stop price staat op 0. Moet negatief zijn volgens de tooltip. 0 is wel logischer, zal dat ook in latere versie aanpassen.

Reboot Asgard dan voert hij het direct uit ipv volgend uur

[HeJ]

Stop price in ODIN naar -1 aangepast, tooltip zegt '0 to disable' (IN v1.0.7-02)
Bandbreedte verruimd, Asgard is gereboot.
In Asgard is nu aangepaste bandbreedte zichtbaar, en bij tijdstip 15:00 rood gekleurd. Ben benieuwd.

[xoror]

@HeJ Ah zal even nakijken, ik draai 2.0 test, dan is de tooltip fout wellicht in de huidige release.

[Johnny_Hasselt]

HeJ schreef op zondag 20 september 2026 @ 12:02:
Goedendag,
na een zomer met solar only cooling, dank aan ODIN!!, begint de kamertemperatuur te dalen en willen we terug naar heating.
Die wordt echter niet geactiveerd, ODIN blijft 'coasting' ondanks dat de gewenste range niet gehaald wordt.
Asgard: heat flow temperature / prohibit control uit op Z1 heating, aan op Z1 cooling
ODIN: fixed rate stroom (0.251) / 'cheap' Threshold: 0.05 / Stop Price: 0 / min.solar coverage: 75 / kwh penalty: 0.5
[Afbeelding] Wat heb ik fout ingesteld?
(ps: ik ben dag/nacht stroom, maar dat krijg ik niet ingesteld. Is dat wel mogelijk?)
Thx,
Hein

Amaai, nu al verwarmen... Ik zit momenteel nog steeds boven de 23 graden...is wel lekker warm 🤗

Ik merk @xoror dat je bijna dezelfde dag als nacht setpoint hebt, dus je verwarming draait continue tijdens koude dagen in herfst en winter. Duurt het bij u dan zo lang eer je warmteafgifte hebt van uw vloerverwarming?

Van die setting instellingen moet ik nog bekijken hoe ik die instel, is ook mijn eerste stookseizoen met nieuwe warmtepomp, verbouwing waardat ik van mijn veranda een leefveranda van gemaakt heb - dikke vloer isolatie enz... Dus zal wel nog wat trial en error worden....







Greetz, J

[ Voor 16% gewijzigd door Johnny_Hasselt op 20-09-2026 15:48 ]

[xoror]

@HeJ 0 zou ook moeten werken zie ik. Moet je even in de gaten houden of de verwarming nu goed gaat, en anders de debug even mailen. Je moet verder de bandbreedte instellen zoals je dat graag wilt zien. Smalle bandbreedte = meer comfort, minder te besparen omdat er weinig speelruimte is.

@Johnny_Hasselt We hebben veel thermische massa. Het duurt lang voor iets erbij komt of eraf gaat. Als we een dag niet verwarmen verliezen we in de winter ongeveer 1c.

De temperatuur moet je meer als bandbreedte bekijken, als het maar daar tussen zit is het ok. De ideale lijn is een soort hulpmiddel voor Odin om te weten wat het ideaal is. Hij stuurt daar wel op.

Ik verwacht dus dat Odin soms in de avond, soms overdag afhankelijk van zon en prijzen gaat verwarmen. In echte koude periodes denk ik inderdaad 24h per dag verwarmen. Hij kan dus eenvoudig hier bufferen en veel uren overbruggen.

Odin zal wel een hoop zelf leren, en je moet gewoon een bandbreedte instellen zoals je het wenst. Bij onduidelijkheden gewoon hier posten. Het kan best zijn dat bepaalde edge cases nog niet goed gaan. Zorg in ieder geval dat de volgende params correct zijn: min/max vermogen van je WP, stop price. De bandbreedte kan je aanpassen als je na verloop van tijd weet hoe je huis reageert, dan kan je het verder tweaken.

[Quitoo]

Het viel mij vanavond toevallig op dat er geen DHW heating gepland stond terwijl de boiler wel ruim onder target is. Hoe snel zou ODIN moeten reageren op een temperatuur drop?

Temperatuur was om kwart voor 7 gezakt van 46 naar 39 graden:

ODIN neemt om 8 uur nog steeds de 46 graden tank temperatuur mee in zijn optimalisatie run.

code:

=== NEW OPTIMIZATION REQUEST ===
W (2028623593) [2026-09-21 19:56:06.711] PHYSICS: HL: no heating data and no manual seed yet — using generic 0.15 kW/K default
W (2028623603) [2026-09-21 19:56:06.719] PHYSICS: Load ratio: no usable heating runtime data (prod=0.0 kWh, run=0.0 h)
I (2028623623) [2026-09-21 19:56:06.739] OPTIMIZER: Required memory: 51744 bytes for 6468 nodes.
I (2028623623) [2026-09-21 19:56:06.741] OPTIMIZER: DHW Urgency: Tank=46.0°C, Trigger=47.0°C, Hard Min=35.0°C.
I (2028623623) [2026-09-21 19:56:06.748] OPTIMIZER: DHW pre-pass: hour 27 chosen (score=0.356)
I (2028623713) [2026-09-21 19:56:06.838] OPTIMIZER: DHW stamped at hour 27: recover=11.7C, V=200L, COP=2.48, 1.09 kWh elec, 0.3975 EUR
I (2028623723) [2026-09-21 19:56:06.839] ODIN_SERVER: === MEMORY CHECK ===
I (2028623723) [2026-09-21 19:56:06.845] ODIN_SERVER: Free RAM before solve: 7126540 bytes
I (2028623733) [2026-09-21 19:56:06.853] ODIN_SERVER: Free RAM after solve : 7124652 bytes
I (2028623743) [2026-09-21 19:56:06.861] ODIN_SERVER: Lowest RAM ever seen : 6948464 bytes
I (2028623753) [2026-09-21 19:56:06.869] ODIN_SERVER: ======================
I (2028623753) [2026-09-21 19:56:06.876] ODIN_SERVER: Projected 24h Cons: 4.78 kWh, Prod: 18.51 kWh, Solar: 3.69 kWh, Cost: ~€0.40
I (2028623763) [2026-09-21 19:56:06.888] ODIN_SERVER: === OPTIMIZATION COMPLETE (110 ms) | states=141 | nodes=15717/576549 (97% pruned) ===

W (2030358493) [2026-09-21 20:25:01.602] httpd_uri: httpd_uri: URI '/favicon.ico' not found
W (2030358493) [2026-09-21 20:25:01.602] httpd_txrx: httpd_resp_send_err: 404 Not Found - Nothing matches the given URI

[xoror]

@Quitoo Hij dropt wel snel, wat ik even niet snap is het volgende:

code:

I (2028623623) [2026-09-21 19:56:06.741] OPTIMIZER: DHW Urgency: Tank=46.0°C, Trigger=47.0°C, Hard Min=35.0°C.
I (2028623623) [2026-09-21 19:56:06.748] OPTIMIZER: DHW pre-pass: hour 27 chosen (score=0.356)
I (2028623713) [2026-09-21 19:56:06.838] OPTIMIZER: DHW stamped at hour 27: recover=11.7C, V=200L, COP=2.48, 1.09 kWh elec, 0.3975 EUR

de 19:55 solve werkt met een tank temp van 46c, maar rond dat tijdstip is het al iets van 39c. Dus ergens is er iets niet goed, staat je wp klok goed?

[Djvdb]

@xoror ik heb een beetje door het topic heen gelezen maar is me nog niet duidelijk hoe ik aspecten zoals fan speed ook uit kan lezen. Ik heb een ftc7 icm suz-swm60va2 en heb momenteel service codes aanstaan.

[LigeTRy]

Al een tijdje niet meer actief in dit draadje, inmiddels wel in een verhitte discussie met de aannemer geraakt omdat de naregeling die ze hebben geinstalleerd (honeywell hcc100 op in1 op de ecodan) ervoor zorgt dat er enorm gependeld wordt als maar enkele kamers koeling/hitte vragen, de ecodan kan z'n energie dan simpelweg niet kwijt. Ik heb verteld dat ik hierachter ben gekomen doordat ik een data logging module heb geinstalleerd. Ofcourse is dat voor hun een mooi handvat geweest om te zeggen: je hebt er zelf mee lopen hannesen dus je garantie vervalt. Die discussie is nog niet klaar, maargoed, daarvoor is dit draadje niet, maar wou het even kwijt </rant>

Ik zie ondertussen (draai nu esp32s3-z1-en-2026-09-18.01) dat er in de code veel functies bij zijn gekomen. Ik draai op een esp32 (m5 atom) en niet asgard.

Afgelopen week op vakantie geweest en slim m'n DHW cycles uitgezet, totdat de interne legionella prevention cycle m'n water van 35 naar 60c is gaan stoken op de booster, 7kwh, das significant. Dus ik wil die legionella prevention beter inregelen (zoveel mogelijk buiten unit, booster voor het laatste stukje indien nodig. Ik zie in de settings nu Dynamic cost solver, maar in de discussions lijkt dit een asgard only functionaliteit. Over de Legionella: DHW Setpoint Automation kan ik ook alleen info vinden in de asgard docs. Betekent dit dat development voor de esp32 lijn (zoals m5 atom) hierop achter loopt en deze functies niet werken?

Ik volg de discussie hierboven graag, wellicht dat de logica duidelijker wordt en ik zelf m'n cycles in node red kan bouwen.

Verder nog steeds enorm blij met wat je allemaal hebt gemaakt @xoror

[Quitoo]

@xoror ja, de tijd klopt. Vanmiddag was hij ook al 2 uur gezakt onder de 35 voordat hij begon te verwarmen omdat hij nog met een oude waarde werkte.

Die snelle drops zie ik wel vaker met douchen of bad. Soms zakt het amper bij veel verbruik, soms veel bij relatief weinig.

[xoror]

@Djvdb Als je de service code kan opvragen dan zou het ook via de esp moeten kunnen. 019 moet je proberen, anders support je unit het niet.

@LigeTRy Voor de Atom kan je de automations gebruiken, die doen hetzelfde. Dit is voor mensen die standalone Asgard draaien en geen HA hebben om de legionella handiger te regelen.

@Quitoo Ik bedoel de klok/tijd op de Ecodan staat die goed ingesteld? Hoeveel liter DHW tank is er geïnstalleerd Kan je even kijken of het bij anderen ook zo is. Hier met 300L zakt het nauwelijks, totdat een groot van het vat koud water bevat en dan kan het wat sneller gaan. Maar 7c drop heb ik zelf nog niet gezien vandaar.
Draai je wel de laatste versie? Want er was een sensor fout waarbij in voor cylinder units de top/bottom omgedraaid had. Laatste officiële release moet het goed doen

[ Voor 20% gewijzigd door xoror op 22-09-2026 22:49 ]

[Djvdb]

xoror schreef op dinsdag 22 september 2026 @ 21:52:
@Djvdb Als je de service code kan opvragen dan zou het ook via de esp moeten kunnen. 019 moet je proberen, anders support je unit het niet.

Ik heb nu de wifi adapter van mitsubishi eraf gehaald en dan zie ik de waarden idd verschijnen. Is het ook mogelijk om de waarden te krijgen icm met de wifi adapter?

[xoror]

@Djvdb Dat is een bewuste design keuze. Ik wilde de proxy transparant (moet dus ook werken voor onbekende/nieuwe cmds) laten zijn. Als ik cmd stuur voor service codes hebben de melcloud adapters daar geen weet van. Het blokkeert ook iets een tijdje de communicatie. Dus kan ja, maar je moet het niet willen niet in deze opzet.

[The Source]

Ik wil deze winter mijn warmte pomp verbruik optimaliseren gezien ik op een variabel contract zit. Aangezien mijn energie planning door DAO aangestuurd wordt zal ik het daar wellicht bij plaatsen. Voorgaande jaren heb ik de temp stabiel gehoudne, afgelopen jaar heb ik via een vast schema gedraaid: 6h temp omhoog, 13h temp omhoog, 21 temp omlaag, 24h temp omlaag

Afgezien van Asgard, kan ik alles optimaliseren met de normale ESP oplossing? ik heb vloerverwarming en temp sensors in alle ruimte. Is er een linkje met tips waar ik rekening mee moet houden?

[Quitoo]

@xoror De datum en tijd staan goed in de ecodan en ik draai de laatste asgard en ODIN versies. 1 uur tijdsverschil komt door de zomertijd.

Dit waren de waarden van afgelopen nacht. Welke info heb je nodig om er achter te kunnen komen waar dit aan ligt?

Timestamp	Log Tank Temp	Measured Temp (Boiler Graph)	Verschil (Δ)	Trigger Temp	Hard Min
2026-09-24 00:55:11	47.0°C	~42.0°C	+5.0°C	47.0°C	35.0°C
2026-09-24 01:56:11	47.0°C	~41.5°C	+5.5°C	47.0°C	35.0°C
2026-09-24 02:56:12	46.5°C	~41.0°C	+5.5°C	47.0°C	35.0°C
2026-09-24 03:56:11	46.0°C	~41.0°C	+5.0°C	47.0°C	35.0°C
2026-09-24 04:55:11	46.0°C	~40.5°C	+5.5°C	47.0°C	35.0°C
2026-09-24 05:56:11	45.5°C	~40.0°C	+5.5°C	47.0°C	35.0°C

[xoror]

@Quitoo Heb je HA ook meedraaien? Kan je de grafiek posten van dhw tank temp en dhw secondary tank temp? Liefst van een dhw -> de volgende dhw.

De laatste update zou de sensoren nu goed moeten behandelen. Kan je kijken waarop je DHW opladen setting staat in de MRC ? Zie Verwijderd in "Mitsubishi Electric Ecodan Lucht/Water Warmtepompen" voor meer uitleg

Ik zeg niet dat het fout is, maar het verbaast mij een beetje. Dus even uitsluiten. Verder is er in de MRC een vinkje, om daylight savings in te stellen

Overigens vandaag ook maar de verwarming op heating gezet...

[ Voor 26% gewijzigd door xoror op 24-09-2026 12:07 ]

[Quitoo]

@xoror Hij gebruikt inderdaad de secondary temperature sensor. Odin staat ingesteld op top probe. Als ik vanavond thuis ben zal ik de settings even bekijken op de mrc

[xoror]

@The Source Je mist de hardware van Asgard, maar voor de rest zou je alles moeten kunnen wat niet afhankelijk is van die ontbrekende hardware. Je kan optimaliseren met eenvoudige regels tot een complexe solver (Odin) die 2 dagen vooruit kijkt. Voor het laatste zijn er geen scriptjes beschikbaar.

Ik denk dat je meer kans maakt bij DAO, dat daar meer mensen ermee bezig zijn.

@Quitoo De top sensor (wat secondary is bij cylinder units) wordt gebruikt om te bepalen wanneer er getriggerd wordt (omdat je top hebt gekozen). Dus mogelijk is dat niet gelijk aan je MRC setting. Dat moet dus wel gelijk zijn aan elkaar. In dit geval moet je dus controleren dat Odin de blauwe lijn gebruikt, dat verloop ziet er normaal uit.

[ Voor 4% gewijzigd door xoror op 24-09-2026 14:30 ]

[Quitoo]

@xoror mrc staat op standaard, dus dat zou goed moeten zijn. Hoe kan het dat hij dan alsnog de verkeerde sensor pakt? Ik kan geen andere instellingen vinden die hiermee te maken hebben.

In het HA dashboard wordt ook sensor.ecodan_heatpump_dhw_current_temp gebruikt ipv sensor.ecodan_heatpump_dhw_secondary_temp. Lees ik dan in HA alleen de verkeerde sensor uit en werkt alles gewoon prima?

[xoror]

Dan zou Odin de juiste moeten gebruiken. Moet een je stukje logging plakken met dhw zodat je kan zien wat hij pakt. Maar omdat je de 'boiler' temp post (onderste tank sensor) dan is het logisch dat je na gebruik flink zakt. Je bovenste sensor blijft stabiel. Je moet dus in jouw geval naar de secondary kijken (of in de dhw climate, daar wordt automatisch afhankelijk van je systeem de juiste afgebeeld)

Dan zal het gedrag wel verklaarbaar moeten zijn?

[Quitoo]

@xoror duidelijk! Misschien goed om het HP dashboard template voor home assistant te updaten, want deze verwijst naar sensor.ecodan_heatpump_dhw_current_temp ipv sensor.ecodan_heatpump_dhw_secondary_temp. Dat was de sensor waar ik altijd naar keek.



Bedankt voor de hulp!

[xoror]

@Quitoo nee, zo moet je het niet zien. Dan werkt het dus niet voor mensen zonder cylinder unit. Je moet naar de tank temp kijken op je dhw climate, die zou de bovenste tank temp moeten tonen afhankelijk van je installatie.

vervang dat DHW element door

YAML:

  - type: entity
        show_name: true
        show_state: true
        show_icon: true
        entity: climate.ecodan_heatpump_dhw_climate
        show_entity_picture: false
        state_content:
          - current_temperature
          - hvac_action
        name: DHW

voorbeeld dashboard is aangepast.

[ Voor 4% gewijzigd door xoror op 24-09-2026 20:57 ]

[xoror]

xoror schreef op woensdag 8 juli 2026 @ 14:12:
Even een huishoudelijke mededeling: Ook ik begin last te krijgen van de AI hype. Alle componenten die ook maar iets met DRAM te maken hebben, zijn explosief gestegen. Soms wel 10x - 15x omhoog gegaan. Gemiddeld zijn de inkoop kosten daardoor z'n 25% gestegen. De huidige batch absorbeer ik dat nog, maar de volgende batch moet ik de prijs helaas verhogen. Ik wil niemand dwingen/bang maken, maar dat jullie dat weten. Dus als je Asgard nog wilt, wacht niet te lang.

heads up: Nog 5 beschikbaar van deze batch

[xoror]

Odin 2.0 Beta is gestart: https://github.com/gekkek...ecodan-hp/discussions/416

Als je graag mee wilt doen, stuur mij dan een berichtje.