New air-con, part 3

Before I give the run down on the new air-con, I want lots of nice graphs showing how the temperature works, and these take time. The simple summary is that I am impressed. So more in part 4, and lots of photos.

But in the mean time - my little WiFi modules for the Daikin air-con. They work really well, and I have the temperatures coming in now. I am sure there will be some fine tuning.

I also have a web interface, to allow simple local control. I have worked hard on the niceties like easy setting WiFi client mode and so on - this being an areas where the Daikin modules really sucked. These are really annoying fiddly things with web sockets and wifi client connects and DHCP and all sorts - really silly small things that take all day. So slow progress for a change. But this should be really good.

So at this point the idea is that these WiFi modules allow local (web) control, and MQTT control which can be local or external and even secure mqtts if needed - ideal for building management, and no "cloud" shit via a third party. That is working well. A nice touch would be to support the old Daikin http URLs as well, which I may yet do.

But there is more...

One of the things I did in my old house was rather convoluted. It was an MQTT connected app on my linux box that poked the http URLs on the old Daikin WiFi module to provide some MQTT access and control. That combined with a separate tool on my linux box that talked MQTT to that app and the environmental sensors. The result was a really neat and tight temperature control using the environmental sensor as the reference. But it did mean tuning these background tasks on my main linux box.

However, I am taking a new approach now - the WiFI modules talk MQTT directly. And the environmental monitors have evolved to have a time profile temperature for controlling central heating as well. That works well with a Shelly Plus 1 (well several) doing heating and water and so on. So the new approach is that the environmental monitors report over MQTT directly to the WiFi control modules - saying what temp they see now and what target they want (or min+max if needed).

(I had a slight issue that heating is set off in bedrooms during day, as you expect, but with a min of say 18C, which is fine for the central heating, but the air-con meant it though that if that was turned on it had to cool to 18C. I have since made it have a wide range define for idle times to avoid the air-con being silly).

The WiFi module then has an local auto mode override. Much like the wired remote which tells the a/c to be cool or heat with appropriate targets, rather than trusting its auto mode, my module can do the same.

But, as always, I reinvent even my own wheels. The direct access to the a/c makes it much more responsive, so I can create a much nicer algorithm. It is always fun making any control/feedback loop system, and more so when you are second guessing the system you are talking to. Some experimentation, and a lot of settings to allow fine tuning, and I found I have to tell the a/c to heat or cool 1.5C beyond where it things it is before it will turn on or off the compressor as required. So I can compensate for its hysteresis and apply my own rules.

Obviously for efficiency you want to avoid rapid heat/cool switch overs, so I have temperature and time controls for that. But I can tweak the target temperature in real time to make it do what I want.

This is a good example, it is my office during the day today. And we have a fun case where this time of year the temperature now is close to what we want, in this case 21C. So no aircon may be better. However it is a good test of the algorithm to test in this edge case of spring/autumn - when it is really hot outside or really cold outside is an easy case.

What is interesting is that it actually went wrong. At 13:40 ish it switched to heating (the heavier line), and it should not have. I have since found the edge case, the temp only just touched the target on previous cycle, not passing it (difference of > and >=) which meant it thought it had been under temp for over 15 minutes which is enough to trip to heating. I also have a min time it stays heating or cooling, but had been cooling all day (starting 7am). I have since fixed this, so today it would have stayed cooling.

Even so, it is otherwise keeping within around 0.2C or 0.3C of target temperature. Basically it should have wandered off below the line for a while, i.e. the room naturally cooler than 21C, before it switched to heating. We'll see that in the autumn now, or who knows? Maybe next week. This is Wales.

Just to be clear - we are not turning it off and on, or changing between heat and cool all the time, this is just small adjustments to the target temperature and letting the Daikin a/c decide what to do as a result.

What is also interesting is the power usage. When installed on 1st, I was using the controller remotes, not my own code, setting a temp in auto mode. Even the early WiFi module code on 2nd and 3rd was not doing this smart control. The result was a lot more power usage.

As I refined the code over the last few days, making a big difference when I started on the 4th, it has ended up much more efficient. Today, for example...

We get solar in next week, which will provide enough power to more than cover this, thankfully.

But the result of all this is my environmental monitor and air-con Daikin WiFi control modules allow much nicer control. I think we may have to start selling them :-)

Part 4

No comments:

Post a Comment

Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

NOTSCO (Not TOTSCO) One Touch Switching test platform (now launched)

I posted about how inept TOTSCO seem to be, and the call today with them was no improvement. It seems they have test stages... A "simul...