Make that 3, and also lost all the heat demands per HR92 when trying.
Hi Amon, I can happily confirm that your proposed solution with the temp_helper and the automation works!
I have attached some screenshots:
- Before opening the window:
- After opening the window, the temp is put to 5 degrees celsius:
- After closing again the window climate is reverted to heat at the temp stored in the helper in temporary mode confirmed also through the Honeywell Total Home Comfort cloud app / I have 4 schedules for this zone and hence that is why I believe the mode is on temporary until the new schedule activates:
Just for me to understand: since I have 12 zones for each I would like to perform this automation does this mean that I need to create 12 helper numbers to store the temp?
Thanks a lot again for your input!
Hi,
Add me to the list but I’m also seeing water_heater.stored_hw as not available.
Congratulations 
Yes
For me too actually.
water_heater.stored_hw has a state “unavailable”.
mine has never worked. always used the direct sensor for HW entity
I also have sensor.10_040239_ch_water_pressure going unavailable from time to time. In climate entities i have noticed that some attributes return null after a while eg preset_mode. Running 0.31.1
No longer available under 0.31.1
binary_sensor.01_216136_schema
water_heater.stored_hw
binary_sensor.01_216136_active_fault
sensor.10_064873_boiler_output_temp
sensor.10_064873_ch_max_setpoint
sensor.10_064873_ch_water_pressure
binary_sensor.10_064873_dhw_enabled
binary_sensor.10_064873_fault_present
Reverting to 0.30.9 restores previous behaviour
For people with missing entities, it appears that 2-3 separate issues are occurring at once - please be clear which is the case for each of your missing entity:
a) does the issue only occur on 0.31.x
b) is the entity no longer being provided by the integration (Settings > Devices & Services > Entities)
c) is the entity permanent unavailable
d) is the entity simply no longer in the Lovelace UI
I am particularly interested in a), for example:
binary_sensor.13_237335_active
water_heater.stored_hw
binary_sensor.01_145038_schema
sensor.01_145038_hw_heat_demand
I think these fit into group c), see:
I want to add that the status of 2 of the 10 climate-entites goes into unknown.
Attributes of the climate entity with status unknown
hvac_modes:
- heat
- auto
min_temp: 5
max_temp: 35
target_temp_step: 0.1
preset_modes:
- none
- temporary
- permanent
current_temperature: 19.6
temperature: 19
hvac_action: idle
preset_mode: null
id: "01:223036_00"
params:
config:
min_temp: 5
max_temp: 35
local_override: false
openwindow_function: false
multiroom_mode: false
mode: null
name: Woonkamer
zone_idx: "00"
heating_type: radiator_valve
mode: null
config:
min_temp: 5
max_temp: 35
local_override: false
openwindow_function: false
multiroom_mode: false
schedule: null
schedule_version: null
icon: mdi:radiator
friendly_name: Woonkamer
supported_features: 17
binary_sensor.13_259021_active:
This entity is no longer being provided by the ramses_cc integration. If the entity is no longer in use, delete it in settings.
This is the same message I see for water_heater.stored_hw
This 0.31.1 bug has been fixed - new release is coming.
FWIW - it was caused by some exciting changes that are coming soon!
This 0.31.1 bug has been fixed.
1 Like
HA Custom Card (PIV) By @Behold81 · zxdavb/ramses_cc Wiki (github.com)
For anyone interesting in a PIV Card.
The 0.31.1 bug for the unavailable OTB binary sensors (e.g. above) has been fixed.
I am using 0.22.4 and have a fake evohome temperature sensor. The fake sensor also has a fake battery sensor which is in HA 100%.
The evohome controller however warns about a low battery.
My guess is that the battery state is not broadcasted to the evohome controller.
Is that right? Any idea how to solve this?
There is an alternative explanation too - just send me a 24 hour packet log. it woudl be great if it included the 0418 (low battery error) packet.
I’ll just get the faked device to ping a battery signal every 24h or so (I thought I’d already done that).
If you have any time left, could you also have a look at the faking of the temperature sensor and my questions about it?
I was able to resolve the issues with these:
- Woonkamer update faked temp sensor (nieuw): Error executing script. Error for call_service at pos 1: Error rendering data template: ValueError: Template error: float got invalid input ‘unknown’ when rendering template ‘{{ states("sensor.indoor_outdoor_meter_1856 ") | float }}’ but no default was specified
- Woonkamer update faked temp sensor (nieuw): Error executing script. Service not found for call_service at pos 1: Service ramses_cc.put_temperature not found.
By tweaking the text (in other words, stealing it from my previous automation) and changing the service call to the put in “ramses_cc.put_zone_temp”.
However, I’ve been unable to get the entity for the temperature sensor back (no longer being provided by ramses_cc etc.) When I run the automation I can see it get’s the reading from the actual sensor, but it never updates the controller panel and the 03:123456 remains no longer available (no longer being provided by ramses_cc etc).
The previous Wiki version had a lot longer automation updating several entities. The new one doesn’t and I’m running into to much weirdness to be able to pinpoint what’s going wrong.
- I see you changed the class to THM, instead of just faked. Is this required?
- Should the faked sensor still be set in the configuration to tell it, it is the sensor for zone x or y with:
zones:
“00”: {sensor: 03:123456}
? - Is it (still) possible to have different sensors with the same name behind the colon “123456” in the second part? As I have both a faked remote for my fan (29:123456) and a sensor (03:123456).
- Entity “ramses_cc.03_123456” is unknown to my system, so can you describe what this represents or what you mean by it? Should it be changed to something else?
- Is it possible to do a write up as I did for the previous version I can try to follow for the new version? Maybe just copy paste my post for 0.22.40 and adjust were needed?
- Any news about the heat demands of the HR92’s disappearing and new temperature entities appearing for all my zones?
I know it’s a lot of questions, but I really want to make it work again, so I can get back to testing this or any other new versions. atm it’s quite cold here, and I’m really not making any friends here when the heat stays off…
I understand the water_heater.stored_hw and OTB binary sensors missing in 0.31.1 will be fixed in the next release, thx.
I also have some other OTB sensors that are permanently unavailable in 0.31.1 that were reliably showing data in 0.30.9:
sensor.10_064873_boiler_output_temp
sensor.10_064873_ch_max_setpoint
sensor.10_064873_ch_water_pressure
sensor.10_064873_dhw_setpoint
Are these addressed by the same fix?
Environment: Home Assistant Blue / SSM-D2 / Evohome colour / R8810A OTB / Intergas boiler
Yes…
First, many sensor entities still exist, but) will no longer appear on the default dashboard, e.g.:
- binary_sensor.04_xxxxxx_battery_low
Note: Every device (and evohome tcs/zone/dhw) you have should appear at least once in the default dashboard as a sensor.
These (actuator) state entities were created in error, and can be removed, e.g.:
binary_sensor.10_xxxxxx_actuator_statebinary_sensor.13_xxxxxx_actuator_state
Several entities were no longer present and have been restored - fixed, e.g.:
binary_sensor.13_237335_activewater_heater.stored_hw
Several entities were always unavailable - this has been fixed, e.g.:
binary_sensor.01_145038_schema???sensor.01_145038_hw_heat_demand???
Note: This bug included almost all OTB sensors.
TBA: Several binary sensor entities were always True (only for OTB?), e.g.:
- ???
TBA: Some sensor entities have been renamed, e.g.:
binary_sensor.01_145038_schemais renamedbinary_sensor.01_145038_status???