Corruption with r34 (heating curve)
- This topic has 3 replies, 2 voices, and was last updated 10 hours, 9 minutes ago by
.
-
Posts
-
Hello,
I’ve made quite sophisticated control system for the heat pump. It’s a model predictive controller for controlling when to overheat (longer, cheap prices) and when to try preventing heating, or heat less time (expensive). I’m using register r34 (curve) for that.
Because of a Nodered (v4.1.8 running on latest HA) corruption OR something fishy happening in MQTT, the pump gets r34 = curve as “40” for no reason sometimes, which means it tries to heat the house indoor temp basically almost 20C higher what it is. I have different curves for different outside temperatures (because of sunshine, outdoor humidity => dampness etc). My indoor target setting is fixed to 21 in the pump, and I’m using 23-25 r34 (curve) normally, depending on the weather. So curve being “40” has a huge impact on the heating deficiency, basically the r19 integral sinks fast to <<-400 and never recovers. When the curve goes to “40”, even my manual state change does not go through to the pump, I have to go to pump display and change it manually to what it is supposed to be (23 or so).
The r34 changing works fine 99% of times, but then for some reason it gets that “40” sometimes.I have made audits and debugs in my software and they proof that the “40” does not come my software. I have also safety clamps there to allow only 21..27 curves to ThermIQ MQTT out. So it should not be possible, but yet that happens.
I’m using r34 to control my r19 integral’s change speed, aiming pump starts to cheap hours, calculating time to reach A1 (integral limit to start pump), etc. I also have a Ruuvi tag to monitor indoor temp, and to prevent excessive overheating. My house has about 150 tons of concrete inside the insulation (basically all except windows and doors are U=0.1), so dynamics are slow and that is why my control offsets for r34 is set quite conservative (-2..+2 from what the base r34 is).
Has anyone else experienced that? I also have filters in the program so that it is writing to MQTT out pump interface only when r34 value has to be changed, and output is filtered so nothing more frequent that 5 min can be written in the interface, to prevent congestion of the MQTT with ThermIQ. Can it be a problem with the ThermIQ card? Or a problem with Node-red function corruption?
I’m using ThermIQ-Room2 with Thermia Diplomat from 2014.
Interesting usecase!
I’ve thought about implementing similar, adjusting curve to control timing of runs but I went the way of adjusting “actual indoor temperature” instead.Anyway,
ThermIQ shall by itself never generate a write to the HP but always be started by MQTT, and all MQTT goes through the server.You should be able to log all MQTT activity to the card through the MQTT server and my first step would be to log all MQTT writes to r34, AND logging all changes of r34 when reading out.
Is there any unexpected writes to r34?
Are there any other writes just before the readout changes in r34?
Are there any other activities just before the readout changes in r34?I think it’s good that you thottle the amount of writes, I believe the value is stored in an EE-flash in the heatpump CPU, and at least mine is a Microchip cpu with high but not unlimited writecycles.
Thermiq is able to handle a high amount of MQTT messages per second but I have not meassured any limit…
My selected curve is 49.
To me this sound more like the heatpump-cpu locking up for some reason. [But I’m of course partial 🙂 ]
Thanks for your response!
I might have found the root cause. I was using r44 (hot water start temp) to trigger hot water heating mode on during cheapest hours, maximum couple of hours before usual shower time. Then after the hot water mode starts, I return r44 back to my default 40.
But apparently, this r44 = 40 went SOMEWHERE to r34 register, not in my program, but in MQTT, or in ThermIQ or in the pump. But only sometimes. When when r34 got that “40”, everything in the MQTT write became unresponsive. Nothing could be written, or I couldn’t use fallback write back to 23 curve, but read from ThermIQ worked fine. This backs up your theory that the pump cpu or firmware might have been the real root cause. So, I removed all r44 related from my program, and now all works well with r34. I have logging active in mosquitto broker and it logs also everything going to ThermIQ interface. Looks like I’m all good.
So r34 is the only thing I’m writing to MQTT, and that is enough for me. It’s sad that I had discard my hot water heating optimization, but well, you don’t always get everything you want.
And, I’m having the original FW in my Diplomat, so… I haven’t able to find a newer one and this one works (I have found only one bug from it, +5 and -5 C curve offset changes the curve drawing opposite way).
But yeah, I have a nice setup going on with my house heating optimization. Works really nicely. I have to say the logic and the controller were not that simple to make.
Hello again.
I _think_ I have found the root cause. Since I’m manipulating the r34 (curve) from Node-red, I give the pump small r34 to delay the heating and bigger r34 to start heating faster / more. It plays with the r34 set value all the time to control r19 integral speed, and when the pump runs, tries to overheat with higher r34.Like I said I have typically the “base” curve set to 23-25 (depending on things, inside temp, outside temp etc) which is the “reference” for those conditions, and then the price control uses -3..+3 offset to that depending how we want to control the r19 integral behavior. When pump runs, I have allowed -2..+2 offset to base curve value.
My curve min and max were set as 22 and 40. And when I commanded r34=21 to pump, I think it got underflow in the pump (21<22 (minimum), and it set the curve r34 to 40 in pump firmware. I now put the min curve in the pump to 20, so this underflow should not happen anymore. I’ll keep monitoring how it behaves.
- You must be logged in to reply to this topic.
