Egyras
Zone heat request temperature values not applied when sent close together
I'm using the Home Assistant integration and when I set up an automation on there to set the temperature for zones 1 and 2, I found that the temperature is only set for one of the zones.
For example, at night I have an automation that sets both zones down to 15 degrees so that the heating goes off. I can see that the message for each zone reaches the Heishamon, as the messages both appear in the Heishamon log, but only one of them is applied.
If I set up two automations 1 minute apart to set the zones separately, e.g. set zone 1 at 23:58 and zone 2 at 23:59, then it works. I have the exact same issue with changing the mode from "Heat only" to "DHW + Heat", where if I try to change the mode and set a zone temperature at the same time, only one of these commands is applied.
I'm managing at the moment by keeping my automations spaced out by 1 minute, but I'd like to start setting the temperature based on room thermometer readings, which makes it harder to ensure that there won't be multiple changes within a short time.
Here's my Heishamon log showing that it receives two settings changes (set z1/2 heat request temperature), but only applies one (Z1_Heat_Request_Temp):
Sat Dec 6 12:35:23 2025 (497540888): Heishamon stats: Uptime: 5 days 18 hours 12 minutes 20 seconds ## Free memory: 69% ## Free PSRAM: 2074036 bytes ## Free heap: 241708 bytes ## Wifi: 50% (RSSI: -75) ## Ethernet: not installed ## Mqtt reconnects: 1 ## Correct data: 99.98% Rules active: 0
Sat Dec 6 12:35:23 2025 (497540892): Requesting new panasonic data
Sat Dec 6 12:35:23 2025 (497540893): sent bytes: 111 including checksum value: 18
Sat Dec 6 12:35:24 2025 (497541363): Received 203 bytes data
Sat Dec 6 12:35:24 2025 (497541364): Checksum and header received ok!
Sat Dec 6 12:35:24 2025 (497541365): received TOP1 Pump_Flow: 32.36
Sat Dec 6 12:35:24 2025 (497541367): received TOP5 Main_Inlet_Temp: 30.50
Sat Dec 6 12:35:24 2025 (497541370): received TOP8 Compressor_Freq: 19
Sat Dec 6 12:35:24 2025 (497541372): received TOP15 Heat_Power_Production: 6400
Sat Dec 6 12:35:24 2025 (497541374): received TOP62 Fan1_Motor_Speed: 350
Sat Dec 6 12:35:24 2025 (497541376): received TOP65 Pump_Speed: 4000
Sat Dec 6 12:35:24 2025 (497541378): received TOP67 Compressor_Current: 4.4
Sat Dec 6 12:35:25 2025 (497542537): set z1 heat request temperature to 26
Sat Dec 6 12:35:25 2025 (497542537): sent bytes: 111 including checksum value: 248
Sat Dec 6 12:35:25 2025 (497542591): set z2 heat request temperature to 26
Sat Dec 6 12:35:25 2025 (497542592): Already sending data. Buffering this send request
Sat Dec 6 12:35:26 2025 (497542924): Received 203 bytes data
Sat Dec 6 12:35:26 2025 (497542925): Checksum and header received ok!
Sat Dec 6 12:35:26 2025 (497542926): received TOP1 Pump_Flow: 33.07
Sat Dec 6 12:35:26 2025 (497542928): received TOP8 Compressor_Freq: 20
Sat Dec 6 12:35:26 2025 (497542930): received TOP15 Heat_Power_Production: 6600
Sat Dec 6 12:35:26 2025 (497542935): Sending command from buffer
Sat Dec 6 12:35:26 2025 (497542936): sent bytes: 111 including checksum value: 248
Sat Dec 6 12:35:28 2025 (497544938): Previous read data attempt failed due to timeout!
Sat Dec 6 12:35:28 2025 (497544939): Received 0 bytes data
Sat Dec 6 12:35:28 2025 (497545889): Heishamon stats: Uptime: 5 days 18 hours 12 minutes 25 seconds ## Free memory: 69% ## Free PSRAM: 2074036 bytes ## Free heap: 241708 bytes ## Wifi: 48% (RSSI: -76) ## Ethernet: not installed ## Mqtt reconnects: 1 ## Correct data: 99.98% Rules active: 0
Sat Dec 6 12:35:28 2025 (497545893): Requesting new panasonic data
Sat Dec 6 12:35:28 2025 (497545894): sent bytes: 111 including checksum value: 18
Sat Dec 6 12:35:29 2025 (497546337): Received 203 bytes data
Sat Dec 6 12:35:29 2025 (497546338): Checksum and header received ok!
Sat Dec 6 12:35:29 2025 (497546339): received TOP1 Pump_Flow: 32.36
Sat Dec 6 12:35:29 2025 (497546341): received TOP15 Heat_Power_Production: 6400
Sat Dec 6 12:35:29 2025 (497546343): received TOP27 Z1_Heat_Request_Temp: 26
Sat Dec 6 12:35:29 2025 (497546345): received TOP67 Compressor_Current: 4.2
Sat Dec 6 12:35:33 2025 (497550890): Heishamon stats: Uptime: 5 days 18 hours 12 minutes 30 seconds ## Free memory: 69% ## Free PSRAM: 2074036 bytes ## Free heap: 241708 bytes ## Wifi: 48% (RSSI: -76) ## Ethernet: not installed ## Mqtt reconnects: 1 ## Correct data: 99.98% Rules active: 0
Sat Dec 6 12:35:33 2025 (497550894): Requesting new panasonic data
Sat Dec 6 12:35:33 2025 (497550895): sent bytes: 111 including checksum value: 18
Sat Dec 6 12:35:34 2025 (497551310): Received 203 bytes data
Sat Dec 6 12:35:34 2025 (497551311): Checksum and header received ok!
Sat Dec 6 12:35:34 2025 (497551312): received TOP1 Pump_Flow: 33.07
Sat Dec 6 12:35:34 2025 (497551314): received TOP5 Main_Inlet_Temp: 30.25
Sat Dec 6 12:35:34 2025 (497551316): received TOP8 Compressor_Freq: 19
Sat Dec 6 12:35:34 2025 (497551318): received TOP15 Heat_Power_Production: 7400
Sat Dec 6 12:35:34 2025 (497551320): received TOP67 Compressor_Current: 4.4
Heat pump model is WH-MXC12J6E5 12 1ph T-CAP Heishamon version is reported as 3.9 on the web interface
Please let me know if there's any other info you need
@IgorYbema could you take a look at this? Why it's timing out while it tells that data is recived?
I think there's a buffering problem. Since the first command is immediately forwarded, the second command has to be buffered until the response from the first is received. This necessitates buffering the second command, which is also visible here:
Sat Dec 6 12:35:25 2025 (497542591): set z2 heat request temperature to 26 Sat Dec 6 12:35:25 2025 (497542592): Already sending data. Buffering this send request
After the response is received, the buffered command is sent:
Sat Dec 6 12:35:26 2025 (497542935): Sending command from buffer Sat Dec 6 12:35:26 2025 (497542936): sent bytes: 111 including checksum value: 248
This command does not arrive correctly at the Panasonic unit, resulting in the following error message:
Sat Dec 6 12:35:28 2025 (497544938): Previous read data attempt failed due to timeout! Sat Dec 6 12:35:28 2025 (497544939): Received 0 bytes of data
This command is simply lost during buffering or becomes corrupted.
This behavior is not new and is well-known, which is why I avoid issuing two commands simultaneously in my ruleset whenever possible. Additionally, for important commands, I check after approximately 12 seconds whether the change has taken place and, if necessary, send the command a second time.
But the log is in same second, shouldn't it be some time span between command's and response? Isn't 5sec is minimal?
Thanks. I think https://github.com/Egyras/HeishaMon/issues/507 is the most relevant here.
I originally reported this to the Home Assistant Heishamon integration project and they told me that because the commands are reaching the Heishamon, this is a Heishamon issue. They're obviously not aware of Heishamon's policy that users need to implement their own retry logic. This is important information that should be in the project documentation.
Would you accept a PR to update the readme to make this clear to users?
The problem clearly lies with the data transfer via Heishamon. I've implemented my automation using Heishamon- Rules and employ the following monitoring mechanisms. For example:
When I send a command, I first check if it's necessary. Then I send the command and maintain a counter "#SetCounts" that provides information about the write cycles, and I call a timer for follow-up checks. After 10 seconds, the timer checks whether the data in the Panasonic has been changed. If not, the command is repeated once, and the counter is incremented by 0.01. This allows me to see how often a 2nd Service was required. Such a control protocol should be achievable in any programming language and, in my opinion, is the simplest way to address the problem.
on StopSperrzeit then
if @External_Control != 0 then
@SetExternalControl = 0;
#SetCounts = #SetCounts + 1;
settimer(9,10);
end
end
on timer=9 then
if @External_Control != 0 then
@SetExternalControl = 0;
#SetCounts = #SetCounts + 0.01;
end
end
Thanks. I think this is a reasonable solution, it just needs to be documented to make people aware.
I've created a PR for this here: https://github.com/Egyras/HeishaMon/pull/767 . I'd be grateful if you could take a look!
I think it's just bug which need to be fixed somehow, we should wait for @IgorYbema, maybe he could find out..
Over the past few days, I've noticed in the console that even Heishamon standard commands can be lost. See the last 5 entries in the screenshot. However, the only effect is that the Panasonic data won't be updated until the next cycle (5 or 10 seconds later), as this was only a read request.
Line with "MQTT reconnects" gives me idea , if your "commands" topics have "ratain" flag ?
So after reconnect perhaps they can be executed again...
The problem clearly lies with the data transfer via Heishamon. I've implemented my automation using Heishamon- Rules and employ the following monitoring mechanisms. For example:
When I send a command, I first check if it's necessary. Then I send the command and maintain a counter "#SetCounts" that provides information about the write cycles, and I call a timer for follow-up checks. After 10 seconds, the timer checks whether the data in the Panasonic has been changed. If not, the command is repeated once, and the counter is incremented by 0.01. This allows me to see how often a 2nd Service was required. Such a control protocol should be achievable in any programming language and, in my opinion, is the simplest way to address the problem.
on StopSperrzeit then if @External_Control != 0 then @SetExternalControl = 0; #SetCounts = #SetCounts + 1; settimer(9,10); end end on timer=9 then if @External_Control != 0 then @SetExternalControl = 0; #SetCounts = #SetCounts + 0.01; end end
Hi McMagellan,
Can you point me a little bit to the right direction with this?
I am a heavy node red user with heishamon. I am in the process of building a controle function for watching mqtt commands and waiting until the command has been confirmed with the corresponding top. If not received within xx seconds, resend it. Although the function is almost complete, if something in the rules engine does the same job.. Then that would be awesome and better of course.
Can I just install this code in the generic rules thingy as you have posted it? Simple "copy/past" and done?
I have never used the rules engine before. Some wise words as guidance would be nice :)
Many thank in advance!!
It's just set/check/repeat implementation in rules, it will not work outside rules. This is as example.
Meanwhile, it's really bug in heishamon.. and it should properly identified and fixed..
Hello, @edterbak:
I'm not familiar with Node-RED. I use ioBroker with the Blockly programming environment. Since Heishamon rules started working flawlessly, I've implemented all my automation exclusively in rules and only use ioBroker for Grafana and simple statistics. Rules also work when the Wi-Fi is down, making them the better choice for me.
It's impossible to completely rule out the possibility of commands being lost when forwarded to the Panasonic device. Therefore, it's advisable to check at the source of the command whether it has been processed by the destination. This concerns the connection between Heishamon and the Panasonic device, for which there is no protocol information. This connection is used by four signal sources, and the chaotically arriving requests must be channeled through buffering: MQTT return channel, URL commands, rules commands, and the CZTAW proxy. Even if the MQTT connection detects an error and resends the command, the transmission to the Panasonic device remains unmonitored.
In Rules, it's relatively easy to implement by checking after a certain time, as described in my example, whether the command has been executed and then repeating it if necessary. I would do the same in another programming language, although it would then have to be implemented using the corresponding syntax. Therefore, my Rule is only usable in Rules.
In my last screenshot, you can see that the timeout message is logged exactly 2 seconds after the command is sent. This information is not available in Rules and cannot be used.
Since Heishamon firmware version 3.9, Rules has been sufficiently stable except for a few edge cases, and I have implemented 8 automations in my ruleset. These all run in the background, and it's still possible to influence the Panasonic parameters from a smart home system.
What does your Node-RED control function do? What do you want to achieve with this automation?
If you mean the node red flow thing itself I am using.. This is just a little dashboard I made. GHehehe..
https://github.com/edterbak/NodeRed_Heishamon_control
Am I correct in understanding that regardless of what application someone is using behind mqtt, the heishamon rules are fully isolated from that. Thus, your rule regarding mqtt throttling can be applied in the heishamon and will function perfecly, even for me as a Node Red user. right?
Wow, what a fantastic frontend you've built!
I don't use a frontend at all. If there's anything to program, I do it on the remote control or via URL commands in the browser.
Rules behaves like a remote control with "Basic" programming capabilities. All the TOP- parameters from the Panasonic are available, as well as the implemented control SET- commands for the Panasonic. However, there's no way to import data via MQTT, for example from Node-RED, into Rules to monitor it from there using a protocol.
The only thing our two automations have in common is the soft-start function: At startup, I check the difference between the main outlet and the main target every 10 seconds. If, for example, only 3K is missing, I lower the main target by 4K, which causes the compressor to quickly reach its threshold and regulate back down. At subsequent 5-minute intervals, I then restore the main target to its original value (2K steps). Should an overshoot occur, I will adjust the settings more quickly if necessary with my also integrated Bonusdegree- function.
I control the intervention in the main target by simultaneously shifting the heating curve target parameters (TOP 29 & TOP30). This ensures that TOP27 remains exclusively available for manual operation via the weekly timer or remote control.
However, there's no way to import data via MQTT, for example from Node-RED, into Rules to monitor it from there using a protocol.
OH. No no...., thats not what I am aiming at or meant The node red flow is doing its thing. sending stuff, receiving stuff. I am not looking to integrate the flow stuff with rules stuff or anything like that.
currently I am nearing completion of a node red flow which watches the sent commands watches the matching confirmation replies. If a command is not confirmed in time.. it resends it. It is a lot of code to write, test and debug to handle it correctly. And im not done yet. ...
I was wondering if your rules can basically do basically the same things. Manage sent commands and verify/resend them when needed. Independanltly of anything I do in node red. No integration needed from my requirements. Just completely stand-alone, do good stuff 😃
If so, I can stop the development of this controlling mechanisme of mine and I can put the rules you have built on my github page as instructions. I can spread it so people get less and less surprizes. 😄 And as a bonus the node red dashboard works more reliable.
I see it as two separate tasks. If we disregard the soft start in your integration, what remains is the setup handling, statistics, and graphs from historical data. Is this data retrieved from an InfluxDB database, or where is it stored? These applications are neither time-critical nor is it a problem if a command is lost, so it wouldn't actually be necessary to set up a 2nd service after every command. You're only experiencing this problem because your automation sent two commands simultaneously, presumably in conjunction with the soft start. With my rules, I continuously monitor the Panasonic controller and send corrective commands to the ongoing operation as needed to promptly correct deficiencies in the original controller.
This includes, for example: Controlling the upper hysteresis point to extend cycles by assigning bonus degrees Controlling the lower hysteresis point to extend cycle pauses Assignment of a dynamic lockout time during cycle pauses Softstart to limit compressor speed after start-up Kick start if cycle pauses become too long Kick start if the main outlet remains below the main target for too long Prioritization of the oil sump heater after a power failure
In addition, there is real-time monitoring and statistics on write commands in the Heishamon Console.
These are all things that happen automatically in the background and require no visualization or input form. The parameters are set and loaded at the beginning of the rules file. My rule is structured so that I avoid sending two commands simultaneously whenever possible, and I've only included a follow-up check when resetting the lockout time as a precaution, since this will have significant consequences in case of data loss.
I've been working on this ruleset for over two years. You need to know how rules work and, more importantly, have in-depth knowledge of Panasonic's control system. Furthermore, every installation has a different profile and hydraulic, so the program is only compatible with the system it's specifically adapted for. My intention was to demonstrate what's possible with Heishamon. However, a word of caution remains: theoretically, too many EEPROM write commands could destroy the controller, although I am not aware of any such case.