Heating Project – Listening in


This is the third instalment in a series of articles I’ve been writing about the re-automation of my home central heating system.  For further details about the construction, you can view the previous article.

In this article I will be discussing the discovery of the heating protocol and how I untangled the information exchanged between the central controller and the room wall controllers.

Tapping In

I’ve discussed in a previous article the addition of an RS485 to WiFi converter that I added to the system.


It is not my intention to explain the detailed workings of the RS485 protocol, nor explain details of binary communications, instead, I will provide an overview for what we need to know to understand the language of the controllers.

Network Topology

Every controller in the house, including the master controller, wire back to two UH1 units, which in turn are interlinked together.  The cabling is CAT 5 networking cable.  From the 8 available cables: 2 provide 12v DC power, 2 provide relay switching and the other two provide the signalling cable for the RS485 network.

The Kitchen controller is the master node on the network.  It is the responsibility of the master node to initiate all communication.  The room controllers only communicate  when spoken to, and they don’t listen to each other (in that they will simply ignore other wall controller node communications).  The master-slave setup uses a method of communication called half-duplex.  In simple terms, it means that only one device at a time can communicate.

The master controller polls each room controller in turn and waits a defined amount of time for the room controller to respond.  The master controller never lets up, it continuously cycles around all the room controllers requesting configuration statuses, this means the network chatter is somewhat saturated. There is no opportunity for another master node to query the room controllers.  Another listening node (like our RS485 to WIFI converter) can listen in, but it would not be possible to splice in request commands from the converter, as to do so will cause crashes of data on the communications bus, with the master controller.  It is for this reason I realised early on, that the current master controller’s days are numbered, once I have a replacement system.

Talking the talk

The RS485 to WiFi converter came with some diagnostics software to link into the unit and listen or talk onto the RS485 network it is connected.  The software required the IP address of the unit and some basic information such as data speed (4800 baud), parity (none) and stop bit (1) configuration.  Once this was set I clicked “Connect” and hey presto, I could see the “chatter” between the master controller and the room controllers.

Here is an excerpt from talk on the network:

01 29 00 2A 01 29 52 04 17 2A 15 0F 82 01 0A 05 01 1E 00 96
01 4E 52 A1 01 4E 52 58 50 65 59 50 5F 61 6E 65 66 6E 5F 1D
01 4F 52 A2 01 4F 52 58 50 65 5B 50 5F 5F 50 65 67 50 5F E3
01 50 52 A3 01 50 52 56 6E 57 6E 63 6E 64 6E 68 50 68 50 68 50 68 50 AF
01 51 52 A4 01 51 52 57 50 58 50 61 50 62 50 68 50 68 50 68 50 68 50 36
02 26 00 28 02 26 51 04 17 2B 15 13 82 0F 0A 00 EF 14 1C A1
02 4E 51 A1 02 4E 51 50 50 5F 50 50 5F 62 6E 63 64 50 5F E5
02 4F 51 A2 02 4F 51 57 50 59 58 6E 5B 62 50 64 65 6E 5D 09
03 26 00 29 03 26 51 04 17 2B 14 33 82 0F 0A 05 EF 14 1C C6
03 4E 51 A2 03 4E 51 57 50 64 58 6E 5F 61 6E 65 65 6E 5F 38
03 4F 51 A3 03 4F 51 58 6E 65 5B 50 5F 5F 50 65 65 50 5F 00
04 26 00 2A 04 26 51 04 17 2B 0F 13 82 0F 0A 00 EF 14 1C 9D
04 4E 51 A3 04 4E 51 57 50 5F 57 50 5F 62 6E 5F 64 50 5F F1
04 4F 51 A4 04 4F 51 58 6E 5F 58 6E 5F 61 50 5F 64 50 5F 11
05 26 00 2B 05 26 51 04 17 2B 10 13 82 0F 0A 00 EF 14 1C 9F
05 4E 51 A4 05 4E 51 57 50 61 58 50 5F 66 50 5F 66 50 5F DD
05 4F 51 A5 05 4F 51 59 50 62 5A 50 5F 66 50 5F 66 50 5F E3
06 26 00 2C 06 26 51 04 17 2B 12 13 82 0F 0A 0A EF 14 1C AC
06 4E 51 A5 06 4E 51 56 6E 65 58 50 5F 63 6E 63 64 6E 5F 3A
06 4F 51 A6 06 4F 51 59 50 65 5B 50 5F 60 50 63 65 50 5F E5
07 26 00 2D 07 26 51 04 17 2B 13 13 82 0F 0A 00 EF 14 1C A4
07 4E 51 A6 07 4E 51 57 50 5F 57 50 5F 61 6E 61 65 50 5F F6
07 4F 51 A7 07 4F 51 58 6E 63 5B 50 5F 60 50 63 65 50 5F 01
08 26 00 2E 08 26 51 04 17 2B 13 13 82 0F 0A 00 EF 14 1C A5
08 4E 51 A7 08 4E 51 57 50 62 58 6E 5F 62 6E 62 65 50 5F 1B
08 4F 51 A8 08 4F 51 58 6E 64 5B 50 62 60 50 64 65 50 62 0A
09 26 00 2F 09 26 51 04 17 2B 13 13 82 0F 0A 0A EF 14 1C B0
09 4E 51 A8 09 4E 51 57 50 5F 57 50 5F 62 6E 63 64 50 5F FA
09 4F 51 A9 09 4F 51 58 6E 5F 58 6E 5F 61 50 62 64 50 5F 19
0A 26 00 30 0A 26 51 04 17 2B 13 13 82 0F 0A 05 EF 14 1C AC
0A 4E 51 A9 0A 4E 51 57 50 63 58 50 5F 62 6E 63 65 50 5F 01
0A 4F 51 AA 0A 4F 51 58 6E 63 5B 50 5F 60 50 63 65 50 5F 04
0B 26 00 31 0B 26 51 04 17 2B 13 13 82 12 0A 0A EF 14 1C B5
0B 4E 51 AA 0B 4E 51 57 50 65 59 50 5F 64 6E 65 66 6E 62 2B
0B 4F 51 AB 0B 4F 51 58 50 65 5A 50 5F 64 50 65 66 6E 62 10
0C 26 00 32 0C 26 51 04 17 2B 13 13 82 0F 0A 00 EF 14 1C A9
0C 4E 51 AB 0C 4E 51 57 50 63 58 6E 5F 62 50 63 65 6E 5F 21
0C 4F 51 AC 0C 4F 51 58 6E 64 5B 50 5F 60 50 64 66 50 5F 09

What you can see is an entire cycle of communication of the master controller talking to each individual room controller.  The communication language between controllers is referred to as a protocol.  It is a defined language that each controller uses to request and respond information.  The protocol is created by the controller designers, in this case Heatmiser/JG.

The output is represented in Hexadecimal.  This is an easier format on the eyes than viewing binary.  Each two character pairs represent a binary byte.  A binary byte consists of 8 bits (0’s and 1’s).  For example: Hexadecimal 4F is equivalent to binary 01001111.  Each byte represents significant data that means something useful that we can decipher.

Breaking it down

Let’s look at one of the lines and break it down:

04 26 00 2A      04 26 51 04 17 2B 0F 13 82 0F 0A 00 EF 14 1C 9D

I’ve colour coded and separated the data for clarity.  The green initial section is actually the request from the master controller (in the kitchen) and the blue is the response from the room controller (lounge in this case).

It took quite a bit of trial and error to analyse the entire protocol.  I’m still not 100% sure what every byte means, but I know sufficient for the purpose of my project.  It is possible to put each room controller in a setup mode.  What I discovered in this setup mode was each controller has an ID, low and behold, this is representative of the communications ID on the network.

In the instance above Node ID 04 is the lounge controller.  To work out what each byte represented, I started changing parameters on the wall controller, like set temperature, actual temperature, schedules, etc.  Eventually I’d worked out the majority of the protocol.

Here’s the breakdown:

The Request

As we said earlier, the green section is the request from the master controller.  The format is as follows:

Byte 1 (04) – Requested controller ID
Byte 2 (26) – Command
Byte 3 (00) – Unused (or possibly the master controller ID)
Byte 4 (2A) – Checksum

What is the checksum?  In network communications, it is preferable to know if the message we received is intact and not corrupted.  A simple method of achieving this is using checksums.  There are different ways of computing the checksum, for our communcation, the method is very simple, the checksum is the summation of the main bytes, therefore 04h + 26h + 00h = 2Ah.

The Response


The main controller requests three commands from each room controller, on its travels around polling the entire system.  The first command (26h) returns the current configuration.  I wrote vertically the parameters I discovered in green, this relates just to the first green highlighted row.

The other two blue rows are the weekday and weekend schedule information. The controllers have to be configured in a weekday/weekend mode because the master controller only supports this feature, each room controller can actually support a 7 day schedule, it is on my “to do” list to investigate switching a controller into a 7 day configuration and experiment sending commands.

The Parameters

The green vertically written parameters, across the top, are as follows:

Byte 1 (02) – The responding node ID (in this case the Study)
Byte 2 (26) – An echo of the requested command from the master
Byte 3 (51) – The type of controller (e.g. PRT-N)
Byte 4 (07) – Day.  Monday = 1 … Sunday = 7
Byte 5 & 6 (10 2E) – Time. HH MM.  So the time was:- 16:46
Byte 7 – (15) – Actual Temperature. 15 hex = 21 degrees Celsius
Byte 8 – (14) – Unknown?
Byte 9 – (82) – This has 4 potential values and represents if a controller is ON/OFF and/or locked/unlocked
Byte 10 (0F) – Set Temperature, effectively the temperature the controller is trying to achieve, in this case: 15 degrees Celsius
Byte 11 (0A) – Frost Temperature. 10 degrees Celsius
Byte 12 to 14 – Unknown?
Byte 15 (1C) – Scale : Celsius or Farenheit. 1C = Celsius, 52 = Farenheit
Byte 16 (A0) – Checksum

The checksum for the response is calculated differently to the request.  The formula I derived to calculate the checksum is:

Checksum = (B1 + B2 + … + B15) – Lower((B1 + B2 + … + B15) / 256d) * 256d

Where B = Byte. Possibly not the most efficient, but I can work on that at a later point.

It would be pointless to go through, byte-by-byte, the scheduling responses.  Essentially, the parameters represent 2 On/Off periods.  The first row represents Weekdays and the second Weekends.


We have finally reached the point where we’ve discovered how the heating system fundamentally communicates.  In some respects it’s simple but brilliant.

What I haven’t considered in this article is how the master controller writes parameters to the room controllers.  It’s actually very similar and straightforward as requesting data from the room controllers.  I will consider documenting this in a future article.

The next stage is to write my own master controller that will replace the current master controller in the kitchen.  The logistics of how I achieve this will be covered in the next article.

Click to view the final post here, including the code!


  1. I’ve got 2x heatmiser UH1s, 11 network stats, a HW stat and a touchpad. I’d be interested to see how you get on with your project. When I connected my system to the PC to monitor the outputs there were hundreds of messages a minute from the touchpad. Are you seeing this too?

    1. Yes, the main controller floods the network with chatter, leaving no gaps for a second device to talk.

      I will be replacing the touch screen with a Sparks Photon IoT, for the brain and a secondhand 7″ Samsung Galaxy I purchased from eBay, for the interface. Hopefully I’ll get this done in summer, while the heating is dormant and I can have downtime without affecting the house temperature. I’ll share all my developments.

  2. Really like the write up, was wondering if your breakdown of the protocol was for the v3 protocol or v2. I have the protocol spec v3 from heatmiser and couldn’t correlate that doc to your write up – what did you think of that doc?

    Will be really interested in how your development is coming along.

    1. Hi Adam,

      Thanks for your feedback. My room controllers are JGSTAT v3’s. I have a copy of the Heatmiser protocol document, and it has little resemblance to the John Guest protocol, even though physically the Heatmiser and JG units look identical. That’s why it took me so much longer to fathom out the protocol.

      I’ve been waiting some time for the hardware to come through which will replace the main controller. It’s just a case of interfacing into the WiFi connected RS485 network now, then I can switch off the main unit and make some nice front-ends on the 7 inch tablet I bought. I’ll post everything in future articles, hopefully very soon.

    2. Adam, do you still have your v2 system? My Touchpad has failed (it connects to the PRT-ENs) and it is now discontinued. I’m trying to find a spare, so if you’e seen anything anywhere I’d love to hear from you!


  3. How goes the project?
    I have been trying to get the Heatmiser protocol doc with no success. Any chance of sending your copy on?
    One element I hope to add of my system is a log of individual room temp through the day against outside temp.

  4. This is really fantastic work. I found this article when I Googled “Heatmiser RS485”. I have wet UFH throughout the house (only towel radiators), all linking back to 4 UH-1s (1 per floor) and a Netmonitor v3. Once we have a working model of Heatmiser’s RS485 protocol (of course, when I say “we”, I mean you!), we should ultimately be able to voice control the heating via Amazon’s Alexa, no?! Just a thought… My other project is to see if Alexa can be persuaded to send Telnet commands to control my lighting system!

    1. Thanks for your comments. I’ve been particularly poor at keeping up with this project. However I’m significantly more advanced than written on the blog. I have written a web based server that fully implements the protocol in its entirety, using python. For some reason I stopped at the interface, which was the easy bit!

      You can interface this with anything. I might just share the code, it’s not my finest hour, more of a draft concept, but it is operational.

      I’ll try and publish it within the next week or so.

      I’ve heard that JG sold out and are no longer producing these units, so I’m wondering on a longer term replacement option for my system.

  5. Infuriating, isn’t it? But I have sympathy for Heatmiser: customers and/or their contractors were apparently incapable of installing Cat5 FTP as specified (shades of your short circuits!) and would then blame the Heatmiser product and use up massive amounts of free phone support. So while it’s a great product for us it was not a commercial success for Heatmiser. Their answer to you and me is Neo 12v. It uses a wireless “mesh” system to communicate among the stats so that nobody can cable it wrong! Neo would use our existing Cat5e only for the supply of 12Vdc (the shame of it!!!) using the existing back boxes. So, 16 new stats plus a Neo-hub – a mere snip at £1,000!!!!! As for the python stuff – that sounds phenomenal – python is one of the languages that can be used on AWS for Alexa scripting…

  6. I too have a HeatMiser PRT-N (v3) network on which my NetMonitor recently died! – HeatMiser took a look and said “it’s dead”. Hmm.

    So, my plan is to use a Raspberry Pi to replace it: hook up the RS485 bus and provide a nice web interface over Ethernet. I also intend to add logging of room temps, boiler cycling, etc. As an extra step it would be great to use a phone or tablet to control the system, possibly as an app but at least using a web HTTP/HTML interface.

    I’ve so far found a few folks on the net who have shared their experiences and some code but I’d be particularly interested in your python scripts.

    Many thanks.

    1. Hi Neil,
      Apologies in the delay responding. I’m about to publish the final instalment on my blog, which as been a long time waiting! What I have created is certainly not perfection, but it’s a good prototype to help others build on top of. I’m working on it today and hope to have it published (along with a GitHub share). Stay tuned.

      I’ve been using a Pi to host a Python server that interfaces to the Heating network via WiFi.


Leave a 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.