Any thoughts on the issues with the fans responsiveness to impersonated remote commands? The physical remote works without issue. Impersonated one unfortunately does has issues. This behavior started with 0.31.3 I believe.
Also still having a lot of these:
RP --- 37:182456 18:203291 --:------ 22F2 003 000482 < PacketInvalid(RP --- 37:182456 18:203291 --:------ 22F2 003 000482 < Unexpected code for src to Tx)
RP --- 37:182456 18:203291 --:------ 3222 007 000504000E000F < PacketInvalid(RP --- 37:182456 18:203291 --:------ 3222 007 000504000E000F < Unexpected code for src to Tx)
RP --- 37:182456 18:203291 --:------ 22F2 003 000483 < PacketInvalid(RP --- 37:182456 18:203291 --:------ 22F2 003 000483 < Unexpected code for src to Tx)
RP --- 37:182456 18:203291 --:------ 3222 009 0004060E000E000F0D < PacketInvalid(RP --- 37:182456 18:203291 --:------ 3222 009 0004060E000E000F0D < Unexpected code for src to Tx)
RP --- 37:182456 18:203291 --:------ 3222 010 0003070E0E000E000F0D < PacketInvalid(RP --- 37:182456 18:203291 --:------ 3222 010 0003070E0E000E000F0D < Unexpected code for src to Tx
And these:
RP --- 37:182456 18:203291 --:------ 3222 013 00000A0E0E000E0E000E000F0D < Payload doesn't match '^00[0-9A-F]{4,20}$': 00000A0E0E000E0E000E000F0D
I 164 03:255542 --:------ 03:255542 30C9 003 010708 < Packet idx is 01, but expecting no idx (00) (0xAB)
I 165 03:255542 --:------ 03:255542 30C9 003 0106F4 < Packet idx is 01, but expecting no idx (00) (0xAB)
I 166 03:255542 --:------ 03:255542 30C9 003 0106EA < Packet idx is 01, but expecting no idx (00) (0xAB)
I 167 03:255542 --:------ 03:255542 30C9 003 0106E0 < Packet idx is 01, but expecting no idx (00) (0xAB)
Lastly, any news on the HCF82? If you search for HCF82, there are apparently more people who are having issues with the entities of these thermostats not being instantiated in HA.
Received my SSM D2 today and updated to latest version.
All seems good and stable, temperature changes respond within a few seconds.
Just need to figure out how to fake the temp sensor for the main controller.
So i can move the evohome controller to the boiler room and use a tablet in the livingroom.
I added the faked sensor to my rames.yaml and removed the intergration and rebooted it again.
Now the integration took my known list and added the faked sensor.
Now im strugling to bind the sensor to the controller
Logger: homeassistant.helpers.script.websocket_api_script
Source: helpers/script.py:476
First occurred: 15:31:02 (41 occurrences)
Last logged: 16:15:16
websocket_api script: Error executing script. Unexpected error for call_service at pos 1: 03:123456: SuppSendOfferWaitForAccept: bad State for binding as a Supplicant
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 476, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 713, in _async_call_service_step
response_data = await self._async_run_long_action(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 675, in _async_run_long_action
return long_task.result()
^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2149, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2186, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1043, in check_permissions
return await service_handler(call)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/ramses_cc/__init__.py", line 183, in async_bind_device
await device._initiate_binding_process( # may: BindingFlowFailed
File "/usr/local/lib/python3.11/site-packages/ramses_rf/device/base.py", line 366, in _initiate_binding_process
msgs = await self._bind_context.initiate_binding_process(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/binding_fsm.py", line 317, in initiate_binding_process
raise exc.BindingFsmError(f"{self}: bad State for binding as a Supplicant")
ramses_rf.exceptions.BindingFsmError: 03:123456: SuppSendOfferWaitForAccept: bad State for binding as a Supplicant
I tried clearing the State and Schema caches via the UI to see how that worked. After submitting the configuration form to clear the cache there’s nothing in the UI to make it clear a restart is needed (unless I missed it).
After clearing the cache 4 of my Evohome zone devices picked up names of the form RAD 01:216136_0x instead of the zone name. Easy to change name and related entity ID’s in the UI of course. Just wondering what the behaviour would be on a new installation via Config Flow.
OK - I was expecting sensors to go “unavailable” initially after clearing the cache - maybe I didn’t wait long enough
Out of interest I tried removing the integration completely and re-installing 0.41.7 from scratch. It was not obvious how to get from installing the integration to the configuration UI stage - it didn’t appear in “Settings - Integrations”. I re-instated my ramses_cc YAML config, re-started and the config was imported as before. Maybe I missed a step there?
After a clean install all devices and and entities appeared as before, minor change to the zone device id’s from climate.ramses_cc_01_216136_0x previously to climate.01_216136_0x and similar for the controller and stored_hw. Zone names all appeared correct immediately.
Apart from not being clear to me how to get to the initial config without using YAML a clean install of 0.41.7 worked fine. Appreciate 0.41.7 is still “experimental”.
You need to press the Add integration button in the lower right and search for “RAMSES RF”. That is to say it’s not any different to adding any other integration for the first time.
First of all, awesome work on the integration!
I installed ramses_cc recently and I was wondering if the integration can impersonate a controller, or if I can use a round thermostat as a controller (less practical, since it is battery powered).
My goal is to change the round thermostat setpoint (as an ATC controller or rfg100 would do), but I’m not seeing how. Do you have any suggestions how I might get this working?
Currently I have a battery powered round thermostat (T87RF2025), an OpenTherm bridge (R8820) and a NanoCul (atmega328) running evofw3. I’m running ramses_cc 0.41.7 on HA OS on a Pi4.
I can see packets being sent between T87RF and bridge, and between Bridge and NanoCul. Also, I can see the thermostat and boiler entities with temperature, setpoint, modulation level, etc.
It could, but you would have to use primitive APIs rather than (say) service calls.
The work would be onerous, and I do not have the capacity to get involved.
For a start, simply watch / appreciate what the round thermostat and the OTB are saying to each other. You can use ramses_rf to decode the packet logs.
binary_sensor.01_123456_schema is now called binary_sensor.01_123456_status
also, within that entity, the attributes.schema of old is now attributes.working_schema, although that is not listed as a breaking change in the release notes (it breaks anything that uses the API to access HA, such as my EvoControl Alexa skill).
