About packets ‘I’, ‘RQ’ or ‘RP’. Looks like it is O.K. Earlier I deleted log file and created new. The first some packets were only ‘I’. Now I see other types…
Do you mean a zone with multiple TRVs? If so, yes I have two of these - seem to be working fine as far as i can tell…
This is how I installed it in the first place. I haven’t used PIP to install on this machine.
I didn’t say you had! I should have explained…
What I’m saying is that evohome-rf may be in your venv, left over from when the manifest.json file used to work.
Let me know how you get on with that and I if you want me to help more, I will probably need another HA log.
It may be worth waiting for the 0.4.3 drop, after the kids have finished soccer practice (there’s a test suite running at home now).
Some update about the packets. Is it possible that for about 5 hours (from 02:00PM to 07:00PM) only ‘I’ packets are sent…? And now it is few minutes past 07:00 and I still do not see other types of packets…
P.S. About what ‘mismatch’ is telling the last part?
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 106, in _read_ready
self._protocol.data_received(data)
File "/config/custom_components/evohome_cc/evohome_rf/packet.py", line 317, in data_received
self._callback(pkt)
File "/config/custom_components/evohome_cc/evohome_rf/__init__.py", line 318, in _process_packet
msg.create_devices() # from pkt header & from msg payload (e.g. 000C)
File "/config/custom_components/evohome_cc/evohome_rf/message.py", line 43, in wrapper
return func(*args, **kwargs)
File "/config/custom_components/evohome_cc/evohome_rf/message.py", line 325, in create_devices
[
File "/config/custom_components/evohome_cc/evohome_rf/message.py", line 326, in <listcomp>
self._gwy.get_device(
File "/config/custom_components/evohome_cc/evohome_rf/__init__.py", line 367, in get_device
device.zone = ctl.get_zone(domain_id)
File "/config/custom_components/evohome_cc/evohome_rf/devices.py", line 532, in zone
raise CorruptStateError(
custom_components.evohome_cc.evohome_rf.exceptions.CorruptStateError: The system state is inconsistent: Device 17:000376 ( 17) has a mismatched parent zone: old=01:023389_04 (RAD), new=01:023389_03 (None) (try restarting the client library)
@dariusz , I got not idea what a 17: is - what is it? It’s not a mixing valve is it?
This is what you get when you do something like moving a TRV from one zone to another - the code just can’t handle it.
I assume you have not moved the 17: device from one zone to another?
I suggest you restart everything & see if it was a one off (it probably isn’t). Otherwise, please PM me a copy of the packet log. I would be very interested to see it.
Yes - a whole bunch of RQ packets at the start, then none more.
The whole thing is built around eavesdropping (listening in on) the RF packets between the controller and it’s devices (e.g. thermostats, TRVs, relays).
For various reasons, it send a bunch of RQ packets on startup, but eavesdrops after that - this will change in future (e.g. periodic bouts of RQ s, say every hour or so, or event-driven).
The only device I’m thinking is maybe ‘floor heating controller’ - HCE60.
No - I’m not moving it…
This device is controlled by 2 HCU30 ‘set-point adjusters’:
Out of heating operations - there is also extension module HXxx (10 or 85 - do not remember exactly). To integrate ‘Hometronic’ system with home security system.
About moving - the 2 HCU30 are not fixed to any wall, just standing on table or becnch… And it is possible that they are moved…
Should I do this inside the homeassistant container? I don’t have pip installed on the host machine and it “breaks the warranty” on hass supervised.
Strange thing… Suddenly stop receiving packets. I have not touched my configurations since yesterday evening…
I think someone earlier reported such problem.
What is solution for that…?
Dunno - I suspect (if issue is my code) an problem with a lock, or an await - I will have to keep an eye out fro it - any info is appreciated!
OK, version 0.4.3 just pushed.
Hours+ of work, lots of improvements (many of these are subtle), some are work-arounds that will need sorting out later on…
There is a New feature: a new sensor, as promised before - see who can spot it first!
There is a lot less logging now - so anything related to evohome_cc that is visible in HA’s web UI is worth knowing. For example, you want to see:
evohome_cc v0.4.3, using evohome_rf v0.4.3 - versions match (this is good)
@scstraus please upgrade (there are a lot of bugs addressed), and check the above is true, then ask for help if things dont work
@dariusz please run this and send me your packet log - it addresses some specific issues for you.
Thank you for the update… Just installed.
The only new beast (in my case) I see is:
But with red ‘!’. Is that O.K. ?
Also I’m wondering why ‘Hall’ is appearing as ‘unavailable’ but on other card is showing the temp.
That was also before the update.
@dariusz I have absolutely no idea if the new fault log functionality will work with hometronics - looks like not. For the rest of it - I’d like a new packet log - just from startup, until 5-10 minutes later.
Log sent to ‘pm’…
I am aware that some sensors are not being updated regularly - this is the next issue I’ll look at. A lot of the work this week was preparing for that work.
You will notice that zone temps appear a little faster than before - and sensor show as unavailable more reliably (e.g. a sensor is unavailable rather that being incorrectly labelled as false or 0).
Hi David,
Installed the new one. I get the “versions match” message in the log and 2 sensors, both unavailable:
Nothing in packet.log. It looks like log messages are mostly the same as last ones I sent you but I can send new ones if you like. Is it just not seeing the HGI-80 or is it something else?
@scstraus I added that version match message just for situations like yours.
The two sensors will appear, even if no packets are received.
As you say, the issue is why are no packets received?
From CLI, try: cat /ttyUSB0 (or whatever yours is)
Okay, so it looks like my migration from Ubuntu to Debian to meet the new supervised installation requirements of ADR-0014 have left me with a distro that doesn’t have the ability to deal with the HGI-80’s firmware. I get the following in dmesg:
[ 3.467383] usbcore: registered new interface driver ti_usb_3410_5052
[ 3.467389] usbserial: USB Serial support registered for TI USB 3410 1 port adapter
[ 3.467394] usbserial: USB Serial support registered for TI USB 5052 2 port adapter
[ 3.467404] ti_usb_3410_5052 1-3:1.0: TI USB 3410 1 port adapter converter detected
[ 3.473050] usb 1-3: firmware: failed to load ti_usb-v10ac-p0102.fw (-2)
[ 3.473142] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 3.473243] usb 1-3: Direct firmware load for ti_usb-v10ac-p0102.fw failed with error -2
[ 3.473250] usb 1-3: firmware: failed to load ti_3410.fw (-2)
[ 3.473339] usb 1-3: Direct firmware load for ti_3410.fw failed with error -2
[ 3.473347] ti_usb_3410_5052: probe of 1-3:1.0 failed with error -2
I found the thread that you had mentioned earlier regarding this problem on hassOS here but I’m not sure how to fix it on Debian. On Ubuntu it “just worked” :-(.
Do I have to recompile my kernel…? It’s been 20 years since I’ve done one.