Mitsubishi Ecodan warmtepomp uitlezen via cn105 + esp32

[xoror]

in server control kan je prima alles instellen...
Dat werkt gewoon.

wat ik me kan voorstellen is dat de mrc (display) wanneer hij actief is, misschien controleert of er 'onheldige' waarden zijn en evt worden die 'hersteld'.

uit de logs van @LigeTRy zie ik geen commandos vanuit de esp die de waarde terug zet. Dus het moet van een andere bron komen (MRC/PARxx)

als dat het geval is kan ik er weinig aan doen vrees ik

@tekenbord
Ik heb net via esp de dhw temp op 19.5 gezet en ben rond gaan kijken op de mrc, zelfs in het sww temp menu waar hij 40 laat zien. Maar mijn waarde blijft nog op 19.5 (nu al 5-10 mins)

[ Voor 19% gewijzigd door xoror op 24-05-2025 09:51 ]

[tekenbord]

als ik in home-assistant 'heatpump on' uitschakel, gaat mrc display uit, voorheen was dit niet.
Als ik display aanzet, of door menu scroll / temp veranderd gaat DHW setpoint naar 40gr inderdaad.
(nu met server control 'aan' getest)

voor mij geen issues verder, maar wel interessant gegeven

[xoror]

'heatpum on/off' switch zet de unit op standby, in standby gaat display uit. Heeft altijd al zo gewerkt?
Als je de warmtepomp aan/uit zet worden 'foutieve' waarden reset gok ik, dat is logisch (unit herstart), dan snap ik wel waarom die 40c weer terug komt.

Waarom zou je je warmte pomp in standby zetten? nergens voor nodig en geeft alleen maar onverwachte issues

[ Voor 4% gewijzigd door xoror op 24-05-2025 10:01 ]

[tekenbord]

Mijn verkeerde aanname van de functie.
Gelijk eea aangepast. dank.

[LigeTRy]

xoror schreef op zaterdag 24 mei 2025 @ 09:26:

wat ik me kan voorstellen is dat de mrc (display) wanneer hij actief is, misschien controleert of er 'onheldige' waarden zijn en evt worden die 'hersteld'.

Ik denk dat je hierin gelijk hebt, ik heb zojuist de waarde een keer naar 25c gezet en het schermpje op de ecodan (ik denk dat je dit bedoelt met mrc) geactiveerd. daarna stond ie weer op 40. Logs upload ik naar het github issue.

Aanname: wanneer er een waarde op de MRC wijzigt (bijvoorbeeld de temp van het water in hele graden of wijzigen van standby/verwarmen etc), wordt deze check gedaan. Dat zou ook meteen verklaren waarom de tijdstippen zo random zijn

[xoror]

@LigeTRy Het is alleen dat ik gisteren dit ook halve dag open had en daar daalde de huidige sww temp natuurlijk ook, maar dat triggert niets bij mij. Ook in de menu's navigeren triggert niets

edit: in je laatste logs zie ik wederom geen commandos vanaf het moment dat het nog goed was. Dus het wordt extern veroorzaakt. Aangezien jij alleen de MRC heb, zou het daar aan moeten liggen.

Aanname: wanneer er een waarde op de MRC wijzigt (bijvoorbeeld de temp van het water in hele graden of wijzigen van standby/verwarmen etc), wordt deze check gedaan. Dat zou ook meteen verklaren waarom de tijdstippen zo random zijn

Misschien schrijft de MRC dus de "gehele" stand bij elke setting. Omdat hij niet lager dan 40c dhw kan, zou dat het kunnen verklaren.

edit:
Check ik heb het kunnen reproduceren door idd een wijziging te doen op mrc

Heb de change terug gedraaid voor de volgende build. Geeft teveel inconsistenties anders. SWW moet je helaas weer op de 'oude' manier disablen (server control + prohibit)

[ Voor 124% gewijzigd door xoror op 24-05-2025 21:55 ]

[LigeTRy]

Vandaag een extra douchebeurtje die ervoor zorgde dat m'n vat zich is gaan vullen (zie temp drop), maar geen heating cycle, weet iemand waardoor dit zou komen? Setpoint op 40c en water nu op 28c, wat lijkt op een disable heat (max temp drop is 5c).

Opzich prima want de stroom is zeer duur nu, maar probeer het te begrijpen (server control en prohibit heating staan uit), of zou er onderwater nog een schedule zitten ergens, de weekklok op de MRC staat op de hele week, altijd voor SWW

[ Voor 14% gewijzigd door LigeTRy op 28-05-2025 21:45 ]

[xoror]

schedule, kan bijna niet anders. Je heb 2 schemas, dus moet je even beide kijken. Plot anders operating mode erbij. Plot ook de prohibit dhw flag erbij voor de zekerheid

Kan ook zijn dat je naar de verkeerde dhw sensor kijkt. Je kan instellen op welke sensor hij triggered

[ Voor 23% gewijzigd door xoror op 28-05-2025 23:02 ]

[LigeTRy]

xoror schreef op woensdag 28 mei 2025 @ 22:58:
schedule, kan bijna niet anders. Je heb 2 schemas, dus moet je even beide kijken. Plot anders operating mode erbij. Plot ook de prohibit dhw flag erbij voor de zekerheid

Kan ook zijn dat je naar de verkeerde dhw sensor kijkt. Je kan instellen op welke sensor hij triggered

yuup, andere sensor it is denk ik, ben benieuwd waar zo'n groot verschil uit komt, je zou toch verwachten dat in hetzelfde vat 2 sensoren redelijk dicht bij elkaar zouden zitten. Even wat onderzoek doen, want procon leest en stuurt op 1, maar de ecodan zelf op 2 dan neem ik aan

[xoror]

dat is het hele principe van gelaagdheid (warm water stijgt/blijft boven) en waarom je het vat altijd staand wil hebben en meestal de bovenste sensor wil gebruiken....

De wp bepaalt welke sensor sturend is (in setting van de hoog/laag). De procon/esp/.. doen daar verder niet veel mee. Ik kan over cn105 niet uitlezen welke gekozen is vandaar.

De esp toont altijd de 1e sensor in de climate, kan je aanpassen door opnieuw te compilen, maar is zelden goed/aan te raden omdat het dan veels te snel getriggerd wordt

[ Voor 59% gewijzigd door xoror op 29-05-2025 12:53 ]

[LigeTRy]

Duidelijk, dan blijft het dus lastig om te bepalen "hoe lang je nog kan douchen" op basis van deze data. Sensor 1 geeft wel aan hoe warm het water is wat je kan tappen, maar de hamvraag is dan, voor hoelang. Idealiter zou je daarop willen sturen, maar we zijn gelimiteerd aan wat de ecodan voor data stuurt.

[xoror]

Kan je toch eenvoudig bepalen? ga douchen en kijk hoeveel graden je boven sensor daalt? Dan weet je hoe lang je kan douchen tot je op max drop temp komt?

[Slayer89]

Sinds enige tijd hebben wij een Ecodan warmtepomp en probeer een ESP32 werkend te krijgen, maar ergens lijkt het te stagneren in de communicatie tussen de ESP en de CN105 connector.

Ik heb de volgende repo gebruikt om de config in ESPhome te krijgen: https://github.com/gekkekoe/esphome-ecodan-hp/tree/main

Als ik de UART logging inschakel, dan zie ik wel iets van antwoord terugkomen dus het lijkt er op dat ik de juiste GPIO pinnen heb gevonden (ESP32-WROOM bordje, waarop de TX en RX pinnen GPIO1 en 3 zijn). Enige aanknopingspunten van waaruit ik het beste kan gaan troubleshooten?

code:

[14:03:24][I][ecodan.component:048]: Serial port message appears invalid, skipping payload...
[14:03:24][E][ecodan.component:034]: Dropping serial data '00', header magic mismatch
[14:03:24][D][uart_debug:114]: <<< F0 00 00 00 00 00 00 FC E0 00 00
[14:03:28][I][ecodan.component:350]: Attempt to tx CONNECT_CMD!
[14:03:29][D][uart_debug:114]: >>> FC 5A 02 7A 02 CA 01 5D
[14:03:29][I][ecodan.component:048]: Serial port message appears invalid, skipping payload...
[14:03:29][E][ecodan.component:034]: Dropping serial data '00', header magic mismatch
[14:03:29][D][uart_debug:114]: <<< F0 00 00 00 00 00 00 FC E0 00 00
[14:03:33][I][ecodan.component:350]: Attempt to tx CONNECT_CMD!
[14:03:34][D][uart_debug:114]: >>> FC 5A 02 7A 02 CA 01 5D
[14:03:34][I][ecodan.component:048]: Serial port message appears invalid, skipping payload...
[14:03:34][E][ecodan.component:034]: Dropping serial data '00', header magic mismatch
[14:03:34][D][uart_debug:114]: <<< F0 00 00 00 00 00 00 FC E0 00 00
[14:03:38][I][ecodan.component:350]: Attempt to tx CONNECT_CMD!
[14:03:39][D][uart_debug:114]: >>> FC 5A 02 7A 02 CA 01 5D
[14:03:39][I][ecodan.component:048]: Serial port message appears invalid, skipping payload...
[14:03:39][E][ecodan.component:034]: Dropping serial data '00', header magic mismatch
[14:03:39][D][uart_debug:114]: <<< F0 00 00 00 00 00 00 FC E0 00 00

[xoror]

gok dat je verkeerde board heb gekozen. Zou esp32.yaml als uitgangspunt nemen. post anders je main yaml

Volg deze guide
https://github.com/gekkek...docs/build-from-source.md

[ Voor 33% gewijzigd door xoror op 30-05-2025 17:14 ]

[Slayer89]

Ik ben inderdaad uitgegaan van de esp32.yaml. Voor het gemak heb ik de code even handmatig toegevoegd, zodat ik sneller via ESPHome kon compilen:
https://pastebin.com/p60wLTs0

Ik merk dat de warmtepomp wél ergens op reageert. Ik klikte per ongeluk het vinkje bij server-control aan, en toen sprong de warmtepomp meteen in een andere modus (vraag me niet welke precies, ik zou het boekje erbij moeten pakken om het symbool te ontcijferen 😅). Er lijkt dus in elk geval wel TX-communicatie te zijn.

Edit:
Ik heb ondertussen een atom s3 lite besteld in de hoop dat de gare chinese cloon de boosdoener is.

[ Voor 9% gewijzigd door Slayer89 op 31-05-2025 18:50 ]

[xoror]

@Slayer89 sommige boardjes willen ook alleen op bepaalde gpio poorten de tx/Rx doen. Bijv 17/18 worden dan vaak gebruikt. Moet je nakijken of de io poorten die je gebruikt wel kunnen.

Een s3 lite is eenvoudigst, krijg je firmware binaries met OTA

[Grolsch]

Een vriend van me heeft een huis gebouwd en hij gebruikt als domotica systeem Loxone.

Hij heeft ook een Mitsu warmtepomp en heeft daar een Procon bijgekocht.

Is er ergens een actueel overzicht van alle registers welke hij kan gebruiken

Of kan ik ergens zien uit welk register welke sensoren komen van deze CN105

[AUijtdehaag]

@Grolsch https://library.mitsubish...uk/pdf/download_full/3909

[Slayer89]

xoror schreef op zondag 1 juni 2025 @ 01:27:
@Slayer89 sommige boqrdjes willen ook alleen op bepaalde gpio poorten de tx/Rx doen. Bijv 17/18 worden dan vaak gebruikt. Moet je nakijken of de ionpoorten die je gebruikt wel kunnen.

Een s3 lite is eenvoudigst, krijg je firmware binaries met OTA

Tnx, dat was inderdaad de oplossing. Waarschijnlijk conflicteerde het met serial logging. GPIO17/18 om UART2 te gebruiken was de oplossing. Ach, ik zet de atom s3 mini wel in voor een ander project dan

[xoror]

nieuwe release

• upgraded to esphome 2025.5.2
• Revert "Allow 0c as min DHW target temp. This enables us to 'disable' DHW by setting it to a low value. The display will still show 40c, but internally the heatpump uses the actual value"
• Added German translations

[Lorduh]

Hallo!

Ik heb onlangs de combinatie ERSF-VM6E + PUZ-SHWM80VAA laten installeren, boilervat van 300L + 80L buffer voor vloerverwarming. Daarnaast heb ik zonnepanelen, thuisbatterij (5.7kWh), ... Het lijkt me wel zinnig om dit evt. wat slimmer te gaan sturen. Het is ook gewoon leuk, meten is weten!

Ik plan tevens om binnenkort een domitcasysteem te plaatsen, meer bepaald Loxone. Er is wel wat informatie te vinden over hoe Loxone deze warmtepomp slim kan gaan sturen. Al is het me eerlijk gezegd nog niet geheel duidelijk. Dit lijkt me een goed startpunt, al ken ik momenteel nog niets van Modbus, dus daarin zal ik me verder moeten verdiepen: Mitsubishi Ecodan (lucht-water) aansturen met Loxone

Mijn eerste zoektocht bracht me ook bij de Procon, maar inderdaad best prijzig. Logisch zou zijn om de Loxone Modbus extension te kopen, maar dat ding zit gewoon meteen rond de 420 euro. Dan zit je in totaal al makkelijk aan 600 euro. De Loxone Modbus module zou ik echter kunnen schrappen en het wat slimmer spelen door gebruik te maken van Procon + convertortje rs485 ModbusTCP. Dat is een combo die langs Loxone's kant ondersteund wordt zonder extra hardware.

Maar, nu kom ik dus uit op de piste ESP ... Ik gok dat dit moet werken i.c.m. met mijn warmtepomp. Ik spot in dit topic twee "succesverhalen" met de ESRF-VM2E. De "6" in mijn model heeft naar ik begrijp een zwaardere weerstand om bij te verwarmen.

Vermoedelijk is de eenvoudigste manier in mijn geval de ESP-piste, maar dan niet gekoppeld aan Home Assistant (al zou HA in theorie ook met Loxone moeten kunnen verbonden worden). MQTT lijkt me dan de oplossing.

Daar loop ik echter wat op vast. Ik heb eigenlijk nog met ESP / ESPHome ervaring, ook niet met Modbus etc. En momenteel dus ook nog niet met Loxone .... Vandaar, alle tips zijn meer dan welkom! Ik wil vooral weten of dit een haalbare kaart zou zijn. Ik kan programmeren en heb een IT-achtergrond, dus dat zit wel goed.

borgoe72 schreef op dinsdag 15 oktober 2024 @ 13:06:
Even een vraag van een eenvoudige gebruiker...

Ik stuur m'n Mitsubishi Electric PUZ-SWM120YAA/ Mitsubishi Electric ERSF-VM2E aan met de module zoals hier besproken en dat bevalt stukken beter dan Melcloud welk ik in mijn vorige woning had.

...

nicowinde schreef op woensdag 30 oktober 2024 @ 13:28:
Vandaag kabeltje + printje van AUijtdehaag ontvangen. ATOM ESP32-S3FN8 opnieuw geladen
(gewijzigde GPIO pinnen),, alles werkt prima. MelCloud als slave.
PUZA-SHWM100YAA + ERSF-VM2E. FCT7, firmware versie 08.01

xoror en AUijtdehaag hartelijk dank voor het geleverde werk!

Grolsch schreef op zondag 1 juni 2025 @ 08:38:
Een vriend van me heeft een huis gebouwd en hij gebruikt als domotica systeem Loxone.

Hij heeft ook een Mitsu warmtepomp en heeft daar een Procon bijgekocht.

Is er ergens een actueel overzicht van alle registers welke hij kan gebruiken

Of kan ik ergens zien uit welk register welke sensoren komen van deze CN105

[Grolsch]

Waarom loxone als domotica? Op tweakers is het toch vooral HA wat gebruikt wordt.

Ik heb evt. Nog een procon liggen mocht je interesse hebben.

[ Voor 28% gewijzigd door Grolsch op 24-06-2025 20:07 ]

[Lorduh]

Grolsch schreef op dinsdag 24 juni 2025 @ 20:05:
Waarom loxone als domotica? Op tweakers is het toch vooral HA wat gebruikt wordt.

Ik heb evt. Nog een procon liggen mocht je interesse hebben.

Tgoh, in theorie kan alles met HA. Dat heb ik nu al deels, Shelly, Philips Hue, wat API's, ... Dat werkt allemaal wel, maar ... Soms is het knutselgehalte me iets te veel gedoe, een Shelly die dan plots zijn connectie verliest, opnieuw pairen etc. Ik zit nu in een situatie waarin ik de mogelijkheid heb om alles met een bedraad systeem kan aansluiten (bv. Loxone). Dat lijkt me toch allemaal net iets robuuster, minder onderhoudsgevoelig etc.

Begrijp me niet verkeerd, ik vind HA fantastisch. Ik zal het zeker nog blijven gebruiken voor bepaalde toepassingen. Kans is groot dat ik het koppel met Loxone. Maar toch, graag wil ik me concentreren op 1 centraal systeem dat gewoon garandeert dat het werkt.

De Procon hou ik nog even in beraad! De ESP-piste is en blijft een stuk goedkoper en een beetje tweaken zie ik zeker zitten!

[Miezie]

Lorduh schreef op dinsdag 24 juni 2025 @ 20:37:
[...]


Tgoh, in theorie kan alles met HA. Dat heb ik nu al deels, Shelly, Philips Hue, wat API's, ... Dat werkt allemaal wel, maar ... Soms is het knutselgehalte me iets te veel gedoe, een Shelly die dan plots zijn connectie verliest, opnieuw pairen etc. Ik zit nu in een situatie waarin ik de mogelijkheid heb om alles met een bedraad systeem kan aansluiten (bv. Loxone). Dat lijkt me toch allemaal net iets robuuster, minder onderhoudsgevoelig etc.

Begrijp me niet verkeerd, ik vind HA fantastisch. Ik zal het zeker nog blijven gebruiken voor bepaalde toepassingen. Kans is groot dat ik het koppel met Loxone. Maar toch, graag wil ik me concentreren op 1 centraal systeem dat gewoon garandeert dat het werkt.

De Procon hou ik nog even in beraad! De ESP-piste is en blijft een stuk goedkoper en een beetje tweaken zie ik zeker zitten!

Hmmm, ik ben benieuwd naar je ervaring… ik had in het verleden Free@Home van Busch Jaeger… viel mij toch tegen, vrij snel
heb ik daar toch home assistant als centraal ding gepositioneerd. Nu heb ik eigenlijk zigbee als centraal systeem, met HA als systeem erachter. Het is maar net hoe je het bekijkt allemaal .

[xoror]

Mqtt kan, maar je kan de esphome ook direct aanspreken met een api. zie https://esphome.io/web-api/

verder kan je het gewoon over http://ip benaderen en eigenlijk ook alles doen zonder HA.

Maar met HA is het eigenlijk het eenvoudigst (en biedt gelijk zoveel mogelijkheden). De esp geeft je verder server control, dat is eigenlijk noodzakelijk als je harde controle wil over wat wanneer mag draaien. Via modbus kan dit niet.

[Lorduh]

Het is wellicht wat off-topic, maar ik ga graag in op je vraag.

Ik heb Philips Hue-lampen, en dat werkt op zich prima. Mijn vriendin en ikzelf geven er echter de voorkeur aan om op een knopje te duwen in plaats van continu met een app te werken. Daarom heb ik bestaande, bedrade schakelaars hier en daar vervangen door Niko's Philips Hue-schakelaars. Dit type schakelaar werkt volledig op kinetische energie. Dit werkt meestal goed, maar niet altijd. Je moet redelijk hard duwen, soms meermaals, enzovoort. Goed, daar valt mee te leven.

Ik weet dat er alternatieven bestaan, maar dan begin je weer met een ander ecosysteem in huis te halen. Dat brengt me bij een volgende ervaring. Ik had hier en daar Sonoff-modules gebruikt om 'domme' verlichting slim te maken. Het probleem was dat wanneer er op een Niko Philips Hue-schakelaar werd gedrukt, de gehele Hue-hub crashte. Dit was oplosbaar door een ZBMINI-L te gebruiken, maar dat gaf dan weer een lekstroom. De lekstroom is vervolgens opgelost met een stabilisator. Het werkt...

Ik wilde ook een aantal slimme stopcontacten. Die heb ik gevonden, maar ze waren niet compatibel met de Hue Bridge. Goed, een extra Zigbee-netwerk aan Home Assistant (Raspberry Pi) gekoppeld. Opgelost.

Af en toe verliezen sommige apparaten hun verbinding. Vooral de Sonoffs durven weleens moeilijk te doen; dan moet ik de module handmatig resetten en opnieuw configureren in Home Assistant. Ideaal? Niet echt.

Rolluiken aansturen: ik heb niet meteen iets 'ideaals' en betaalbaars gevonden. Ik heb Shelly's gebruikt. Dat werkt op zich, maar ook hier flikkert er af en toe eentje uit. Bovendien is het geen pretje om die dingen achter een bestaande schakelaar te krijgen. Kortom, weer extra problemen.

De API van de zonnepanelen geeft nu en dan ook problemen. Allemaal oplosbaar.

Ik heb het gevoel dat het er allemaal ietwat te veel 'bijkomt'. Verbouwingen, kinderen... het is veel.

Vandaar dat ik bij de verbouwingen nu gekozen heb om overal EIB-kabel te voorzien. Mijn situatie liet ook toe om de huidige lichtpunten relatief eenvoudig apart naar de schakelkast te brengen. Ik zit al een hele tijd te kijken naar welk domoticasysteem nu echt een "alles-in-één"-oplossing biedt. Dat heeft me uiteindelijk bij Loxone gebracht. De manier van bedrading en aansluiten maakt het voor mij als 'zelfverbouwer' relatief eenvoudig om dit allemaal zelf te realiseren.

Ik hoor en zie daar veel mooie dingen mee gebeuren zonder al te veel gedoe. Al zal ik bijvoorbeeld voor mijn camera's wel bij Home Assistant + Frigate NVR blijven. Misschien zie ik het inderdaad wat te rooskleurig, de toekomst zal het uitwijzen!

xoror schreef op woensdag 25 juni 2025 @ 01:04:
MQTT kan, maar je kunt de ESPHome ook direct aanspreken met een API. Zie https://esphome.io/web-api/

Verder kun je het gewoon via http://ip benaderen en eigenlijk ook alles doen zonder Home Assistant.

Maar met Home Assistant is het eigenlijk het eenvoudigst (en biedt gelijk zoveel mogelijkheden). De ESP geeft je verder 'server control', dat is eigenlijk noodzakelijk als je harde controle wilt over wat wanneer mag draaien. Via Modbus kan dit niet.

Ga ik zeker eens bekijken! Snel even gezocht, Loxone kan overweg met HTTP-API's, dus dat is zeker een piste, wellicht eenvoudiger dan MQTT.

[ Voor 16% gewijzigd door Lorduh op 25-06-2025 11:16 ]

[Miezie]

Lorduh schreef op woensdag 25 juni 2025 @ 11:15:
Het is wellicht wat off-topic, maar ik ga graag in op je vraag.

Ik heb Philips Hue-lampen, en dat werkt op zich prima. Mijn vriendin en ikzelf geven er echter de voorkeur aan om op een knopje te duwen in plaats van continu met een app te werken. Daarom heb ik bestaande, bedrade schakelaars hier en daar vervangen door Niko's Philips Hue-schakelaars. Dit type schakelaar werkt volledig op kinetische energie. Dit werkt meestal goed, maar niet altijd. Je moet redelijk hard duwen, soms meermaals, enzovoort. Goed, daar valt mee te leven.

Ik weet dat er alternatieven bestaan, maar dan begin je weer met een ander ecosysteem in huis te halen. Dat brengt me bij een volgende ervaring. Ik had hier en daar Sonoff-modules gebruikt om 'domme' verlichting slim te maken. Het probleem was dat wanneer er op een Niko Philips Hue-schakelaar werd gedrukt, de gehele Hue-hub crashte. Dit was oplosbaar door een ZBMINI-L te gebruiken, maar dat gaf dan weer een lekstroom. De lekstroom is vervolgens opgelost met een stabilisator. Het werkt...

Ik wilde ook een aantal slimme stopcontacten. Die heb ik gevonden, maar ze waren niet compatibel met de Hue Bridge. Goed, een extra Zigbee-netwerk aan Home Assistant (Raspberry Pi) gekoppeld. Opgelost.

Af en toe verliezen sommige apparaten hun verbinding. Vooral de Sonoffs durven weleens moeilijk te doen; dan moet ik de module handmatig resetten en opnieuw configureren in Home Assistant. Ideaal? Niet echt.

Rolluiken aansturen: ik heb niet meteen iets 'ideaals' en betaalbaars gevonden. Ik heb Shelly's gebruikt. Dat werkt op zich, maar ook hier flikkert er af en toe eentje uit. Bovendien is het geen pretje om die dingen achter een bestaande schakelaar te krijgen. Kortom, weer extra problemen.

De API van de zonnepanelen geeft nu en dan ook problemen. Allemaal oplosbaar.

Ik heb het gevoel dat het er allemaal ietwat te veel 'bijkomt'. Verbouwingen, kinderen... het is veel.

Vandaar dat ik bij de verbouwingen nu gekozen heb om overal EIB-kabel te voorzien. Mijn situatie liet ook toe om de huidige lichtpunten relatief eenvoudig apart naar de schakelkast te brengen. Ik zit al een hele tijd te kijken naar welk domoticasysteem nu echt een "alles-in-één"-oplossing biedt. Dat heeft me uiteindelijk bij Loxone gebracht. De manier van bedrading en aansluiten maakt het voor mij als 'zelfverbouwer' relatief eenvoudig om dit allemaal zelf te realiseren.

Ik hoor en zie daar veel mooie dingen mee gebeuren zonder al te veel gedoe. Al zal ik bijvoorbeeld voor mijn camera's wel bij Home Assistant + Frigate NVR blijven. Misschien zie ik het inderdaad wat te rooskleurig, de toekomst zal het uitwijzen!


[...]


Ga ik zeker eens bekijken! Snel even gezocht, Loxone kan overweg met HTTP-API's, dus dat is zeker een piste, wellicht eenvoudiger dan MQTT.

Als je zo goed als alles in de meterkast hebt, zou je dan niet voor KNX moeten gaan?

Ik snap je verhaal… dat had ik in m’n vorige huis ook. Hier een stuk minder uitdagingen, juist door die geleerde lessen. Ik zou persoonlijk alleen geen bepaald merk in huis fietsen, maar juist die standaard. Uiteindelijk ontlopen we elkaar dus niet zoveel :-). Zonwering is hier trouwens Somfy. Zeer degelijk.

Nu weer on topic!

[Breud]

Hallo, daar ben ik weer eens

Vandaag is onze 14kw buiten unit dan eens vervangen door een lichtere 8kw ecodan warmtepomp. Binnenunit is niet veranderd.

De esp werkt goed in combinatie met de nieuwe buiten unit, alleen de parameter ‘Operating Runtime’ heeft zich niet ge-update. Hier zienik nog steeds de runtime van de oude buiten unit. Had deze niet naar 0 moeten gaan? Code 002 en 003 op de binnenunit staan ook op 0

[xoror]

Dat is apart, ik lees die uit de buiten unit (start/stops). Is die wel reset?

Ik heb geen idee waarom de tellers niet resetten. De runtime komt uit de binnenunit, dus apart dat die code anders geeft. Wellicht haalt de unit het via de code op uit de buiten unit

[K44S]

Ik heb vandaag mijn ecodan opengeschroefd, om een atom aan te sluiten op de cn105 poort. Maar bij het openmaken blijkt er al een procon a1m mini op deze poort aangesloten. Op de rs485 poort van deze procon zit niets aangesloten.

Kan ik deze procon afkoppelen, en verwisselen voor de atom+esp zonder tegen problemen aan te lopen? Of zorgt deze procon op dit moment voor de aansturing van de warmtepomp?

[vormulier]

K44S schreef op vrijdag 4 juli 2025 @ 10:47:
Ik heb vandaag mijn ecodan opengeschroefd, om een atom aan te sluiten op de cn105 poort. Maar bij het openmaken blijkt er al een procon a1m mini op deze poort aangesloten. Op de rs485 poort van deze procon zit niets aangesloten.

Kan ik deze procon afkoppelen, en verwisselen voor de atom+esp zonder tegen problemen aan te lopen? Of zorgt deze procon op dit moment voor de aansturing van de warmtepomp?

Je kan de procon gewoon vervangen voor de ESP. De procon zal niks doen zonder verdere aansturing.

[xoror]

Op marktplaats zetten krijg je nog wat voor de procon

[Lorduh]

Ik heb via @AUijtdehaag de proxy-versie aangekocht. Werkt op 't eerste zicht prima i.c.m. het type warmtepomp dat ik heb. Waarvoor dank!

Al spot ik wel meteen al een "foutje". Bij de slider van sanitair warm-water kan ik maximaal 60 graden instellen, op de pomp zelf kan ik tot 65 graden gaan. Iemand enig idee hoe ik dit kan corrigeren?

Al denk ik dat het sowieso wel verstandiger is om tot max. 60 graden te verwarmen omwille van de levensduur. Ik stel doorgaans max. 44 graden in. Maar, nu heb ik bv. veel energie-overschot van de zonnepanelen (en batterij is volledig geladen).

[xoror]

Lorduh schreef op vrijdag 4 juli 2025 @ 17:31:
Ik heb via @AUijtdehaag de proxy-versie aangekocht. Werkt op 't eerste zicht prima i.c.m. het type warmtepomp dat ik heb. Waarvoor dank!

Al spot ik wel meteen al een "foutje". Bij de slider van sanitair warm-water kan ik maximaal 60 graden instellen, op de pomp zelf kan ik tot 65 graden gaan. Iemand enig idee hoe ik dit kan corrigeren?

Al denk ik dat het sowieso wel verstandiger is om tot max. 60 graden te verwarmen omwille van de levensduur. Ik stel doorgaans max. 44 graden in. Maar, nu heb ik bv. veel energie-overschot van de zonnepanelen (en batterij is volledig geladen).

Ik volg zoveel mogelijk de limits opgelegd door FTC. Bij mijn dhw kan ik dus max 60 instellen. Weet je zeker dat dat bij jou ook niet zo is? Ben je wellicht bij legionella settings aan het kijken?

Misschien is het bij R290 anders, heb je propaan?

[Lorduh]

xoror schreef op vrijdag 4 juli 2025 @ 17:46:
[...]


Ik volg zoveel mogelijk de limits opgelegd door FTC. Bij mijn dhw kan ik dus max 60 instellen. Weet je zeker dat dat bij jou ook niet zo is? Ben je wellicht bij legionella settings aan het kijken?

Misschien is het bij R290 anders, heb je propaan?

Via de display kan ik wel degelijk tot 65 instellen voor DHW. Legionella staat op 60 graden ingesteld. Geen propaan hier, R32.

Nu goed, een ramp is het zeker niet hoor. 60 graden is al behoorlijk hoog lijkt me. De installateur had 58 graden ingesteld bij ingebruikname. Vind ik nogal hoog voor dagdagelijks gebruik.

[xoror]

@Lorduh FTC6 of FTC7 ?
Ik draai zelf maar sww temp van 47 graden...

zo ziet het er bij mij uit: YouTube: Setting hot water temperature Mitsubishi air source controller

[ Voor 54% gewijzigd door xoror op 04-07-2025 18:10 ]

[Lorduh]

@xoror
Ik maak geen gebruik van de FTC. Rechtstreeks op display van de binnenunit. Staat bij mij doorgaans op 44. Ik zet het (voorlopig) manueel naar 58 wanneer ik overproductie heb van de zonnepanelen.



Plan is om dit te automatiseren, hetzij met Home Assistant, hetzij met Loxone. De FTC heb ik niet echt nodig, daar ik ga steunen op de mogelijkheden van een domoticasysteem. Om de vloerverwarming te sturen ga ik gebruik maken van actuators, i.c.m. een schakelaar die een temperatuur- en luchtvochtigheidsensor aan boord heeft. Wel een duur grapje ...

[xoror]

dat is ftc7 Het is alleen jammer dat ik niet dynamisch die grenzen kan zetten (wel in esphome, maar HA pakt het niet eenvoudig op. zie https://github.com/gekkekoe/esphome-ecodan-hp/issues/42)

Anderzijds zullen weinig mensen sww van meer dan 60c maken. Is serieus heet.

Ik heb ook luchtvochtigheid meters, maar dan in mijn thermostaten, en daarmee kan ik actuele dauw temp bepalen.

Dan koel ik altijd max op hoogste dauwpunt + 0.5c. Als je gaat koelen is dat wel handig

[ Voor 11% gewijzigd door xoror op 05-07-2025 12:28 ]

[Lorduh]

Kijk, we leren bij, FTC7 it is. Voor mij op zich geen probleem dat ik via deze weg tot "maar" 60 graden kan. Deze nacht, om 3u00 is het SWW verwarmd tot 60 graden (Legionella stond nog zo ingesteld; tijdstip intussen aangepast). Temperatuur is nu nog steeds 58 graden.

Is je koeltemperatuur dan niet relatief laag? De installateur heeft mij aanbevolen om de koeling niet lager dan 18 graden in te stellen om condens op de vloerverwarmingkoeling te vermijden. Is wellicht eerder vuistregel, maar goed.

[xoror]

condens krijg je als je lager koelt dan dauwpunt. Ik koel vandaag 17c. Geen problemen. 18c is safe als je de lucht vochtigheid niet weet van je ruimtes. Althans het gaat hier goed, ik heb in begin leidingen gecontroleerd, maar geen condens



Ik kan nog harder koelen maar is niet nodig, huis is al aangenaam, 18c was ws ook prima.

@Breud zijn je tellers inmiddels bijgetrokken ? Anders moeten we een keer logs dumpen en kijken of we wat kunnen vinden.

[ Voor 8% gewijzigd door xoror op 05-07-2025 12:36 ]

[Miezie]

xoror schreef op zaterdag 5 juli 2025 @ 12:27:
condens krijg je als je lager koelt dan dauwpunt. Ik koel vandaag 17c. Geen problemen. 18c is safe als je de lucht vochtigheid niet weet van je ruimtes. Althans het gaat hier goed, ik heb in begin leidingen gecontroleerd, maar geen condens

[Afbeelding]

Ik kan nog harder koelen maar is niet nodig, huis is al aangenaam, 18c was ws ook prima.

@Breud zijn je tellers inmiddels bijgetrokken ? Anders moeten we een keer logs dumpen en kijken of we wat kunnen vinden.

Kan je die automations voor koelen delen? Scheelt weer tijd hier 😝.

Die 18 graden is simpelweg de safe call om je te vrijwaren van alles als bouwer/installateur.

Klinkt wel allemaal onnodig complex en prijzig @Lorduh , maar prima hoor 👍.

[xoror]

@Miezie https://github.com/gekkek.../template-sensor.yaml#L12

vervolgens max nemen van alle waarden en +0.5 of 1 graad bij doen en setten als flow temp indien huidige temp hoger is

[Miezie]

xoror schreef op zaterdag 5 juli 2025 @ 17:53:
@Miezie https://github.com/gekkek.../template-sensor.yaml#L12

vervolgens max nemen van alle waarden en +0.5 of 1 graad bij doen en setten als flow temp indien huidige temp hoger is

Bedoelde het regelen van de temperatuur :-). (Vooral omdat ik lui ben nu ).

[Breud]

Lorduh schreef op zaterdag 5 juli 2025 @ 08:51:
@xoror
Ik maak geen gebruik van de FTC. Rechtstreeks op display van de binnenunit. Staat bij mij doorgaans op 44. Ik zet het (voorlopig) manueel naar 58 wanneer ik overproductie heb van de zonnepanelen.

[Afbeelding]

Plan is om dit te automatiseren, hetzij met Home Assistant, hetzij met Loxone. De FTC heb ik niet echt nodig, daar ik ga steunen op de mogelijkheden van een domoticasysteem. Om de vloerverwarming te sturen ga ik gebruik maken van actuators, i.c.m. een schakelaar die een temperatuur- en luchtvochtigheidsensor aan boord heeft. Wel een duur grapje ...

Is je aantal bar (druk) niet wat hoog?

[xoror]

Miezie schreef op zaterdag 5 juli 2025 @ 20:32:
[...]

Bedoelde het regelen van de temperatuur :-). (Vooral omdat ik lui ben nu ).

Oh op die fiets, Nee ik heb geen automatische automation helaas (17c gaat vrijwel altijd goed hier, en dan is het huis koel zat. Bij hoge luchtvochtigheid zet ik aan de hand van de max(dauwpunten) handmatig te temp (komt dus niet zo vaak voor)).

Maar is iets van
1) x = max(dauwpunten,..)
2) s = x + 0.5
3) set climate when s > current climate flow temp.

Ws wil je bij stap 3 ook een soort [min, max] bij houden waar tussen hij moet blijven (just in case)

En dat periodiek doen, elke min oid.

[ Voor 15% gewijzigd door xoror op 05-07-2025 23:27 ]

[xoror]

Voor de mensen die mijn binaries gebruiken icm OTA. Sinds esphome 2025.03 hebben ze esp-idf versie veranderd waardoor je misschien settings verloren gaan (dus je wifi password) na OTA.

zie: https://github.com/gekkek...ecodan-hp/discussions/165

[ Voor 29% gewijzigd door xoror op 07-07-2025 09:39 ]

[tekenbord]

goed dat het dauwpunt vermeld wordt inderdaad.
Zelf had ik de eerste dagen de 'normale' cooling target functie aanstaan, maar dat geeft echt vochtproblemen (condens op vloer). Je kunt voor zover ik weet ook niet de min/max feed-temp instellen, waardoor er 10gr koeling door de leidingen liep.

Overgestapt naar cool flow, op 18gr. tussen 08:00-20:00
Verbruikt weinig vermogen/geen herrie, zeer aangename temperatuur binnen(22-24gr en buiten 30-35), en geen condens.
Enige is dat je deuren dicht moet houden, en de cool flow bijna de hele dag aan hebben, voor mij echter geen nadeel.
Bij de volgende warmte periode probeer ik een paar dagen 20gr.

Ik heb dit nog nooit geprobeerd met heating flow, ben benieuwd hoe dat gaat in de winter.

[Miezie]

tekenbord schreef op maandag 7 juli 2025 @ 10:39:
goed dat het dauwpunt vermeld wordt inderdaad.
Zelf had ik de eerste dagen de 'normale' cooling target functie aanstaan, maar dat geeft echt vochtproblemen (condens op vloer). Je kunt voor zover ik weet ook niet de min/max feed-temp instellen, waardoor er 10gr koeling door de leidingen liep.

Overgestapt naar cool flow, op 18gr. tussen 08:00-20:00
Verbruikt weinig vermogen/geen herrie, zeer aangename temperatuur binnen(22-24gr en buiten 30-35), en geen condens.
Enige is dat je deuren dicht moet houden, en de cool flow bijna de hele dag aan hebben, voor mij echter geen nadeel.
Bij de volgende warmte periode probeer ik een paar dagen 20gr.

Ik heb dit nog nooit geprobeerd met heating flow, ben benieuwd hoe dat gaat in de winter.

Waarom zou je cooling flow op 20 proberen? Je wilt die zo laag mogelijk hebben…

Heating flow is verwarmen met een vaste TA… niks meer / minder. Cooling flow is koelen met vaste TA.

[Lorduh]

Het is interessant om de luchtvochtigheid te bekijken. Vorige week was het hier buiten 37 graden. De koeling stond ingesteld op 18 graden. Toen ontstond er toch wat condens bij de collector, maar gelukkig niet op de vloer. Ik heb de koeling toen maar verhoogd naar 20 graden. Dit was eigenlijk nog steeds voldoende om het huis aangenaam fris te houden. Onze woonkamer is de warmste ruimte, en die werd niet warmer dan 25 graden. De koeling staat nu alweer een paar dagen uit.

@Miezie Het is inderdaad allemaal erg prijzig. Ik ben nog volop bezig de situatie wat in kaart te brengen. Ik heb bijvoorbeeld ook redelijk wat Philips Hue-spullen. Een mogelijkheid is om die te blijven gebruiken en te switchen zodra er uitval is, eventueel te integreren in Loxone. Al is dat wederom gepruts waar ik in zekere zin vanaf wil. Nu goed, ik ga me eerst en vooral focussen op de vloerverwarming, warmtepomp en alles wat met de bovenverdieping te maken heeft. Dan kan ik alsnog zien wat ik wel of niet met de benedenverdieping doe.

[P5ycho]

Even een idee dumpen hoor... TLDR: stooklijn in esp32 en regelen op Ta?

Het is voor mij al langer een wens om mijn wp te sturen op aanvoertemperatuur in plaats van een stooklijn met aan/uit regeling.

Het probleem van de stooklijn met aan/uit regeling is wat mij betreft dat dit in een vaste temperatuurstijging per uur resulteert, en er geen compensatie gedaan kan worden voor een dag met sterke wind, wat zoninstraling, compensatie in Ta afhankelijk van de delta tussen Tsetpoint en Thuidig, etc. En daar bovenop, ik wil geen start/stops als er duidelijk een warmtevraag is en blijft. De enige manier om lange runs te krijgen is een grotere hysterese en een zo laag mogelijke Ta.

De oplossing zou mijns inziens zijn om te sturen op Ta. Een stooklijn-target als basis, met daar bovenop een compensatie om de Ta zo te sturen dat de temperatuur rond het setpoint blijft.

Op de binnenunit kun je de stooklijn met een paar graden plussen of minnen, maar dit is helaas niet mogelijk via CN105.
Om deze functionaliteit te maken zou de unit in Heat flow modus moeten draaien met een Ta als input vanuit CN105, stooklijn en andere slimmigheid moet dan extern geregeld worden.

Daarnaast viel het me ook op dat de wp meteen volle bak aan de slag gaat om de Ta temperatuur te halen, terwijl ik liever zou zien dat de Ta begint op Tretour + 5K en langzaam naar de Ta bolgens stooklijn. Dat lijkt me niet het meest efficient, en de Panasonic Heichamon gebruikers hebben al trucjes uitgehaald om de unit rustig te laten starten.

Dus toen dacht ik, kunnen we de stooklijn en PI regeling niet in de esp32 zetten? Is daar interesse in?

[Miezie]

P5ycho schreef op woensdag 9 juli 2025 @ 16:44:
Even een idee dumpen hoor... TLDR: stooklijn in esp32 en regelen op Ta?

Het is voor mij al langer een wens om mijn wp te sturen op aanvoertemperatuur in plaats van een stooklijn met aan/uit regeling.

Het probleem van de stooklijn met aan/uit regeling is wat mij betreft dat dit in een vaste temperatuurstijging per uur resulteert, en er geen compensatie gedaan kan worden voor een dag met sterke wind, wat zoninstraling, compensatie in Ta afhankelijk van de delta tussen Tsetpoint en Thuidig, etc. En daar bovenop, ik wil geen start/stops als er duidelijk een warmtevraag is en blijft. De enige manier om lange runs te krijgen is een grotere hysterese en een zo laag mogelijke Ta.

De oplossing zou mijns inziens zijn om te sturen op Ta. Een stooklijn-target als basis, met daar bovenop een compensatie om de Ta zo te sturen dat de temperatuur rond het setpoint blijft.

Op de binnenunit kun je de stooklijn met een paar graden plussen of minnen, maar dit is helaas niet mogelijk via CN105.
Om deze functionaliteit te maken zou de unit in Heat flow modus moeten draaien met een Ta als input vanuit CN105, stooklijn en andere slimmigheid moet dan extern geregeld worden.

Daarnaast viel het me ook op dat de wp meteen volle bak aan de slag gaat om de Ta temperatuur te halen, terwijl ik liever zou zien dat de Ta begint op Tretour + 5K en langzaam naar de Ta bolgens stooklijn. Dat lijkt me niet het meest efficient, en de Panasonic Heichamon gebruikers hebben al trucjes uitgehaald om de unit rustig te laten starten.

Dus toen dacht ik, kunnen we de stooklijn en PI regeling niet in de esp32 zetten? Is daar interesse in?

Dit kan je toch prima met een home assistant doen? En de ruimteregeling van de FTC doet dit in principe ook…

[P5ycho]

Dat was mijn vraag niet natuurlijk, maar ik wil wel motiveren waarom ik dit in een esp32 zou stoppen.

In home assistant kan alles ook, maar dan ben je er wel afhankelijk van. Een regellus over wifi, dat zie ik niet als betrouwbaar. Als dit zou draaien op een esp32 dan kan dat een standalone upgrade zijn zonder verdere afhankelijkheden. Een setpoint met een bluetooth temperatuursensor en gaan met die banaan.

De ruimteregeling heeft ook zo zijn eigenaardigheden helaas.

Dus, los van of het op andere manieren kan leek het me wel een waardevolle toevoeging.

[Miezie]

P5ycho schreef op woensdag 9 juli 2025 @ 18:25:
Dat was mijn vraag niet natuurlijk, maar ik wil wel motiveren waarom ik dit in een esp32 zou stoppen.

In home assistant kan alles ook, maar dan ben je er wel afhankelijk van. Een regellus over wifi, dat zie ik niet als betrouwbaar. Als dit zou draaien op een esp32 dan kan dat een standalone upgrade zijn zonder verdere afhankelijkheden. Een setpoint met een bluetooth temperatuursensor en gaan met die banaan.

De ruimteregeling heeft ook zo zijn eigenaardigheden helaas.

Dus, los van of het op andere manieren kan leek het me wel een waardevolle toevoeging.

Of het op de esp moet of niet, daar ga ik niet over. Persoonlijk zou ik het niet doen, omdat het afwijkt van de geëigende manier van stoken en niet per se past bij het doel van de esp (uitlezen en aansturing beschikbaar maken) en niet echt standaard is.

De uitdaging die je alleen omschrijft zit voor mij wel een beetje de crux. Hoe is je systeem Waterzijdig ingeregeld? Waar hangen je thermostaten? Klopt je stooklijn wel? Et cetera… de oplossing met de hysterese is een prima oplossing, daar is het juist voor…

Met die gedachte erbij snap ik niet zo goed waarom je het zou willen…

[P5ycho]

Ik wil dit omdat deze regeling oneindige runs op minimale benodigde Ta toelaat. Dat geeft een beter rendement, want lagere Ta is minder defrosts en minder start/stops.

Mijn systeem loopt al 6 jaar prima, dit is geen probleem maar optimalisatie.

Thermostaten die een gasketel bedienen via opentherm werken overigens hetzelfde: PI controller met regeling op Ta. Het is dus heel normaal, misschien wel de meest gebruikte regeling van Nederland. Warmtepompen zijn echter nog niet zover.

[SebastiaanPs]

@P5ycho
Deze wensen:

P5ycho schreef op woensdag 9 juli 2025 @ 16:44:
Het probleem van de stooklijn met aan/uit regeling is wat mij betreft dat dit in een vaste temperatuurstijging per uur resulteert,

En

En daar bovenop, ik wil geen start/stops als er duidelijk een warmtevraag is en blijft.

Deze wensen gaan niet goed met elkaar samen, je zit nou eenmaal aan je minimumvermogen vast? Als je geen starts/stops wil dan is een geleidelijke stijging van de temp niet te vermijden?

Daarnaast viel het me ook op dat de wp meteen volle bak aan de slag gaat om de Ta temperatuur te halen, terwijl ik liever zou zien dat de Ta begint op Tretour + 5K en langzaam naar de Ta bolgens stooklijn. Dat lijkt me niet het meest efficient, en de Panasonic Heichamon gebruikers hebben al trucjes uitgehaald om de unit rustig te laten starten.

In de ruimteregeling start ie bij mij rustiger dan met vaste Ta/WAR. Ook gaat de warmtepomp dan terug naar het minimumvermogen en gaat dan vele uren op exact het minimumvermogen verwarmen. Je ziet dan de Ta over de uren heel geleidelijk stijgen. Dit is het gedrag wat jij zoekt?
Je hebt wel een grote hysterese in de ruimteregeling. Maar is het dan niet simpeler om die op te lossen? Bijv bij Tset overshoot 0.6 graden of meer, de Tset tijdelijk verlagen met 0.5 graden, zodat je de hysterese verlaagt van 1.0 naar 0.5 gr in de ruimteregeling. Of door elke 3 uur de Tset gedurende bijv 30 min met 0.5 gr te verlagen, zelfde effect.

Dus toen dacht ik, kunnen we de stooklijn en PI regeling niet in de esp32 zetten? Is daar interesse in?

Ik vind het op zich wel een mooi project en snap waar de wens vandaan komt, maar denk dat een goed afgestelde ruimteregeling met gereduceerde hysterese dit doel ook aardig bereikt. Heb daarom zelf nu geen sterke behoefte.

[xoror]

- We kunnen alleen Ta instellen, en dan gaat de wp daarmee aan de slag (in begin idd volle toeren). Daar kan je niet zoveel aan veranderen.
- Als je een BT temp sensor toevoegt heb je ook alweer een afhankelijkheid (draadloos).
- De externe prikkels (verwachtingen, zonne instraling) zullen toch op een of andere manier gevoed moeten worden, dus wifi of ethernet

Nu is het zo dat ik zo iets al in gedachten had, maar je blijft met de externe prikkels. Dan kan je beter even mijn andere project remote thermostat proberen. Nadat die is ingeregeld hoor ik goede verhalen over.

Ik heb hier wel eens over nagedacht maar die externe prikkels houden me steeds tegen, juist omdat ik het altijd stand alone wil laten draaien. En dan kom je bij z'n adaptieve regeling als ruimte regeling. (Want je ziet alleen thermostaat temp, buiten temp en hoe je ingestelde Ta hierop effect heeft. Ik gok dus dat hij na het inleren weet welke TA hoeveel graden de temp binnen in een bepaalde tijd ophoog krijgt en daarop stuurt).

[P5ycho]

- Je zou de Ta langzaam kunnen laten oplopen bij een start, beginnende bij 25C, of retourtemp+5K oid. Dan langzaam opvoeren. Volgens mij doen de panasonic monoblokkers dat met heishamon.
- De 'externe prikkels' worden weggeregeld door de PI controller, als het goed is. Ik had daar zelf geen externe input voor in gedachte.
- Ik ben het met je eens dat een BT sensor ook weer een afhankelijkheid is, en het is ook niet mijn end goal om dat zo op te stellen. Uiteindelijk wil ik een KNX gebaseerd klimaatsysteem bewerkstelligen dat automatisch kan verwarmen met vvw, koelen met fancoils, en de wp optimaal inzet. De koppeling tussen wp+esp32 en knx daar ga ik me later pas zorgen over maken, stapje voor stapje.

Ik ga je remote thermostat ook nog even bekijken vanavond.

[ Voor 4% gewijzigd door P5ycho op 10-07-2025 14:56 ]

[Miezie]

Je eerste twee bullets zijn eigenlijk wat de ruimteregeling doet. Misschien dat de delta T niet helemaal lekker is, maar het is wel wat het doet. Dat met de remote thermostat is denk ik wel een basis.

Wat je met KNX wilt bewerkstelligen heb ik hier met Home Assistant voor elkaar gemaakt, dan geen fancoils... maar wel de zonwering optimaal, vloerkoeling erbij, automatischi schakelen tussen verwarmen en koelen, zoeken naar de maximale rust in de wp, etc. Ik heb het near perfect en toen kwam er een thuisaccu, is de nachtverlaging weer niet zo nodig (vind ik dan...) en gaat het weer anders .

Hier hangt de FTC trouwens in de woonkamer, dus een RR voor de woonkamer is hier heel logisch en die hysterese is nou net iets waar ik niet wakker van kan liggen ;-).

[P5ycho]

Hoe vind jij de maximale rust in je wp dan? Geen ruimteregeling?

[Miezie]

P5ycho schreef op donderdag 10 juli 2025 @ 21:11:
Hoe vind jij de maximale rust in je wp dan? Geen ruimteregeling?

Maximale oppervlakte voor afgifte, TA laag zetten en niet zo laag dat het in het tussenseizoen nooit weer warm wordt (dan draai je op een afgifte die te laag is en dan puf je altijd het minimale vermogen de lucht in) en me vooral niet druk maken om defrosten, want dat is met die ruimteregeling (en met elke andere) gewoon wat het is…

En als ik dan kijk in de data heb ik nu 2600 starts op 3600 draaiuren (ofzoiets)… dus de warmtepomp zal logischerwijs op draaiuren een keer stuk gaan.

Als ik dan ga spelen met prohibits in dure uren en stapsgewijs de gewenste ruimte temperatuur aanpassen zie ik wel geklooi met de frequenties die je eigenlijk liever niet hebt, maar daar werken de kosten op tegen de baten zullen we het maar zeggen…

Als de hystereses acceptabel zijn, de TA klopt en de afgifte klopt is die ruimteregeling eigenlijk best goed.

Wat ik ook zie is dat de delta T eigenlijk ook veelal juist kleiner dan 5 is… en dat wil je.

[ Voor 4% gewijzigd door Miezie op 10-07-2025 23:20 ]

[xoror]

P5ycho schreef op donderdag 10 juli 2025 @ 14:56:
- Je zou de Ta langzaam kunnen laten oplopen bij een start, beginnende bij 25C, of retourtemp+5K oid. Dan langzaam opvoeren. Volgens mij doen de panasonic monoblokkers dat met heishamon.
- De 'externe prikkels' worden weggeregeld door de PI controller, als het goed is. Ik had daar zelf geen externe input voor in gedachte.
- Ik ben het met je eens dat een BT sensor ook weer een afhankelijkheid is, en het is ook niet mijn end goal om dat zo op te stellen. Uiteindelijk wil ik een KNX gebaseerd klimaatsysteem bewerkstelligen dat automatisch kan verwarmen met vvw, koelen met fancoils, en de wp optimaal inzet. De koppeling tussen wp+esp32 en knx daar ga ik me later pas zorgen over maken, stapje voor stapje.

Ik ga je remote thermostat ook nog even bekijken vanavond.

- De min Ta bij mij is 25c bij fixed flow. Mijn huis heeft niet meer nodig dan 27c. Maar als ik hem dus op 25c laat starten gaat de compressor ook even los voordat hij tot rust komt. Voor mijn gevoel scheelt dat dus niet zo erg. Bij ruimte regeling laat hij lagere Ta toe, maar die zijn niet zelf instelbaar.

- je moet nog praten met die Pi controller...

[P5ycho]

De PI controller heeft alleen setpoint als input en zou op de esp32 draaien lijkt me.
Ja, als Ta=25C minimum is en 27 gewenst, dan valt daar weinig te halen helaas. Misschien dat het voor minder ideale afgiftesystemen nog wat opleveren kan.

[ Voor 18% gewijzigd door P5ycho op 11-07-2025 21:00 ]

[xoror]

HA heeft helaas weer wat dingen gewijzigd waardoor je nu niet meerdere esp32 kan draaien met mijn project. Hier is een breaking change voor nodig. Voor een volgende release moet je de sensor namen die je in je eigen scripts gebruikt even aanpassen naar het nieuwe formaat

zie https://github.com/gekkek...ecodan-hp/discussions/166

[Miezie]

xoror schreef op dinsdag 15 juli 2025 @ 14:34:
HA heeft helaas weer wat dingen gewijzigd waardoor je nu niet meerdere esp32 kan draaien met mijn project. Hier is een breaking change voor nodig. Voor een volgende release moet je de sensor namen die je in je eigen scripts gebruikt even aanpassen naar het nieuwe formaat

zie https://github.com/gekkek...ecodan-hp/discussions/166

Mooi moment om meer aan te pakken. Dat vind ik niet zo erg .

Is een extract makkelijk te maken voor alle sensornamen? Dan kan ik het voorbereiden.

[xoror]

Niet dat ik weet, maar je hoeft alleen maar die suffix toe te voegen aan je custom scripts/automations. De rest gaat automatisch goed.

[SebastiaanPs]

xoror schreef op dinsdag 15 juli 2025 @ 14:34:
HA heeft helaas weer wat dingen gewijzigd waardoor je nu niet meerdere esp32 kan draaien met mijn project. Hier is een breaking change voor nodig. Voor een volgende release moet je de sensor namen die je in je eigen scripts gebruikt even aanpassen naar het nieuwe formaat

zie https://github.com/gekkek...ecodan-hp/discussions/166

Thanks voor al jouw inspanningen

[xoror]

er komen ook wat changes aan om wifi hopelijk wat beter te maken, maar die ben ik nog even een dagje testen (de gene die van source bouwen kunnen al testen, changes staan online, maar release build en OTA komen later)

edit: OTA images zijn nu in pre-release beschikbaar, voor mensen die handmatig flashen om te testen. Ik kijk het even aan, en als er geen issues zijn dan maak ik ze beschikbaar voor het publiek.

[ Voor 31% gewijzigd door xoror op 15-07-2025 21:33 ]

[Miezie]

xoror schreef op dinsdag 15 juli 2025 @ 16:01:
er komen ook wat changes aan om wifi hopelijk wat beter te maken, maar die ben ik nog even een dagje testen (de gene die van source bouwen kunnen al testen, changes staan online, maar release build en OTA komen later)

edit: OTA images zijn nu in pre-release beschikbaar, voor mensen die handmatig flashen om te testen. Ik kijk het even aan, en als er geen issues zijn dan maak ik ze beschikbaar voor het publiek.

Held :-)

[Wouterie]

Ah, heeft dat ook nog gevolgen voor de remote thermostat? Die synchroniseert sinds een paar dagen ook niet meer. Kan natuurlijk weer aan mijn 'stabiele' configuratie liggen

[xoror]

Als het goed is niet, tenzij je expliciet de naam ecodan heat pump heb gebruikt bij het sync script. post je sync script anders even

mogelijk moet je de access goed zetten na reinstall (die stap met meer rechten geven omdat het component nu anders heet)

[ Voor 7% gewijzigd door xoror op 16-07-2025 11:57 ]

[Wouterie]

Dat is dit script:

code:

  trigger:
    - trigger: state
      entity_id:
        - climate.thuis
  conditions:
    - condition: template
      value_template: "{{ trigger.from_state.attributes.current_temperature != trigger.to_state.attributes.current_temperature }}"
  actions:
    - action: esphome.ecodan_thermostat_set_climate_temperature_room_0
      data:
        temperature: "{{ state_attr('climate.thuis' , 'current_temperature') }}"

Het lijkt goed te werken, maar de temperatuur wordt toch niet gesynchroniseerd. Als ik bijvoorbeeld handmatig 19 ingeef dan blijft dat staan. Ik heb alles al herstart etc... maar goed. Heeft niet echt prio verder.

[xoror]

"Allow the device to perform Home Assistant actions”
al aangezet?

[Wouterie]

Ja, dat staat nog steeds aan. Ik ga wel even rommelen, komt wel goed. Ik dacht dat er wellicht wat was omgevallen na een update. Als dat zo is dan wordt het doorgaans vanzelf weer opgelost

[xoror]

Wouterie schreef op woensdag 16 juli 2025 @ 14:04:
Ja, dat staat nog steeds aan. Ik ga wel even rommelen, komt wel goed. Ik dacht dat er wellicht wat was omgevallen na een update. Als dat zo is dan wordt het doorgaans vanzelf weer opgelost

had je met de hand geupgrade? Want ik heb de release nog niet publiek gemaakt namelijk.
Hier werkt alles nog wel naar behoren

[Wouterie]

Nee, ik had Home Assistant geupdate laatst, de rest blijf ik eigenlijk vanaf.

[xoror]

Wouterie schreef op woensdag 16 juli 2025 @ 16:38:
Nee, ik had Home Assistant geupdate laatst, de rest blijf ik eigenlijk vanaf.

dan draai je nog de oude code hoor en zou het moeten werken.
Moet je bij automations kijken waarom de sync actie niet lukt, of je daar wat kan zien in de traces (logs)

[xoror]

Geen issues gezien afgelopen dagen en wifi en cou usage waren iets beter. Dus nu beschikbaar als OTA.

Lees de release notes goed door als je eigen scripts heb.

https://github.com/gekkek...eleases/tag/2025-07-15.01

Voor mensen die hun wifi credentials verliezen na OTA, lees https://github.com/gekkek...ecodan-hp/discussions/165

[ Voor 20% gewijzigd door xoror op 17-07-2025 12:04 ]

[Gaiber]

Iemand anders last van settings die bij elke reboot gereset worden na een update naar esphome 2025.7? Hij werkt wel maar de settings blijven niet bewaard. Bijv server control (en alle prohibits) en heatpump staan uit na een reboot.

Enige aanpassing aan de yaml die ik heb gedaan is het toevoegen van: name_add_mac_suffix: false op advies uit een eerdere comment zodat de namen ongewijzigd blijven.

Update gaat via esphome builder en niet via de ota releases. Bij het terugzetten naar 2025.6 gaat het wel weer goed.

Yaml:

code:

substitutions:
  name: ecodan-heatpump
  friendlyName: Ecodan heatpump

# # enable ota update via http request
# http_request:
#   buffer_size_tx: 20248

esphome:
  name: ${name}
  friendly_name: ${friendlyName}
  name_add_mac_suffix: false

ota:
  - platform: esphome
#  - http_request
#  password: !secret heatpump_ota_password

wifi:
  manual_ip: 
    static_ip: 192.168.2.36
    gateway: 192.168.2.1
    subnet: 255.255.255.0

api:
  reboot_timeout: 0s
#  encryption:
#    key: !secret heatpump_encryption_key

# external_components:
# - source:
#     type: local
#     path: components
#   components: [ ecodan ]

# packages:
#  base: !include confs/base.yaml # 
#  esp32: !include confs/esp32s3-heishamon.yaml # esp32.yaml for regular board
#  zone1: !include confs/zone1.yaml
# # disable if you don't want to use zone 2
# # zone2: !include confs/zone2.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
#  svc: !include confs/server-control.yaml
#  dbg: !include confs/debug.yaml
#  wifi: !include confs/wifi.yaml

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: [ 
            confs/base.yaml,            # required
            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,
            ## 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/ecodan-labels-it.yaml,
            #confs/ecodan-labels-fr.yaml,
            confs/server-control.yaml,
            #confs/debug.yaml,
            confs/wifi.yaml
           ]

# enable logger
logger:
  baud_rate: 115200
  # logs:
  #   esp32.preferences: ERROR
  #   sensor: ERROR
  #   text_sensor: ERROR
  #   binary_sensor: ERROR
  #   switch: ERROR
  #   button: ERROR
  #   number: ERROR
  #   climate: ERROR
  #   component: ERROR
  #   ecodan.component: ERROR


# Enable Web server.
web_server:
  port: 80
  #ota: true

ecodan:
  id: ecodan_instance
  uart_id: uart_ecodan
# polling interval override in ms, default 500
#  polling_interval_override: 1000
# uncomment line below and adjust the heat constant if your system uses a water + glycol mixture
#  specific_heat_constant_override: 3.9

[xoror]

ik geloof dat ze overgestapt zijn naar nieuwe esp-idf. Ik geloof dat een OTA de nvs niet opnieuw aanmaakt (dat wil je ook niet, want dan gaan je settings verloren). Kijk of je logs kan zien/aanzetten. En monitor nvs write errors. Dan zie je wellicht waarom het fout gaat.

Zie hier voor meer info: https://github.com/gekkek...ecodan-hp/discussions/165
Wat je kan proberen is 1x met de laatste esphome via usb flashen (de factory image) zodat alle partities goed worden gezet.

Laat even weten of het lukt, want ik ben dit issue ook aan het tracen, kan het alleen niet reproduceren lokaal

[Gaiber]

Zojuist wat versies geprobeerd, alle opties met flash via usb.
- Via de .bin release op github (esp32s3-z1-en-2025-07-15.01.factory.bin) blijven de settings wel bewaard na een herstart. Deze versie draait op esphome 2025.6.3.
- Via het maken van eigen factory bin met bovenstaande yaml op esphome 2025.6.3 gaat het ook goed.
- Via het maken van eigen factory bin met bovenstaande yaml op esphome 2025.7.3 gaat het niet goed en moet ik de setting voor heatpump, server control en prohibits weer aanvinken omdat deze uit staan na herstart.

UART logging zie ik alleen het volgende bij een herstart:
20:57:25 [D] [esp32.preferences:142]
Writing 3 items: 3 cached, 0 written, 0 failed

Voor de rest geen foutmeldingen of write errors.

[ Voor 15% gewijzigd door Gaiber op 23-07-2025 21:19 ]

[xoror]

@Gaiber
Bedoel je dat de ESP na het rebooten de setting niet terug leest alleen vanaf 2025.7.x ?

edit:
Ik kan het reproduceren. Ik denk dat het een regressie is in esphome 2025.7.x.
Ik zie de warmte pomp wel de juiste waarde terug sturen, ik zal eens kijken of het nieuw/gewijzigd gedrag is


edit 2:
hmm komt door deze breaking change https://github.com/esphome/esphome/pull/8961
ze hebben gedrag van on_state veranderd, dat lijkt gewijzigd naar on_state_changed. Het vervelende is dat dit breaking is met oude versies

edit 3:
Het gaat om de initial state, als ik dat expliciet zet dan werkt hij voor zowel oude als nieuwe. Dus even recompile dan zal het moeten werken

[ Voor 89% gewijzigd door xoror op 23-07-2025 22:42 ]

[Gaiber]

@xoror Zojuist getest en werkt nu goed met esphome 2025.7.3. Bedankt voor de snelle fix!

[xoror]

nieuwe release getagged:

- upgraded to esphome https://github.com/esphome/esphome/releases/tag/2025.7.3
- re-enabled munual upload of ota binaries via web browser
- leave `wifi:` blank for OTA binaries, the ssid and password seem to take priority over the configured ones (improv/wifi portal)
- handle breaking change in esphome 2025.7.x (https://github.com/esphome/esphome/pull/8961)

Als het goed is worden de wifi credentials nu niet meer gewist bij OTA.
zie https://github.com/gekkek...ecodan-hp/discussions/165

[Takkeding]

Net bijgewerkt via ESPHome en verloor de verbinding, dacht eerst dat mDNS om een of andere reden niet meer goed werkt. Maar het lijkt complexer. Op het IP van de Atom/ESP is de webinterface nog te benaderen, maar HA ziet het apparaat niet meer. ESPHome ziet 'm nog wel, maar als ik daar op logs klik gebeurt er na verbinden niets meer. Dat is ook op de webinterface van de Atom/ESP zo. Die is te benaderen en ik kan de ESP zo aansturen, maar er worden daar ook geen logs weergegeven. Voor de zekerheid de .yaml nog gelijk getrokken met degene op de github, maar dan krijg ik een warning in de logs:

WARNING Can't connect to ESPHome API for ecodan-heatpump @ x.x.x.x: Error connecting to [AddrInfo(family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, proto=6, sockaddr=IPv4Sockaddr(address='192.168.1.134', port=6053))]: [Errno 111] Connect call failed ('x.x.x.x', 6053) (SocketAPIError)

De poort 6053 kan ik vanaf mijn laptop iig wel gewoon pingen via Test-NetConnection dus die staat wel open. Iemand dit eerder gezien? Ben al een klein uur bezig met wat dingen nalopen maar krijg het vooralsnog niet gevonden.

[xoror]

je heb via esphome builder gecompiled? Logs kan je aanzetten dmv de switch "uart logging", even togglen.
is je IP misschien ook in gebruik door een ander apparaat toevallig ?

Verder deze https://github.com/gekkek...ecodan-hp/discussions/166 gelezen?

en check je config of je wel een

api:

sectie heb, anders heb je geen api naar HA.

Je kan de esp ook handmatig in HA zetten, door add te doen en ip geloof ik in te vullen.

[ Voor 44% gewijzigd door xoror op 25-07-2025 10:23 ]

[Takkeding]

Ik heb gecompiled via de webinterface van ESPHome, weet niet zeker of dat de esphome builder is die je bedoelt. UART logging wordt toch al standaard gedaan via de .yaml? Dit staan nu zo:

# enable logger
logger:
baud_rate: 115200

Mee dat ik kijk zie ik de switch staan op de webinterface Er wordt nogal veel verschillende varianten van de ecodan.component gelogd:

code:

[I] [ecodan.component:018]  
Could not publish state of sensor 'status_multi_zone' with value: '0.000000'

En begrijp uit https://esphome.io/components/logger.html deze documentatie dat hij dan default alles op DEBUG logt.

Ik weet vrij zeker dat het IP adres niet gebruikt wordt door een ander apparaat, de ESP/Atom heeft een reservation in m'n DHCP server om dat te voorkomen

Ook heb ik de discussion gezien, maar omdat dit het enige ecodan apparaat is niet toegepast.

[ Voor 17% gewijzigd door Takkeding op 25-07-2025 10:30 ]

[xoror]

er zit een switch op de esphome page

die kan je aanzetten dan zie je alle logging op de esp

Maar de error geeft aan dat de esp niet naar HA kan connecten. Je kan even kijken vanuit HA shell of je de esp ip kan pingen. Misschien zit er iets niet lekker in je netwerk waardoor er geen verkeer tussen die 2 mogelijk is

[ Voor 21% gewijzigd door xoror op 25-07-2025 10:32 ]

[Takkeding]

Wat opvalt met inschakelen van UART logging is dat die gegevens dan ook in ESPHome onder de logs te zien zijn. Dus het is puur dat de ESP geen data kan of mag sturen lijkt het. Vanuit de HA shell kan ik het de ESP/Atom ook gewoon pingen. Netwerkprobleem lijkt het daarom ook niet te zijn. Voor de update werkte het ook 'gewoon'.

Ik kan niet vinden hoe ik standaard de UART logging in kan schakelen, mogelijk dat daarmee wel duidelijk wordt waar het stokt. Enig idee hoe ik die standaard in kan schakelen?

[xoror]

YAML:

# enable logger
logger:
  baud_rate: 115200
  # logs:
  #   esp32.preferences: ERROR
  #   sensor: ERROR
  #   text_sensor: ERROR
  #   binary_sensor: ERROR
  #   switch: ERROR
  #   button: ERROR
  #   number: ERROR
  #   climate: ERROR
  #   component: ERROR
  #   ecodan.component: ERROR

of alles op debug is misschien handiger

YAML:

logger:
  baud_rate: 115200
  level: DEBUG

uncommenten in je main yaml en alles van ERROR naar DEBUG veranderen.
Kan het zijn dat je firewall policies heb die alleen 1 richting toestaat ? Dus van esp naar ha wellicht niet toegestaan ?

Uart logging staat standaard aan vanwege baudrate != 0. Met de toggle zetten we alleen de loglevel lager zodat je meer ziet.

Wat ook kan helpen is 'clean' doen in esphomebuilder en dan opnieuw bouwen.

Verder inpluggen via usb-c, en dan via https://web.esphome.io/?dashboard_install
kan je logs direct meekijken over uart (werkt alleen in edge of chrome) zonder extras te hoeven installeren.

[ Voor 16% gewijzigd door xoror op 25-07-2025 11:38 ]

[Takkeding]

Het logger component stond al op:

code:

# enable logger
logger:
  baud_rate: 115200

In de YAML op github, maar heb hem nu naar

code:

# enable logger
logger:
  baud_rate: 115200
  level: DEBUG

gezet, een clean build files gedaan. Echter moet ik nog steeds de switch toggelen voordat er dingen gelogged worden.

[xoror]

YAML:

switch:
  - platform: template
    name: UART Logging
    id: uart_debug_switch
    restore_mode: ALWAYS_OFF
    optimistic: true
    turn_on_action:
      - logger.set_level: VERBOSE
    turn_off_action:
      - logger.set_level: ERROR

ALWAYS_OFF -> ALWAYS_ON

[ Voor 3% gewijzigd door xoror op 25-07-2025 11:58 ]

[Takkeding]

Die zag ik, maar dat kan ik niet niet doen via ESPHome, dan miept de device builder dat er een duplicate entry voor 'UART Logging' is, wat pas uit de base.yaml komt. Had gehoopt dat het wel via ESPHome kon. Zal later vandaag even uitvogelen hoe ik zonder ESPHome compile, dat heb ik nog nooit gedaan. Bedankt voor zover!

[Takkeding]

Als ik in de yaml het volgende toevoeg

code:

switch:
  - platform: template
    name: UART Logging2
    id: uart_debug_switch2
    restore_mode: ALWAYS_ON
    optimistic: true
    turn_on_action:
      - logger.set_level: DEBUG
    turn_off_action:
      - logger.set_level: ERROR

Dan werkt het wel, en heb ik een tweede knopje UART Logging2. Beetje lelijk, maar does the job. Heb de ESP ook even losgehaald van de WP en via USB C geflashed. Daarna zag ik van de ESP zelf in HA nog geen stats, toch teruggehangen en de WP weer op spanning gezet. Ook dat werkte nog niet.

Hierna klikte ik eens op het tandwiel in de ESPHome integratie van HA op het tandwiel bij de ESP. Staat het vinkje uit bij "Toestaan dat het apparaat HomeAssistant-acties uitvoert". Dat aangevinkt en direct werkt alles weer Kan mij niet voorstellen dat ik dit bewust heb uitgezet. Maar dat moet wel zo zijn. Ook nu logged de ESP nog steeds afentoe de acties dat hij niets kan sturen naar HA.

Nogmaals bedankt voor de hulp, probleem zat tussen het scherm en bureaustoel

[xoror]

Die actie is alleen nodig voor remote thermostat project
(is nodig dat de remote thermostat de climate zelf kan terugkoppelen)

Voor de reguliere esp is dat niet nodig, apart dat jij dat nodig heb. Het staat hier uit namelijk...

[The Source]

Ik probeer een nieuwe release te flashen want de status van de warmtepomp wordt niet goed weergegeven.
Na terug komst staat alles uit en dus geen server control aan oid, echter moet ik elke keer forceren voor de DHW run, meestal nadat ik erachter kom dat ik koud water had.

Echter ging remote flahen niet, dus ik denk ik download de te flashen file maar het gaat fout bij het compileren. Heeft iemand een idee:

code:

INFO ESPHome 2025.7.4
INFO Reading configuration /config/esphome/ecodan.yaml...
INFO Updating https://github.com/gekkekoe/esphome-ecodan-hp@main
INFO Updating https://github.com/gekkekoe/esphome-ecodan-hp.git@main
INFO Detected timezone 'Europe/Amsterdam'
INFO Generating C++ source...
INFO Compiling app...
Processing warmtepomp-ecodan (board: esp32-s3-devkitc-1; framework: espidf; platform: https://github.com/pioarduino/platform-espressif32/releases/download/53.03.13/platform-espressif32.zip)
--------------------------------------------------------------------------------
HARDWARE: ESP32S3 240MHz, 320KB RAM, 8MB Flash
 - framework-espidf @ 3.50302.0 (5.3.2) 
 - tool-cmake @ 3.30.2 
 - tool-esptoolpy @ 4.8.6 
 - tool-mklittlefs @ 3.2.0 
 - tool-ninja @ 1.7.1 
 - tool-riscv32-esp-elf-gdb @ 14.2.0+20240403 
 - tool-xtensa-esp-elf-gdb @ 14.2.0+20240403 
 - toolchain-esp32ulp @ 2.35.0-20220830 
 - toolchain-riscv32-esp @ 13.2.0+20240530 
 - toolchain-xtensa-esp-elf @ 13.2.0+20240530
Reading CMake configuration...
Dependency Graph
|-- ArduinoJson @ 7.4.2
Compiling .pioenvs/warmtepomp-ecodan/src/esphome/components/api/api_connection.cpp.o
Compiling .pioenvs/warmtepomp-ecodan/src/esphome/components/api/api_pb2.cpp.o
[b]xtensa-esp-elf-g++: fatal error: Killed signal terminated program cc1plus[/b]
compilation terminated.
*** [.pioenvs/warmtepomp-ecodan/src/esphome/components/api/api_connection.cpp.o] Error 1
========================= [FAILED] Took 72.36 seconds =========================

[xoror]

je moet laatste source downloaden, esphome 2025.7.x had wat dingen gebroken (server control werd niet uitgelezen). Was een discussie paar posts hierboven.

makkelijkst is gewoon de factory bin downloaden en dan flashen en wifi configgen. daarna kan je Ota vanuit home assistant doen. Dat is als je de atom gebruikt, en anders even source aynchen en rebuild.

[Miezie]

xoror schreef op donderdag 31 juli 2025 @ 20:46:
je moet laatste source downloaden, esphome 2025.7.x had wat dingen gebroken (server control werd niet uitgelezen). Was een discussie paar posts hierboven.

makkelijkst is gewoon de factory bin downloaden en dan flashen en wifi configgen. daarna kan je Ota vanuit home assistant doen. Dat is als je de atom gebruikt, en anders even source aynchen en rebuild.

DTV: wipe je hiermee ook alle registers en begin je dus clean? Heb al maanden wat te repareren…

[xoror]

Miezie schreef op donderdag 31 juli 2025 @ 21:17:
[...]

DTV: wipe je hiermee ook alle registers en begin je dus clean? Heb al maanden wat te repareren…

een factory image cleared alle settings (mits over usb geflashed).
https://github.com/gekkek.../docs/install-from-bin.md
Je kan je wifi tegenwoordig gewoon via usb configgen, na flashen even wachten tot led blauw wordt en dan improv over serial draaien.

[ Voor 15% gewijzigd door xoror op 31-07-2025 21:19 ]

[The Source]

Dank je, geupdate, alles draait weer.
Nu mijn dashboard nog in orde krijgen en in de gaten houden of alles inderdaad de status weergeeft die het moet zijn.

[Miezie]

xoror schreef op donderdag 31 juli 2025 @ 21:19:
[...]


een factory image cleared alle settings (mits over usb geflashed).
https://github.com/gekkek.../docs/install-from-bin.md
Je kan je wifi tegenwoordig gewoon via usb configgen, na flashen even wachten tot led blauw wordt en dan improv over serial draaien.

Had ik dus maaaaaaaanden eerder kunnen doen, smooth migration .

Ik heb ook die entiteit namen al aangepast in mijn automations en er lijkt een migratiefase in de software te zitten? Alle automtations werken namelijk nog steeds, maar de entiteiten in home assistant zijn nog niet hernoemd... Hoe dan ook: we zien het wel.

On the side doen ook de entiteiten die stuk waren het weer, ook mooi .