How are messages actually sent? One Zone not working - how to debug :(

[g6ejd]

The Opentherm has been designed to enable transfer (2-way) of the following to show just a few of the protocol capabilities:

Day of Week & Time of Day
Year
Room Setpoint by zone
Room temperature by zone
Boiler water temp
DHW temperature
Outside temperature
Outside air temperature
Return water temperature
Return water temperature to boiler
Solar storage temperature
Solar storage temperature
Solar collector temperature
Solar collector temperature
Flow temperature
Flow water temperature of the second central

So if your a designer of Opentherm, you have to implement (via the bridge) some or all of these OT commands and THEN design another protocol to transfer data between local devices, using (as I said I find it incredulous if so) another protocol which would increase overheads and no-one likes higher cost in industry, therefore it is still probable that they used OT protocols until someone from Honeywell tells us otherwise that is...

Has 'Honeywell Speak' been confirmed?

[paulockenden]

The protocol used internally by Evohome is Ramses II.

[DBMandrake]

There must be a reasonably robust two-way protocol that exists between the controller and an HR92 as the HR 92 receives and displays its assigned zone name, it reports current temperature and receives temperature demand from the controller all in an environment that could see any HR92 report information at any time, so not synchronised and doing all that requires the protocol to send and resend on-error and handle transmission clashes and so-on. I had in mind that Honeywell would have used an Opentherm protocol to make it consistent.

The over the air 868Mhz protocol used between the controller and all the satellite devices is called Rameses II and is a proprietary Honeywell protocol, probably originally developed for the Hometronic system, as devices like the HR80 are compatible with both Hometronic and Evohome.

As far as I know this protocol is not publicly documented by Honeywell although a large part of it has now been reverse engineered, at least at the packet level. The HGI80 interface handles support for the protocol at the low level radio/wireless level making it possible to send and receive packets to wireless devices over a USB interface and API - this reverse engineered protocol spec is used by Domoticz to communicate directly with Evohome devices using an HGI80, so out of everyone here DanD the maintainer of Domoticz Evohome support is probably best positioned to speak on the specifics of the protocol, and what it can and can't do.

I would not be so confident as you that the protocol is fully bi-directional at least in a message and acknowledgement sense. I haven't studied packet dumps from an HGI80 yet (as I don't have one) but after nearly a year observing the operation of the system in great detail I have to conclude that some aspects of communication are acknowledged and some are only sent in a "broadcast" fashion with no expectation of an acknowledgement to confirm that the message was received.

Some messages like those in the binding process seem to be acknowledged immediately, since you see a confirmation on the controller after a successful binding response from the remote device. However some messages like a temperature sensor sending periodic temperature updates seems to be sent as a "broadcast" with other "bound" devices choosing to listen to that broadcast, but not acknowledge it.

For the most part HR92's do not "report information at any time" - they only communicate on periodic four minute intervals. Anyone using the system will notice that changes made at the controller to set points take up to 4 minutes or so to be applied on an HR92 - this is because the HR92 sits in a low power sleep mode 99% of the time with only the LCD display lit. Most likely the CPU is in a halt state waiting for an external timer interrupt, and the wireless radio turned off. This is the only way that it would be possible to achieve a two year battery life. If you time it carefully the communication interval seems to be between about 3 min 30 seconds and 4 min 30 seconds - it's not exactly 4 minutes.

Temperature updates from the HR92 (or any temperature sensor) to the controller are also only sent on a regular interval of about 4 minutes. Heat demand messages are only sent after the device has woken up during a 4 minute periodic communication interval - at which time it looks at the temperature measurement, decides whether the heat demand and/or valve pin need to change, the valve pin is moved, then the updated heat demand message sent then it goes back to sleep for another 4 minutes.

An interesting piece of trivia is that even if you have a single HR92 in a zone and you are using its built in sensor, if the zone is in the default "single room mode" the temperature reading is not used directly by the valve. The temperature reading is sent to the controller then sent back to the HR92, sometimes with a few minutes delay. This is why the temperature reading on the controller actually updates before the reading on the HR92 even though the HR92 is the sensor.

I'm not really sure why its done this way, but it is. If the zone is in "multi room mode" or the HR92 is unbound it uses its own temperature reading directly without waiting for it to be relayed via the controller.

The only time an HR92 sends a message that is un-synchronised is a set point change message when you manually adjust the HR92. And funnily enough, those messages do seem to go missing sometimes. If you make multiple manual adjustments on an HR92 within a few minutes you'll find that typically more than 1 in 10 will "go missing". EG you turn the HR92 to a new temperature and it updates on the HR92 but the set point on the controller never updates. This to me does not sound like a protocol with universal acknowledgement of all messages...

If I try by repeatedly changing the set point every 20 seconds or so I can usually get it to misbehave within a few minutes. Doesn't matter what HR92 I use - they all do it, even the one in the hallway that is about 1 metre from the controller. I have no 868Mhz wireless devices that might be interfering in the house and all HR92's get full 5/5 signal reading when tested. I can only assume that the un-synchronised transmission of the HR92 sent after a manual adjustment has collided with one of the scheduled transmissions - most likely one made by the controller, since the controller would not hear anything while it was busy transmitting.

In normal day to day use it happens very infrequently but just often enough to remind me that it does happen.

I have also very rarely seen set point updates from the controller to an HR92 go missing - for example I'll cancel a bathroom override at the controller after a shower then go back to the bathroom 15 minutes later and discover that the radiator is still on and set to the previous set point. It's only happened to me a couple of times in the last month or two so it is pretty rare. This also suggests to me that the controller -> HR92 set point updates are unacknowledged and rely on scheduling to avoid collisions with other devices. If there was any retry mechanism the change would at most be delayed a few seconds, but when it happens it does not update at all until a different set point is sent.

So my impression is that the protocol is a largely broadcast, acknowledgement free, idempotent protocol which relies heavily on very short infrequent scheduled transmissions to avoid collisions. When I one day get an HGI80 I'm curious to analyse the protocol in a bit more detail.

There is a micro-controller board called the Arduino or the Raspberry Pi that have been programmed to receive the Opentherm protocols and there are Application Programming Interfaces (API) that enable some communications with the system, I've found this on the Honeywell Developers forum as examples of what can be obtained:

GET Get an Authorization Code /authorize
POST Create a Token from an Authorization Code /token
POST Refresh a Token /token
GET Get all devices for a location /devices
POST Change Thermostat Settings /devices/thermostats/{deviceId}
GET Get Thermostat /devices/thermostats/{deviceId}
GET Get current fan settings /devices/thermostats/{deviceId}/fan
POST Change fan setting for device /devices/thermostats/{deviceId}/fan
GET Get all Devices by Type /devices/{deviceType}
GET Get a Specific Device by ID /devices/{deviceType}/{deviceId}
GET Get all Locations /locations
GET Get temperature and humidity sensor history

So if it was Opentherm compliant then we could establish things like determine zones, get and set temperatures and their history.

The way into the device is therefore via the Wi-Fi network using HTML commands as above, which is relatively easy to do, when I get time I will programme an Arduino to seek information from the Evohome device ID and see what it returns.

I postulate that Honeywell will have designed Evohome around an open-standard, but which one, and clearly they have because the Amazon Echo can communicate and control it and they (Amazon developers) know what it is!

Rameses II is not an open standard and it is not OpenTherm. In general an over the wire protocol does not make a good basis for a wireless protocol so it wouldn't make sense to take a protocol designed for one specific task (hard wired thermostat to boiler communication) and try to extend it to do something it was not really designed to do.

You can't connect directly to the controller from your local Wifi/lan network - if you try port scanning it you'll find it has no open ports whatsoever, it uses the wireless connection purely to connect to Honeywell servers using a persistent outgoing connection. This is to allow remote control via the Phone apps and Web API, update the time and date, and download firmware updates.

At the moment there are only two way to communicate with the system - one is to use the Web API that the Phone apps use. This is the method used by IFTTT, Amazon echo and so on. It's quite easy to access this API with 3rd party libraries - for example on a Raspberry Pi (or any Linux system) there is an excellent Python API that only requires you to write a few lines of code to query zones or make changes. I use a munin plugin to graph my temperatures via this API, as well as Domoticz.

The other method is to send and receive Rameses II messages directly to the controller and/or other devices using an HCI80 over a USB interface - in this case the HCI80 has to be in your house within 868Mhz wireless range. Domoticz supports this direct communication and it's possible to get a lot more information than that available by the API. I believe on the latest versions it can also do clever things like simulate a honeywell temperature sensor based on sensor input from other temperature sensors. I'm not sure whether any other software supports the HCI80 or how hard it is to program for it "from scratch".

[g6ejd]

Thanks for the informative insight, that was the sort of response I enjoy reading and was looking for. I can see from your technical references and level of detail we may have a lot in common and look forward to further discussion. From what your saying it looks like only port 80 is open, or it is only the Honeywell cloud like server that accepts the connection then communicates either controller, but then that must use some form of routing protocol if not IP, could be keyed UDP as a connectionless process and rely on the underlying circuit reliability to achieve pseudo connected communications. I'll try to communicate with the controller using an ESP8266 or Arduino and see what it sends back to a client as a starting point. Getting the ESP8266 into minimal power consumption mode (I have found) requires a 10-min deep sleep otherwise quiescent average current consumption is so high that battery life of a year is impossible to achieve let alone 2 years! so I have empathy with the design choices made. As ever this technology needs to be a compromise.

[paulockenden]

I think if you take some time to read what's been written here, and on the Domoticz forums, and look at the existing code on GitHub, rather then stomping in with wild ideas and speculation, you might have more success.

There's a lot of information out there.

Even a simple Google search for the protocol used for Evohome comms would have saved you the embarrassment of the posts yesterday where you tried to insist it was 'Opentherm'.

[g6ejd]

I find your responses to be arrogant rather than helpful, the complete the opposite of those from DBMandrake, probably due to your low self-esteem and perceived knowledge in some areas, such that when your challenged you respond is this way.

As to 'stomping in' and 'insisting' , perhaps you should learn to read and understand properly and understand a context then you will have seen that I used the word 'postulated' more than once, but clearly on this forum or the world according to you, no-one can challenge or discuss anything especially if you disagree with it.

Now that you have resorted to that form of response and I hope others note your arrogance too, I will now ignore any of your responses on the basis they are unhelpful and from someone I do-not wish to converse with.

Your the 'embarrassed' one...

[DBMandrake]

From what your saying it looks like only port 80 is open, or it is only the Honeywell cloud like server that accepts the connection then communicates either controller, but then that must use some form of routing protocol if not IP, could be keyed UDP as a connectionless process and rely on the underlying circuit reliability to achieve pseudo connected communications. I'll try to communicate with the controller using an ESP8266 or Arduino and see what it sends back to a client as a starting point. Getting the ESP8266 into minimal power consumption mode (I have found) requires a 10-min deep sleep otherwise quiescent average current consumption is so high that battery life of a year is impossible to achieve let alone 2 years! so I have empathy with the design choices made. As ever this technology needs to be a compromise.

You still misunderstand - you won't be able to connect directly to the controller over IP. As I said earlier it exposes no open ports at all on its local IP address. (I just did a full port scan on it again last night to double check) It purely uses the IP connection over Wifi to make a persistent outgoing connection to Honeywell servers.

It constantly reports all changes to the Honeywell servers including temperature measurements, set point changes, quick action mode changes (off, eco etc) and also any changes made to schedules. So the state stored at the Honeywell servers seems to be at most only a few seconds behind.

API access is done over a standard HTTPS connection to Honeywell servers, so all API interactions are via Honeywell's online servers.

This online API is now well understood and there are library bindings for many languages - the one I'm familiar with is watchforstock's python library which you can find here:

https://github.com/watchforstock/evohome-client

watchforstock is a forum member here although he doesn't seem to have posted recently. About 5 lines of python code will retrieve and display all the zone temperatures for example:

#!/usr/bin/python

from evohomeclient import EvohomeClient

client = EvohomeClient('[email protected]', 'password')

for device in client.temperatures():
    print device

Will result in something like:

{'temp': 20.29, 'setpoint': 16.0, 'thermostat': u'EMEA_ZONE', 'name': u'Bathroom', 'id': 1377389}
{'temp': 20.18, 'setpoint': 20.0, 'thermostat': u'EMEA_ZONE', 'name': u'Hall', 'id': 1643302}
{'temp': 20.35, 'setpoint': 16.0, 'thermostat': u'EMEA_ZONE', 'name': u'Kitchen', 'id': 1643296}
{'temp': 20.86, 'setpoint': 20.0, 'thermostat': u'EMEA_ZONE', 'name': u'Living Room', 'id': 1378782}
{'temp': 17.15, 'setpoint': 5.0, 'thermostat': u'EMEA_ZONE', 'name': u'Main Bedroom', 'id': 1438045}

Anything that the iPhone/Android apps can do can be replicated via the API. A notable shortcoming of the API is that heat demand information from HR92's cannot be obtained. (There is a field in the data structure returned from the server that looks like it should provide this, but it is not updated)

The only way to communicate directly with the controller without going through Honeywells servers is using an HCI80 which will talk the same 868Mhz Rameses II protocol as the controller and other devices.

This is a lot more complex to program for but it makes additional information available, such as heat demand being sent from HR92's to controller, and from controller to BDR91's. It also provides raw temperature measurements that aren't rounded to half a degree, although it's now possible to get that from the V1 Web API as well. It's possible to get temperature readings from all devices in a zone rather than just the "nominated" sensor that the controller has bound. It's also possible to simulate devices. I don't think it's possible to examine or modify schedules via HCI80 though.

So depending on what you want to do, those are your two options. For many uses the Web API is sufficient and is very easy to use thanks to the libraries that are available now.

[g6ejd]

Thank you once again for a very helpful response and your further explanation.

I'd gathered the only direct communication with the Controller is via the Honeywell server, that's why I presumed they are using a UDP connection to the controller or something like that, as there must be an open port somewhere as it communicates on Wi-Fi network using IP but it will only respond to information with the correct key information, the Network Owl works like this for their Home heating system and I can now communicate with their controller via UDP but it took me some time to reverse engineer the connection and client calls.

Your Python call examples will help me quickly get to the place I'd like to be, except I shall be using the Arduino and ESP8266 and C.

Later today I'll set my network analyser running and then (indirectly) connect to the Controller and see what traffic is flowing to the IP address of my controller as I'm intrigued to see if it's in the clear (text) or what form it takes.

[paulockenden]

There are no open ports on the controller. It opens an outbound https (TCP port 443, no UDP involved) connection to Honeywell's Alarmnet servers. The local source port is usually in the 30000 range, and is incremented with every new request (if the connection is broken). The local controller is a client, not a server.

[DanD]

Hi,

I just wanted to add a response to Bruce's comment:

So my impression is that the protocol is a largely broadcast, acknowledgement free, idempotent protocol which relies heavily on very short infrequent scheduled transmissions to avoid collisions. When I one day get an HGI80 I'm curious to analyse the protocol in a bit more detail.

I agree 100% with Bruce's description of the controller <-> device communication. I've spent a few months this year extending the Domoticz Evohome code which uses the Honeywell HGI80 usb device to communicate directly with all other Evohome devices within the home via the Ramses II protocol and Honeywell's own proprietary command language which is a little like going back to machine code. It seems designed to heavily minimise wireless messages and there is no handshaking or acknowledgement. The devices send out their status messages on an infrequent timed and event driven basis and there's also an occasional keep-alive message which is used to maintain a common time clock. If the controller hasn't heard from a device for a few hours then it eventually flags this as a device communication problem, but this takes many hours.

Dan

[DBMandrake]

I just wanted to add a response to Bruce's comment:

Who is Bruce ?

I'm not sure if I've ever said my real name on this forum but for the record it's Simon.

[DanD]

Oops, sorry Simon.

You've confirmed something that I suspected, that I'm not really safe with a keyboard at the moment . I've got plenty of spare time just at the moment as I'm recovering from illness, but unfortunately I don't make a lot of sense . I definitely think that I should stay away from the Domoticz code for the next few weeks......

Regards,
Dan

[g6ejd]

My Evohome controller reports itself on a network analyser as 'Gateway A130EE'. There is no IP traffic on the network from the Controller, but a huge amount of broadcast, which is what I expected. Here's a transcript of when I used my iPhone to increase a room temperature:
62995 12:04:06 17/10/2016 1853.3337782 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -72 dBm, Rate = 24.0 Mbps
62997 12:04:06 17/10/2016 1853.3345366 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
62999 12:04:06 17/10/2016 1853.3356227 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63001 12:04:06 17/10/2016 1853.3362728 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63002 12:04:06 17/10/2016 1853.3367326 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -72 dBm, Rate = 24.0 Mbps
63004 12:04:06 17/10/2016 1853.3401153 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -72 dBm, Rate = 24.0 Mbps
63006 12:04:06 17/10/2016 1853.4258111 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -71 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63013 12:04:07 17/10/2016 1854.1426895 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -71 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63014 12:04:07 17/10/2016 1854.2450706 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -72 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63015 12:04:07 17/10/2016 1854.3469516 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -72 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63018 12:04:07 17/10/2016 1854.4498143 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -71 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63019 12:04:07 17/10/2016 1854.5522528 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -73 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63020 12:04:07 17/10/2016 1854.6546877 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -72 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63021 12:04:07 17/10/2016 1854.7565720 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -73 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63023 12:04:07 17/10/2016 1854.8594841 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -72 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63024 12:04:08 17/10/2016 1854.9618112 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -71 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63025 12:04:08 17/10/2016 1855.0642457 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -73 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63026 12:04:08 17/10/2016 1855.1666948 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -71 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63028 12:04:08 17/10/2016 1855.2299626 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -72 dBm, Rate = 24.0 Mbps
63029 12:04:08 17/10/2016 1855.2307746 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63030 12:04:08 17/10/2016 1855.2312010 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63032 12:04:08 17/10/2016 1855.2318461 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63034 12:04:08 17/10/2016 1855.2698673 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -76 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63035 12:04:08 17/10/2016 1855.3771118 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -77 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63036 12:04:08 17/10/2016 1855.4795274 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -77 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63038 12:04:08 17/10/2016 1855.5576717 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63042 12:04:08 17/10/2016 1855.5600442 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63044 12:04:08 17/10/2016 1855.5615762 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63046 12:04:08 17/10/2016 1855.5622744 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63050 12:04:08 17/10/2016 1855.5700040 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63052 12:04:08 17/10/2016 1855.5798950 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -77 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63053 12:04:08 17/10/2016 1855.6866324 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -76 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63054 12:04:08 17/10/2016 1855.7846396 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -77 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63055 12:04:08 17/10/2016 1855.8352165 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -72 dBm, Rate = 24.0 Mbps
63057 12:04:08 17/10/2016 1855.8549422 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -74 dBm, Rate = 24.0 Mbps
63058 12:04:08 17/10/2016 1855.8559991 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -72 dBm, Rate = 24.0 Mbps
63060 12:04:09 17/10/2016 1855.8848957 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -77 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63061 12:04:09 17/10/2016 1856.0036910 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -77 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63062 12:04:09 17/10/2016 1856.0036910 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63064 12:04:09 17/10/2016 1856.0957282 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -77 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63065 12:04:09 17/10/2016 1856.1531107 [C03E0F A33669] [ADEMCO A130EE] WiFi WiFi:[ ControlBlockAck] ....... RSSI = -73 dBm, Rate = 24.0 Mbps
63066 12:04:09 17/10/2016 1856.1921059 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -78 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63067 12:04:09 17/10/2016 1856.2438275 [C03E0F A33669] [ADEMCO A130EE] WiFi WiFi:[ ControlBlockAck] ....... RSSI = -72 dBm, Rate = 24.0 Mbps
63068 12:04:09 17/10/2016 1856.2438275 [C03E0F A33669] [ADEMCO A130EE] WiFi WiFi:[ ControlBlockAck] ....... RSSI = -72 dBm, Rate = 24.0 Mbps
63069 12:04:09 17/10/2016 1856.2440382 [C03E0F A33669] [6466B3 FAF228] WiFi WiFi:[ ControlRTS] ....... RSSI = -74 dBm, Rate = 24.0 Mbps
63072 12:04:09 17/10/2016 1856.2966467 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -75 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63073 12:04:09 17/10/2016 1856.3334282 [C03E0F A33669] [ADEMCO A130EE] WiFi WiFi:[ ControlBlockAck] ....... RSSI = -72 dBm, Rate = 24.0 Mbps
63074 12:04:09 17/10/2016 1856.3339430 [C03E0F A33669] [ADEMCO A130EE] WiFi WiFi:[ ControlBlockAck] ....... RSSI = -72 dBm, Rate = 24.0 Mbps
63075 12:04:09 17/10/2016 1856.3973960 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -76 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63076 12:04:09 17/10/2016 1856.4998007 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -77 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63077 12:04:09 17/10/2016 1856.6043422 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -78 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63078 12:04:09 17/10/2016 1856.7089752 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -78 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63080 12:04:09 17/10/2016 1856.8115584 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -78 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63081 12:04:10 17/10/2016 1856.9140345 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -78 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63082 12:04:10 17/10/2016 1857.0161745 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -75 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63083 12:04:10 17/10/2016 1857.1185293 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -78 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1
63084 12:04:10 17/10/2016 1857.2165969 [C03E0F A33669] [*BROADCAST] WiFi WiFi:[ ManagementBeacon] ....... RSSI = -76 dBm, Rate = 1.0 Mbps, SSID = SKY6D12C, Channel = 1


You can see no IP traffic during the exchange on my network, certainly no port 443 traffic expected of an HTTPS connection. Try it for yourself download and install MS Network Analyser, start the analysis then watch the Evohome controller network traffic.

The Sky Router is transferring packets directly to the Evohome gateway because the routing information has a header to indicate its destination (A130EE), then on receipt the Gateway (Evohome Controller) distributes the packets (internally and externally) as its final destinations.

[bruce_miranda]

I too had an HR80 that wouldn't take a setpoint. It would report its temperature back to the controller but not accept the setpoint from the controller. No matter what i did, the situation didn't change. In the end I just put this down to a defective HR80 actuator circuit. But because it can still send a temperature reading back to the panel I installed this dud HR80 in the loft where all the boiler and unvented cylinder are located. If the temperature in the loft goes below 7C, I have a script that starts the boiler even if the rest of the house doesn't need any heating. So the faulty HR80 didn't land up in the bin.

Back to your issue. You arent going to solve anything analysing the wifi or network traffic. If you really want to figure out what might be causing the issue between controller and HR92 then you need to analyse the radio traffic between them. You can do this with a stand alone receiver, a HGI80 or by sniffing the packets on the BDR91. You will have to shut everything else off and unpower them, else you wouldn't be able to tell the woods from the trees. Get your system to simply include the controller and that faulty HR92. Alternatively try that HR92 with another controller.

[paulockenden]

Did you perform your capture using promiscuous mode (might need new drivers)? Without that you won't see all traffic - only broadcast traffic plus anything directed to your particular machine.

I normally use Wireshark. Plenty of us have seen the https traffic this way.