Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Best practice and expected behaviour when controlling eq3's #62

Open
WNTLtd opened this issue Mar 9, 2021 · 4 comments
Open

Best practice and expected behaviour when controlling eq3's #62

WNTLtd opened this issue Mar 9, 2021 · 4 comments

Comments

@WNTLtd
Copy link

WNTLtd commented Mar 9, 2021

Not really an issue, more of a use case....

I have 9xEQ3s all controlled from HA, via this brilliant Wifi-BLE bridge code. (Mega thanks to Paul and the others!!!)

Q. What are people's suggestions in terms of the way you interact with them.
For instance - I currently have it all set up in NodeRed, where from a front end setting of a temperature on the Generic Thermostat in Home Assistant; NR then looks to see if 'that room' is either in 'schedule override' or 'on' schedule for the heating to be on, checks the current temperature (from a separate Temp/Humidity sensor in the room), and it then sends the relevant MQTT "on" or "off" message.

The said TRV then goes on or off - until then temperature in the room has equalled the set temp.

However, this is obviously having the effect of ramping as the heat inevitably goes over the set temp while the radiator is still HOT after turn off.

How can I flatten this hysteresis?
Is it best to send a "settemp xx" message and let the TRV decide?

The other question I have is that sometimes my MQTT broker comes back with "Device Unavailable" or " TRV not found" (What is the difference BTW?) and in that case - I'm resending the MQTT command, until I get a sensible reply. Is that the correct way to do it, or am I misunderstanding the whole concept of MQTT.
I'm currently sending with QOS 1 and Retain False.

So say I do just send it a settemp command. Once that temp has been reached, should I still be sending it an OFF command? Or will it do that by itself? In other words say I wanted the room to be at 21deg for 2hours - I send the command settemp 21, and then 2hrs later send the off command. During those 2hrs does the EQ3 regulate the room temp itself to 21deg?
Only, with the temp sensor in the TRV so close to the rad, my feeling was that the temp sensor up on the wall would be better suited to read the correct room temp? But then that would mean me controlling the on/off of the TRV as I'm already doing. But I'd prefer to be able to open the TRV slightly and not just FULL ON of Nothing.

Suggestions please.

Ta.

@larkingabout
Copy link

Just my take, Firstly Dont let the valve do the 'thinking' as you say its sat next to the radiator so will read hot prematurely and while you can cater for this by using the temperature offset feature this would require more anaylsis and specific values for each radiator making life very complex. Set the eq3 to manual and send open and close or boost commands as needed.

Having 2x or more temp sensors per area as well as the radiator input is probably the best way to monitor the actual temperature, the xiaomi ble sensors are dirt cheap £3-4, and the xiaomi miflora plant pot sensors take temperature readings too, and to read the ble sensor data openmqttgateway(OMG) is another esp32 based project for that job..

To try and hit a target temp say 20c in a particular room try logging temperature readings with your system as is and check the data for signs of a consistent rise above the target in each room after valve closing. If a room rises consistently by 2c you could attempt to set the target 2c lower.. run for a day or 2 and recheck temps.. rinse and repeat to refine.

Each room will need its own analysis and factors such as doors left open may have a significant impact if leading to unheated areas. however its a very quick check, and easy to test.

Yes if unreachable Loop (With a delay 60-300 seconds) a resend until a successful ack is received. you can delve into QOS but from my perspective life is way too short.

TRV's are on/off devices think digital vs analogue the way to throttle a radiators flow is via the valve covered at the other end of the radiator, remove the cap, set the valve to the flow rate you want and rely on the trv to just open and close the flow.

@llemtt
Copy link

llemtt commented Mar 11, 2021

I do let the valve do his own job and then I adjust the offset based on temperature readings from xiaomi ble sensors. It works well even if my home has poor thermal insulation, the most difficult scenario to handle is a huge daily exterior temperature range.

To optimize consumption I use also a fundamental parameter which is the water temperature from the heater.

For maximum efficiency water temperature should be kept as low as possible with valve opening at 100%.

I also don't like to set the valves fully closed because it puts to much stress on my heater pump.

It would be definitely easier with a direct control of the valve opening.

@WNTLtd
Copy link
Author

WNTLtd commented Mar 11, 2021

Thanks for both your thoughts.

I think I'm going to go with adjusting the return valve to limit the flow in certain rooms - as I already plot the graphs in Grafana - and can see that certain rooms get hotter a lot quicker than others - even though my xiaomi sensors are all roughly the same distance from the rads.
Some rooms rads a bigger than others though - hence I'm going to try limiting their flow on the return valve.

I'll also add a caveat into the NodeRed flow to turn off the the eq3s just before they reach the desired temp, to try and mitigate overshoot.

I have a spare xiaomi - and I'm considering putting that outside. That way I can monitor the actual outside temp verses an inside temp, and have some sort of algorithm that determines the offsets to apply to the desired room temperatures based on the outside temp. Kinda like a 'feels like' temp rather than 'actual' temp. (thoughts?)

I also realised the other day, that the window sensor in the EQ3 is completely automatic. Even if the EQ3 is set to manual.
Meaning that the status of 'window: open/closed' is really only for reporting back to the system.
So if the window sensor has detected that a window has been opened - the valve shuts off for 15mins.
I didn't need to program this - as it was already a feature! D'oh!

Again - thanks for your feedback.

@terragit
Copy link

I've 6 EQ3 BT installed for about two years and control them via multiple PiZeros which are distributed in my house. Now I want to add some ESP32 to even out some connection problems. No big problem but sometimes a TRV cannot be set for 10 minutes or so.

@WNTLtd
I'm quite surprised to find suggestions to not use the settemp feature but boost and on/off only. Hence, maybe my setup is interesting for you.
I did some tests and best result for me is when all TRVs are set to manual and window open detection is disabled. Manual mode set to a specific temperature resulted in the lowest temperature fluctuations over the course of the day. But this may also depend on the volume and speed of your heating pump. Mine is set to low speed to save energy.
Because all windows are equipped with reed switches, it's way more energy efficient to set TRVs to off till the window is closed. All rooms are equipped with temperature sensors. In addition, I've temperature sensors outside and in some walls to calculate dew point.
Node-red (NR) handles programmatic heating of all rooms, e.g. lower temp at night or when everybody left the house.
Depending on direct sunlight measured outside and outside temperature, NR reduces the temperature set at TRVs. When a window is opened, the TRV is set to off. Depending on overall conditions, there is a delay in activation of the TRV if the window is closed. In most rooms I found it unnecessary to boost heat immediately after closing the window.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants