I can’t wait! Again, Tnx for the hard work!
Could anyone kindly post their data template that can handle it when the underlying sensor is unavailable?
I am time-poor, but it needs to be in the wiki.
For example, this:
- id: cast_faked_zone_sensor
trigger:
- platform: state
entity_id: sensor.room_temperature # rename to your temp sensor
action:
- service: ramses_cc.put_temperature
data:
entity_id: ramses_cc.03_123456
temperature: '{{ states("sensor.room_temperature") | float }}'
… shoudl look something like this:
- id: cast_faked_zone_sensor
trigger:
- platform: state
entity_id: sensor.room_temperature # rename to your temp sensor
action:
- service: ramses_cc.put_temperature
data:
entity_id: ramses_cc.03_123456
temperature: >-
{% if states("sensor.room_temperature") != "unavailable" -%}
{{ states("sensor.room_temperature") }}
{%- else -%}
{{ None }}
{%- endif %}
Curious to know if anyone is using the new-ish wireless DT4R thermostat (YT42WRFT20) with Evohome, it is “backwards” compatible with RAMSES-II and supports the new RAMSES-III protocol. Not sure what’s changed in the protocol but I suspect it includes encryption. That could be a long but hopefully slow death if the packets are encrypted in newer products.
So I bought the DT4R thermostat (YT42WRFT20) for testing but I suspect a new device ID is required as I get the following log error
I --- 22:033088 63:262142 --:------ 10E0 038 000002FF1F00FFFFFFFFFFFFFFFFFFFFFFFF44543420303232004999DF19F7BD683294B0B073 < Support the development of ramses_rf by reporting this packet, with the make/model of device: DT2:033088 (device type 22 not known to have signature: 0002FF1F00FFFFFFFF)
I created an issue here Support DT4R (YT42WRFT20) thermostat · Issue #139 · zxdavb/ramses_cc · GitHub
When executing the service ramses_cc.set_zone_mode to do a temporary override, it sometimes doesn’t happens. I have the same experience with 0.31.1 and 0.30.9.
- service: ramses_cc.set_zone_mode
data:
entity_id: climate.febe
mode: temporary_override
setpoint: 18
duration:
hours: 1
minutes: 20
seconds: 0
Can I revert to 0.22.40?
Version 0.31.2 has just been released.
We apologise for 0.31.1… This release should include fixes for all reported bugs in that release.
I encourage people to try this release - you should be able to bounce between
- 0.20.x, 0.21.x, 0.22.x, and
- 0.30.x, and
- 0.31.x
… without losing data.
Those who do so, should report bugs here.
Note that some of the service call names/schemas have changed.
In particular, I have tested faking of HVAC switches / remotes.
You should be able to:
a) create virtual switches (rather than simply impersonate existing switches)
b) fake those switches (i.e. cause them to send commands)
I have extensively tested this for the Nuaire OEM, and I would appreciate people trying this out, see: the wiki
The code should also support Itho and Orcon (and others), but I have not written the wiki for these as I do not have the necessary data (i.e. YAML) - that will require input from yourselves.
1 Like
With v31.2 (and probably earlier versions) the get_zone_service isn’t working. It works in v21.4
service: ramses_cc.get_zone_schedule
Log error
"Failed to call service ramses_cc.get_zone_schedule. Unknown error"
Furthermore, is it possible to add this new DT4R device type?
I managed to get my 4 way fake switch working. I notice you have 2 more commands (batt and Device Info)
Do I need to add these and is there a way I can test this end to end for you with the fact I have already bound a device?
Any other tests you would like done?
FYI, I have a DT4R working as a zone thermostat with an Evohome colour controller. I saw similar messages in 0.22.40 but it was still recognised with data retrieved. In 0.30.9 I didn’t see those log messages and still working OK.
Testing 0.31.2: The missing water_heater.stored_hw and OTB binary sensors in 0.31.1 seem to be fixed. Still getting permanently unavailable from the following OTB sensors:
sensor.10_064873_boiler_output_temp
sensor.10_064873_ch_max_setpoint
sensor.10_064873_ch_water_pressure
sensor.10_064873_dhw_setpoint
Switching back to 0.30.9 results in reliable data from those sensors
I believe I have fixed this.
I didn’t know anyone was using it! Are you using set_zone_schedule too?
sensor.07_038573_temperature this is no longer recieving any data. this is a CS92 HW Temp Sensor
I am getting the water_heater sensor now. but i have a few cards using State for filter control not attribute and do not support this. this is a useful entity to have. I am seeing no mention of it in the logs any longer.
Thanks
I don’t believe so. It is there just as an indication of what is possible.
IIRC, you are using Nuaire and you do not have a real switch?
Is teh automation working OK? Did you have any difficulty with the instructions on the wiki?
If you like, you can start playing with a virtual relative humidity sensor? I will tweak the relevant page of the wiki for you to make a start:
1 Like
I wonder if this has something to do with use_native_otb: ?
Can you PM me your configuration.yaml, and a packet log from 0.31.2?
When I followed it I was on 31.1 and i had a small issue with the bind. I had to issue the boost command to complete the bind. but it worked. since all 4 commands worked fine. Happy to add the humidity option.
I assume I add the humidity sensor with a feed from another sensor to control it. and in theory I could create a virtual sensor combining multiple sensors and use the average or highest humidity to control the unit.
My understanding is the Humidity sensor activates a boost mode not a purge so only increases the fan 1 speed rather than full speed. so be useful for when humidity is only slightly higher then really high instigate purge through automation
I am using the schedule get_zone_service to populate my schedule card
I’d also like to use the set_zone_schedule but I thought it was never implemented or broken? Do you have a JSON / data example to try it out?
Initially I was not seeing
sensor.07_050121_temperature
binary_sensor.07_050121_battery_low
on 0.31.2 either - both showing “unavailable”. However, after a couple of hours they’re available again.
1 Like
Still not showing on mine yet. we will see.
This is normal behaviour - these packets are sent only infrequently.
See above.
1 Like
I am a little doubtful. How did you know the bind wasn’t successful before you issued the boost?