Any information on how to add the opentherm parts?
This is the cause - it’s trying to create an ExtSensor, and they’re not fully implemented yet - resulting in the crash.
Why is it trying to create one? Can you look in you .storage/evohome_cc.json file (they’re likely in there as orphans:
"orphans": [
"17:000730",
]
There real question is - why is ramses_rf creating these devices despite the allow_lisy?
See here: Create new page · zxdavb/ramses_cc Wiki · GitHub
You want a Controller ID, and an allow_list if you can make one.
If you’ve an evohome system, it should pick up the OTB during discovery, and expose the sensors automatically. It may not do that well, as I don’t have an OTB to test with, but I’m willing to work with people on that.
{
"version": 1,
"key": "evohome_cc",
"data": {
"client_state": {
"schema": {
"main_controller": "01:169176",
"01:169176": {
"controller": "01:169176",
"system": {
"heating_control": null
},
"orphans": [],
"stored_hotwater": {},
"underfloor_heating": {},
"zones": {
"00": {
"heating_type": "radiator_valve",
"sensor": "04:090189",
"devices": [
"04:090189"
]
},
"01": {
"heating_type": "radiator_valve",
"sensor": "04:112546",
"devices": [
"04:112546"
]
},
"02": {
"heating_type": "radiator_valve",
"sensor": "04:190691",
"devices": [
"04:190691"
]
},
"03": {
"heating_type": "radiator_valve",
"sensor": "04:198483",
"devices": [
"04:198483"
]
},
"04": {
"heating_type": "radiator_valve",
"sensor": "04:038015",
"devices": [
"04:038015",
"04:006190"
]
},
"05": {
"heating_type": "radiator_valve",
"sensor": "04:198487",
"devices": [
"04:198487"
]
},
"06": {
"heating_type": "radiator_valve",
"sensor": "04:198485",
"devices": [
"04:198485"
]
}
}
},
"orphans": [
"10:051349"
]
}
evohome_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
scan_interval: 180
config:
max_zones: 9
packet_log: packet.log
schema:
controller: 01:169176
allow_list:
- 04:090189
- 04:112546
- 04:190691
- 04:198483
- 04:038015
- 04:198487
- 04:198485
- 01:169176
- 10:051349This looks like it’s added 4 new entities but only 2 seem to update, rel_modulation_level and boiler_setpoint.
@fysmd @TheMystery and others…
Just pushed 0.9.8 - it should solve issues with ghost devices causing a cached schema to fail to load. For example:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 248, in _async_setup_component
result = await task
...
File "/usr/local/lib/python3.8/site-packages/ramses_rf/devices.py", line 964, in status
self.LUMINOSITY: self.luminosity,
File "/usr/local/lib/python3.8/site-packages/ramses_rf/devices.py", line 946, in luminosity
raise NotImplementedError
NotImplementedError
2 Likes
Not all OTBs send all data. It also depends upon your boiler/appliance. Some of the data is OpenTherm, some is RAMSES.
Here is an example of one person’s system (not mine - I don’t have an OTB):
"10:123456": {
"actuator_state": {
"actuator_enabled": false,
"modulation_level": 0.0,
"flame_active": false,
"dhw_active": false,
"ch_enabled": false
},
"modulation_level": 0.0,
"boiler_setpoint": 10.0,
"opentherm_status": {
"boiler_temp": 54.95703125,
"ch_pressure": 0.8984375,
"dhw_flow_rate": null,
"dhw_temp": 0.0,
"rel_modulation_level": 0.0,
"return_cv_temp": 54.09765625
… and another:
"10:040239": {
"actuator_state": {
"actuator_enabled": true,
"modulation_level": 0.5,
"flame_active": true,
"dhw_active": false,
"ch_enabled": true,
"ch_active": true,
"ch_setpoint": 75,
"max_rel_modulation": 100
},
"modulation_level": 0.5,
"boiler_setpoint": null,
"opentherm_status": {
"boiler_temp": 53.6796875,
"ch_pressure": 1.5,
"dhw_flow_rate": 71.66796875,
"dhw_temp": 71.66796875,
"rel_modulation_level": 99.0,
"return_cv_temp": 37.8984375
}
},
You’ll need to PM me your packet logs for me to comment further on your system.
From your schema:
"system": {
"heating_control": null
},
IIRC, this is normal when the heating controller is an OTB.
Yes, I see:
"schema": {
"main_controller": "01:138490",
"01:138490": {
"controller": "01:138490",
"system": {
"heating_control": null
},
"orphans": [
"17:000730"
],
and also the following just prior to PACKETS.
even in my official evohome mobile app I see two zones which dont exist and errors to a similar effect in the evohome addon in Homeassistant.
"01:000730": {
"controller": "01:000730",
"system": {
"heating_control": null
},
"orphans": [],
"stored_hotwater": {},
"underfloor_heating": {},
"zones": {}
},
"01:136410": {
"controller": "01:136410",
"system": {
"heating_control": null
},
"orphans": [],
"stored_hotwater": {},
"underfloor_heating": {},
"zones": {}
},
"orphans": [
"08:000730",
"08:000030"
]
},
Pulled and seems to be working now, thank you (again!)
I notice the icons for heating and DWH demand have changed:
FWIW I preferred the previous one!
Updated to version 0.9.10, get this message in the log:
Logger: ramses_rf.schema
Source: /srv/homeassistant/lib/python3.8/site-packages/ramses_rf/schema.py:349
First occurred: 14:45:10 (3 occurrences)
Last logged: 14:45:10
00:110277 is in the schema, but is not in the allow list: check the lists and the (cached) schema
00:025605 is in the schema, but is not in the allow list: check the lists and the (cached) schema
00:256005 is in the schema, but is not in the allow list: check the lists and the (cached) schema
And from these 3 devices i now have from each 4 entities within homeassistant, do i need to remove these orphans in the cached schema?
Edit: downgraded to 0.9.8, because all entities where unavailable.
If you have these in the cached schema / saved state - try restarting with restore_state: false
Anyone else having issues with 0.9.10?
I had to comment out my allow list, otherwise the majority (if not all) of my entities remained unavailable. The logs reported I had a sensor in my schema which was not in the allow list, this was a faked sensor created by mistake. Can’t remember exactly what I did but I think adding this sensor into the allow list didn’t solve the entities being unavailable.
Pretty sure the same behaviour of entities being unavailable started with one of the earlier builds, possibly 0.9.8.
Currently using 0.9.10 without an allow list.
I can confirm by commenting out my allow list as DanRp has done, i have also now got back all my temps/demands/battery and draught devices.
I had only thermostat devices prior to the commenting out.
Wil this not be a problem for a fake sensor i have added to a zone?
I’ve come across a new error and I did some debugging and logging.
I’ve created a new zone, with a fake temperature sensor. However I cannot set the temperature for the zone. When I do a service call I get the following error:
2021-05-25 11:00:57 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [1795891768] Error handling message: Unknown error
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py”, line 21, in _handle_async_response
await func(hass, connection, msg)
File “/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py”, line 482, in handle_execute_script
await script_obj.async_run(msg.get(“variables”), context=context)
File “/usr/src/homeassistant/homeassistant/helpers/script.py”, line 1209, in async_run
await asyncio.shield(run.async_run())
File “/usr/src/homeassistant/homeassistant/helpers/script.py”, line 345, in async_run
await self._async_step(log_exceptions=False)
File “/usr/src/homeassistant/homeassistant/helpers/script.py”, line 363, in _async_step
await getattr(self, handler)()
File “/usr/src/homeassistant/homeassistant/helpers/script.py”, line 563, in _async_call_service_step
await service_task
File “/usr/src/homeassistant/homeassistant/core.py”, line 1481, in async_call
task.result()
File “/usr/src/homeassistant/homeassistant/core.py”, line 1516, in _execute_service
await handler.job.target(service_call)
File “/usr/src/homeassistant/homeassistant/helpers/entity_platform.py”, line 630, in handle_service
await service.entity_service_call(
File “/usr/src/homeassistant/homeassistant/helpers/service.py”, line 658, in entity_service_call
future.result() # pop exception if have
File “/usr/src/homeassistant/homeassistant/helpers/entity.py”, line 726, in async_request_call
await coro
File “/usr/src/homeassistant/homeassistant/helpers/service.py”, line 695, in _handle_entity_call
await result
File “/usr/local/lib/python3.8/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/evohome_cc/climate.py”, line 284, in svc_set_zone_temp
self._device.sensor.temperature = temperature
AttributeError: ‘NoneType’ object has no attribute ‘temperature’
(climate.py line 284 is actually 283 in reality in version 0.9.10, because of a modification)
I logged what self._device would be and it is the correct zone the log saying:
Which device: 01:073976_07 (underfloor_heating)
However the underfloor_heating zone entity, does not contain something like a temperature attribute. I guess it has to map the climate entry however my Python skills are to limited to if this goes correctly. However can it be that setting the temperature setting for a underfloor heating zone is different to a radiator zone?
Another thing I came across, which is not a bug, but user error… I created the zone first as radiator zone, deleted the zone, created it again (all on the Evohome controller). In evohome_cc I kept getting the error of a mismatch between evohome_cc and ramses_rf of the heating type for the zone. Fixed it by changing the type in the file .storage/evohome_cc after a HA restart the error was gone.
Please make your question more clear.
Faked devices need to be in the allow_list. They will appear in the schema.
OK, this gives me something to work on…
I believe this may be broken - I will look at it when I have fixed all other bugs.
I would recommend against implementing faked sensors for now, unless you already have one working.
Seems you me: You created a schema (which is a representation of the real world according to the controller). Then you changed what the controller held to be true, but persisted in using the old schema?
This is not supported, if you change the configuration of your system, you mustdisable using the old schema:
evohome_cc:
restore_state: false
1 Like
i mean if i use this config command: restore_state: false wil this be a problem for my fake sensor?