Multi zone air conditioning control system


I have a large ducted reverse cycle unit, which is getting old, but I have managed to keep it going by replacing contactors and fan motors as required. I should note that I am a licenced electrician, so I can do things myself that the normal home owner would have to get someone else to do. I am also comfortable writing Javascript and to a lesser extent bash.


My thermostat went a couple of years back. Originally I used a couple of Arduinos connected by radio link to control the AC. One to sense the temperature, and one to control the AC unit. This worked OK, but I wanted to expand the temperature sensing to all rooms, so they could be automatically controlled. I made a prototype battery powered arduino based unit, but then various factors made me change tack:

  1. Similar WiFi and Bluetooth units are now available off the shelf
  2. Aesthetic packaging of custom arduino projects is a problem
  3. This solution is difficult to maintain and upgrade, e.g.

a. What happens if I succumb to Covid-19?
b. If I want to change the code, I need to reflash the arduino and it is difficult to debug

My desired outcomes were:

  1. Have something that was easy to maintain and upgrade
  2. Use off the shelf hardware as much as possible (for reasons for requirement 1).
  3. Aesthetic packaging of long lasting battery operated sensors in each room, which then meant that each room could be separately controlled.


Given all this I decided to follow an IoT methodology

  1. Initially I tried using Hassio, but that proved to be quite a hassle. There seems to be a number of ways to implement this, and when trying to sort things out I couldn’t sort out which system the websites I ended up visiting were talking about, and ended up in a mess.
  2. I then tried node-red, and it worked out to be a perfect fit. It has an easy GUI for broad brush configuration of the system, and then allows javascript programming for the “dirty details”. Changing something is a breeze. I am currently experimenting with subflows to avoid the problems with maintaining multiple duplicate pieces of code (e.g. one for each room).
  3. The system I ended up using uses:

a. Unmodified Sonoff 4 channel devices for the output. I know purists will not like this, as I am dependent on eWelink, and I might get round to flashing the Sonoffs sometime, but it does mean it is easy to maintain. These have proved to have a problem with receiving too many instructions at once, so my code will only send 1 command per 5 seconds to any one device. This has proved to be reliable, but I also have background code that checks my outputs are what they should be, just to make sure.
b. Xiaomi BLE (LYWSD03MMC) temperature and humidity sensors. I did originally try using a Sonoff sensor, connected via IFTTT, which then emailed node-red to control the AC, but that proved unreliable. These seem to do the job well. I am adding code to monitor how long since I got a reading from them, and to alarm if it is too long. I also want to add code to monitor the battery voltage and alarm if it is getting too low.
c. An old Windows XP netbook now running Linux Mint as the server. This is as slow as a wet week when using it locally, but as a node-red server, accessed via SSH, it works well. I have a BLE dongle plugged into a USB port to talk to the sensors. Initially I thought I would use this as a photo frame screensaver, which would then show the GUI if touched, but it just doesn’t have enough grunt to do that. Using the GUI on our mobile phones works well, so that is all we need.
d. To talk to the Xiaomi devices, I use a bash script running on the server, which is then called by node-red functions and returns the relevant values. I looked at various node-red BLE nodes, but none seemed to be able to talk to the LYWSD03MMC device. I found a bash script which did so, and modified that to suit my purpose, adding battery voltage. I am going to have to do more mods to this to cope with using subflows.

  1. I have implemented the system this weekend, and it has been working well apart from some specific issues:

a. When deploying, the stored username and password for the eWelink gets lost or garbled and I have to reset that (not difficult, but annoying)
b. Occasionally when deploying, the bash script stops working properly for certain sensors. Redeploying can clear this problem.

Any suggestions welcome.

Wow! Sounds like fun.

Since you are using Node-Red, one thing you could do is keep the device's functionality simple.

As I read it you have some smarts in there and are worried about updating it.

What you could do is make that only a simple "switch" and all the smarts done in Node-Red.

Sorry, I haven't read all the post. I'm a bit distracted with other things just now.

But that is my 2cent's worth on that part of the problem.

1 - Are you saying that when you deploy, the the uesrname and password need to be re-entered in NR and the flow deployed again? What node are you using (node-red-contrib-xxxx?)

2 - how are you running the bash script

3 - are you doing a Full, Modified Flows or Modified Nodes deploy?

4 - what versions of NR and node;js are you running (see startup log)

Are you saying that when you deploy, the the uesrname and password need to be re-entered in NR and the flow deployed again?
I have been resetting it by selecting "Configuration Nodes", where the ewelink-credentials are now a hexadecimal? string, and double click on that, and click on Update, and deploy again.

What node are you using?
I am using node-red-contrib-ewelink

How are you running the bash script?
I am using an exec node. I currently have a number of them (one for each sensor), and it is only certain ones that fail, but they vary, and running the script on the command line for that sensor is fine.

Are you doing a Full , Modified Flows or Modified Nodes deploy?
Full, I suppose I should experiment with that. I need to do at least a Modified Flows to get eWelink to behave again.

What versions of NR and node;js are you running (see startup log)

  • Node-RED version: v1.0.3
  • Node.js version: v12.16.1

Try using "Modified Flows"

When you loose connection, what happens if you stop/start NR? Does it connect to the ewelink? This wll tell us if the password is corrupted or is the connection just lost.

Note, there is an issue with node-red-contrib-ewelink node: Does not reconnect once connection is briefly interrupted #84 that was reported back n January. It may be related to your issue.

If I restart, or stop and start node-red, eWelink generally stays up. I have seen similar error messages to that reported in the issue mentioned.

That is not my major issue, it has an easy work around. My main problem is the bash scripts not reliably working as expected.

What are the settings in the exec node you are using to tun them?

No append, no parameters, exec mode, 40 seconds timeout

Having changed the deploy to 'Modified Flows' are the exec nodes running the bash in the flows you modify and deploy?

They have always run, but somehow something goes wrong in the running - various error messages are sent back.

With more testing, and moving the server, it is working reliably (fingers crossed), so maybe it was just at the limit of the BLE.

1 Like
[quote="andrewa, post:10, topic:24303"] various error messages are sent back. [/quote]

't would help if you posted these errors.

Good to see you got it working.

But still, it may help if you did post the errors.

This is all working well now, even have the fans and ducts and so on coming on or off in an appropriate sequence. Node-red certainly makes modifying things easy.

Using Modified Flows on deploy has solved the problem with eWeLink forgetting its credentials.

However I do have a question about my bash script to talk to the LYWSD03MMC devices using ble. It uses gattool, but I saw somewhere that this is deprecated. Is there something I should use instead? I presume it is not going to disappear in the near future?

This topic was automatically closed after 60 days. New replies are no longer allowed.