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

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.

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! :wink:

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.

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.

@nicoske This is a planned feature. Sorry, I’m in the middle of a re-write of the underlying library, and I am short of time.

Hello @zxdavb
First of all Merry Christmas. :slight_smile:
I found some time to finally scan the ID of the HM80. I ran sudo python3 client.py monitor /dev/ttyUSB0 -d -o probe.log on the last bleeding_edge.
Here is the result: https://pastebin.com/gisSWm9e
If I properly understood, the ID is 12:193204.

What data do you need now ?

Hello @Supermarco333, Thanks for this.

Sadly, the 12: device is a programmer, or a thermostat, not a HM80. I see your logs ran for 10 minutes or so? You’ll have to run it for longer, to pick it up.

There is a new version of evohome_rf, so pull the latest commit, and use the bleeding edge branch.
You can start with:

python -O client.py -r listen /dev/ttyUSB0 -o packet.log

…and just run that for a few hours (say 30-120 mins). You can then end evohome_rf via a `Ctrl-C’, and you might see something like:

client.py: Finished evohome_rf, results:

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

...

Then just look among the orphans for a likely HM80 (e.g. 08:123456 - it may not be an 08:)

  • if you do not find a device that is likely to be a HM80, just re-run the above command, and it will append to the log.

  • if you do find a likely device, say, then execute:

python -O client.py -rr execute /dev/ttyUSB0 -sf 08:123456 -o scan_full.log

The -sf is a full scan (aka --scan-full) - it takes approx 60 seconds to do against a controller, but will likely take a few minutes longer for a HM80.

When the scan is finished, you’ll have to end evohome_rf via a `Ctrl-C’.

Then just send me both logs.

There is no immediate need for this, but if anyone is feeling very adventurous, they can also try:

python -O client.py -rr execute /dev/ttyUSB0 -sh 02:123456 -o scan_hard.log

I’d be particularly interested in the results of hard scans of UFH controllers, which start 02: - this scan will take hours (it used to take 24h, but evohome_rf is much faster now.

Of course, none of the above should cause any issues with your system (but if they do, turning the controller off/on will be sufficient)…

Hello,

I’ve been running the program the whole day and even the whole night. I only got garbage.
Here is the packet.log: https://pastebin.com/8ijZKxeW

Any idea ?

Sure:

2020-12-27T02:01:27.215597 098 RQ --- --:------ --:------ --:------ ???? ??? * Invalid Manchester Code 

The 098 tells me the signal is very weak. The paucity of log entries confirms the diagnosis: the signal from the heating system and the nanoCUL/evofw3 dongle is too weak - it is attenuated either by (say) brick walls, or distance.

Optimally, you want something in the 40s-60s (IIRC, the evofw3 RSSI is similar to that from a HGI80)…

Ok, it’s a bit weird though. Here’s the setup. The Pi is only 2m far from the HM80.

I can see the HM80 - where is the thermostat? What model is the thermostat?

Maybe the poor reception is only for the thermostat, and the HM80 is not being picked up at all - I dunno: I’ve never had anyone test a HM80 before - sometimes there can be an issue with timings.

Try forcing the issue by making the HM80 ‘speak’ somehow?

Am I right that you sat the nanoCUL next to a thermostat before, but is now moved into that space?

You’re absolutely right. The NanoCUL was initially next to the thermostat in the kitchen (model CMS927B1023). I moved the Pi next to the HM80. From that position, I got some packets from 12:193204 which is the thermostat according to what you previously said. Yet, the thermostat is a bit far so the signal isn’t probably very good for the NanoCUL which could lead to these bad packets.

Should I try to unplug/plug the HM80 ?

Lets switch to PM will send you a msg.

Hello @zxdavb and Merry Christmas.

I’ve had a Hometronic system for more than 10 years and always wanted to be able to be able to view/control it from outside so I was very happy to find your project and got myself a nanoCUL.

After I’ve set everything up I noticed that I can only see heat demand sensor from a couple of my HR80s out of 17 I have.

Looking at the packet logs it seems that most of my HR80 TRVs have device ID 00 and only 2 have ID 04. evohome_rf code doesn’t seems to have device ID 00 defined in the const.py so I went and created a little patch to make them work. It all seems to be working fine and I’d like to contribute it to your code (master).

Let me know what’s the best way to do this (I’m assuming PR but can do a patch as well) and I’m happy to integrate it to bleeding_edge if necessary.

Thanks for your great work.

2 Likes

I have never seen 00: devices before!

Re: PR - sure… How much did you need you change? In the first instance, you would best send me a 24h packet log (also, I’d like to see if these 00: devices behave differently).

Don’t port to bleeding_edge yet - we may end up duplicating effort.

Hometronics support is offered, but is a moving feast, as you’d imaging. If you can, the two scans from post #570 would also be useful.

Didn’t have to change much, see PR#11. Let me know where to put the logs. I suspect they may have started with TRVs as 00: before moving to 04: I have devices from 00:000392 to 00:000951 so pretty low id numbers.

Pretty good - well done!

I have homeassistant on a new Ubuntu instance
I had evohome_cc and evohome_rf running on my old pi but can not get ik working on my new machine.
I have installed the latest version of evohome_cc and evohome_rf in the custom_components folder as described in the wiki.
In my configuration.yaml I added:

evohome_cc:
  scan_interval: 60
  serial_port: /dev/ttyUSB1
#  serial_port: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port03410-if00-port0
  packet_log: /home/homeassistant/evohome/packets.log
  schema:
    controller: 01:051477

When I check the config I get:
Component error: evohome_cc - Integration ‘evohome_cc’ not found.

In the log it tells me I am missing serial_asyncio
Log file:

2020-12-30 14:46:17 ERROR (MainThread) [homeassistant.loader] Error loading custom_components.evohome_cc. Make sure all dependencies are installed
Traceback (most recent call last):
  File "/home/homeassistant/.homeassistant/custom_components/evohome_cc/__init__.py", line 13, in <module>
    from . import evohome_rf
  File "/home/homeassistant/.homeassistant/custom_components/evohome_cc/evohome_rf/__init__.py", line 19, in <module>
    from serial_asyncio import SerialTransport
ModuleNotFoundError: No module named 'serial_asyncio'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.8/site-packages/homeassistant/loader.py", line 541, in _load_file
    module = importlib.import_module(path)
  File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 783, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/home/homeassistant/.homeassistant/custom_components/evohome_cc/__init__.py", line 15, in <module>
    import evohome_rf
ModuleNotFoundError: No module named 'evohome_rf'

What do I have to do to get serial_asyncio available?

Something like?

pip install serial_asyncio

I tried that but ran into an not authorized exception.
After changing the owner of the package location to the right user, installing the package, and changing the owner again I did get it working.
I saw setting the temperature is also working. Very nice David.:+1::+1:

There is a lot of outstanding functionality - is just taking ages…

Currently, the main work is converting evohome_rf to have a QoS & act like TCP rather than UDP… Nearly there.