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
1 Like
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:
- 24h of packet logs using the fix_state_data branch of evohome_rf
- with no configuration changes (no adding / deleting zones, no adding / deleting devices); however, changing setpoints & modes is encouraged
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.
Here is what evohome_rf has learnt about the controller after approx 10 mins. You can see teh fault log (limited to first 3 entries); it hasn’t picked up the DHW sensor (yet), but it has picked up the TPI relay:
"01:145038": {
"description": "Evo Color",
"device_type": "CTL",
"dhw_sensor": null,
"fault_log": [
{
"log_idx": "00",
"timestamp": "20-05-14 16:14:37",
"fault_state": "Fault",
"fault_type": "BatteryLow",
"zone_idx": "03",
"device_class": "Actuator",
"device_id": "04:056057"
},
{
"log_idx": "01",
"timestamp": "20-05-14 05:43:24",
"fault_state": "Restore",
"fault_type": "BatteryLow",
"zone_idx": "00",
"device_class": "Controller?",
"device_id": "00:000001"
},
{
"log_idx": "02",
"timestamp": "20-05-14 00:42:05",
"fault_state": "Fault",
"fault_type": "BatteryLow",
"zone_idx": "00",
"device_class": "Controller?",
"device_id": "00:000001"
}
],
"language": "en",
"last_pkt": "2020-05-18T12:06:08.742970",
"parent_000c": null,
"parent_zone": "FF",
"pkt_1fc9": [
{
"zone_idx": "00",
"command": "device_info",
"device_id": "01:145038"
},
{
"zone_idx": "00",
"command": "bind_device",
"device_id": "01:145038"
}
],
"pkt_codes": [
"1F09", "1FC9", "10E0", "0002", "0418", "2E04", "000A", "12B0", "30C9",
"2349", "000C", "0004", "1100", "0005", "1F41", "1260", "0100", "10A0",
"313F", "0016", "0008", "2309", "3B00"
],
"system_mode": {
"mode": "Eco",
"until": null
},
"tpi_relay": "13:237335"
},
Here’s what it picks up for a zone:
"01": {
"actuators": ["04:056053", "04:056059"],
"configuration": {
"local_override": true,
"multi_room_mode": false,
"openwindow_function": true,
"max_temp": 35.0,
"min_temp": 5.0
},
"devices": ["04:056059", "04:056053", "34:092243"],
"heat_demand": 0,
"last_pkt": "2020-05-18T12:02:31.116455",
"name": "Front Room",
"pkt_codes": ["000A", "12B0", "30C9", "2349", "000C", "2309", "3150" ],
"sensor": "34:092243",
"setpoint_status": {
"setpoint": 5.0,
"mode": "FollowSchedule",
"until": null
},
"temperature": 19.14,
"window_open": false,
"zone_type": "Radiator Valve"
},
… and, an exampl of a non-TRV device (a BDR91 in this case):
"13:237335": {
"actuator_enabled": null,
"actuator_state": null,
"description": null,
"device_type": "TPI",
"is_tpi": true,
"last_pkt": "2020-05-18T13:13:04.927614",
"parent_000c": null,
"parent_zone": null,
"pkt_1fc9": [
{"command": "actuator_enabled", "device_id": "13:237335"},
{"command": "sync_tpi","device_id": "13:237335"}
],
"pkt_codes": ["3EF0", "1FC9", "0016", "3B00"],
"rf_signal": {"rf_strength": 5, "rf_value": 24}
},
@Captain I think your UFH is in zone 1 (what I call zone “00”), but would you be willing to run the latest code for me to test my probe/discovery system? You’d have to download a special branch of my latest code & run it outside of HA - it would only take 5 minutes.
That’s great.
I’ve just ordered the nano 868Mhz, it should be here by the end of the week, sending packets is not that important to me, so I can get the same functionality I need from HGI80 (eavesdropping), for a fraction of the price, if it will be able to send packets in the future, it’s even better.
Meanwhile I’m setting up HA and will download the code so I have everything ready.
As soon as I get my hands on it, I can do all the testing you’ll need and help as much as I can.
Thanks.