EvoHome HGI80 + OpenTherm boiler module

[dannybloe]

Cool!!

[StanHD]

Have been tracking this thread and would just like to thank you Guys for the hard work here. The improvements you are making to Evohome / Domoticz integration are really useful, and it's very much appreciated.

[stuiow]

Have been tracking this thread and would just like to thank you Guys for the hard work here. The improvements you are making to Evohome / Domoticz integration are really useful, and it's very much appreciated.

Completely agree, same here

[DanD]

Hi,
Here's another update which I've just posted to my github area. This adds the ability to create temperature sensors for all devices which is useful where you have more HR92s or other temperature sensors than the maximum of 12 zones and you've had to group some into a single zone (either a multi-room or single-room zone set-up). If you're interested in seeing the temperature profile of each individual device within the zone then this functionality might be helpful. For example, I have 2 radiators one in each of my 2 bathrooms and these are set-up as a multi-room zone on the Evohome controller. I'm interested in seeing the temperature profile of each radiator in this multi-room zone.

Here's how to set it up. Go to the Hardware tab and you'll see a new button labelled 'All Sensors' attached to the HGI80 (you'll have to refresh your browser cache after installing the update)

AllSensors Button.jpg (15.64 KiB) Viewed 5057 times

If you click on this button it will add a temporary dummy temperature sensor with a Unit(zone) number 13 which begins the process of adding an individual zone temperature device for every unique sensor that the HGI80 detects. The dummy device will disappear once the first sensor has been detected and you'll start to see lots of devices with Unit(zone) numbers 13 and higher and labelled 'Zone #' where # is the zone group defined on the controller (the Unit(zone) number is the original zone value offset by 12). If there are multiple sensors within one zone these will all have the same name and Unit numbers, but unique IDs. Here's a screenshot of my 16 new 'All Sensors' devices, one for each HR92:

AllSensors.jpg (139.63 KiB) Viewed 5057 times

and here's my separate list of 12 standard zone devices for comparison which all still function as normal:

AllZones.jpg (101.89 KiB) Viewed 5057 times

Usage notes: if you don't click on the 'All Sensors' button this update has no effect on your device list and it will remain unaffected. If you want to remove the functionality, simply select and delete all these new devices with Unit values in the range 13-24 and the functionality will be disabled. The new devices update their temperatures and setpoints based upon the messages received by the HGI80 directly from the sensors themselves rather than from the controller. You only need to enable the functionality once and the devices will remain and update after each restart.

Dan

[DanD]

Here's how the different temperature profiles look for my 2 bathroom radiators in the multi-room zone set-up using the 'All Sensors' function to create the individual sensors

Zone4.jpg (58.18 KiB) Viewed 5056 times

Dan

[stuiow]

I see your work has made it onto today's Beta 3.5228!

Congrats!.
I will installed and setup the new stuff, i'll look more into it all later or tomorrow, early start.

Many thanks!

[DanD]

Thanks for the feedback!

You've reminded me to post an update with a list of Evohome HGI80 functionality changes that are included in the 3.5228 beta.
Here's a brief list of the updates.

•Added automatic temperature device naming
•Added 'Bind Temp Sensor' button which enables the linking of non-Evohome room temperature sensor devices
•Added devices to monitor heat demand
•Added 'All Sensors' button which enables functionality to monitor individual device temperatures in zones with multiple devices (single-room and multi-room zones)
•And a few bug fixes

I'm also working on a few more tweaks:

•Update to improve automatic zone naming in situations when zone_name messages get interrupted
•Add functionality to handle installations where there are multiple controllers within range
•Fix bug preventing battery levels appearing in device list
•Investigate periodic corruption of groups of messages
•Investigate whether any Opentherm messages are available

PS I had to tidy-up my github area and merge in the main Domoticz changes to update my branch before the pull request. I hope this hasn't messed-up your github branch.

Dan

[StanHD]

I have updated to Beta 3.5239 under Windows. My set-up consists of radiator valves and "Round" room thermostats. So I used the "All Sensors" button and after a time got all of the radiator sensor values, set points and demand status, as well as the existing thermostat sensor values and set points. So basically everything I could need. Excellent, thank you very very much for your work.

[DanD]

Great. Thanks for the feedback. Really happy that the new functionality is all working with your set-up and I hope you find it useful.

I think I've also completed my improvements to the auto zone naming, I'm still testing the set-up for environments with multiple controllers within range and I've fixed the battery level info display. Here's how the battery level info currently looks (column filled with 100/200 values which represent 50% & 100% battery charge):

Battery levels.jpg (164.99 KiB) Viewed 4992 times

I've not tried testing out swapping out the batteries with almost exhausted ones yet to see whether the battery low messages in Domoticz need tweaking for Evohome or whether I should normalise the raw Evohome battery values to 0-100. Whilst testing out the battery levels fix I had to keep opening up one of my HR92s to trigger the battery message as otherwise it's only sent about once per day which makes testing rather tedious . Anyway, I discovered that the HR92s send their own 0x10E0 (sysinfo) message as they start up which shows their date of manufacture and software version. This has prompted me to explore whether there are any other commands not yet implemented in the Domoticz Evohome code. I've found 5 additional recognised commands so far just by sequentially sending every combination to the controller, but I'm not sure I'll be able to work out what any of them do. Based on some of the limited documentation on what should be achievable with the HGI80, the only obvious missing functionality is the ability to grab the fault log from the controller and also enable a password protected mode (which I'm hoping I don't trigger accidentally during my testing!). As mentioned previously, I don't think it looks like any of the Opentherm info is transmitted wirelessly and the bridge translates the Evohome demand messages into the Opentherm control. I think the bridge must also provide some feedback to the controller via it's return boiler demand messages, but I haven't worked this out yet.

Dan

[DanD]

Here's some further info on the unknown commands that I'm seeing during my testing. Here a snapshot of the request (RQ) commands I'm sending to the controller with a response (RP) received for 0x10A0:

Code: Select all

2016-06-12 09:43:37 095 RQ --- 18:002858 01:073076 --:------ 109B 001 00 ( )
2016-06-12 09:43:38 095 RQ --- 18:002858 01:073076 --:------ 109C 001 00 ( )
2016-06-12 09:43:39 095 RQ --- 18:002858 01:073076 --:------ 109D 001 00 ( )
2016-06-12 09:43:40 095 RQ --- 18:002858 01:073076 --:------ 109E 001 00 ( )
2016-06-12 09:43:41 095 RQ --- 18:002858 01:073076 --:------ 109F 001 00 ( )
2016-06-12 09:43:42 095 RQ --- 18:002858 01:073076 --:------ 10A0 001 00 ( )
2016-06-12 09:43:42 045 RP --- 01:073076 18:002858 --:------ 10A0 006 0016A80003E8 ( ¨ è)
2016-06-12 09:43:42 evohome: unknown command 10a0

I've also noticed that 0x10A0 appears elsewhere in the log too with a larger payload:

Code: Select all

2016-06-12 23:39:03 045 RQ --- 07:024946 01:073076 --:------ 10A0 006 0016910003E4 ( ‘ ä)
2016-06-12 23:39:03 evohome: unknown command 10a0
2016-06-12 23:39:03 045 RP --- 01:073076 07:024946 --:------ 10A0 006 0016A80003E8 ( ¨ è)
2016-06-12 23:39:03 evohome: unknown command 10a0

Here are the other recognised commands so far:

Code: Select all

2016-06-11 18:00:03 095 RQ --- 18:002858 01:073076 --:------ 0006 001 00 ( )
2016-06-11 18:00:03 045 RP --- 01:073076 18:002858 --:------ 0006 004 00050000 ( )
2016-06-11 18:00:03 evohome: unknown command 0006
2016-06-11 18:00:19 095 RQ --- 18:002858 01:073076 --:------ 0016 001 00 ( )
2016-06-11 18:00:19 045 RP --- 01:073076 18:002858 --:------ 0016 002 0019 ( )
2016-06-11 18:00:19 evohome: unknown command 0016
2016-06-11 18:04:13 095 RQ --- 18:002858 01:073076 --:------ 0100 001 00 ( )
2016-06-11 18:04:13 045 RP --- 01:073076 18:002858 --:------ 0100 005 00656EFFFF ( enÿÿ)
2016-06-11 18:04:13 evohome: unknown command 0100
2016-06-12 09:51:58 095 RQ --- 18:002858 01:073076 --:------ 1290 001 00 ( )
2016-06-12 09:51:58 045 RP --- 01:073076 18:002858 --:------ 1290 003 003E22 ( >")
2016-06-12 09:51:58 evohome: unknown command 1290

Once I've exhausted the list of possible commands I'll have a play with the structure of the info I send in my requests to see if I can work out the meaning of any of the messages.
Dan

[DanD]

Just a quick update. I've updated the Domoticz Evohome wiki to describe all the new HGI80 functionality available in version 4.5337 beta onwards.

Enjoy!

Dan

[MLS]

Interesting... Would it be possible to directly send/receive setpoints to/from a HR80 or HR92 using the HGI80 this way? Without the Evotouch controller in between?
I'm experimenting with the fullTalgoRythm/EvohomeWirelessFW firmware, but still unsuccessful at this point.

[DanD]

Hi,

Yes, pretty much anything is possible with the HGI80! You have to be careful not to cause conflicts with the controller commands, but yes the HGI80 can communicate 2-way directly with each device. The current Domoticz Evohome code primarily listens to the messages from the controller, with only 1or 2 exceptions and I've been working on this extensively recently as I've been developing the code further to cope with noisy environments with multiple Evohome installations. I'm not 100% sure, but I think the HGI80 control commands are just copies of the controller messages and go straight to the devices.

Dan

[MLS]

Thanks DanD, that's great! I'll try to get the fullTalgoRythm FW to send properly and scout for a secondhand HGI80 in the meanwhile

[DanD]

Good luck with the RFBee. I don't have one, but I've taken a brief look at all the great work that Hydrogenetic has produced in their Github area. The baudrate and clock speed set-up seems to be one of the barriers to getting it working and I don't know if the 115200 speed is essential, but hopefully once you've got these running in a stable state it should be great.

[RFMuser]

Hi,

I've updated my Github branch to add in the ability to use any of your Domoticz temperature devices as a remote temperature sensor for any Evohome zone if you're using the HGI80. It works by creating and binding a Evohome remote zone temperature device in Domoticz and then you can link this device to your chosen temperature sensor by giving them both the same device name.

Here are the detailed instructions if you want to test this out once you've compiled the Github branch:

• On the Evohome controller: press and hold the settings button to get into the set-up menu. Choose 'Zone Configuration' and then select the zone you want to link to the temperature sensor. Choose the 'Temperature Sensor' option, then 'Remote Sensor' and accept the replace/re-bind message. The controller will now be waiting for the binding message.
  
  In Domoticz, choose the Hardware option in the Setup tab and click on the new 'Bind Temp Sensor' button (you'll probably need to refresh your browser cache to get the button to appear as I've updated HardwareController.js). After a few seconds you should see a confirmation in Domoticz and on the controller that the binding was successful.
  
  Click on the devices list in Domoticz and you should see the new Evohome zone temperature device labelled 'Unknown' with a zone (Unit) number in the range 40-51 (this allows for remote sensors on all 12 zones if required). You now need to rename this zone and the temperature sensor you want to link and give them both exactly the same name.

After about 5min you should start to see the zone displaying the remote sensor temperature value on the Evohome controller and in Domoticz. An added bonus is that if you set the HR92 to display the zone temperature rather than the default setpoint temperature, it will also show the remote sensor temperature.

If the binding fails you'll end up with a redundant new zone temperature device in Domoticz which you should delete and then try the binding again. I recommend waiting a while (ideally at least 1 hour) after starting Domoticz before setting up the remote zone temperature devices as this allows it to collect a list of all Evohome devices and their Device IDs. When creating the new devices, it has to generate a new Device ID and there is the unlikely possibility of a conflict. If you're just testing the functionality, then it's OK to set them up immediately.

I'll submit a pull request to the main Domoticz repository once a few users have had a chance to test it out.

https://github.com/Evsdd/domoticz

Dan

Great work! You mentioned this in another topic where I requested this functionality. I tried it back then but only succeeded on the outside air temp. Today I needed to link a temp sensor to my Evohome system as the room temp jumps up and down all the time. This because the radiator has too much influence on this controller. It also causes the controller valve (HR92) to open/close the whole time so not efficiently controlling room temp, and draining the battery faster because of the extra movements.
I have now successfully linked a RFlink sensor to it! As test tried a virtual sensor as well. Basically anything can be matched.

Thanks!. If you have some reference on how you achieve this would be interesting.

[DanD]

Excellent, thanks for letting me know that the functionality works OK for you! Are you using the main Domoticz beta code or the version from my Github branch? The reason that I ask is that another user recently identified a bug in the main Domoticz code which has now been fixed, but I wondered which version you've been able to use successfully?

Unfortunately I don't think I can answer your question, if I'm understanding your question correctly, about a reference on how I achieved the functionality, as I just made up the solution myself because you requested it (I enjoyed the challenge). The HGI80 device along with suitably modified Domoticz Evohome code can simulate any number of Evohome devices that you might want. As long as you've been able to reverse-engineer the commands that the Evohome controller expects from a particular device, then the HGI80 can send these and the controller cannot distinguish these messages from the real ones. As an example, the HGI80 could easily be used to act as a very simple repeater. Any messages that it hears from a specific device with a poor signal path to the controller, it could replicate and re-send. If you want to add a completely new device to your system simulated by the HGI80, the first step is get its new unique DeviceID (a bit like a MAC address) recognised by the controller. This step is achieved by binding the device to the controller and this adds the new DeviceID to its whitelist of acceptable DeviceIDs. My code just selects a new DeviceID +1 greater than the highest DeviceID currently in use in the system. The HGI80 then pretends to be an Evohome temperature sensor device, but uses the temperature copied from the sensor than you've chosen to link (pretty simple really). I ended up testing the functionality using a Weather Underground sensor somewhere else in the world and thought it was a really cool feature that the HR92 radiator controller also showed this temperature value too (I get impressed by pretty stupid things ).

Dan

[SevenW]

Great work. A few days back I upgraded to the latest domoticz beta, from a januari 2016 version. A lot of progress. I like the relay values (valve settings). At first I was confused a bit, until I found the "all sensors" button. Then I got readings making sense. I experience one issue:

I am missing a temperature sensor. It happens to be my RFBee, which I joined on the Evotouch to zone 6. in the evoraw.log it is all there, but it does not show as device in domoticz. Any idea?

It is device 0x1cdada

Code: Select all

2016-10-20 18:59:50 074  I --- 07:056026 --:------ 07:056026 30C9 003 000852 ( R)
2016-10-20 18:59:50 evohome: ZONE_TEMP: Zone sensor msg: 0x1cdada: 0: 2130
2016-10-20 18:59:52 evohome: invalid message structure - possible corrupt message
2016-10-20 18:59:57 evohome: invalid message structure - possible corrupt message
2016-10-20 19:00:09 049  I --- 04:219486 --:------ 04:219486 30C9 003 000930 ( 	0)
2016-10-20 19:00:09 evohome: ZONE_TEMP: Zone sensor msg: 0x13595e: 0: 2352
2016-10-20 19:00:09 evohome: ZONE_TEMP: Zone sensor msg: 0x13595e: 14: 2352
2016-10-20 19:00:20 062  I --- 04:194093 --:------ 01:070648 12B0 003 060000 (  )
2016-10-20 19:00:20 evohome: ZONE_WINDOW: 7: Window 0
2016-10-20 19:00:22 063  I --- 04:194093 --:------ 01:070648 12B0 003 060000 (  )
2016-10-20 19:00:22 evohome: ZONE_WINDOW: 7: Window 0
2016-10-20 19:00:23 evohome: invalid message structure - possible corrupt message
2016-10-20 19:00:24 048  I --- 01:070648 --:------ 01:070648 2349 007 0607D000FFFFFF (Ð ÿÿÿ)
2016-10-20 19:00:24 evohome: ZONE_SETPOINT_MODE: Setting: 7 (0x513f8): 2000 (0=Auto)
2016-10-20 19:00:27 evohome: invalid message structure - possible corrupt message
2016-10-20 19:00:44 evohome: invalid message structure - possible corrupt message
2016-10-20 19:00:53 evohome: invalid message structure - possible corrupt message
2016-10-20 19:00:57 evohome: invalid message structure - possible corrupt message
2016-10-20 19:01:00 072  I --- 07:056026 --:------ 07:056026 30C9 003 0007E4 ( ä)
2016-10-20 19:01:00 evohome: ZONE_TEMP: Zone sensor msg: 0x1cdada: 0: 2020

SevenW

[DanD]

@SevenW.

Thanks for the feedback. Can I just check exactly how you've setup the RFBee and what you're expecting to see in Domoticz? Have you successfully linked the RFBee device as a non Evohome temperature sensor via the 'Bind Temp Sensor' function and is its temperature being used (and correctly displayed) by the Evohome controller for zone 6? If it is, then I'd have expected an additional device to have appeared in your device list with Unit = 40 (this is separate functionality from the 'All Sensors' function).

You might have worked out all of this already, but the 'All Sensors' function creates a large number of additional Heating-Zone temperature devices in the device list, many of which will simply be duplicates of the ones already there which showed the sensor values reported from the controller. These additional devices are showing the messages immediately as they sent by the temperature sensor rather than via the controller. However, in the case of the RFBee temperature device, its messages are actually sent from the HGI80 as it is performing the function of an Evohome temperature sensor device and I don't think an additional device will be created when the 'All Sensors' function is activated (I'm not 100% sure about this as I'd need to do some more checking of exactly how the 'All Sensors' and 'Bind Temp Sensor' functions interact).

Could you post or PM me a screenshot of your complete Evohome device list in Domoticz as this would help me work out exactly how your system is currently being detected by the HGI80 and Domoticz? The evoraw.log output is really helpful thanks, but I'm trying to also work out exactly how this device has been configured in Domoticz.

Thanks,
Dan

[MLS]

I wanted to add a success story as well. My HGI80 just arrived and worked straight out of the box, in contrast to my fullTalgoRythm attempt that did receive, but was unable to send properly. All six HR80/HR92 radiator controllers are properly read out and setpoints are transmitted.

Because I don't trust the Evohome controller anymore in taking control of the boiler via either the Opentherm module or the relay module (sometimes it just keeps burning without heat request), I'm now looking for a way to control the BDR91 from domoticz directly (W/O Evotouch) and/or overriding its status (switching off) when I detect it remains activated when it shouldn't.
I'm using a separate Opentherm thermostat for the living room and want to be able to fire an extra heating demand when one of the other rooms is falling behind the setpoint. This requires me to control the BDR91 without binding it to the Evotouch. I've successfully bound it to a device in Domoticz via the 'Bind Relay' button, but the switch item is grayed out (output only, just like the dummy relays of heat request). Is this the intended functionality and is controlling the relay not (yet) implemented?
Of course I can use a wifi relay or inject commands into a OpenthermGateway module when I get it operational, but the ability to control the BDR91 from Domoticz would be nice anyway.