Hi,
Yes I have seen that, but that’s based on internet API and does not support custom thermostats.
I have to inject custom thermostat into Evohome with the HGI80 on the local network. None of the house appliances are allowed to connect to the internet ever so using API’s to clouds is a big no no.
Yeah, so I don’t think the HGI-80 integration is quite where you want it yet. For now it’s just for watching the TRV temps and zones. It can’t set the thermostat. @zxdavb is doing a great job of adding evohome functionality and he expects to have close to the full functionality supported by HGI-80 by next winter (he gives lots of details in the thread above if you want more), but for now the Domoticz integration is ahead of hass on this point.
If you decided you weren’t opposed to the cloud API for now, you could combine your external temperature sensors and the controls for the individual zones into a single climate entity using this I think.
Can’t help you on the firmware issue, it fired right up on my Ubuntu mac mini running hass.io.
evohome_cc, the HA integration that talks to evohome_rf (which itself is the library that picks up the RF packets) does not yet support custom thermostats in the way that Domoticz does.
In fact, evohome_cc is read-only - all it does at present is eavesdrop.
Much functionality is forthcoming (we could, for example, replace the controller altogether), but that will be for next Winter.
That’s alright, I already noticed this integration was quite new and just starting off. Just the fact that this is now being developed for Home Assistant is awesome! I can wait a bit more before finally adding it all to HA.
About the HGI80 firmware part. This is a problem that’s been around for years and nobody seems to post their solutions anywhere, I want to urge anyone to please please post the fix or supply the firmware file somewhere. You will help a lot of other people! For me it happens on a Raspberry Pi 3B+.
HGI80 usually just needs ti_usb serial driver, assuming debian:
apt-get install linux-firmware
That package should install any known firmwares - Firmware - Debian Wiki
Does that help?
Running raspbian on a Pi, unfortunately that command doesn’t work.
Also, the ti_usb_3410 driver was missing at first, fixed that by downloading it and adding to the firmware location.
Then one error remained which is the ti_usb-v10ac-p0102.fw and is nowhere to be found.
The 3410 is loading fine but is only half of the needed firmware.
Strange, I’ve got several HGI80 and they all only need the 3410 file.
How old is yours? Perhaps a newer model was released that has changed?
Or perhaps something has changed in recent debian builds that’s incorrectly saying it needs that other file.
You could try going to an older build, e.g. Jessie or Stretch and seeing if it still does the same thing.
Thanks for the help, meanwhile I’ve found the culprit!
Excuse the off-topic but I think a lot of people with a Pi will run into this problem as already many have without solutions showing on the internet. If you have a better fix please tell me I’ll update this.
TL:DR: Need correct Texas Instruments firmware, I extracted it from OpenSuSE RPM and everything worked after reboot. “Direct firmware load for ti_usb-v10ac-p0102.fw failed with error -2” error can be ignored.
The problem is a mix of multiple things which threw me off completely.
Problem 1: Missing the ti_usb_3410.fw firmware/driver.
Problem 2: Missing the ti_usb-v10ac-p0102.fw firmware/driver.
Problem 3: Not mounting to /dev/ttyUSBx.
With Problem 1, I thought I solved it by downloading this exact firmware somewhere from the net. Although dmesg did show it was loading the driver and seems to recognize the HGI80, it didn’t bind to /dev/ttyUSB0 for me(Problem 3). At the same time I was getting an error about still missing the ti_usb-v10ac-p0102.fw (Problem 2).
Logically I assumed that Problem 1 was fixed and Problem 2 was causing Problem 3.
After building a custom kernel with the TI USB 3410 driver explicitly in there, I still ran into Problem 2 and Problem 3. However Problem 2 firmware is nowhere to be found on the internet, even Texas Instruments don’t seem to hand it out, I thought it would be unlikely to be an actual problem as surely someone would have a solution.
Back to the drawing board, I assumed my Problem 1 fix was actually not fixed and I extracted ti_3410.fw and ti_5052.fw from an OpenSuSE RPM package and put those in /lib/firmware.
After a reboot, behold, it activated and bound to /dev/ttyUSB0, HGI80 fully functional!
dmesg still complains about Problem 2, but it appears this isn’t a problem at all.
How to get the files from OpenSuSE:
Go to: http://rpmfind.net/linux/rpm2html/search.php?query=firmware(ti_3410.fw) and find the latest rpm package.
On the Pi:
sudo apt-get install rpm2cpio
sudo wget http://rpmfind.net/linux/opensuse/distribution/leap/15.2/repo/oss/noarch/kernel-firmware-20200107-lp152.1.1.noarch.rpm
sudo rpm2cpio kernel-firmware-20200107-lp152.1.1.noarch.rpm | cpio -vid
sudo cp lib/firmware/ti_* /lib/firmware/
Result after reboot:
usb 1-1.1.2: TI USB 3410 1 port adapter converter now attached to ttyUSB0
Wow a lot harder than on Ubuntu server
Exactly, still not sure why “apt-get install linux-firmware” didn’t work - it’s explicit purpose is to install all of the firmware files on the url that I linked to previously - Firmware - Debian Wiki - both ti_3410.fw and ti_5052.fw are listed there.
Seems to work for me on all my RPi running various versions or Raspbian!
Hello,
The project continues to progress - I am now at the stage of trying create / maintain a state database, and I need help: could as many people as possible send me some packet logs to test against
I am particularly interested in hearing from people with unusual configurations - OTB, DHW, UFH, v1 controller, Hometronics, DTS92/92es, External weather sensors, etc…
I need:
This will be separate from HA, as this branch of evohome_rf (radio frequency) is not compatible with the HA integration, evohome_cc (custom component)
If you are using a nanoCUL instead of a HGI80, please first upgrade to the latest firmware, which is much more reliable now
You will need to do something like:
git clone https://github.com/zxdavb/evohome_rf
cd evohome_rf
git checkout fix_state_data
python -m venv venv
source bin/activate
pip install --upgrade pip
pip install -r requirements.txt
pip install -r requirements-dev.txt
Then you can collect the logs (COMx: works for windows):
python client.py -r monitor /dev/ttyUSB -o packets.log
If you do have a nanoCUL running the latest evofw3, please instead use:
python client.py -r monitor /dev/ttyUSB1 -o packets.log -T '!T01'
Please PM me the log file (I may want to ask you some details about your configuration after I parse it, but this is not required).
You can expect to see something like this on STDOUT:
(venv) ➜ evohome git:(fix_state_data) python client.py -r monitor /dev/ttyUSB1
18:58:47.872 Starting evohome_rf...
18:58:51.237 || STA:064023 | CTL:145038 | RQ | zone_config | 03 || {'parent_zone_idx': '03'}
18:58:51.253 || CTL:145038 | STA:064023 | RP | zone_config | 03100... || {'zone_idx': '03', 'min_temp': 5.5, 'max_temp': 29.5, 'local_override': True, 'openwindow_function': True, 'multi_room_mode': ...
18:58:51.316 || STA:064023 | CTL:145038 | RQ | setpoint | 03 || {'parent_zone_idx': '03'}
18:58:51.332 || CTL:145038 | STA:064023 | RP | setpoint | 030226 || {'zone_idx': '03', 'setpoint': 5.5}
18:59:36.740 || GWY:082155 | GWY:082155 | I | sync_cycle | 000537 || {'remaining_seconds': 133.5, 'next_sync': '19:01:50'}
18:59:40.678 || CTL:145038 | CTL:145038 | I | sync_cycle | FF073F || {'remaining_seconds': 185.5, 'next_sync': '19:02:46'}
18:59:40.710 || CTL:145038 | CTL:145038 | I | setpoint | 0001F... || [{'zone_idx': '00', 'setpoint': 5.0}, {'zone_idx': '01', 'setpoint': 5.0}, {'zone_idx': '02', 'setpoint': 5.5}, {'zone_idx':...
18:59:40.731 || CTL:145038 | CTL:145038 | I | temperature | 0008A... || [{'temperature': 22.22, 'zone_idx': '00'}, {'temperature': None, 'zone_idx': '01'}, {'temperature': 24.57, 'zone_idx': '02'},...
Can we do this alongside the existing Hgi-80 integration or do we need to uninstall or stop that first?
You need to stop the HA integration (evohome_cc) as the old version wont share \dev\ttyUSBx (the new version can share).
BTW, you can run this version against your old logs, for example:
cat old_packets.log | grep -v '18:' | tail | python client.py parse
Or even:
cat *.log | python client.py parse
When you do the above, it doesn’t use (need access to) a serial device - so the parser (but not the monitor) can be run alongside evohome_cc.
If anyone is curious, this version of evohome_rf is > 2x (~4300 lines) the size of the old version (~2000 lines).
Is that enough to give you what you need? It sounds like the easiest way to me. I wouldn’t need to run the monitor in that case, would I?
@scstraus I probably don’t need one from you - you’ve provided a high-quality sample before.
Actually, what I may do is just re-integrate the existing library back into HA first…
Question: Do you see zones in HA with evohome_rf/evohome_cc?
Kind of. I have climate.rf_zone_0 though 9, though I have 12 zones defined in my thermostat. Also some of the sensors for the TRV’s report their parent zone as null. Others correctly report it.
Does anyone here have UFH (i.e. a HCE80 or similar) that is not in the first zone? I could use a packet log.
Hi @zxdavb
I’ve just registered to answer your question.
I’ve been following your work and let me thank you very much for that, it’s really impressive.
I’m planning to buy the nanocul to be able to get all the information in homeassistant, the HGI80 is not easy to find at this point as it was discontinued, apparently.
My setup will be a Raspberry Pi 3 + nanocul running homeassistant, and my honeywell setup (fully wireless) for underfloor heating is the following:
1 EvoHome controller - which controls the whole setup and one zone
2 HCE80+HRA80 units with 3 zones each and each with a round wireless thermometer
2 BDR91, one for the main heating line and other for another zone.
Will this be an interesting setup for you to get packet logs ?
I’m a developer myself, so I can also try to help either by testing and/or getting hands on if needed.
Kind regards,
Yes! Let me know when you have the hardware - the nanoCUL is currently unable to send packets, but that will be changing soon, the hardware guys tell me.
I am currently working on probing rather than eavesdropping - this means sending packets to devices to learn about their abilities and configuration. These are RQ packets rather than W (write) packets, so nothing is changed. For example:
20:32:58.273 042 RQ --- 18:013393 13:237335 --:------ 1FC9 001 00
20:32:58.297 066 RP --- 13:237335 18:013393 --:------ 1FC9 012 003EF0379F17003B00379F17
20:43:02.927 039 RQ --- 18:013393 13:106039 --:------ 1FC9 001 00
20:43:02.948 051 RP --- 13:106039 18:013393 --:------ 1FC9 006 003EF0359E37
The first BDR91 (which has a 3B00 in the payload) is the TPI relay (it turns the boiler on/off), the 2nd is not.
What I’m really wanting is a system with UFH which is not in zone 1 (what I call zone 00), but anyone who is able to set up my code so I can probe their UFH (or OTB) would be grand!
Good. There is an known issue with HA on Rasp Pi & HGI80s wont work with it currently (no way to load the required USB driver).
Make sure you get an 868Mhz version & not a 433MHz version marked at 868.