EvoHome HGI80 + OpenTherm boiler module

[DanD]

@thecosmicgate

Hi,
I've done a little more searching for information on the Itho Spider and even watched some of the installation videos on their website (unfortunately I understand only a little Dutch, sorry ). I didn't realise that the Honeywell HGI80 USB device was used by non-Honeywell products. Have Itho support provided any guidance on what functionality Domoticz should provide if the HGI80 device is connected or any advice on set-up? I'm an active developer of the Domoticz Evohome code which uses the HGI80 device to monitor and control a Honeywell Evohome installation, but your message is the first time I've been contacted about using this set-up with the Spider. I'm guessing that the Spider must either use some licensed version of the Honeywell system or is possibly manufactured by Honeywell.

I assume that you added a 'Evohome USB (for HGI/S80)' Domoticz hardware device which then generated the errors in the log? Have any devices appeared in your Domoticz device list? If some devices have appeared, could you either PM me a screenshot of your device list or post it in a reply and I'll try and help further.

Dan

[rogerrabbit]

When I installed the drivers I noticed the hgi80 to contain an fpga. It may therefore well be that the fpga has been reprogrammed to fit the needs for this setup. A totally different protocol could have been implemented.
Fpga stands for field programmable gatearray and immensely powerful in its flexibility. It usually comes with an eeprom on the side that contains the configuration for the fpga. The config always needs to load into the fpga at startup.

Cheers


Sent from my iPhone using Tapatalk

[DanD]

@rogerrabbit

Thanks for the information. I'm really hoping that the HGI80 devices are identical and that understanding how the device is controlled within the Itho system may help fill some of the gaps in my knowledge.

Dan

[shutty101]

Hi,

Yes, happy to confirm that you can definitely control a HR92 in this way and possibly some of the early (pre-Domoticz) examples did try this out (they may still be lying around in Github). All of the pieces of functionality you'd need exist in the Domoticz Evohome code (evohome.cpp), but it's not configured to work in this way. Here are a few pointers to some hacks that you could make to evohome.cpp to possibly get this working, but realise that this will take some time to pull together:

The code looks for device type #1 to identify the controller and doesn't proceed until it finds one. If you hard-coded the controller to a dummy value it should at least get the code running. It will obviously fail to receive any of the necessary zone set-up info that it needs, but you may be able to activate the 'All sensors' function which adds any temperature sensor devices that it detects and your HR92s may show up if they are sending any messages in their unbound state. You'd then need to tweak the 'bind relay' function to bind the HR92 so that it responds to messages from your dummy controller.

Alternatively, if none of this works (I've never tested it out) you'd have to extract the following pieces of the code and get them running together with a dummy controller ID:

binding
keep-alive
zone_setpoint

Once the HR92 is sent a setpoint it will send out a heat_demand message on a regular basis which reflects the setting of the TRV and you'd need to come up with some algorithm of how to link this to your boiler control, the simplest would be demand >0=boiler on. I think the HR92 will do the rest and gradually reduce the heat_demand until the setpoint is exceeded by a certain amount. Do you already have a way of controlling your boiler that you can link in to all of this?

Hope this is of some help.

Dan

Hi Dan
Have you had chance to look any further at the "headless controller" approach. My hgi80 arrived yesterday and I have set up an environment in windows for testing. I have given it a false ID as suggested and I have HR92 messages in the console and the device appearing in the device list, although the binding process is not completing on the HR92. I will look to tweak the bind process next, but not sure what that will be yet. Only had 30 mins looking at the code. Can you point me at any further info on what data (eg zone info) the controller is providing so that I can simulate it. thanks

[DanD]

@shutty101

I haven't got very far yet with the 'headless' version of the Evohome Domoticz code, sorry. I hit a problem early on which has diverted my focus for a while. The problem relates to the HGI80 always adding its internal deviceID as the first device in every message that it sends. You have to set the ID to 18:730 for a message to send successfully and I think each HGI80 converts this ID to its own unique ID before sending the message. This prevents the HGI80 from being able to send messages as if it is a controller. I've spent quite a long time working out how to work around this for most message types, but unfortunately I think there are 1 or 2 message types which must be sent from a controller. Hence, I've recently switched my attention to tweaking the 'EvohomeWirelessFW' RFBee firmware, which was written by FullTalgoRythm (Hydrogenetic). I hope to be able to use the RFBee to send any type of message, which will then permit a 'headless' set-up. It's all going to take quite a long time!

The Domoticz code set-up process begins by sending a 10E0 SYSINFO message followed by a few other set-up messages. A good place to start is to have a look at the RequestCurrentState function in the code. This triggers 6 different requests which gather info about the system.

Hope this helps.

Dan

[shutty101]

@Dan

many thanks for the update, I saw a note on another forum post and I suspected you had hit a snag. If I have understood your explanation correctly, it does not look like you can circumvent this or inject the right data at any point, if it is the hgi80 driving that behavior.. so switching to something you have full control over with the RFBee makes a lot of sense, but to your point means a lot of coding to build the functionality I guess. Is there a resource that documents the message structure to and fro or are you capturing this somehow and interpreting it. Is your thought to do away with the hgi80 altogether (and controller of course) and use the RFbee for transmit and receive or a blended approach, still leveraging the hgi80.. I think I will cut my losses, send the hgi80 back and turn my attention to anything I can support on the RFbee side. (But will all be steep learning for me i suspect, but very interesting and a nice challenge)

[DanD]

@shutty101

it does not look like you can circumvent this or inject the right data at any point, if it is the hgi80 driving that behavior..

Correct. I think I wasted quite a bit of time seeing whether it was possible to trick the HGI80 into sending 2 messages, as a way of getting around the problem. However, I should have thought about this a bit more as it's simply not possible. I'm spending a bit of time understanding the message packet structure at the moment as I tweak the RFBee firmware and this seems to confirm my thoughts.

I'm sorry for getting your hopes up about the HGI80 device.

Dan

[shutty101]

@Dan
no worries on getting my hopes up, its all part of the learning / discovery.
Have ordered my RfBee and UartsBee on a slow boat from China. (Could not find stock anywhere, think you got the last one)

Will flip over to the other forum now http://www.automatedhome.co.uk/vbulleti ... GI80/page4 to follow progress.

good luck with it and hopefully by the time my bits arrive you will have some basic functionality working.... no pressure.

edit .... argh missed the sodaq suggestion. they still have them for anyone else interested.

[bcoakley]

Hey DanD

Just wondering if your Raspberry Pi branch of Domoticz has the ability to push TPI %demand to InfluxDB?

I'm currently running the latest Beta on Ubuntu on my ESXi rig and although I can see %demand in the Domoticz graph for a TPI device - a HR92 or the Boiler Relay - I cannot seem to push this data to InfluxDB so that I can really dig into my setup using Grafana.s

If this feature is available exclusively in your branch I'd consider ditching the ESXi setup in favour of a Pi but it would be great to hear your thoughts first.

Cheers

[DanD]

@bcoakley

I did develop a potential fix for this issue, but I didn't get to the point of testing as I don't have the necessary set-up to test out the fix and got diverted onto other issues, sorry. The potential fix is visible in the commit history in the master branch of my development area, if you are interested in spending some time testing it out? I had to revert the changes due to the lack of testing. All my code should work fine on any Linux (or windows) set-up (I run it on my Pi, Ubuntu VMs and Windows 7) and my aim is always to commit to the main repository once each piece of development work is finished. Here's the link to the commit and you'll see that the changes are pretty simple (and may not work at all ).

https://github.com/Evsdd/domoticz/commi ... 386973bcae

You can either make the simple changes yourself in a test area on your machine and let me know how you get on. Or if you'd prefer, I can create a temporary new branch for this and then once we're happy it's working OK, merge it into the main area. Let me know what you'd like to do.

Dan

[bcoakley]

DanD

It worked

Screen Shot 2017-03-18 at 21.50.47.jpg (265.25 KiB) Viewed 4235 times

I cloned your git and loaded that specific commit, compiled and it just worked Luckily I hadn't really done much to my domoticz/grafana setup beforehand so I just ditched the setup I had and reconfigured using your build from scratch.

I had a quick look at the current state of the code (beta branch) around the area you modified and it seems like the structure has changed a bit since you did your work - I couldn't really figure out how complicated it would now be to merge your changes with my rudimentary programming skills but it does look like it will be more work than it would have been at that time unfortunately. It would be great to see it merged to the master obviously so others can benefit from it and I can run a more recent version but I appreciate that this is probably not as straightforward now as it once was. My guess is that the recent changes are part of the "Push to InfluxDB" feature which has recently been added but that is purely a guess.

Thanks for your work anyway, it's been stable for almost a week now and is a really useful feature.

Cheers

[DanD]

@bcoakley

Fantastic! Thanks for your willingness to test out the fix and letting me know the outcome. The additional information about the "Push to InfluxDB" functionality is really helpful too and possibly explains why the Evohome heat demand value issue was closed a few weeks ago which confused me. I'll take a look at the current beta code and see what changes I need to make to integrate this fix. I'll post an update when I've submitted a pull request.

Thanks again and welcome to the Domoticz Evohome development team !

Dan

[dlefol]

Hello,

I have just installed a HGI80 on my Pi to monitor my evohome setup. My evohome is equiped with the OT module and I have underfloor heating controlled via a HCC80 unit.
All the zones have been detected fine, but the relays corresponding to the underfloor heating (HCC80) have not been detected properly. I only see one of them and it seems that the heat demand of the different zone plugged to the HCC80 are agregated in a single relay.
I also have a boiler relay and a boiler (OT bridge) relay. The bolier relay shows a % of heat demand, but the boiler (OT bridge) relay just show off command being received at different time (so the graph is alwayz at 0% since no On command received).

I have moreover a lot of error messages in the logs of domoticz (around 2-5 errors message per minute) such as the one below:

Code: Select all

2017-11-15 21:41:03.931 Error: evohome: EXTERNAL_SENSOR: Error decoding command, packet size too small: 1
2017-11-15 21:41:03.931 Error: evohome: unable to decode payload for command 0002
2017-11-15 21:41:24.731 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 1
2017-11-15 21:41:24.731 Error: evohome: unable to decode payload for command 3ef0
2017-11-15 21:41:24.756 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 6
2017-11-15 21:41:24.756 Error: evohome: unable to decode payload for command 3ef0
2017-11-15 21:42:19.571 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 1
2017-11-15 21:42:19.572 Error: evohome: unable to decode payload for command 3ef0
2017-11-15 21:42:19.596 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 6
2017-11-15 21:42:19.596 Error: evohome: unable to decode payload for command 3ef0
2017-11-15 21:43:13.419 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 1
2017-11-15 21:43:13.420 Error: evohome: unable to decode payload for command 3ef0
2017-11-15 21:43:13.447 Error: evohome: ACTUATOR_STATE: Error decoding command, unknown packet size: 6
2017-11-15 21:43:13.447 Error: evohome: unable to decode payload for command 3ef0

Is it normal that the relay of the underfloor heating are not detected separatelzy ?
I thought the OT relay was implemented now. Is it normal that mine is at 0 all the time ?
I've read on the forum that some errors are normal, but I'm pretty sure the amount of error I see is anormaly high. Any idea what can be the cause ? I tried moving the HGI80 around but didn't see to change anything (and it s quite clause to the evohome controller so it should receive the signal fine I think).

Any help is appreciated. I tried looking around the forum but no luck so far

[dlefol]

no one has this problem ??

[dobje]

Yes same error

[dlefol]

I basically gave up as I couldn't find any info on why this doesn't work well... kind of bought a HGI80 for nothing

[HFman]

Little late to respond may be.. but.. your floor heating is for every "tube" a temp sensors ?
I wondering if you really "miss" something.