Mitsubishi Ecodan warmtepomp uitlezen via cn105 + esp32

[xoror]

Software

Op https://github.com/gekkekoe/esphome-ecodan-hp staat de open source implementatie van esphome voor de Ecodan warmtepompen. Je kan daarmee je warmte pomp monitoren en bedienen vanuit home assistant (Als je Asgard PCB draait, kan je de warmtepomp ook bedienen via een lokale web interface)

Hardware

De integratie draait op een microcontroller. Hier vindt je meer info daarover.

Standalone mode (geen HA nodig)

Asgard kan ook werken zonder HA. Je kan alle besturing doen met 1 dag historische data.

Het is nu ook mogelijk on de melcloud wifi adapter als slave te gebruiken

Dit kan handig zijn wanneer je installateur nog bij melcloud moet, maar je toch alles lokaal via de esp wil regelen. voor meer info zie https://github.com/gekkek...p/blob/main/docs/proxy.md

Disclaimer

Gebruik is uiteraard op eigen risico en ik aanvaard geen enkele aansprakelijkheid. Het is een project wat ik in mijn vrije tijd doe, en niets voor vraag. Uiteraard gebruik ik het zelf ook.

Belangrijk!

Maak de unit altijd spanningsloos als je de unit in of uit wil pluggen. Dit geldt ook voor de slave units op de slave poort.

Home Assistant automations

Op github staan voorbeelden staan van automations

Hier is nog een instructie film hoe je het dashboard kan toevoegen in HA

[ Voor 193% gewijzigd door xoror op 02-10-2026 10:42 ]

[KabouterSuper]

Ik heb interesse. Sluit je deze aan in plaats van een melcloud of kan je dit samen met je melcloud gebruiken?

[xoror]

KabouterSuper schreef op zondag 24 maart 2024 @ 13:37:
Ik heb interesse. Sluit je deze aan in plaats van een melcloud of kan je dit samen met je melcloud gebruiken?

In plaatst van. Er zijn andere oplossingen als je ze beide wil draaien (zonde van het geld imho). Maar als je HA heb, waarom heb je nog melcloud nodig ;-)

[ Voor 3% gewijzigd door xoror op 24-03-2024 16:06 ]

[Takkeding]

Ik meld mij hier ook even als iemand die dit heeft draaien Spullen gekocht via de advertentie die je refereert. Heb het draaien met de ecodan esphome koppeling. Kwam er ook achter dat deze modules met USB-C aan de laptop gewoon te flashen zijn, dus je hebt geen USB-Serieel converter nodig wat puur gemak is en het nog toegankelijker maakt.

[xoror]

Ik heb een esphome versie gemaakt die te vinden is op: https://github.com/gekkekoe/esphome-ecodan-hp
probeer het eens uit zou ik zeggen.

[xoror]

Verdere aanpassingen gedaan:
- switches en selects nemen nu ook huidige waarde van wp over
- polling naar 30s gebracht
- meer attributen toegevoegd

[Miezie]

Even wachten op de module van @AUijtdehaag en dan gaat het hier am ende ook gebeuren 👍.

[Takkeding]

Netjes weer hoor! Valt overigens op dat Set flow target en set Z1 target beide de ruimte temperatuur lijken aan te passen. Tenminste, de sensor z1_room_temp_target knalde ook omhoog toen ik per ongeluk de Set Flow Target aanklikte haha.

[xoror]

Takkeding schreef op vrijdag 12 april 2024 @ 11:29:
Netjes weer hoor! Valt overigens op dat Set flow target en set Z1 target beide de ruimte temperatuur lijken aan te passen. Tenminste, de sensor z1_room_temp_target knalde ook omhoog toen ik per ongeluk de Set Flow Target aanklikte haha.

Hangt af of je op heating of op cooling staat. afhankelijk van de mode, wordt als het goed is het juiste ingesteld
Het is misschien nu een beetje dubbelop, en misschien verstop/verwijder ik een van de sensors. Zodat je altijd slider ziet die van toepassing is op de huidige mode.

[ Voor 15% gewijzigd door xoror op 12-04-2024 11:41 ]

[xoror]

weer wat verbeteringen aangebracht
- configs aangepast om een reguliere esp32 te supporten
- support voor zone1 en zone2 dmv include in config bestand

[xoror]

Holiday mode switch toegevoegd

[AUijtdehaag]

*klein schopje

Je code begint steeds vollediger te worden.
Heb er zelf nog een nederlandse vertaling aan toegevoegd.
(maar ik zet het pas later op github, als er niet veel meer wijzigt en er moet nog wat aangepast worden)

Ben benieuwd naar je nieuwe bevindingen na het uitlezen van de signalen van de procon.
Keep up the good work @xoror

[xoror]

Ondertussen ben ik wel druk bezig geweest met dit projectje.
- Proxy mechanisme toegevoegd (vergelijkbaar aan heishamon) zo dat je een slave apparaat kan aansluiiten (melcloud wifi adapter of procon bijv). Enige probleem hierbij is dat je hiervoor wel wat moet solderen, dat is niet zo handig.
- Ik kan ondertussen de procon afluisteren en ontbrekende commandos bekijken

hierdoor heb ik al een paar bugs kunnen fixen en de signed temp set commands achterhaald en geimplementeerd.

volgens de procon manual is prohibit cool z1/z2 writeable, maar dat lijkt niet te werken (iemand die hier wat meer van weet?)

hier foto van de setup:


1) atom S3 is verbonden via een 'cn105' met de procon.
2) atom S3 met modbus module die praat via modbus met de procon.

We kunnen nu dus modbus registers schrijven en aan de andere ant kijken wat de procon ervan maakt.

[ Voor 22% gewijzigd door xoror op 27-04-2024 22:08 ]

[ocaj]

xoror schreef op zaterdag 27 april 2024 @ 21:41:
volgens de procon manual is prohibit cool z1/z2 writeable, maar dat lijkt niet te werken (iemand die hier wat meer van weet?)

In de oorspronkelijke procon-handleiding waren registers 39, 40 en 41 van functiecode 03 alle 3 writable. In de Nederlands-talige installatiehandleiding staat bij 39 en 40 dat ze Alleen-lezen zijn.

Maar zoals je al vastgesteld hebt: 41 (koelen) is ook zo read-only als het maar zijn kan. Althans, bij mij werkt hij - met alleen een Procon - ook niet....

[xoror]

ocaj schreef op zaterdag 27 april 2024 @ 22:41:
[...]


In de oorspronkelijke procon-handleiding waren registers 39, 40 en 41 van functiecode 03 alle 3 writable. In de Nederlands-talige installatiehandleiding staat bij 39 en 40 dat ze Alleen-lezen zijn.

Maar zoals je al vastgesteld hebt: 41 (koelen) is ook zo read-only als het maar zijn kan. Althans, bij mij werkt hij - met alleen een Procon - ook niet....

Het grappige is, is dat wanneer je de read only registers schrijft, de procon toch een commando stuurt naar de ecodan over de cn105. Het blijft merkwaardig allemaal.

[ocaj]

Dat is inderdaad interessant. Voor de Procon zijn het dus read/write-registers, maar de FTC negeert ze simpelweg. Daar is niet veel meer aan te doen dan vragen bij Alkima of ze dat in nieuwe firmware kunnen oplossen (maar ik verwacht niet dat dat heel kansrijk zal zijn....).

[xoror]

heb de nieuwe velden en commandos toegevoegd en gedocumenteerd:
https://github.com/gekkek...-hp/blob/main/protocol.md

- water pump status
- 3 way valve
- refrigerant liquid temp

achterhaald met de procon, en nog boel andere kleine dingen

[badFISH]

Ik heb de nieuwe config meteen geinstalleerd. Kan het zijn dat bij de refrigerant liquid temp de komma nog 1 plaats naar links moet (dus gedeeld door 10)?


Verder wel gaaf wat je zo voor elkaar krijgt!

[xoror]

badFISH schreef op zondag 28 april 2024 @ 11:18:
Ik heb de nieuwe config meteen geinstalleerd. Kan het zijn dat bij de refrigerant liquid temp de komma nog 1 plaats naar links moet (dus gedeeld door 10)?
[Afbeelding]

Verder wel gaaf wat je zo voor elkaar krijgt!

dat ziet er fout uit ik ga even uitzoeken
[edit] lol had ik wel goed opgeschreven, maar heb ik in de code fout uitgelezen. Bedankt voor reporten, is aangepast, even verversen


Waar ik nog over na moet denken is dat je niet teveel wijzigingen achter elkaar stuurt, de WP verwerkt maar 1x per zoveel tijd, en als ze overlappen gaan soms commando's verloren. Moet nog even kijken hoe ik dit mooi oplost (misschien minder vaak updaten, of minder snel commando's sturen, maar daar ben ik nog niet over uit).

Voor nu even 1 commando per refresh van de sensoren aanhouden, dan zit je wel save (dus 1x per +- 30s)
het automatisch aanpassen van de dropdownlijsten is daardoor ook uitgezet (want dit kan een update triggeren tijdens een van je andere commando's)

[ Voor 40% gewijzigd door xoror op 28-04-2024 11:42 ]

[xoror]

Zojuist een grote push gedaan.
- correcte detectie dhw forced mode
- in1 thermostaat ingang
- booster heater
- immersion heater
- heater source
- controller version
- en ben nog vast een boel vergeten

Het belangrijkste is denk ik de nieuwe manier van commando's versturen. Ze worden nu gegroepeerd zodat er geen commandos verloren gaan. Het kan zijn dat je pas na 10-20s de geupdate waarde terug ziet, maar uiteindelijk komt het er wel te staan.

Voor nu denk ik dat ik alle velden gevonden heb die ik wilde vinden. het is nu vooral finetunen.

[xoror]

nog een paar velden toegevoegd
- In6 (room 2 thermostat) ingang
- 2e pomp
- 2e 3-wegsklep

[xoror]

we kunnen nu zelfs meer dan de procon

In de server control mode kunnen we de prohibit flags zetten. De gevonden procon cmds werken in server control mode. Ik heb als experiment een switch gemaakt om server control en dhw te schakelen. Dan kan je dhw verbieden of toestaan. Het zelfde kan vrij eenvoudig voor koelen/verwarmen.

[Plenkske]

@xoror mooi gevonden !
Is er nog een nadeel van die "server control mode" ? of doe je het simpelweg zo:
- inschakelen server control mode
- prohibit commando
- uitschakelen server control mode

[xoror]

@Plenkske
Over Server Control is weinig te vinden in de documentatie. Het is dus een beetje gokken wat het precies doet.

Wanneer server control mode verlaat herstelt hij de settings, dus je aanpassingen zijn dan weg. Maar ik heb nog geen nadelige effecten gezien van de server control mode, dus misschien kan je beter gewoon in die mode draaien als je handmatig de prohibits wil doen.

In mijn repo kan je nu een regel un-commenten en dan krijg je alle switches om mee te spelen.

Met dank aan @AUijtdehaag voor de vertalingen, daardoor kan je nu ook NL kiezen als taal.

[Plenkske]

Zou het kunnen dat in "server control mode" je geen aanpassingen kan doen op het scherm ? Dat de unit daar niks mee doet totdat je die modus verlaat ?

[xoror]

Voor een aantal settings lijkt dat het geval (heating/cooling en dhw). Maar ik kan wel force dhw nog doen via scherm. is dus wel een klein nadeel (alhoewel als je een esp32 eraan heb hangen, kan je alles natuurlijk aanpassen in esphome/home assistant)

[AUijtdehaag]

Begint weer ergens op te lijken...

[ Voor 23% gewijzigd door AUijtdehaag op 08-05-2024 14:42 ]

[xoror]

heb nog realtime output power toegevoegd, heb je gelijk ter beschikking ipv nog in HA een template sensor maken.

[AUijtdehaag]

Nice.

Heb je rekening gehouden met een abs getal?
Bij koelen is de deltaT negatief en dus ook de power.

Als ik toch mag verzoeken mis ik nog ook de deltaT voor in mijn plaatje linksboven
Die wil ik wel graag negatief

code:

template:
  - sensor:
    - name: ecodan_heatpump_delta_t
      unique_id: ecodan_heatpump_delta_t
      unit_of_measurement: "°C"
      state: >-
        {% set ta = states('sensor.ecodan_heatpump_aanvoer_temp') | default(0) | float %}
        {% set tr = states('sensor.ecodan_heatpump_retour_temp') | default(0) | float %}
        {{ 0 if freq == 0 else (ta - tr)| float | round(1) }}

Ik ga morgen eens spelen met een template thermostaat
https://github.com/jcwillox/hass-template-climate
Kijken of dat wat is.

Edit: en de procon op vraag en aanbod zetten

[ Voor 3% gewijzigd door AUijtdehaag op 10-05-2024 21:47 ]

[roelzadh]

Ik zat te testen met cooling automatisch instellen:

• Cooling flow mode ingesteld
• Heating compensation mode ingesteld
• Warmte pomp begint te verwarmen
• Thermostaat op 19.5, ruimte temperatuur is 21.5

Meer mensen die dit hebben?

[xoror]

AUijtdehaag schreef op vrijdag 10 mei 2024 @ 21:44:
Nice.

Heb je rekening gehouden met een abs getal?
Bij koelen is de deltaT negatief en dus ook de power.

Als ik toch mag verzoeken mis ik nog ook de deltaT voor in mijn plaatje linksboven
Die wil ik wel graag negatief

code:

template:
  - sensor:
    - name: ecodan_heatpump_delta_t
      unique_id: ecodan_heatpump_delta_t
      unit_of_measurement: "°C"
      state: >-
        {% set ta = states('sensor.ecodan_heatpump_aanvoer_temp') | default(0) | float %}
        {% set tr = states('sensor.ecodan_heatpump_retour_temp') | default(0) | float %}
        {{ 0 if freq == 0 else (ta - tr)| float | round(1) }}

Ik ga morgen eens spelen met een template thermostaat
https://github.com/jcwillox/hass-template-climate
Kijken of dat wat is.

Edit: en de procon op vraag en aanbod zetten

voor mezelf had ik altijd negatief, maar ik denk dat het voor iedereen beter altijd positief is. of hebben jullie het liever negatief

@roelzadh
wat is het probleem precies? Ik begrijp het niet helemaal.
- in cool flow wordt de Ta bepaald door Zone 1 H/C setpoint value (deze kan je instellen met de slider)
- in compensation curve bepaalt de wp de Ta. aanpassen van de Ta heeft geen nut in deze mode.

in beide gevallen, als je thermostaat zijn trigger heeft bereikt schakelt hij de wp aan/uit. Je kan dit zien aan de In1 ingang (als je thermostaat daar aan hangt)

Soms moet je ook je je thermostaten vertellen dat je gaat koelen/verwarmen als deze niet meeschakelen met de wp.

[ Voor 26% gewijzigd door xoror op 10-05-2024 22:16 ]

[Jazzle]

Bedankt voor deze mooie oplossing. Ik heb inmiddels alles draaien (op een m5stickc), en alle data komt netjes door. Echter, ik kan geen waardes aanpassen: die veranderen dan vanzelf weer terug of in het geval van temperaturen worden ze simpelweg niet aangepast.

Wat me in de logging opvalt:

code:

[22:27:06][I][ecodan.component:290]: command queue was not empty when queueing status query: 147

Dat getal loopt steeds verder op. Enig idee wat er mis kan zijn?

[xoror]

dwz dat hij commandos niet kan sturen. 147 stuks pending bij elke update leest hij weer de wp waarde uit (je set cmds zijn nooit verstuurd)

heb je juiste esp32 gekozen? standaard ga ik van de s3 uit. maar ik gok het wel anders compileert het niet.

heb je tx pin goed ingesteld? anders even je tx lijn doormeten.

maar lijkt mij dat je dat wel goed gedaan heb, anders kan je nooit de connect handshake naar de wp sturen.

staat er nog meer in de logging? sync voor de zekerheid naar laatste code van vandaag

voor de zekerheid (zo geconfigureerd toch?):

code:

  rx_pin: GPIO32
  tx_pin: GPIO33

@Jazzle zie je verder ook FTC version terugkomen?
Laatste wat ik nog kan bedenken is dat je misschien iets te ongeduldig bent, probeer even als test de dhw setpoint aan te passen en wacht even 30s om te kijken of de value wordt aangepast ?

[ Voor 62% gewijzigd door xoror op 11-05-2024 08:33 ]

[roelzadh]

@xoror
Denk dat die inderdaad met cooling flow begon en die stond op default 30c. Na 5 minuten sloeg die weer netjes af.

Ik begrijp dus goed dat ik voor verwarming op compensation curve de h/c waarde negeer en hij van de ingestelde stooklijn pakt.

[xoror]

roelzadh schreef op vrijdag 10 mei 2024 @ 23:20:
@xoror
Denk dat die inderdaad met cooling flow begon en die stond op default 30c. Na 5 minuten sloeg die weer netjes af.

Ik begrijp dus goed dat ik voor verwarming op compensation curve de h/c waarde negeer en hij van de ingestelde stooklijn pakt.

Juist, als je zelf Ta wil aanpassen tijdens verwarmen, moet je Heat flow kiezen.
Let ook op dat na het aanpassen het wel 15s kan duren voordat de wp het verwerkt heeft.

[Jazzle]

xoror schreef op vrijdag 10 mei 2024 @ 22:38:
dwz dat hij commandos niet kan sturen. 147 stuks pending bij elke update leest hij weer de wp waarde uit (je set cmds zijn nooit verstuurd)

heb je juiste esp32 gekozen? standaard ga ik van de s3 uit. maar ik gok het wel anders compileert het niet.

heb je tx pin goed ingesteld? anders even je tx lijn doormeten.

maar lijkt mij dat je dat wel goed gedaan heb, anders kan je nooit de connect handshake naar de wp sturen.

staat er nog meer in de logging? sync voor de zekerheid naar laatste code van vandaag

voor de zekerheid (zo geconfigureerd toch?):

code:

  rx_pin: GPIO32
  tx_pin: GPIO33

@Jazzle zie je verder ook FTC version terugkomen?
Laatste wat ik nog kan bedenken is dat je misschien iets te ongeduldig bent, probeer even als test de dhw setpoint aan te passen en wacht even 30s om te kijken of de value wordt aangepast ?

Het aantal loopt afgelopen nacht op tot enkele duizenden. De handshake gaat blijkbaar goed want er komt data binnen, dus ook TX zou wel moeten werken, of zouden de waarden gewoon doorkomen omdat er eerst een Melcloud kastje aan hing?

De Controller versie komt door (FTC6), de compressor frequentie overigens niet.

Anders lijkt het er op dat de ESP het op de een of andere manier niet bij kan benen?

Relevante delen uit de config:

code:

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

packages:
  remote_package:
    url: https://github.com/gekkekoe/esphome-ecodan-hp/
    ref: main
    refresh: always
    files: [ 
            #/esp32s3.yaml, # confs/esp32.yaml, for regular board
            confs/zone1.yaml,
            ## enable if you want to use zone 2
            #confs/zone2.yaml,
            ## enable label language file
            confs/ecodan-labels-en.yaml,
            #confs/ecodan-labels-nl.yaml,
            #confs/server-control.yaml,
            #confs/debug.yaml,
           ]

esp32:
  board: m5stick-c
  framework:
    type: arduino

ecodan:
  id: ecodan_instance
  rx_pin: GPIO32
  tx_pin: GPIO33

[ Voor 23% gewijzigd door Jazzle op 11-05-2024 10:52 ]

[xoror]

Ja hij heeft 15s om alles te verwerken, daarna komt een nieuwe status request. hier op mijn atom is hij altijd < 10s klaar. de status query wordt alijd vooraan de queue gezet, en in jouw geval komen de set cmd nooit aan de beurt. Het lijk me sterk dat hij nog replied op melcloud commandos. replies zijn meestal binnen paar seconden.

Nu weet ik niet zeker of dit het geval is, en wil niet voor iedereen de timing omlaag gooien. Op zich wordt er niet veel gedaan, dus ik verbaas me dat jouw esp32 pico het niet kan bij benen. zie je wel pauzes in de logging of is het een continue stroom aan berichten ?

je kan gewoon als board esp32dev proberen hoor, misschien dat dat beter werkt.

[Jazzle]

xoror schreef op zaterdag 11 mei 2024 @ 11:25:
Ja hij heeft 15s om alles te verwerken, daarna komt een nieuwe status request. hier op mijn atom is hij altijd < 10s klaar. de status query wordt alijd vooraan de queue gezet, en in jouw geval komen de set cmd nooit aan de beurt. Het lijk me sterk dat hij nog replied op melcloud commandos. replies zijn meestal binnen paar seconden.

Nu weet ik niet zeker of dit het geval is, en wil niet voor iedereen de timing omlaag gooien. Op zich wordt er niet veel gedaan, dus ik verbaas me dat jouw esp32 pico het niet kan bij benen. zie je wel pauzes in de logging of is het een continue stroom aan berichten ?

je kan gewoon als board esp32dev proberen hoor, misschien dat dat beter werkt.

Met esp32dev als board blijft het gedrag hetzelfde. Ik zie inderdaad in de logging ook wel dat hij soms enkele seconden hangt tussen de verschillende berichten, ik vermoed dat 15s niet voldoende is in mijn geval. Ik kan de repo ook forken en dat aanpassen, maar het blijft raar dat daar verschil in zou zitten.

[xoror]

als je pauzes ziet dan wacht hij...
welke WP/FTC is het (misschien dat die extreem lang doet over antwoorden) ? je zou kunnen proberen te forken en even aanpassen. Draait je stick misschien op hele lage mhz ivm batterij oid?

https://github.com/gekkek...dan/ecodan.h#L23C9-L23C23 wijzig die naar iets van 30s

en

https://github.com/gekkek...ts/ecodan/serial.cpp#L139

ook naar 30s.

nogmaal zou me verbazen, maar je het kan proberen.
yaml even aanpassen dat hij lokaal files neemt (en remote files commenten)

[ Voor 63% gewijzigd door xoror op 11-05-2024 11:54 ]

[Jazzle]

xoror schreef op zaterdag 11 mei 2024 @ 11:47:
als je pauzes ziet dan wacht hij...
welke WP/FTC is het (misschien dat die extreem lang doet over antwoorden) ? je zou kunnen proberen te forken en even aanpassen. Draait je stick misschien op hele lage mhz ivm batterij oid?

https://github.com/gekkek...dan/ecodan.h#L23C9-L23C23 wijzig die naar iets van 30s

en

https://github.com/gekkek...ts/ecodan/serial.cpp#L139

ook naar 30s.

nogmaal zou me verbazen, maar je het kan proberen.
yaml even aanpassen dat hij lokaal files neemt (en remote files commenten)

Het is een FTC6, maar het lijkt er inderdaad op dat deze trager reageert. Nu met polling freq aangepast naar 30/25 seconden stapelen de berichten niet meer op, en zie ik dat commando's wel gestuurd worden. Nog steeds doet de FTC niks met die commando's... vanavond verder puzzelen.

Edit: de queue loopt alsnog op. Ik verplaats de discussie naar Github

[ Voor 3% gewijzigd door Jazzle op 11-05-2024 17:45 ]

[xoror]

ik heb ook een FTC6. maar klinkt alsof het niet aankomt (hij zou wel moeten klagen in de log), dus zou je tx pin/kabel even voor de zekerheid nalopen.

[roelzadh]

xoror schreef op vrijdag 10 mei 2024 @ 23:25:
[...]


Juist, als je zelf Ta wil aanpassen tijdens verwarmen, moet je Heat flow kiezen.
Let ook op dat na het aanpassen het wel 15s kan duren voordat de wp het verwerkt heeft.

Gebruik voor heating curve, voor cooling flow = 18c.

Toch lijkt het erop dat als je de operation mode veranderd hij standaard begint met verwarmen/koelen zonder naar de thermostaat te kijken.

[xoror]

@Jazzle ik lees dat de m5stickc alleen 5v output doet op de grove port.

de cn105 levert juist alleen op die pin. Je esp draait nu via batterij of power je via usb?

misschien werkt de stickc daarom niet goed. kan je de 5v van de cn105 gebruiken als voeding? zo te zien kan hij alleen via usb of batterij.

heb je nog een esp met grove poort die ook 5v input support? ik zou de m5stickc niet gebruiken hiervoor.

[ Voor 32% gewijzigd door xoror op 11-05-2024 21:55 ]

[Jazzle]

xoror schreef op zaterdag 11 mei 2024 @ 21:49:
@Jazzle ik lees dat de m5stickc alleen 5v output doet op de grove port.

de cn105 levert juist alleen op die pin. Je esp draait nu via batterij of power je via usb?

misschien werkt de stickc daarom niet goed. kan je de 5v van de cn105 gebruiken als voeding? zo te zien kan hij alleen via usb of batterij.

heb je nog een esp met grove poort die ook 5v input support? ik zou de m5stickc niet gebruiken hiervoor.

Scherp, maar de 5v heb ik verbonden met de 5v in op de HAT pinnen aan de andere kant (custom kabeltje gemaakt).

[xoror]

roelzadh schreef op zaterdag 11 mei 2024 @ 18:49:
[...]

Gebruik voor heating curve, voor cooling flow = 18c.

Toch lijkt het erop dat als je de operation mode veranderd hij standaard begint met verwarmen/koelen zonder naar de thermostaat te kijken.

Als je via de main controller van de warmtepomp van mode wisselt, werkt hij dan anders? wat verwacht je dat het moet doen? ik begrijp niet helemaal wat het probleem is namelijk

@Jazzle ah okay, als ik tijd heb zal ik de logging eens bekijken

[ Voor 6% gewijzigd door xoror op 11-05-2024 23:27 ]

[roelzadh]

Kan het zijn dat deze setting de verkeerde waarde aanpast.

Zone 1 H/C setpoint value is 15 terwijl ik 16.5 verwacht.
Zone 1 room setpoint temperature is wel 16.5 waar ik 24c verwacht.

[xoror]

Als je tussen modes switched herstelt hij de opgeslagen waarden, deze zie je in de 'xxx value' velden. De slider wordt niet mee geupdate , dat gaf namelijk nare bij effecten. het is dus een richtingsverkeer.

als je even na mode switch de waarde ook instelt van de slider gaat het verder wel goed. Ik was nog aan het kijken naar manieren om dit goed te laten werken, maar voorlopig even uitgezet.

[roelzadh]

Ik wil eigenlijk het volgende bereiken:
- Koelen
- Minimale flow temperatuur = 18c
- Zone 1 room setpoint = 24c

Ik gebruik de draadloze thermostaat die bij de Ecodan geleverd is, mijn verwachting is dat die met 18 graden water gaat koelen als het 24 graden of meer is en stopt als de thermostaat 23 aangeeft.

Als ik in mode Cool Target Temperature zit past de Zone 1 H/C setpoint de warde aan van Zone 1 room setpoint value en niet van Zone 1 H/C setpoint value.

Verander ik de mode naar Cool Flow Temperature, dan lijken de sliders wel de juiste waarde aan te passen?

Volgens mij heb ik het nu voor elkaar, door eerst de Ecodan uit te zetten voor het wisselen heb ik geen onverwacht gedrag meer dat hij aanslaat op de verkeerde waardes. Na 30 seconden switch ik de Ecodan weer aan. Mode Cool Flow Temperature is dus de waarde die ik moest gebruiken voor wat ik wil bereiken. De naam Cool Target Temperature bracht wat verwarring met zich mee

[ Voor 24% gewijzigd door roelzadh op 13-05-2024 18:54 ]

[xoror]

omdat een aantal mensen WP's hebben die wat traag reageren, heb ik het mechanisme iets aangepast. Verder doe ik nu ook set cmd opnieuw sturen als er geen ack van de wp komt. Dit moet ervoor zorgen dat er minder/geen commando's verloren gaan.

[alberthakvoort]

Misschien nog even de slider aanpassen, zodat koelen ook vanaf 16 graden kan?

[xoror]

@alberthakvoort
hmm ik kan gewoon tussen 5-60 aanpassen? zowel op de esp als in ha.
is dit wel mijn firmware ? heb idee van niet namelijk. Het heet al heel lang H/C setpoint bij mij. even voor de zekerheid bijwerken naar laatste versie ?

[ Voor 41% gewijzigd door xoror op 14-05-2024 12:05 ]

[alberthakvoort]

xoror schreef op dinsdag 14 mei 2024 @ 12:05:
@alberthakvoort
hmm ik kan gewoon tussen 5-60 aanpassen? zowel op de esp als in ha.
is dit wel mijn firmware ? heb idee van niet namelijk. Het heet al heel lang H/C setpoint bij mij. even voor de zekerheid bijwerken naar laatste versie ?

[Afbeelding]

Ik had juist net alles opnieuw er opgezet,

url: https://github.com/gekkekoe/esphome-ecodan-hp/

Of er moet nog iets in HA mis gaan qua cache

[xoror]

alberthakvoort schreef op dinsdag 14 mei 2024 @ 12:14:
[...]


Ik had juist net alles opnieuw er opgezet,

url: https://github.com/gekkekoe/esphome-ecodan-hp/

Of er moet nog iets in HA mis gaan qua cache

Er zijn wat naamswijziging en geweest, mogelijk is dit nog de oude die nog niet is opgeruimd

werkt alles nu naar behoren?

[ Voor 13% gewijzigd door xoror op 14-05-2024 12:24 ]

[AUijtdehaag]

@alberthakvoort
Bij nieuwe download, kan je misschien het beste de esphome device verwijderen onder instellingen / apparaten en diensten / esphome / drie puntjes
En dan HA herstarten. Dan vind hij hem weer

[ Voor 7% gewijzigd door AUijtdehaag op 14-05-2024 12:27 ]

[alberthakvoort]

AUijtdehaag schreef op dinsdag 14 mei 2024 @ 12:26:
@alberthakvoort
Bij nieuwe download, kan je misschien het beste de esphome device verwijderen onder apparaten en diensten / esphome
En dan HA herstarten. Dan vind hij hem weer

Dan had ik gedaan, als ik bij Esphome hem bekijk blijft hij daar ook op minimaal 20 staan.. :



Ik zie in de webinterface wel dat hij niet alle velden goed laat zien... Ik gebruik nu wel even een esp01_1m variant...

[ Voor 28% gewijzigd door alberthakvoort op 14-05-2024 12:31 . Reden: Screenshot aangepast ]

[AUijtdehaag]

Ook als je hem bekijkt met http://ecodan-heatpump.local/ ?
Ik heb de laatste versie nog niet bijgewerkt in ieder geval dus of er foutjes in zitten weet ik niet.
Ik kan eventueel een bin versturen van een vorige versie?

[ Voor 29% gewijzigd door AUijtdehaag op 14-05-2024 12:33 ]

[xoror]

ik zie allemaal termen van de concurrent in je HA en ESPHome

[ Voor 18% gewijzigd door xoror op 14-05-2024 13:02 ]

[AUijtdehaag]

Esp write protected

@alberthakvoort
Dat is een ESP01-1m en geen atom ESP32?
Kan het daar aan liggen?

[ Voor 70% gewijzigd door AUijtdehaag op 14-05-2024 12:38 ]

[xoror]

nee dit is de andere esphome firmware. ik zie aan de benaming.

@AUijtdehaag ESP01-1m zou ook moeten werken, maar ik heb nog geen definitie file gemaakt voor de 8266
je moet dus even een maken en dan builden.

@alberthakvoort
zoek in je build yaml board definitie op en plak die in mijn build yaml. comment de esp32 even eruit, dan zou het wel moeten builden voor je board.

[ Voor 83% gewijzigd door xoror op 14-05-2024 12:55 ]

[AUijtdehaag]

@xoror
Voor de procon esphome versie, was de esp8266 te beperkt in geheugen volgens mij.
Daar liep het vast met teveel code.
En waarom zou je een oudere hardware versie nemen dan een esp32?

[xoror]

@AUijtdehaag
als je niets anders heb liggen ;-) maar een atom is uiteraal the way to go.
Overigens denk ik dat het door die bloatware komt die je erop had
op zich past mijn firmware prima op een 8266

code:

Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  15.1% (used 49552 bytes from 327680 bytes)
Flash: [=====     ]  52.5% (used 963365 bytes from 1835008 bytes)

[alberthakvoort]

AUijtdehaag schreef op dinsdag 14 mei 2024 @ 12:57:
En waarom zou je een oudere hardware versie nemen dan een esp32?

Ik had er nog 5 liggen, en had er destijds voor wat kennissen een CN105 klaar gemaakt. Wilde even testen of deze variant ook goed draaide

@xoror ik heb niet goed gelezen, net terug van vakantie...
Ik las "for regular board" maar dat is uiteraard een ESP32....

[ Voor 18% gewijzigd door alberthakvoort op 14-05-2024 14:23 ]

[xoror]

alberthakvoort schreef op dinsdag 14 mei 2024 @ 14:17:
[...]


Ik had er nog 5 liggen, en had er destijds voor wat kennissen een CN105 klaar gemaakt. Wilde even testen of deze variant ook goed draaide

@xoror ik heb niet goed gelezen, net terug van vakantie...
Ik las "for regular board" maar dat is uiteraard een ESP32....

Als je de esp32.yaml even aanpast naar jouw board, moet het ook werken gok ik zo

[alberthakvoort]

xoror schreef op dinsdag 14 mei 2024 @ 14:49:
[...]


Als je de esp32.yaml even aanpast naar jouw board, moet het ook werken gok ik zo

esp8266:
board: esp01_1m

De framework optie blijkbaar alleen voor de ESP32? Die herkend hij namelijk niet. Als ik die weghaal klaagt hij over

src/esphome/components/ecodan/commands.cpp:3:10: fatal error: esp_log.h: No such file or directory

*****************************************************************
* Looking for esp_log.h dependency? Check our library registry!
*
* CLI > platformio lib search "header:esp_log.h"
* Web > https://registry.platformio.org/search?q=header:esp_log.h
*
*****************************************************************

3 | #include "esp_log.h"
| ^~~~~~~~~~~
compilation terminated.
*** [.pioenvs/ecodan-heatpump/src/esphome/components/ecodan/commands.cpp.o] Error 1
src/esphome/components/ecodan/ecodan.cpp:3:10: fatal error: esp_log.h: No such file or directory


Of moet ik hem dan handmatig compilen en niet via ESPhome zelf in HA?

[xoror]

probeer via HA ? hmm die 8266 heeft geen esp log
moet wat meer aangepast worden zo te zien. Misschien beter een atom scoren voor 9 euro
Als ik wat tijd heb zal ik kijken wat ik voor de 8266 kan doen

[ Voor 136% gewijzigd door xoror op 14-05-2024 15:45 ]

[alberthakvoort]

xoror schreef op dinsdag 14 mei 2024 @ 15:33:
probeer via HA ? hmm die 8266 heeft geen esp log
moet wat meer aangepast worden zo te zien. Misschien beter een atom scoren voor 9 euro
Als ik wat tijd heb zal ik kijken wat ik voor de 8266 kan doen

Als het teveel moeite is laat je het maar zitten hoor, dan blijven ze maar op de oudere repo zitten, en anders upgraden ze de zaak maar naar een atom

[xoror]

even gekeken, de logging is eenvoudig opgelost, maar toen liep ik tegen aan dat freertos niet wordt ondersteund op 8266 lijkt het, of ik zie even niet snel hoe. Die heb ik nodig om achtergrond task te draaien om de serial port te luisteren

hmm helaas denk ik, mis je hoop leuke dingen (je kan geen flow temp zetten in cooling modus, mist al die extra flags, vacation mode, ...)

Mijn repo is btw niet op die andere esphome gebaseerd he, maar op ecodan ha local. Alhoewel daar nu bijna niets meer van over is

[ Voor 28% gewijzigd door xoror op 14-05-2024 16:53 ]

[xoror]

Ik heb weer een aanpassing gedaan, hoofd yaml is opgeschoond, alle sensoren zijn naar een aparte file verplaatst. Dan kunnen user configs gescheiden worden van het systeem. Dan kan ik wat makkelijker updates doorvoeren zonder configs van users aan te raken.

Verder is de 2e temp sensor voor dhw gevonden door een andere ontwikkelaar (degene waar hij niet op stuurt) en toegevoegd. Degene die 2 temp sensoren hebben in hun boiler, laat even weten of het goed werkt. (lijkt FTC6 only btw)

[Miezie]

xoror schreef op dinsdag 14 mei 2024 @ 18:15:
Ik heb weer een aanpassing gedaan, hoofd yaml is opgeschoond, alle sensoren zijn naar een aparte file verplaatst. Dan kunnen user configs gescheiden worden van het systeem. Dan kan ik wat makkelijker updates doorvoeren zonder configs van users aan te raken.

Verder is de 2e temp sensor voor dhw gevonden door een andere ontwikkelaar (degene waar hij niet op stuurt) en toegevoegd. Degene die 2 temp sensoren hebben in hun boiler, laat even weten of het goed werkt. (lijkt FTC6 only btw)

Eindbaas! Ik bleef die yaml maar updaten .

Pas je wel op met de sensornamen? Zal zo even naar de sensor voor je kijken.

[xoror]

2e dhw temp sensor is goed, heb al confirmation gekregen.
verder nog koelmiddel condensatie temp toegevoegd

[Miezie]

Ik zie het hier nu ook. Zag ook dat @AUijtdehaag fanatiek vertaald had... alleen een week terug waren toen ook de sensor id's anders. Is dit het plan? Of vertalen we labels... misschien ga ik dan op een verloren moment nog even refactoren.

[xoror]

dat is het probleem met HA, in esphome zijn de id's gelijk. Ha wil alleen altijd van de namen de id's afleiden. Ik heb daar nog geen oplossing voor gevonden. Hij zou gewoon de esphome id's moeten gebruiken.

Denk dat er alleen nog dingen worden toegevoegd. ze worden pas gewijzigd als het echt fout is. (ik moet ook in HA aanpassen als ik wijzig, dus dat is soort stok achter de deur zeg maar . De vertaalslag was nodig om meerdere talen te supporten. daar gaat niet zoveel meer in wijzigen)

[ Voor 10% gewijzigd door xoror op 15-05-2024 09:32 ]

[Plenkske]

Ik ben al een tijdje aan het klooien om verbinding te krijgen via een ESP32. Wil nog niet lukken.
(heeft ook lang stil gelegen door andere prioriteiten)

Eerst een lolin32, maar die bleek gaar te zijn (gaf veel wifi errors) en ook de level shifter was anders dan die andere gebruiken.
Kortom, wat nieuwe hardware besteld en dat gesoldeerd.
Ook de kabel opnieuw gemakt om uit te sluiten of het dat is.
Aangezien ik begon met schema en software van @barteg zijn project, gebruik ik ook een 12v - 5v voor de power van het esp32 bordje. Dat heeft altijd goed gewerkt.


Huidige ESP32 is dit bordje: https://www.tinytronics.n...rd-met-wi-fi-en-bluetooth

Schema is als volgt (vergeef mijn paint skills):



Ik heb verschillende keren het schema nagekeken met andere schema's. Ook heb ik met een simpele multimeter gecontroleerd of alle soldeerverbindingen goed zijn, en daarbij ook gekeken of niet per ongeluk verkeerde pins geraakt worden. Ook softwarematig verschillende keren de tx/rx omgedraaid.

Waar loop ik al vanaf het begin vast: de "connect" commando geeft geen reactie van de WP. Kortom dat blijft hij proberen maar geeft geen resultaat.
Eerst met Bart zijn software, en aanpassingen daarop.
Daarna met ecodan-ha-local.
En nu als laatste met de esphome van @xoror . Daar heb ik mqtt aan toegevoegd in de config (dat werkt).
Maar ik krijg het volgende in de log:




Weet iemand wat ik nog kan proberen om het werkend te krijgen ?

[AUijtdehaag]

@Plenkske
Ik kan wel een Atom opsturen eventueel?

[Plenkske]

AUijtdehaag schreef op donderdag 16 mei 2024 @ 11:46:
@Plenkske
Ik kan wel een Atom opsturen eventueel?

Als niemand ideeën heeft om de huidige hardware werkend te krijgen, dan was dit wel het volgende waar ik aan dacht ja

[xoror]

sommige boards zijn de eerste pinnen reserved. heb je tx/rx op 16/17 geprobeerd?

[Plenkske]

xoror schreef op donderdag 16 mei 2024 @ 12:15:
sommige boards zijn de eerste pinnen reserved. heb je tx/rx op 16/17 geprobeerd?

Bedoel je: soldeer ze op 16/17 en stel dat in , in de software ?
Want voor dit bordje heb ik alleen de aangeduide TX (GPIO1) en RX (GPIO3) geprobeerd. En in de software dus ook reverse test gedaan.

[xoror]

solderen op pin 16/17 en dan software instellen op 16/17

[Plenkske]

xoror schreef op donderdag 16 mei 2024 @ 12:37:
solderen op pin 16/17 en dan software instellen op 16/17

Dit was het !! Hij doet het eindelijk !
Blijkbaar voor dit bordje dus inderdaad die pins nodig.

Ik denk dat bij mijn vorige hardware ofwel de gare lolin32 ofwel de gare level shifter het probleem was.


Ik zie in de log berichten dit steeds terugkomen (ik heb zelf nog niets aangepast):

code:

14:35:36    [I] [ecodan.component:045][1;31m[serial_rx_task][0;32m  
Could not publish state of sensor 'status_water_pump_2' with value: 'On'
14:35:36    [I] [ecodan.component:045][1;31m[serial_rx_task][0;32m  
Could not publish state of sensor 'status_three_way_valve_2' with value: 'On'

Could not publish state of sensor 'status_prohibit_heating_z2' with value: 'Off'
14:36:13    [I] [ecodan.component:045][1;31m[serial_rx_task][0;32m  
Could not publish state of sensor 'status_prohibit_cool_z2' with value: 'Off'

14:36:18    [I] [ecodan.component:034][1;31m[serial_rx_task][0;32m  
Could not publish state of sensor 'z2_room_temp_target' with value: '20.000000'
14:36:18    [I] [ecodan.component:034][1;31m[serial_rx_task][0;32m  
Could not publish state of sensor 'z2_flow_temp_target' with value: '35.000000'
14:36:18    [I] [ecodan.component:034][1;31m[serial_rx_task][0;32m  
Could not publish state of sensor 'z2_room_temp' with value: '0.000000'

Zal vast niet zo erg zijn, maar ik dacht ik meld het even.


Volgende uitdaging heeft hiermee te maken:
https://esphome.io/components/mqtt.html


Ik wil dus alleen MQTT gebruiken, omdat ik Domoticz heb en geen HomeAssistant.
Als ik echter het stukje api weghaal in de .yaml , dan krijg ik bij het compilen een heleboel errors omdat hij in andere bestanden die api verwacht blijkbaar.
Is daar iets aan te doen ? Ik zal zelf ook een beetje zoeken, dit zijn mijn eerste ervaringen met esphome...

[xoror]

je heb geen zone2 enabled, dus dan krijg je wat warnings , dat is geen probleem verder.
Ik heb verder nooit mqtt gebruikt voor esphome, even googlen denk ik zal eens kijken als ik wat tijd heb, maar in andere files doe ik volgens mij niets HA specifiek.

maar nu zou je evt ook de andere repo kunnen gebruiken.

[Plenkske]

xoror schreef op donderdag 16 mei 2024 @ 16:19:
je heb geen zone2 enabled, dus dan krijg je wat warnings , dat is geen probleem verder.
Ik heb verder nooit mqtt gebruikt voor esphome, even googlen denk ik zal eens kijken als ik wat tijd heb, maar in andere files doe ik volgens mij niets HA specifiek.

maar nu zou je evt ook de andere repo kunnen gebruiken.

Oke.
Als je in de yaml het api stukje uitcomment en dan compiled, zie je wat ik bedoel.
In andere files staan blijkbaar bepaalde api verwijzingen. Ik heb nog niet getest om die weg te halen oid.

[xoror]

Plenkske schreef op donderdag 16 mei 2024 @ 16:25:
[...]

Oke.
Als je in de yaml het api stukje uitcomment en dan compiled, zie je wat ik bedoel.
In andere files staan blijkbaar bepaalde api verwijzingen. Ik heb nog niet getest om die weg te halen oid.

oh ik zie al. ik test nog even lokaal, maar je kan alvast het volgende proberen
[edit] getest, lijkt okay, dus refresh en dan zou je mqtt moeten kunnen bouwen.

[ Voor 137% gewijzigd door xoror op 16-05-2024 17:34 ]

[Plenkske]

xoror schreef op donderdag 16 mei 2024 @ 16:35:
[...]

oh ik zie al. ik test nog even lokaal, maar je kan alvast het volgende proberen
[edit] getest, lijkt okay, dus refresh en dan zou je mqtt moeten kunnen bouwen.

Het compilen heb ik alvast getest, en dat werkt nu inderdaad. Top !
Vandaag ben ik op kantoor, dus tests met de esp32 volgen later.

[xoror]

Ik heb een pull request gemerged die de namen (engels) wat consistenter maakt en binary sensors worden gebruikt ipv text sensors voor on/off. Het kan zijn dat HA even een paar sensors na moet kijken (heb hier nog geen goede oplossing voor)

De nederlandse vertalingen zijn niet aangepast.

[MichielDTC]

Ik heb ook de Atoms3 bij AUijtdehaag besteld. Hiermee wilde ik mijn Mitsubishi Electric MSZ-EF25VGKW ZEN in Home assistent krijgen. Met de hulp van Alphons is dit helaas nog niet gelukt.
De airco voed de Atoms3, ESP home maakt verbinding met de Atoms3, de Atoms3 maakt geen verbinding met de airco. Heeft iemand de magische tip?

[xoror]

van https://github.com/echave...105ESPHome/discussions/83 moet je de volgende dingen aanpassen

code:

    PINs for rx & tx
    board: esp32-s3-devkitc-1
    framework type to arduino

in je uart moet je ws ook

code:

data_bits: 8
stop_bits: 1
parity: even

doen voor communicatie. Maar heb geen airco dus zeker weten doe ik het niet.
verder denk ik dat je beter daar support kan vragen

[ Voor 25% gewijzigd door xoror op 26-05-2024 21:09 ]

[MichielDTC]

xoror schreef op zondag 26 mei 2024 @ 20:57:
van https://github.com/echave...105ESPHome/discussions/83 moet je de volgende dingen aanpassen

code:

    PINs for rx & tx
    board: esp32-s3-devkitc-1
    framework type to arduino

in je uart moet je ws ook

code:

data_bits: 8
stop_bits: 1
parity: even

doen voor communicatie. Maar heb geen airco dus zeker weten doe ik het niet.
verder denk ik dat je beter daar support kan vragen

en hiermee is het gelukt! Thanks!

Enige wat ik aangepast heb is:
esp32:
board: esp32-s3-devkitc-1
#board: esp32doit-devkit-v1
framework:
type: arduino
#type: esp-idf
version: latest

De andere zaken die je aangeeft, kunnen die nog problemen geven als ik daar niets mee doe?

[ Voor 19% gewijzigd door MichielDTC op 26-05-2024 21:22 ]

[xoror]

wat raar dat ze dat niet geadviseerd hebben, cn105 communicatie gaat via 2400, SERIAL_8E1

nee, ga er vanuit dat de lib dat standaard instelt, want zonder die params werkt het niet.

[ Voor 34% gewijzigd door xoror op 26-05-2024 21:25 ]

[xoror]

voor de mensen met zone2, bugje gefixed voor zetten van temp voor zone2

[Plenkske]

Ondertussen al een tijdje de boel werkend met mqtt in domoticz en de verschillende devices gecheckt etc.

Wat nog niet werkt zijn de "numbers":
- zone 1 room setpoint value
- zone 1 h/c setpoint value
- dhw setpoint value

Domoticz maakt hier standaard temperatuur sensoren van en dan kan je alleen lezen en niks instellen.
Volgens mij is de mooiste oplossing om hier "climate" van te maken.
Dit is mijn eerste project met esphome, dus ik weet nog niet wat de bedoeling is om dit te maken.
Wat is het makkelijkste ?

Of weet iemand een andere oplossing ?

[xoror]

kan je niet configureren zodat die schrijfbaar wordt ?
wat betreft climate control, het is lastig omdat netjes te krijgen voor alle scenarios (cooling/heating/externe thermostaat).

Als je de interne thermostaat alleen gebruikt dan lukt het ws wel. zie https://esphome.io/components/climate/bang_bang.html

Maar ik zou denk ik beter zoeken naar een manier om die controls schrijfbaar te krijgen in Domoticz .
in de yaml zie je de interne call naar het espcomponent, je kan vrij eenvoudig een control toevoegen voor jezelf.

[Plenkske]

@xoror de numbers zijn niet mooi schrijfbaar te krijgen.
Ik begrijp idd wel dat de climate optie wellicht te lastig is.

Ik denk dat het makkelijker is om van de numbers een select te maken. In domoticz komen die dan als switch met een keuze lijst.
Kan ik dat in de yaml doen, of moet ik nog wat anders programmeren ?

[xoror]

Plenkske schreef op woensdag 29 mei 2024 @ 18:18:
@xoror de numbers zijn niet mooi schrijfbaar te krijgen.
Ik begrijp idd wel dat de climate optie wellicht te lastig is.

Ik denk dat het makkelijker is om van de numbers een select te maken. In domoticz komen die dan als switch met een keuze lijst.
Kan ik dat in de yaml doen, of moet ik nog wat anders programmeren ?

kan in yaml.
maar misschien kijken naar welke slider hij omzet naar input. misschien ziet ie celcius als temp en doet ie wat anders. je zou geen UOM kunnen proberen. dus even experimenteren, heb alleen HA dus beetje gokken

[AUijtdehaag]

Thermostat (climate) staat ook nog hoog op mijn verlanglijstje.

Maar ook nog andere dingen ook dus..... staat op de todo.
Tenzij @xoror zich gaat vervelen

[Plenkske]

Ik heb het nu met selectors gemaakt. In Domoticz krijg ik dan switches. Dit werkt.

Voor wie het nodig heeft:
In de base.yaml de "number" bovenin weghalen.
En onder select voeg je de volgende toe.
Als je meer keuzes wil qua temperatuur, kan je die gewoon toevoegen.

code:

- platform: template
    name: ${heatpump_number_set_dhw_temperature}
    id: heatpump_number_set_dhw_temperature
    optimistic: true
    restore_value: true
    options:
      - "47.0"
      - "47.5"
      - "48.0"
      - "48.5"
      - "49.0"
      - "49.5"
      - "50.0"
      - "50.5"
      - "51.0"
      - "51.5"
      - "52.0"
      - "52.5"
      - "53.0"
      - "53.5"
      - "54.0"
      - "54.5"
      - "55.0"
      - "55.5"
      - "56.0"
      - "56.5"
      - "57.0"
      - "57.5"
      - "58.0"
      - "58.5"
      - "59.0"
      - "59.5"      
      - "60.0"
    set_action:
      - lambda: |-
          float targetdwh = std::stof(x);
          id(ecodan_instance).set_dhw_target_temperature(targetdwh);

In zone1.yaml hetzelfde verhaal maar dan voor beide numbers die daar staan.

code:

select:
  - platform: template
    name: ${heatpump_number_z1_set_room_temperature}
    id: heatpump_number_z1_set_room_temperature
    optimistic: true
    restore_value: true
    options:
      - "18.0"
      - "18.5"
      - "19.0"
      - "19.5"
      - "20.0"
      - "20.5"
      - "21.0"
      - "21.5"
      - "22.0"
      - "22.5"
      - "23.0"
      - "23.5"
      - "24.0"
      - "24.5"
      - "25.0"
    set_action:
      - lambda: |-
          float targetroom = std::stof(x);
          id(ecodan_instance).set_room_temperature(targetroom, esphome::ecodan::SetZone::ZONE_1);
          
  - platform: template
    name: ${heatpump_number_z1_set_flow_temperature}
    id: heatpump_number_z1_set_flow_temperature
    optimistic: true
    restore_value: true
    options:
      - "25.0"
      - "25.5"
      - "26.0"
      - "26.5"
      - "27.0"
      - "27.5"
      - "28.0"
      - "28.5"
      - "29.0"
      - "29.5"
      - "30.0"
      - "30.5"
      - "31.0"
      - "31.5"
      - "32.0"
      - "32.5"
      - "33.0"
      - "33.5"
      - "34.0"
      - "34.5"
      - "35.0"
      - "35.5"
      - "36.0"
      - "36.5"
      - "37.0"
      - "37.5"
      - "38.0"
      - "38.5"
      - "39.0"
      - "39.5"
      - "40.0"      
    set_action:
      then:
        - lambda: |-
            float targetflow = std::stof(x);
            id(ecodan_instance).set_flow_target_temperature(targetflow, esphome::ecodan::SetZone::ZONE_1);

[xoror]

Het lijkt me dat het wel makkelijker moet kunnen, maar kan ook niet zoveel vinden over koppeling van esphome.

[xoror]

code:

climate:
  - platform: thermostat
    name: "${name} Climate"
    id: z1_room_climate
    visual:
      min_temperature: 10.0
      max_temperature: 45.0
      temperature_step: 0.5
    sensor: z1_flow_temp_target
    min_heating_off_time: 60s
    min_heating_run_time: 60s
    min_cooling_off_time: 60s
    min_cooling_run_time: 60s
    min_idle_time: 30s
    heat_action:
      - logger.log: "heat"
    cool_action:
      - logger.log: "cool"
    idle_action:
      - logger.log: "idle"
    on_state:
      - lambda: |-
          id(ecodan_instance).set_room_temperature(x.target_temperature, esphome::ecodan::SetZone::ZONE_1);

zoiets werkt hier wel, maar is dit dan echt beter?
ik heb voor room temp een climate toegevoegd. Het zelfde eigenlijk voor DHW.
het is gewoon een grotere slider met de huidige temp. Voor flow zou ik niet weten wat ik als huidige temp moet afbeelden namelijk, dus weet niet hoe nuttig daar een climate control voor is.

even een tijdje testen en als het goed werkt, kunnen we de slider disablen

[ Voor 19% gewijzigd door xoror op 30-05-2024 00:42 ]

[Plenkske]

Dankje @xoror !
Ik zal het eens testen icm domoticz. Als het daarin werkt is het sowieso een verbetering, omdat je met de "numbers" niks kan in domoticz. In HA weet ik niet wat beter is.

Betreft flow: gewoon de huidige instelling laten zien ?

[xoror]

flow ook maar toegevoegd, even week of 2 naast elkaar draaien en als alles goed werkt kunnen die sliders evt eruit. de thermostaat kan je alleen de temp aanpassen. Het is als het ware een grote slider.

off/heat/cool instelling doet hij niets mee, die zijn alleen verplicht en kan ik niet disablen. (zou ook niet weten wat je hier onder zou hangen, dit is meer voor als je airco of andere verwarming aan en uit kan zetten op basis van je thermostaat component. Maar ik zou deze automatisering niet via Ha laten lopen tbh)

[ Voor 27% gewijzigd door xoror op 30-05-2024 09:26 ]

[Plenkske]

@xoror dit ziet er goed uit en werkt zo te zien !
Zo ziet het eruit in standaard domoticz: