HeishaMon - Panasonic Aquarea monitoring

[snader2]

Hier hetzelfde probleem, ik gebruikte Advanced IP Scanner om een ander apparaat te vinden op mijn netwerk en beide Heishamons large zijn via de webportal niet meer te bereiken. Gelukkig hier even gekeken wat er nu aan de hand was.

[Charlie_Root]

Ik heb sinds kort de Aquarea WH-WXG12ME8 12kW en een HeishaMon besteld (en inmiddels ontvangen, dank!). Ik was alleen even benieuwd of meer mensen ook een account hebben aangemaakt via aquarea-service.panasonic.com, daar kun je het hele systeem uitlezen (als installateur), zonder dat HeishaMon nog nodig is.

[BarryH]

Charlie_Root schreef op zaterdag 8 augustus 2026 @ 19:56:
Ik heb sinds kort de Aquarea WH-WXG12ME8 12kW en een HeishaMon besteld (en inmiddels ontvangen, dank!). Ik was alleen even benieuwd of meer mensen ook een account hebben aangemaakt via aquarea-service.panasonic.com, daar kun je het hele systeem uitlezen (als installateur), zonder dat HeishaMon nog nodig is.

Ik heb beide

Heishamon geeft je het echte E verbruik. Dat doet de pana interface niet

[phrancus]

en de Heisha doet het op je eigen netwerk, zonder internet.

[blb4]

Charlie_Root schreef op zaterdag 8 augustus 2026 @ 19:56:
Ik heb sinds kort de Aquarea WH-WXG12ME8 12kW en een HeishaMon besteld (en inmiddels ontvangen, dank!). Ik was alleen even benieuwd of meer mensen ook een account hebben aangemaakt via aquarea-service.panasonic.com, daar kun je het hele systeem uitlezen (als installateur), zonder dat HeishaMon nog nodig is.

Waarom heb je de HeishaMon dan besteld? Daar zal je toch een gedachte bij gehad hebben? Neem aan dat je iets wil wat je niet binnen het Panasonic Ecosysteem voor elkaar kunt krijgen.

[ Voor 8% gewijzigd door blb4 op 08-08-2026 23:19 ]

[Charlie_Root]

blb4 schreef op zaterdag 8 augustus 2026 @ 23:06:
[...]

Waarom heb je de HeishaMon dan besteld? Daar zal je toch een gedachte bij gehad hebben? Neem aan dat je iets wil wat je niet binnen het Panasonic Ecosysteem voor elkaar kunt krijgen.

Ik kende die portal niet en had HeishaMon al besteld, deze portal is blijkbaar voor installateurs maar ik kon me meteen aanmelden. Voor mij is het wel belangrijk dat het ook zonder internet werkt, dus ik ga zeker verder met HeishaMon - maar was gewoon benieuwd of andere deze portal kende.

[blb4]

Charlie_Root schreef op zondag 9 augustus 2026 @ 09:29:
[...]

Ik kende die portal niet en had HeishaMon al besteld, deze portal is blijkbaar voor installateurs maar ik kon me meteen aanmelden. Voor mij is het wel belangrijk dat het ook zonder internet werkt, dus ik ga zeker verder met HeishaMon - maar was gewoon benieuwd of andere deze portal kende.

De portal & app zijn de oplossingen binnen 't Panasonic ecosysteem en zoals zo vaak is dat idd cloud based. Je kan er best veel mee en sommige leveranciers stellen 't ook als voorwaarde voor garantieverlening. Met HeishaMon ben je idd in staat je WP lokaal te monitoren en aan te sturen.

[phrancus]

Aanvulling: het kan tegelijk. Mijn installateur kijkt mee via die portal (en kan aanpassen) en ik kan prutsen zonder internet. En ik kan ook nog via de panasonic app de wp bedienen.

Dat laatste levert weinig op aan instellingen maar áls die het doet dan werkt het instellen van de temperatuur goed.

[elgringo]

Ik heb de heishamon aan een L serie gekoppeld. De heat/cool productie en consumptie is -200watt terwijl de pomp niets doet.

Is dit een bug of een hidden feature? Ik heb versie 4.2.1

[thehog]

Zoals je ook al in github had gevraagd en ik geantwoord, je moet in de XTOPs kijken bij dit model

[Dean88?]

Eerste stappen gezet! Wat is de volgende stap?

Oké naar veel twijfelen heb ik dit weekend HeishaMon geïnstalleerd. Ik ben al een tijdje op zoek naar de juiste manier om mijn warmtepomp slim aan te sturen. Nog even de Tado warmtepomp optimizer x geprobeerd zonder tevredenheid.

Inmiddels de HeishaMon geïnstalleerd en geïntegreerd met HA (met wat hulp van Chat GTP) en de eerste twee tegels toegevoegd:



Nu op zoek naar de juiste volgende stap. Wat zouden jullie adviseren?

Doel: Mijn energie in het huis zo efficiënt mogelijk sturen met behoudt van comfort. Daarbij rekening houden met: dynamische prijzen, Thuisbatterij en toekomstige laadpaal.

Zo wil ik dat de warmtepomp voor het cv water rekening gaat houden met het weer en dynamische prijzen. Zodat hij in de winter op de goedkoopste momenten het CV water verwarmt, eventueel alvast voor verwarmt en indien nodig meer verwarmt dan nodig om zo op duurdere uren niet aan te hoeven verwarmen. Idem voor warmwater in het boilervat. Rekening houden met verbruik en alvast voorverwarmen als de stroom goedkoop is.

Ik speel met de gedachte om alles te integreren in EVCC welke draait binnen HA. Maar ik ben benieuwd hoe jullie dit zien.

[Ethirty]

Ik kom nog niet verder dan losse ideeën: dynamische vloerkoeling op basis van dauwpunt en SWW op basis van dynamische prijzen/zon opbrengst. Had ik in Homey zo voor elkaar en werkt best briljant - met name die vloerkoeling was deze zomer een uitkomst.

Ik ben nog aan het nadenken over voor- en naseizoen stoken op basis van zon/goedkope stroom en 's nachts de verwarming dan weer uit. Maar ik heb de parameters voor mezelf nog niet helder.

Tip: zorg dat je een fallback hebt als je puur op prijs gaat sturen. Ik heb door storingen ergens in een backend nu al meermaals geen warmwater gehad.

[Dean88?]

Ethirty schreef op dinsdag 8 september 2026 @ 14:33:
Ik kom nog niet verder dan losse ideeën: dynamische vloerkoeling op basis van dauwpunt en SWW op basis van dynamische prijzen/zon opbrengst. Had ik in Homey zo voor elkaar en werkt best briljant - met name die vloerkoeling was deze zomer een uitkomst.

Ik ben nog aan het nadenken over voor- en naseizoen stoken op basis van zon/goedkope stroom en 's nachts de verwarming dan weer uit. Maar ik heb de parameters voor mezelf nog niet helder.

Tip: zorg dat je een fallback hebt als je puur op prijs gaat sturen. Ik heb door storingen ergens in een backend nu al meermaals geen warmwater gehad.

Had je HeishaMon geïnstalleerd in Homey?

[Ethirty]

Nee, ik lees een boel variabelen via json uit en de rest is via api calls. Moet dat nog een keer naar mqtt omzetten. Voor zover mij bekend is/was er geen HeishaMon app voor Homey.

[Charlie_Root]

Ethirty schreef op donderdag 10 september 2026 @ 15:29:
Nee, ik lees een boel variabelen via json uit en de rest is via api calls. Moet dat nog een keer naar mqtt omzetten. Voor zover mij bekend is/was er geen HeishaMon app voor Homey.

Niet voor HeishaMon, wel voor de Panasonic zelf.

[darkseas]

Heb net een nieuwe warmtepomp (M-generatie). Bij mij is de CZ-TAW1B WiFi module aangesloten op de CN-CNT2 (red) poort. Kan ik mijn HeishaMon (groot model) hierop aansluiten en doorlussen?
Is het correct dat ik ze niet naast elkaar kan installeren? (Dus Wifi in CN-CNT2 en HeishaMon in CN-CNT?)

[BarryH]

darkseas schreef op vrijdag 18 september 2026 @ 14:27:
Heb net een nieuwe warmtepomp (M-generatie). Bij mij is de CZ-TAW1B WiFi module aangesloten op de CN-CNT2 (red) poort. Kan ik mijn HeishaMon (groot model) hierop aansluiten en doorlussen?
Is het correct dat ik ze niet naast elkaar kan installeren? (Dus Wifi in CN-CNT2 en HeishaMon in CN-CNT?)

[Afbeelding]

klopt

[thehog]

BarryH schreef op vrijdag 18 september 2026 @ 17:01:
[...]

klopt

Nou dat weet ik nog niet zo. Het zou best kunnen dat deze twee wel afzonderlijk van elkaar werken en dus de proxy mode van de heishamon niet nodig is. De handleiding van panasonic is er niet duidelijk genoeg over. Ik zou zeggen, probeer het eens.

Het gaat vooral om dat je CN-NMODE niet kan gebruiken in combinatie met de CZ-TAW1 (dan moet de heishamon op listenonly)

[ Voor 14% gewijzigd door thehog op 19-09-2026 20:29 ]

[darkseas]

thehog schreef op zaterdag 19 september 2026 @ 20:28:
[...]

Nou dat weet ik nog niet zo. Het zou best kunnen dat deze twee wel afzonderlijk van elkaar werken en dus de proxy mode van de heishamon niet nodig is. De handleiding van panasonic is er niet duidelijk genoeg over. Ik zou zeggen, probeer het eens.

Het gaat vooral om dat je CN-NMODE niet kan gebruiken in combinatie met de CZ-TAW1 (dan moet de heishamon op listenonly)

Heb 'm (HeishMon v6, grote versie) parallel aangesloten. Dus HeishaMon in CN-CNT en de WiFi-module (CZ-TAW1B) in CN-CNT2(red). Wanneer ik nu een wijziging doe (e.g. doeltemperatuur boiler) via Home Assistant, zie ik die binnen een paar seconden terug in mijn Comfort Cloud app. En ook vice versa.

[Fr33z]

Dean88? schreef op dinsdag 8 september 2026 @ 13:49:
Eerste stappen gezet! Wat is de volgende stap?

Oké naar veel twijfelen heb ik dit weekend HeishaMon geïnstalleerd. Ik ben al een tijdje op zoek naar de juiste manier om mijn warmtepomp slim aan te sturen. Nog even de Tado warmtepomp optimizer x geprobeerd zonder tevredenheid.

Inmiddels de HeishaMon geïnstalleerd en geïntegreerd met HA (met wat hulp van Chat GTP) en de eerste twee tegels toegevoegd:

[Afbeelding]

Nu op zoek naar de juiste volgende stap. Wat zouden jullie adviseren?

Doel: Mijn energie in het huis zo efficiënt mogelijk sturen met behoudt van comfort. Daarbij rekening houden met: dynamische prijzen, Thuisbatterij en toekomstige laadpaal.

Zo wil ik dat de warmtepomp voor het cv water rekening gaat houden met het weer en dynamische prijzen. Zodat hij in de winter op de goedkoopste momenten het CV water verwarmt, eventueel alvast voor verwarmt en indien nodig meer verwarmt dan nodig om zo op duurdere uren niet aan te hoeven verwarmen. Idem voor warmwater in het boilervat. Rekening houden met verbruik en alvast voorverwarmen als de stroom goedkoop is.

Ik speel met de gedachte om alles te integreren in EVCC welke draait binnen HA. Maar ik ben benieuwd hoe jullie dit zien.

hangt er van af hoe ver je wilt gaan. en van de eigenschappen van je huis en hoeveel comfort je wel/niet wilt inleveren. je zou gebruik kunnen maken van DAO (day ahead optimizer).

hoe vaak per dag moet je tapwatervat warm? als dat bij 1x blijft dan dat gewoon op een timer zetten en bijv elke dag tussen 1400-1500 doen. dan is het buiten het warmst dus beste COP en is de stroom meestal goedkoop.

voor ruimteverwarming is het moeilijker. simpel gezegd kun je doen wat ik eerder had: gewoon schemas met shiften op de stooklijn, bijv om 9.00 naar +1 of 2 en stoppen om 1700, eventueel in de dure uren tussen 1800-2100 altijd volledig uit. Het moeilijke is dat het elke dag anders is of een uur 'goedkoop' is. want stel we hebben een week zoals vorige week, er waren dagen dat de stroomprijs varieerde tussen 28 en 45ct. Normaal.is 28ct/kWh niet 'goedkoop' en dus kun je geen vaste regel maken. maar je moet tov de andere uren in een 24u-cyclus weten of het duur/goedkoop is.

ik verwacht dat 90% van de winst te halen is door gewoon paar slimme schemas/tijdsblokken te pakken. mogelijk werkt het prima, mogelijk krijg je mega overshootz en undershoots. hangt van je huis af

[BiggieByte]

Ik heb mijn Panasonic 7J op een plat dak naast mijn zolder. Ik heb al een CZ TAW module aangesloten en wil de Heishamon dus in proxy mode. Zal ik de Heishamon bij de CZ module in de warmtepomp plaatsen, of met een 5m lange kabel naar binnen en beide daar aansluiten?

[blb4]

BiggieByte schreef op donderdag 24 september 2026 @ 13:21:
Ik heb mijn Panasonic 7J op een plat dak naast mijn zolder. Ik heb al een CZ TAW module aangesloten en wil de Heishamon dus in proxy mode. Zal ik de Heishamon bij de CZ module in de warmtepomp plaatsen, of met een 5m lange kabel naar binnen en beide daar aansluiten?

Volgens mij is 't ook nogal afhankelijk wat je verder allemaal op de HeishaMon wil aansluiten (OT thermostaat, relais, 1W sensoren, ethernet ipv WIFI) en waar die kabels dan allemaal vandaan komen.

[KweNi]

Ik heb de heishamon gisteren geinstalleerd en kunnen integreren in HA.
Kan het zijn dat er een foute sensor benamingen/friendly names zijn voor TOP29, 30, 31 en 32

code:

TOP29   Z1_Heat_Curve_Target_High_Temp   55 °C
TOP30   Z1_Heat_Curve_Target_Low_Temp    33 °C
TOP31   Z1_Heat_Curve_Outside_High_Temp  15 °C
TOP32   Z1_Heat_Curve_Outside_Low_Temp   -10°C

De waardes komen overeen met:

	sensor / friendly name
TOP29	number.panasonic_heat_pump_main_z1_heat_curve_target_high_temp Aquarea Zone 1 Target water temperature at highest outside temperature on heating curve
TOP30	number.panasonic_heat_pump_main_z1_heat_curve_target_low_temp Aquarea Zone 1 Target water temperature at highest outside temperature on heating curve
TOP31	number.panasonic_heat_pump_main_z1_heat_curve_outside_high_temp Aquarea Zone 1 Outside water temperature at highest target temperature on heating curve
TOP32	number.panasonic_heat_pump_main_z1_heat_curve_outside_low_temp Aquarea Zone 1 Outside water temperature at lowest target temperature on heating curve

Het lijkt me beter om de de friendly names aan te passen:

TOP29	Aquarea Zone 1 Target water temperature at lowest outside temperature on heating curve
TOP30	Aquarea Zone 1 Target water temperature at highest outside temperature on heating curve
TOP31	Aquarea Zone 1 Outside water temperature at lowest target temperature on heating curve
TOP32	Aquarea Zone 1 Outside water temperature at highest target temperature on heating curve

TOP29 is de doeltemperatuur die hoort bij buitentemperatuur TOP32
TOP30 is de doeltemperatuur die hoort bij buitentemperatuur TOP31

[thehog]

Ja snap dat het verwarrend is. Binnen heishamon gekozen voor gewoon hoe de temps in de curve zichtbaar zijn (hoogste temp en laagste temp etc).

De friendly names in HA kloppen inderdaad niet. Stuur maar een PR naar de github repo eigenaar

[BiggieByte]

blb4 schreef op donderdag 24 september 2026 @ 15:18:
[...]

Volgens mij is 't ook nogal afhankelijk wat je verder allemaal op de HeishaMon wil aansluiten (OT thermostaat, relais, 1W sensoren, ethernet ipv WIFI) en waar die kabels dan allemaal vandaan komen.

Wat voor meerwaarde zouden die dingen hebben? Ethernet spreekt voor zich, maar de rest is mij onbekend.

[hemertje]

BiggieByte schreef op zaterdag 26 september 2026 @ 00:36:
[...]

Wat voor meerwaarde zouden die dingen hebben? Ethernet spreekt voor zich, maar de rest is mij onbekend.

Lees de start posting eens

[TimoDimo]

thehog schreef op maandag 21 juli 2025 @ 10:55:
Sun Jul 20 17:43:07 2025 (441270): Readlen: 695241, Totallen: 695168

Dat is een debugregel die er in zit en aangeeft dat de upload niet lekker is gegaan. Meer data dan zou moeten en dan breekt hij dus af. Oudere firmwares hadden hier meer last van dan nieuwere.
Beste wat je kan doen is even alleen 1 browser openen (dus niet de console log in een 2e tab) en dan even heishamon een reboot geven. Na reboot gelijk firmware doen. Meestal pakt ie hem dan wel.

Dit was gelukt vorige keer, maar nu wil ik versie v4.1.4 updaten naar de laatste versie (HeishaMon.ino.d1-v4.2.2.bin) en nu krijg ik dit in de log als ik de firmware update start:
"New firmware POST data but update not running anymore!"

En hij zit in een loop want dit bericht komt onophoudelijk als een lange stroom zo'n 70 keer per seconde. Kun je nog een keer helpen @thehog?

[Dean88?]

Ik heb de afgelopen dagen gesleuteld aan een automatisering voor het warm water. Het is nu nog een eerste automatisering geworden die enkel kijkt naar de dynamische prijzen. Later kan ik deze dan aanpassen. Flink gepuzzeld met helpers en de automatisering. Zonder ChatGTP was het niet gelukt. Onderstaan de filosofie en logica eronder. Ik heb ook nog een volledige stappenplan met alle sensoren en entiteiten voor de geïnteresseerde.

Tips, suggesties en feedback zijn altijd welkom!

Dynamische regeling tapwater Panasonic Aquarea

Doel en uitgangspunt

De regeling is ontwikkeld om het tapwater van de Panasonic Aquarea slimmer te verwarmen in combinatie met een dynamisch energiecontract. Het uitgangspunt is dat de warmtepomp zoveel mogelijk gebruikmaakt van goedkope elektriciteitsuren, zonder dat het comfort en de beschikbaarheid van warm water onnodig in gevaar komen.

Daarbij bepaalt Home Assistant wanneer het gunstig is om de boiler op temperatuur te brengen. De interne regeling van de Panasonic blijft verantwoordelijk voor het daadwerkelijke verwarmingsproces.

Werking van de regeling

Iedere dag zijn de actuele en toekomstige uurprijzen beschikbaar. De regeling kijkt naar het prijsverloop van de hele dag en bepaalt daaruit de goedkoopste uren.

De Aquarea krijgt vervolgens twee mogelijke normale instellingen:

48 °C – normale temperatuur
Tijdens de twee goedkoopste uren van de dag wordt de gewenste boilertemperatuur verhoogd naar 48 °C. Hierdoor krijgt de warmtepomp juist op die momenten de mogelijkheid om het tapwater op temperatuur te brengen.

40 °C – uitgestelde verwarming
Buiten de geselecteerde goedkope uren wordt de gewenste temperatuur tijdelijk verlaagd naar 40 °C. Hierdoor wordt voorkomen dat de Aquarea bij een beperkte temperatuurdaling direct opnieuw gaat verwarmen. De verwarming wordt daarmee zoveel mogelijk uitgesteld naar een gunstiger moment.

De keuze van de twee goedkope uren gebeurt dynamisch op basis van de werkelijke elektriciteitsprijzen. Er wordt dus niet gewerkt met vaste tijdstippen.

Comfort- en veiligheidsgrens

Naast de prijs wordt altijd gekeken naar de actuele temperatuur van het tapwater.

De kritische ondergrens is ingesteld op 35 °C. Wanneer het tapwater deze temperatuur bereikt, krijgt comfort voorrang op de prijs. De regeling zet de gewenste temperatuur dan weer op 48 °C, zodat de boiler opnieuw kan opwarmen.

Dit voorkomt dat de prijsoptimalisatie ertoe leidt dat de watertemperatuur onbeperkt verder daalt.

Logica in hoofdlijnen

Situatie	Instelling
Goedkoopste uur van de dag	48 °C
Tweede goedkoopste uur van de dag	48 °C
Tapwatertemperatuur ≤ 35 °C	48 °C
Overige uren	40 °C

De Aquarea heeft een verwarmingsdelta van circa 5 K. Bij een ingestelde doeltemperatuur van 40 °C zal de normale verwarmingscyclus daardoor pas rond 35 °C opnieuw worden geactiveerd. Hiermee sluit de technische werking aan op de gekozen ondergrens.

Filosofie

De regeling volgt daarmee drie principes:

Prijsgestuurd: energie-intensief tapwater verwarmen op de goedkoopste beschikbare momenten.

Flexibel: niet werken met vaste schakeltijden, maar iedere dag opnieuw bepalen wanneer verwarmen financieel het meest interessant is.

Comfort als ondergrens: prijsoptimalisatie mag nooit betekenen dat de boiler te ver afkoelt. Bij 35 °C krijgt beschikbaarheid van warm water voorrang.

De huidige oplossing is bewust een eerste, relatief eenvoudige versie. Een mogelijke vervolgstap is om tijdens de duurste uren daadwerkelijk een harde verwarmingsblokkade toe te passen en daarnaast rekening te houden met bijvoorbeeld voorspeld verbruik, zonnepanelen en de beschikbare energie uit de thuisbatterij.

De gekozen aanpak past bij het bredere principe van energiemanagement: verbruik verschuiven naar momenten waarop elektriciteit goedkoper of ruimer beschikbaar is.

[mar-10]

Dean88? schreef op zondag 27 september 2026 @ 15:04:
Ik heb de afgelopen dagen gesleuteld aan een automatisering voor het warm water. Het is nu nog een eerste automatisering geworden die enkel kijkt naar de dynamische prijzen. Later kan ik deze dan aanpassen. Flink gepuzzeld met helpers en de automatisering. Zonder ChatGTP was het niet gelukt. Onderstaan de filosofie en logica eronder. Ik heb ook nog een volledige stappenplan met alle sensoren en entiteiten voor de geïnteresseerde.

Tips, suggesties en feedback zijn altijd welkom!

Dynamische regeling tapwater Panasonic Aquarea

Doel en uitgangspunt

De regeling is ontwikkeld om het tapwater van de Panasonic Aquarea slimmer te verwarmen in combinatie met een dynamisch energiecontract. Het uitgangspunt is dat de warmtepomp zoveel mogelijk gebruikmaakt van goedkope elektriciteitsuren, zonder dat het comfort en de beschikbaarheid van warm water onnodig in gevaar komen.

Daarbij bepaalt Home Assistant wanneer het gunstig is om de boiler op temperatuur te brengen. De interne regeling van de Panasonic blijft verantwoordelijk voor het daadwerkelijke verwarmingsproces.

Werking van de regeling

Iedere dag zijn de actuele en toekomstige uurprijzen beschikbaar. De regeling kijkt naar het prijsverloop van de hele dag en bepaalt daaruit de goedkoopste uren.

De Aquarea krijgt vervolgens twee mogelijke normale instellingen:

48 °C – normale temperatuur
Tijdens de twee goedkoopste uren van de dag wordt de gewenste boilertemperatuur verhoogd naar 48 °C. Hierdoor krijgt de warmtepomp juist op die momenten de mogelijkheid om het tapwater op temperatuur te brengen.

40 °C – uitgestelde verwarming
Buiten de geselecteerde goedkope uren wordt de gewenste temperatuur tijdelijk verlaagd naar 40 °C. Hierdoor wordt voorkomen dat de Aquarea bij een beperkte temperatuurdaling direct opnieuw gaat verwarmen. De verwarming wordt daarmee zoveel mogelijk uitgesteld naar een gunstiger moment.

De keuze van de twee goedkope uren gebeurt dynamisch op basis van de werkelijke elektriciteitsprijzen. Er wordt dus niet gewerkt met vaste tijdstippen.

Comfort- en veiligheidsgrens

Naast de prijs wordt altijd gekeken naar de actuele temperatuur van het tapwater.

De kritische ondergrens is ingesteld op 35 °C. Wanneer het tapwater deze temperatuur bereikt, krijgt comfort voorrang op de prijs. De regeling zet de gewenste temperatuur dan weer op 48 °C, zodat de boiler opnieuw kan opwarmen.

Dit voorkomt dat de prijsoptimalisatie ertoe leidt dat de watertemperatuur onbeperkt verder daalt.

Logica in hoofdlijnen

Situatie	Instelling
Goedkoopste uur van de dag	48 °C
Tweede goedkoopste uur van de dag	48 °C
Tapwatertemperatuur ≤ 35 °C	48 °C
Overige uren	40 °C

De Aquarea heeft een verwarmingsdelta van circa 5 K. Bij een ingestelde doeltemperatuur van 40 °C zal de normale verwarmingscyclus daardoor pas rond 35 °C opnieuw worden geactiveerd. Hiermee sluit de technische werking aan op de gekozen ondergrens.

Filosofie

De regeling volgt daarmee drie principes:

Prijsgestuurd: energie-intensief tapwater verwarmen op de goedkoopste beschikbare momenten.

Flexibel: niet werken met vaste schakeltijden, maar iedere dag opnieuw bepalen wanneer verwarmen financieel het meest interessant is.

Comfort als ondergrens: prijsoptimalisatie mag nooit betekenen dat de boiler te ver afkoelt. Bij 35 °C krijgt beschikbaarheid van warm water voorrang.

De huidige oplossing is bewust een eerste, relatief eenvoudige versie. Een mogelijke vervolgstap is om tijdens de duurste uren daadwerkelijk een harde verwarmingsblokkade toe te passen en daarnaast rekening te houden met bijvoorbeeld voorspeld verbruik, zonnepanelen en de beschikbare energie uit de thuisbatterij.

De gekozen aanpak past bij het bredere principe van energiemanagement: verbruik verschuiven naar momenten waarop elektriciteit goedkoper of ruimer beschikbaar is.

Twee vraagjes: hoe vaak verwarm jij SWW? Ik bijvoorbeeld maar één keer per dag.

En je weet dat je SWW ook kunt afschakelen? Als je SWW dan activeert, gaat de WP direct SWW verwarmen als de tanktemperatuur lager dan de instelling is. De hysterese van 8 graden is enkel van toepassing als SWW in het rooster actief is en de tanktemperatuur daalt.

Ik heb mijn SWW altijd op 14 uur aan. De hogere COP bij hogere buitentemperatuur is ook wat waard . Als automatisering heb ik toegevoegd dat de WP met SWW start als de afvoer tijdens verwarmen op 3 graden boven target komt en het tussen 12 en 14 uur is. Daarmee bespaar ik een compressorstart. En optimaliseer ik ook op zonnestroom

[Dean88?]

mar-10 schreef op zondag 27 september 2026 @ 16:23:
[...]

Twee vraagjes: hoe vaak verwarm jij SWW? Ik bijvoorbeeld maar één keer per dag.

En je weet dat je SWW ook kunt afschakelen? Als je SWW dan activeert, gaat de WP direct SWW verwarmen als de tanktemperatuur lager dan de instelling is. De hysterese van 8 graden is enkel van toepassing als SWW in het rooster actief is en de tanktemperatuur daalt.

Ik heb mijn SWW altijd op 14 uur aan. De hogere COP bij hogere buitentemperatuur is ook wat waard . Als automatisering heb ik toegevoegd dat de WP met SWW start als de afvoer tijdens verwarmen op 3 graden boven target komt en het tussen 12 en 14 uur is. Daarmee bespaar ik een compressorstart. En optimaliseer ik ook op zonnestroom

In deze automatisering in de basis ook maar 1 keer per dag. Het goedkoopste uur van de dag.
Met met nog een extra optie dat hij in het tweede goedkoopste uur van de dag nogmaals kijkt of hij kan verwarmen. Ik merk dat ik eigenlijk niet red om maar 1 keer te verwarmen per dag.

Als voorbeeld: om 13.00 uur wordt het water verwarmt. Om 14.00 uur doucht vrouwlief. Als ik vervolgens om 19.00 uur douche komt het water onder de grens en gaat de WP alsnog warmwater maken op het duurste moment. In dit geval heb ik liever dat hij om 14.00 uur nogmaals het water naar de gewenste temperatuur brengt.

De laagste waarde die ik kan instellen in HeishaMon is 40 graden. Dus met de Delta = 5 K. Is 35 graden nu de ondergrens. Zet jij in jou situatie het dan helemaal uit? Tot welke tempratuur zakt het water dan?

In de volgende fase van deze automatisering wil ik weersvoorspelling, zonne-energie en verbruik verder meenemen.

[mar-10]

Dean88? schreef op maandag 28 september 2026 @ 08:18:
[...]

In deze automatisering in de basis ook maar 1 keer per dag. Het goedkoopste uur van de dag.
Met met nog een extra optie dat hij in het tweede goedkoopste uur van de dag nogmaals kijkt of hij kan verwarmen. Ik merk dat ik eigenlijk niet red om maar 1 keer te verwarmen per dag.

Als voorbeeld: om 13.00 uur wordt het water verwarmt. Om 14.00 uur doucht vrouwlief. Als ik vervolgens om 19.00 uur douche komt het water onder de grens en gaat de WP alsnog warmwater maken op het duurste moment. In dit geval heb ik liever dat hij om 14.00 uur nogmaals het water naar de gewenste temperatuur brengt.

De laagste waarde die ik kan instellen in HeishaMon is 40 graden. Dus met de Delta = 5 K. Is 35 graden nu de ondergrens. Zet jij in jou situatie het dan helemaal uit? Tot welke tempratuur zakt het water dan?

In de volgende fase van deze automatisering wil ik weersvoorspelling, zonne-energie en verbruik verder meenemen.

offtopic:
We gaan denk ik een beetje offtopic:

hoe groot is jouw SWW-boilervat? Heb je het waterverbruik van de douche gemeten? Hoe lang wordt er gedouchd? En op welke hoogte van het vat zit de temperatuursensor? En weet je toevallig of de spiraal door het hele vat loopt of alleen onderin zit?
Als alternatief: weet je hoeveel warmte je per run in het SWW-vat stopt?

Mijn situatie is: 200 liter vat, reguliere doeltemperatuur 40 graden (in de praktijk bovenin het vat bijna 50 graden) (gisteren doeltemperatuur op 65 ivm tariefverschil ), spaarkop met 8 liter per minuut, ongeveer 15 minuten per dag douchen --> verbruik van 100 a 120 liter SWW op een dag. De sensor zit op ongeveer 1/3e van de hoogte en geeft 20 graden (in de winter 10) aan, maar er zit nog genoeg reserve in het vat. Dit komt trouwens redelijk overeen met de 3,5 a 4 kWh die ik dagelijks in het vat stop.

Spiraal door het hele vat is vrij standaard (ik heb het ook), maar eigenlijk niet optimaal. Als je gaat verwarmen en als er bovenin het vat nog warm water zit, dan wordt de warmte eerst van boven naar beneden herverdeeld en dan pas het hele vat verwarmd.

Maar goed: Ik gok dat je te vaak SWW opwarmt. Als het vat nog veel warm water bevat, heb je stiekem een slechtere COP dan als het vat bijna leeg is. En je runs zullen ook betrekkelijk kort zijn.

[ Voor 7% gewijzigd door mar-10 op 28-09-2026 10:08 ]

[Dean88?]

Interessant, ga ik eens verder in verdiepen. Hier staat een 300 liter vat en de sensor zit vrij hoog. zeg 2/3de. Verbruik niet echt bekend, ga ik eens nakijken.

Wat betreft de laatste zin: voor de verwarming heb ik altijd aangenomen dat de WP liefst niet een te groot verschil wil hebben tussen aanvoer en retour. Is dat voor warm water anders?

[mar-10]

Dean88? schreef op maandag 28 september 2026 @ 12:57:
Interessant, ga ik eens verder in verdiepen. Hier staat een 300 liter vat en de sensor zit vrij hoog. zeg 2/3de. Verbruik niet echt bekend, ga ik eens nakijken.

Wat betreft de laatste zin: voor de verwarming heb ik altijd aangenomen dat de WP liefst niet een te groot verschil wil hebben tussen aanvoer en retour. Is dat voor warm water anders?

offtopic:
Als je sensor zo hoog zit, dan kan het zijn dat je niet het hele vat verwarmd. Kun je hem lager plaatsen?

De grap met SWW is dat minder vaak opwarmen een iets hogere COP zal geven. Stel je hebt een 200 liter vat en gebruikt dagelijks 100 liter uit het vat. De doeltemperatuur is 40 graden, het waterbedrijf levert 20 graden (zomer).
Na één dag zou (bij perfecte gelaagdheid) de onderste helft 20 graden zijn, de bovenste helft 40 graden. Gemiddeld dus 30 graden. Als je gaat verwarmen, dan breng je het vat van 30 naar 40 graden.
Na twee dagen zou het vat 'leeg' zijn en is het gehele vat 20 graden. Als je gaat verwarmen, dan breng je het vat van 20 naar 40 graden. Omdat de COP in het bereik tussen 20 en 30 hoger is, pak je een beetje winst. Orde 10%.
Deze cijfers passen redelijk bij mijn situatie, maar ik doe het toch niet: gelaagdheid is niet perfect. Als eega als tweede op dag 2 doucht, wordt er gemopperd. En als er een extra douchebeurt is vanwege sporten of vies kind, dan hang ik ook. Comfort is ook belangrijk.

[xoror]

[edit] 3 testers gevonden.

[ Voor 113% gewijzigd door xoror op 29-09-2026 09:02 ]

[SpikeHome]

xoror schreef op maandag 28 september 2026 @ 17:03:
ODIN: MPC-optimizer voor HeishaMon (testers gezocht)

Ik heb dit met @thehog afgestemd en post het daarom in deze thread.

Even kort wie ik ben: ik ben de auteur van Asgard voor Mitsubishi Electric warmtepompen (esphome-ecodan-hp) en van ODIN (gekkekoe.github.io/heatpump-optimizer), een warmtepomp-optimizer die inmiddels draait bij een groep Mitsubishi-gebruikers. Nu breid ik ODIN uit naar HeishaMon + Panasonic Aquarea. Die route kan ik zelf niet op een echte installatie testen, en daarom deze oproep.

Wat doet ODIN?
ODIN is een Model Predictive Control (MPC)-engine die lokaal op eigen hardware draait en elk uur een nieuw 48-uursplan maakt voor verwarming, koeling en warm water. Geen timer en geen standaardprofiel, maar een natuurkundig model van jouw huis. Warmteverlies, thermische massa en passieve zonnewinst leert ODIN uit je eigen meetdata, en het model corrigeert zichzelf door de seizoenen heen.

Het plan weegt dynamische stroomprijzen, zon- en weersvoorspelling tegen dat model en kiest de goedkoopste volgorde van uren, altijd binnen jouw comfortband (bijvoorbeeld 20,5–22,5 °C). Eén keer instellen en je hoeft er daarna niet meer naar om te kijken.

Waarom HeishaMon-gebruikers?
De Aquarea leent zich goed voor MPC: via MQTT is alles uit te lezen én aan te sturen, dus ODIN kan direct reageren op elk prijs- of zonuur in plaats van te wachten op een stooklijn. Concreet:

• Verwarming schuift van dure avondpieken naar goedkope (nacht)uren, binnen jouw comfortband;
• Met PV draait de pomp bij voorkeur in zonvensters;
• Warm water wordt in het goedkoopste uur van de dag opgewarmd, vóórdat de naverwarmer nodig is;
• Alles is 100% lokaal: geen cloud, geen account, geen abonnement, en je data blijft in huis.

Disclaimer
Op Mitsubishi/Ecodan is ODIN al in gebruik. De HeishaMon-route is nog niet op een echte Aquarea getest. De MQTT-kant is geschreven (sensoren, commando's, verwarm-, koel- en DHW-modes, en legionellabeveiliging via het ingebouwde sterilisatieprogramma van de pomp), maar de mapping moet zich in de praktijk nog bewijzen.

Ik zoek daarom gebruikers (max: 3) die dit samen met mij scherp willen krijgen: laat ODIN draaien en deel af en toe een debug-dump, zodat ik model en planning kan kalibreren.

Wat heb je nodig?

• Een Aquarea met HeishaMon, waarbij MQTT beschikbaar is op je lokale netwerk;
• Bij voorkeur een dynamisch stroomcontract (bij een vast contract maakt ODIN het vooral comfortabeler, niet per se goedkoper);
• Bereidheid om feedback te geven op github.

Interesse of nieuwsgierig? Stuur gerust een bericht. Meer achtergrond vind je op gekkekoe.github.io/heatpump-optimizer en in de GitHub-repo.

Hier nog een screenshot van Odin:
[Afbeelding]

Klinkt interessant.

Wil minder ermee bezig zijn om alles te regelen.

[hemertje]

xoror schreef op maandag 28 september 2026 @ 17:03:
ODIN: MPC-optimizer voor HeishaMon (testers gezocht)

Ik heb dit met @thehog afgestemd en post het daarom in deze thread.

Even kort wie ik ben: ik ben de auteur van Asgard voor Mitsubishi Electric warmtepompen (esphome-ecodan-hp) en van ODIN (gekkekoe.github.io/heatpump-optimizer), een warmtepomp-optimizer die inmiddels draait bij een groep Mitsubishi-gebruikers. Nu breid ik ODIN uit naar HeishaMon + Panasonic Aquarea. Die route kan ik zelf niet op een echte installatie testen, en daarom deze oproep.

Wat doet ODIN?
ODIN is een Model Predictive Control (MPC)-engine die lokaal op eigen hardware draait en elk uur een nieuw 48-uursplan maakt voor verwarming, koeling en warm water. Geen timer en geen standaardprofiel, maar een natuurkundig model van jouw huis. Warmteverlies, thermische massa en passieve zonnewinst leert ODIN uit je eigen meetdata, en het model corrigeert zichzelf door de seizoenen heen.

Het plan weegt dynamische stroomprijzen, zon- en weersvoorspelling tegen dat model en kiest de goedkoopste volgorde van uren, altijd binnen jouw comfortband (bijvoorbeeld 20,5–22,5 °C). Eén keer instellen en je hoeft er daarna niet meer naar om te kijken.

Waarom HeishaMon-gebruikers?
De Aquarea leent zich goed voor MPC: via MQTT is alles uit te lezen én aan te sturen, dus ODIN kan direct reageren op elk prijs- of zonuur in plaats van te wachten op een stooklijn. Concreet:

• Verwarming schuift van dure avondpieken naar goedkope (nacht)uren, binnen jouw comfortband;
• Met PV draait de pomp bij voorkeur in zonvensters;
• Warm water wordt in het goedkoopste uur van de dag opgewarmd, vóórdat de naverwarmer nodig is;
• Alles is 100% lokaal: geen cloud, geen account, geen abonnement, en je data blijft in huis.

Disclaimer
Op Mitsubishi/Ecodan is ODIN al in gebruik. De HeishaMon-route is nog niet op een echte Aquarea getest. De MQTT-kant is geschreven (sensoren, commando's, verwarm-, koel- en DHW-modes, en legionellabeveiliging via het ingebouwde sterilisatieprogramma van de pomp), maar de mapping moet zich in de praktijk nog bewijzen.

Ik zoek daarom gebruikers (max: 3) die dit samen met mij scherp willen krijgen: laat ODIN draaien en deel af en toe een debug-dump, zodat ik model en planning kan kalibreren.

Wat heb je nodig?

• Een Aquarea met HeishaMon, waarbij MQTT beschikbaar is op je lokale netwerk;
• Bij voorkeur een dynamisch stroomcontract (bij een vast contract maakt ODIN het vooral comfortabeler, niet per se goedkoper);
• Bereidheid om feedback te geven op github.

Interesse of nieuwsgierig? Stuur gerust een bericht. Meer achtergrond vind je op gekkekoe.github.io/heatpump-optimizer en in de GitHub-repo.

Hier nog een screenshot van Odin:
[Afbeelding]

Hoi @xoror

mooi project heb je opgezet!

ken je deze projecten al?

Algemeen:
Heishamon <> Node Red voor Panasonic warmtepompen

Panasonic specifiek:
Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

Zou mooi zijn als je denk en werkwijze breed geimplmenteerd wordt!

[hemertje]

xoror schreef op maandag 28 september 2026 @ 17:03:
ODIN: MPC-optimizer voor HeishaMon (testers gezocht)

Ik heb dit met @thehog afgestemd en post het daarom in deze thread.

Even kort wie ik ben: ik ben de auteur van Asgard voor Mitsubishi Electric warmtepompen (esphome-ecodan-hp) en van ODIN (gekkekoe.github.io/heatpump-optimizer), een warmtepomp-optimizer die inmiddels draait bij een groep Mitsubishi-gebruikers. Nu breid ik ODIN uit naar HeishaMon + Panasonic Aquarea. Die route kan ik zelf niet op een echte installatie testen, en daarom deze oproep.

Wat doet ODIN?
ODIN is een Model Predictive Control (MPC)-engine die lokaal op eigen hardware draait en elk uur een nieuw 48-uursplan maakt voor verwarming, koeling en warm water. Geen timer en geen standaardprofiel, maar een natuurkundig model van jouw huis. Warmteverlies, thermische massa en passieve zonnewinst leert ODIN uit je eigen meetdata, en het model corrigeert zichzelf door de seizoenen heen.

Het plan weegt dynamische stroomprijzen, zon- en weersvoorspelling tegen dat model en kiest de goedkoopste volgorde van uren, altijd binnen jouw comfortband (bijvoorbeeld 20,5–22,5 °C). Eén keer instellen en je hoeft er daarna niet meer naar om te kijken.

Waarom HeishaMon-gebruikers?
De Aquarea leent zich goed voor MPC: via MQTT is alles uit te lezen én aan te sturen, dus ODIN kan direct reageren op elk prijs- of zonuur in plaats van te wachten op een stooklijn. Concreet:

• Verwarming schuift van dure avondpieken naar goedkope (nacht)uren, binnen jouw comfortband;
• Met PV draait de pomp bij voorkeur in zonvensters;
• Warm water wordt in het goedkoopste uur van de dag opgewarmd, vóórdat de naverwarmer nodig is;
• Alles is 100% lokaal: geen cloud, geen account, geen abonnement, en je data blijft in huis.

Disclaimer
Op Mitsubishi/Ecodan is ODIN al in gebruik. De HeishaMon-route is nog niet op een echte Aquarea getest. De MQTT-kant is geschreven (sensoren, commando's, verwarm-, koel- en DHW-modes, en legionellabeveiliging via het ingebouwde sterilisatieprogramma van de pomp), maar de mapping moet zich in de praktijk nog bewijzen.

Ik zoek daarom gebruikers (max: 3) die dit samen met mij scherp willen krijgen: laat ODIN draaien en deel af en toe een debug-dump, zodat ik model en planning kan kalibreren.

Wat heb je nodig?

• Een Aquarea met HeishaMon, waarbij MQTT beschikbaar is op je lokale netwerk;
• Bij voorkeur een dynamisch stroomcontract (bij een vast contract maakt ODIN het vooral comfortabeler, niet per se goedkoper);
• Bereidheid om feedback te geven op github.

Interesse of nieuwsgierig? Stuur gerust een bericht. Meer achtergrond vind je op gekkekoe.github.io/heatpump-optimizer en in de GitHub-repo.

Hier nog een screenshot van Odin:
[Afbeelding]

maar nooit geweten dat Tweakers gebruikt werd om software te verkopen: €199

[ErikKo]

hemertje schreef op maandag 28 september 2026 @ 22:38:
[...]


maar nooit geweten dat Tweakers gebruikt werd om software te verkopen: €199

Huh, het kost €199? Daar wordt geen woord over gerept in de post.

[xoror]

Ik heb de product pagina link voor meer achtergrond info weggelaten. De bedoeling van de post was om mensen te vinden die mij willen helpen om Heishamon ondersteuning goed te krijgen in Odin. Ik heb inmiddels 3 aanmeldingen en die zullen een gratis test unit krijgen om mee te spelen.

[edterbak]

@xoror Ik heb daar wel een mening over.
Het komt mij over als een commercieel product met een duidelijk verdienmodel.
Ik sta daar duidelijk anders in gezien wat ik doe voor de community. The hog ook met een kaartje op tindy voor 20 euro...
Ik was in eerste instantie enthousiast. Maar laat maar. Ik wil niet meewerken aan een commercieel product voor een appel en een ei...

[SpikeHome]

Voor mensen die Heisamon gebruken met Homey

Check dit:

https://homey.app/nl-nl/app/nl.alexredwood.aquarea-heishamon/Panasonic-Aquarea-via-HeishaMon/test/

https://community.homey.app/t/app-panasonic-aquarea-via-heishamon/159095

Ik heb nu via Home Assist uitgezet.

En werkt het nu via Homey.
Nu nog Enphase compleet van Home Assist eraf dan kan die ook uit.

[TimoDimo]

TimoDimo schreef op zaterdag 26 september 2026 @ 20:46:
[...]

Dit was gelukt vorige keer, maar nu wil ik versie v4.1.4 updaten naar de laatste versie (HeishaMon.ino.d1-v4.2.2.bin) en nu krijg ik dit in de log als ik de firmware update start:
"New firmware POST data but update not running anymore!"

En hij zit in een loop want dit bericht komt onophoudelijk als een lange stroom zo'n 70 keer per seconde. Kun je nog een keer helpen @thehog?

Oh laat maar, @thehog. Het is inmiddels gelukt. Ik weet niet wat er mis was. Na een paar keer rebooten lukte het wel.

[thehog]

TimoDimo schreef op dinsdag 29 september 2026 @ 21:48:
[...]

Oh laat maar, @thehog. Het is inmiddels gelukt. Ik weet niet wat er mis was. Na een paar keer rebooten lukte het wel.

Dat is een bug die er al heel lang in zit en in, ik geloof 4.2.0, gefixed is. Updaten werkt daarvoor het beste met maar 1 browser actief (de uploader)

[edterbak]

thehog schreef op woensdag 30 september 2026 @ 18:39:
[...]

Dat is een bug die er al heel lang in zit en in, ik geloof 4.2.0, gefixed is. Updaten werkt daarvoor het beste met maar 1 browser actief (de uploader)

Kun je daar misschien een popup voor inbouwen. "Please close all other active browser windows showing Heishamon [Ok]"?