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

zxdavb · November 15, 2020, 1:23pm

Bleeding edge says it all - no?

In truth - there are so many changes to bleeding edge per unit time, even I have problems keeping up. I just did a git diff between bleeding edge and master and it is a lot, here is a selection:

added get-schedule, get-faults methods to evohome_rf, added execute command to client.py
re-wrote fetcher - exposed as a protocol (a callback), re-wrote packet processor
cleaned up signal/exception handler
cleaned up QoS (packet layer) and RQ/RP processor (message layer)
bugfix parsers, message processors
pulled out a system as separate from a controller (lots of work - still WIP)

zxdavb · November 15, 2020, 1:33pm

@Supermarco333 The device 01:145038 is my controller, I doubt your nanoCUL will reach it from where you are.

So (using the bleeding_edge branch)…

First, you need to eavesdrop your system, and pick up all your device IDs, or least your controller’s device ID (which, if it is battery-powered, is not of much use for probing):

python client.py monitor /dev/ttyUSB0 -o eavesdrop.log

If you wish, you can try an automated probe - this will puzzle each device as they are first seen:

python client.py monitor /dev/ttyUSB0 -p -o probe.log

Once you’ve the device IDs, you can do a deep probe of a device:

python client.py execute /dev/ttyUSB0 --device-id 13:123456 -o deep_probe.log

Let me know how that works for you.

Supermarco333 · November 15, 2020, 4:16pm

All right, sorry for this confusion. So, after running this command: sudo python3.8 client.py monitor /dev/ttyUSB0 and changing the requested temperature, I got this:

client.py: Starting evohome_rf...
2020-11-15T17:09:50.203354 # evofw3 0.4.4 
2020-11-15T17:09:55.658374 ||            | THm:193204 |  I | setpoint         | 010866   || {'other_idx': '01', 'setpoint': 21.5}

client.py: Finished evohome_rf, results:

Schema[gateway] = {"main_controller": null, "orphans": ["12:193204"]}

Params[gateway] = {"devices": {"12:193204": {}}}

Status[gateway] = {"devices": {"12:193204": {"temperature": null, "setpoint": 22.0, "battery_state": null}}}

client.py: Finished evohome_rf.

This gives me the controller ID.

I ran this: sudo python3.8 client.py execute /dev/ttyUSB0 --device-id 12:193204 -o deep_probe.log

I got the following error:

client.py: Starting evohome_rf...
17:12:41.925 Discovery scripts specified, so disabling probes
Traceback (most recent call last):
  File "client.py", line 213, in <module>
    cli()
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.8/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/click/decorators.py", line 33, in new_func
    return f(get_current_context().obj, *args, **kwargs)
  File "client.py", line 104, in execute
    debug_wrapper(**obj, **kwargs)
  File "client.py", line 141, in debug_wrapper
    asyncio.run(main(serial_port, **config))
  File "/usr/local/lib/python3.8/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete
    return future.result()
  File "client.py", line 164, in main
    await task
  File "/home/pi/evohome_rf-bleeding_edge/evohome_rf/__init__.py", line 227, in start
    await asyncio.gather(*self._tasks)
  File "/home/pi/evohome_rf-bleeding_edge/evohome_rf/discovery.py", line 78, in get_device
    device = gwy._get_device(dev_addr, ctl_addr=dev_addr)
  File "/home/pi/evohome_rf-bleeding_edge/evohome_rf/__init__.py", line 263, in _get_device
    self.evo = ctl._evo
AttributeError: 'Thermostat' object has no attribute '_evo'

zxdavb · November 15, 2020, 4:46pm

There was a typo in my previous post (missing -p, I’ve since corrected it), run that fro an hour or so:

python client.py monitor /dev/ttyUSB0 -p -o probe.log

Is your controller battery powered (e.g. a a DTS92A)? If so, it will not respond to any messages sent to it.

The HM80 will probably respond to an RQ, but we won’t know until you run the probe for longer - you’ll need it’s address - it may be picked up with an automated quick probe, or…

You can deep probe the HM80, or whatever else turns up, once you have its address.

Supermarco333 · November 15, 2020, 6:13pm

Ok, I’m now running the command. By the way, do you know the average range of the nanoCUL ? My Raspberry Pi server is maybe a bit far from the HM80.

Yes the controller is battery powered, there’s two batteries inside. If I remember well, the thermostat is a CMS927B1023.

What’s the effect of “-p” ? You send a message to trigger an answer from devices ?

zxdavb · November 15, 2020, 7:14pm

When it sees a device of a type it recognizes, it sends a sequence of RQs to learn more about that device. This strategy doesn’t work for devices that are battery powered (your controller) - such devices don’t listen for packets to conserve their batteries.

It knows what messages to send which device types (e.g. it wont send a 0418 to a BDR91A).

Other than that, it will eavesdrop.

Here is the probe (discovery) code for a relay:

    def _discover(self, discover_flag=DISCOVER_ALL) -> None:
        if discover_flag & DISCOVER_PARAMS:
            for code in ("1100", "3B00"):  # only a heater_relay will respond? to 3B00
                self._send_cmd(code)

        if discover_flag & DISCOVER_STATUS:
            for code in ("0008", "3EF1"):
                self._send_cmd(code)

Gilles_van_den_Hoven · November 22, 2020, 10:59am

I had a question related to Evohome, but (only partially) connected to this topic; can somebody take a look at my other topic (not to spoil this one to much): Usefull upgrading my thermostat to Evohome?

zxdavb · November 22, 2020, 12:58pm

At the risk of being accused of double-posting…

The best place for (HA-agnostic) technical evohome advice is here:
https://www.automatedhome.co.uk/vbulletin/forumdisplay.php?13-Heating-Control

There are very knowledgeable people in that forum (although - for some weird reason - some persist in using Domoticz over HA).

Mr_Q · November 22, 2020, 8:06pm

Hi zxdavb,

Thank you very much for all the work you have done with this integration. I’m really happy with the result! I have an nanoCUL running with home assistant and your CC, everything is smooth.

Before I got this nanoCUL, I was managing my heating with ‘schedy’, an appdaemon app which allows you to manage your schedule easily, allowing integration with things like window (door) sensors etc. It just controls ‘climate’ entities, in my case the ones from the official evhome API integration, and has been working perfectly the last 1.5 years.

Now with your project and the nanoCUL, I would like to ‘swap’ the entities from the official integration with the ones from your custom component. This is easy by changing the config (and or renaming the entities) but the problem I noticed is that changing the temperature using the climate entity that comes with your custom component, results into ‘temporary’ change (from evohome point of view). This means that it will start to follow the controller/unit’s schedule. Is it possible to make temperature changes done via your custom component are also ‘permanent’ to prevent falling back to the schedule of the controller? This is required to keep home assistant in charge instead of the controller. And yes I can remove all schedules in the controller but I guess at least once a day it will still modify the temperature.

I have searched in this topic and on google but couldn’t find an option to get it arranged.

zxdavb · November 22, 2020, 10:23pm

This will require a minor update to evohome_cc - you will then have to use a service call, like evohome.set_temperature

Mr_Q · November 23, 2020, 6:28am

Ah so it is possible!

Does it mean that changing the temperature through the climate entity will not be permanent?

Can you point me a bit into the direction what should be changed? There is a good chance I can change it myself if it is a minor change. Or do you have any plans to integrate it in your official version? Would be really nice!

Gilles_van_den_Hoven · November 23, 2020, 5:17pm

i think this can be done, by looking at how the code in the official API behaves if you don’t pass a duration with the SET_ZONE_OVERRIDE method.

Mr_Q · November 23, 2020, 6:13pm

Yes, the official API supports it and this is available by default using a selection-box when you open the climate entity in Home Assistant. This allows you to change it to ‘temporary’ or ‘permanent’. But we’re here talking about the custom component implementation of zxdavb, which doesn’t have this option/selection box.

This is reverse engineering work done to understand the protocol and I don’t think there’s any official documentation available about it…

So my questions regarding this option in this implemenation are still current

zxdavb · November 23, 2020, 8:46pm

There will be (have always been plans for) three options:
a) permanent change
b) until next scheduled setpoint
c) for a set period of time

Whether it is a simple change, I leave to you - I am sorry, I am just too busy. It will happen soon enough.

I know what’s involved - I wrote both integrations, and I have a sufficient understanding of the RF protocol.

Mr_Q · November 23, 2020, 9:07pm

Just for clarification: my response was to Gilles_van_den_Hoven and not to you.
I fully respect your work and appreciate what you do. I’m sure you know a lot more about all of it than I do, and I never doubted that. I also understand you are really busy. Honestly I was not aware the official cloud API integration was also written by you. Great piece of work!

Your previous response was:

'This will require a minor update to evohome_cc - you will then have to use a service call, like evohome.set_temperature

This, sounded to me that it might be a small adjustment to make it permanent for all the settings changed via entities provided by ‘evohome_cc’. I understand that to include it permanently in your intergration, it requires more work. I’ll look at the ‘evohome_cc’ code myself and see if I can find the location/settings to change.

Happy to see that you already had plans to include the three options!
Can I support your work somehow?

zxdavb · November 23, 2020, 9:33pm

OMG - I am so sorry if I gave the impression I was in any way annoyed - sometimes my tone is a bit brusque, and I apologize for that. My intention was only to supply useful information.

Please don’t stop providing info to other users because I’ve had a bad day…

I wasn’t going to say, but it is probably also worth mentioning that I may be the expert on the RF protocol - I did most of the most recent reverse engineering (although not the core bit, and not schedules, and only a little bit of fault logs, but 0005/000C is all mine).

Of course, many other people contributed, such as the guys who developed evofw3, Perversely, I know very little about how the controller behaves - other people are expert on that…

My main contribution is creating a python protocol stack for the RF protocol - something that others, such as evohome_cc can leverage.

Depends - are you a python dev? I am happy to guide someone through fleshing out evohome_cc.

The other thing I’m looking fro is for someone to send me some logs with a HM80 in it!

Finally, the non-official documention of the protocol is avaialble here: Home · zxdavb/ramses_protocol Wiki · GitHub - you’ll see I wrote almost all of that, but I am way behind

fysmd · November 30, 2020, 5:53pm

Hiya, I have some (I hope not too) silly questions:

I cannot change setpoints using this CC, I have verified the evofw3 version, am I missing something obvs?
Now that zone names are no longer discovered, is there an easy way to associate the various components this adds to each room/zone, they all seem to have different numbers for the sensor / door open etc.
I previously had a demand binary sensor (actuator) for both my HW and CH relay. Are they still around / changed in some way?

Sorry (in advance) if I’m being thick!

zxdavb · December 2, 2020, 1:58pm

Hi @fysmd

IIRC, this should work - I am not using it personally, as my dev/test bed is all over the shop - can others please confirm this is working / not working

My expectation is that zone names are discovered. Again, can others confirm this is true.

OMG - dunno! You need to give me more information. Is it for a device (e.g.13:123456) or a domain (like FC). The former should definitely be there.

Can you check what version of things you are using? Have a look in the logs for a line very similar to this one:

2020-12-02 13:49:34 WARNING (MainThread) [custom_components.evohome_cc] evohome_cc v0.4.4, using evohome_rf v0.4.4 - versions match (this is good)

It is not a warning, although is logged as one - it is an informational message.

fysmd · December 2, 2020, 6:09pm

I’m a bit embarrised: my machine has been down for a while today after decorating and when back up most things are working again - I promise i changed nothing! I dont have my uptime but it’s not very long, I updated hasio OS and more only last week. Maybe I didn’t fully reboot the MACHINE…

I appreciate your patient answer though!

I"m running 4.4.3:

bash-5.0# pip list | grep evoh
evohome-async                    0.3.5.post1
evohome-rf                       0.4.3
bash-5.0# cd custom_components/
bash-5.0# cd evohome_cc/
bash-5.0# git pull
Already up to date.

confirmed in log:

2020-12-02 17:39:41 WARNING (MainThread) [custom_components.evohome_cc] evohome_cc v0.4.3, using evohome_rf v0.4.3 - versions match (this is good)

The binary sensors for the actuators, are working now, first time since november. Only thing different is that my hass machne has been totally restrted!

regarding zone name and thermostat controls. Names are coming bakc since I rebooted:

but when I select the zone:

changes when I try to change the setpoint:

so when I click up or down, the setpoint value goes blank and cant be changed. The value reappears if I close the control and open it again.

nicoske · December 12, 2020, 8:00am

Hello there,

In the end is there an easy way to control the BDR91 relay with the nanoCUL using evohome_rf ? I already have a to temperature probe, I’d like to use HA generic thermostat. Just need to be able to set the relay on/off.