Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

zxdavb · February 8, 2022, 10:21am

Check this:

> cat .secret*/bishop/*.log | grep -v RQ | grep -E '02:024358.* 3150 ... 00' | wc -l
2363

> cat .secret*/bishop/*.log | grep -v RQ | grep -E '02:024358.* 3150 ... 01' | wc -l
0

The above is important, since it tells us that your UFH controller never issues a heat demand for zone 01 (‘Office’), like it does for zone 00 (‘Living room’):

> cat .secret*/bishop/*.log | grep -v RQ | grep -E '02:024358.* 3150 ... 00' | head -1 | python client.py parse
00:10:07.015 || UFC:024358 | CTL:076010 |  I | heat_demand      |  00  || {'zone_idx': '00', 'heat_demand': 0.23}

This suggest your system is misconfigured - although I am not 100% sure.

How many active UFH circuits do you have?

zxdavb · February 8, 2022, 10:31am

@bishop In the meantime, try this in your schema:

        "system": {
            "heating_control": "10:052644"
        },
        "zones": {
            "00": {"devices": ["02:024358"]},
            "01": {"devices": ["02:024358"]}
        }

It should give you a heat demand for zone 00.

bishop · February 8, 2022, 10:46am

My UFH is as follow:

I have:

HCE80-NL Ver. 1.04 underfloor heating controller (installed end of 2014)
HRA80 external Antenna (installed end of 2014)
extension module HCS80 (installed end of 2019)

Concerning a possible mis-configuration it is possible. Everything seems to work well (zones heating as expected, including the office zone 01 you pointed at), but I have noticed one thing which is a bit strange. When a thermostat is off (for exemple battery died or someone switching it off by mistake and me not noticing), after a few hours without packet from this thermostat, evohome starts eating this zone regardless of the state of the heating (even if off for instance). It happened to me during the summer holidays when I was away and the battery died and the one room what heating for a week for nothing. I am a bit astonished by this behaviour of my system and so was wondering if something is wrong somewhere.

I can try re-binding my whole system to see if it helps with my UFH heat demand. If I have the time I’ll try to look at it this week end.

bishop · February 8, 2022, 10:55am

zxdavb:

zxdavb:

I wouldn’t have expected this release to fix the above issue. Watch this space.

@bishop In the meantime, try this in your schema:
        "system": {
            "heating_control": "10:052644"
        },
        "zones": {
            "00": {"devices": ["02:024358"]},
            "01": {"devices": ["02:024358"]}
        }
It should give you a heat demand for zone 00.

ok I’ll try.

Concerning zone 00 I already have heat demand since version 0.18.3 (see my post here ).
It is the only UFH zone I have heat demand for. Maybe it is linked to the fact that this zone is using the evohome controller as sensor ?

zxdavb · February 8, 2022, 10:57am

If so, it would be great to capture all that whilst HA is running - you can send me that packet log.

Likely you’ll have to restart HA with restore_cache: false.

You have a HCS80 - so >5 circuits?

There is a lot of other devices in your logs - do you have a lot of neighbours running Honeywell kit?

zxdavb · February 8, 2022, 11:03am

Contemporaneous packet logs will show what’s going on - but IIRC zones have a default temp, in teh absence of a temperature sensor.

bishop · February 8, 2022, 11:09am

ok will do. Concerning the restore_cache: false, do you meant I should put restore cache at false and reboot HA before starting to rebind everything or after rebiding everthing ?

Yes I have 6 zones with UFH (5 on the HCE80 and 1 on the extension board HCS80). They are zones 00, 01, 07, 08, 09 and 0A on my system.

Concerning my neighbours, I am not sure what they run but I live in a densly built area and there is massive amount of EM noise. I can see various systems (wifi, RFXCOM, evohome,…) but unsure which neighbour is running what. Not sure how to avoid that without covering my house in tin foil

zxdavb · February 8, 2022, 11:33am

No.

Maybe give it a go without disabling restore_cache, but if any funny business, have a low tolerance for that.

OK, my mistake - I didn’t look properly:

> cat .secrets/bishop/2022-02-01i_nocache.log | grep -v RQ | grep -E ' (0005) ' | python client.py -c .secrets/bishop.json -s parse

20:31:08.063 || CTL:076010 | HGI:198151 | RP | system_zones     | 0008 || {'_device_class': '08', 'zone_mask': [0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'zone_type': 'radiator_valve'}
20:31:08.265 || CTL:076010 | HGI:198151 | RP | system_zones     | 0009 || {'_device_class': '09', 'zone_mask': [1, 1, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0], 'zone_type': 'underfloor_heating'}

So, six UFH zones, but still:

> cat .secret*/bishop/*.log | grep -E '02:024358.* 3150 ... 0[1789A]' | wc -l
0
> cat .secret*/bishop/*.log | grep -E '02:024358.* 3150 ... 00' | wc -l
2363

From my understanding, it should be producing a heat demand per zone.

zxdavb · February 8, 2022, 11:36am

Here is someone else’s system:

> cat .secret*/xxx/*.log | grep -v RQ | grep -E '02:.* 3150 ... 0[1-9A-F]' | wc -l
6302

They have:

> cat .secret*/xxx/*.log | grep -v RQ | grep ' 0005 ' | python client.py parse

20:24:55.953 || CTL:073976 | RFG:258720 | RP | system_zones     | 0008 || {'_device_class': '08', 'zone_mask': [0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'zone_type': 'radiator_valve'}
20:25:01.783 || CTL:073976 | RFG:258720 | RP | system_zones     | 0009 || {'_device_class': '09', 'zone_mask': [1, 1, 0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0], 'zone_type': 'underfloor_heating'}

bishop · February 8, 2022, 12:55pm

Update on 0.18.7:

I’ve been running the new version this morning, and the heat demand of my zone 00 (the only UFH zone for which i have actually a heat demand) disappeared around 30 minutes after updating. It has not re-appeared despite rebooting and waiting for 1h.
I have reverted back to 0.18.6 to see if it helps and the heat demand for zone 00 re-appeared straight away. I will run 0.18.6 for a few hours to see if it disappears again and, if it’s stable in 0.18.6 will update again to 0.18.7 to see if I can reproduce the problem.
This heat demand was never missing in 0.18.6 so maybe something has been modified in 0.18.7. Will update you once I’ve finished testing.

zxdavb · February 8, 2022, 1:31pm

These heat demands packets are sent periodically by the UFH controller. evohome_rf has no influence over that - I would just run 0.18.7 for a day before giving up.

Useful tip (for all)

If anyone is ever re-binding a system, for many reasons, it would be convenient / very useful to not have a zone 00 if you can…

The way to do this, generally, is to create a electric heating zone in slot 00, then create all the other zones, then delete that zone or just leave it’s setpoint to 5C (in any case, it will have a heat demand of 0%).

It is always useful to remember that the controller will use the zone_idx with the lowest number when creating a zone.

Have a look at the (contrived) following example:

> cat .secrets/xxx/2022-02-01.log | grep -v RQ | grep -E ' (0005) ' | python client.py -c .secrets/bishop.json -s parse

20:31:08.063 || CTL:123456 | HGI:123456 | RP | system_zones     | 0008 || {'_device_class': '08', 'zone_mask': [0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'zone_type': 'radiator_valve'}
20:31:08.265 || CTL:123456 | HGI:123456 | RP | system_zones     | 0011 || {'_device_class': '11', 'zone_mask': [1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'zone_type': 'electric_heat'}

If you have an older controller (@bishop: I think your is an older version), you can’t create electric zones, so just use a zone_valve zone - just be aware these will generate a heat demand.

@bishop I recommend you do the above.

jonboy · February 8, 2022, 2:30pm

With 0.18.7, UFH demand matches that shown on the controller (for a sample size of 1 so far).

@zxdavb On an unrelated matter, I’ve been looking through your wiki for the ramses protocol

https://github.com/zxdavb/ramses_protocol

I was wondering whether you had considered exposing the RSSI Value (signal strength)? I don’t have the Pi co-located with the Evohome Controller at present but would look to do so if the signal strength values were meaningful (i.e. actually correspond with reality). I think it would be helpful to have insight into the signal strength. (The flip side is that I have never seen any issues with comms between Evohome components, whilst I have had quite a few issues with comms between Z-Wave devices, so perhaps this just isn’t a concern for Evohome.)

zxdavb · February 8, 2022, 3:39pm

Unfortunately, that wiki is horribly out-of-date…

I have been asked re: RSSI before - the idea has merit… It is not high priority for me. One issue is that RSSI for a HGI80 and for a evofw3 dongle don’t correlate.

In a similar fashion, ramses_rf could also track RTT to devices, and the number of re-transmits required before getting a response from a device…

In the meantime, just look at your packet logs, that’s why they’re there!

Robvde · February 8, 2022, 7:43pm

The same thing happened to me a few years ago.
This appears to be a standard setting of the EvoHome.

This can be changed in the System parameters:
1.Press and hold the settings icon on the main screen of the evohome controller for 5 seconds.
2.Press the green tick.
3.Press the SYSTEM Parameter settings icon
4.Press FAIL SAFE icon
5.Select DISABLED

Robvde · February 8, 2022, 7:53pm

I also no heat demand at version 0.18.7 (updated at 08:00) come from 0.18.6. I will wait and see if this comes back and it might be due to my configuration.

P.S. I updated the log file if you want to use it (same link in the PM)

zxdavb · February 8, 2022, 8:00pm

Be aware that raw values of <= 30% are transformed into 0%.

Looking at the code - I think I have confused a raw 0% (zero) with None - a fix will come - in the meantime, just run 0.18.6 if you wish.

bishop · February 9, 2022, 9:23am

Thanks for the information, unfortunatelly I have already put my fail safe to disable a few years back (and it is still in that position) but this did not solve my problem… that’s why I am wondering if everything is really properly set up.

TheMystery · February 16, 2022, 7:47pm

Strange problem, i updated node red where i have a automation for setting the temperature of my fake sensor.
I’m geting this error:
value should be a string for dictionary value @ data[‘entity_id’]"

If i use within ha the development services option and do the same i have the same error
So it cant be a problem of the update of node red.
Someone an idea where it Goes wrong?

zxdavb · February 18, 2022, 12:20pm

I would like to release 0.18.x as stable - please report any bugs now, if you have any.

Then only the latest 0.17.x will be available - I will remove all earlier releases.

… and we can start 0.19.x for the more adventurous among you.

stevieb12345 · February 20, 2022, 12:45pm

Anything nice coming in 0.19?