Heishamon <> Node Red voor Panasonic warmtepompen

[MikeyMan]

edterbak schreef op donderdag 20 november 2025 @ 18:21:
Het is al lang mogelijk.
Gebruik de scheduler...

Sterilization run plannen met deze conditie (02)
[Afbeelding]

Block: "Time since last sterelization is less than...."

Google staat vol met legionella informatie. "Legionella temperatuur".

Edit:
Er zit alleen een max op van 500 uur. Dat is ~20 dagen.
Als dat te kort is hoor ik het wel

Nice! Die had ik gemist. Dat gaat knaken schelen

[hemertje]

mbt de sterilisatie run, ik heb de eerste 5 jaar dat we de WP hebben nog nooit een gedaan
ik ben/was van mening dat in een normale woning bij dagelijks gebruik geen legionella kan ontstaan
standaard schijnt legionella toch al in het water te zitten?

heb ook ooit gelezen dat we NL zo bovenop legionella zitten en dat het in het buitenland geen issue is...
sinds dit jaar draai ik de sterilisatie 1x per week smiddags om 13u
in de zomer op zonnestroom
in de winter op 1 van de goedkoopste periodes per dag naar mijn idee

dank voor de discussie hierboven m.b.t. efficiënt sturen, dat geeft me als leek weer wat inzichten
hanteren jullie dan 1 temperatuur 24/7 en laten jullie dan de Pana het zelf uitzoeken?

@MikeyMan
Ken je DAO op te helpen sturen met Accu, WP en oa EV:
Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO ?

[hemertje]

Natrixz schreef op donderdag 20 november 2025 @ 14:55:
[...]
Daarnaast laat ik Heat gewoon zo comfortabel mogelijk zijn

wat is voor jou dan 'zo comfortabel mogelijk' @Natrixz ?

[hemertje]

ercolano schreef op donderdag 20 november 2025 @ 14:56:
[...]
Nadat vannacht mn langste run ooit (2887 minuten) afbrak door een van de 9 defrosts, begon het wel weer te kriebelen....

@ercolano hoe krijg jij zo'n lange run voor elkaar?
zie mijn eerdere screenshots
ik heb steeds runs van 1-4 uur ofzo

[MikeyMan]

@hemertje nooit heel erg in verdiept, maar volgens mij ontkom je er niet aan om verbruik (/stoken) te verplaatsen naar de tijden waarop het relatief minder nut heeft.

Comfort noem ik stabiel klimaat en stoken als we thuis/Wakker zijn. Dat past niet helemaal met de uurkoersen volgens mij.

[blb4]

hemertje schreef op donderdag 20 november 2025 @ 21:28:
sinds dit jaar draai ik de sterilisatie 1x per week smiddags om 13u
in de zomer op zonnestroom
in de winter op 1 van de goedkoopste periodes per dag naar mijn idee

Zoiets doe ik ook, 1 x per week op zaterdag om 13:00u een DHW + legionella run. Als op vrijdag 13:00u al een DHW run gedaan wordt (vanwege dan al te lage DHW temp) dan doe ik de legionellarun al op vrijdag en wordt de DHW run op zaterdag overgeslagen. Ik zou de vaste dag logica inderdaad ook helemaal kunnen loslaten met behulp van een "legionella-timer" en bij elke DHW run controleren of deze timer al expired is voor het uitvoeren van een legionellarun. (ik draai op HeishaMon rules).

dank voor de discussie hierboven m.b.t. efficiënt sturen, dat geeft me als leek weer wat inzichten
hanteren jullie dan 1 temperatuur 24/7 en laten jullie dan de Pana het zelf uitzoeken?

Ik laat de Pana helemaal niets zelf uitzoeken . Ik gebruik - tegen alle adviezen in - gedeeltelijke zoneregeling en nachtverlaging en pas de Heat Request Temperatuur constant aan op basis van WAR/CCC, Kamertemperatuurdelta PID regeling, softstart en minimaal gewenste compressorruntime.

[hemertje]

blb4 schreef op vrijdag 21 november 2025 @ 01:23:
[...]
Ik laat de Pana helemaal niets zelf uitzoeken . Ik gebruik - tegen alle adviezen in - gedeeltelijke zoneregeling en nachtverlaging en pas de Heat Request Temperatuur constant aan op basis van WAR/CCC, Kamertemperatuurdelta PID regeling, softstart en minimaal gewenste compressorruntime.
Zoiets doe ik ook,

uiteraard gebruik in Ed's Node Red ook

• WAR 15/25 en -5/30
• RTC
• Softstart met QuietMode add-on

Maar ik ben nog steeds zoekende hoe ik de minimale stooklijn kan bepalen n.a.v. de warmteverliezen voor onze woning en hoe ik lange runs op een lage frequentie kan behalen?

Hoe kan ik bv de warmteverliezen vanuit NR bepalen n.a.v. het historisch kWh-verbruik en de bijbehorende buitentemperatuur?
Zit een dergelijke functionaliteit al in NR en heb ik deze nog niet gevonden?

De minimaal gewenste compressorruntime kan je toch niet sturen, ik heb altijd begrepen dat deze door de pana kabouters bepaald wordt?

[hemertje]

edterbak schreef op donderdag 20 november 2025 @ 18:21:
Het is al lang mogelijk.
Gebruik de scheduler...

Sterilization run plannen met deze conditie (02)
[Afbeelding]

Block: "Time since last sterelization is less than...."

Google staat vol met legionella informatie. "Legionella temperatuur".

Edit:
Er zit alleen een max op van 500 uur. Dat is ~20 dagen.
Als dat te kort is hoor ik het wel

goed om te weten Ed, gelijk toegepast!
wellicht verdient de legionella run wel een uitgebreider kopje in de Settings?
met de mogelijkheid deze om de vrij instelbare X (1-31) dagen te laten draaien

een kers op de taart is helemaal wanneer RN dan ook op deze dag het goedkoopste tijdblok van laten we zeggen 4 uur analyseert en bepaald en toepast voor de legionalle run n.a.v. de Nord Pool prijzen

[hemertje]

MikeyMan schreef op donderdag 20 november 2025 @ 22:19:
@hemertje nooit heel erg in verdiept, maar volgens mij ontkom je er niet aan om verbruik (/stoken) te verplaatsen naar de tijden waarop het relatief minder nut heeft.

Comfort noem ik stabiel klimaat en stoken als we thuis/Wakker zijn. Dat past niet helemaal met de uurkoersen volgens mij.

los van de euro's hebben we ook nog de COP nav de buitentemperaturen waarop het het efficiënts verwarmen is

je kunt er op afstuderen zeg maar...

bij het DAO project zijn ze bezig dit te implementeren incl. een voorspelling in weer en dynamische prijzen
biedt naar mijn idee dus mooie kansen op dit samen met NR voor de warmtepompen in te gaan zetten

[Natrixz]

MikeyMan schreef op donderdag 20 november 2025 @ 22:19:
@hemertje nooit heel erg in verdiept, maar volgens mij ontkom je er niet aan om verbruik (/stoken) te verplaatsen naar de tijden waarop het relatief minder nut heeft.

Comfort noem ik stabiel klimaat en stoken als we thuis/Wakker zijn. Dat past niet helemaal met de uurkoersen volgens mij.

Ik doe ongeveer hetzelfde, in de nacht hoeft hij niet te stoken, dan liggen we toch warm in bed. Of iig zo min mogelijk. Dus ik heb een halve graad nacht verlaging staan, dat is bij mij de meeste nachten voldoende.
Plus dat de nacht vaak minder gunstig is om te moeten stoken vanwege de buitentemperatuur.

[ Voor 6% gewijzigd door Natrixz op 21-11-2025 09:04 ]

[MikeyMan]

hemertje schreef op vrijdag 21 november 2025 @ 08:28:
[...]


los van de euro's hebben we ook nog de COP nav de buitentemperaturen waarop het het efficiënts verwarmen is

je kunt er op afstuderen zeg maar...

bij het DAO project zijn ze bezig dit te implementeren incl. een voorspelling in weer en dynamische prijzen
biedt naar mijn idee dus mooie kansen op dit samen met NR voor de warmtepompen in te gaan zetten

Ja eens, er is een hogere COP te halen. Maar ook dat komt normaal gesproken neer op stoken in de middag

[blb4]

hemertje schreef op vrijdag 21 november 2025 @ 08:11:
[...]

Maar ik ben nog steeds zoekende hoe ik de minimale stooklijn kan bepalen n.a.v. de warmteverliezen voor onze woning en hoe ik lange runs op een lage frequentie kan behalen?

Hoe kan ik bv de warmteverliezen vanuit NR bepalen n.a.v. het historisch kWh-verbruik en de bijbehorende buitentemperatuur?
Zit een dergelijke functionaliteit al in NR en heb ik deze nog niet gevonden?

De minimaal gewenste compressorruntime kan je toch niet sturen, ik heb altijd begrepen dat deze door de pana kabouters bepaald wordt?

De WAR/CCC blijft de basis, deze zal je zo goed mogelijk moeten zien in te stellen. Dit is voor elke woning uniek (warmteverlies en afgiftesysteem zijn daarin bepalend). Dit is vaak een kwestie van gewoon uitproberen (en goed noteren wat je gedaan hebt en wat het resultaat was). Niet proberen in te stellen op zeer zonnige dagen.

De kabouters laten zich helaas niet (op die manier) sturen, belangrijkste sturing is de HRT.

[edterbak]

hemertje schreef op vrijdag 21 november 2025 @ 08:24:
[...]


goed om te weten Ed, gelijk toegepast!
wellicht verdient de legionella run wel een uitgebreider kopje in de Settings?
met de mogelijkheid deze om de vrij instelbare X (1-31) dagen te laten draaien

een kers op de taart is helemaal wanneer RN dan ook op deze dag het goedkoopste tijdblok van laten we zeggen 4 uur analyseert en bepaald en toepast voor de legionalle run n.a.v. de Nord Pool prijzen

Ik had het al aangegeven. maar misschien niet helder genoeg.

ik zal zelf geen logica bouwen om norpool prijzen te analyseren of zonneplan plugins what ever om wat te bepalen. Daar zijn andere mensen en apps veel beter in om de berekening te doen. Daar ga ik absoluut niet aan beginnen.
Ik beperk mij in deze node red flow tot het ontvangen van een trigger. Een signaal.
(Oké oké.. de P1 integratie is hier een uitzondering op. Deze functie is al wat ouder. Maar deze kan ik ook verplaatsen naar een externe plugin om in lijn te zijn met deze keuze)

Maar, de flow heeft een flinke selectie aan input nodes op de tab WP Input.
Dus je mag van mij alle apps gebruiken die je wilt om een trigger te genereren voor de node red flow. Vervolgens start de NR flow de sterelization run

[Breadrun]

@edterbak heb ik het nog niet gevonden of is het niet mogelijk om quiet mode uit te laten schakelen bij de dhw run? Mijn L-serie past quiet mode namelijk ook toe op de dhw run en die duren met dit weer wel heel lang (lees hij red het niet echt)

[blb4]

Breadrun schreef op vrijdag 21 november 2025 @ 17:02:
@edterbak heb ik het nog niet gevonden of is het niet mogelijk om quiet mode uit te laten schakelen bij de dhw run? Mijn L-serie past quiet mode namelijk ook toe op de dhw run en die duren met dit weer wel heel lang (lees hij red het niet echt)

Dit kan je denk ik sowieso via de scheduler regelen

[MikeyMan]

Breadrun schreef op vrijdag 21 november 2025 @ 17:02:
@edterbak heb ik het nog niet gevonden of is het niet mogelijk om quiet mode uit te laten schakelen bij de dhw run? Mijn L-serie past quiet mode namelijk ook toe op de dhw run en die duren met dit weer wel heel lang (lees hij red het niet echt)

Draai je altijd quiet mode dan?

[hemertje]

blb4 schreef op vrijdag 21 november 2025 @ 10:39:
[...]

De WAR/CCC blijft de basis, deze zal je zo goed mogelijk moeten zien in te stellen. Dit is voor elke woning uniek (warmteverlies en afgiftesysteem zijn daarin bepalend). Dit is vaak een kwestie van gewoon uitproberen (en goed noteren wat je gedaan hebt en wat het resultaat was). Niet proberen in te stellen op zeer zonnige dagen.

De kabouters laten zich helaas niet (op die manier) sturen, belangrijkste sturing is de HRT.

HRT?

[blb4]

hemertje schreef op vrijdag 21 november 2025 @ 19:11:
[...]


HRT?

Heat Request Temperature

[hemertje]

blb4 schreef op vrijdag 21 november 2025 @ 19:30:
[...]

Heat Request Temperature

is dat de 'Calculated new setpoint: XX °C' ?

[hemertje]

ik zag vandaag met het mooie open weer dat de zonnepanelen flink produceerden
ik bedacht me dat een functie als 'Solar² RTC – Room Temperature Correction' vergelijkbaar met de Solar²DHW een mooie toevoeging is, met de werking:

kamertemperatuur-setpoint dynamisch corrigeert (verhoogt) op basis van:
1. MQTT topics:
- P1 meter energie export: sensor.tibber_pulse_hemertje_power
- Kamertemp: zigbee2mqtt/temperatuur.sensor.woonkamer
- Setpoint: flow.z1_setpoint (context var)

2. Logica:
- Actief bij P1 meter energie export > -500W, tussen 10:00-17:00
- Correctie: +1°C per 500W (max +2°C)
- Max setpoint: 22°C

3. Output:
- MQTT: panasonic_heat_pump/commands/SetZ1HeatRequestTemperature
- Dashboard: switch "Solar RTC Active"

4. Failsafe:
- Terugval na 5 min geen P1 meter energie export
- Hysterese: 500W aan, 100W uit

Ik heb LLM deze eens laten genereren 'solar_rtc_flow.json'

[
{
"id": "solar_rtc_tab",
"type": "tab",
"label": "Own WP Sensors",
"disabled": false,
"info": "Solar² RTC - Room Temperature Correction\nDynamische setpoint correctie op basis van PV-overschot"
},
{
"id": "mqtt_p1_export",
"type": "mqtt in",
"z": "solar_rtc_tab",
"name": "P1 Export Power",
"topic": "sensor.tibber_pulse_hemertje_power",
"qos": "0",
"datatype": "auto",
"broker": "",
"nl": false,
"rap": true,
"rh": 0,
"inputs": 0,
"x": 130,
"y": 100,
"wires": [
[
"parse_p1_power"
]
]
},
{
"id": "mqtt_room_temp",
"type": "mqtt in",
"z": "solar_rtc_tab",
"name": "Woonkamer Temp",
"topic": "zigbee2mqtt/temperatuur.sensor.woonkamer",
"qos": "0",
"datatype": "auto",
"broker": "",
"nl": false,
"rap": true,
"rh": 0,
"inputs": 0,
"x": 140,
"y": 180,
"wires": [
[
"parse_room_temp"
]
]
},
{
"id": "parse_p1_power",
"type": "function",
"z": "solar_rtc_tab",
"name": "Parse P1 Power",
"func": "// Parse P1 meter power export value\nlet power = 0;\n\nif (typeof msg.payload === 'string') {\n try {\n const json = JSON.parse(msg.payload);\n power = parseFloat(json.power || json.value || json.state || 0);\n } catch (e) {\n power = parseFloat(msg.payload);\n }\n} else if (typeof msg.payload === 'number') {\n power = msg.payload;\n} else if (typeof msg.payload === 'object' && msg.payload !== null) {\n power = parseFloat(msg.payload.power || msg.payload.value || msg.payload.state || 0);\n}\n\n// Store in flow context\nflow.set('p1_export_power', power);\nflow.set('p1_last_update', Date.now());\n\nmsg.payload = power;\nreturn msg;",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 350,
"y": 100,
"wires": [
[
"solar_rtc_logic",
"debug_p1_power"
]
]
},
{
"id": "parse_room_temp",
"type": "function",
"z": "solar_rtc_tab",
"name": "Parse Room Temp",
"func": "// Parse Zigbee2MQTT temperature sensor\nlet temp = 0;\n\nif (typeof msg.payload === 'string') {\n try {\n const json = JSON.parse(msg.payload);\n temp = parseFloat(json.temperature || json.value || json.state || 0);\n } catch (e) {\n temp = parseFloat(msg.payload);\n }\n} else if (typeof msg.payload === 'number') {\n temp = msg.payload;\n} else if (typeof msg.payload === 'object' && msg.payload !== null) {\n temp = parseFloat(msg.payload.temperature || msg.payload.value || msg.payload.state || 0);\n}\n\n// Store in flow context\nflow.set('room_temperature', temp);\n\nmsg.payload = temp;\nreturn msg;",
"outputs": 1,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 360,
"y": 180,
"wires": [
[
"solar_rtc_logic",
"debug_room_temp"
]
]
},
{
"id": "solar_rtc_logic",
"type": "function",
"z": "solar_rtc_tab",
"name": "Solar² RTC Logic",
"func": "// ===== CONFIGURATIE =====\nconst CONFIG = {\n // Drempels (negatieve waarden = export)\n on_threshold: -500, // W export om in te schakelen\n off_threshold: -100, // W export om uit te schakelen\n \n // Correctie parameters\n correction_per_watt: 1 / 500, // +1°C per 500W\n max_correction: 2, // Max +2°C\n max_setpoint: 22, // Absolute max setpoint\n \n // Tijdvenster\n time_start: 10, // uur (10:00)\n time_end: 17, // uur (17:00)\n \n // Failsafe\n timeout_ms: 5 * 60 * 1000 // 5 minuten\n};\n\n// ===== INITIALISATIE =====\nlet state = flow.get('solar_rtc_state') || {\n active: false,\n last_active: 0,\n corrected_setpoint: null\n};\n\n// ===== DATA OPHALEN =====\nconst p1_power = flow.get('p1_export_power') || 0;\nconst p1_last_update = flow.get('p1_last_update') || 0;\nconst room_temp = flow.get('room_temperature') || 20;\nconst base_setpoint = flow.get('z1_setpoint') || 21;\n\nconst now = Date.now();\nconst current_hour = new Date().getHours();\n\n// ===== FAILSAFE CHECK =====\nconst data_timeout = (now - p1_last_update) > CONFIG.timeout_ms;\n\nif (data_timeout && state.active) {\n node.warn('⚠️ P1 data timeout - deactivating Solar RTC');\n state.active = false;\n}\n\n// ===== TIJDVENSTER CHECK =====\nconst in_time_window = (current_hour >= CONFIG.time_start && current_hour < CONFIG.time_end);\n\nif (!in_time_window && state.active) {\n node.status({fill: \"yellow\", shape: \"ring\", text: \"buiten tijdvenster\"});\n state.active = false;\n}\n\n// ===== HYSTERESE LOGICA =====\n// P1 power is negatief bij export, dus we vergelijken met negatieve drempels\nif (!state.active && p1_power <= CONFIG.on_threshold && in_time_window && !data_timeout) {\n state.active = true;\n state.last_active = now;\n node.warn(`✅ Solar RTC geactiveerd (export: ${Math.abs(p1_power)}W)`);\n}\n\nif (state.active && p1_power >= CONFIG.off_threshold) {\n state.active = false;\n node.warn(`❌ Solar RTC gedeactiveerd (export: ${Math.abs(p1_power)}W)`);\n}\n\n// ===== SETPOINT BEREKENING =====\nlet new_setpoint = base_setpoint;\n\nif (state.active) {\n // Bereken correctie op basis van export (negatieve waarde)\n const export_power = Math.abs(p1_power);\n const correction = Math.min(\n export_power * CONFIG.correction_per_watt,\n CONFIG.max_correction\n );\n \n new_setpoint = Math.min(\n base_setpoint + correction,\n CONFIG.max_setpoint\n );\n \n // Rond af op 0.5°C\n new_setpoint = Math.round(new_setpoint * 2) / 2;\n \n node.status({\n fill: \"green\",\n shape: \"dot\",\n text: `ACTIEF | Export: ${export_power}W | Correctie: +${correction.toFixed(1)}°C | Setpoint: ${new_setpoint}°C`\n });\n} else {\n node.status({\n fill: \"grey\",\n shape: \"ring\",\n text: `INACTIEF | Export: ${Math.abs(p1_power)}W | Basis: ${base_setpoint}°C`\n });\n}\n\n// ===== STATE OPSLAAN =====\nstate.corrected_setpoint = new_setpoint;\nflow.set('solar_rtc_state', state);\nflow.set('solar_rtc_corrected_setpoint', new_setpoint);\n\n// ===== OUTPUT =====\nreturn [\n // Output 1: MQTT command (alleen bij wijziging)\n {\n payload: new_setpoint.toString(),\n topic: 'panasonic_heat_pump/commands/SetZ1HeatRequestTemperature'\n },\n // Output 2: Dashboard status\n {\n payload: state.active,\n topic: 'solar_rtc_active'\n },\n // Output 3: Debug info\n {\n payload: {\n active: state.active,\n p1_export: p1_power,\n room_temp: room_temp,\n base_setpoint: base_setpoint,\n corrected_setpoint: new_setpoint,\n in_time_window: in_time_window,\n data_timeout: data_timeout\n }\n }\n];",
"outputs": 3,
"noerr": 0,
"initialize": "",
"finalize": "",
"libs": [],
"x": 600,
"y": 140,
"wires": [
[
"mqtt_setpoint_out",
"debug_setpoint"
],
[
"ui_switch_active"
],
[
"debug_solar_rtc"
]
]
},
{
"id": "mqtt_setpoint_out",
"type": "mqtt out",
"z": "solar_rtc_tab",
"name": "Set Z1 Setpoint",
"topic": "",
"qos": "0",
"retain": "false",
"respTopic": "",
"contentType": "",
"userProps": "",
"correl": "",
"expiry": "",
"broker": "",
"x": 870,
"y": 100,
"wires": []
},
{
"id": "ui_switch_active",
"type": "ui_switch",
"z": "solar_rtc_tab",
"name": "Solar RTC Active",
"label": "Solar² RTC",
"tooltip": "Room Temperature Correction actief",
"group": "",
"order": 1,
"width": 0,
"height": 0,
"passthru": false,
"decouple": "true",
"topic": "solar_rtc_active",
"topicType": "msg",
"style": "",
"onvalue": "true",
"onvalueType": "bool",
"onicon": "fa-sun-o",
"oncolor": "green",
"offvalue": "false",
"offvalueType": "bool",
"officon": "fa-moon-o",
"offcolor": "grey",
"animate": false,
"className": "",
"x": 880,
"y": 140,
"wires": [
[]
]
},
{
"id": "debug_p1_power",
"type": "debug",
"z": "solar_rtc_tab",
"name": "P1 Power",
"active": false,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"statusVal": "",
"statusType": "auto",
"x": 570,
"y": 60,
"wires": []
},
{
"id": "debug_room_temp",
"type": "debug",
"z": "solar_rtc_tab",
"name": "Room Temp",
"active": false,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"statusVal": "",
"statusType": "auto",
"x": 580,
"y": 220,
"wires": []
},
{
"id": "debug_setpoint",
"type": "debug",
"z": "solar_rtc_tab",
"name": "Setpoint Out",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"statusVal": "",
"statusType": "auto",
"x": 880,
"y": 60,
"wires": []
},
{
"id": "debug_solar_rtc",
"type": "debug",
"z": "solar_rtc_tab",
"name": "Solar RTC Debug",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "payload",
"targetType": "msg",
"statusVal": "",
"statusType": "auto",
"x": 890,
"y": 180,
"wires": []
},
{
"id": "inject_trigger",
"type": "inject",
"z": "solar_rtc_tab",
"name": "Manual Trigger",
"props": [
{
"p": "payload"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "trigger",
"payloadType": "str",
"x": 370,
"y": 260,
"wires": [
[
"solar_rtc_logic"
]
]
},
{
"id": "comment_header",
"type": "comment",
"z": "solar_rtc_tab",
"name": "Solar² RTC - Room Temperature Correction | Dynamische setpoint correctie op basis van PV-export",
"info": "# Solar² RTC - Room Temperature Correction\n\n## Functionaliteit\n- Verhoogt Z1 setpoint bij PV-export overschot\n- Hysterese: 500W aan / 100W uit\n- Correctie: +1°C per 500W export (max +2°C)\n- Max setpoint: 22°C\n- Actief: 10:00-17:00\n- Failsafe: terugval na 5 min geen data\n\n## Inputs\n- P1 meter: sensor.tibber_pulse_hemertje_power\n- Kamertemp: zigbee2mqtt/temperatuur.sensor.woonkamer\n- Basis setpoint: flow.z1_setpoint\n\n## Output\n- MQTT: panasonic_heat_pump/commands/SetZ1HeatRequestTemperature\n- Dashboard: Solar RTC Active switch\n\n## Configuratie\nAlle parameters aanpasbaar in Solar² RTC Logic function node.",
"x": 380,
"y": 20,
"wires": []
}
]

Functionaliteit
Tab:
"Own WP Sensors" met Solar² RTC functie

Inputs:
P1 meter export: sensor.tibber_pulse_hemertje_power
Kamertemp: zigbee2mqtt/temperatuur.sensor.woonkamer
Basis setpoint: flow.z1_setpoint

Logica:
Actief bij export > 500W (hysterese: uit bij < 100W)
Correctie: +1°C per 500W export (max +2°C)
Max setpoint: 22°C
Tijdvenster: 10:00–17:00
Failsafe: terugval na 5 min geen data

Output:
MQTT: panasonic_heat_pump/commands/SetZ1HeatRequestTemperature
Dashboard switch: "Solar² RTC Active"

Willen jullie eens meedenken of dit kans van slagen heeft en of de Node Red code klopt?

[Breadrun]

MikeyMan schreef op vrijdag 21 november 2025 @ 18:59:
[...]


Draai je altijd quiet mode dan?

Ja ik had hem op twee staan en dat loopt als een zonnetje. Is hier goed geïsoleerd en hij pruttelt rustig tussen de 16 en 25hz altijd. Maar hij is dan gelimiteerd rond de 35hz dus dat gaat niet goed met de dhw runs dan.

[Breadrun]

hemertje schreef op vrijdag 21 november 2025 @ 20:53:
ik zag vandaag met het mooie open weer dat de zonnepanelen flink produceerden
ik bedacht me dat een functie als 'Solar² RTC – Room Temperature Correction' vergelijkbaar met de Solar²DHW een mooie toevoeging is, met de werking:

kamertemperatuur-setpoint dynamisch corrigeert (verhoogt) op basis van:
1. MQTT topics:
- P1 meter energie export: sensor.tibber_pulse_hemertje_power
- Kamertemp: zigbee2mqtt/temperatuur.sensor.woonkamer
- Setpoint: flow.z1_setpoint (context var)

2. Logica:
- Actief bij P1 meter energie export > -500W, tussen 10:00-17:00
- Correctie: +1°C per 500W (max +2°C)
- Max setpoint: 22°C

3. Output:
- MQTT: panasonic_heat_pump/commands/SetZ1HeatRequestTemperature
- Dashboard: switch "Solar RTC Active"

4. Failsafe:
- Terugval na 5 min geen P1 meter energie export
- Hysterese: 500W aan, 100W uit

Ik heb LLM deze eens laten genereren 'solar_rtc_flow.json'


[...]


Functionaliteit
Tab:
"Own WP Sensors" met Solar² RTC functie

Inputs:
P1 meter export: sensor.tibber_pulse_hemertje_power
Kamertemp: zigbee2mqtt/temperatuur.sensor.woonkamer
Basis setpoint: flow.z1_setpoint

Logica:
Actief bij export > 500W (hysterese: uit bij < 100W)
Correctie: +1°C per 500W export (max +2°C)
Max setpoint: 22°C
Tijdvenster: 10:00–17:00
Failsafe: terugval na 5 min geen data

Output:
MQTT: panasonic_heat_pump/commands/SetZ1HeatRequestTemperature
Dashboard switch: "Solar² RTC Active"

Willen jullie eens meedenken of dit kans van slagen heeft en of de Node Red code klopt?

Het idee spreekt mij wel aan! Wij hebben een hele grote pui (16m2 triple glas) dus de warmte gaat er makkelijk in en blijft daarna lang hangen. Denk dat dit wellicht vlotter reageert dan de reguliere RTC. Hij draai hier nu vaak wel een tijd door terwijl het echt niet meer hoeft.

[MikeyMan]

Breadrun schreef op vrijdag 21 november 2025 @ 21:26:
[...]


Ja ik had hem op twee staan en dat loopt als een zonnetje. Is hier goed geïsoleerd en hij pruttelt rustig tussen de 16 en 25hz altijd. Maar hij is dan gelimiteerd rond de 35hz dus dat gaat niet goed met de dhw runs dan.

In de scheduler silent mode uit zetten vlak voor de dhw run start en weer aan als ie klaar is.

[Breadrun]

MikeyMan schreef op vrijdag 21 november 2025 @ 21:55:
[...]


In de scheduler silent mode uit zetten vlak voor de dhw run start en weer aan als ie klaar is.

Ja hij staat nu gewoon op heat+dhw maar als ik dat aanpas dan kan het op die manier. Goed idee, een run per dag zou voldoende moeten zijn.

[hemertje]

MikeyMan schreef op vrijdag 21 november 2025 @ 21:55:
[...]


In de scheduler silent mode uit zetten vlak voor de dhw run start en weer aan als ie klaar is.

Hi Mickeyman,

kaan je eens toelichten hoe je die in de scheduler dan uitzet tijdens een DHW run?

ik zag van de week dat de DHW run zomaar 4-5 uur duurde

[edterbak]

Ik heb na wat feedback hier en daar over sensoren met jitter (en de impact dat dit heeft op de Softstart-functie) wat tijd gestoken in het maken van een filter functie, samen met copilot en gezond verstand doorvragen.
Na wat vergelijken heb ik hem nu zelf in gebruik genomen voor de volgende nodes:


Het resultaat op de binnen temperatuur sensor (2) zie je hier onder.
Het gaat om de blauwe sensor. Het scheelt niet heel veel, maar de jitter is minder en de lijn is wat rustiger.


Zijn er meer mensen die het willen proberen?

• Het is een filter type "Kalman".
• Het filter is 'auto-tuning'.
• De tuning-variabelen worden in de context store "file" opgeslagen, dus per node en het overleefd herstarts.
• Het filter zou 'iets' beter moeten zijn dan het zwevende gemiddelde nemen, omdat deze sneller reageert. Maar ik verwacht geen grote impact als ik eerlijk ben.
• Bij een goede sensor zul je zien dat hij zo goed als niks doet.
• Bij een sensor met heel veel jitter, zul je zien dat hij wat gladstrijkt.

Dit is de code voor het filter.
Je kunt het importeren en gebruiken waar je wil.

code:

[
    {
        "id": "bf01688126aaf3e3",
        "type": "function",
        "z": "a938de76db0b71f6",
        "g": "5a496e1f1ea93a38",
        "name": "Filter",
        "func": "// ===== CONFIGURATION =====\nconst R_MIN = 0.02;    // Sensor jitter baseline\nconst R_MAX = 0.10;    // For noisy conditions\nconst Q_MIN = 0.003;   // Slightly more responsive than 0.001\nconst Q_MAX = 0.02;    // Allow faster adaptation with slower updates\n\nconst RESET_INTERVAL_DAYS = 3;\nconst EDGE_MARGIN = 0.05;        // 5% near edges considered extreme\nconst MAX_GAIN = 0.30;           // clamp K for smoothing\nconst HARD_RESET_DIFF = 0.7;     // re-seed if jump > 0.7°C\n\nconst SENSOR_KEY = 'sensor';\n\n// ===== LOAD CONTEXT =====\nlet sensor = context.get(SENSOR_KEY, 'file') || {\n    R: R_MIN,\n    Q: Q_MIN,\n    estimate: msg.payload,\n    errorCov: 1,\n    lastTimestamp: Date.now(),\n    lastReset: Date.now()\n};\n\nlet now = Date.now();\nlet dt = (now - sensor.lastTimestamp) / 1000;\nif (!Number.isFinite(dt) || dt < 0) dt = 0;\nsensor.lastTimestamp = now;\n\n// ===== RESET CONDITIONS (fixed) =====\nconst rLowerEdge = R_MIN + (R_MAX - R_MIN) * EDGE_MARGIN;\nconst rUpperEdge = R_MAX - (R_MAX - R_MIN) * EDGE_MARGIN;\nconst qLowerEdge = Q_MIN + (Q_MAX - Q_MIN) * EDGE_MARGIN;\nconst qUpperEdge = Q_MAX - (Q_MAX - Q_MIN) * EDGE_MARGIN;\n\nlet daysSinceReset = (now - sensor.lastReset) / (1000 * 60 * 60 * 24);\nlet extremeR = (sensor.R <= rLowerEdge) || (sensor.R >= rUpperEdge);\nlet extremeQ = (sensor.Q <= qLowerEdge) || (sensor.Q >= qUpperEdge);\nlet hardReset = Math.abs(msg.payload - sensor.estimate) > HARD_RESET_DIFF;\n\nif (daysSinceReset >= RESET_INTERVAL_DAYS || (extremeR && extremeQ) || hardReset) {\n    sensor.R = R_MIN;\n    sensor.Q = Q_MIN;\n    if (hardReset) sensor.estimate = msg.payload; // only re-seed on large jump\n    sensor.errorCov = 1;\n    sensor.lastReset = now;\n}\n\n// ===== AUTO-TUNE =====\nlet diff = Math.abs(msg.payload - sensor.estimate);\nlet diffCap = Math.min(diff, 0.2); // avoid letting spikes push R too high\nsensor.R = R_MIN + (diffCap / 0.2) * (R_MAX - R_MIN); \n\nlet intervalFactor = Math.min(Math.max(dt / 60, 0), 1); // 60s -> Q_MAX\nsensor.Q = Q_MIN + intervalFactor * (Q_MAX - Q_MIN);\n\n// ===== KALMAN FILTER =====\nlet predictedEstimate = sensor.estimate;\nlet predictedErrorCov = sensor.errorCov + sensor.Q;\n\nlet K = predictedErrorCov / (predictedErrorCov + sensor.R);\nif (K > MAX_GAIN) K = MAX_GAIN; // critical clamp\n\nsensor.estimate = predictedEstimate + K * (msg.payload - predictedEstimate);\nsensor.errorCov = (1 - K) * predictedErrorCov;\n\n// ===== SAVE CONTEXT =====\ncontext.set(SENSOR_KEY, sensor, 'file');\n\n// ===== OUTPUT =====\nmsg.payload = sensor.estimate;\nnode.status({fill:\"blue\", shape:\"dot\", text:`K=${K.toFixed(2)} R=${sensor.R.toFixed(3)} Q=${sensor.Q.toFixed(3)} est=${sensor.estimate.toFixed(2)}`});\nreturn msg;",
        "outputs": 1,
        "timeout": 0,
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 470,
        "y": 140,
        "wires": [
            [
                "f130c43288ca6830"
            ]
        ]
    }
]

Ik ben benieuwd naar jullie feedback of het uberhaupt nut heeft.

[MikeyMan]

hemertje schreef op zaterdag 22 november 2025 @ 13:30:
[...]


Hi Mickeyman,

kaan je eens toelichten hoe je die in de scheduler dan uitzet tijdens een DHW run?

ik zag van de week dat de DHW run zomaar 4-5 uur duurde

Vlak voor de dhw silent mode uit zetten en vlak erna weer aan.

[hemertje]

MikeyMan schreef op zaterdag 22 november 2025 @ 14:06:
[...]


Vlak voor de dhw silent mode uit zetten en vlak erna weer aan.

die snap ik
maar ik zie in de Scheduler bij de Actions of Conditions niet de mogelijkheid om deze te selecteren
of bedoel je handmatig aanpassen in de code?

[ercolano]

Hoi @edterbak
Ik ga het niet uitproberen, want heb zelf al iets geïmplementeerd.

Ter illustratie:
Ik heb 3 woonkamer sensoren (1 via zigbee en 2 van die simpele wemos d1 dingetjes). Deze sturen elke 3 minuten een mqtt bericht. In de flow haal ik die op en haal ze door de "Smooth" functie (https://flows.nodered.org/node/node-red-node-smooth) met als actie "perform low pass filter met factor 10.
Waarom 10 en geen 9 weet ik niet meer, maar het was toen logisch :-)
Werkt ook prima, mooie rustige sinus.

@hemertje
lange runs. Analyseren om welke reden de run stopt. Meestal Ta+2. Dan kan ie zn warmte niet kwijt. Stooklijn omhoog => meer afgifte.
Hij mag zo snel mogelijk inkakken. Een hoge pomp snelheid (vaste waarde) of een lage dT helpt dan niet, want dan blijft hij er flink warmte in pompen.

Ik draai op minimaal war van 28 (anders heb ik te weinig afgifte ) met een dT van 6 (ligt de Tr eerder in het window en toert de compressor eerder af), en var pump speed. Als het dan te koud wordt gooit de RTC er gedoseerd een graadje bij.

Je wilt ook geen combi van Td verlaging door buitentemp in combi met RTC verlaging van Td. 2 graden lager in korte tijd lukt meestal niet. Daarom de RTC correctie "slim" insteken zodat er gecombineerd nooit 2 graden verlaging plaats vind in korte tijd.

[MikeyMan]

hemertje schreef op zaterdag 22 november 2025 @ 14:46:
[...]


die snap ik
maar ik zie in de Scheduler bij de Actions of Conditions niet de mogelijkheid om deze te selecteren
of bedoel je handmatig aanpassen in de code?

Nee? quiet mode zit gewoon in de scheduling acties?

[ Voor 32% gewijzigd door MikeyMan op 23-11-2025 10:26 ]

[hemertje]

MikeyMan schreef op zondag 23 november 2025 @ 08:47:
[...]


Nee? quiet mode zit gewoon in de scheduling acties?

[Afbeelding]

ja ook gezien maar de schedulers gaan normaal op tijd, een DHW run houdt zich niet aan een vaste tijd

dus ik ben op zoek naar de mogelijkheid om deze met de conditions deze afhankelijk van de start van een een DHW run quiet mode terug naar quiet mode 0 te schakelen

of zit mijn gedachtegang helemaal verkeerd?

[MikeyMan]

hemertje schreef op zondag 23 november 2025 @ 16:35:
[...]


ja ook gezien maar de schedulers gaan normaal op tijd, een DHW run houdt zich niet aan een vaste tijd

dus ik ben op zoek naar de mogelijkheid om deze met de conditions deze afhankelijk van de start van een een DHW run quiet mode terug naar quiet mode 0 te schakelen

of zit mijn gedachtegang helemaal verkeerd?

Oh ja zo lang duurt die dhw run toch niet. Ff kijken hoe lang die duurt en iets marge nemen. Zoveel herrie maken die panas niet.

[blb4]

MikeyMan schreef op zondag 23 november 2025 @ 16:36:
[...]


Oh ja zo lang duurt die dhw run toch niet. Ff kijken hoe lang die duurt en iets marge nemen. Zoveel herrie maken die panas niet.

Kan je in de scheduler geen trigger instellen op omschakeling 3-wegklep? Ander dit ff in HA automatiseren

[MikeyMan]

blb4 schreef op zondag 23 november 2025 @ 16:56:
[...]

Kan je in de scheduler geen trigger instellen op omschakeling 3-wegklep? Ander dit ff in HA automatiseren

Ik gebruik de quiet mode alleen snachts. Maargoed, ook overdag maakt de wtw van de buren meer herrie dan mn monoblock

[blb4]

MikeyMan schreef op zondag 23 november 2025 @ 17:31:
[...]


Ik gebruik de quiet mode alleen snachts. Maargoed, ook overdag maakt de wtw van de buren meer herrie dan mn monoblock

Heb je ze al eens als hint een oliespuitje gegeven 😎?

[MikeyMan]

Haha zou niet gek zijn. Heb zelf de motoren laten reviseren. De mijne is stil

[hemertje]

MikeyMan schreef op zondag 23 november 2025 @ 16:36:
[...]


Oh ja zo lang duurt die dhw run toch niet. Ff kijken hoe lang die duurt en iets marge nemen. Zoveel herrie maken die panas niet.

de DHW run is niet tijd gestuurd maar DHW delta gestuurd
dus via de Scheduler niet te sturen naar mijn idee als leek?

[MikeyMan]

hemertje schreef op zondag 23 november 2025 @ 21:00:
[...]


de DHW run is niet tijd gestuurd maar DHW delta gestuurd
dus via de Scheduler niet te sturen naar mijn idee als leek?

Tuurlijk wel. Als je heat only draait, en je schakelt naar heat+dhw, krijg je een dhw run. Daarnaast kun je nog een minimum temp instellen als fallback. Mogelijkheden te over.

[hemertje]

MikeyMan schreef op zondag 23 november 2025 @ 21:13:
[...]
Tuurlijk wel. Als je heat only draait, en je schakelt naar heat+dhw, krijg je een dhw run. Daarnaast kun je nog een minimum temp instellen als fallback. Mogelijkheden te over.

daar had ik idd nog niet aan gedacht,
dank voor het meedenken!

[Nnoitra]

@edterbak

Heb je er wel eens aan gedacht om de Room Setpoint waarde voor RTC ook configurabel te maken?
Zodat je er onder System, Sensors, bijvoorbeeld, een thermostaat aan kunt koppelen.

Usecase:
Op een willekeurig moment vindt gezinslid X dat het toch net ff iets te koud is. Net als vroegah, bij de CV ketel, gaat de thermostaat een (halve) graad omhoog.
Als de WP al lekker doorprutteld op laaglast, zal het niet opeens (sneller) warmer gaan worden.
MAAR!! *drumm roll*, als door het (tijdelijk) verhogen van de temperatuur op de thermostaat het RTC setpoint mee omhoog gaat, kom je terecht in de RTC functionaliteit. En afhankelijk van je instellingen gaat de stooklijn dan automagisch omhoog.

Heb het zelf even quick 'n dirty er in gebutst. Kijken of dit wat werkt

[MikeyMan]

@Nnoitra dat werkt toch al zo?

[hemertje]

Onder System - Sensors kan je je MQTT sensor topics koppelen voor o.a. RTC function (Temperature)
Hierop gaat de RTC dan corrigeren



of bedoel je wat anders?

[Nnoitra]

MikeyMan schreef op woensdag 26 november 2025 @ 07:21:
@Nnoitra dat werkt toch al zo?

hemertje schreef op woensdag 26 november 2025 @ 08:42:

Die RTC waarde pakt de huidige (woonkamer) temperatuur en vergelijkt deze met de ingestelde Room setpoint
Mijn idee is om de ingestelde temperatuur, op de thermostaat, als Room setpoint te gebruiken.

[MikeyMan]

Nnoitra schreef op woensdag 26 november 2025 @ 09:41:
[...]


[...]


Die RTC waarde pakt de huidige (woonkamer) temperatuur en vergelijkt deze met de ingestelde Room setpoint
Mijn idee is om de ingestelde temperatuur, op de thermostaat, als Room setpoint te gebruiken.

Ja dat kan toch?

Daar is al een input voor.

[Nnoitra]

@edterbak
----------------------- Bugje - Flow version25.06 (! Beta 4 !) -----------------------
Ik kon in de scheduler de Toggle Action i.c.m. RTC_Z1 niet aanzetten, dan gaf ie een undefined.

In de WP Scheduler -->GET global / topics heb je dit staan:

code:

if (msg6.payload == 'toggle item') {
    var items = global.get(schedule_topic + '_toggle_item', "file");
    
    if (items !== undefined) {
        var state = items.State;
        if (state === false) {state = 'off'}
        if (state === true) { state = 'on' }
        var list;
        if (items.WAR === true)         {list = 'WAR'}
        if (items.RTC === true)         { if (list !== undefined) { list += ', RTC' } else { list = 'RTC' } }
        if (items.SoftStart === true)   { if (list !== undefined) { list += ', SoftStart' } else { list = 'SoftStart' } }
        if (items.SolarDHW === true)    { if (list !== undefined) { list += ', Solar²DHW' } else { list = 'Solar²DHW' } }
            
        msg6.tooltip = 'Turn ' + state + ': ' + list;
    }

En door je Zone2 toevoegingen is de aanvoer van data:

code:

CCC_Z1: false
CCC_Z2: false
RTC_Z1: true
RTC_Z2: false
SoftStart: false
Solar2DHW: false
State: true

Dat matcht dus niet meer met de Items.
Idem voor de WAR/CCC.

---------------------------------------------------

MikeyMan schreef op woensdag 26 november 2025 @ 09:47:
Ja dat kan toch?
Daar is al een input voor.

Ja, je hebt gelijk, het kan al. Die zit in de WP Input tab.
Mijn toevoeging is om 'm ook via de front-end, via Sensors toe te kunnen voegen.
_{Ik had die usecase txt er niet bij hoeven zetten, dat maakt het verwarrend. In my defence, het was laat}

[ Voor 20% gewijzigd door Nnoitra op 26-11-2025 10:20 ]

[ercolano]

Nnoitra schreef op woensdag 26 november 2025 @ 01:00:
...
Usecase:
Op een willekeurig moment vindt gezinslid X dat het toch net ff iets te koud is.
...

Die usecase kom ik ook tegen. En los van jou oplossing zou het prettig zijn voor medebewoners om de "room setpoint" temperatuur al op het het "home" screen te kunnen aanpassen (ipv op "rtc" tabblad). Voor computer-leken lijkt dat makkelijker ... Wellicht is die invoer te dupliceren op beide tabbladen, of wordt de gebrukersinterface daarmee te rommelig ?

Verder kan je ook de temperatuur in huis verhogen door de "final water temperature" te verhogen. Vooral handig als de thermostaat instelling op zich goed is maar de temperatuur niet of te langzaam gehaald wordt. In geval van direct-mode heb je geen shift tot je beschikking (toch ?) . Ik misbruik daar de "night reduction" optie voor, die ik heb aangepast zodat hij ook + waardes kan geven. Niet clean maar wel begrijpbaar door huisgenoten.

off-topic: ga gedwongen worden door mijn vrouw om een huishandleiding te schrijven zodat ze na de laatste kus dmv kiss het huis aan de praat kan houden ...

[MikeyMan]

@ercolano je kan willekeurig welke thermostaat met mqtt pakken. Ik had evohome, heb nu een Shelly hangen. Kan gewoon als ouderwetse thermostaat functioneren.

Als je home assistant er nog tussen hebt is de keuze helemaal reuze.

[Nnoitra]

ercolano schreef op woensdag 26 november 2025 @ 10:42:
[...]


Die usecase kom ik ook tegen. En los van jou oplossing zou het prettig zijn voor medebewoners om de "room setpoint" temperatuur al op het het "home" screen te kunnen aanpassen (ipv op "rtc" tabblad). Voor computer-leken lijkt dat makkelijker ... Wellicht is die invoer te dupliceren op beide tabbladen, of wordt de gebrukersinterface daarmee te rommelig ?

Verder kan je ook de temperatuur in huis verhogen door de "final water temperature" te verhogen. Vooral handig als de thermostaat instelling op zich goed is maar de temperatuur niet of te langzaam gehaald wordt. In geval van direct-mode heb je geen shift tot je beschikking (toch ?) . Ik misbruik daar de "night reduction" optie voor, die ik heb aangepast zodat hij ook + waardes kan geven. Niet clean maar wel begrijpbaar door huisgenoten.

off-topic: ga gedwongen worden door mijn vrouw om een huishandleiding te schrijven zodat ze na de laatste kus dmv kiss het huis aan de praat kan houden ...

Ik gebruik geen Direct-Mode, dus geen idee hoe de RTC in die situatie werkt.

Hier kun je de input voor de Room Setpoint koppelen.

Bij mij komt er nu een temperatuur waarde vanaf een Netatmo Wireless Thermostat, via HomeAssistant, binnen. Een verhoging op die thermostaat pakt Netatmo op als een "temporary boost", waardoor ie na x tijd weer terug gaat naar z'n scheduled temperatuur.

Mijn insteek mbt automatisering is dat iedere Niet-IT'er eigenlijk niets met dashboards en instellingen moet (hoeven) doen.
Het moet of autonoom werken (bv: lichten op basis van aanwezigheid/tijd/etc), of het moet met een simpele handeling/knop kunnen (bv: thermostaat +1 = sneller verwarmen, of lichtknop indrukken is licht aan/uit).

[ Voor 11% gewijzigd door Nnoitra op 26-11-2025 11:13 ]

[blb4]

MikeyMan schreef op woensdag 26 november 2025 @ 10:52:
@ercolano je kan willekeurig welke thermostaat met mqtt pakken. Ik had evohome, heb nu een Shelly hangen. Kan gewoon als ouderwetse thermostaat functioneren.

Als je home assistant er nog tussen hebt is de keuze helemaal reuze.

Dit is bij mij ook the way to go. Het moet voor 'leken' ook te bedienen blijven. Alle automatisering is prima, zolang er ook maar gewoon een thermostaat is die huisgenoten gewend zijn en die zij kunnen bedienen. Ik maak ook gebruik van Evohome (zelfs met zoneregeling) en daar kan gewoon de gewenste temperatuur worden ingesteld.

[ercolano]

Ik heb zelf een super simpele set-up zonder thermostaat. 3 sensoren die gemiddeld de flow voeden waarin zeg maar de thermostaat functie zit ingebakken. Maar, een losse thermostaat is natuurlijk veel begrijpelijker voor huisgenoten, zeker als je even wilt plussen. Ga het overwegen. thanxs.

[edterbak]

Nnoitra schreef op woensdag 26 november 2025 @ 01:00:
@edterbak

Heb je er wel eens aan gedacht om de Room Setpoint waarde voor RTC ook configurabel te maken?
Zodat je er onder System, Sensors, bijvoorbeeld, een thermostaat aan kunt koppelen.

Usecase:
Op een willekeurig moment vindt gezinslid X dat het toch net ff iets te koud is. Net als vroegah, bij de CV ketel, gaat de thermostaat een (halve) graad omhoog.
Als de WP al lekker doorprutteld op laaglast, zal het niet opeens (sneller) warmer gaan worden.
MAAR!! *drumm roll*, als door het (tijdelijk) verhogen van de temperatuur op de thermostaat het RTC setpoint mee omhoog gaat, kom je terecht in de RTC functionaliteit. En afhankelijk van je instellingen gaat de stooklijn dan automagisch omhoog.

Heb het zelf even quick 'n dirty er in gebutst. Kijken of dit wat werkt

Ik weet niet exact hoe je de logica ziet werken en of dat voor jouw situatie ook gaat werken. Maar... het is al vrij eenvoudig om te doen.
Je kunt namelijk gebruik maken van een link-in node welke al beschikbaar is.

In WP-Input tab, rechter gedeelte van het scherm, onderop daar zie je deze:
[Room Setpoint Link-in (ZONE 1)]
Dit linkt door naar het setpoint van RTC waar je het over hebt.

Je kunt in je eigen WP Personal tabje, iedere bron gebruiken en er wat mee doen. zo ook je eigen thermostaat setpoint.
Als je deze link-out naar de link-in van hierboven. Volgens mij ben je er dan.

Is dit wat je zoekt?
[edit] ah... zo ver waren jullie al

[edterbak]

Nnoitra schreef op woensdag 26 november 2025 @ 09:50:
@edterbak
----------------------- Bugje - Flow version25.06 (! Beta 4 !) -----------------------
Ik kon in de scheduler de Toggle Action i.c.m. RTC_Z1 niet aanzetten, dan gaf ie een undefined.

In de WP Scheduler -->GET global / topics heb je dit staan:

code:

if (msg6.payload == 'toggle item') {
    var items = global.get(schedule_topic + '_toggle_item', "file");
    
    if (items !== undefined) {
        var state = items.State;
        if (state === false) {state = 'off'}
        if (state === true) { state = 'on' }
        var list;
        if (items.WAR === true)         {list = 'WAR'}
        if (items.RTC === true)         { if (list !== undefined) { list += ', RTC' } else { list = 'RTC' } }
        if (items.SoftStart === true)   { if (list !== undefined) { list += ', SoftStart' } else { list = 'SoftStart' } }
        if (items.SolarDHW === true)    { if (list !== undefined) { list += ', Solar²DHW' } else { list = 'Solar²DHW' } }
            
        msg6.tooltip = 'Turn ' + state + ': ' + list;
    }

En door je Zone2 toevoegingen is de aanvoer van data:

code:

CCC_Z1: false
CCC_Z2: false
RTC_Z1: true
RTC_Z2: false
SoftStart: false
Solar2DHW: false
State: true

Dat matcht dus niet meer met de Items.
Idem voor de WAR/CCC.

---------------------------------------------------


[...]
Ja, je hebt gelijk, het kan al. Die zit in de WP Input tab.
Mijn toevoeging is om 'm ook via de front-end, via Sensors toe te kunnen voegen.
_{Ik had die usecase txt er niet bij hoeven zetten, dat maakt het verwarrend. In my defence, het was laat}

Ik ga hier naar kijken. TOP.!!! dank je voor het vinden van de bug.
die had ik zelf nog niet gevonden

[edterbak]

Nnoitra schreef op woensdag 26 november 2025 @ 09:50:
@edterbak
----------------------- Bugje - Flow version25.06 (! Beta 4 !) -----------------------
Ik kon in de scheduler de Toggle Action i.c.m. RTC_Z1 niet aanzetten, dan gaf ie een undefined.

In de WP Scheduler -->GET global / topics heb je dit staan:

code:

if (msg6.payload == 'toggle item') {
    var items = global.get(schedule_topic + '_toggle_item', "file");
    
    if (items !== undefined) {
        var state = items.State;
        if (state === false) {state = 'off'}
        if (state === true) { state = 'on' }
        var list;
        if (items.WAR === true)         {list = 'WAR'}
        if (items.RTC === true)         { if (list !== undefined) { list += ', RTC' } else { list = 'RTC' } }
        if (items.SoftStart === true)   { if (list !== undefined) { list += ', SoftStart' } else { list = 'SoftStart' } }
        if (items.SolarDHW === true)    { if (list !== undefined) { list += ', Solar²DHW' } else { list = 'Solar²DHW' } }
            
        msg6.tooltip = 'Turn ' + state + ': ' + list;
    }

En door je Zone2 toevoegingen is de aanvoer van data:

code:

CCC_Z1: false
CCC_Z2: false
RTC_Z1: true
RTC_Z2: false
SoftStart: false
Solar2DHW: false
State: true

Dat matcht dus niet meer met de Items.
Idem voor de WAR/CCC.

---------------------------------------------------


[...]
Ja, je hebt gelijk, het kan al. Die zit in de WP Input tab.
Mijn toevoeging is om 'm ook via de front-end, via Sensors toe te kunnen voegen.
_{Ik had die usecase txt er niet bij hoeven zetten, dat maakt het verwarrend. In my defence, het was laat}

Scheduler fixed in volgende release. Maar dat moet nog even getest worden ben bevestigd worden.

[Nnoitra]

edterbak schreef op woensdag 26 november 2025 @ 19:31:
[...]


Scheduler fixed in volgende release. Maar dat moet nog even getest worden ben bevestigd worden.

Top!

Ik had overigens nog een dingetje, maar dat kan ook een lokaal issue zijn geweest.
De delete van Schedule_2 wou maar niet lukken. Na het verwijderen verdween ie wel uit de gui, maar na een refresh/restart stond ie er gewoon weer in.
Uiteindelijk heb ik NR maar gestopt en de waarden in de global. json verwijdert.

[edterbak]

Nnoitra schreef op woensdag 26 november 2025 @ 20:32:
[...]

Top!

Ik had overigens nog een dingetje, maar dat kan ook een lokaal issue zijn geweest.
De delete van Schedule_2 wou maar niet lukken. Na het verwijderen verdween ie wel uit de gui, maar na een refresh/restart stond ie er gewoon weer in.
Uiteindelijk heb ik NR maar gestopt en de waarden in de global. json verwijdert.

Found it. Dank je voor het melden.
Node: "c4fb7de363d6e1c1"
topic: msg: Schedule_2
moet zijn:
topic: string: Schedule_2

Fixed in volgende release


--------
edit
komt door de geestdodende copy/past handelingen voor al deze schedules.... killing voor je concentratie.

[ Voor 9% gewijzigd door edterbak op 26-11-2025 22:00 ]

[Beer070]

Ik heb mijn heishamon node red flows deze week uitgezet, de 25.02 versie geeft in combinatie met onze wp vooralsnog geen voordeel. Ligt waarschijnlijk aan de Panasonic tcap die minder efficiency heeft op zeer laag vermogen.
Ergens rond 40% vermogen lijkt de cop veel hoger, en ik moet dus iets gaan uitvogelen om daar op te sturen.

[Looka]

Hallo vrienden, ik ben ook eigenaar van een Panasonic J09-serie warmtepomp en ik wil graag een regeling in de planner instellen, een geautomatiseerde logica (zoals "als buitentemperatuur > 4 °C → FM3, anders FM0"). Is dit mogelijk met de planner? Bij voorbaat dank en mijn oprechte waardering voor jullie fantastische werk.

[lampy25]

Gebruik al een mooie tijd de flow, echt super blij mee. Loop alleen tegen 1 ding aan in de winter, hoe combineren jullie RTC on/off met DHW?
Wat ik voor ogen heb is RTC on/off regelt de kamertemperatuur en DHW wordt 1x per dag verwarmt wanneer de boilertemp <40graden is. Dit gebeurd rond 13:00 uur middags om vanwege dynamische tarieven.

Prima te regelen met de scheduler, Force DHW om 13:00 incl. optie dat hij zichzelf mag aanzetten. Vervolgens om 15:00 weer de warmtepomp uit. Alleen dit brengt RTC in de war.

Hoe hebben jullie dit ingesteld?

[hemertje]

Ik heb in de Scheduler de modus "Operation Mode HEAT + DHW" actief tussen 13:00 en 17:00 daarbuiten alleen HEAT
In Home:
DHW setpoint 52 °C
Auto start DHW actief bij 40 °C

[ Voor 6% gewijzigd door hemertje op 30-11-2025 14:04 ]

[blb4]

hemertje schreef op zondag 30 november 2025 @ 14:04:
Ik heb in de Scheduler de modus "Operation Mode HEAT + DHW" actief tussen 13:00 en 17:00 daarbuiten alleen HEAT
In Home:
DHW setpoint 52 °C
Auto start DHW actief bij 40 °C

Dan is er dus (door het omschakelen naar een OM met DHW) elke dag om 13:00u een DHW run. Als dat is wat je wil dan is dat natuurlijk prima. Als je dat niet voor ogen hebt moet je 't anders regelen.

[hemertje]

blb4 schreef op zondag 30 november 2025 @ 15:44:
[...]

Dan is er dus (door het omschakelen naar een OM met DHW) elke dag om 13:00u een DHW run. Als dat is wat je wil dan is dat natuurlijk prima. Als je dat niet voor ogen hebt moet je 't anders regelen.

nee is niet wat ik zie in de Pana statistieken
de run is er alleen wanneer de temp onder de 40GrC komt

[hemertje]

@edterbak en anderen

vraagje, worden alle TOP's vanuit Heishamon meegestuurd naar MQTT?

in InfluxDB / Topics zie ik nergens Heat_Power_Production (TOP 15) en Heat_Power_Consumption (TOP16)
ben aan het kijken of in de COP in Grafana zichtbaar kan maken

[Hieke]

hemertje schreef op zondag 30 november 2025 @ 16:49:
@edterbak en anderen

vraagje, worden alle TOP's vanuit Heishamon meegestuurd naar MQTT?

in InfluxDB / Topics zie ik nergens Heat_Power_Production (TOP 15) en Heat_Power_Consumption (TOP16)
ben aan het kijken of in de COP in Grafana zichtbaar kan maken

Dat kun je bij eigen HeismaMon toch inzien? Gewoon naar het bijbehorende IP-adres gaan en kijken of die daar ververst.
Bij de nieuwere modellen is er overigens een andere benaming aan gehangen. Als voorbeeld een screenshot van HeishaMon icm K-Serie





Welk model HeishaMon en firmware heb je? Misschien is daar een relatie mee te leggen.

[ Voor 12% gewijzigd door Hieke op 30-11-2025 17:23 . Reden: Plaatje MQTT toegevoegd ]

[hemertje]

ik heb de grote Heishamon met Firmware Version: 3.9

en 2 stuks Current S0 kWh meters aangesloten voor warmtepomp (S0) en Backup Heater (S1)

TOP15 Heat_Power_Production 2400 Watt is dit thermisch vermogen geproduceerd?
TOP16 Heat_Power_Consumption 400 Watt is dit het elektrisch opgenomen vermogen die ik ook via S0 meet?

Wat is de relatie tussen TOP 15, 16 en S0?

Welke Grafana grafieken gebruiken jullie zoal vanuit Heishamon?

[ Voor 16% gewijzigd door hemertje op 30-11-2025 20:35 ]

[hemertje]

ik krijg vanuit Node Red / Heishamon geen "productie" vermogenswaarden binnen in Influx?



tewijl deze wel beschikbaar is in MQTT explorer in Home Assistant?

[hemertje]

Abacus.ai komt met de volgende reactie nav Ed's zijn heishamon2influxdb

https://github.com/edterb...port2influx%20(v1.1).json

Heel duidelijk nu – je flow verklaart precies waarom Heat_Power_Production / Heat_Power_Consumption niet in Influx staan.

1. Wat de flow nu doet

Relevant stuk (onderste groep “Send Heishamon to INFLUXdb”):

mqtt in panasonic_heat_pump/main/# → Map sensor to ID (main/#) → Prepare InfluxDB output → influxdb out.
Bij startup wordt global setup één keer aangeroepen; die zet:
context.global.heishamon.SensorMapping = [
// MAIN/#
["Heatpump_State"],
["Pump_Flow"],
...
["Outside_Temp"],
["Heat_Energy_Production"],
["Heat_Energy_Consumption"],
...
// S0/#
["Watthour/1"],
["WatthourTotal/1"],
["Watt/1"],
["Watthour/2"],
["WatthourTotal/2"],
["Watt/2"]
];


Maar: Heat_Power_Production en Heat_Power_Consumption staan hier NIET in.

In Map sensor to ID (main/#):

var sensorsplit = msg.topic.split("/");
var sensor = sensorsplit[sensorsplit.length-1];

for (i = 0; i < context.global.heishamon.SensorMapping.length; i++) {
msg.sensor = sensor;
if (sensor == context.global.heishamon.SensorMapping[i][0]) {
return msg; // alleen DOORLATEN als in SensorMapping
}
}
return; // anders: DROPPEN


Dus:

Alleen topics die expliciet in SensorMapping staan, gaan door naar Influx.
Alles wat niet in de lijst staat (incl. Heat_Power_Production / Heat_Power_Consumption) wordt weggegooid.

Daarom zie je ze niet in Influx Data Explorer.

Prepare InfluxDB output zet wat er wél door komt in 2 Influx‑fields:

msg.payload = [{
numValue: parseFloat(msg.payload), // numeric value
strValue: msg.sensor // sensornaam als string
},
{
topic: msg.sensor // tag 'topic'
}];


In Influx krijg je dus:

measurement = heishamon
_field = "numValue" met waarde
tag topic = <sensornaam>
(exact de laatste component van MQTT topic)

Dat deel is prima.

2. Oplossing: voeg Heat_Power_* toe aan SensorMapping

Dit is de minimale, veilige fix:

Open function node global setup.
In de array SensorMapping onder // MAIN/# voeg je deze entries toe:
["Heat_Power_Production"],
["Heat_Power_Consumption"],


Bijvoorbeeld direct na ["Heat_Energy_Consumption"], (plaats maakt niet uit, maar logisch bij elkaar):

["Heat_Energy_Production"],
["Heat_Energy_Consumption"],
["Heat_Power_Production"],
["Heat_Power_Consumption"],
["Powerful_Mode_Time"],
["Quiet_Mode_Level"],
...

Deploy flow.
Wacht een paar minuten en check in Influx Data Explorer:
from(bucket: "panasonic")
|> range(start: -15m)
|> filter(fn: (r) => r._measurement == "heishamon")
|> filter(fn: (r) => r._field == "numValue")
|> filter(fn: (r) =>
r.topic == "Heat_Power_Production" or
r.topic == "Heat_Power_Consumption"
)


Als alles goed is, zie je nu netjes _value rond 2200 / 200 W.

3. (Optioneel beter) – generieker maken

Je zou ook de hele whitelist kunnen schrappen zodat alle Heishamon‑topics naar Influx gaan:

In Map sensor to ID (main/#) kun je dit simpeler maken:

var sensorsplit = msg.topic.split("/");
var sensor = sensorsplit[sensorsplit.length-1];

msg.sensor = sensor;
return msg; // geen whitelist meer


En dan kun je SensorMapping in global setup zelfs helemaal verwijderen, tenzij je die nog voor andere dingen gebruikt.

Voordeel:

Elke nieuwe variable in Heishamon komt automatisch in Influx.
Geen risk meer dat je iets vergeet (zoals nu met Heat_Power_*).

Nadeel:

Je krijgt véél meer series in Influx (ook minder interessante), maar dat is meestal geen echt probleem.

Als je voorzichtig wilt zijn: nu eerst alleen de 2 entries toevoegen zoals hierboven; later kun je altijd nog whitelisting eruit slopen.

4. Daarna: simpele COP‑query in Grafana

Zodra Heat_Power_Production in Influx staat:

// Elektrisch vermogen WP (S0-1, Watt/1)
power_el_hp = from(bucket: "panasonic")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r._measurement == "heishamon")
|> filter(fn: (r) => r._field == "numValue")
|> filter(fn: (r) => r.topic == "Watt/1")
|> aggregateWindow(every: 5m, fn: mean, createEmpty: false)
|> keep(columns: ["_time", "_value"])
|> rename(columns: {_value: "P_el_hp"})

// Thermisch vermogen (Heat_Power_Production)
power_th = from(bucket: "panasonic")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r._measurement == "heishamon")
|> filter(fn: (r) => r._field == "numValue")
|> filter(fn: (r) => r.topic == "Heat_Power_Production")
|> aggregateWindow(every: 5m, fn: mean, createEmpty: false)
|> keep(columns: ["_time", "_value"])
|> rename(columns: {_value: "P_th"})

// Join en COP
join(
tables: {el: power_el_hp, th: power_th},
on: ["_time"]
)
|> map(fn: (r) => ({
_time: r._time,
COP_hp: if r.P_el_hp > 0.0 then r.P_th / r.P_el_hp else 0.0
)
|> keep(columns: ["_time", "COP_hp"])


Dit is de exacte COP van de compressor, zonder hydraulische schattingen.

5. Samenvatting voortgang
Probleem: Node‑RED whitelists SensorMapping; Heat_Power_Production / Heat_Power_Consumption staan niet in de lijst → worden niet naar Influx geschreven.
Oplossing nu: 2 regels toevoegen in SensorMapping (of whitelisting verwijderen).
Na deploy: check in Influx of topic == "Heat_Power_Production" data heeft.
Daarna: simpele COP‑grafiek in Grafana op basis van Heat_Power_Production en Watt/1.

Als je wilt, kan ik een concrete, kortere versie van Map sensor to ID geven die whitelisting veilig uitschakelt.

[Beer070]

hemertje schreef op zondag 30 november 2025 @ 16:49:
@edterbak en anderen

vraagje, worden alle TOP's vanuit Heishamon meegestuurd naar MQTT?

in InfluxDB / Topics zie ik nergens Heat_Power_Production (TOP 15) en Heat_Power_Consumption (TOP16)
ben aan het kijken of in de COP in Grafana zichtbaar kan maken

Ik moest voor de transitie van Mqtt topics naar influxdb ze zelf invoeren (regel voor regel). Ik kon niet zonder meer alles aan influxdb toevoegen en mijn HA grafana had geen werkende mqtt adapter.

[edterbak]

Als de mqtt topics in de broker geupdate worden, dan zijn ze ook gewoon beschikbaar in ieder ander platform. Of het nu node red is of influx

[Beer070]

edterbak schreef op zondag 30 november 2025 @ 21:19:
Als de mqtt topics in de broker geupdate worden, dan zijn ze ook gewoon beschikbaar in ieder ander platform. Of het nu node red is of influx

Hoe krijg jij ze dan in influxdb? Bij mij moest ik dat configureren

[hemertje]

ik heb AI de whitelisting eruit laten halen

[edterbak]

https://github.com/edterb...e/main/heishamon2influxdb

Voor zover ik heb gehoord, werkt deze nog. Ik gebruik het zelf niet overigens.
Ik zou zelf niet weten waarom ik alles in een db moet zetten. Ik heb er geen usecase voor anders dan 'nice to have', of 'voor grafana' (ook geen usecase).

Als deze flow niet meer werkt, dan mag iemand hem updaten hoor, dan pas ik hem aan in github

[Beer070]

Ah,

Ik doe het netjes vanuit de configuration.yaml in home assistant. Daar kan je de sensoren toevoegen en dan worden ze bewaard in influxdb. Leek me handig voor typisch historische data.

[hemertje]

edterbak schreef op zondag 30 november 2025 @ 21:38:
https://github.com/edterb...e/main/heishamon2influxdb

Voor zover ik heb gehoord, werkt deze nog. Ik gebruik het zelf niet overigens.
Ik zou zelf niet weten waarom ik alles in een db moet zetten. Ik heb er geen usecase voor anders dan 'nice to have', of 'voor grafana' (ook geen usecase).

Als deze flow niet meer werkt, dan mag iemand hem updaten hoor, dan pas ik hem aan in github

deze heb ik gebruikt, maar daar zat een whitelisting in zodat de S0 en S1 sensoren geblokt worden.
hieronder de code zonder de whitelisting

code:

[
  {
    "id": "heishamon_tab",
    "type": "tab",
    "label": "Heishamon to InfluxDB",
    "disabled": false,
    "info": "",
    "env": []
  },
  {
    "id": "heishamon_group",
    "type": "group",
    "z": "heishamon_tab",
    "style": {
      "stroke": "#999999",
      "stroke-opacity": "1",
      "fill": "none",
      "fill-opacity": "1",
      "label": true,
      "label-position": "nw",
      "color": "#a4a4a4"
    },
    "nodes": [
      "mqtt_main",
      "mqtt_s0",
      "map_main",
      "map_s0",
      "prepare_influx",
      "influx_out",
      "comment_node"
    ],
    "x": 154,
    "y": 79,
    "w": 1152,
    "h": 282
  },
  {
    "id": "comment_node",
    "type": "comment",
    "z": "heishamon_tab",
    "g": "heishamon_group",
    "name": "Send Heishamon to InfluxDB",
    "info": "",
    "x": 240,
    "y": 100,
    "wires": []
  },
  {
    "id": "mqtt_main",
    "type": "mqtt in",
    "z": "heishamon_tab",
    "g": "heishamon_group",
    "name": "Heishamon main/#",
    "topic": "panasonic_heat_pump/main/#",
    "qos": "0",
    "datatype": "auto-detect",
    "broker": "mqtt_broker",
    "nl": false,
    "rap": false,
    "inputs": 0,
    "x": 240,
    "y": 160,
    "wires": [["map_main"]]
  },
  {
    "id": "map_main",
    "type": "function",
    "z": "heishamon_tab",
    "g": "heishamon_group",
    "name": "Map sensor to ID (main/#)",
    "func": "// Extract sensor name from topic (last part after /)\nvar sensorsplit = msg.topic.split(\"/\");\nvar sensor = sensorsplit[sensorsplit.length - 1];\n\nmsg.sensor = sensor;\nreturn msg;",
    "outputs": 1,
    "noerr": 0,
    "initialize": "",
    "finalize": "",
    "libs": [],
    "x": 520,
    "y": 160,
    "wires": [["prepare_influx"]]
  },
  {
    "id": "mqtt_s0",
    "type": "mqtt in",
    "z": "heishamon_tab",
    "g": "heishamon_group",
    "name": "Heishamon s0/#",
    "topic": "panasonic_heat_pump/s0/#",
    "qos": "0",
    "datatype": "auto-detect",
    "broker": "mqtt_broker",
    "nl": false,
    "rap": false,
    "inputs": 0,
    "x": 240,
    "y": 240,
    "wires": [["map_s0"]]
  },
  {
    "id": "map_s0",
    "type": "function",
    "z": "heishamon_tab",
    "g": "heishamon_group",
    "name": "Map sensor to ID (s0/#)",
    "func": "// Extract sensor name from topic (after s0/)\nvar sensorsplit = msg.topic.split(\"s0/\");\nvar sensor = sensorsplit[sensorsplit.length - 1];\n\nmsg.sensor = sensor;\nreturn msg;",
    "outputs": 1,
    "noerr": 0,
    "initialize": "",
    "finalize": "",
    "libs": [],
    "x": 520,
    "y": 240,
    "wires": [["prepare_influx"]]
  },
  {
    "id": "prepare_influx",
    "type": "function",
    "z": "heishamon_tab",
    "g": "heishamon_group",
    "name": "Prepare InfluxDB output",
    "func": "if (isNaN(parseFloat(msg.payload))) {\n    return;\n} else {\n    msg.payload = [\n        {\n            numValue: parseFloat(msg.payload),\n            strValue: msg.sensor\n        },\n        {\n            topic: msg.sensor\n        }\n    ];\n    return msg;\n}",
    "outputs": 1,
    "noerr": 0,
    "initialize": "",
    "finalize": "",
    "libs": [],
    "x": 820,
    "y": 200,
    "wires": [["influx_out"]]
  },
  {
    "id": "influx_out",
    "type": "influxdb out",
    "z": "heishamon_tab",
    "g": "heishamon_group",
    "influxdb": "influxdb_config",
    "name": "Panasonic heatpump",
    "measurement": "heishamon",
    "precision": "",
    "retentionPolicy": "",
    "database": "Panasonic",
    "precisionV18FluxV20": "s",
    "retentionPolicyV18Flux": "",
    "org": "Home",
    "bucket": "panasonic",
    "x": 1100,
    "y": 200,
    "wires": []
  },
  {
    "id": "mqtt_broker",
    "type": "mqtt-broker",
    "name": "MQTT (192.168.2.5)",
    "broker": "192.168.2.5",
    "port": "1883",
    "clientid": "",
    "autoConnect": true,
    "usetls": false,
    "compatmode": false,
    "protocolVersion": "4",
    "keepalive": "60",
    "cleansession": true,
    "autoUnsubscribe": true,
    "birthTopic": "",
    "birthQos": "0",
    "birthRetain": "false",
    "birthPayload": "",
    "birthMsg": {},
    "closeTopic": "",
    "closeQos": "0",
    "closeRetain": "false",
    "closePayload": "",
    "closeMsg": {},
    "willTopic": "",
    "willQos": "0",
    "willRetain": "false",
    "willPayload": "",
    "willMsg": {},
    "userProps": "",
    "sessionExpiry": ""
  },
  {
    "id": "influxdb_config",
    "type": "influxdb",
    "hostname": "192.168.2.5",
    "port": "8086",
    "protocol": "http",
    "database": "test",
    "name": "InfluxDB",
    "usetls": false,
    "tls": "",
    "influxdbVersion": "2.0",
    "url": "http://192.168.2.5:8086",
    "timeout": "",
    "rejectUnauthorized": false
  }
]

Wat deze flow doet

• 2 MQTT‑inputs:

1. panasonic_heat_pump/main/# → alle main topics (Heat_Power_Production, Compressor_Freq, etc.)
2. panasonic_heat_pump/s0/# → S0‑meters (Watt/1, Watt/2, etc.)

2 function nodes:

• Extraheren topic‑naam (laatste deel na / of na s0/)
• Geen whitelisting → alle topics gaan door

Prepare InfluxDB output:

• Controleert of payload numeriek is
• Maakt InfluxDB‑structuur: numValue + topic

InfluxDB out:

• Schrijft naar bucket panasonic, measurement heishamon

Configuratie aanpassen (indien nodig)

Als je MQTT‑broker of InfluxDB andere instellingen heeft:

1. Dubbelklik op een MQTT in node → klik op potlood bij broker → pas IP/poort aan
2. Dubbelklik op Panasonic heatpump (InfluxDB out) → klik op potlood bij InfluxDB → pas URL/token/bucket aan

Samenvatting

• Standalone flow zonder "Own WP Sensors"
• Alle Heishamon topics (main + s0) → InfluxDB
• Geen whitelisting, dus Heat_Power_Production, Heat_Power_Consumption, Watt/1, Watt/2 komen allemaal door
• Visuele layout: netjes gegroepeerd in één frame, klaar voor gebruik

[blb4]

hemertje schreef op zondag 30 november 2025 @ 20:31:
ik heb de grote Heishamon met Firmware Version: 3.9

en 2 stuks Current S0 kWh meters aangesloten voor warmtepomp (S0) en Backup Heater (S1)

TOP15 Heat_Power_Production 2400 Watt is dit thermisch vermogen geproduceerd?
TOP16 Heat_Power_Consumption 400 Watt is dit het elektrisch opgenomen vermogen die ik ook via S0 meet?

Wat is de relatie tussen TOP 15, 16 en S0?

Welke Grafana grafieken gebruiken jullie zoal vanuit Heishamon?

Als het goed is zie je aardig verschil tussen S0 en TOP16, TOP16 gaat in stappen van 200W, dat is behoorlijk onnauwkeurig. Voor nauwkeurig opgenomen vermogen/energie kan je dus beter de S0 meter gebruiken.

Als je de Ta en Tr sensoren op elkaar hebt gekalibreerd (als de waterpomp wel loopt - met liefst zo hoog mogelijke flow - maar de compressor niet dan moet Ta en Tr gelijk zijn) dan ik TOP15 behoorlijk nauwkeurig.

COP is dan dus TOP15/S0. Als je Top15 en S0 vermogen beide in Grafana hebt kan je de COP in een grafiek zetten via een transformatie.

[BazemanKM]

hemertje schreef op zondag 30 november 2025 @ 21:09:
Abacus.ai komt met de volgende reactie nav Ed's zijn heishamon2influxdb

https://github.com/edterb...port2influx%20(v1.1).json


[...]

Ooit zijn de topics vanuit Heishamon aangepast, dus moet je de influxdb flow ook even aanpassen.

[hemertje]

heb het nu als volgt draaien binnen Influx i.c.m. Grafana



Influx haalt de gegevens uit Heishamon, maar bedacht me vanmorgen dat dit dubbelop is want de parameters zijn al beschikbaar binnen MQTT in HomeAssistant en dus dubbel nu

beter is dan Influx vullen vanuit HomeAssistant - MQTT?

vraagje tussendoor, ik begrijp dat HomeAssistant de parameters maar 7 dagen opslaat?
voor de lange termijn is het dus beter om deze in de Influx database te importeren?

[Breadrun]

Looka schreef op zondag 30 november 2025 @ 11:00:
Hallo vrienden, ik ben ook eigenaar van een Panasonic J09-serie warmtepomp en ik wil graag een regeling in de planner instellen, een geautomatiseerde logica (zoals "als buitentemperatuur > 4 °C → FM3, anders FM0"). Is dit mogelijk met de planner? Bij voorbaat dank en mijn oprechte waardering voor jullie fantastische werk.

Als je Quiet Mode bedoelt dan kan je dat regelen in de scheduler. Wil je dat ook op temperatuur doen dan zal je een logica in node red moeten maken, of je past je schedule aan als het koud wordt

[Looka]

Breadrun schreef op dinsdag 2 december 2025 @ 08:09:
[...]


Als je Quiet Mode bedoelt dan kan je dat regelen in de scheduler. Wil je dat ook op temperatuur doen dan zal je een logica in node red moeten maken, of je past je schedule aan als het koud wordt

Ik heb het zo geprogrammeerd met een buitentemperatuurconditie, het werkt, dank je wel

[ Voor 39% gewijzigd door Looka op 02-12-2025 11:14 ]

[Crazy-]

Het is al lang geleden dat ik Node heb ingezet. De boel draait derhalve ook prima

Echter nu wil ik de temperatuur sensor vervangen van de woning. Huidige is een lelijke D1 module welke MQTT naar m’n oude server stuurt, nog naar degene voor Domotica

Ondertussen is het halve huis voorzien van Shelly en dat werkt prima. Door het plaatsen van 2 HT modules van Shelly (mancave & woning) kan ik deels al wat sturen. Icm home assistent.

Echter het Node dashboard draait nog volledig dus op de mqtt sensor.

Echter heb ik werkelijk geen idee meer hoe ik dat ooit ingesteld heb… in Node wel zitten zoeken en ergens zag ik een waarde welke de MQTT uitleest. Maar hoe of wat is weer even uitzoeken.

Eigenlijk zoek ik dus de manier nu hoe ik die Shelly temperatuur sensor kan uitlezen?

Bij voorkeur zonder Mqtt omdat ik die mqtt server weg wil halen (oude synology). Kan eventueel nieuwe opspinnen in Docker.

[MikeyMan]

@Crazy- hoe ga je de heishamon node red draaien zonder mqtt dan?

De Shelly kan ofwel via mqtt ofwel via webcast/home assistant zn data kwijt.

[ Voor 4% gewijzigd door MikeyMan op 03-12-2025 12:39 ]

[edterbak]

Als de sensor bekend is binnen home assistant, dan kun je hem ook inlezen via node red.
er is een HomeAssistant pallet, welke dat voor je doet.

Als dat werkend is, dan kun je eenvoudig dus een "Events: State" node plaatsen in je tabje "WP Personal"
Als je die niet hebt, even maken.
Vervolgens selecteer je in die node daar de sensor.

Achter deze node, zet je een link-out node. Deze verbind je met de juiste node op het tabje "WP Input"

Echter, ik weet niet welke versie flow je draait. Ik gok dat je er al heeeel lang niet naar omgekeken hebt omdat het prima werkt.
Dus dat stukje kan ik je niet heel erg veel over vertellen.
hier ziet het er als volgt uit:



success

[edit]
Het is wel belangrijk wat @MikeyMan zegt over mqtt.
de heishamon pcb heefft een mqtt broker nodig. De flow ook. Je kunt niet zonder.
Je kunt uiteraard wel zonder node red, maar niet zonder broker

[ Voor 8% gewijzigd door edterbak op 03-12-2025 12:49 ]

[Crazy-]

MikeyMan schreef op woensdag 3 december 2025 @ 12:39:
@Crazy- hoe ga je de heishamon node red draaien zonder mqtt dan?

De Shelly kan ofwel via mqtt ofwel via webcast/home assistant zn data kwijt.

Aaai dat is waar! Oké. Dan voeg ik een docker container toe. Geen issue Richt ik gelijk maar de nieuwe Node Red volledig in want die heb ik sindsdien niet meer bijgewerkt ook 🫣

Ik merk alweer. Het draait al zolang goed. Kijk er op die manier niet naar behalve vorige week: - toen moest ik wel opnieuw inregelen ivm nieuwe vloerverwarming garage & nieuwe verdeler in de woning.

@edterbak heb Flow version 22.00 Stable release zelfs nog ik ga na dit weekend paar dagen naar het buitenland, dus ik doe nu even niets. als ik terugkom maar eens de boel upgraden en gelijk de bedrage heishmon (utp) aansluiten

[ Voor 32% gewijzigd door Crazy- op 03-12-2025 16:31 ]

[edterbak]

als je niet hoeft te updaten en het werkt perfect, zou ik niet updaten.
Er is geen noodzaak.

[edterbak]

Nieuwe versie beschikbaar.

Link: https://github.com/edterb...n_control/tree/25.06-BETA

Changelog:
Version 25.06 (! Beta 5 !)
Changes:
- Fix Softstart: Buffertank enabled would have bad performance. Variable was not initialized propperly.
- Fix Zone2: No change in setpoint being sent other than 0 or 1. There was a math error.
- Fix Zone2: MQTT Comand spamming resolved.
- New Feature: Created a generic control mechanism to verify sent commands have been processed. If not, a retry is initiated with a maximum retrycount of 3 for each topic. This is done for a couple of the most important commands.
- Added an auto-tuning noice filter to the input sensors by default.
- Fix Scheduler: Toggle functions to accomadate zone 1 and zone 2 were not adjusted yet. Now they should be working
- Fix Scheduler: Removing line 2 did not work. Now it does.


------------------------------
Dit is een redelijke update t.o.v. beta 4.
Softstart zou nu stabieler moeten zijn. Er zit nog 1 eigenaardigheid in m.i. Maar dat komt later. Dit is al veeel beter.
Tevens zijn er een aantal gemelde bugs gefixt.

[hemertje]

Grote dank voor Ed!

[edterbak]

Softstart settings welke voor mij goed werken:


Let daarbij niet op de Upper/Lower limit correction. Die is irrelevant

[edterbak]

Added an auto-tuning noice filter to the input sensors by default.

Op [WP Control] tab


Mocht je deze filters niet willen gebruiken, dan kun je ze disablen en de draadjes er tussen verbinden weer.

[edterbak]

New Feature: Created a generic control mechanism to verify sent commands have been processed.

Op [WP Manager] tab


Mocht je TOCH een mqtt spam hebben met de regel "resend" er in...
Dan deze mqtt out node disablen

[Nnoitra]

edterbak schreef op woensdag 3 december 2025 @ 16:39:
Added an auto-tuning noice filter to the input sensors by default.

Op [WP Control] tab
[Afbeelding]

Mocht je deze filters niet willen gebruiken, dan kun je ze disablen en de draadjes er tussen verbinden weer.

Ik heb die filter voor de T_Zone_1_Temperature er tussenuit gehaald, net als de round(?) die er eerder in zat.
De netatmo wireless thermostaat, die ik heb, geeft dusdanig weinig updates dat met de round/filter de uiteindelijke waarde te veel afweek van de werkelijke waarde. En dat is funest voor de werking van de RTC functie.

Ander dingetje.
In Function 19, van "Home (pump)", WP Dash

code:

var SHIFT_Final = (Math.round(global.get('SHIFT_Final',"file") * 10 )) / 10;
var Start_temp = (Math.round(Math.max(global.get('F_CCC.z1.setpoint',"file"),global.get('F_CCC.z2.setpoint',"file"))) * 10) / 10;

msg.label = SHIFT_Final + Start_temp;
return msg;

Hier gebruik je een combinatie van zone 1 en 2 van de CCC. En die waarde toon je bij de SoftStart --> Outlet setpoint (<<-- hier -->> °C).
Echter, als je geen Z2 gebruikt en je heb die waarden op het CCC scherm voor Z2 nooit gelijk getrokken met Z1.. Dan pakt ie een default waarde en in mijn geval toonde ie daar een Outlet setpoint (** °C) van 36 graden ofzo
Ik kan me voorstellen dat dit verwarrend is, als je niet weet waar die temperatuur vandaan komt
Idem als je voor Z1 de Pana waarden niet geïmporteerd hebt.

[edterbak]

Nnoitra schreef op woensdag 3 december 2025 @ 23:47:
[...]

Ik heb die filter voor de T_Zone_1_Temperature er tussenuit gehaald, net als de round(?) die er eerder in zat.
De netatmo wireless thermostaat, die ik heb, geeft dusdanig weinig updates dat met de round/filter de uiteindelijke waarde te veel afweek van de werkelijke waarde. En dat is funest voor de werking van de RTC functie.

Kun je daar in een grafiekje wat resultaten van plotten? RAW + Filtered.
De round ? Welke round bedoel je? In het filter en de functie daar achter zit geen "round" functie

Ander dingetje.
In Function 19, van "Home (pump)", WP Dash

code:

var SHIFT_Final = (Math.round(global.get('SHIFT_Final',"file") * 10 )) / 10;
var Start_temp = (Math.round(Math.max(global.get('F_CCC.z1.setpoint',"file"),global.get('F_CCC.z2.setpoint',"file"))) * 10) / 10;

msg.label = SHIFT_Final + Start_temp;
return msg;

Hier gebruik je een combinatie van zone 1 en 2 van de CCC. En die waarde toon je bij de SoftStart --> Outlet setpoint (<<-- hier -->> °C).
Echter, als je geen Z2 gebruikt en je heb die waarden op het CCC scherm voor Z2 nooit gelijk getrokken met Z1.. Dan pakt ie een default waarde en in mijn geval toonde ie daar een Outlet setpoint (** °C) van 36 graden ofzo
Ik kan me voorstellen dat dit verwarrend is, als je niet weet waar die temperatuur vandaan komt
Idem als je voor Z1 de Pana waarden niet geïmporteerd hebt.

Dat is gek, hoe komt die 36 graden in je stored variable?
Bij mij staat daar:
20C water
of
-5C shift

[Nnoitra]

edterbak schreef op donderdag 4 december 2025 @ 09:11:
[...]

Kun je daar in een grafiekje wat resultaten van plotten? RAW + Filtered.
De round ? Welke round bedoel je? In het filter en de functie daar achter zit geen "round" functie

Dat zat in een vorig versie, die heb je vervangen door die filter. Ik meende dat het een Round was, maar kan ook wat anders zijn geweest.
Geen data meer van..

Dat is gek, hoe komt die 36 graden in je stored variable?
Bij mij staat daar:
20C water
of
-5C shift

Die komt uit het berekende setpoint van de CCC.
Hier staat Z2 absurd hoog:


En hier is Z2 gelijk aan Z1:

[Roger_de_Poger]

Ik heb bij de initiële configuratie van Heishamon de mqtt topic base gewijzigd in aquarea.
Zojuist heb ik de Heishamon <> Node Red flows eens uitgeprobeerd, maar er zit dus een mqtt topic base mismatch omdat NR op zoek gaat naar de originele topic base panasonic_heat_pump...
Kan ik dat eenvoudig wijzigen in NR?
Bij voorkeur in NR omdat ik al eea gemaakt heb in HA...

[ Voor 15% gewijzigd door Roger_de_Poger op 04-12-2025 12:16 ]

[edterbak]

je kunt de geimporteerde JSON even editen. find>replace uitvoeren.

dan alles verwijderen in je node red zelf weer, en opnieuw importeren met de gecorrigeerde base

[edterbak]

Nnoitra schreef op donderdag 4 december 2025 @ 10:30:
[...]

Dat zat in een vorig versie, die heb je vervangen door die filter. Ik meende dat het een Round was, maar kan ook wat anders zijn geweest.
Geen data meer van..


[...]

Die komt uit het berekende setpoint van de CCC.
Hier staat Z2 absurd hoog:
[Afbeelding]

En hier is Z2 gelijk aan Z1:
[Afbeelding]

Ik ben het even kwijt.

Heb je 2 zones actief?
Zo nee, is CCC voor zone 2 actief? Het lijkt uit je screenshot van niet

[Nnoitra]

edterbak schreef op donderdag 4 december 2025 @ 13:29:
[...]

Ik ben het even kwijt.

Heb je 2 zones actief?
Zo nee, is CCC voor zone 2 actief? Het lijkt uit je screenshot van niet

Ik gebruik 1 zone, en ik laat de pana de stooklijn bepalen.
De CCC functie gebruik ik niet.

Maar die waarde in Outlet setpoint (28 °C), op de softstart pagina, gebruikt wél de berekende setpoint waardes van de CCC pagina, ongeacht of CCC actief is of niet.

[ Voor 5% gewijzigd door Nnoitra op 04-12-2025 13:51 ]

[edterbak]

Ik heb denk ik een fix.
graag even kijken of dit werkt.

kun je het importeren en overschrijven?
het zijn de 2 CCC functie nodes.

code:

[
    {
        "id": "0d996033de2ed84e",
        "type": "function",
        "z": "a938de76db0b71f6",
        "g": "d2b7e1d6e85a96cf",
        "name": "Function CCC (zone1)",
        "func": "// All these functions ONLY need to be executed when the heatpump is in HEAT mode. \nvar msg1 = {};        //  pin 1 - SP_CCC (function on)\nvar msg99 = {};        //  pin 2 - Log information\n\n//******************************************************************************\nvar TOP20_ThreeWay_Valve_State = global.get('TOP20_ThreeWay_Valve_State');                    // Get the global variable for current possition of the three way valve. ROOM or DHW mode. (0=HEAT / 1=DHW)\n\tif (TOP20_ThreeWay_Valve_State === undefined) { return null; }\nvar Operating_Mode = global.get('TOP4_Operating_Mode_State', \"file\");\n\tif (Operating_Mode === undefined) { return null; }\nvar current_sp = global.get('TOP42_Z1_Water_Target_Temp', \"file\");                        // TOP27 >> TOP42\n\tif (current_sp === undefined) { return null; }\nvar TOP76_Heating_Mode = global.get('TOP76_Heating_Mode', \"file\");                     // TOP76 - Compensation curve or DIRECT mode\n\tif (TOP76_Heating_Mode === undefined) { return null ; }\nvar ccc_state = global.get('F_CCC.z1.state', \"file\");          // Get the global variable. Used to see if the WAR function is enabled.\n\tif (ccc_state === undefined) { ccc_state = 0; global.set('F_CCC.z1.state', 0, \"file\"); }\nvar TOP94_Zones_State = global.get(\"TOP94_Zones_State\",\"file\");\n    if (TOP94_Zones_State === undefined) { return null ; }\n\n\n//******************************************************************************\nvar war_ot1 = global.get('F_CCC.z1.ot1', \"file\");                             // Outside temperature high         (warm outside)\nvar war_ot2 = global.get('F_CCC.z1.ot2', \"file\");                             // Outside temperature intermediate (intermediate outside temperature)\nvar war_ot3 = global.get('F_CCC.z1.ot3', \"file\");                             // Outside temperature low          (cold outside)\n\nvar war_wt1 = global.get('F_CCC.z1.wt1', \"file\");                             // Water temperature low            (cold water)\nvar war_wt2 = global.get('F_CCC.z1.wt2', \"file\");                             // Water temperature intermediate   (intermediate water temperature)\nvar war_wt3 = global.get('F_CCC.z1.wt3', \"file\");                             // Water temperature high           (warm water)\n\n//******************************************************************************\n\nvar SP_start = global.get('F_CCC.z1.SP_DIRECT_virt', \"file\");                       // Get the global variable for SP_DIRECT_virt. Value is set through the dashboard\nif (TOP76_Heating_Mode === 1 && (SP_start < 20 || SP_start === undefined || TOP94_Zones_State === 1)) {\n    SP_start = 20;\n    global.set('F_CCC.z1.SP_DIRECT_virt', 20, \"file\");\n}\nif (TOP76_Heating_Mode === 0 && (SP_start > 5 || SP_start === undefined || TOP94_Zones_State === 1)) {\n    SP_start = -5;\n    global.set('F_CCC.z1.SP_DIRECT_virt', 0, \"file\");\n}\n\n\nvar check = (war_ot1 + war_ot2 + war_ot3 + war_wt1 + war_wt2 + war_wt3);\nif (isNaN(check) || check === undefined)     // if the variables are added to eachother and the result is Not a Number, produce an error message.\n{\n    msg99.payload = \"<font color=red>Profile temperatures are not correctly set in the dashboard. Waiting for Panasonic import or user input</font>\";\n    msg99.topic = \"Function CCC (Zone 1)\";\n    global.set('F_CCC.z1.state', 0, \"file\");\n    global.set('F_CCC.z1.setpoint', SP_start, \"file\");\n    return [null, msg99];\n}\n\nif (war_wt2 < war_wt1 || war_wt3 < war_wt1) {\n    msg99.payload = \"<font color=red>Temperature profile is inverted and not setup correctly. This requires your attention. CCC-function disabled</font>\";\n    msg99.topic = \"Function CCC (Zone 1)\";\n    global.set('F_CCC.z1.state', 0, \"file\");\n    global.set('F_CCC.z1.setpoint', SP_start, \"file\");\n    return [null, msg99, msg99];\n}\n\nvar SP_ccc;                                                                     // set empty starting variable\n\nvar war_Tb = global.get('T_outside', \"file\");                           // Outdoor temperature.\nif (isNaN(war_Tb) || war_Tb === undefined || war_Tb < -50)             // if the variable is Not a Number, produce an error message.\n{\n    msg99.payload = \"T_outside is not valid. Waiting for correct value.\";\n    msg99.topic = \"Function CCC (Zone 1)\";\n    //global.set('F_CCC.z1.setpoint', SP_start, \"file\");\n    return [null, msg99, msg99];\n}\n\nvar F_CCC_old_SP = global.get('F_CCC.z1.setpoint',\"file\");\nif (F_CCC_old_SP === undefined) {\n    F_CCC_old_SP = SP_start;\n    global.set('F_CCC.z1.setpoint', SP_start, \"file\");\n}\n\n\n////////////////////////////////////////////////////////////////////////////////\n//      Calculation of the NR WAR Setpoint\n////////////////////////////////////////////////////////////////////////////////\n\n\n\nif (war_Tb >= war_ot1) { SP_ccc = war_wt1; }                                         // Range 1\n\nif (war_Tb < war_ot1 && war_Tb > war_ot2)                       // Range 2\n{ SP_ccc = (((war_wt1 - war_wt2) * ((war_Tb - war_ot1) / (war_ot1 - war_ot2))) + war_wt1); }\n\n\nif (war_Tb <= war_ot2 && war_Tb > war_ot3)                      // Range 3\n{ SP_ccc = (((war_wt2 - war_wt3) * ((war_Tb - war_ot2) / (war_ot2 - war_ot3))) + war_wt2); }\n\nif (war_Tb <= war_ot3)                                          // Range 4\n{ SP_ccc = war_wt3; }\n\nSP_ccc = Number(SP_ccc).toFixed(1);\nSP_ccc = parseFloat(SP_ccc);\n\n\n////////////////////////////////////////////////////////////////////////////////\n//      Compensation curve being used. WAR function not allowed.\n////////////////////////////////////////////////////////////////////////////////\nif (TOP76_Heating_Mode === 0) {                    // Compensation Curve\n    if (ccc_state === 1) {\n        global.set('F_CCC.z1.state', 0, \"file\");\n        msg99.payload = \"Compensation curve active. Using internal Panasonic WAR function. NodeRed WAR function is now disabled\";\n        msg99.topic = \"Function CCC (Zone 1)\";\n        return [null, msg99];\n    }\n    //if (ccc_state === 0 || ccc_state === undefined) { SP_ccc = SP_start; }\n    global.set('F_CCC.z1.setpoint', SP_ccc,\"file\");\n    msg1.payload = SP_ccc;\n    return [msg1, null];\n}\n////////////////////////////\n\n// Operating mode (0=Heat only, 1=Cool only, 2=Auto(Heat), 3=DHW only, 4=Heat+DHW, 5=Cool+DHW, 6=Auto(Heat)+DHW, 7=Auto(Cool), 8=Auto(Cool)+DHW)\n////////////////////////////////////////////////////////////////////////////////\n//      Direct mode > WAR function allowed.\n////////////////////////////////////////////////////////////////////////////////\nif (TOP76_Heating_Mode === 1) {                // Direct\n        if (Operating_Mode === undefined || \n            current_sp === 0 || \n            Operating_Mode === 1 || \n            //Operating_Mode === 3 || \n            Operating_Mode === 5 || \n            Operating_Mode === 7 || \n            Operating_Mode === 8\n        ){\n            return null;                                                        // If state is 1 (DHW mode), correction 0 is direclty exported to the message and the function ends here.\n        }\n\n    msg1.payload = SP_ccc;                                                         // required\n    msg1.topic = 'SP_war';\n    msg1.source = 'WAR';\n\n    if (ccc_state === 0) {                                            // If the state is 1 (enabled), AND outside temperature contains a value.\n        global.set('F_CCC.z1.setpoint', SP_start,\"file\");\n        msg1.payload = SP_start;\n        return [msg1, null];\n    }\n\n    if (ccc_state === 1) {\n        msg1.payload = SP_ccc;\n        if (SP_ccc === F_CCC_old_SP) {\n            return [msg1, null];\n        }\n        else {\n            global.set('F_CCC.z1.setpoint', SP_ccc,\"file\");\n\n            msg99.payload = \"Setpoint change: From \" + F_CCC_old_SP + \" to \" + SP_ccc + \" °C\";\n            msg99.topic = \"Function CCC (Zone 1)\";\n\n            return [msg1, msg99];\n        }\n    }\n    ////////////////////////////////////////////////////////////////////////////////\n\n}",
        "outputs": 3,
        "timeout": "",
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 1100,
        "y": 820,
        "wires": [
            [
                "d16f38ef74db786a"
            ],
            [
                "663fd79ce5a1610d"
            ],
            [
                "e06c72be3ce79609"
            ]
        ],
        "outputLabels": [
            "SP_WAR (function on)",
            "ToLog",
            "ToToggle_CCC"
        ],
        "info": "# ALL IN ONE FUNCTION\n\nThis function takes care of WAR, RTC and SoftStart. Comments are within"
    },
    {
        "id": "51a6bac27fdf889f",
        "type": "function",
        "z": "a938de76db0b71f6",
        "g": "56ad661c12898edd",
        "name": "Function CCC (zone2)",
        "func": "// All these functions ONLY need to be executed when the heatpump is in HEAT mode. \nvar msg1 = {};        //  pin 1 - SP_CCC (function on)\nvar msg99 = {};        //  pin 2 - Log information\n\n//******************************************************************************\nvar TOP20_ThreeWay_Valve_State = global.get('TOP20_ThreeWay_Valve_State');                    // Get the global variable for current possition of the three way valve. ROOM or DHW mode. (0=HEAT / 1=DHW)\n\tif (TOP20_ThreeWay_Valve_State === undefined) { return null; }\nvar Operating_Mode = global.get('TOP4_Operating_Mode_State', \"file\");\n\tif (Operating_Mode === undefined) { return null; }\nvar current_sp = global.get('TOP43_Z2_Water_Target_Temp',\"file\");                        // TOP27\n\tif (current_sp === undefined) { return null; }\nvar TOP76_Heating_Mode = global.get('TOP76_Heating_Mode', \"file\");                     // TOP76 - Compensation curve or DIRECT mode\n\tif (TOP76_Heating_Mode === undefined) { return null; }\nvar ccc_state = global.get('F_CCC.z2.state', \"file\");          // Get the global variable. Used to see if the WAR function is enabled.\n\tif (ccc_state === undefined) { ccc_state = 0; global.set('F_CCC.z2.state', 0, \"file\"); }\nvar TOP94_Zones_State = global.get(\"TOP94_Zones_State\",\"file\");\n    if (TOP94_Zones_State === undefined) { return null ; }\n\n//******************************************************************************\nvar war_ot1 = global.get('F_CCC.z2.ot1', \"file\");                             // Outside temperature high         (warm outside)\nvar war_ot2 = global.get('F_CCC.z2.ot2', \"file\");                             // Outside temperature intermediate (intermediate outside temperature)\nvar war_ot3 = global.get('F_CCC.z2.ot3', \"file\");                             // Outside temperature low          (cold outside)\n\nvar war_wt1 = global.get('F_CCC.z2.wt1', \"file\");                             // Water temperature low            (cold water)\nvar war_wt2 = global.get('F_CCC.z2.wt2', \"file\");                             // Water temperature intermediate   (intermediate water temperature)\nvar war_wt3 = global.get('F_CCC.z2.wt3', \"file\");                             // Water temperature high           (warm water)\n\n//******************************************************************************\n\nvar SP_start = global.get('F_CCC.z2.SP_DIRECT_virt', \"file\");                       // Get the global variable for SP_DIRECT_virt. Value is set through the dashboard\nif (TOP76_Heating_Mode === 1 && (SP_start < 20 || SP_start === undefined || TOP94_Zones_State === 0)) {\n    SP_start = 20;\n    global.set('F_CCC.z2.SP_DIRECT_virt', 20, \"file\");\n}\nif (TOP76_Heating_Mode === 0 && (SP_start > 5 || SP_start === undefined || TOP94_Zones_State === 0)) {\n    SP_start = -5;\n    global.set('F_CCC.z2.SP_DIRECT_virt', 0, \"file\");\n}\n\n\nvar check = (war_ot1 + war_ot2 + war_ot3 + war_wt1 + war_wt2 + war_wt3);\nif (isNaN(check) || check === undefined)     // if the variables are added to eachother and the result is Not a Number, produce an error message.\n{\n    msg99.payload = \"<font color=red>Profile temperatures are not correctly set in the dashboard. Waiting for Panasonic import or user input</font>\";\n    msg99.topic = \"Function CCC (Zone 2)\";\n    global.set('F_CCC.z2.state', 0, \"file\");\n    global.set('F_CCC.z2.setpoint', SP_start, \"file\");\n    return [null, msg99];\n}\n\nif (war_wt2 < war_wt1 || war_wt3 < war_wt1) {\n    msg99.payload = \"<font color=red>Temperature profile is inverted and not setup correctly. This requires your attention. CCC-function disabled</font>\";\n    msg99.topic = \"Function CCC (Zone 2)\";\n    global.set('F_CCC.z2.state', 0, \"file\");\n    global.set('F_CCC.z2.setpoint', SP_start, \"file\");\n    return [null, msg99, msg99];\n}\n\nvar SP_ccc;                                                                     // set empty starting variable\n\nvar war_Tb = global.get('T_outside', \"file\");                           // Outdoor temperature.\nif (isNaN(war_Tb) || war_Tb === undefined || war_Tb < -50)             // if the variable is Not a Number, produce an error message.\n{\n    msg99.payload = \"T_outside is not valid. Waiting for correct value.\";\n    msg99.topic = \"Function CCC (Zone 2)\";\n    //global.set('F_CCC.z2.setpoint', SP_start, \"file\");\n    return [null, msg99];\n}\n\nvar F_CCC_old_SP = global.get('F_CCC.z2.setpoint', \"file\");\nif (F_CCC_old_SP === undefined) {\n    F_CCC_old_SP = SP_start;\n    global.set('F_CCC.z2.setpoint', SP_start);\n}\n\n\n////////////////////////////////////////////////////////////////////////////////\n//      Calculation of the NR WAR Setpoint\n////////////////////////////////////////////////////////////////////////////////\n\n\n\nif (war_Tb >= war_ot1) { SP_ccc = war_wt1; }                                         // Range 1\n\nif (war_Tb < war_ot1 && war_Tb > war_ot2)                       // Range 2\n{ SP_ccc = (((war_wt1 - war_wt2) * ((war_Tb - war_ot1) / (war_ot1 - war_ot2))) + war_wt1); }\n\n\nif (war_Tb <= war_ot2 && war_Tb > war_ot3)                      // Range 3\n{ SP_ccc = (((war_wt2 - war_wt3) * ((war_Tb - war_ot2) / (war_ot2 - war_ot3))) + war_wt2); }\n\nif (war_Tb <= war_ot3)                                          // Range 4\n{ SP_ccc = war_wt3; }\n\nSP_ccc = Number(SP_ccc).toFixed(1);\nSP_ccc = parseFloat(SP_ccc);\n\n\n////////////////////////////////////////////////////////////////////////////////\n//      Compensation curve being used. WAR function not allowed.\n////////////////////////////////////////////////////////////////////////////////\nif (TOP76_Heating_Mode === 0) {                    // Compensation Curve\n    if (ccc_state === 1) {\n        global.set('F_CCC.z2.state', 0, \"file\");\n        msg99.payload = \"Compensation curve active. Using internal Panasonic WAR function. NodeRed WAR function is now disabled\";\n        msg99.topic = \"Function CCC (Zone 2)\";\n        return [null, msg99];\n    }\n    //if (ccc_state === 0 || ccc_state === undefined) { SP_ccc = SP_start; }\n    global.set('F_CCC.z2.setpoint', SP_ccc, \"file\");\n    msg1.payload = SP_ccc;\n    return [msg1, null];\n}\n////////////////////////////\n\n\n////////////////////////////////////////////////////////////////////////////////\n//      Direct mode > WAR function allowed.\n////////////////////////////////////////////////////////////////////////////////\nif (TOP76_Heating_Mode === 1) {                // Direct\n    if (TOP20_ThreeWay_Valve_State === 1 || Operating_Mode === undefined || current_sp === 0 || TOP76_Heating_Mode === 0 || Operating_Mode === 1 || Operating_Mode === 3 || Operating_Mode === 5 || Operating_Mode === 7 || Operating_Mode === 8) {\n        return null;                                                        // If state is 1 (DHW mode), correction 0 is direclty exported to the message and the function ends here.\n    }\n\n    msg1.payload = SP_ccc;                                                         // required\n    msg1.topic = 'SP_war';\n    msg1.source = 'WAR';\n\n    if (ccc_state === 0) {                                            // If the state is 1 (enabled), AND outside temperature contains a value.\n        global.set('F_CCC.z2.setpoint', SP_start, \"file\");\n        msg1.payload = SP_start;\n        return [msg1, null];\n    }\n\n    if (ccc_state === 1) {\n        msg1.payload = SP_ccc;\n        if (SP_ccc === F_CCC_old_SP) {\n            return [msg1, null];\n        }\n        else {\n            global.set('F_CCC.z2.setpoint', SP_ccc, \"file\");\n\n            msg99.payload = \"Setpoint change: From \" + F_CCC_old_SP + \" to \" + SP_ccc + \" °C\";\n            msg99.topic = \"Function CCC (Zone 2)\";\n\n            return [msg1, msg99];\n        }\n    }\n    ////////////////////////////////////////////////////////////////////////////////\n\n}",
        "outputs": 3,
        "timeout": 0,
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 2700,
        "y": 820,
        "wires": [
            [
                "d625be872191a9a8"
            ],
            [
                "663fd79ce5a1610d"
            ],
            [
                "161478f41649a6fa"
            ]
        ],
        "outputLabels": [
            "SP_CCC_Z2 (function on)",
            "ToLog",
            ""
        ]
    }
]

Als zone 1 in gebruik is, zet ik zone 2 op de minimum waarde
Als zone 2 in gebruik is, zset ik zone 1 op de minimum waarde

[Nnoitra]

edterbak schreef op donderdag 4 december 2025 @ 14:00:
Ik heb denk ik een fix.
graag even kijken of dit werkt.

kun je het importeren en overschrijven?
het zijn de 2 CCC functie nodes.

Als zone 1 in gebruik is, zet ik zone 2 op de minimum waarde
Als zone 2 in gebruik is, zset ik zone 1 op de minimum waarde

Komende dagen past het niet echt, maar volgens mij wordt die waarder verder niet gebruikt. Dus er valt niets om.
Ook weet ik niet of ik het kan testen, angezien ik de NR - CCC helemaal niet gebruik / ze staan beide uit..

In het kader van simplify; wat is het doel van die waarde tussen haakjes? Het uiteindelijke setpoint, welke gebruikt word, staat erachter in bold.
Je zou die "( *° C)" gewoon weg kunnen laten, scheelt weer een stuk(je) logica.

[Roger_de_Poger]

edterbak schreef op donderdag 4 december 2025 @ 12:24:
je kunt de geimporteerde JSON even editen. find>replace uitvoeren.

dan alles verwijderen in je node red zelf weer, en opnieuw importeren met de gecorrigeerde base

Thx!

[edterbak]

Nnoitra schreef op donderdag 4 december 2025 @ 10:30:
[...]

Dat zat in een vorig versie, die heb je vervangen door die filter. Ik meende dat het een Round was, maar kan ook wat anders zijn geweest.
Geen data meer van..

Wat ik eigenlijk bedoel. Voor zover ik kan opmaken uit je reactie, is dat je het filter niet daadwerkelijk getest hebt.
Het kenmerk van de Kalman filter, is dat deze bij nauwkeurige signalen eigenlijk niets doet.
Dus het zou zomaar prima kunnen zijn dat je er geen invloed van ziet.

Om dit te testen, kun je dit doen.

[Nnoitra]

edterbak schreef op donderdag 4 december 2025 @ 20:17:
[...]


Wat ik eigenlijk bedoel. Voor zover ik kan opmaken uit je reactie, is dat je het filter niet daadwerkelijk getest hebt.
Het kenmerk van de Kalman filter, is dat deze bij nauwkeurige signalen eigenlijk niets doet.
Dus het zou zomaar prima kunnen zijn dat je er geen invloed van ziet.

Om dit te testen, kun je dit doen.
[Afbeelding]

Als ik het niet had getest, had ik niet gezien dat de waarde uit de Filter functie (te veel) afwijkt van de daadwerkelijke temperatuur.
Hier een screenshot met 2x een debug, want die chart werkend krijg kost me meer tijd dan ik nu ff heb.

Om goed te sturen wil ik gewoon die 21.5 als Room Actual, de waarde die de thermostaat aanlevert.