EvoHome HGI80 + OpenTherm boiler module

[dannybloe]

Hi folks,

Has anybody figured out how to get info into Domoticz from the EvoHome OpenTherm boiler module (R8810A1018) using the HGI80 module? I'd love to see at least when the boiler is activated and even better: at what temperature. Or is that already possible? I don't see that device (I think).

Cheers,

Danny

[DanD]

Hi,

Did you ever make any progress with monitoring the EvoHome OpenTherm boiler module via the HGI80? I'm working on the Domoticz HGI80 code at the moment to add some additional functionality to monitor all individual sensors rather than just zones and controller messages. I'd be happy to take a look and see if there's a simple way to decode the Opentherm module and get it to appear as an additional Evohome device in Domoticz. Unfortunately I don't have one of the Opentherm modules, but if you were able to turn on debugging in the Evohome.cpp code following the debugging guide at the bottom of the Domoticz Evohome wiki and recompile Domoticz from source on your RPi you could take a look at the Error tab in the Domoticz log window and see whether any new unknown Evohome commands are logged. This would be a good starting point.

Dan

[dannybloe]

Hey Dan!

Danny here..

I haven't made any progress on the boiler module so far. Didn't have much time to dive into this. But it's great to have someone dive into the code some more because I think that it has more potential than what is exposed just now and I'd love to provide some help (and perhaps ideas). I can try to compile Domoticz on my Pi (takes ages though) and see what info I get. I don't know if that will be today but sure as h.ll in the coming days.

I'd love to be able to see when a zone has a heating request although I suspect that that is not controlled by the zone but by the main controller. But it would be nice to see some 'light bulb' in Domoticz in the zone device that it is heating (or demanding heat).
And the time-zone difference is a nasty annoyance when you want to set a time for a heating action. So that bug shouldn't be too hard to fix.

What are you enhancement ideas?

Cheers,

Danny

(I'm the developer of dzVents Domoticz scripting library. I recently added some evohome specific commands to the lib. See updateSetpoint for instance).

[DanD]

Hi Danny,

Thanks for your quick reply. I only checked after posting and realised that you're very active on the forum!

I've been working on the evohome.cpp code over the last month or so and I'm enjoying playing with the code and getting to learn far more about both how Domoticz works and the Evohome system. I'm doing my development work on a Windows machine using Visual Studio 2015 and Inno Setup Compiler so the build times are really quick and then only testing occasionally on my Pi (version 3) which I've only had for the last couple of weeks. I'm also really new to Github development so it was a major achievement for me to have a couple of Evohome updates accepted last week (override not visible bug and multi-zone functionality)! I really like the compactness and simplicity of the Pi+HGI80 and it gives so much more potential for monitoring and controlling the Evohome system. Even though my heating is now switched off for the Spring/Summer it's great to be still able to monitor the temperatures room by room around the home.

What are you enhancement ideas?

The main new HGI80 functionality which I've developed and currently testing is to show all Evohome devices in addition to the zone devices. I have 16 radiators with HR92s in my set-up which are grouped into the max 12 zones and I want to be able to at least individually monitor the temperatures via each device and potentially override them too (I'm not 100% certain about overrides though as they may conflict with the controller - I need to test this out). I think the original Evohome code is excellent as it has most of the data structures and message decoding functionality already built in, so my coding is mainly just manipulating the data to create and update additional Domoticz devices. At the moment the functionality to add all sensors is triggered by a new 'All Sensors' button which I've added to the HGI80 hardware device in Domoticz. Oh, and I've also added the ability to pre-populated all the HGI80 device names with the controller zone names so you don't have to identify them yourself.

I'd love to be able to see when a zone has a heating request although I suspect that that is not controlled by the zone but by the main controller. But it would be nice to see some 'light bulb' in Domoticz in the zone device that it is heating (or demanding heat).

I haven't looked at the heat demand messages, but I've seen quite a few people asking for this capability. I think I don't really understand what people would like to see though as I see this as just the same as actual temp < setpoint and then the controller works out how to combine all these requests into a boiler demand? I'm happy to take a look at this also and we could possibly add the %demand value to the data items associated with each zone device which could then link to a new icon/value.

And the time-zone difference is a nasty annoyance when you want to set a time for a heating action. So that bug shouldn't be too hard to fix.

I know what you mean about the time difference bug and I'm seeing this problem on my Pi which won't accept updates via the Domoticz web interface due to a 1h time difference, but my PC works fine. I've not looked into the problem yet, but a recent fix by another user doesn't seem to fix the problem on my Pi.

Let me know when you've had the chance to set-up the Evohome log file and have some unknown command error messages. There's a great DumpMessage(msg) function in the Evohome code which is really useful for showing the full payload values of each message. I'm using the Evohome controller with in-built Wifi and the only unknown commands I see in the error log are 0x1f09 and 0x0100. The 0x1f09 must be a corrupted message as this is just part of the header and shouldn't be flagged as unknown, I've not investigated the 0x0100 messages any further.

Dan

[dannybloe]

Wow, sounds cool all this. I didn't realize that indeed a zone consists of one or more temperature/valve controllers and that you might want to see them individually in D.

I know what you mean about heat demand for a zone. Of course, when a zone is lower than the desired temperature then there's a heat demand. I realize that I'm more curious about the valve states of each radiator. Is that information available? So then you could show the percentage per valve.

Also, as I have the opentherm module, I'm curious what opentherm information is floating around the network. How it modulates. OT supports all kinds of boiler information like water temperature etc.

It would also be nice if you could have a non-evo temperature sensor as the main sensor for a zone. My bathroom only has the hr92 but it's too close to the radiator. I also have an Aeotec multisensor in the bathroom and it would be nice if that sensor provides the zone temperature. So maybe the evo bridge in Domoticz can mimic an evohome sensor using measurements from another sensor.

Cheers,
Danny

[DanD]

Thanks Danny, great ideas!

I'm not sure my programming skills are up to the task or you might need to be very patient !

Also, as I have the opentherm module, I'm curious what opentherm information is floating around the network. How it modulates. OT supports all kinds of boiler information like water temperature etc.

I've had a look at the Opentherm devices in Domoticz and it would be great if some of this information is being communicated between the controller and the Opentherm module. If it is, it might be possible to create a Evohome Opentherm device. I'm guessing though that only a limited amount of information will be transmitted otherwise it's going to be a lot of traffic. I'll be interested to see what messages you see in the log.

It would also be nice if you could have a non-evo temperature sensor as the main sensor for a zone. My bathroom only has the hr92 but it's too close to the radiator. I also have an Aeotec multisensor in the bathroom and it would be nice if that sensor provides the zone temperature. So maybe the evo bridge in Domoticz can mimic an evohome sensor using measurements from another sensor.

This is a great idea and based upon the approach taken in the code for the outdoor sensor and its binding protocol it looks possible to mimic a temperature sensor. In your situation, as you already have a bound HR92 you could even try just 'tweaking' the temperature message coming from the HR92 ie. try re-sending HR92 temp message, but with the Aeotec values so they get immediately overwritten. This would simplify all of the keep-alive messages that a virtual device would need to maintain to stop error messages appearing on the controller etc. I might try this myself and see what it does to the controller. I'm guessing it'll cause some trouble though if the controller thinks the zone temperature is jumping around, but it'll be fun to test!

[DanD]

PS I've tidied up my Github branch and synced it with the current Domoticz master so my branch is now only 1 commit ahead (Added automatic zone naming for Evohome HGI80). I'm still testing my 'All Sensors' update which adds devices for all sensors for Evohome set-ups which use either single-room or multi-room zones with multiple HR92s in each. I'll continue to commit my Evohome updates to this branch and I'll let you know if I think there's something worth testing. I'm also currently testing out sending temperature messages to the controller, but struggling to get any recognised and I'm getting frustrated trying to work out what I'm missing from the messages. Once I've got this working I might try modifying the 'Outdoor Sensor' code to add the ability to bind a virtual temperature sensor of your choice to the controller in a zone. Is your Aeotec mutisensor all setup as a device in Domoticz? I think this would be a pretty neat solution, but will likely take some time to develop.

https://github.com/Evsdd/domoticz

Dan

[DanD]

Some progress on one of the updates...

I've successfully tested some modifications to the Evohome code which converts the 'Outdoor Sensor' binding and set-up functionality into a zone temperature sensor bound to the controller. I was able to link my Domoticz Weather Underground temperature sensor to a Evohome virtual sensor and send this value as a zone temperature to the controller instead of using the HR92s sensor. Here are the very rough modifications:

First step: the Domoticz temperature sensor device that you want to link needs to be renamed to 'Outside'

Next: modify this section of the code to bind a ZoneTemp sensor rather than an ExternalSensor. I've chosen 0x11CCCC as the fixed DeviceID for this new sensor and this is sent to the controller during binding.

Original code:

Code: Select all

	while(m_nBindID==0)
		{
			AddSendQueue(CEvohomeMsg(CEvohomeMsg::pktinf,0,nGatewayID,cmdBinding).Add((uint8_t)0).Add((uint16_t)cmdExternalSensor).Add(CEvohomeID(nGatewayID)).Add((uint8_t)2).Add((uint16_t)cmdExternalSensor).Add(CEvohomeID(nGatewayID)).Add((uint8_t)0).Add((uint16_t)cmdBinding).Add(CEvohomeID(nGatewayID)));
			boost::system_time const wait=boost::get_system_time() + boost::posix_time::seconds(5);//monotonic?
			if(!m_cndBindNotify.timed_wait(lock,wait) && boost::get_system_time()>timeout)
				return 0;
		}
		AddSendQueue(CEvohomeMsg(CEvohomeMsg::pktinf,m_nBindID,cmdBinding).Add((uint8_t)0).Add((uint16_t)0xFFFF).Add(CEvohomeID(nGatewayID)));

Modified code:

Code: Select all

	while(m_nBindID==0)
		{
			//Just a hack to see if I can bind a dummy ZoneTemp sensor
			AddSendQueue(CEvohomeMsg(CEvohomeMsg::pktinf,0,nGatewayID,cmdBinding).Add((uint8_t)0).Add((uint16_t)cmdZoneTemp).Add((uint16_t)0x11CC).Add((uint8_t)0xCC).Add((uint8_t)2).Add((uint16_t)cmdZoneTemp).Add((uint16_t)0x11CC).Add((uint8_t)0xCC).Add((uint8_t)0).Add((uint16_t)cmdBinding).Add(CEvohomeID(nGatewayID)));
			boost::system_time const wait=boost::get_system_time() + boost::posix_time::seconds(5);//monotonic?
			if(!m_cndBindNotify.timed_wait(lock,wait) && boost::get_system_time()>timeout)
				return 0;
		}
		AddSendQueue(CEvohomeMsg(CEvohomeMsg::pktinf,m_nBindID,cmdBinding).Add((uint8_t)0).Add((uint16_t)cmdZoneTemp).Add((uint16_t)0x11CC).Add((uint8_t)0xCC));

Next: modify another few lines of code to send the temperature value as a ZoneTemp message rather than a message from the ExternalSensor. I've commented out the redundant UV value conversion code. The code just above this section is where 'Outside' is fixed as the name of the linked sensor.

Original code:

Code: Select all

	//FIXME no light level data available UV from WU is only thing vaguely close (on dev system) without a real sensor 
	result = m_sql.safe_query("SELECT sValue FROM DeviceStatus WHERE (Type==%d)", (int)pTypeUV);
	if (result.size()>0)
		dbUV=atof(result[0][0].c_str());
	else
		return;
	
	AddSendQueue(CEvohomeMsg(CEvohomeMsg::pktinf,0,GetGatewayID(),cmdExternalSensor).Add((uint8_t)0).Add(static_cast<uint16_t>(dbUV*39)).Add((uint8_t)2).Add((uint8_t)2).Add(static_cast<int16_t>(dbTemp*100.0)).Add((uint8_t)1));

Modified code:

Code: Select all

	//FIXME no light level data available UV from WU is only thing vaguely close (on dev system) without a real sensor 
	//result = m_sql.safe_query("SELECT sValue FROM DeviceStatus WHERE (Type==%d)", (int)pTypeUV);
	//if (result.size()>0)
	//	dbUV=atof(result[0][0].c_str());
	//else
	//	return;
	AddSendQueue(CEvohomeMsg(CEvohomeMsg::pktinf,0, 0x11CCCC,cmdZoneTemp).Add((uint8_t)0).Add(static_cast<int16_t>(dbTemp*100.0)));

All you have to do after making these changes is use the Zone Configuration menu on the Evohome controller and select the Temperature Sensor option for the zone where you want to use your own Domoticz temperature sensor. Choose 'Remote Sensor' and follow the binding instructions. While the controller is waiting for the blinding signal, click on the 'Outdoor Sensor' button on the Evohome hardware device in Domoticz and they should bind successfully. Within about 5min you should start to see the new temperature values appearing in the zone!

I'll tidy up the code to add more flexibility and also reinstate the 'Outside Sensor' functionality (unfortunately this is no longer compatible with the wifi controller as it's been removed from it's menus). I thought it was worth sharing these changes to show what's possible with the HGI80 device and the Evohome Domoticz code.

Dan

[DanD]

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

[dannybloe]

The past two days (!) I have been trying to compile the branch on my Pi without success. After almost a day of waiting it fails:

Code: Select all

[100%] Building CXX object CMakeFiles/domoticz.dir/tinyxpath/xpath_static.cpp.o
Linking CXX executable domoticz
collect2: error: ld terminated with signal 9 [Killed]
CMakeFiles/domoticz.dir/build.make:4202: recipe for target 'domoticz' failed
make[2]: *** [domoticz] Error 1
CMakeFiles/Makefile2:64: recipe for target 'CMakeFiles/domoticz.dir/all' failed
make[1]: *** [CMakeFiles/domoticz.dir/all] Error 2
Makefile:133: recipe for target 'all' failed
make: *** [all] Error 2

I updated all the boost libraries and the packages but to no avail. I'm running on a Pi B+. Any suggestions?

[DanD]

Hi Danny,

Sorry to hear about the trouble you're having with compiling in the pi. I'm assuming that it's the make that's failing and that the cmake works OK? Have you tried using make without any -j option? I've had trouble with the -j switch on first compiles. I'll try compiling from scratch on my pi tonight to double check that there aren't any files that have been incorrectly pulled into the repository. I had a quick search of the forum and some other users have hit a tinyxpath compile error which was fixed by removing an out of date boost library: apt-get remove libboost*.

Dan

[DanD]

Ignore my previous sggestion about the make problem being possibly caused by out of date boost libraries. Looking at the error more carefully, it looks like it's failing at the final step and I think this is more likely to be caused by some incorrect additional files being pulled into my repository. I'll look into the problem this evening.

Dan

[DanD]

Hi,

I've tested out installing my git repository from scratch on my pi, cloning directly from github on and it worked OK with no errors. I think the problem is likely to be some older boost libraries on your pi which need to be removed and then updated.

Good luck!

Dan

[stuiow]

Hi guys.

I've got a HGI80 setup with my domoticz and I 've got the latest beta installed.

Do you think that any chances that you've submitted into domoticz has had any adverse effect with the Evohome actual temperatures?

A few weeks ago I had trouble getting any zone actual temperatures (DHW was fine, so too were all the setpoints). Outdoor sensor hasn't worked for a while now either.

A beat 2 weeks ago fixed all that but since updating to newer beta's, the problem has come back, i'm getting no actual temperatures updating, but all setpoints and DHW data continues to work.

I've put a bug in the GitHub about it but no progress has been made there and I don't really understand the programming going on here, I need to get involved and learn about all this really soon.

[DanD]

Hi,

Do you think that any chances that you've submitted into domoticz has had any adverse effect with the Evohome actual temperatures?

I've taken a look at the details you've posted in the bug reports on Github and checked the changes that I made that were included in the May 1st update. Of the 2 changes, the only one that I think could possibly be causing a problem is that the HGI80 now specifically requests the temps for each zone from the controller every 5min. This was to fix a problem that the controller doesn't seem to send temps for devices in a multi-room setup and they have to specifically requested.

A few questions for you to help troubleshoot; which evohome controller do you have, is it the newer version with inbuilt wifi or are you also using a RFG100 gateway? Could you post a screenshot of the Domoticz devices page showing your list of evohome devices? Do you also have the evohome set-up via scripting (and are the values being updated OK)? Is everything else working OK with the evohome system, is the controller display showing updated values OK? Also, when you say that all the zone temps are frozen, is this also the case with the values shown on the Domoticz devices page?

Thanks,
Dan

[stuiow]

A few questions for you to help troubleshoot;
which evohome controller do you have, is it the newer version with inbuilt wifi or are you also using a RFG100 gateway? RFG100 gateway i use

Could you post a screenshot of the Domoticz devices page showing your list of evohome devices?
https://www.dropbox.com/s/uwtsnzo6c40vh ... e.png?dl=0
Do you also have the evohome set-up via scripting (and are the values being updated OK)? No Scripting, all taken from HGI80 interface

Is everything else working OK with the evohome system, is the controller display showing updated values OK? THe hot water works perfectly, no difference there. Set points are also working fine. I can contrinue to change setpoints.

Also, when you say that all the zone temps are frozen, is this also the case with the values shown on the Domoticz devices page? Yes.

BUT just as i have answered all that, i noticed there were multiple "EvoTouch Colour" devices in my devices lsit. So i deleted all the old ones last seen and kept the one recent one. I then rebooted Domoticz.

I then noticed the outside temperature appeared on the evo screen, took a look at the temperatures and they are all there and updated.

So it looks like the problem was for whatever reason, there were multiple EvoTouch Colour devices in my list. Old ones deleted, all is well.

WIthout your assistance, i doubt i would have noticed that, so Dan, big thanks! I dont often take a look at the devices screen for evohome stuff.

[DanD]

Excellent, I'm pleased its all working OK (and also relieved that I hadn't introduced a bug in the recent evohome updates which were meant to be bug fixes ). I'm doing all my evohome development & testing with the wifi controller so I have a nagging worry that I might fix something for the newer controller, but break compatibility with the RFG100. PS I'm jealous that you have the outside temp on your controller, it's a shame they dropped this from the wifi controller interface.

[DanD]

I've posted an update to my github development area with an update to the Evohome functionality. I've added the ability to see the heat demand for each zone. The demand info is shown as switch devices and they show demand as On/Off & %. If you want to try it out I recommend making a backup of your db before installing. Once it's installed, I also recommend deleting all Evohome HGI80 relay devices and then restarting (no need to remove any zone temp sensors). This should help prevent problems with duplicate conflicting devices. I you do try it out please let me know how you get on. The next 2 items on my list are to finish off the code for detecting all sensors for setups where multiple sensors have been grouped into a single zone and then to take a look at the opentherm commands.

Dan

[dannybloe]

I'm recompiling at this moment. I removed all traces of the boost stuff and reinstalled it. Hopefully compiling/building works now. I'm very curious to try this new stuff....

[DanD]

I've just posted another update to my Github Evohome development area. I've updated the Domoticz graphing code for switch devices so that the zone demand is now shown as a % rather than just On/Off. Note: you'll need to refresh the cache on your browser if you want to try this out as the small update is to the javascript in Domoticz.js.gz (so no need to recompile for this update). Here's an example from one zone over the last few hours showing the heat demand values from one of the HR92 radiator controllers:

DEMAND.PNG (93.53 KiB) Viewed 6041 times

and here's the temperature profile for this zone over the same period:

TEMP.PNG (109.93 KiB) Viewed 6041 times

I still need to complete some further testing before I'm ready to submit a pull request to merge this all back in into the main Domoticz code and I'll post an update once this is completed. I'm still working on investigating whether it's possible to decode the Opentherm messages for those using the Evohome Opentherm bridge and another update to show all temperature sensors for grouped zones.

Dan