@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. 
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)…
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.
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.
I see the firmware for the hgi80 (TI 3410/5052) is now part of the home assistant operating system in 5.10 released today.
I presume this will now allow usage of the hgi80 with home assistant?
1 Like
@zxdavb hi, i use your project for a while now, but sometimes its looks like that he lost connection. (I cant control/read the temperature) and sometimes he sends the temperature of 25 degrees to the radiator valve. But is has been 20 degrees for example.
This error is also in the HA log file:
Source: custom_components/evohome_cc/evohome_rf/command.py:201
First occurred: 15:24:40 (3 occurrences)
Last logged: 15:24:42
Error doing job: Exception in callback SerialTransport._read_ready()
Traceback (most recent call last):
File "/usr/local/lib/python3.8/asyncio/events.py", line 81, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.8/site-packages/serial_asyncio/__init__.py", line 119, in _read_ready
self._protocol.data_received(data)
File "/config/custom_components/evohome_cc/evohome_rf/packet.py", line 315, in data_received
self._callback(pkt)
File "/config/custom_components/evohome_cc/evohome_rf/__init__.py", line 304, in _process_packet
proc_callback(msg)
File "/config/custom_components/evohome_cc/evohome_rf/__init__.py", line 291, in proc_callback
callback["func"](msg, *callback["args"], **callback["kwargs"])
File "/config/custom_components/evohome_cc/evohome_rf/command.py", line 201, in proc_log_entry
log_idx = int(log.pop("log_idx"))
ValueError: invalid literal for int() with base 10: '0A'
Hi, thanks for your help. The good news is that this bug has been squashed:
log_idx = int(log.pop("log_idx"), 16)
… the bad news is that you’ll have to wait for an update.
In the meantime, simply clear your fault log on the controller to keep the number of log entries < 10.