Mitsubishi Ecodan warmtepomp uitlezen via cn105 + esp32

[xoror]

@John.S Waar je naar wilt kijken is de liquid pipe(1) vs ambient. Dus je kijkt naar het verschil tussen de intrede verdamper en de buiten lucht. Als dat groot is, dan is je wp hard aan het werk (immers, je onttrekt of geeft veel warmte af).

Bij systemen waar problemen zijn zie je bij normale omstandigheden de liquidpipe temp ver weg zitten van je buiten temp. Bijv hier een voorbeeld, maar in het algemente topic kan je nog meer vinden

@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

[Zjemm]

@xoror

Even een gedachte, ik heb mn SWW op 50 staan en eens in de 12 of 14 (uit m'n hoofd) een legionella run.
Door deze instelling gaat hij eigenlijk maar heel kort op de compressor verwarmen en vrij snel de rest op het element doen. dat lijkt me inefficient.

zou het in asguard te implementeren zijn dat je op basis van je ingestelde legionella run schema, vlak van te voren het SWW setpoint wat omhoog zet, zodat hij langer op de compressor gaat verwarmen? En dan na de run weer terug

of levert dat niet veel op?

[xoror]

@Zjemm https://github.com/gekkek...tomations/legionella.yaml

Maar dan moet je HA draaien

[Zjemm]

ja met HA kan dat soswieso, ik vroeg me af of het interressant is om in asgard te implementeren?

[xoror]

@Zjemm Dat zou alleen voor stand alone users zijn, ik had het wel in mijn achterhoofd, maar nog geen tijd gehad, en twijfel of het wel in Asgard moet.

[Zjemm]

idd. nou kijk maar, het is een idee. je moet er ook maar net tijd en zo voor hebben

[Ben(V)]

Ik heb daar ook een HA script voor gemaakt, maar dat gebruik ik enkel als er geen zonnestroom is.
In de zomer is er toch een overschot aan elektriciteit beschikbaar hier.

Lijkt me niet zo zinvol om dat in Asgard te stoppen, te veel variabelen om rekening mee te houden die voor iedereen anders zijn.

[xoror]

@tromphakvoort Even hier verder.
Ik denk dat jouw trigger door gemiddelde wordt gedaan. Jouw voorbeeld sww was niet door Odin getriggerd namelijk (niet op het hele uur gestart, dan is het meestal niet door Odin gedaan)

Kan je van die run de beide tank temps en operation mode plotten? Dan kunnen we even kijken waarom en onder welke conditie het triggert

[tromphakvoort]

@xoror Hierbij de plot, ik draai inderdaad op mode Large (gemiddelde van de twee sensoren) sinds een tijdje (hebben we het destijds over gehad) maar denk dat die nu te vroeg triggert voor mijn warm water vraag. Weet alleen even niet of ik nu in ECO draai of niet, DHW ECO is aan maar DHW Mode staat op Normal, mogelijk dat hierdoor de WP zo hoog in de toeren loopt.

[xoror]

@tromphakvoort ook even je dhw settings? zo dat ik kan zien welke drop hij is ingesteld en setpoint

[tromphakvoort]

[xoror]

@tromphakvoort

ok dus gemiddeld zou dan: ~46 + ~44 = 45 gemiddeld.
dhw setpoint: 52, met drop van 8, dan gaat hij starten bij: 52-8 = 44
Ik gok dat ik die waarden niet goed heb bekeken, maar ws was het gemiddeld 44c.

Je moet denk ik meer drop doen vanwege je gemiddelde. Is er ook een reden dat je 52C dhw setpoint gebruikt? dat is best hoog

[tromphakvoort]

@xoror Niet perse, ik heb hem destijds op 52 gezet omdat we soms last hadden van koud water als er bijvoorbeeld twee man achter elkaar doucht. Maar ik denk zomaar met mode Large dat dit niet echt meer zal optreden dus misschien dat 50 of 48 nu ook wel voldoet al. Ga dat wel even testen, ik zal vanmiddag de drop even op 10 graden zetten. Of denk je dat een nog hogere drop kan?

[xoror]

@tromphakvoort ik zou 50c proberen met zelfde met 10c drop (zorg dat hij triggert op 40c oid). en als het goed gaat, kan je naar 49, 48, ... tot het niet meer gaat en dan +1c doen, dan zit je ok denk ik

[PeterMi]

Komt er voor de Asgard misschien nog ooit een instelling dat de DHW run calender en tijd gestuurd wordt. Deze functie werkt niet op de ftc6. De runs zijn vaak op ongunstige tijdstippen (dynamisch tarief) en ver weg van mijn douche beurten thuis. Dit zou mijn inziens een mooie toevoeging zijn.

[xoror]

@PeterMi Hoe zou dat moeten werken ? Want als je temp onder je drop komt dat gaat hij altijd af. Tenzij je iets van een prohibit erop zet, maar dan heb je kans op koude douche. Maar je moet dan wel met HA aan de slag (of zelf scripten en dan direct Asgard rest api aanspreken). Kom je niet uit met de reguliere week schema? Het nadeel is dat die natuurlijk altijd op het tijdstip start, maar die houdt geen rekening met de prijzen, al kan je erop gokken dat het rond 14:00-15:00 het goedkoopst is.

Ik denk niet dat het in Asgard goed te regelen valt. In Odin zit wel dhw planning icm dynamische prijzen. Ik heb sinds deze maand nu ook dynamisch tarief, en probeer alles op solar te doen. Hij probeert op de goedkope/gratis uren de tank te laden om de dure periode te overbruggen
Voor meer uitleg, zie hier

[PeterMi]

Ik zou idd willen dat ik standaard om de 3 en 4 dagen kan laden met een weekschema op de goedkope momenten. Dus niet perse echt t dynamische tarief volgen maar 'gokken' op de juiste tijd. Ons douche patroon is super goed voorspelbaar door ons vaste week ritme.

T reguliere weekschema werkt bij ons niet. Als ik programeer dat hij 2x in de week een dhw cyclus moet draaien op een bepaalde tijd doet ie dat gewoon iedere dag (wel op de juiste tijd).

Doe ik misschen wat fout. Zijn er mensen die dit wel werkend hebben gekregen op een ftc6.

[xoror]

ik denk dat je de handleiding even moet naslaan. Je kan met het week schema gewoon instellen welke dag en welke tijd hij start met dhw. Ik meen me te herinneren dat je dat gewoon voor elke dag kan instellen.

[xoror]

@Zjemm https://github.com/gekkek...eleases/tag/2026-08-16.02
Ik had het al een tijdje in mijn achterhoofd om de legionenella setpoint verhoging ook door te voeren voor stand alone users die geen HA hebben. Vanaf deze pre-release zit het erin, test het aub en report issues. Mijn legionella is helaas al afgegaan deze week.

[bilgy_no1]

xoror schreef op zondag 16 augustus 2026 @ 15:07:
@Zjemm https://github.com/gekkek...eleases/tag/2026-08-16.02
Ik had het al een tijdje in mijn achterhoofd om de legionenella setpoint verhoging ook door te voeren voor stand alone users die geen HA hebben. Vanaf deze pre-release zit het erin, test het aub en report issues. Mijn legionella is helaas al afgegaan deze week.

[Afbeelding]

Top. Ik zou dit het liefst automatisch zien gaan via Odin. Dus als Legionella binnen 48 uur nodig is dan zo gunstig mogelijk inplannen icm DHW run. Is zoiets mogelijk?

Een grote ergernis afgelopen jaren als ik probeerde de gunstigste uren te gebruiken dat Legionella doodleuk 's avonds om 20.00 uur tegen €0,45 z'n ding ging doen...

[ Voor 8% gewijzigd door bilgy_no1 op 16-08-2026 16:54 ]

[xoror]

staat wel op de planning voor wat er mogelijk is https://github.com/gekkek...ecodan-hp/discussions/395

We kunnen zelf niet de legionella starten helaas, maar wel rekening houden met. In het andere geval kan je natuurlijk zelf een legionella prevention maken. 60c voor 30m bijv. Maar dat kost wel weer veel tijd. Dus het eerste deel rekening houden met starten we mee.

[ Voor 66% gewijzigd door xoror op 16-08-2026 17:26 ]

[FrensDJ]

bilgy_no1 schreef op zondag 16 augustus 2026 @ 16:52:
[...]

Top. Ik zou dit het liefst automatisch zien gaan via Odin. Dus als Legionella binnen 48 uur nodig is dan zo gunstig mogelijk inplannen icm DHW run. Is zoiets mogelijk?

Een grote ergernis afgelopen jaren als ik probeerde de gunstigste uren te gebruiken dat Legionella doodleuk 's avonds om 20.00 uur tegen €0,45 z'n ding ging doen...

Legionella start tijd is in te stellen in de ecodan en door beetje met dagen te gaan spelen (minder of dagen tussen 2 rund) heb ik hem zover dat hij elke donderdag om 13:00 hem gaat doen

[bilgy_no1]

FrensDJ schreef op maandag 17 augustus 2026 @ 09:12:
[...]


Legionella start tijd is in te stellen in de ecodan en door beetje met dagen te gaan spelen (minder of dagen tussen 2 rund) heb ik hem zover dat hij elke donderdag om 13:00 hem gaat doen

Ik geloof niet dat ik die instelling in de Ecodan ooit heb kunnen vinden. Is dat misschien afhankelijk van het model? Ik las hierboven het antwoord dat je het niet zelf kunt starten.

Mooiste zou wmb zijn dat het vanuit Odin kan worden meegenomen... Maar ik begrijp uit het antwoord van xoror dat dit in eerste instantie alleen is dat de planning rekening houdt met het uitvoeren van de legionella run.

[xoror]

Legionella kan je instellen door long press te doen op die menu knop, dan zijn de settings editable. Kijk even in de handleiding.

Hier start het elke zondag 11.00 bijvoorbeeld. Maar je kan ook een keer per 2 weken etc doen

[bilgy_no1]

xoror schreef op maandag 17 augustus 2026 @ 11:04:
Legionella kan je instellen door long press te doen op die menu knop, dan zijn de settings editable. Kijk even in de handleiding.

Hier start het elke zondag 11.00 bijvoorbeeld. Maar je kan ook een keer per 2 weken etc doen

Thanks. Die maar eens bekijken dan. Ik had het destijds nog gevraagd aan de installateur...

[xoror]

bilgy_no1 schreef op maandag 17 augustus 2026 @ 11:20:
[...]

Thanks. Die maar eens bekijken dan. Ik had het destijds nog gevraagd aan de installateur...

Heeft hij/zij de rest wel goed geïnstalleerd? geen overbodige start/stops etc?

[bilgy_no1]

xoror schreef op maandag 17 augustus 2026 @ 12:13:
[...]

Heeft hij/zij de rest wel goed geïnstalleerd? geen overbodige start/stops etc?

Daarvoor heb ik nu Asgard en Odin 💪🏻

[tante Truus]

Ik heb vanmorgen de cooling omgezet naar heating. Dat heb ik gedaan op de MRC, maar ik zag zojuist dat in Asgard de modus nog op cooling stond. Zojuist in Asgard ook op heating gezet.
Ik zie nu iets vreemds met de virtual thermostat. Die geeft nu in Asgard de waarde 21,9 aan, terwijl deze in werkelijkheid 23,9 is. In HA staat het wel goed.



Waarom geeft Asgard een verkeerde current temp aan?

[tante Truus]

ik zie nu in de historie dat die 21,9 al langere tijd onveranderd is, ik begin te vermoeden sinds de laatste update?

[ Voor 26% gewijzigd door tante Truus op 17-08-2026 19:31 ]

[John.S]

tante Truus schreef op maandag 17 augustus 2026 @ 17:43:
Ik heb vanmorgen de cooling omgezet naar heating. Dat heb ik gedaan op de MRC, maar ik zag zojuist dat in Asgard de modus nog op cooling stond. Zojuist in Asgard ook op heating gezet.
Ik zie nu iets vreemds met de virtual thermostat. Die geeft nu in Asgard de waarde 21,9 aan, terwijl deze in werkelijkheid 23,9 is. In HA staat het wel goed.

[Afbeelding]

[Afbeelding]Waarom geeft Asgard een verkeerde current temp aan?

Er zit nog een automatisering tussen (blue print). Wat zegt de trace?

[tante Truus]

John.S, ik weet niet of je vraag begrijp, maar ik heb een Shelly in de woonkamer staan, en die geeft de werkelijke temperatuur door aan de Asgard (althans dat was zo, en nu niet meer).
Wat bedoel je met wat zegt de trace?

[John.S]

@tante Truus

Een automatisering zorgt ervoor dat je Shelly temp entiteit zijn waarde overgeeft aan Asgard (Esphome).

Kans bestaat dat Asgard niet (meer) uitgelezen wordt middels Esphome, of de automatisering loopt niet lekker die het plaatsen van de nieuwe waarde (temp) moet verzorgen.

Even het hele proces nogmaals doorlopen hoe je hem ook gekoppeld heb.

[tante Truus]

misschien dat dat het is, een aantal andere entiteiten werden niet meer herkend in HA en wellicht dat er zo ook een mismatch is ontstaan met de Shelly. Ik moet alleen weer even uitvogelen hoe ik m destijds gekoppeld/ingesteld heb.

[xoror]

Je hebt ws HA geupdate/aangepast? De sync zou gewoon moeten blijven werken bij mode change. Waarschijnlijk had je het via https://github.com/gekkek..._blueprints/setup_sync.md gedaan.

Wanneer je settings aanpast op de MRC, dan komen deze vanzelf binnen 1-2 minuten door naar je Asgard. Hij zou het gewoon uiteindelijk moeten zien.

[tante Truus]

@Xoror, ik heb idd HA aangepast. De reden was dat de nieuwste updates niet meer goed werkten op mijn Synology (geen ondersteuning meer van HA). Dat was gelijktijdig met de nieuwste Asgard firmwarerelease. Ik heb daarom een oude laptop omgebouwd naar linux/HA server en de backup van de oude HA gebruikt op de nieuwe.
Het bleek dat er hier en daar wat entiteiten niet meer klopten, maar omdat de temperatuur wel gewoon goed wordt weergegeven, geen vermoeden gehad dat de koppeling naar Asgard misschien niet meegenomen is. Ik heb gisteren de automatisering en blue print opnieuw ingesteld, en vandaag staat nu ook in Asgard de temp weer goed.
De aanpassing op de kamerthermostaat (dat is toch de MRC?) waren een paar uur later niet door Asgard overgenomen, maar Heat Flow Temperature staat weer voor en Thermostat mode staat op heat. (ik verwacht/hoop dat het nog een paar maanden duurt voordat de verwarming daadwerkelijk aan zal gaan).

[xoror]

De aanpassingen op de MRC komen als room thermostaat waarden door. Ze worden niet in de virtual thermostaat over genomen. Ik had ooit een automation gemaakt voor @_RRM_ die status beide kanten (mrc/wireless <-> virtual thermostat) op synced. Deze zou je kunnen proberen.

YAML:

alias: Sync target temp (Two-Way)
description: Keeps Zone 1 and Virtual Thermostat target temperatures in sync in both directions.
mode: single
triggers:
  - trigger: state
    entity_id: climate.ecodan_heatpump_zone_1_room_temp
    attribute: temperature
    id: "zone_1_changed"
  - trigger: state
    entity_id: climate.ecodan_heatpump_virtual_thermostat_z1
    attribute: temperature
    id: "virtual_changed"
conditions:
  - condition: template
    value_template: >-
      {{ state_attr('climate.ecodan_heatpump_zone_1_room_temp', 'temperature') | float(0) !=
         state_attr('climate.ecodan_heatpump_virtual_thermostat_z1', 'temperature') | float(0) }}
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: "zone_1_changed"
        sequence:
          - action: climate.set_temperature
            target:
              entity_id: climate.ecodan_heatpump_virtual_thermostat_z1
            data:
              temperature: "{{ trigger.to_state.attributes.temperature | float(0) }}"
      - conditions:
          - condition: trigger
            id: "virtual_changed"
        sequence:
          - action: climate.set_temperature
            target:
              entity_id: climate.ecodan_heatpump_zone_1_room_temp
            data:
              temperature: "{{ trigger.to_state.attributes.temperature | float(0) }}"

Als er dingen niet helemaal werkt, even AI vragen, die kan simpele yaml wel voor je fixen

In het algemeen beter via Asgard doen.

[_RRM_]

xoror schreef op dinsdag 18 augustus 2026 @ 12:09:
De aanpassingen op de MRC komen als room thermostaat waarden door. Ze worden niet in de virtual thermostaat over genomen. Ik had ooit een automation gemaakt voor @_RRM_ die status beide kanten (mrc/wireless <-> virtual thermostat) op synced. Deze zou je kunnen proberen.

YAML:

alias: Sync target temp (Two-Way)
description: Keeps Zone 1 and Virtual Thermostat target temperatures in sync in both directions.
mode: single
triggers:
  - trigger: state
    entity_id: climate.ecodan_heatpump_zone_1_room_temp
    attribute: temperature
    id: "zone_1_changed"
  - trigger: state
    entity_id: climate.ecodan_heatpump_virtual_thermostat_z1
    attribute: temperature
    id: "virtual_changed"
conditions:
  - condition: template
    value_template: >-
      {{ state_attr('climate.ecodan_heatpump_zone_1_room_temp', 'temperature') | float(0) !=
         state_attr('climate.ecodan_heatpump_virtual_thermostat_z1', 'temperature') | float(0) }}
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: "zone_1_changed"
        sequence:
          - action: climate.set_temperature
            target:
              entity_id: climate.ecodan_heatpump_virtual_thermostat_z1
            data:
              temperature: "{{ trigger.to_state.attributes.temperature | float(0) }}"
      - conditions:
          - condition: trigger
            id: "virtual_changed"
        sequence:
          - action: climate.set_temperature
            target:
              entity_id: climate.ecodan_heatpump_zone_1_room_temp
            data:
              temperature: "{{ trigger.to_state.attributes.temperature | float(0) }}"

Als er dingen niet helemaal werkt, even AI vragen, die kan simpele yaml wel voor je fixen

In het algemeen beter via Asgard doen.

@tante Truus gaat als een trein met deze automation. Vrijwel direct synchronisatie.

[Bravertal]

AUijtdehaag schreef op zaterdag 28 maart 2026 @ 15:32:
@Bravertal
Heb hier eventueel een menu
https://github.com/ebbenb...e/main/homeassistant/menu
en de plaatjes
https://github.com/ebbenb...ee/main/www/images/ecodan
[Afbeelding]

@t.werkhoven

[tante Truus]

_RRM_ schreef op dinsdag 18 augustus 2026 @ 13:29:
[...]

@tante Truus gaat als een trein met deze automation. Vrijwel direct synchronisatie.

Ik heb de automation toegevoegd, maar nog niet getest. ik zie iig geen foutmeldingen.

[The Source]

Ik heb de PCR-75YA-300 (ERST30D-VM2ED binnen unit en PUHZ-SW75 YAA buiten unit). Ik heb naast mijn batterij en laadpaal nu ook mijn SWW in DAO (energie planner) gezet voor normaal gebruik. Nu sta ik op het punt om de legionellerrun erbij te automatiseren, echter ben ik er niet 100% zeker van waar dit stroomverbruik zit om mijn COP duidelijk te houden. De warmtepomp zit op een 3 fase en een 1 fase aangesloten die ik beide apart extern meet.

1. Op dit moment gebruik ik de COP van ESPHome, echter twijfel ik of ik deze niet beter tegen het echte stroom verbruik kan afzetten, extern gemeten. Iemand ervaringen?
2. Klopt het dat de 1 fase enkel gebruikt wordt voor 1-op-1 verwarming bij de legionelle run? Gekke hier is dat ik bij de legionelle run naar 60 graden ~50min stroom verbruik op de 1 fase zie, maar bij de normale verwarmings run tot 55 graden zie ik de 1 fase ook even pieken (minder dan 1kwh energie verbruik).
3. Misschien domme vraag... maar kan ik niet tot 60 graden verwarmen zonder het 1op1 verwarmings element te gebruiken? Dat zou mijn COP toch ten goede komen, niet?

[xoror]

@The Source
1. via echte meter is beter. Maar dan moet je zowel wp als booster meten.
2. zie bovenstaande punt. Verbruik is logisch, je sw75yaa gebruikt 3 fasen, dus logisch dat je ook die fase hier ziet waar je booster element op zit. De booster is een aparte group, loop je leiding in je kast maar na.
3. de sw75yaa kan wel maar alleen onder ideale omstandigheden, kijk even data book na, daar staat bij performance data tot hoeveel graden hij kan. Maar de 2e vraag is of je dat moet willen, want rond 60c push je hem serieus hard (slijtage).

[xoror]

Hebben hier mensen de pre release met legionella temp verhoging en restore al getest?
~[edit] Ondertussen is mijn Legionella afgegaan, en allemaal goed verlopen via Asgard. Dus voor Asgard bezitters, even vinkje aanzetten in de UI voor legionella tank temp verhoging. Even laatste release updaten

[ Voor 56% gewijzigd door xoror op 23-08-2026 15:48 ]

[Zjemm]

@xoror nog niet, zal er binnenkort even tijd voor maken. thnx

[Bravertal]

Moet ik voor aankomende stookseizoen auto-adaptive aanzetten (en defrosts beperken)? Ik werk nu sinds kort met home assistant. Afgelopen stookseizoen gewoon (standaard Mitsubishi) thermostaat op 20 graden. Maar wil het allemaal wat effectiever hebben. Ik heb een 2-kapper uit 2021 met op de begane grond en eerste verdieping vloerverwarming (zolder wordt niet verwarmd).

Wat zijn jullie ervaringen met auto-adaptive en moet ik nog meer settings aanpassen?

[ Voor 14% gewijzigd door Bravertal op 25-08-2026 08:23 ]

[Ben(V)]

Auto Adaptive is veel zuiniger dan de standaard regeling van de ecodan mcd.

Wat ik wel zou aanraden is een eigen thermometer te gebruiken via de virtual thermostat van de Asgard.
De mcd van de Ecodan zelf heeft een oplossend vermogen van een halve graad en dat regelt echt veel slechter.
Ik gebruik zelf deze:
https://www.sonoff.nl/a-80532623/zigbee-producten/sonoff-zigbee-snzb-02d-temperatuur-en-luchtvochtigheidssensor/#description

Lees dit ook even:
https://github.com/gekkekoe/esphome-ecodan-hp/blob/main/docs/auto-adaptive.md#getting-started-with-auto-adaptive-control

[michaelvo]

Ben(V) schreef op dinsdag 25 augustus 2026 @ 10:04:
Auto Adaptive is veel zuiniger dan de standaard regeling van de ecodan mcd.

Dat zou ik niet zo stellen. De ingebouwde Mitsubishi ruimtetemperatuurregeling doet het best wel goed. Ik ben het wel met je eens dat de Auto Adaptive van Xoror een wat rustiger regelgedrag geeft en dat is wel fijn. Ik denk dat het verschil in energiegebruik wel echt minimaal is bij mij. Nadeel is er ook, namelijk dat de ruimtetemperatuurregeling tot onder de 25 graden Ta kan regelen en de auto adaptive niet...

Wat ik wel zou aanraden is een eigen thermometer te gebruiken via de virtual thermostat van de Asgard.
De mcd van de Ecodan zelf heeft een oplossend vermogen van een halve graad en dat regelt echt veel slechter.
Ik gebruik zelf deze:
https://www.sonoff.nl/a-80532623/zigbee-producten/sonoff-zigbee-snzb-02d-temperatuur-en-luchtvochtigheidssensor/#description

Ook niet helemaal mee eens. Bij mij werkt het uitstekend met de Mitsubishi PAR draadloze thermostaat. De halve graad onnauwkeurigheid of de hele graad hysterese heb ik in de praktijk geen last van. In de winter draait de warmtepomp gewoon rustig 24/7 en in het voor- en naseizoen draait ie gewoon één run per dag op het juiste moment.

Voordelen van de Mitsubishi PAR:

• de batterijduur is beter (PAR draait al 3 jaar op het eerste setje batterijen, Sonoff SNZB-02D bij mij ongeveer 6 a 9 maanden per batterij).
• communicatie is stabieler. PAR heeft nog nooit niet gewerkt, Sonoff is al paar keer in 2 jaar tijd gestopt met zenden (waarbij batterij erin en eruit het oploste).

[ Voor 4% gewijzigd door michaelvo op 25-08-2026 11:14 ]

[xoror]

@Bravertal Ik zou gewoon eerst proberen met wat je al hebt liggen, upgraden kan altijd nog.

@Ben(V) @michaelvo
- Auto adaptive kan ook onder 25c regelen, je kan zelf min flow temp instellen, die beperking is al een tijdje weg. Voor nu heb ik even 24c aangehouden, maar is willekeurig en kan ook lager maar vond dat zelf niet zo nuttig.
- ik zelf zou geen oplossingen nemen met batterijen, gewoon bedraad, dat werkt gewoon beste.
- voor AA maakt de overschoot en 0.5c temp resolutie iets minder uit. Al is het voor een groot oppervlakte 0.5c wel veel kWh stoken voordat hij uitgaat. Voor Odin zou ik wel 0.1c resolutie temp sensor aanraden puur omdat die moet zien hoeveel warmte er afgelopen uur is bijgekomen/weggelekt.

[michaelvo]

xoror schreef op dinsdag 25 augustus 2026 @ 11:59:
- Auto adaptive kan ook onder 25c regelen, je kan zelf min flow temp instellen, die beperking is al een tijdje weg. Voor nu heb ik even 24c aangehouden, maar is willekeurig en kan ook lager maar vond dat zelf niet zo nuttig.

Auto adaptive kan inderdaad onder de 25 graden sturen, probleem is dat de FTC er tóch minimaal 25 graden van gaat maken. In ieder geval op FTC6. Zie ook "Minimaal instelbare aanvoertemperatuur 25°C" bij Andrehj in "Mitsubishi Electric Ecodan Lucht/Water Warmtepompen" Ruimtetemperatuurregeling is de enige manier om ónder de 25 graden Ta te geraken.

[xoror]

Dat komt doordat je de MRC activeert om bijv iets in te stellen/bekijken. Dan gaat hij ongeldige grenzen resetten. Maar zolang je er niet aan zit accepteert hij het gewoon en regelt ernaar. Ik zelf gebruik die MRC niet, dus heb daar niet echt last van.

[Ben(V)]

Ik heb hier echt een verlaging in verbruik gemeten nadat ik Auto Adaptive heb ingeschakeld.
Ik vermoed dat het voornamelijk te maken heeft met een veel rustiger regeling en het stoppen van het continue pendelen.

Ik vind die halve graad van de mcd helemaal ruk, als ik 20,5^o graden wil gaat dat niet maar moet ik 21^o instellen wat dan als gevolg heeft dat door de overshoot de kamer af en toe 22^o wordt.

De Sonoff draait hier al twee jaar op dezelfde batterijen en hij geeft nog steeds aan dat die batterij 100% vol is.
Ik denk eerder dat je Zigbee netwerk niet goed dekkend is en daardoor raakt de Sonoff zijn verbinding kwijt en tevens kost een slechte Zigbee verbinding ook veel meer batterij vermogen.

@xoror
Zowel in het Asgard Dashboard, de browser interface als in Home Assistant kan ik geen lagere flow instellen dan 24^o( niet dat het zinvol zou zijn hoor).
Ik heb wel de laatste versie van Asgard draaien.

[ Voor 12% gewijzigd door Ben(V) op 25-08-2026 12:36 ]

[morlune]

Kan de Auto adaptive ook koelen? Ik merk met name met koeling icm vloerverwarming (dus 17-18gr) veel gependel...

[Bravertal]

xoror schreef op dinsdag 25 augustus 2026 @ 11:59:
@Bravertal Ik zou gewoon eerst proberen met wat je al hebt liggen, upgraden kan altijd nog.

Dus gewoon de standaard thermostaat aanhouden (dat wil ik eigenlijk ook) en auto-adaptive aanklikken en verder geen omkijken meer naar, toch?

[xoror]

@Ben(V) Zie mijn vorige bericht, ik heb het even voor nu op 24c gezet. Het probleem is met systemen waarbij de MRC in de woonkamer staat, dat mensen eraan zitten, en bij elke MRC activatie reset hij alle grenzen (want officieel mag je maar min 25 instellen bij vaste Ta). Maar als je er niet aan zit dan gaat het prima. Als het nodig is kan ik die 24c nog lager toestaan, maar volgens mij is het niet echt heel nuttig lager.

@morlune Ja hoor, lees vooral even: https://github.com/gekkek...ecodan-hp/discussions/356

@Bravertal Je moet nog wel wat instellingen doen, op niet-Asgard boardjes moet je wat sync scripts instellen om de ruimte temp door te geven. Zie https://github.com/gekkek...ith-auto-adaptive-control

[michaelvo]

@xoror ik kom echt nooit aan de MRC en bij mij levert hij gewoon Ta 25 graden als auto adaptive 24 graden vraagt. Ik zal het komend stookseizoen een keer laten zien.

[michaelvo]

@Ben(V) ja tuurlijk als auto adaptive ervoor zorgt dat je (veel) minder pendelgedrag hebt dan ga je daar wat winnen aan efficiëntie. Ben het met je eens dat auto adaptive beter omgaat met een grotere range aan installaties. Maar het is zeker niet per definitie veel zuiniger dan de ingebouwde ruimtetemperatuurregeling.

En offtopic, mijn Zigbee netwerk is prima, ik vertrouw eerder de door mij gebruikte knoopcellen niet helemaal. Maar mijn punt was dat je een extra variabele introduceert, zeker als je de PAR al hebt en deze prima werkt.

[michaelvo]

xoror schreef op dinsdag 25 augustus 2026 @ 13:15:
@Bravertal Je moet nog wel wat instellingen doen, op niet-Asgard boardjes moet je wat sync scripts instellen om de ruimte temp door te geven. Zie https://github.com/gekkek...ith-auto-adaptive-control

Dat heb ik nooit gedaan. Ruimte temp krijgt hij toch van de kamerthermostaat als je die selecteert?

[Ben(V)]

Zoals ik al zei doet die mcd enkel hele graden en dat vind ik ruk.
En ik heb nog steeds de meegeleverde knoopcel van de Sonoff erin zitten die al meer dan 2 jaar daarop draait.

En je moet toch echt in Home Assistant ooit eens die Sonoff aan de Asgard input gekoppeld hebben anders werkt het niet en blijft hij gewoon op de mrc thermostaat draaien.

[michaelvo]

MCD? Dat ken ik niet. De Mitsubishi PAR draadloze thermostaat doet in ieder geval halve graden.

En ik moet niks, ik heb niet eens een Asgard. En @Bravertal ook niet.

Zo werkt het bij mij iig prima, zonder verder dingen in te stellen of te syncen:

[xoror]

@michaelvo hmm ik heb geen wireless thermostaat en de MRC gebruik ik niet als thermostaat, dan kan het gewoon (de hele temp sync flow gaat dan buiten de MRC om). Misschien als de MRC 'actief' wordt om bijv een temp terug te sturen, dat hij het dan reset. Dat zou goed mogelijk zijn, maar test het even komend seizoen en laat mij weten. Dan zal ik de documentatie ervoor updaten.

Jij hebt verder wireless thermostat, dan heb je impliciet een stop conditie. Bij een MRC als hoofd thermostaat moet je nog wat instellingen doen voor een stop conditie, want hij stopt anders nooit. Dus MRC/room selecteren en stop conditie maken zou voldoende moeten zijn.

@Ben(V) Ik gok dat de meerderheid geen Asgard draait, dus die moeten iets meer werk doen. De controle over demand/hysteresis was een van de redenen dat ik Asgard heb gemaakt. Vooral mensen met alleen een MRC zonder Asgard als hoofd thermostaat moeten wat meer werk doen. Allemaal prima natuurlijk, software is tenslotte gratis/vrij beschikbaar.

In het algemeen denk ik dat er weinig verschil is tussen een goed geconfigureerde ruimte regeling vs auto adaptive. Behalve dat mijn implementatie transparant is, en je kan zien wat hij doet. Alleen kunnen mensen zonder een Mitsubishi thermostaat nooit gebruik maken van de ruimte regeling...

Misschien leuk voor hier: Ik heb die MRC al een keer helemaal uit elkaar gehaald

De th1 temp sensor is een heel fragiel uitsteeksel (ws om warmte van de pcb te voorkomen)

[ Voor 12% gewijzigd door xoror op 25-08-2026 14:30 ]

[Bravertal]

michaelvo schreef op dinsdag 25 augustus 2026 @ 14:17:
MCD? Dat ken ik niet. De Mitsubishi PAR draadloze thermostaat doet in ieder geval halve graden.

En ik moet niks, ik heb niet eens een Asgard. En @Bravertal ook niet.

Zo werkt het bij mij iig prima, zonder verder dingen in te stellen of te syncen:
[Afbeelding]

Max 27 graden, dus daar krijg je het warm mee? Ik zit in de nieuwbouw en moet dat dan ook kunnen? Ben helemaal nieuw met home assistant en vind het ook wel "spannend", wil geen comfort verlies ervaren (althans de vrouw en dochters niet).

[michaelvo]

Bravertal schreef op dinsdag 25 augustus 2026 @ 15:20:
[...]

Max 27 graden, dus daar krijg je het warm mee? Ik zit in de nieuwbouw en moet dat dan ook kunnen? Ben helemaal nieuw met home assistant en vind het ook wel "spannend", wil geen comfort verlies ervaren (althans de vrouw en dochters niet).

Ja, maar dat zegt niks over jouw situatie. Zegt weinig over isolatie maar vooral iets over je afgiftesysteem. Kun je voor nu ook prima op 32 graden laten staan, en gewoon monitoren wat hij daarmee doet. Zou wel de setpoint bias gewoon op 0 zetten, zo lang je daar niks mee wil doen.

[xoror]

@Breud Hoe had jij thermostaten uitgelezen in HA ? Jij had toch ook Watts ? @xchrisnl heeft hetzelfde namelijk

[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.