Yes sorry I should have been more explicit. All is fine with 0.30.2 for me but the flame_active sensor is unavailable (it was available in 0.22 version I was using before)
I did not understand their message in the same way. My understanding is that they upgraded to 0.30.2 and since then lost the flame_active sensor
I’m not using the use_native_ot in my configuration file. I didn’t know this parameter existed. If you want I can try tonight to see if it helps.
I have identified, and fixed this bug. The fix will be in next release.
Thanks David, I’ll test it out when the release comes out.
In my case I had problems on 0.21.40 so I upgraded to 0.30.2. After that I also had some problems, but after restarting without restoring the cache everything recovered, except the flame_active sensor.
So I except that after upgrading to the new release everything will be OK!
Version 0.30.4 has been released.
Just upgraded to 0.30.4, everything looks fine with the sensors, I got the flame active back:
I only got a new warning, or I just can’t recall if I saw this one before:
/dev/ttyUSB1: the gateway type is not determinable, will assume evofw3, TIP: specify the serial port by-id (i.e. /dev/serial/by-id/usb-...)
I run HA in docker, the USB stick is connected to the docker container via the /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_CX7UU2GJ-if00-port0 device and it’s on /dev/ttyUSB1. Can I do anything about this warning, or I can let it go until everything works fine?
This is new to 0.30.4. It is advising you to use /dev/serial/by-id/usb-... instead of /dev/ttyUSB1, so it knows you have an evofw3-compatible device, rather than a HGI80.
The distinction is important to the internal workings of ramses_rf…
The best thing is to do what is asks (the TIP):
ramses_cc:
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_CX7UU2GJ-if00-port0
… but you can ignore the message otherwise.
I also confirm that upgrading to 0.30.4 brings back the flame active sensor. All the rest also seems to work fine. Thanks a lot.
Thanks David! I’m not sure if I can redirect the hosts /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_CX7UU2GJ-if00-port0 into the docker container to the same name, but I’ll try it.
I’m seeing a new issue on 0.30.4 which didn’t happen on 0.30.2. An hour or more after a restart, the friendly names of all zones disappear and revert to “ramses cc 01 …”.
I’ve tried restore_cache=false → restart → restore_cache=true → restart. A few minutes after the final restart all zone names populate correctly, but disappear again a few hours later.
The same thing happens on a standard restart (restore_cache=true): zone names appear after a few minutes, then disappear later.
This is on a standard EvoHome setup. Auto-discovered schema, just with boiler relay and display unit set as one zone temperature sensor, enable_eavesdrop=false
Thanks again for all of this. It’s so great to have this 100% local control.
One other comment, not specific to 0.30.x: would it be possible to cache/restore min_temp and max_temp for zones?
After a restart, even with restore_cache=true, thermostat GUI controls are locked out as min/max are null in the state of each zone entity. It generally takes a few minutes to an hour before they re-populate.
It should do this already - so the fact it isn’t, is a bug.
Has anyone else noticed this issue?
Either I am blind (highly possible) or there is still not a confirmed process to bind a 4 way remote to my Nuaire? I have tried reading extensivly the 3700+ comments to try and find the answer.
I can see the RF code for my using and my remote will send commands. but I assume binding process still is not working?
Ok I’m completely stuck here (and have been for days). I have a combined evohome system with UFH on ground level and radiator valves on the first floor. For the UFH I have a HCE80 and the radiator valves are HR92. They are controlled by a ATC928G3000 communicating with a R8810 which is connected to the central heating. I flashed a Nano Cul and configured the configuration.yaml file. All the divices show up. I’m just having a hard time with the Heat_demand of the UFH. The heat_demand entity is showing but it is always unavailable. Only the heat_demand for the living room is showing which is part of the UFH. Can someone please point me in the right direction? here’s my configuration so far:
ramses_cc:
serial_port: /dev/ttyUSB2
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true
max_zones: 9
restore_cache: true
packet_log:
file_name: /config/ramses_cc.log
rotate_backups: 7
01:079786:
system:
appliance_control: 10:073268
zones:
"00": {sensor: 01:079786}
"01": {sensor: 34:250925} # hal
"02": {sensor: 34:006961} # keuken
"03": {sensor: 34:006955} # kantoor
"04": {sensor: 34:250929} # washok
"08": {sensor: 04:022508} # badkamer
orphans_hvac: [32:017542]
known_list:
01:079786: # Controller
02:032611: # HCE80
04:022506: # Thermostatic radiator valve (sk peter)
04:022508: # Thermostatic radiator valve (badkamer)
04:022510: # Thermostatic radiator valve (slaapkamer bas&bien)
04:022512: # Thermostatic radiator valve (sk emma)
10:073268: # OpenTherm bridge (R8810)
18:262143: # Honeywell Gateway Interface (HGI80, HGS80)
32:017542:
34:006955: # Honeywell Round thermostat (kantoor)
34:006961: # Honeywell Round thermostat (keuken)
34:250925: # Honeywell Round thermostat (hal)
34:250929: # Honeywell Round thermostat (washok)
logger:
default: warn
logs:
homeassistant.core: debug
# custom_components.evohome_cc: info
custom_components.evohome_cc.sensor: info
ramses_rf.message: info
ramses_rf.protocol.message: info
ramses_rf.protocol.transport: debug
Just upgraded to 0.30.4 on ha 2023.12.0. Zone names where missing and current temperature was not shown on climate display. After second reboot with enable eavesdrop it all works! Great work.
Welcome!
Don’t use enable_eavesdrop: true unless you know exactly how it works, or someone like me has advised you to.
Having it enabled can cause grief.
It is intended for very specific use-cases, and enabling it was unlikely to be the solution to your missing data (temps are ‘eavesdropped’ in all cases and names are rarely eavesdroppable).
It is only the schema that is eavesdropped, or not.
When I developed ramses_rf, I did not have an UFC (HCE80/HCC80) to test/dev against.
I now have an UFC, but have not had the time to put it on a test bed - and wont now, until at least Summer.
Thus, with UFH, you get what you get.
People can help by sending me 72h packet logs, but this is still a lower priority than, say, fixing binding of HVAC remotes.
My Ramses integration stopped recording and logging last night out of the blue. No changes were made to the config or changes in home assistant for that matter.
I’ve spent the day to get it up an running again. The logging works from a restart but after the first 1 or 2 minutes no recordings are done. In the logs there is also no mentioning of any failure. Have tried to restart with restore_schema and restore_states true/false.
What would be the next step to explore? It has worked perfectly for 3 months but I can’t get it to work anymore.
Anyone has a hint?
These are the logs. After startup it does the initial setup and then it just stops recording. Could it be the antenna not ‘seeing’ anything - so the hardware?
2023-12-09T19:09:36.225204 # ramses_rf 0.21.40
2023-12-09T19:09:36.302281 ... RP --- 32:143323 18:072965 --:------ 22F1 003 000407 # 22F1|RP|32:143323
2023-12-09T19:09:36.366405 ... RP --- 32:143323 18:072965 --:------ 2210 042 00FF00FFFFFF0000000000FFFFFFFFFF00FFFFFF0000000000FFFFFFFFFFFFFFFF000000000000000800 # 2210|RP|32:143323
2023-12-09T19:09:36.375971 ... RP --- 32:143323 18:072965 --:------ 22E0 004 0064E61E # 22E0|RP|32:143323
2023-12-09T19:09:36.384475 ... RP --- 32:143323 18:072965 --:------ 22E5 004 0086C800 # 22E5|RP|32:143323
2023-12-09T19:09:36.391572 ... RP --- 32:143323 18:072965 --:------ 22E9 004 00B0C800 # 22E9|RP|32:143323
2023-12-09T19:09:36.402487 ... RP --- 32:143323 18:072965 --:------ 22F2 006 0007F50106DE # 22F2|RP|32:143323
2023-12-09T19:09:36.697257 ... RP --- 32:143323 18:072965 --:------ 22F4 013 0040B000000000000000200000 # 22F4|RP|32:143323
2023-12-09T19:09:36.702486 ... I --- 37:006795 32:133306 --:------ 31E0 008 0000000001006400 # 31E0| I|37:006795
2023-12-09T19:09:36.712876 ... I --- 32:143323 32:133306 --:------ 31E0 004 0000B000 # 31E0| I|32:143323
2023-12-09T19:09:37.312242 ... RP --- 32:143323 18:072965 --:------ 313E 011 00000000192C003C800000 # 313E|RP|32:143323
2023-12-09T19:09:37.784609 ... RP --- 32:143323 18:072965 --:------ 3222 003 000000 # 3222|RP|32:143323
2023-12-09T19:09:37.988628 ... RP --- 32:143323 18:072965 --:------ 10D0 006 008AB4990000 # 10D0|RP|32:143323
2023-12-09T19:14:50.848405 # ramses_rf 0.21.40
2023-12-09T19:14:53.010559 ... RP --- 32:143323 18:072965 --:------ 22F1 003 000407 # 22F1|RP|32:143323
2023-12-09T19:14:53.088492 ... RP --- 32:143323 18:072965 --:------ 2210 042 00FF00FFFFFF0000000000FFFFFFFFFF00FFFFFF0000000000FFFFFFFFFFFFFFFF000000000000000800 # 2210|RP|32:143323
2023-12-09T19:14:53.105443 ... RP --- 32:143323 18:072965 --:------ 22E0 004 0064E61E # 22E0|RP|32:143323
2023-12-09T19:14:53.141761 ... RP --- 32:143323 18:072965 --:------ 22E5 004 0086C800 # 22E5|RP|32:143323
2023-12-09T19:14:53.181119 ... RP --- 32:143323 18:072965 --:------ 22E9 004 00B0C800 # 22E9|RP|32:143323
2023-12-09T19:14:53.198671 ... RP --- 32:143323 18:072965 --:------ 22F2 006 0007F50106DE # 22F2|RP|32:143323
2023-12-09T19:14:53.703922 ... RP --- 32:143323 18:072965 --:------ 22F4 013 0040B000000000000000200000 # 22F4|RP|32:143323
2023-12-09T19:14:53.737494 ... I --- 37:006795 32:133306 --:------ 31E0 008 0000000001006400 # 31E0| I|37:006795
2023-12-09T19:14:53.787754 ... I --- 32:143323 32:133306 --:------ 31E0 004 0000B000 # 31E0| I|32:143323
2023-12-09T19:14:53.935662 ... RP --- 32:143323 18:072965 --:------ 313E 011 00000000192C003C800000 # 313E|RP|32:143323
2023-12-09T19:14:53.960303 ... RP --- 32:143323 18:072965 --:------ 3222 003 000000 # 3222|RP|32:143323
2023-12-09T19:14:53.978158 ... RP --- 32:143323 18:072965 --:------ 10D0 006 008AB4990000 # 10D0|RP|32:143323
? Hardware failed (or loose cable?)
There is no evidence of logging, other than restoring a cache?
If you had access to a CLI, try teh basics (ls /dev, lsusb, etc.).
You could try upgrading to 0.30.4, as it is much more strict about serial ports, and you may get a better error message.
Hi.
I tried an update from 0.21.40 to 0.30.4 and on the restart of Home Assistant, these errors are recorded in the home-assistant.log.
2023-12-09 13:56:48.993 WARNING (MainThread) [homeassistant.setup] Setup of ramses_cc is taking over 10 seconds.
2023-12-09 13:56:49.525 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/ramses_rf/helpers.py", line 93, in schedule_fnc
await execute_fnc(fnc, *args, **kwargs)
File "/usr/local/lib/python3.11/site-packages/ramses_rf/helpers.py", line 83, in execute_fnc
return await fnc(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/entity_base.py", line 434, in _poll_discovery_cmds
await self.discover()
File "/usr/local/lib/python3.11/site-packages/ramses_rf/entity_base.py", line 524, in discover
if pkt := await send_disc_cmd(hdr, task): # TODO: OK 4 some exceptions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/entity_base.py", line 480, in send_disc_cmd
pkt: Packet | None = await asyncio.wait_for(
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/asyncio/tasks.py", line 489, in wait_for
return fut.result()
^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/gateway.py", line 826, in async_send_cmd
pkt = await super().async_send_cmd(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/gateway.py", line 323, in async_send_cmd
return await self._protocol.send_cmd(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 598, in send_cmd
return await super().send_cmd(
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 393, in send_cmd
return await self._send_cmd(
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 416, in _send_cmd
await self._send_frame(str(cmd))
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 122, in wrapper
await fnc(*args, **kwargs)
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 198, in wrapper
await fnc(self, frame, *args, **kwargs)
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 564, in _send_frame
await super()._send_frame(frame)
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 426, in _send_frame
self._transport.send_frame(frame)
^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'send_frame'
Home Assistant Core 2023.11.3, Supervisor 23.11.6 & Operating System 11.2.
Can anyone help me understand what it’s telling me?
Cheers
Mike
Hi, you have a really nice imgae for your WTW. Would it be possible to share the image/code?
I also would add the Filter remaining time; sensor.xx_xxxxxx_filter_remaining
(To do so, you’ll need to ad some code manually to the sensor.ply and add an autoimation for keeping the value as it is not integrated yet)