Mitsubishi Ecodan warmtepomp uitlezen via cn105 + esp32

[trippelb]

@xoror ondertussen een paar dagen verder en zoals gesuggereerd heb ik de nachtverlaging uitgezet en een andere sensor via home Assistant gekoppeld. De regeling loopt nu een stuk rustiger en ondanks de lage buitentemperaturen ook netjes op een lage TA.

Nogmaals mijn dank voor dit project!

[ThaDude]

Vind het wel jammer dat mijn warmte pomp niet wil of kan pruttelen. Hij houd het huis tot heden prima warm. Meeste mensen met Panasonic en buffer draaien hele dag door. Mijn mitsu rechtstreeks op vloer kan of wil dag niet

Gisteren om 0:03 dit te zien

code:

00:03:09    [I] [auto_adaptive:046] Learning: Day transition detected (9 -> 10). Processing model...
00:03:09    [I] [auto_adaptive:083] Learning Stats: AvgTemp=-2.0C, Heat=55.6kWh, Elec=16.9kWh, Run=3.0h
00:03:09    [I] [auto_adaptive:133] Learning Updated: HeatLoss=0.195 (kW/K), BaseCOP=4.96, Output=7.3 kW, Power=1.9 kW

Dit was vannacht zonder nachtverlaging. Als iemand tips heeft om meer hele dagen te "pruttelen" dan hoor ik het graag. In ochtend nu warme vloer en avond koude vloer



Duurt gewoon best lang alvorens temperatuur duur vloer/beton weer naar boven komt..

[ Voor 19% gewijzigd door ThaDude op 11-01-2026 09:12 ]

[xoror]

met dit weer is het lastig om hele dag te pruttelen..

Mijnes heeft hele nacht zowat vol vermogen gedraaid...

Als je wil laten pruttelen, moet je een kleine negatieve bias instellen, hij zal dat setpoint niet halen, en blijft rustig draaien omdat hij bijna bij setpoint is.

Hier is het -6c, en wp draait 98hz volle bak 8.7kW output. Huis is prima op 21.4c

[ Voor 13% gewijzigd door xoror op 11-01-2026 09:48 ]

[xoror]

Update over de pcb:
- PCB heeft officieel naam Asgard gekregen
- Alles wat ik wilde testen is allemaal goed verlopen. Vandaag de final test in de unit en alles ziet er erg goed uit. Hij draait nu dus fulltime hier bij mij.
- Case volgt nog, door het weer heb ik geen filament ontvangen (wacht al een week op)
- Een positief punt is dat wifi signaal (In de hydrobox) beter is dan de normale atom s3. Zie grafiek onder




Bij interesse laat het me weten. Ik ben voorbereiding aan het treffen de definitieve batch te bestellen.

[peterpijpelink]

xoror schreef op zondag 11 januari 2026 @ 13:23:
Update over de pcb:
- PCB heeft officieel naam Asgard gekregen

Let je wel op met de keuze van de naam? Ervaring is dat er ellende kan komen als er een naam gebruikt wordt, ook al is het niet in de categorie die een ander bedrijf zelf zou kiezen... kan dure grap soms worden is mijn ervaring. (en Heatbooster moest destijd naam aanpassen omdat teveel leek op....).

Kijk vooral in register.
https://www.boip.int/nl/m...ter?app=%2F&query=asguard

[jorritsmit]

xoror schreef op zondag 11 januari 2026 @ 13:23:
Update over de pcb:
- PCB heeft officieel naam Asgard gekregen
- Alles wat ik wilde testen is allemaal goed verlopen. Vandaag de final test in de unit en alles ziet er erg goed uit. Hij draait nu dus fulltime hier bij mij.
- Case volgt nog, door het weer heb ik geen filament ontvangen (wacht al een week op)
- Een positief punt is dat wifi signaal (In de hydrobox) beter is dan de normale atom s3. Zie grafiek onder
[Afbeelding]

[Afbeelding]

Bij interesse laat het me weten. Ik ben voorbereiding aan het treffen de definitieve batch te bestellen.

Ook een idee van wat je nou bespaart?

[xoror]

@jorritsmit Het varieert een beetje tussen 0-25% heb ik gezien per dag, maar tegen de tijd dat alles gereed is zal ik wat meer metingen doen

[barcomoon]

xoror schreef op zondag 11 januari 2026 @ 13:23:
Bij interesse laat het me weten. Ik ben voorbereiding aan het treffen de definitieve batch te bestellen.

Ik ben zeker geïnteresseerd! Dus zet mij maar op de lijst.

[SebastiaanPs]

xoror schreef op zondag 11 januari 2026 @ 13:23:
Update over de pcb:
- PCB heeft officieel naam Asgard gekregen
- Alles wat ik wilde testen is allemaal goed verlopen. Vandaag de final test in de unit en alles ziet er erg goed uit. Hij draait nu dus fulltime hier bij mij.
- Case volgt nog, door het weer heb ik geen filament ontvangen (wacht al een week op)
- Een positief punt is dat wifi signaal (In de hydrobox) beter is dan de normale atom s3. Zie grafiek onder
[Afbeelding]

[Afbeelding]

Bij interesse laat het me weten. Ik ben voorbereiding aan het treffen de definitieve batch te bestellen.

Ben heel benieuwd!
Wat zit er nou op welke poort? Gaat de pcb in plaats van de Atoms3 op de CN105?

Of zit ie op 2 poorten, ook de CNRF?
In het laatste geval: hoe zit het dan met de remote thermostats? Zullen temp sensoren in huis ook te linken zijn aan de pcb?

[xoror]

Even wat duidelijkheid scheppen. Dus ik wilde initieel de solver (vrekkie) meeleveren op 1 pcb, maar dat krijg ik niet voor elkaar zonder de solver bron code te moeten vrijgeven. Daardoor ben ik genoodzaakt om de solver los te koppelen, dus het wordt een los component die je in je netwerk stopt. De solver is dan lokaal aanwezig, geen cloud of subscriptions. Het gevolg is dat je ook iets van een pcb nodig heb om dit te draaien. Ik kan hier helaas niets aan veranderen.

Dan over de PCB.
- Het wordt een optie naast wat er nu draait, als je tevreden bent met wat je heb, moet je dat gewoon blijven gebruiken. De huidige esphome impl blijft gewoon werken.
- PCB kan stand alone of in proxy draaien zoals de hudige pcb van @AUijtdehaag
- CNRF wordt overbodig, ik ga de thermostaat functie overnemen op de pcb. Dus geen gare +1c overshoots meer maar gewoon zelf instelbaar wat je wil.
- Straks als de solver wordt gereleased heb je de poorten nodig om netjes de warmtepomp te bedienen. Dus je heb deze pcb nodig om samen met de solver te werken.
- Omdat ik meerdere keren gezien heb dat mensen hun melcloud adapters stuk hebben gemaakt, heb ik de nodige voorzorgmaatregelen getroffen op deze pcb. Daar zie je niets van, maar het zit er wel op (en dus kosten).
- PCB kan ook op de airco draaien, en dat ben ik nog aan het bekijken.

[Miezie]

xoror schreef op zondag 11 januari 2026 @ 17:45:
Even wat duidelijkheid scheppen. Dus ik wilde initieel de solver (vrekkie) meeleveren op 1 pcb, maar dat krijg ik niet voor elkaar zonder de solver bron code te moeten vrijgeven. Daardoor ben ik genoodzaakt om de solver los te koppelen, dus het wordt een los component die je in je netwerk stopt. De solver is dan lokaal aanwezig, geen cloud of subscriptions. Het gevolg is dat je ook iets van een pcb nodig heb om dit te draaien. Ik kan hier helaas niets aan veranderen.

Dan over de PCB.
- Het wordt een optie naast wat er nu draait, als je tevreden bent met wat je heb, moet je dat gewoon blijven gebruiken. De huidige esphome impl blijft gewoon werken.
- PCB kan stand alone of in proxy draaien zoals de hudige pcb van @AUijtdehaag
- CNRF wordt overbodig, ik ga de thermostaat functie overnemen op de pcb. Dus geen gare +1c overshoots meer maar gewoon zelf instelbaar wat je wil.
- Straks als de solver wordt gereleased heb je de poorten nodig om netjes de warmtepomp te bedienen. Dus je heb deze pcb nodig om samen met de solver te werken.
- Omdat ik meerdere keren gezien heb dat mensen hun melcloud adapters stuk hebben gemaakt, heb ik de nodige voorzorgmaatregelen getroffen op deze pcb. Daar zie je niets van, maar het zit er wel op (en dus kosten).
- PCB kan ook op de airco draaien, en dat ben ik nog aan het bekijken.

Maar wat doet het ding nou eigenlijk? Heb op zich wel interesse.

[xoror]

@Miezie
Het is een pcb om esphome te draaien, met extra's en voorbereiding om samen te kunnen werken met de solver. Dus 'in principe' is het een luxere versie van atom+proxy pcb met wat extra's. De extra poorten heb je nodig zodat de solver via de esp besturing kan overnemen van demand.

@SebastiaanPs Zie hier tests van de poorten, ik bestuur hier in6

[ Voor 13% gewijzigd door xoror op 12-01-2026 11:43 ]

[Blackraven]

Munsterman97 schreef op zaterdag 10 januari 2026 @ 11:22:
Hey allemaal,
Onlangs heb ik mijn Ecodan FTC6 aangesloten op HA.
Nu krijg ik echter de volgende waardes:
[Afbeelding]
Het kan toch niet zo zijn dat de temperatuur va de vloerverwarming zo hoog wordt als weergegeven in de bovenste grafiek? Zijn de sensoren dan op de verkeerde leidingen geplaatst? Of is dat temperatuur van het koelmiddel?

Hartelijk dank alvast!

Gewoon Ecodan is in je binnenunit, Z1 is van je afgiftesysteem.
Meest logische verklaring is dat je om 11u bij een SWW run de hogere temperaturen in je binnenunit ziet.
Edit: het lijkt er op dat je unit om 9u nog een run maakt, maar z'n warmte niet kwijt kan omdat Z1 niks afgeeft. Maar deze vraag kan beter in het algemene ecodan topic gesteld worden.

[ Voor 10% gewijzigd door Blackraven op 13-01-2026 08:03 ]

[xoror]

Eerste poging voor de case...

[MikevanEngelen]

Door een foutje is bij mij de z1 feedback temp voor een poosje op 0 doorgegeven (Zigbee issue), waardoor de Ecodan als een malle is gaan verwarmen. Nu probeer ik de temperatuur weer onder controle te krijgen, maar heb niet het idee dat de logica actief probeert de temperatuur te verlagen.

code:

22:31:29    [D] [auto_adaptive:421] [*] Starting auto-adaptive cycle, z2 independent: 0, has_cooling: 1, cold factor: 0.35, min delta T: 2.00, max delta T: 6.50
22:31:29    [D] [auto_adaptive:212] Processing Zone 1: Room=24.0, Target=21.5, Actual Feedtemp: 32.0, Return temp: 28.5, Outside: 8.0, Bias: 0.0, heating: 1, cooling: 0
22:31:29    [D] [auto_adaptive:232] Effective delta T: 2.70, cold factor: 0.35, dynamic min delta T: 2.70, error factor: 0.00, smart boost: 1.00, linear profile: 0
22:31:29    [D] [auto_adaptive:283] Z1 Setpoint reached (Error -2.5). Reverting to Base Delta T (2.0).
22:31:29    [D] [auto_adaptive:305] Z1 HEATING (Delta T): calculated_flow: 30.50°C (boost: 0.0)
22:31:29    [W] [auto_adaptive:144] Flow adjust: 31.50°C to prevent compressor stop! (setpoint: 30.50°C is 1.50°C below actual feed temp)
22:36:29    [D] [auto_adaptive:421] [*] Starting auto-adaptive cycle, z2 independent: 0, has_cooling: 1, cold factor: 0.35, min delta T: 2.00, max delta T: 6.50
22:36:29    [D] [auto_adaptive:212] Processing Zone 1: Room=24.0, Target=21.5, Actual Feedtemp: 32.0, Return temp: 29.0, Outside: 8.0, Bias: 0.0, heating: 1, cooling: 0
22:36:29    [D] [auto_adaptive:232] Effective delta T: 2.70, cold factor: 0.35, dynamic min delta T: 2.70, error factor: 0.00, smart boost: 1.00, linear profile: 0
22:36:29    [D] [auto_adaptive:283] Z1 Setpoint reached (Error -2.5). Reverting to Base Delta T (2.0).
22:36:29    [D] [auto_adaptive:305] Z1 HEATING (Delta T): calculated_flow: 31.00°C (boost: 0.0)
22:36:29    [D] [auto_adaptive:123] CMD: Set Dependent Heat Flow -> 31.0°C (31.5°C)
22:41:29    [D] [auto_adaptive:421] [*] Starting auto-adaptive cycle, z2 independent: 0, has_cooling: 1, cold factor: 0.35, min delta T: 2.00, max delta T: 6.50
22:41:29    [D] [auto_adaptive:212] Processing Zone 1: Room=24.0, Target=21.5, Actual Feedtemp: 32.0, Return temp: 29.0, Outside: 8.0, Bias: 0.0, heating: 1, cooling: 0
22:41:29    [D] [auto_adaptive:232] Effective delta T: 2.70, cold factor: 0.35, dynamic min delta T: 2.70, error factor: 0.00, smart boost: 1.00, linear profile: 0
22:41:29    [D] [auto_adaptive:283] Z1 Setpoint reached (Error -2.5). Reverting to Base Delta T (2.0).
22:41:29    [D] [auto_adaptive:305] Z1 HEATING (Delta T): calculated_flow: 31.00°C (boost: 0.0)

En met 24c in huis is 't flink warm ;-). Iemand een suggestie?

[xoror]

@MikevanEngelen Je kamer temp is 24c, maar je setpoint is maar 21.5, het is logisch dat hij naar min delta T gaat. Heb je toevallig alleen MRC ? Want dan heb je geen stop conditie. Dan heb je iets van CNRF nodig, externe thermostaat of het boardje boven je posting nodig

[MikevanEngelen]

xoror schreef op dinsdag 13 januari 2026 @ 23:05:
@MikevanEngelen Je kamer temp is 24c, maar je setpoint is maar 21.5, het is logisch dat hij naar min delta T gaat. Heb je toevallig alleen MRC ? Want dan heb je geen stop conditie. Dan heb je iets van CNRF nodig, externe thermostaat of het boardje boven je posting nodig

We hebben de buiten en binnenunit, met een Honeywell Home systeem voor multi-zone control.
Zover ik heb kunnen vinden, geeft die Honeywell geen temperatuur terug aan de Ecodan.

Ik heb geprobeerd dit te figeren door de feedback temp te voeden vanuit HA dmv. een Zigbee thermostaatje die de werkelijke temperatuur terugmeld. Het setpoint heb ik ingesteld via HA/ESP zelf.
Heb ik de documentatie verkeerd geintepreteerd?

EDIT: Verder zit op de binnenunit zelf de FTC6 - maar daar deze in een warm boilerhok staat, heb ik daar niet zoveel aan.

[ Voor 7% gewijzigd door MikevanEngelen op 13-01-2026 23:26 ]

[xoror]

MikevanEngelen schreef op dinsdag 13 januari 2026 @ 23:24:
[...]


We hebben de buiten en binnenunit, met een Honeywell Home systeem voor multi-zone control.
Zover ik heb kunnen vinden, geeft die Honeywell geen temperatuur terug aan de Ecodan.

Ik heb geprobeerd dit te figeren door de feedback temp te voeden vanuit HA dmv. een Zigbee thermostaatje die de werkelijke temperatuur terugmeld. Het setpoint heb ik ingesteld via HA/ESP zelf.
Heb ik de documentatie verkeerd geintepreteerd?

EDIT: Verder zit op de binnenunit zelf de FTC6 - maar daar deze in een warm boilerhok staat, heb ik daar niet zoveel aan.

Heb je een buffer tank toevallig ? Als je alleen een MRC heb mis je de stop conditie, en moet je iets knutselen met server control prohibits. Je moet het zo zien, als je je MRC op vaste Ta zet, stopt de wp eigenlijk nooit. En AA gebruikt vaste Ta om te regelen, en we hebben wel iets van een stop conditie nodig,

[MikevanEngelen]

xoror schreef op dinsdag 13 januari 2026 @ 23:27:
[...]


Heb je een buffer tank toevallig ? Als je alleen een MRC heb mis je de stop conditie, en moet je iets knutselen met server control prohibits. Je moet het zo zien, als je je MRC op vaste Ta zet, stopt de wp eigenlijk nooit. En AA gebruikt vaste Ta om te regelen, en we hebben wel iets van een stop conditie nodig,

Ik durf het niet met zekerheid te zeggen. Ik denk het wel.
Als ik kijk naar deze foto, denk ik dat het buffervat de grote cilinder is?

[xoror]

Nee, dat lijkt een expansievat en een buffer vat in de retour, dat is wel okay (niet erg)
Wanneer gaat je wp normaal gesproken verwarmen (maw wat stuurt hem aan). Zie je in de ESP in1/in6 wel eens actief worden?

[MikevanEngelen]

xoror schreef op dinsdag 13 januari 2026 @ 23:45:
Nee, dat lijkt een expansievat en een buffer vat in de retour, dat is wel okay (niet erg)
Wanneer gaat je wp normaal gesproken verwarmen (maw wat stuurt hem aan). Zie je in de ESP in1/in6 wel eens actief worden?

IN1 staat altijd op ON
IN6 staat altijd op OFF
(volgens HA historie)

Ik zal de exacte details achterwegen laten, maar we hebben al (gedurende de winter) issues om bepaalde verdiepingen te verwarmen, terwijl de begane grond niet reageert op de kamerthermostaat (een Honeywell Home Chronoterm).
De installateur adviseert de modus van het huisje met de twee thermometers in het pictogram, waar we het huis uberhaupt niet warm mee kregen (obv. de kamerthermostaat) - uiteindelijk overgestapt op compensatiecurve wat eindelijk het eea. eindelijk verwarmde.

Door het gebruik van de Atom (eigenlijk de proxy, zonder aangesloten slave), hoopte ik de controle te kunnen overnemen, maar kwam er al snel achter dat ik aan de temperatuur in de kamer niets heb (daar die geen feedbackloop naar de Ecodan lijkt te hebben, maar alleen een regulator open/dicht zet), vandaar mijn professorische oplossing met de Zigbee>REST feedback loop.

Ik dacht dat de oplopende temperatuur te maken had met de tijdelijke (let wel, twee dagen) temperatuur feedback die was gefaald (en dus 0 graden door gaf), maar ik begrijp dat ik er niet ben om dit verhaal goed te laten werken?

[xoror]

@MikevanEngelen Oplopende temp is ws omdat je geen stop conditie heb, en dus nooit stopt.
De ruimte regeling (dat huisje met de thermo meter) is de enige regeling dat kan stoppen met alleen de MRC.

Wat je kan doen is een van de volgende dingen:
1) CNRF inpluggen (mijn ander project) en feeden met je sensor, je heb dan een 'wireless' thermostaat
2) externe of mitsubishi thermostaat nemen. Nadeel is dat CNRF een resolutie heeft van 0.5c
3) Ruimte regeling alleen draaien, het verbaast mij dat die je huis niet warm krijgt (ws aan een enorme geklooi aan naregeling)
4) Je kan via HA zelf een stop conditie bouwen met automations, je moet dan server control aanzetten als je setpoint is bereikt.
5) Asgard board, die gaat in1/in6 kunnen bedienen dmv virtueel thermostaat

[ Voor 5% gewijzigd door xoror op 14-01-2026 00:53 ]

[Blackraven]

@xoror vandaag geprobeerd om een nieuwe build te maken, hij gaf het bij het editen van de .yaml al aan en loopt er ook daadwerkelijk op vast als ik probeer te builden:
Ik dacht valt wel mee, want line 36 staat op comment, of pakt hij hem in line 67 alsnog op?
(maar daar slaat hij niet op aan)
Of komt dit omdat ik de ethernet module gebruik?
Edit: ESPHome 2025.12.6 en line 84 # confs/wifi.yaml (i.v.m. Ethernet module)

code:

INFO ESPHome 2025.12.6
INFO Reading configuration /config/ecodan-esphome.yaml...
INFO Updating https://github.com/gekkekoe/esphome-ecodan-hp/@main
INFO Updating https://github.com/gekkekoe/esphome-ecodan-hp.git@main
Failed config

interval: [source /config/.esphome/packages/224a9af1/confs/auto-adaptive.yaml:354]
  - interval: 5min
    then: 
      - lambda: id(optimizer_ptr)->run_auto_adaptive_loop();
  - interval: 30s
    then: 
      - lambda: id(optimizer_ptr)->check_lockout_expiration();
      - lambda: id(optimizer_ptr)->predictive_short_cycle_check();
      - lambda: id(optimizer_ptr)->update_boost_sensor();
      - lambda: id(optimizer_ptr)->update_heat_model();
  - interval: 2s
    then: 
      - lambda: |-
          #include "freertos/FreeRTOS.h"
          #include "freertos/task.h"
          #include <vector>
          
          static uint32_t& last_total_runtime = id(g_core_ticks_last);
          static uint32_t& last_idle0_runtime = id(g_core_idle0_last);
          static uint32_t& last_idle1_runtime = id(g_core_idle1_last);
          static std::vector<TaskStatus_t> task_status_array;
          
          volatile UBaseType_t task_count;
          uint32_t total_runtime;
          uint32_t idle0_runtime = 0;
          uint32_t idle1_runtime = 0;
          
          task_count = uxTaskGetNumberOfTasks();
          task_status_array.resize(task_count);
          
          if (!task_status_array.empty()) {
            // Call the system state only ONCE
            task_count = uxTaskGetSystemState(task_status_array.data(), task_count, &total_runtime);
            
            // Find both IDLE tasks
            for (UBaseType_t i = 0; i < task_count; i++) {
              const char *task_name = pcTaskGetName(task_status_array[i].xHandle);
              if (strcmp(task_name, "IDLE0") == 0 || strcmp(task_name, "IDLE") == 0) {
                idle0_runtime = task_status_array[i].ulRunTimeCounter;
              } else if (strcmp(task_name, "IDLE1") == 0) {
                idle1_runtime = task_status_array[i].ulRunTimeCounter;
              }
            }
            
            // Only publish if we have a previous value to compare against
            if (last_total_runtime > 0 && total_runtime > last_total_runtime) {
              uint32_t total_diff = total_runtime - last_total_runtime;
              
              // Calculate and Publish Core 0
              uint32_t idle0_diff = idle0_runtime - last_idle0_runtime;
              float cpu_load_0 = 100.0f - ((float)idle0_diff / (float)total_diff * 100.0f);
              if (cpu_load_0 < 0.0f) cpu_load_0 = 0.0f;
              if (cpu_load_0 > 100.0f) cpu_load_0 = 100.0f;
              id(g_cpu_load_0) = cpu_load_0;
              id(cpu_load_core0).publish_state(cpu_load_0);
          
              // Calculate and Publish Core 1
              uint32_t idle1_diff = idle1_runtime - last_idle1_runtime;
              float cpu_load_1 = 100.0f - ((float)idle1_diff / (float)total_diff * 100.0f);
              if (cpu_load_1 < 0.0f) cpu_load_1 = 0.0f;
              if (cpu_load_1 > 100.0f) cpu_load_1 = 100.0f;
              id(g_cpu_load_1) = cpu_load_1;
              id(cpu_load_core1).publish_state(cpu_load_1);
            }
            
            // Store the current values for the next iteration
            last_total_runtime = total_runtime;
            last_idle0_runtime = idle0_runtime;
            last_idle1_runtime = idle1_runtime;
          }
  - interval: 10s
    then: 
      if: 
        condition: 
          
          Unable to find condition with the name 'wifi.connected'.
          wifi.connected: 
        then: 
          if:

[ Voor 83% gewijzigd door Blackraven op 14-01-2026 09:50 ]

[xoror]

Blackraven schreef op woensdag 14 januari 2026 @ 09:41:
@xoror vandaag geprobeerd om een nieuwe build te maken, hij gaf het bij het editen van de .yaml al aan en loopt er ook daadwerkelijk op vast als ik probeer te builden:[Afbeelding]
Ik dacht valt wel mee, want line 36 staat op comment, of pakt hij hem in line 67 alsnog op?
(maar daar slaat hij niet op aan)
Of komt dit omdat ik de ethernet module gebruik?
Edit: ESPHome 2025.12.6 en line 84 # confs/wifi.yaml (i.v.m. Ethernet module)

[...]

Kijk even naar de laatste yaml op mijn home page die is altijd up to date. Ik heb de esp32s3-led.yaml nu verplaatst naar de apparaat configs, dus die moet je weg laten

[Blackraven]

@xoror Ik heb voor de zekerheid je kale config even gebruikt, zodra ik de wifi.yaml comment krijg ik de error.
de esp32s3-led.yaml heb ik overigens nooit gebruikt.
Dus schijnbaar kan ik geen nieuwe build meer maken aangezien ik de ethernet i.p.v. de wifi component van ESPHome gebruik.
Ik zie dat esp32s3.yaml deze line nu bevat: <<: !include esp32s3-led.yaml
Betekent dat deze nu standaard ook voor mij aan staat?

[ Voor 18% gewijzigd door Blackraven op 14-01-2026 11:18 ]

[xoror]

Blackraven schreef op woensdag 14 januari 2026 @ 11:05:
@xoror Ik heb voor de zekerheid je kale config even gebruikt, zodra ik de wifi.yaml comment krijg ik de error.
de esp32s3-led.yaml heb ik overigens nooit gebruikt.
Dus schijnbaar kan ik geen nieuwe build meer maken aangezien ik de ethernet i.p.v. de wifi component van ESPHome gebruik.
Ik zie dat esp32s3.yaml deze line nu bevat: <<: !include esp32s3-led.yaml
Betekent dat deze nu standaard ook voor mij aan staat?

Ja, faalt hij daarom ?
Je kan dan even lokaal builden.

- git pull
en dan in je main yaml

code:

external_components:
- source:
    type: local
    path: components
  components: [ ecodan, optimizer ]

packages:
 base: !include confs/base.yaml # required
 adaptive: !include confs/auto-adaptive.yaml
 req: !include confs/request-codes.yaml 
 esp32: !include confs/esp32s3.yaml # esp32.yaml for regular board
 zone1: !include confs/zone1.yaml
 svc_z1: !include confs/server-control-z1.yaml
# disable if you don't want to use zone 2
# zone2: !include confs/zone2.yaml
# svc_z2: !include confs/server-control-z2.yaml
# change language labels to -en for English or -nl for Dutch
# substitutions: !include confs/ecodan-labels-nl.yaml
 substitutions: !include confs/ecodan-labels-en.yaml
 dbg: !include confs/debug.yaml
 wifi: !include confs/wifi.yaml
 energy: !include confs/energy.yaml
 cpu: !include confs/cpu-monitoring.yaml
 #svc: !include confs/server-control-z1.yaml

# external_components:
#   - source: github://gekkekoe/esphome-ecodan-hp@main
#     components: [ ecodan, optimizer ]
#     refresh: always

# packages:
#   remote_package:
#     url: https://github.com/gekkekoe/esphome-ecodan-hp/
#     ref: main
#     refresh: always
#     files: [ 
#             confs/base.yaml,            # required
#             confs/energy.yaml,            # required
#             confs/auto-adaptive.yaml,    # recommended
#             confs/cpu-monitoring.yaml,    # recommended
#             confs/request-codes.yaml,   # disable if your unit does not support request codes (service menu)
#             confs/esp32s3.yaml,         # confs/esp32.yaml, for regular board
#             confs/zone1.yaml,
#             confs/server-control-z1.yaml,
#             ## enable if you want to use zone 2
#             #confs/zone2.yaml,
#             #confs/server-control-z2.yaml,
#             ## enable label language files
#             confs/ecodan-labels-en.yaml,  # English
#             # confs/ecodan-labels-nl.yaml,  # Dutch
#             # confs/ecodan-labels-it.yaml,  # Italian
#             # confs/ecodan-labels-fr.yaml,  # French
#             # confs/ecodan-labels-de.yaml,  # German
#             # confs/ecodan-labels-fi.yaml,  # Finnish
#             # confs/ecodan-labels-no.yaml,  # Norwegian
#             # confs/ecodan-labels-sv.yaml,  # Swedish
#             # confs/ecodan-labels-da.yaml,  # Danish
#             # confs/ecodan-labels-pl.yaml,  # Polish
#             confs/debug.yaml,
#             confs/wifi.yaml
#            ]

doen, en dan lokaal de led eruit commenten, werkt dat dan wel ?
de esp32s3 zijn eigenlijk atom profielen namelijk

[Blackraven]

xoror schreef op woensdag 14 januari 2026 @ 11:34:
[...]


Ja, faalt hij daarom ?
Je kan dan even lokaal builden.

- git pull
en dan in je main yaml

code:

external_components:
- source:
    type: local
    path: components
  components: [ ecodan, optimizer ]

packages:
 base: !include confs/base.yaml # required
 adaptive: !include confs/auto-adaptive.yaml
 req: !include confs/request-codes.yaml 
 esp32: !include confs/esp32s3.yaml # esp32.yaml for regular board
 zone1: !include confs/zone1.yaml
 svc_z1: !include confs/server-control-z1.yaml
# disable if you don't want to use zone 2
# zone2: !include confs/zone2.yaml
# svc_z2: !include confs/server-control-z2.yaml
# change language labels to -en for English or -nl for Dutch
# substitutions: !include confs/ecodan-labels-nl.yaml
 substitutions: !include confs/ecodan-labels-en.yaml
 dbg: !include confs/debug.yaml
 wifi: !include confs/wifi.yaml
 energy: !include confs/energy.yaml
 cpu: !include confs/cpu-monitoring.yaml
 #svc: !include confs/server-control-z1.yaml

# external_components:
#   - source: github://gekkekoe/esphome-ecodan-hp@main
#     components: [ ecodan, optimizer ]
#     refresh: always

# packages:
#   remote_package:
#     url: https://github.com/gekkekoe/esphome-ecodan-hp/
#     ref: main
#     refresh: always
#     files: [ 
#             confs/base.yaml,            # required
#             confs/energy.yaml,            # required
#             confs/auto-adaptive.yaml,    # recommended
#             confs/cpu-monitoring.yaml,    # recommended
#             confs/request-codes.yaml,   # disable if your unit does not support request codes (service menu)
#             confs/esp32s3.yaml,         # confs/esp32.yaml, for regular board
#             confs/zone1.yaml,
#             confs/server-control-z1.yaml,
#             ## enable if you want to use zone 2
#             #confs/zone2.yaml,
#             #confs/server-control-z2.yaml,
#             ## enable label language files
#             confs/ecodan-labels-en.yaml,  # English
#             # confs/ecodan-labels-nl.yaml,  # Dutch
#             # confs/ecodan-labels-it.yaml,  # Italian
#             # confs/ecodan-labels-fr.yaml,  # French
#             # confs/ecodan-labels-de.yaml,  # German
#             # confs/ecodan-labels-fi.yaml,  # Finnish
#             # confs/ecodan-labels-no.yaml,  # Norwegian
#             # confs/ecodan-labels-sv.yaml,  # Swedish
#             # confs/ecodan-labels-da.yaml,  # Danish
#             # confs/ecodan-labels-pl.yaml,  # Polish
#             confs/debug.yaml,
#             confs/wifi.yaml
#            ]

doen, en dan lokaal de led eruit commenten, werkt dat dan wel ?
de esp32s3 zijn eigenlijk atom profielen namelijk

Voor lokaal builden moet/wil ik even m'n andere laptop met linux zoeken, dat is me iets teveel tijd, heb nu even m'n eigen fork gemaakt en de !include line eruit gehaald, vooralsnog is ie begonnen met compilen.
Edit: En nu geflashed, dus dat werkt prima. Zit blijkbaar toch in de verwijzingen naar de wifi component.

[xoror]

dank voor testen. Ja de led status is afhankelijk van netwerk idd.

[ThaDude]

@xoror Ik had AA uitgezet en even een vaste Ta gekozen. Nu al 2 dagen dat AA automatisch spontaan aangaat klopt dit. Jij enig idee?
Misschien is max en min flow hetzelfde anders een optie?

Haha dank! Inderdaad de boosdoener gevonden. Ik ga aan me eigen automations ten onder

[ Voor 20% gewijzigd door ThaDude op 14-01-2026 22:53 ]

[xoror]

@ThaDude je kan bij history kijken wie de AA switch aanzet. Ik zet nooit uit mezelf het aan hoor. Ws nog een automation ergens lopen?

[The Source]

Is er hier een gebruiker van DOA?
Ik zou graag de JASON voor de Ecodan warmtepomp en/of boiler die met deze esphome oplossing wordt aangestuurd als voorbeeld willen hebben. Het is ingewikkeld voor mij om de warmtepomp van scratch in te stellen. Dank, mag per DM.

[ Voor 8% gewijzigd door The Source op 14-01-2026 23:24 ]

[Blackraven]

@The Source Beide werken binnen Home Assistant, dus lijkt me niet al te moeilijk om de output van DOA middels wat automations voor de aansturing van ESPHome/Ecodan te gebruiken.

[Miezie]

En als het ingewikkeld is of als je het ingewikkeld wilt maken is het echt beter om eerst de kennis op te poetsen (zeker met home automation) voordat je aan de slag gaat. Bij problemen moet je er ook mee overweg kunnen…

[xoror]

Deze week druk met case bezig en dit zal hem moeten zijn

[xoror]

Ik heb hier wat info gepost over de virtuele thermostaat


Er staat ook meer info/vraag over hoe ik verder het af kan handelen. Neem even een kijkje.

[barcomoon]

xoror schreef op zondag 18 januari 2026 @ 13:23:
Ik heb hier wat info gepost over de virtuele thermostaat
[Afbeelding]

Er staat ook meer info/vraag over hoe ik verder het af kan handelen. Neem even een kijkje.

Super interessant en bruikbaar. De nieuwe setup lost voor mij een ‘issue’ op met de 1c hysteresis van de virtual remote thermostat. Dit naast natuurlijk de andere potentiële verbeteringen in efficiëntie waar ik benieuwd naar ben.

Al moet ik zeggen dat huidige AA hier ook al super smooth draait

[xoror]

@barcomoon Ja ik merk toch dat er veel setups zijn met alleen MRC, of helemaal geen thermostaat (par. buffer tank, en een 'thermostaat' die alleen de water pomp bedient). In dit geval mag CNRF dus met pensioen

Je kan verder zelf een hysteresis instellen, en omdat het een software thermostaat is, kunnen we vrij veel regelen. Een van de dingen die ik nog graag wil is tussen verwarmen en koelen schakelen. Dat zou dan kunnen en we kunnen nu echt een hardware signaal sturen om de wp te starten/stoppen. Dat opent veel nieuwe mogelijkheden.

Wat ook nog ondergesneeuwd is zijn de temp sensoren, daar moet ik nog wat documentatie voor maken. Maar je kan dan temp probes aan de aanvoer en retour leidingen hangen, je krijgt dan delta T op 0.1c nauwkeurig terug. Je krijgt dan een beter realtime output vermogen. Zit er ook op dus.

Pre-productie board draait al een week in mijn WP, en vanaf morgen neemt hij thermostaat functie over, hij draait nu in schaduw zodat ik kan vergelijken en tweaken.

[Johnny_Hasselt]

Hallo, ik volg al maanden dit gedeelte. In de zomer is mijn warmtepomp geplaatst (8kW op 3 Faze) en momenteel is die enkel in dienst voor mijn warm water productie en dit owv de verbouwing die ik ga uitvoeren van de volledige gelijkvloers. Alles gaat eruit en er komt 60m2 vloerverwarming.

Op de cn105 hangt er een AtomS3 en die werkt uitstekend....

Bovenverdieping is voorzien van LT radiators van Vasco.

Nu, ik ben van plan om als kamerthermostaat die te gebruiken dewelke in de Shelly Wall Display XL zit (met externe BT sensor). De hysterisch van die thermostaat kan ingesteld worden tot 0,1 graden.
Momenteel is er natuurlijk niets aangesloten op de In1 van de hydrobox.

Is er hier iemand die deze Shelly Wall Display XL ook gebruikt en wat zijn uw ervaringen?

PS: reden van plaatsen in de zomer is kostenspreiding enerzijds en hoogte van staatspremie die verlaagd werd in 2026.

J

[ Voor 7% gewijzigd door Johnny_Hasselt op 18-01-2026 20:19 ]

[xoror]

@Johnny_Hasselt Je zou dat kunnen doen met CNRF project, maar het nadeel is dat CNRF praat met een resolutie van 0.5c, dus je mooie 0,1 resolutie is dan kwijt. Het lastige van CNRF is dat die iets van +1c overshoot standaard heeft. Linkje 3 post hierboven lost je probleem wel netjes op.

[xoror]

Vandaag de uponor thermostaat met pensioen gestuurd en de virtuele thermostaat permanent op in1 aangesloten.



Ik heb verder de integratie met AA eenvoudiger gemaakt. Gewoon de virtuele thermostaat als source kiezen en je bent klaar, hij kan dan direct de huidige en setpoint uitlezen van de thermostaat. In mijn geval kan ik dan ook op 0.1c setpoint nu instellen ipv 0.5c. Dat is ook wel fijn. De hysteresis is ook instelbaar.

In dit geval zal hij stoppen bij 22.1 + 0.1
De verwarming zal dan weer starten als hij onder 22.1 komt. Je kan ook nog met deadbands spelen, maar dat is even voor later.

[jorritsmit]

Ik heb een vraagje over je laatste update waar je de cold factor iets harder laat reageren op kou, is dat misschien iets wat in de toekomst instelbaar/leerbaar kan worden want dit lijkt mij sterk gecorreleerd met de R waarde van je huis

[xoror]

@jorritsmit Ik reken nu ook heatloss uit per dag, kijk maar in de logs vlak na datum overgang. Dat kan later gebruikt worden om de factoren te corrigeren.

Voor nu kijk ik alleen naar de return value en het gekozen profiel. Daar zit impliciet de isolatie waarde van je woning in gemodelleerd.

[Frank90]

Ik gebruik deze integratie nu al een tijdje met veel plezier, dank voor de ontwikkeling!

Wat ik me afvroeg: naar wat voor soort geheugen op de Ecodan worden de waardes weggeschreven? En is er een kans dat deze integratie dat geheugen eerder sloopt met teveel write-acties?

[vormulier]

Frank90 schreef op dinsdag 20 januari 2026 @ 09:27:
Ik gebruik deze integratie nu al een tijdje met veel plezier, dank voor de ontwikkeling!

Wat ik me afvroeg: naar wat voor soort geheugen op de Ecodan worden de waardes weggeschreven? En is er een kans dat deze integratie dat geheugen eerder sloopt met teveel write-acties?

Er word niks groots geschreven op de ecodan door de integratie. Alles blijft op de esp.
Ze communiceren wel natuurlijk waardoor je writes hebt, Maar dat zou een procon ook (officieele integratie) doen dus veel problemen zou ik er niet van verwachten. En tegen die tijd heeft @xoror gewoon de gehele pcb al vervangen met een custom integratie

[xoror]

Als je bijv een instelling doet wordt deze wel opgeslagen op de FTC (dus schrijf actie). Maar wist je dat als je de ruimte regeling gebruikt de FTC zelf veel vaker de flow setpoint wegschrijft dan ik ooit voor elkaar krijg? Maw, je hoeft daar niet druk om te maken.

Ik lees de data uit en sla het wel op de esp, maar voordat die slijt ben je ws al toe aan vervanging van je wp.
Ik sla verder ook maar een beperkt deel settings op zodat je na reboot je settings van je esp niet kwijt bent. Ik heb een esp al 3 jaar in gebruik bijna, pas van de week vervangen met eigen board. Maw, bij normaal gebruik gaat je esp ook gewoon lang mee.

[Frank90]

Ok, helder! Goed om te horen dat dit geen issue is

[xoror]

Frank90 schreef op dinsdag 20 januari 2026 @ 16:13:
Ok, helder! Goed om te horen dat dit geen issue is

Je doet alleen incidenteel een setting aanpassen/sturen. Alleen in auto adaptive kunnen we elke 5min een nieuwe aanvoer temp instellen. Maar dit doen we alleen als de nieuwe berekende aanvoer anders is dan de huidige, dus in praktijk schrijf je veel minder vaak dan 1x per 5min in AA.

[ThaDude]

xoror schreef op maandag 19 januari 2026 @ 18:13:
@jorritsmit Ik reken nu ook heatloss uit per dag, kijk maar in de logs vlak na datum overgang. Dat kan later gebruikt worden om de factoren te corrigeren.

Voor nu kijk ik alleen naar de return value en het gekozen profiel. Daar zit impliciet de isolatie waarde van je woning in gemodelleerd.

Kunnen we die heatllos nog ergens uit of teruglezen? Elke dag tot 0:00 opblijven ook zo wat

[xoror]

@ThaDude Twijfel geval, als ik het beschikbaar nu maak, wordt ik overspoeld met vragen, even wachten tot de hardware release de deur uit is.

Tip:
esphome -logs --device ip file.yaml
Dat in een terminal open laten, kan je volgende ochtend even terug scrollen.

[xoror]

Virtuele thermostaat werkt ook goed en voorspelbaar. In1 wordt netjes aangestuurd...

[xoror]

Nog een voorbeeld hoe je de temp sensor poort kan gebruiken. Je zou dit met een klemmetje op aanvoer en retour kunnen klemmen.

Ik ben nog over aan het nadenken om nog een toe te staan om bijv temp te meten voor de virtuele thermostaat. Dan heb je geen HA nodig, maar wel een kabel nodig naar de ruimte die je wil meten.

Maar als je al kabel of loze leiding heb lopen, zou je een sensor daar kunnen ophangen. Dan heb je 'virtuele' thermostaat die nergens meer van afhankelijk is.

[ Voor 10% gewijzigd door xoror op 21-01-2026 22:41 ]

[Miezie]

xoror schreef op woensdag 21 januari 2026 @ 22:34:
[Afbeelding]

[Afbeelding]

Nog een voorbeeld hoe je de temp sensor poort kan gebruiken. Je zou dit met een klemmetje op aanvoer en retour kunnen klemmen.

Ik ben nog over aan het nadenken om nog een toe te staan om bijv temp te meten voor de virtuele thermostaat. Dan heb je geen HA nodig, maar wel een kabel nodig naar de ruimte die je wil meten.

Maar als je al kabel of loze leiding heb lopen, zou je een sensor daar kunnen ophangen. Dan heb je 'virtuele' thermostaat die nergens meer van afhankelijk is.

Kan je dan niet beter kijken of je een thermostaat kan maken die over die bedrading kan werken? Of draadloos…

[xoror]

@Miezie Je moet dit meer zien als een extra iets.

Als je een thermostaat maakt, dan moet je weer pcb + scherm + knoppen oid hebben. Dan kan je beter een bestaande gebruiken. De temp kan je dan syncen met HA/REST. Het zelfde geldt voor draadloos, je kan dan beter een bestaande gebruiken.

Als je toevallig al bedrading (bijv cat5) heb lopen, dan kan je een sensor plaatsen en gebruiken zonder tussenkomst van HA.

[Koffie]

Is het in niet auto-adaptive ook mogelijk een aparte source voor roomtemp op te geven?

[xoror]

@Koffie
Het zijn 2 dingen

1) Je moet een room temp koppelen aan de virtuele thermostaat. Vanaf dit moment heb je een thermostaat die je voor alles kan gebruiken, dus regulier verwarmen etc.
2) als je AA wil gebruiken, moet je normaal de room temp voeden naar AA. Dit is makkelijk gemaakt door hier alleen "Virtual thermostat" te kiezen, dan weet AA waar hij de kamer target en setpoint vandaan moet halen. Hoef je verder geen sync acties te maken in HA.

Dus antwoord op je vraag is dus: Ja

[ Voor 5% gewijzigd door xoror op 22-01-2026 10:03 ]

[xoror]

Ik heb de handleiding gemaakt en online gezet. Verder meer info over verkrijgbaarheid geplaatst.

[Munsterman97]

Echt knap staaltje engineering👏👏
Ik heb echter het gevoel dat ik iets mis..


Vandaar dus een vraag van mijn kant; ik draai nu een dag op auto adaptive, en de temperatuur stijgt 2 graden.
Is dit normaal gedrag voor een nieuwbouwwoning met vloerverwarming?
Ik heb github lopen doorpluizen, maar ik kon er niet echt achterkomen of dit inleergedrag is of niet..
Zie hieronder voor instellingen en een aantal plotjes, thanks!

[ Voor 12% gewijzigd door Munsterman97 op 22-01-2026 22:14 ]

[xoror]

@Munsterman97 Tip installeer het dashboard, is niet te zien dit

Je wil zoiets zien


Als ik moet gokken heb je geen stop conditie. Heb je toevallig alleen een MRC? Dus alleen die main display en verder geen thermostaat ? Zo ja lees dan https://github.com/gekkek...ith-auto-adaptive-control het stukje over stop conditie.

Je anvoer temp zijn ook veel te hoog voor nieuwbouw woning. Ik gok dus dat je allang op setpoint bent maar geen stop conditie heb,

Edit: Ja dus, je kamer setpoint is 19c, maar hij is al tot 21+ aan verwarmen.
Als je geen stop conditie kan instellen, kan je beter geen AA draaien. Dan beter de ruimte regeling van Mitsubishi zelf draaien.

Je kan de stop conditie toe voegen door (van gratis naar duur)
0) software matig prohibits instellen
1) CNRF te draaien en te voeden met temp sensor
2) Asgard gebruiken met virtuele thermostaat.
3) hardware thermostaat die op in1/in6 werkt kopen

[ Voor 41% gewijzigd door xoror op 22-01-2026 22:40 ]

[Munsterman97]

@xoror ,

Wow thanks, ga direct aan het werk. Ik skipte dat gedeelte. Er staat namelijk dat ik dat over moest slaan!

Edit: oei de stop conditie instellen is toch iets lastigs voor mij , ga hier later mee bezig.

[ Voor 43% gewijzigd door Munsterman97 op 23-01-2026 07:52 ]

[xoror]

@Munsterman97 gewoon ruimte regeling gebruiken, of een van de andere bovengenoemde opties

De MRC en CNRF hebben wat lager temp resolutie en overshoot, en zijn niet ideaal. Alleen de ruimte regeling is er speciaal voor gemaakt

[Munsterman97]

@xoror
Thanks voor je advies. Dan laat ik hem staan op room temperatuur. Ondertussen blijf ik in the loop voor je Asgaard project!

[xoror]

Ik heb het opgelost dat je nu dynamisch in de binaries 4 temp sensoren kan toekennen aan Feed/Return/Z1/Z2 temps. Je kan dan dmv selectie boxen aangeven hoe hij zich moet gedragen. Dan kan je dus een temp sensor aan de virtuele thermostaat toekennen zonder afhankelijk te zijn van HA. Dan kan de boel gewoon blijven draaien bij HA uitval. (Vandaar dat ik de configuratie in ESPHome interface laat zien)



Volledige uitleg hier
Voor de gene die het gemist hebben, Hier kan je nog info vinden over verkrijgbaarheid

[xoror]

“ESPHome 2026.1.0 delivers one of the most requested features: automatic WiFi roaming. Devices now switch to better access points after connecting, solving the problem of devices getting stuck on distant APs after power outages or AP reboots.”

In de laatse pre-release kan je proberen als je last van WiFi heb. @Breud
https://github.com/gekkekoe/esphome-ecodan-hp/releases

@Blackraven Als jij software bijwerkt, moet je even kijken of alles nu nog goed werkt, de 'step down' enforce was een bug bij systemen met buffervaten, en volgens mij maakte je daar vrolijk gebruik van

[ Voor 29% gewijzigd door xoror op 24-01-2026 08:55 ]

[Blackraven]

@xoror Moet ik zelf de "!include esp32s3-led.yaml" er nog uit halen, of heb je die nog conditional gemaakt op basis van de wifi.yaml?

[xoror]

@Blackraven moet je nog even zelf eruit halen, ben ik nog niet aan toe gekomen

Waar je even op moet letten is of hij nu gaat pendelen, als er een calculated flow uit komt die onder je tank temp zit. Ik moet even kijken of ik dat op min de mixing tank temp moet houden om de compressor stop te voorkomen

[ Voor 58% gewijzigd door xoror op 26-01-2026 09:47 ]

[xoror]

@Blackraven
https://github.com/gekkek...27fe5ac943787722a821ec19a
Ik heb hem voorlopig even op minimaal mixing tank gezet, anders gaat hij stoppen. Moet je even source refreshen

De step down waar je gebruik van maakte was een fout, en niet bedoeld voor dit stuk, maar gok dat het zo nu ook voor jou goed werkt.

[Blackraven]

xoror schreef op maandag 26 januari 2026 @ 10:10:
@Blackraven
https://github.com/gekkek...27fe5ac943787722a821ec19a
Ik heb hem voorlopig even op minimaal mixing tank gezet, anders gaat hij stoppen. Moet je even source refreshen

De step down waar je gebruik van maakte was een fout, en niet bedoeld voor dit stuk, maar gok dat het zo nu ook voor jou goed werkt.

Met m'n FTC5 heb ik geen mixingtank temp, weet niet of dit wel goed gaat uitpakken dan...
(ik gebruik de Z1 sensoren voor m'n buffervat)

[ Voor 4% gewijzigd door Blackraven op 26-01-2026 10:27 ]

[xoror]

Blackraven schreef op maandag 26 januari 2026 @ 10:23:
[...]

Met m'n FTC5 heb ik geen mixingtank temp, weet niet of dit wel goed gaat uitpakken dan...
(ik gebruik de Z1 sensoren voor m'n buffervat)

Ik val terug op de primary return voor FTC5. Heb je wel de Boiler Return?
Ik pak de eerste niet 25c van MixingTankTemp, BoilerReturnTemp, primary return temp
(25c krijg je als de sensoren niet geinstalleerd zijn)

[ Voor 17% gewijzigd door xoror op 26-01-2026 10:45 ]

[Blackraven]

@xoror dan komt het goed, primary return is wat de FTC5 doet door de gelaagdheid van het vat om te woelen en zo een idee van de tanktemp. te krijgen.
Voor m'n eigen referentie gebruik ik de volgende sensoren:
Boiler feed is bovenkant buffer
Boiler return is midden buffer
Z1 return is onderkant buffer
Z1 feed zit op de aanvoerleiding richting buffer en/of Z2 (normaal gezien gelijk aan Ecodan feed).
Retour Z2 loopt via de onderkant buffervat terug naar de ecodan

En om half zeven woelt de ecodan de gelaagdheid aan gort:

(De stijging in de nacht komt door het E-element in het vat, ben nu nog wat aan het hobbyen )

[ Voor 39% gewijzigd door Blackraven op 26-01-2026 11:12 . Reden: plaatje even aangepast en verloop buffertemp. toegevoegd. ]

[xoror]

@Blackraven ja misschien moet je nog even refreshen. De fallback heb ik er net ingezet.

Wat ik nog aan het uit zoeken ben is de exacte compressor stop conditie.
Lijkt die bij jou ook bijv voor z1:
z1 actual flow temp - z1 flow setpoint > 1.5
te zijn? Dat de compressor afslaat? Of kijkt hij bij jou puur naar de return/mixing tank ?

[Blackraven]

xoror schreef op maandag 26 januari 2026 @ 11:17:
@Blackraven ja misschien moet je nog even refreshen. De fallback heb ik er net ingezet.

Wat ik nog aan het uit zoeken ben is de exacte compressor stop conditie.
Lijkt die bij jou ook bijv voor z1:
z1 actual flow temp - z1 flow setpoint > 1.5
te zijn? Dat de compressor afslaat? Of kijkt hij bij jou puur naar de return/mixing tank ?

Dat is een lastige, ik bereik bijna nooit het punt dat hij aan de max. temp zit voor Z1, ook omdat hij de retour van Z1 en Z2 terugmengt in het buffervat retour richting de Ecodan.
Maar aangezien ik vannacht wat te enthousiast aan het bijverwarmen was en de buffertank nu al op 48°C zit, is het nog 2K te gaan tot hij op de max. temp zit voor de AA (50°C), dus wellicht dat hij vandaag er wel op reageert. Geef je wel even feedback als hij gaat takten.
Edit: ik trigger hem wel even met Z2 prohibit.

[Blackraven]

@xoror Zo te zien is de dip in Ecodan return de trigger:

(Eerder zie je mooi dat AA de aanvoersetpoint nog wat opschroeft)

[ Voor 9% gewijzigd door Blackraven op 26-01-2026 13:22 ]

[xoror]

@Blackraven Ik heb denk ik de echte fout gevonden. Recompile laatste.
Kijk of het weer goed werkt voor je.

Zo te zien stopt de boel bij jou > 1.5c
@Blackraven
Met de laatste code zou hij dus moeten zien dat:
- werkelijke z1 flow = 52c
- hij geen flow setpoint mag doen < 50.5c

In dit geval heeft hij er 50c van gemaakt ? Dus de compressor stopt. Als je het nog een keer kan triggeren met de laatste code zou dat erg behulpzaam zijn. Hij doet nu weer netjes enforce step down

[ Voor 68% gewijzigd door xoror op 26-01-2026 13:52 ]

[Blackraven]

xoror schreef op maandag 26 januari 2026 @ 13:44:
@Blackraven Ik heb denk ik de echte fout gevonden. Recompile laatste.
Kijk of het weer goed werkt voor je.

Zo te zien stopt de boel bij jou > 1.5c
@Blackraven
Met de laatste code zou hij dus moeten zien dat:
- werkelijke z1 flow = 52c
- hij geen flow setpoint mag doen < 50.5c

In dit geval heeft hij er 50c van gemaakt ? Dus de compressor stopt. Als je het nog een keer kan triggeren met de laatste code zou dat erg behulpzaam zijn. Hij doet nu weer netjes enforce step down

Nog paar compile warnings, maar daar zal ie wel niet op vast lopen:

code:

WARNING 'server control - enable/disable' contains '/' which is reserved as a URL path separator. Automatically replacing with 'server control - enable⁄disable' (Unicode FRACTION SLASH). Please update your configuration. This will become an error in ESPHome 2026.7.0.
WARNING 'Zone 1 H/C Setpoint Value' contains '/' which is reserved as a URL path separator. Automatically replacing with 'Zone 1 H⁄C Setpoint Value' (Unicode FRACTION SLASH). Please update your configuration. This will become an error in ESPHome 2026.7.0.
WARNING 'H/C status' contains '/' which is reserved as a URL path separator. Automatically replacing with 'H⁄C status' (Unicode FRACTION SLASH). Please update your configuration. This will become an error in ESPHome 2026.7.0.
WARNING 'Zone 2 H/C Setpoint Value' contains '/' which is reserved as a URL path separator. Automatically replacing with 'Zone 2 H⁄C Setpoint Value' (Unicode FRACTION SLASH). Please update your configuration. This will become an error in ESPHome 2026.7.0.
WARNING 'H/C status z2' contains '/' which is reserved as a URL path separator. Automatically replacing with 'H⁄C status z2' (Unicode FRACTION SLASH). Please update your configuration. This will become an error in ESPHome 2026.7.0.

En hij is succesvol herstart, poging 2 om hem te laten takten.

[xoror]

die warnings worden later pas opgelost, dat worden breaking changes. Los ik later op, want dit breekt automations van mensen als ik '/' niet meer in namen mag gebruiken

@Blackraven Laat logging ook mee lopen
in esphome builder lang je logs meekijken

[ Voor 20% gewijzigd door xoror op 26-01-2026 14:22 ]

[Blackraven]

xoror schreef op maandag 26 januari 2026 @ 14:18:
die warnings worden later pas opgelost, dat worden breaking changes. Los ik later op, want dit breekt automations van mensen als ik '/' niet meer in namen mag gebruiken

@Blackraven Laat logging ook mee lopen
in esphome builder lang je logs meekijken

Wordt dit niet al eerder een probleem voor de mensen die zelf compilen, aangezien hij aangeeft dat hij dit automatisch al vervangt door die plattere slash?
Logging draait mee.

[xoror]

is change met nieuwe esphome, is voor iedereen. Maar per juni 2026 pas, dus een keer goed moment kiezen om de breaking change te doen

[Blackraven]

xoror schreef op maandag 26 januari 2026 @ 14:31:
is change met nieuwe esphome, is voor iedereen. Maar per juni 2026 pas, dus een keer goed moment kiezen om de breaking change te doen

Hij heeft het al aangepast, vgl. de bovenste "/" vs. de onderste vervangen "⁄":

En de volgende takt:

code:

[14:45:19.777][W][auto_adaptive:059]: Flow limited to 50.0°C (Zone Max Limit), calculated_flow: 56.0
[14:45:19.784][D][auto_adaptive:092]: CMD: Set Z1 Heat Flow -> 50.0°C (51.0°C)
[14:45:25.556][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:45:26.073][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:45:56.716][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:46:11.288][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:46:26.376][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:46:56.989][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:48:36.000][W][auto_adaptive:151]: Flow adjust: 51.00°C to prevent compressor stop! (setpoint: 50.00°C is 1.50°C below actual feed temp)
[14:48:36.003][D][auto_adaptive:092]: CMD: Set Z1 Heat Flow -> 51.0°C (50.0°C)
[14:48:51.572][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:49:12.208][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:49:26.789][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:49:59.972][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:50:19.767][D][auto_adaptive:460]: [*] Starting auto-adaptive cycle, z2 independent: 1, has_cooling: 0, cold factor: 0.54, min delta T: 2.00, max delta T: 6.50
[14:50:19.772][D][auto_adaptive:248]: Processing Zone 1: climate source: 0, Room=0.0, Target=28.0, Actual Feedtemp: 52.0, Return temp: 49.5, Outside: 3.0, Bias: 0.0, heating: 1, cooling: 0
[14:50:19.774][D][auto_adaptive:268]: Effective delta T: 6.50, cold factor: 0.54, dynamic min delta T: 3.08, error factor: 1.00, smart boost: 1.00, linear profile: 0
[14:50:19.774][D][auto_adaptive:341]: Z1 HEATING (Delta T): calculated_flow: 56.00°C (boost: 0.0)
[14:50:19.782][W][auto_adaptive:059]: Flow limited to 50.0°C (Zone Max Limit), calculated_flow: 56.0
[14:50:19.783][D][auto_adaptive:092]: CMD: Set Z1 Heat Flow -> 50.0°C (51.0°C)
[14:50:20.834][W][ecodan.component:351]: Command timed out. Retrying (attempt 2/30)...[1]
[14:50:21.836][W][ecodan.component:351]: Command timed out. Retrying (attempt 3/30)...[1]
[14:50:22.839][W][ecodan.component:351]: Command timed out. Retrying (attempt 4/30)...[1]
[14:50:35.607][I][short_cycle:248]: Compressor STOP detected
[14:50:35.651][D][short_cycle:161]: Running compressor stop logic...
[14:51:06.256][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:51:06.757][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:51:10.285][D][auto_adaptive:227]: Operation Mode Changed to heating: 0 -> 2
[14:51:10.290][D][auto_adaptive:460]: [*] Starting auto-adaptive cycle, z2 independent: 1, has_cooling: 0, cold factor: 0.54, min delta T: 2.00, max delta T: 6.50
[14:51:10.291][D][auto_adaptive:248]: Processing Zone 1: climate source: 0, Room=0.0, Target=28.0, Actual Feedtemp: 51.0, Return temp: 50.0, Outside: 3.0, Bias: 0.0, heating: 1, cooling: 0
[14:51:10.291][D][auto_adaptive:268]: Effective delta T: 6.50, cold factor: 0.54, dynamic min delta T: 3.08, error factor: 1.00, smart boost: 1.00, linear profile: 0
[14:51:10.301][D][auto_adaptive:341]: Z1 HEATING (Delta T): calculated_flow: 56.50°C (boost: 0.0)
[14:51:10.301][W][auto_adaptive:059]: Flow limited to 50.0°C (Zone Max Limit), calculated_flow: 56.5
[14:51:23.327][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:51:23.843][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:51:56.505][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:53:41.540][I][short_cycle:256]: Compressor START detected
[14:53:41.543][D][auto_adaptive:262]: Compressor start: triggering auto-adaptive loop.
[14:53:41.543][D][auto_adaptive:460]: [*] Starting auto-adaptive cycle, z2 independent: 1, has_cooling: 0, cold factor: 0.54, min delta T: 2.00, max delta T: 6.50
[14:53:41.548][D][auto_adaptive:248]: Processing Zone 1: climate source: 0, Room=0.0, Target=28.0, Actual Feedtemp: 49.5, Return temp: 49.5, Outside: 3.0, Bias: 0.0, heating: 1, cooling: 0
[14:53:41.548][D][auto_adaptive:268]: Effective delta T: 6.50, cold factor: 0.54, dynamic min delta T: 3.08, error factor: 1.00, smart boost: 1.00, linear profile: 0
[14:53:41.549][D][auto_adaptive:341]: Z1 HEATING (Delta T): calculated_flow: 56.00°C (boost: 0.0)
[14:53:41.554][W][auto_adaptive:059]: Flow limited to 50.0°C (Zone Max Limit), calculated_flow: 56.0

[ Voor 98% gewijzigd door Blackraven op 26-01-2026 14:57 ]

[xoror]

@Blackraven
[14:50:19.782][W][auto_adaptive:059]: Flow limited to 50.0°C (Zone Max Limit), calculated_flow: 56.0
[14:50:19.783][D][auto_adaptive:092]: CMD: Set Z1 Heat Flow -> 50.0°C (51.0°C)

Hij respecteert je max z1 limit, die heb je op 50C staan. Hij kan dan niet step down doen in dit geval, want hij moet de harde limited respecteren.

Deed ik vroeger dus de limieten negeren of zijn deze nieuw?

[Blackraven]

@xoror Ik begrijp je laatste zin niet helemaal, maar ik heb niet aan de limitieten gezeten vandaag, alleen Z2 prohibit on en off, verder laat ik hem lekker z'n ding doen.
AA min Z1 = 24°C en max Z1 = 50°C.
Ik zie dat hij nog wel de harde limiet van 50°C overschrijdt, ook met je laatste code.

[xoror]

er zijn 2 processen
- wanneer je de flow set, kijk ik of alles netjes binnen limieten zit, en respecteer ik de max

code:

[14:51:10.290][D][auto_adaptive:460]: [*] Starting auto-adaptive cycle, z2 independent: 1, has_cooling: 0, cold factor: 0.54, min delta T: 2.00, max delta T: 6.50
[14:51:10.291][D][auto_adaptive:248]: Processing Zone 1: climate source: 0, Room=0.0, Target=28.0, Actual Feedtemp: 51.0, Return temp: 50.0, Outside: 3.0, Bias: 0.0, heating: 1, cooling: 0
[14:51:10.291][D][auto_adaptive:268]: Effective delta T: 6.50, cold factor: 0.54, dynamic min delta T: 3.08, error factor: 1.00, smart boost: 1.00, linear profile: 0
[14:51:10.301][D][auto_adaptive:341]: Z1 HEATING (Delta T): calculated_flow: 56.50°C (boost: 0.0)
[14:51:10.301][W][auto_adaptive:059]: Flow limited to 50.0°C (Zone Max Limit), calculated_flow: 56.5

- Wanneer we een flow gezet hebben, draait er een bewaking op de achtergrond. Deze houdt geen rekening met limieten.

code:

[14:51:23.327][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:51:23.843][D][auto_adaptive:024]: Change event ignored: cooling down from own action.
[14:51:56.505][D][auto_adaptive:024]: Change event ignored: cooling down from own action.

Het 2e deel skipt dus omdat ik mijn eigen acties niet wil corrigeren (omdat alles in principe afgehandeld is). Voorheen deed ik dat wel, en kreeg je een flow adjust om de compressor stop te voorkomen.

Bij anderen gaat dit fout, omdat hij dan oneindig door gaat verhogen. ff kijken hoe ik dit kan laten werken voor jou en anderen

Maar als je max limiet van 50c heb, dan neem ik aan dat je wil dat hij deze respecteert toch?

[xoror]

@Blackraven
Ik heb de 2e stap nu weg gelaten. Dat wordt alleen nog uitgevoerd ten tijde van een SWW of 5m erna. Dat is puur om die overgang goed te doen. Het is niet bedoeld voor algemeen.

Dus ik kan even helaas niets aan die compressor stop in jouw geval doen omdat we in dit geval correct de limieten hanteren

[Blackraven]

xoror schreef op maandag 26 januari 2026 @ 16:02:
@Blackraven
Ik heb de 2e stap nu weg gelaten. Dat wordt alleen nog uitgevoerd ten tijde van een SWW of 5m erna. Dat is puur om die overgang goed te doen. Het is niet bedoeld voor algemeen.

Dus ik kan even helaas niets aan die compressor stop in jouw geval doen omdat we in dit geval correct de limieten hanteren

Die compressor stop is ook geen probleem, die treedt alleen op op het moment dat de WP z'n energie écht niet meer kwijt kan.
Praktisch staat Z2 altijd aan en probeer ik de energie die de WP nog over heeft in het buffervat te steken, dus normaal snort hij mooi door.
Deze situatie zou alleen op in de zomer zijn als ik de (hygiëne)buffer ook voor tapwater wil gaan gebruiken om zonnestroom thermisch op te slaan.
Wel lekker lang douchen, met 1000+200L warm water

[xoror]

@Blackraven Ben nu de short cycle prevention per zone aan het testen, ik gok dat je deze wellicht kan inzetten.
korte limit zetten 1m ofzo met 1c delta, dan gaat. hij ook boosten.
Is nog beta en wordt nu nog getest, maar als je laatste source compiled kan je het uitproberen

[Blackraven]

@xoror Short-cycle predictive prevention staat hier uit, voor zover ik het zie heb ik dat niet nodig omdat hij nooit pendelt bij normaal bedrijf.
Gisteren even op jouw verzoek getriggerd, maar dat is geen normale situatie.

[xoror]

even recompile doen. Pendel is een rekbaar begrip
hij probeert te voorkomen dat actual - setpoint van je zone de grens van 1.5c overgaat om de compressor stop te voorkomen

[xoror]

https://github.com/gekkek...eleases/tag/2026-01-27.03
changelog

esphome 2026.1.2 (fix build issues, contains WiFi improvements)
1-wire: allow dynamic binding of detected sensors
AA: Ensure that z1/z2 setpoint >= mixing tank temp
Stats: fix day transition on boot
AA: Only apply step down during DHW or 5m post DHW
Fix esphome naming issues. Please note that '/' was replaced and that some sensors have been renamed. (The H/C... sensors)
Refactored predictive cycle prevention to work the same in non-AA. It now supports mixing tank configurations

Let op, de H/C stukken uit de namen zijn weggelaten. De '/' mag je binnenkort niet meer gebruiken in namen. Predictive cycle prevention is nu gelijk getrokken met AA. Hij respecteert nu ook max temp van de zones.

[xoror]

https://github.com/gekkek...#5-how-can-i-monitor-logs

Ik heb nog een eenvoudige manier toegevoegd om logs te bekijken

[Zjemm]

geinig, ik krijg alleen wel elke keer connection closed, en geen logs

[xoror]

apart, moet je in dev tools kijken waarom die verbinding wordt gesloten, het werkt hier wel goed. Je moet hem lokaal openen met file:// en niet vanaf het web

[Beireken]

Het was een tijdje geleden maar nu toch nog eens een update proberen uitvoeren.
Volgende error krijg ik echter:

code:

/data/packages/224a9af1/confs/short-cycle.yaml: In lambda function:
/data/packages/224a9af1/confs/short-cycle.yaml:350:20: error: 'const struct esphome::ecodan::Status' has no member named 'has_independent_z2'; did you mean 'has_independent_zone_temps'?
  350 |             if (status.has_independent_z2()) {
      |                    ^~~~~~~~~~~~~~~~~~
      |                    has_independent_zone_temps
/data/packages/224a9af1/confs/auto-adaptive.yaml: In lambda function:
/data/packages/224a9af1/confs/auto-adaptive.yaml:345:109: error: 'const struct esphome::ecodan::Status' has no member named 'has_independent_z2'; did you mean 'has_independent_zone_temps'?
  345 |           ESP_LOGD("auto_adaptive", "Starting auto-adaptive cycle, z2 independent: %d, has_cooling: %d", status.has_independent_z2(), status.has_cooling());
      |                                                                                                             ^~~~~~~~~~~~~~~~~~
src/esphome/core/log.h:96:100: note: in definition of macro 'esph_log_d'
   96 |   ::esphome::esp_log_printf_(ESPHOME_LOG_LEVEL_DEBUG, tag, __LINE__, ESPHOME_LOG_FORMAT(format), ##__VA_ARGS__)
      |                                                                                                    ^~~~~~~~~~~
/data/packages/224a9af1/confs/auto-adaptive.yaml:345:7: note: in expansion of macro 'ESP_LOGD'
  345 |           ESP_LOGD("auto_adaptive", "Starting auto-adaptive cycle, z2 independent: %d, has_cooling: %d", status.has_independent_z2(), status.has_cooling());
      |       ^   ~~~~
/data/packages/224a9af1/confs/auto-adaptive.yaml:389:43: error: 'const struct esphome::ecodan::Status' has no member named 'has_independent_z2'; did you mean 'has_independent_zone_temps'?
  389 |               if (is_heating_active && status.has_independent_z2()) {
      |                                           ^~~~~~~~~~~~~~~~~~
      |                                           has_independent_zone_temps
/data/packages/224a9af1/confs/auto-adaptive.yaml:407:43: error: 'const struct esphome::ecodan::Status' has no member named 'has_independent_z2'; did you mean 'has_independent_zone_temps'?
  407 |               float actual_flow_temp = status.has_independent_z2() ? ((i == 0) ? status.Z1FeedTemperature : status.Z2FeedTemperature) : id(hp_feed_temp).state;
      |                                           ^~~~~~~~~~~~~~~~~~
      |                                           has_independent_zone_temps
/data/packages/224a9af1/confs/auto-adaptive.yaml:408:45: error: 'const struct esphome::ecodan::Status' has no member named 'has_independent_z2'; did you mean 'has_independent_zone_temps'?
  408 |               float actual_return_temp = status.has_independent_z2() ? ((i == 0) ? status.Z1ReturnTemperature : status.Z2ReturnTemperature) : id(hp_return_temp).state;
      |                                             ^~~~~~~~~~~~~~~~~~
      |                                             has_independent_zone_temps
/data/packages/224a9af1/confs/auto-adaptive.yaml:639:18: error: 'const struct esphome::ecodan::Status' has no member named 'has_independent_z2'; did you mean 'has_independent_zone_temps'?
  639 |           if (status.has_independent_z2()) {
      |                  ^~~~~~~~~~~~~~~~~~
      |                  has_independent_zone_temps

Ik zie waarschijnlijk weer iets over het hoofd in de yaml...:
Lijkt voornamelijk over z2 te gaan, maar die gebruik ik niet.

code:

packages:
  remote_package:
    url: https://github.com/gekkekoe/esphome-ecodan-hp/
    ref: main
    refresh: always
    files: [ 
            confs/base.yaml,            # required
            confs/energy.yaml,            # required
            confs/cpu-monitoring.yaml,    # recommended
            confs/short-cycle.yaml,     # recommended
            confs/auto-adaptive.yaml,    # recommended
            confs/request-codes.yaml,   # disable if your unit does not support request codes (service menu)
            confs/esp32s3.yaml,         # confs/esp32.yaml, for regular board
            #confs/esp32s3-led.yaml,    # atom s3 status leds
            confs/zone1.yaml,
            confs/server-control-z1.yaml,
            ## enable if you want to use zone 2
            #confs/zone2.yaml,
            #confs/server-control-z2.yaml,
            ## enable label language files
            confs/ecodan-labels-en.yaml,  # English
            # confs/ecodan-labels-nl.yaml,  # Dutch
            # confs/ecodan-labels-it.yaml,  # Italian
            # confs/ecodan-labels-fr.yaml,  # French
            # confs/ecodan-labels-de.yaml,  # German
            # confs/ecodan-labels-fi.yaml,  # Finnish
            # confs/ecodan-labels-no.yaml,  # Norwegian
            # confs/ecodan-labels-sv.yaml,  # Swedish
            # confs/ecodan-labels-da.yaml,  # Danish
            # confs/ecodan-labels-pl.yaml,  # Polish
            confs/debug.yaml,
            confs/wifi.yaml
           ]

external_components:
  - source: github://gekkekoe/esphome-ecodan-hp@main
    components: [ ecodan, optimizer ]
    refresh: always

[xoror]

@Beireken make clean of clear cache en nog eens proberen?

[Zjemm]

xoror schreef op donderdag 29 januari 2026 @ 22:49:
apart, moet je in dev tools kijken waarom die verbinding wordt gesloten, het werkt hier wel goed. Je moet hem lokaal openen met file:// en niet vanaf het web

dat was het idd

[Beireken]

xoror schreef op vrijdag 30 januari 2026 @ 08:31:
@Beireken make clean of clear cache en nog eens proberen?

Ik heb dit een tweede keer gedaan en nu kreeg ik de fout dat confs/short-cycle.yaml niet meer in de yaml mag
Dus toch iets over het hoofd gezien hehe.

[xoror]

Beireken schreef op vrijdag 30 januari 2026 @ 08:57:
[...]


Ik heb dit een tweede keer gedaan en nu kreeg ik de fout dat confs/short-cycle.yaml niet meer in de yaml mag
Dus toch iets over het hoofd gezien hehe.

https://github.com/gekkek.../main/ecodan-esphome.yaml
deze is altijd up to date, moet je daar tegen houden. Ik doe geen moeite meer om die backwards compatible te houden omdat er binaries zijn. Als je zelf kan compilen ga ik van uit dat je weet wat je doet en die file bij gaat houden

[Mooper]

Ik probeer de Melcloud adapter te koppelen aan mijn Atom, maar het wil nog niet echt lukken aangezien de lampjes niet branden. Zie ik iets over het hoofd?







Voordat ik vragen krijgen over de waarom: ik wil graag via Frank Energie het 'Slim Verwarmen' eens testen aangezien ik in mijn HA skills niet kundig genoeg ben.

[xoror]

@Mooper had je geen kabel bij je proxy pcb gekregen ? Je heb een andere kabel nodig als je de proxy pcb wil gebruiken. Die moet je in de heatpump poort doen (en de kabel die op de atom zit eruit halen)

De atom kabel geeft 12v niet door, die is nodig voor melcloud. Ik zeg het verder voor de zekerheid, niets in/uitpluggen als er spanning op het systeem staat (omdat ik zie dat je atom lampje aan is).

[ Voor 20% gewijzigd door xoror op 30-01-2026 10:09 ]

[Mooper]

xoror schreef op vrijdag 30 januari 2026 @ 10:06:
@Mooper had je geen kabel bij je proxy pcb gekregen ? Je heb een andere kabel nodig als je de proxy pcb wil gebruiken. Die moet je in de heatpump poort doen (en de kabel die op de atom zit eruit halen)

De atom kabel geeft 12v niet door, die is nodig voor melcloud. Ik zeg het verder voor de zekerheid, niets in/uitpluggen als er spanning op het systeem staat (omdat ik zie dat je atom lampje aan is).

Ik heb het teruggekregen vanuit mijn buurman maar zonder die kabel. Hij heeft die ook niet meer geeft die aan. Wat voor kabel is het precies, weet je dat toevallig? Dan schaf ik die zelf aan.

Ik was inderdaad niet van plan om iets in/uit te pluggen, maar bedankt voor de alertheid

[Geeforce]

@xoror even een vraag mbt de laatste update:

- Auto adaptive defrost mitigation staat nu aan. Kan me niet herinneren dat ik die had en waarom staat deze standaaard aan?

Ik mis nu de volgende entitie:
- sensor.ecodan_heatpump_zone_1_h_c_setpoint_value

[xoror]

@Mooper
Het zijn geen standaard kabels. Je heb een kabel nodig met 2x ST PAP-05V-S aan elk kant. Op internet kan je met wat speurwerk wel vinden. Je kan ook zelf de onderdelen kopen en zelf een kabeltje in elkaar zetten dat is het makkelijkst.

Ik heb ook de 2m kabels die ik bundel met asgard. stuur maar pm

@Geeforce heb je de release notes gelezen? ik heb de namen moeten renamen, de '/' mag niet meer. Dus hij heet nu
- sensor.ecodan_heatpump_zone_1_setpoint_value

Defrost mitigation is standaard uit, dus die heb je misschien per ongeluk aangezet. Je kan in history kijken wanneer dat is aangegeven in HA