Talking the Talk – The Finale

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.

Process implementations

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.

Why Python


  • 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.

Current state

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.

GitHub repository

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.
  • Enjoy!


  1. Thanks for the wealth of info on communicating with the Heatmiser / JG thermostats. I found the listening in post really useful. I’m still waiting on a piece of hardware to come before I begin on an arduino project to control mine.

    You may have since come across it since the original post but I managed to get hold of a copy of heatmisers network protocols. You can download them here if it helps to fill in any gaps

  2. Hi, I’ve followed your blog for quite a while now always with the intention of setting this up on my JG system. I’ve finally got round to it, however my system uses the JGv3 touch screens, which use the published Heatmiser V3 protocol rather than the version your code uses.

    My idea is to use the python script as a backend to a Node red interface using Emon CMS as the data logging tool.

    I’m getting there with it, I’ve modified your code to use the V3 protocol at least for getting the status of the stats and setting the temperature of each using Node red. I’ve got it publishing the room and set temperatures via MQTT to Emon CMS.

    Still a long way to go on getting everything to work together but finally getting there.

    Once again thanks for your code being the starting point

    1. Thanks for the support. I’d like to submit more stuff, but daily commitments consume too much spare time. I’ve got some cool stuff lined up however:

      • Heating control using Amazon’s echo Alexa service. Just bought and echo dot. Combined with Python and Flask-Ask, it won’t take long to be able to control the heating by voice. You can still use visualisations using the app.
      • Servant bells using servos and probably my now redundant Particle Photons and an IFTTT button/trigger. (I don’t have servants 😉
      • I’m interested in 433MHz, I’ve got some devices around the house that transmit data using this frequency, hoping to integrate into a Pi based Python project

      Thanks for taking an interest. Your project sounds interesting, keep us up to date.

      1. I’ve also thought of adding voice control via Alexa, I will look into this more. I’ve got some 433MHz devices I’ve built to monitor humidity and temperature. The idea being they can feed into the heating control system and turn the radiator heating circuit (via the JG stat) on should any of the rooms fall below the desired temperatures. Mine are based on the Tiny TX )more info here )so far I’ve built 2 and have intend building a further 8

  3. I have a small program in C that runs as a windows service and when used with a rs485 to tcp/ip device available on ebay and presents a tcp/ip listening port on the localhost for ascii commands to be entered to control all functions of the heatmiser touch wired thermostats (as the wifi ones were buggy then I have not tested with these but as my commands are converted to the v3 rs485 protocol then it doesn’t touch the wifi interface so I cant see why they wont work).

    It reads all the devices data in sequence and stores it in a XML file

    I have used it to provide a easy interface to various home automation software that can send tcp/ip ascii – can be easily tested with putty.

    Been using it for a year now and works well – I will post it to GitHub when I have time.

Leave a Reply to Stuart Robinson Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.