Notes on the Schema II

Overview

TL;DR: The controller uses device data (e.g. sensor temperatures, actuator heat demands), resolved against an internal schema, to determine the system state (e.g. zone temperature).

Some of this data (e.g. the controller's sensor temperature, each zone's heat demand) is not able to be determined by ramses_rf without behaving as the controller does, by resolving these packets against the schema.

A device's location in the schema is tenuous, and the schema is what the controller believes to be true. Of course, your own 'truth' (e.g. a TRV is in a zone) is irrelevant to the controller (as many people see when they first start using ramses_rf). The controller uses the schema to maintain state, and ramses_rf hopes to construct the same schema as the controller for reasons that will become obvious soon...

Many devices, including the controller have a built-in temperature sensor, and ramses_rf eavesdrops the reporting of these (which are cast for the controller's benefit), as it maintains the system state in a manner similar to the controller. Note the evohome controller doesn't have to broadcast it's own temperature to itself and, sadly, doesn't do so.

Now a zone's temperature (as reported by the controller) is the temperature of the device tagged in the controllers schema as the sensor for that zone. There is no other plan, such as:

• no alternative sensor device should the first stop reporting temps for whatever reason
• no average of all the temps of all the sensors in that zone

evhome_rf uses discovery (i.e. it simply asks the controller) to get the schema - and thus to get teh device ID of each zone's sensor. Unfortunately, the controller doesn't tell you what zone it is the sensor for - that zone will simply be reported as having no sensor.

There are other issues too, but the main point is this - ramses_rf cannot guarantee it knows what zone the controller is a sensor for (from discovery), although it could in many circumstances be very confident of which (from eavesdropping - this feature is not enabled, presently).

Questions & Answers

Note: The controller, as a device, has no concept of setpoint, because it is not an actuator (i.e. it is not a TRV, a relay, etc.).

In fact, the controller is not really a device at all is most respects, except it does have a temperature sensor, just like: TRVs, the various Thermostats, the DHW sensor, etc.

I've used the schema.json to allocate the controller as the sensor for zone 0

To be clear - without going into details - I don't think it really offers any value to do so.

From your comment here I think you're therefore saying that it's not possible to show the temperature / setpoint of the controller device itself as it's not physically sending that over RF?

Correct (although see my note above - the controller does not have a setpoint), but you can get the temperature / setpoint of the corresponding zone: you just ask the controller (that is it's main job - to use device data & the schema to maintain the system's state).

and it is the only sensor in the zone

I want to make clear - a zone can only have 1 (or zero) sensor. It can have multiple 'child' devices - many/all of which may have temperature sensors - the controller will pay no attention to those temperatures.

So if the controller is allocated as a sensor to a zone via schema.json (and it is the only sensor in the zone), would it be appropriate to assume that the zone's temperature / setpoint is the controller temperature / setpoint?

This is incorrect. A Zone's temperature & setpoint is from the controller as a controller, not as a sensor. Let me rephrase:

If a zone has no reported temperature sensor in the schema, but the controller reports that the zone has a current temperature (and so must have a temperature sensor), is it appropriate to assume that the zone's sensor is the controller?

Answer: Yes (beware multiroom mode).

As I've said - there is little advantage is manually adding the controller (as a sensor) to the schema.json file - doing so does not provide any additional (reliable) data/functionality & can only break things (that's why I've taken the code out that was able to do this).

I initially thought "oh cool, you also get all the device individual data too" but then noticed that some facets were missing for the hall room thermostat device (which is the controller).

This works both ways - there is some missing device data (e.g. the controller's temperature sensor) and some missing zone data (e.g. each zone's individual heat demand- ramses_rf derives this in a similar way to the controller (i.e. using a schema & device data).