It could, but you would have to use primitive APIs rather than (say) service calls.
The work would be onerous, and I do not have the capacity to get involved.
For a start, simply watch / appreciate what the round thermostat and the OTB are saying to each other. You can use ramses_rf to decode the packet logs.
Methinks it should actually be
binary_sensor.01_123456_schema is now called binary_sensor.01_123456_status
also, within that entity, the attributes.schema of old is now attributes.working_schema, although that is not listed as a breaking change in the release notes (it breaks anything that uses the API to access HA, such as my EvoControl Alexa skill).
@philchillbill I am afraid I neglected to take you into account.
I am sure I promised to keep you up to date with breaking changes & I didn’t.
We’ll need to work out a way of stopping this happening in the future - perhaps with a test suite integrated into ramses_cc that pings the endpoints you rely upon.
This one got me when I reloaded
climate.ramses_cc_01_123456_00
is now
climate.01_123456_00
I would like at many people as willing to try turning on Qos:
For version 0.31.7, in configuration.yaml:
ramses_cc:
ramses_rf:
disable_qos: false # true, false, default is null
For version 0.41.7 (config flow), use Settings > Devices > RAMSES RF > CONFIGURE > Gateway configuration and:
disable_qos: false # true, false, default is null
NOTE: You may get more errors in you HA log - only because it will now know when a Tx has failed, and is reporting it as such.
That is, there errors may have always been there, but you only now have visibility of them.
I just received and installed my SSM-D2 Rev B, after shipping costs and import duties it was quite an investment. But it installed and works like a charm!
Does anybody know whether there are options for a range extender of the signal from the Evohome thermostats? Or other tricks?
The stick is installed in my server at one side of the house and the thermostat at the oppside side of the house is discovered, and sometimes receives a signal but it is frequently interrupted:
Here is an example:
2024-02-12 19:24:29.814 INFO (MainThread) [ramses_tx.transport] Tx: b'RQ --- 18:000730 10:048122 --:------ 3220 005 0000000000\r\n'
2024-02-12 19:24:29.841 INFO (MainThread) [ramses_tx.transport] Rx: b'000 RQ --- 18:006402 10:048122 --:------ 3220 005 0000000000\r\n'
2024-02-12 19:24:30.045 DEBUG (MainThread) [ramses_tx.protocol_fsm] Context(WantRply, len(Queue)=1/0): Failed to Rx reply 3220|RP|10:048122|00 (will retry): Failed to leave WantRply(rx_hdr=3220|RP|10:048122|00, sends=1) in time
2024-02-12 19:24:30.045 INFO (MainThread) [ramses_tx.transport] Tx: b'RQ --- 18:000730 10:048122 --:------ 3220 005 0000000000\r\n'
2024-02-12 19:24:30.072 INFO (MainThread) [ramses_tx.transport] Rx: b'000 RQ --- 18:006402 10:048122 --:------ 3220 005 0000000000\r\n'
2024-02-12 19:24:30.102 INFO (MainThread) [ramses_tx.transport] Rx: b'062 RP --- 10:048122 18:006402 --:------ 3220 005 00C0000300\r\n'
I ran a SMA coax cable from my SSM-D2 to an upper floor to extend the range. This is what I bought SMA cable
Sounds interesting! Do you use that on the antenna plug, to extend the antenna?
Enabled QOS as requested - here is latest entry in system log. Do you need packet.log as well?
Logger: ramses_rf.dispatcher
Source: runner.py:188
First occurred: 10 February 2024 at 12:47:48 (81 occurrences)
Last logged: 21:50:05
I don’t need logs.
These errors are not caused by QoS:
[quote="dwp, post:4254, topic:151584"]
I — 02:022960 18:069148 --:------ 2309 003 030C80 < PacketInvalid( I — 02:022960 18:069148 --:------ 2309 003 030C80 < Unexpected verb/code for src to Tx)
[/quote]
I’ve been running 0.41.7 with disable_qos: false for a little over 12 hours - no obvious changes in behaviour. As you noted, I’m seeing occasional log errors like these:
2024-02-13 12:56:35.110 ERROR (MainThread) [ramses_rf.gateway] Failed to send 2401|RQ|10:064873: 2401|RQ|10:064873: Other error
2024-02-13 13:01:35.556 ERROR (MainThread) [ramses_rf.gateway] Failed to send 3220|RQ|10:064873|00: 3220|RQ|10:064873|00: Other error
2024-02-13 14:14:08.591 ERROR (MainThread) [ramses_rf.gateway] Failed to send 2349|RQ|01:216136|08: 2349|RQ|01:216136|08: Other error
No obvious pattern to the transmission errors, about 1 or 2 an hour.
I updated to 0.31.7 over the weekend and noticed some strange behaviour with my automations. When I make service calls to set the mode, eco_boost always sets for an hour, even if I leave period and duration empty, whereas it used to make this permanent. I can’t select day_off, custom or away at all. I’m also having problems resetting zone overrides but this may because I don’t have delays between the service calls. Downgrading back to 0.21.40 hasn’t helped, but this may also coincide with upgrading to HA 2024.02.01.
I’m running 0.41.7 also on HA 2024.2.1 and I’ve just confirmed I can see the same problem when setting eco_boost. Only sets for 1 hour instead of permanently.
The Honeywell Total Connect Comfort (API based) service call still works as expected.
This script just sets ECO for 1 hour:
alias: Evohome to Auto with Eco
sequence:
- service: ramses_cc.set_system_mode
data:
mode: eco_boost
entity_id: climate.01_216136
mode: single
icon: mdi:home-thermometer-outline
whereas this still sets “permanently” as expected:
alias: Evohome to Auto with Eco
sequence:
- service: evohome.set_system_mode
data:
mode: AutoWithEco
mode: single
icon: mdi:home-thermometer-outline
echo_boost and AutowithEco are different things.
ramses_cc is probably providing a helpful way to implement eco for the predefined boost period of 1 hour. Something that isnt possible with the controller. On the controller only HW gets a boost for 1 hour.
Having said that, I would still expect a normal eco mode for the System mode, if indeed eco_boost is designed to be just 1 hour of boost.
Just unscrew the supplied omni antenna and insert the cable in line.
Has anyone else noticed that the Hot Water device e.g.
water_heater.01_078710_hw
created by ramses_cc does not get a Friendly name assigned to it. Is that a bug with ramses_cc or does the water_heater entity in HA not have the state attribute
friendly_name
?
David,
when people link HA to EvoControl they tell me their desired controller_id on a web-form. During discovery, I call /api/states and filter the JSON looking for and caching certain entity matches. The main one is of course binary_sensor.01_123456_status which I parse for stored_hotwater and zones inside attributes.working_schema. As long as those parameters are not renamed, along with the fields _name, sensor and actuators then nothing breaks for me. The ‘main’ entity-name change from _schema to _status obviously caught me, as did the change from schema to working_schema inside attributes.
In operation (i.e. after initial discovery), I call /api/states and filter on e.g.
binary_sensor.${i}_battery_low,
binary_sensor.${cid}_${haZid}_window_open, sensor.${cid}_${haZid}_heat_demand,
climate.${cid},
water_heater.${cid}_hw,
sensor.${dhwRelayId}_relay_demand,
sensor.${cid}_heat_demand
where cid is the controller_id and the haZids are the 00…0A…0B keys of the zones inside binary_sensor.01_123456_status.
I was initially bitten by the fact that the haZids run from 00…0A…0B while the entity names use lowercased _0a and _0b so maybe that’s an unintentional inconsistency.
I also noticed a change in the reporting of battery status since e.g. 0.22.40 to 0.41.7
"attributes": {
"battery_level": 1 <-- 0.5, <-- null
"device_class": "battery",
"friendly_name": "04:xxxxx battery_low"
}
became
"attributes": {
"id": "04:xxxxxx",
"battery_level": {
"battery_low": false,
"battery_level": 1 <-- 0.5, <-- null
},
"device_class": "battery",
"friendly_name": "TRV 04:xxxxxx Battery"
}
so attributes.battery_level suddenly became attributes.battery_level.battery_level and that also clobbered me.
I’m a bit confused at what you’re saying Bruce. I know the original Evohome integration called it AutoWithEco, but the controller and this has used eco/boost. Either way, the behaviour has recently changed and for me there’s no way to make a system mode permanent.
@brucemiranda - my understanding is that those two service calls should set the same mode on the controller - the first by direct radio communication to the controller and the second via the Honeywell web API. Eco/boost is a single “feature” on the Evohome controller which can be set to be either a reduction or increase in temperature - i.e. it can either be an Eco or Boost setting depending on how the user has set their Evohome controller. I’m assuming the two services just have different terminology for the same controller mode. The first (ramses_cc) service call does set the mode correctly but just for 1 hour. With no time period specified I think it should be “permanent” instead.