EvoControl - custom Alexa skill for Evohome

[philchillbill]

I've added a new error message for when you set up Domoticz to connect via the easy-ngrok updater script but fail to subsequently run the updater after running the installer. This leaves your URL at ''** will be updated by downloaded ngrok script **' in your account dashboard so you'll see that when you visit your HGI config page. That's clearly not a valid URL and so fails to connect, but the error message was generic so you might not spot the issue. Here's looking at you, Glyn

[bruce_miranda]

Surely 70 pages is long enough for a new thread to be created. You won't convince anyone to jump on board if they need to read 70 pages of how to start!

[philchillbill]

[bruce_miranda]

You love to tease us, don't you.

[philchillbill]

Cooking on gas now!

All the grief you're having today is because HA is returning null for your zone names via the API

"zones": {
                "00": {
                    "_name": null,
                    "class": "radiator_valve",
                    "sensor": "04:041296",
                    "actuators": [
                        "04:041296"
                    ]
                },
                "01": {
                    "_name": null,
                    "class": "radiator_valve",
                    "sensor": "34:259472",
                    "actuators": [
                        "04:041290",
                        "04:041302"
                    ]
                },
                "02": {
                    "_name": null,
                    "class": "radiator_valve",
                    "sensor": "04:045088",
                    "actuators": [
                        "04:045088"
                    ]
                },
                "03": {
                    "_name": null,
                    "class": "radiator_valve",
                    "sensor": "04:041710",
                    "actuators": [
                        "04:041710"
                    ]
                },
                "04": {
                    "_name": null,
                    "class": "radiator_valve",
                    "sensor": "04:041718",
                    "actuators": [
                        "04:041718",
                        "04:041720"
                    ]
                },
                "05": {
                    "_name": null,
                    "class": "radiator_valve",
                    "sensor": "04:041292",
                    "actuators": [
                        "04:041292"
                    ]
                },
                "06": {
                    "_name": null,
                    "class": "radiator_valve",
                    "sensor": "04:041874",
                    "actuators": [
                        "04:041874"
                    ]
                },
                "08": {
                    "_name": null,
                    "class": "radiator_valve",
                    "sensor": "04:041712",
                    "actuators": [
                        "04:041712"
                    ]
                }

[s.w.webb1]

Thanks- I made some edits in HA to zone names nd it’s not matching anymore. Tomorrow job to revert back….

[zxdavb]

What version of HA are you running? The results from the API for your climate.xxx entries look quite different to the results Bruce and I saw when beta-testing the HA integration.

The expected data has this form:

{
  "entity_id": "climate.bedroom",
  "state": "off",
  "attributes": {
    "current_temperature": 21,
    "temperature": 5,
    "hvac_action": "off",
    "preset_mode": "none",
    "zone_idx": "06",

...

while your HA is producing

 {
      "entity_id": "climate.guest_room",
      "state": "off",
      "attributes": {
        "current_temperature": 16.3,
        "temperature": 5,
        "preset_mode": "none",
        "status": {
          "setpoints": {
            "this_sp_from": "2023-07-25T10:00:00+01:00",
            "this_sp_temp": 5,
            "next_sp_from": "2023-07-25T17:00:00+01:00",
            "next_sp_temp": 5
          },
          "zone_id": "1234567",

...

so you are missing the mode subsection and the actual 1234567 Honeywell ID is showing for the zone instead of a ramses_cc 04:123456 id.

EDIT: To recover the missing appendages under the tiles, try asking "Alexa, reset the system mode" when inside the skill

Sorry for the delay in response (I don't check slack often - and I cannot tell why it doesn't alert me a message has been sent to me).

The confusion has a simple cause:
- climate.bedroom has a zone_idx property: it is from the ramses_cc integration
- climate.guest_room has a zone_id property: it is from the evohome integration

(you may have worked this out already - I haven't the all the subsequent messages)

[zxdavb]

David must have made a conscious choice to completely change the data-structure at some stage.

Nope. If I do something that drastic, I'll try to let you know.

[zxdavb]

ramses_cc has not had an update for a long time. But previously it was changing quite rapidly and often quite significantly.

It has had significant changes, I just haven't published them - will be doing so shortly enough - before Winter starts up again.

I have another theory about why there appear to be two different structures. It could be that this install had 2 different versions of ramses_cc installed over time.

As I said - it's evohome (the Web API) version state attrs. I don't think the alexia integration wants to deal with that, as it can query the RESTful API directly? However, maybe it does - there is some value-add in the sate attrs, e.g. (IIRC) with now/next setpoint?

[zxdavb]

All the grief you're having today is because HA is returning null for your zone names via the API

"zones": {
                "00": {
                    "_name": null,
                    "class": "radiator_valve",
                    "sensor": "04:041296",
                    "actuators": [
                        "04:041296"
                    ]
                },
                "01": {
                    "_name": null,

...

I have responded to s.webb in the HA forum... I suspect he was doing something inadvisable - it appears that he had a rather fat hand-crafted (aka 'input'/configured) schema. The configured schema should always be as thin as possible, usually only the controller ID, and maybe the OTB ID (as the appliance).

Phil: Be aware: the JSON key starts with an underscore - there is a reason for that. That is: the zone name is **not** part of the schema - it is actually a part of the params (like the zone setpoint/mode). Anything starting with an underscore is silently dropped before the YAML/JSON is used by ramses_rf.

So the _name is a convenience, to save people looking up the corresponding zone_idx in the params section of the state attrs...

Why his output schema has null for these values: dunno. I asked him to make some changes to his input schema.

Phil: if you're using JSON key names starting with an underscore: I suggest you stop - there is a 'supported' equivalent somewhere else in the state attrs.

[s.w.webb1]

Thanks - apologies for crossing forums - thought I was doing right by asking the questions on a ramses thread & not evocontrol.

I've just discovered a load of Honeywell integration entities in my HA setup which has caused the different structures. I never actually used the Honeywell integration on this HA instance (as per the ramses wiki) so I'm not sure how these came to exist unless it's some sort of auto detect thing with HA....

...still learning....

[philchillbill]

- climate.bedroom has a zone_idx property: it is from the ramses_cc integration
- climate.guest_room has a zone_id property: it is from the evohome integration

Now why didn't that occur to me? I make sure in the Domoticz integration to reject any devices that have hardwareTypeVal other than 39 which is a way of rejecting the non-RF Evohome integration but it never occurred to me that HA can of course also integrate via the WebAPI. Definitely don't want the skill using that route because it offers nothing over just talking directly to TCC. Thanks for the explanation!

[philchillbill]

It has had significant changes, I just haven't published them - will be doing so shortly enough - before Winter starts up again.

As I said - it's evohome (the Web API) version state attrs. I don't think the alexia integration wants to deal with that, as it can query the RESTful API directly? However, maybe it does - there is some value-add in the sate attrs, e.g. (IIRC) with now/next setpoint?

[philchillbill]

Phil: Be aware: the JSON key starts with an underscore - there is a reason for that. That is: the zone name is **not** part of the schema - it is actually a part of the params (like the zone setpoint/mode). Anything starting with an underscore is silently dropped before the YAML/JSON is used by ramses_rf.

So the _name is a convenience, to save people looking up the corresponding zone_idx in the params section of the state attrs...

Phil: if you're using JSON key names starting with an underscore: I suggest you stop - there is a 'supported' equivalent somewhere else in the state attrs.

I use the _name during what I call discovery which is where I find the correlation between the ramses_cc userdata and that in the TCC cloud.

Basically, I loop over all the known TCC zone names and look for a fuzzy-matched equivalent in the HA API data. Currently, I parse the binary_sensor.01_123456_schema and make sure all the TCC zone names also have an equivalent _name field somewhere in the schema. If there is a 1:1 match for all zones, the discovery succeeds and subsequently for determining state, I use the climate.xxxxxx entries returned by the API.

If you think it's safer, I can filter out all the climate entities that have a zone_idx (and as I now know, not a zone_id) and extract attributes.params.name as the name to check against TCC.

[philchillbill]

Why his output schema has null for these values: dunno. I asked him to make some changes to his input schema.

I see that when the _name in the schema is null then the corresponding climate.xxxxxx entity also has null in the attributes.params.name field. However, attributes.friendly_name is correctly populated.