Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

[zxdavb (David Bonnes)]

@PyroPath

The sensor itself is alive and well, but the faked entity (03:123456) becomes unavailable. I’ve noticed that when my temperature is very constant for something around 2 hours the entity will become unavailable. If I make the temperature change, the ramses entity also will come back to live.

I am not 100% sure of what you describe, so I am not sure if this is the answer you need, but…

ramses_rf has a feature where if it doesn’t hear from a device for a while (on a per command-code basis), then it treats that value as unavailable.

That is (for example), it is better to not know the temperature of a room than it is to believe the room is (say) 15 'C simply because it was so, 4 hours ago. It could be 20 'C at present!

These tombstone timers are usually 2.1x the expected interval between such packets.

I can’t recall the exact time for room temperature packets…

Anyway, if you have a faked room sensor, and it only sends a faked packet when the temp changes, and - for various factors - the temp doesn’t change for a while, then your automation may not send such a packet for such a long period of time that the data expires.

This is why, in the wiki, we have this example:

- id: cast_faked_zone_sensor
  trigger:
    - platform: state
      entity_id: sensor.room_temperature  # rename to your temp sensor
    - platform: time_pattern
      minutes: /15
  action:
...

Notice the second trigger?

[zxdavb (David Bonnes)]

@PyroPath

I’ve been back to 0.22.40 since I couldn’t get 0.31.1

Version 0.31.1 is not recommended.

[zxdavb (David Bonnes)]

@PyroPath

If you have any time left, could you also have a look at the faking of the temperature sensor and my questions about it?

In 0.31.1, binding should be working - faking is not working.

My plan is for this (faking) to be available within the week.

[PyroPath (Wilco Slegers)]

Ah, yes, I see now. Tnx for clearing that up. The previous example for an automation does not include a timed update, and if I recall correctly it explicitly advised against it. I guess what you say is true. I’d rather have the heating off when something goes wrong then a sauna. Tnx for clearing that up.

The past days Evohome seems to have adapted to the colder weather quite good. In the previous weeks I had quite some swings in temperature between +0,5 and - 0,5 degrees compared to the setpoint. At the moment though it holds temperature very well and the temperature can remain constant for hours on end. Hence I had sensors go unavailable and I went into panic mode, thinking that something went wrong.

[PyroPath (Wilco Slegers)]

I can’t wait! Again, Tnx for the hard work!

[zxdavb (David Bonnes)]

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 %}

[galaxy_explorer]

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.

[galaxy_explorer]

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

[phdelodder (Philippe Delodder)]

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?

[zxdavb (David Bonnes)]

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.

[galaxy_explorer]

@zxdavb

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?

Support DT4R (YT42WRFT20) thermostat

[behold81]

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?

[peternash]

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.

[peternash]

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

[zxdavb (David Bonnes)]

@galaxy_explorer

With v31.2 (and probably earlier versions) the get_zone_service isn’t working. It works in v21.4

I believe I have fixed this.

I didn’t know anyone was using it! Are you using set_zone_schedule too?

[behold81]

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

[zxdavb (David Bonnes)]

@behold81

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?

I don’t believe so. It is there just as an indication of what is possible.

@behold81

I managed to get my 4 way fake switch working.

… is there a way I can test this end to end for you with the fact I have already bound a device?

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:

[zxdavb (David Bonnes)]

@peternash

Switching back to 0.30.9 results in reliable data from those sensors

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?

[behold81]

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

[galaxy_explorer]

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?