Jump straight to the code! (Although I’d recommend reading the blog).
Where are we…
It’s been some time since my first few articles. Other commitments (i.e. Work and life) have dominated my time, meaning the heating project has been sat cold, gathering dust. I’ve received some interest from fellow JG owners which has invigorated the motivation to publish the final rendition of this project.
So far, my system (UH1s, PRT-Ns, etc) have been faultless. However, from chatting around, others are not so fortunate. Reports of wiring issues, failing Touchpads, faulty stats to mention but a few issues. Worse still, I’ve been told that the product line from JG has deprecated. They’ve moved from wired to wireless with their JG Aura range. Rumour has it that they were suffering support woes with poorly wired systems (during installation) causing a massive burden on their support services. A neighbour of mine recently contacted them for support to be told his system was obsolete and unsupported. Not good, especially as things start to fail. Replacing all the system is a costly affair that is clearly going to hurt the pocket. Depending on what fails, my hope is to run a hybrid system as the older units fail, possibly using the heating interface to mesh the whole system together.
I haven’t done a lot of research into the new wireless systems, I’m assuming each unit just needs power, either battery or wired. I can reuse the 12v supply from the current system a permanent source of power. I’m guessing the relay switching that currently occurs in the stats has probably been migrated to the UH1 replacement, the stat I imagine just acts to manage schedules and temperature, sending an “on” and “off” command (wirelessly) to a central unit. Maybe I’ll look into this as a separate article. It’s better to have a solution sooner than being caught short with the failure of [worst case] a UH1, which would render 50% of my system inoperative.
Down to business – talking the talk…
I don’t want this article to become unmanageable, for both writing or reading, so I’ll get down to business without delay. I had some changes in concept from my original articles. I intended to use Particle Photon as the “brain” of the system, debugging was becoming a massive headache, plus the working with the C language was proving to be cumbersome.
I decided to scrap the Photon and replace it for the new generation Raspberry Pi 3. It’s cheap, portable and has loads of online support. Windows is my home OS, so I had to dust off my Linux knowledge to build the Pi. My language of choice was Python, I’ve never written anything using it before, but I liked the concepts and language syntax. After many tutorials and tinkering sessions, I was ready to begin sculpting the new heating software.
The rough sketch above is a similar concept to what I’d scoped with the original design. The idea is that the heating bus is interfaced via the RJ485 network via a WiFi bridge, the Raspberry Pi acts as the brain. It does the talking to the heating system and implements the heating protocol. It also exposes an interface for any other device or software to send commands and manage the heating.
Inside the Raspberry brain
A crude sketch of the Python software which I’m hosting inside the Raspberry Pi (rPi3). There a four aspects to the software:
- Main process: The heart of the system. The main process sets up all the other processes and passes message between the different processes.
- Web Socket: At the time of implementation, web sockets are a fairly new idea that is supported within most popular web browsers. It effectively provides a mechanism for a web browser to connect directly to heating manager and receive a live stream of data in and out of the system without disconnection. TCP/IP sockets are by no ways a new concept and form the backbone of network communications, the web socket builds on top of this and implements the mechanisms and security necessary to do this from within a web browser.
- Heating process: Manages the communication with the heating system. There are two methods of communication, one-off and recurring. Recurring messages persistently talk to the heating asking the units for updates to their statuses. The one-off messages are the type of messages sent by your interaction with the web interface, such as you request a temperature change, this sends the one-off message into he heating process that communicates accordingly with the heating system.
- Logging process: The last module I wrote which is still being implemented and tested. The idea with this process is that it will be responsible for recording all the information within processes and events. It will also provide a historic log for analysis of the heating status, i.e. temperatures, statuses, schedules, etc.
Any Python connoisseurs out there will understand that you cannot truly multi-thread within Python, due to limitations of the GIL. Enough said, there are plenty are articles and videos out there that explain this. The main reason I went for the option of threads is that each process has to be non-blocking and standalone. They’re linked via Python Queues, these provide the conduit to send messages between processes.
- It’s portable, meaning it can be run an different platforms. I wrote the software on my laptop and simply published it to the rPi3 to operate.
- Massive support, there is a vast community out there supporting Python, there probably isn’t a module out there that hasn’t been written already.
- Tools, there are a plethora of free tools (IDEs) to help with creating, debugging and creating the software.
The present version of the software was intended to be more of a prototype. I didn’t intend on sharing it in the current state. Some of the settings are hardcoded, for example, I only have 12 zones, so I’ve hardcoded these for the time being to save time.
Whilst the independent processes seem like a good idea, they do bring some of the perils you get with parallel processing. Timings and sequencing were at times somewhat of a headache.
All the heating protocol commands that I could generate between the JGStats and the Touchpad have been implemented. A client connects via a Web Socket and sends JSON strings containing commands and parameters; in return, the system will respond with JSON strings. There isn’t any formal documentation, most of the code has commenting, but I have to admit, it is easy to get lost in the modules. This is something I would probably address in a rewrite.
I’m new to Python, so the experts out there my be critical of some of my coding methodologies. I’m certainly happy to accept critic and receive comments accordingly.
The logging process was the last code I implemented. It’s not fully complete, it was starting to record temperatures into a database.
All it needs is a client and interface that implement the JSON interface. One point worth mentioning, certain browsers are a little temperamental with their implementation of Web Sockets. When I was sending commands via Firefox, there was a connection bug within the browser which meant you had to connect twice before it established. A beta version confirmed that Mozilla had sorted this problem for later releases, which may be released already.
Life’s about sharing
A few people out there have expressed interest in the project with a similar idea to automate their JG wired systems. I’m going to host the code via a GitHub share. I’d appreciate if you would fork as required and keep your personal versions online with mine so that I can benefit from any improvements and new features.
I’m struggling to find time to complete the UI and was undecided what method to use to implement it. I like the idea of using an old iPad or Nexus as a touch screen encased in a nice wooden surround. It’s finding the time to write the interface, mount the device and find a permanent charging solution. I’m not a fan of “Heath Robinson”style installations. To do this I must be sure that the JG Touchpad can be retired, as they cannot be run together. I may leave the Touchpad intact for some time, eventually, the whole system may need replacing anyway.
I also have a Z-Wave Fibaro driven home automation system, this could be the main interface. The Fibaro home center supports plugins. My only concern is whilst sleek, the iPhone app in clunky and relatively slow to connect. Apple have released support for home automation via their HomeKit. I haven’t looked into this, I’m sure it won’t be cheap to implement, and I don’t know what capabilities it will have, worth investigating at some point.
If you want to contribute, you can download and do so at the GitHub respository:
Please note the following points:
- If there is a blocking issue, time dependant, I’ll try and sort it at some point.
- I cannot support individual requests to setup your exact system, I’m happy to answer questions when possible. Please ask questions through GitHub.
- If you want to contribute to the Master code to improve it, please do. If you want to change the code for your own setup, please fork the code instead.
- I don’t authorise this software for monetary gain without seeking prior permission.
- If I have breached any patent or copyright, I will revoke the code on request.
- No warranty or guarantee is implied. The code is a prototype, therefore you shouldn’t rely on software as a primary means of running your heating.