Jusbe
Forum Replies Created
-
Posts
-
Ok, there’s is some kind of a floor for r34 (curve) in the pump firmware. I had that min+1 limitation there, min set to 20, so min r34 command was 21. But every time r34=21, it would change to 40 in the pump. So I guess the r34=22 is something like a built-in minimum in the pump firmware, and with 21 it underflows. With r34=22 all is good. So, I set the minimum clamp to 22 in my program.
So, what I have is and all works well:
– Spot price classification with multi-hour lookahead (hourly price flags for next 24h, and then it makes decisions based on near future flags)
– Curve modulation, not EVU on/off
– Integral-aware steering with explicit minutes-to-A1 estimation
– Indoor temperature feedback with hysteresis
– Hot water optimization on a separate path
– Forecast integration for thermal banking
– Defensive write paths with audit and watchdogYes, the issue was that the min “curve” (minimum water temp for return line) was bigger than r34 curve value I was commanding, so the r34 (curve) got underflow inside the pump. Has not happened anymore. I also made a rationality check, it read the r35 (min temp), and adds +1, and uses that as the minimum clamp for the r34.
So basically, next is to try that hot water optimization again, because that was not the issue. But this will take some time since I have to go for a 2-3 week work trip and I don’t want anything funny happening with the system when I’m gone (even though I have remote connections etc).
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.
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.
