is config flow documented somewhere? it isn’t clear to me the benefit/why I want to take advantage of it. Thanks.
Upgraded to 0.41.7 from 0.31.6
All dashboards and automations are working as normal
love how all the entities are now showing under Ramses integration, especially the controller showing all the connected devices and then navigate to all asociated automations etc. Fantastic work
1 Like
@ zxdavb
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.
how do i do this with the new version ?
known_list:
03:123456: {class: THM, faked: true}
returns a error in the config
Edit
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
Please provide a packet log, if you want any help on this. Make it a 24h log, and I’ll try to address the other issues to.
and yet the UI shows:
03:123456:
class: THM
faked: true
Why not try this: 03:123456: {class: THM, faked: true}, or this:
03:123456:
class: THM
faked: true
I think this is saying it is already binding. Did you invoke the service call a second time before waiting for it to succeed/fail?
What is your system schema?
A couple of minor observations with 0.41.7:
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.
A restart is not needed - the integration is restarted in the background.
After the restart caused by clearing the cache, it has to collect 0004 packets - these contain the zone name.
By default it polls for these data only once every 6 hours…
This is a UX issue - please submit an issue to the github repo.
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”.
I guess what I was saying was: what error message are you getting the first time?
The error message you have shown us, if when you trued a subsequent time - it is not useful.
You have not indicated if you have seen the expected messages (as shown in the wiki) in your packet log?
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.
I think I may have been having a dumb moment and used Search Integrations instead of using Add Integration
Im sorry , i probably had a dumb moment , it all worked out and is working as it should.
Thanks for your responses and time!
Appreciate the good and awesome work!
I have updated to 0.41.7 and very impressed thank you. Interestingly I’m still getting
The config schema is not minimal (consider minimising it)
even though I have commented out all the ramses_cc entries in configuration.yaml
Please post or PM me your configuration.yaml. When you do, please remind me why I asked you to do so, like:
Here is the configuration.yaml you asked me to post because I am getting this error message:
The config schema is not minimal (consider minimising it)
Here is the configuration.yaml you asked me to post because I am getting this error message: The config schema is not minimal (consider minimising it)
# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:
group: !include groups.yaml
automation: !include automations.yaml
# script: !include scripts.yaml
scene: !include scenes.yaml
logger:
default: info
template:
- sensor:
- name: "Forecast Temperature"
unit_of_measurement: "C"
state: >
{{ '%0.1f' | format(state_attr('weather.bracadale','temperature') | float) }}
alarm_control_panel:
- platform: manual
device_tracker:
- platform: luci
host: 192.168.1.1
username: !secret luci_username
password: !secret luci_password
consider_home: 180
interval_seconds: 10
new_device_defaults:
track_new_devices: false
recorder:
# db_url: 'sqlite:///:memory:'
commit_interval: 30
purge_keep_days: 5
auto_purge: true
auto_repack: true
zha:
device_config:
00:12:4b:00:23:43:e8:7c-1:
type: switch
I am running RAMSES CC version 0.41.7 and have removed all reference to it in the above config file
The schema is reported as
ID 01:108199
Working schema
system: appliance_control: null orphans: []
stored_hotwater:
sensor: '07:030355'
hotwater_valve: null
heating_valve: '13:142019'
underfloor_heating: '02:022960':
circuits: '00':
zone_idx: 0A '01': zone_idx: null '02': zone_idx: 0A '03': zone_idx: 0A '04': zone_idx: null '05': zone_idx: null '06': zone_idx: null '07': zone_idx: null
zones:
'00': _name: Hallway class: radiator_valve sensor: '04:123650' actuators: - '04:123650'
'01': _name: Front Room class: radiator_valve sensor: '04:123652' actuators: - '04:123652'
'02': _name: Kitchen class: radiator_valve sensor: '04:123648' actuators: - '04:123648'
'03': _name: Master Bedroom class: radiator_valve sensor: '04:123654' actuators: - '04:123654'
'04': _name: Toilet class: radiator_valve sensor: '04:125369' actuators: - '04:125369'
'05': _name: Findlay Bedroom class: radiator_valve sensor: '04:246790' actuators: - '04:246790'
'06': _name: Guest Bedroom class: radiator_valve sensor: '04:024890' actuators: - '04:024890'
'07': _name: Landing class: radiator_valve sensor: '04:112432' actuators: - '04:112432'
'09': _name: Playroom class: underfloor_heating sensor: '34:007977' actuators: []
0A: _name: Living Room class: underfloor_heating sensor: '34:009973' actuators: []
0B: _name: William Bedroom class: radiator_valve sensor: '04:049506' actuators: - '04:049506'
I’m also seeing this warning on 0.41.7 but I was seeing in on 0.31.7 as well. My ramses_cc YAML has been migrated into Config Flow, as follows:
System schema(s):
"01:216136":
system:
appliance_control: "10:064873"
Known device IDs:
"18:072981":
class: HGI
"01:216136": {}
"10:064873": {}
"13:042605": {}
"13:016112": {}
"07:050121": {}
"22:012299": {}
"34:058721": {}
"04:056673": {}
"04:034720": {}
"04:034682": {}
"04:034716": {}
"04:034726": {}
"04:036050": {}
"04:036076": {}
"04:056677": {}
"04:106557": {}
"04:056675": {}
"04:036066": {}
"04:034690": {}
"04:036068": {}
"04:034722": {}
"04:208998": {}
"04:208990": {}
"04:208994": {}
"04:034684": {}
"04:034692": {}
"04:208992": {}
Hi David,
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.