Notes on the Schema

OMG, the answer to this will be worth making into a wiki entry...

1st (useful to know): the output schema can be used as an input schema, so just use:

python client.py monitor /dev/ttyUSBx -x "RQ 01:xxxxxx 1F09 00"

and hit Ctrl-C after the last RP/01:xxxxxx/0418/xx - the schema should be there for you. Have you run the CLI yet - to do so is very useful, so get involved in that.

2nd: I have not had a UFH system to test against, so expect some issues.

3rd (the biggie): There are three means used by evohome_rf to construct the schema (in order of development):

• from eavesdropping (by capturing packets between the controller and other devices)
• from the input schema provided as a dict
• from discovery (i.e. the controller is asked a series of RQ s, and the corresponding RP are used)

There are advantages to all 3 options - and each has issues, too. One is that when an received packet - usually an eavesdropped packet) does not match the schema: CorruptStateError (another reason why your input schema should be 'right').

The schema is important, it is used to construct some meta-data (e.g. zone heat demand from the child devices of that zone), and the objects (so you can, e.g. set the mode of a zones).

4th...

If I use the temperature sensor in the main controller itself for one zone

I just want to say, just want to avoid confusion: the schema should reflect reality: (evohome_rf doesn't change the behaviour of evohome), so 'making' the controller the sensor for a zone is only appropriate if it is the sensor for that zone.

There is no simple means to learn the sensor for a zone, when that sensor is the controller - I do have some code for this, but it is only 'nearly-deterministic' and is currently disabled. That is, the only 'hard/fast' way to know which zone the controller is a sensor for (if any) is via an input schema (which we hope is 'true' to reality for the above reasons).

Note: evohome_rf track all controllers (i.e. systems) it sees, but by default the first controller seen is the controller, (unless the allow/block lists come into play) - The schema allows you to ensure that this is your controller.

You don't really need a schema, except for:

• to ID your controller (vs that of your neighbours)
• to ID the zone that the controller is a sensor for, everything else can be discovered for evohome (that doesn't apply for other RAMSES-based systems, like Sundial, etc.).

In fact, it is probably better to keep it minimal, rather than risk it being wrong:

    "schema": {
        "controller": "01:123456",
        "zones": {
            "07": {
                "sensor": "01:123456",
            }
        }
    }