I’m seeing something similar. If the yaml is
- service: ramses_cc.set_dhw_mode
data:
mode: temporary_override
active: true
duration:
minutes: 10
mode: single
then the gui in the automation editor does not show a duration value (the slider is hard to the left). If I put 10 (minutes) in the gui, then the generated yaml simply shows duration:10.
Installed latest 0.20.22d and the binary sensor: '‘binary_sensor.10_040239_flame_active’ stays unavailable.
Config:
ramses_cc:
serial_port: /dev/ttyUSB0
restore_cache: true
scan_interval: 180
packet_log:
file_name: /config/ramses_cc_packet.log
rotate_bytes: null
rotate_backups: 7
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true
01:223036:
zones:
"00": {sensor: 01:223036}
known_list:
01:223036:
10:040239:
04:231770:
04:231772:
04:231774:
04:231776:
04:050559:
04:155445:
04:155403:
04:081849:
04:155443:
04:155407:
04:155551:
04:155533:
04:155537:
Log: 2022-09-07T11:00:08.118759 095 RQ --- 18:005567 01:223036 --:------ 12B0 001 01 - Pastebin.com
what version did you come from?
please provide at least a 24h log
I was using 0.20.15a
Hi, I’ve upgraded to 0.20.22d and got the following config and it managed to identify all the components of the Evo system correctly except second BDR91 driving Hot water valve (but relevent binary sensor still shows the activity, just around 5 min late)
This is the config I used
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
01:095421: {}
restore_cache: true
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
scan_interval: 180
and this is the schema
system:
appliance_control: '13:246010'
orphans: []
stored_hotwater:
sensor: '07:043766'
hotwater_valve: '13:133295'
heating_valve: null
underfloor_heating: {}
zones:
'00':
_name: Living-Dining
class: radiator_valve
sensor: '04:112342'
actuators:
- '04:112342'
- '04:112622'
'01':
_name: Bathrooms
class: radiator_valve
sensor: '04:256582'
actuators:
- '04:112616'
- '04:256354'
- '04:256582'
'02':
_name: Hall
class: radiator_valve
sensor: '04:112626'
actuators:
- '04:112626'
'03':
_name: Bed1
class: radiator_valve
sensor: '04:123563'
actuators:
- '04:123563'
'04':
_name: Bed2
class: radiator_valve
sensor: '04:112340'
actuators:
- '04:112340'
'05':
_name: Bed3
class: radiator_valve
sensor: '04:112346'
actuators:
- '04:112346'
'06':
_name: Bed4
class: radiator_valve
sensor: '04:112624'
actuators:
- '04:112624'
'07':
_name: Bed5
class: radiator_valve
sensor: '04:112338'
actuators:
- '04:112338'
'08':
_name: Study1
class: radiator_valve
sensor: '04:256588'
actuators:
- '04:256588'
'09':
_name: Kitchen
class: underfloor_heating
sensor: '22:172595'
actuators: []
0A:
_name: Study2
class: underfloor_heating
sensor: '22:172591'
actuators: []
0B:
_name: Consv
class: underfloor_heating
sensor: '22:143362'
actuators: []
I like to feedback on UFH testing as not many got it, but just wondering if my configuration is good enough to provide realistic feedback.
For info, my heating setup is EvoHome with 12 zones; Living-Dining with 2 actuators in one zone, and 3 bathrooms under one zone, and 3 UFH zones via HCC80 and 2 BDR91 to control boiler and hot water valve
Thanks,
I never had the flame sensor. I have several sensors always unavailable. I assumed it was my ems-ot gateway not providing that information. @phdelodder could this also be your case?
It worked before upgrading to 0.20.22d, if it revert to 0.20.15a I get the sensors back.
I can work with that… hang on.
OK, I have identified, and corrected this bug - fix coming.
@phdelodder Try version 0.20.22e, just released & let me know.
All - I am making only the smallest changes necessary to 0.20.22 - I would consider it stable, and strongly advise people to upgrade to it.
It’s fixed, the sensor is back!
Hello,
I’ve updated to 0.20.22e and finally had time to test a bit more the latest version (I was still on the last stable before). Everything is working great for me so far. All my sensors are present and I see a lot more information coming up from my ventilation system (Orcon).
The remote control faking is working very well with the ventilation too. I can change speed, activate or deactivate the bypass, … That’s really amazing :D.
Thanks a lot for all the hard work you’ve put into this.
Just updated to 0.20.22e, from 0.18.x, did the gateway binary_sensor get removed?
For example, for my nanoCUL I used to have ‘binary_sensor.18_141846_gateway’ - I used to check for availability and/or the controller status and alerted on errors.
ramses_cc:
restore_cache: True
serial_port:
port_name: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
baudrate: 57600
packet_log:
file_name: /config/packet.log
rotate_backups: 3
ramses_rf:
enforce_known_list: true
max_zones: 8
# schema:
# controller: 01:050858
known_list:
01:050858: # Controller
04:055594: # Living Room Rad 1
04:055514: # Living Room Rad 2
03:055594: {faked: true} # Living Room Xiaomi Faked Sensor
04:055596: # Front Room
03:055596: {faked: true} # Front Room Xiaomi Faked Sensor
04:055510: # Utility
03:055510: {faked: true} # Utility Xiaomi Faked Sensor
04:055480: # Guest Room
03:055480: {faked: true} # Guest Room Xiaomi Faked Sensor
04:055506: # Master Bedroom
03:055506: {faked: true} # Master Bedroom Xiaomi Faked Sensor
04:055486: # E Office
03:055486: {faked: true} # E Office Xiaomi Faked Sensor
04:055482: # Y Office
03:055482: {faked: true} # Y Office Xiaomi Faked Sensor
04:055600: # Hallway
07:014869: # Stored Hot Water
18:141846: # nanoCUL
13:215029: # Stored Hot Water Relay
13:246213: # Central Heating Relay
EDIT: Ah, I see, but I don’t seem to have this new entity:
Other breaking changes:
The two gateway sensors have merged into
binary_sensor.18_xxxxxx_status:
binary_sensor.18_xxxxxx_config, andbinary_sensor.18_xxxxxx_gatewayIt may be useful to rename it to
binary_sensor.18_xxxxxx_gatewayto preserve your automations.
Anyone else with a nanoCUL, do you see the new binary_sensor.18_xxxxxx_status entity?
Every time I restart HA - latest stable release, Home Assistant 2022.9.2 - I get these messages, most of my zones have faked sensors. I assume, because of the approximately-5-minute-delay in start-up until everything becomes available, the service is not present at start up:
Guest Room Evohome Faked Sensor uses an unknown service
The automation “Guest Room Evohome Faked Sensor” (
automation.guest_room_evohome_faked_sensor) has an action that calls an unknown service:ramses_cc.put_zone_temp.This error prevents the automation from running correctly. Maybe this service is no longer available, or perhaps a typo caused it.
To fix this error, [edit the automation](/config/automation/edit/Guest Room Evohome Faked Sensor) and remove the action that calls this service.
Click on SUBMIT below to confirm you have fixed this automation.
… it does run correctly, when all evohome ‘stuff’ becomes available eventually. But on every HA restart, I get one of these for every zone with a faked sensor/automation.
I have fixed that with checking if the main climate entity is available within the automation.
I get “sensor.10_130890_ch_water_pressure” as not available and many more sensor.10_130890 not available but not all off them the flame is working well I upgraded from 0.18.x in this version I saw the sensor.10_130890_ch_water_pressure. Thanks in advanced
How long have you waited after upgrading? It may take a while for the initial updates to come, as you will have lost your cache during the upgrade from 0.18.x.
I get this error too - only just noticed - @phdelodder can you explain in more detail how you got rid of it - I cannot.
Perhaps a ‘not’ condition, something like?
condition:
condition: not
conditions:
- condition: state
entity_id: climate.guest_room
state: "unavailable"
Can’t do any more restarts until tomorrow 
I appear to have that entity.