New Device Support Request - eCozy Smart Heating Thermostat

[ddppddpp]

I'd like to request the integration of a automatic radiator valve (TRV) by eCozy, the 1TST.
Currently the device is visible via VNC, I'd ultimately like to use it in a hassio/deConz add-on/conbee setup.

Thanks in advance!

[SwoopX]

Can you please also add a screenshot of the node info panel and all available device clusters?

[ddppddpp]

Sure, here it is, more structured:
Node info:

Basic Cluster:

Power Configuration Cluster:

Identify Cluster:

Time Cluster:

Poll Control Cluster:

Thermostat Cluster 1/2

Thermostat Cluster 2/2

unknown cluster

Temperature measurement cluster:

[SwoopX]

Thanks! A misunderstanding though regarding the available clusters: I meant the device itself, where all the fancy lines are drawn. For your thermostat, there should be on the top right 2 black bullets. Clicking on the right most one should extend all available clusters.

[ddppddpp]

this one?

[SwoopX]

jep :)

Looks like some work has to be done to resolve the unknown cluster 0204, as this appears to be about the device configuration...

[Mimiix]

It seems this issue is resolved. If it is not, please re-open!

[ebaauw]

@honzakeller kindly provided me with an eCozy TRV, for integration into Homebridge-hue (see ebaauw/homebridge-hue#728).

However, there's also much to improve for REST API support of this device:

• Better support for on-device schedules:
  • deCONZ hangs when reading a schedule with more than one transition; Fixed.
  • I think times for the transitions should be specified using ISO(-ish) format "Wwww/Thh:mm", as for /schedules, instead of hard-coding the English weekday names;
• It contains an on-device real-time clock (obviously needed for the schedules), but it needs to be set initially (and I suppose after power cycle). Unfortunately, the GUI doesn't support the utc data type, so we need API support for this. Also, I think it might need to be set periodically, to prevent any drift (I don't yet know how precise the on-device real-time clock is). Edit It runs about 6 minutes too fast over 24h.
  I think we'd best create a ZHATime sensor type for the Time cluster, exposing the on-device clock through state.utc and state.localtime, using state.lastupdated to trace when the clock was last synced, and providing config.synchronized (ugly American English) to enable/disable clock synchronisation.
  Related to this: I think the built-in Daylight sensor should base its uniqueid on the Time cluster (so 00:21:2e:ff:ff:xx:xx:xx-01-000a instead of 00:21:2e:ff:ff:xx:xx:xx-01).
• GUI support for the commands: Set Weekly Schedule, Get Weekly Schedule, Clear Weekly Schedule, and Get Relay Status Log (although I don't think the eCozy supports the status log). Done Not sure if I can get the GUI to support the Get Weekly Schedule Response and Get Replay Status Log Response. Done with tip from @manup.
• Child lock (through the 0x0204 cluster);
• The TRV supports an external temperature sensor: bind the sensor's server Temperature measurement cluster to the TRV's endpoint (with the client cluster), and set the Remote Sensing attribute to 0x01. However, until the API provides better support for bindings, I don't think it makes sense to expose this attribute (since you need the GUI to create the binding anyways). It would be cool to set a config.external_sensor to a /sensors id and have the API create the binding.

[ebaauw]

For reference, to set the real-time clock using the CLI plugin

Find the hex utc value you want to set the time to, which is the number of seconds from Jan 1st, 2000:

$ node
Welcome to Node.js v12.18.3.
> Math.round((new Date('2020-07-25T12:25:00') - new Date('2000-01-01')) / 1000).toString(16)
'26aec4fc'

So in little-endian, the value is FCC4AE26.

Next, write the time to the TRV (in my case NWK 0x663c):

$ echo 'zclattr 0x663c 3 0x000a 020000E2FCC4AE26' | nc localhost 5008
zclattr 0x663c 3 0x000a 020000E2FCC4AE26
 --> send OK

[ebaauw]

Updated general.xml:

• Added commands and additional attributes to general.xml. You can now set, get, and clear the on-device schedule in the GUI. Note that you need a sniffer to see the response to Get Weekly Schedule.
• The eCozy actually keeps track of who (Manual, Scheduler, Zigbee) last changed the set point by how much and when. Unfortunately, the time seems to be reported in localtime instead of UTC, so the GUI displays the wrong time;
• Make sure Temperature Setpoint Hold is Off, or the on-device schedule is disabled.

Exposed Pi Heating Demand as state.valve.

Fixed the hang when processing a schedule with more than one transition.

[ebaauw]

Linked the Get Weekly Schedule Response to the Get Weekly Schedule. Thanks to @manup for providing the clue on how to do this.

[ebaauw]

I think I cracked syncing the on-device clock. Time cluster is exposed as ZHATime /sensors resource:

{
  "config": {
    "battery": 66,
    "on": true,
    "reachable": true
  },
  "ep": 3,
  "etag": "b3dfa008d9d6a957bee43567dd291a79",
  "lastseen": "2020-07-28T11:02Z",
  "manufacturername": "eCozy",
  "modelid": "Thermostat",
  "name": "Living Room Radiator 1",
  "state": {
    "lastset": "2020-07-28T11:02:25Z",
    "lastupdated": "2020-07-28T11:02:48.605",
    "localtime": "2020-07-28T13:02:47",
    "utc": "2020-07-28T11:02:46Z"
  },
  "swversion": "20160824eCozy967",
  "type": "ZHATime",
  "uniqueid": "70:b3:d5:de:00:00:14:2d-03-000a"
}

The API plugin polls the TRV for it's real-time clock and re-syncs it, when it's drifted more than 10 seconds. lastset indicates the time of the last sync. lastupdated indicates the time of the last poll. utc and localtime are the values reported by the Time cluster. utc and lastupdated shouldn't be more than 10 seconds apart.

On sync, I do set the other settable attributes, Time Status, Time Zone, Dst Start, Dst End, Dst Shift_ and Valid Until Time, but I see no use exposing these. localtime is based on the reported Local Time, so that would show if the time zone or DST setting are wrong.

[ebaauw]

Now exposing the Thermostat cluster of the eCozy as:

{
  "config": {
    "battery": 33,
    "heatsetpoint": 1600,
    "lastchange": {
      "amount": 200,
      "source": "schedule",
      "time": "2020-08-10T13:59:01Z"
    },
    "offset": 0,
    "on": true,
    "reachable": true,
    "schedule": {
      "W127": [
        {
          "heatsetpoint": 1500,
          "localtime": "T00:00"
        },
        {
          "heatsetpoint": 800,
          "localtime": "T08:00"
        },
        {
          "heatsetpoint": 900,
          "localtime": "T09:00"
        },
        {
          "heatsetpoint": 1000,
          "localtime": "T10:00"
        },
        {
          "heatsetpoint": 1200,
          "localtime": "T12:00"
        },
        {
          "heatsetpoint": 1400,
          "localtime": "T14:00"
        },
        {
          "heatsetpoint": 1600,
          "localtime": "T16:00"
        },
        {
          "heatsetpoint": 1800,
          "localtime": "T18:00"
        },
        {
          "heatsetpoint": 2000,
          "localtime": "T20:00"
        },
        {
          "heatsetpoint": 2200,
          "localtime": "T22:00"
        }
      ]
    },
    "schedule_on": true
  },
  "ep": 3,
  "etag": "5eae5cba59e1d9413c931bc1de0da9a4",
  "lastseen": "2020-08-10T14:33Z",
  "manufacturername": "eCozy",
  "modelid": "Thermostat",
  "name": "eCozy",
  "state": {
    "lastupdated": "2020-08-10T14:33:56.570",
    "on": false,
    "temperature": 3326,
    "valve": 0
  },
  "swversion": "20160826eCozy114",
  "type": "ZHAThermostat",
  "uniqueid": "70:b3:d5:de:00:00:0c:f0-03-0201"
}

I added support for following attributes:

• Temperature Setpoint Hold (0x0023): config.schedule_on;
• Setpoint Change Source (0x0030): config.lastchange.source, the values can be "manual" (using the on-device keys), "schedule", or "zigbee".
• Setpoint Change Amount (0x0031): config.lastchange.amount;
• _Setpoint Change Timestamp (0x0032): config.lastchange.time (in UTC).

I made sure that all the state and config attributes are reported and/or polled.

I don't think it makes sense to expose System Mode (0x001C) as config.mode - the eCozy doesn't seem to support anything but auto.

I refactored the logic to expose the on-device schedule as JSON instead of as a string. The code no longer clears the schedule when refreshing it; newly received Get Weekly Schedule Response messages are merged with the cached schedule. It now also handles multiple days in the response correctly.
The schedule is serialised as a string in the database, and converted to JSON on API output and web socket notifications.

I renamed config.scheduler and config.scheduleron to config.schedule and config.schedule_on. I don't particularly like the _ (would have preferred camelCase), but seems to be the API standard (cf. all_on, any_on, bri_inc, etc.).
The Wbbb keys in config.schedule are a bitmap for weekdays, same as for the localtime attribute in the /schedules resources. W64 is Monday, W32 Tuesday, W1 Sunday. W124 is weekdays, W3 is weekends.

I'm also polling the schedule, but the code still queues all seven request (one per weekday) at the same time. While that seems to work on my small test network, I keep losing requests on my production network.

Still todo: refactor logic to set schedule from the API. I think it makes most sense to expose a POST and DELETE on /sensors/idconfig/schudule/Wbbb, with (for POST) a body of the {"transitions": [...]}. This would overwrite (delete) the schedule for the days specified in the resource, but leave the other days alone.

Note that the eCozy firmware reports the first transitiontime in a schedule as T00:00, even though it does change the heatsetpoint on (or around) the scheduled time.

[ebaauw]

Still to do:

• Setting/updating/deleting the on-device schedule though the API;
• Double-checking that polling the schedule works on larger networks. The code now queues 7 Get Weekly Schedule commands (one for each weekday) in one go, rather than queueing the request for the next weekday on receipt of the response of the previous weekday.

[ebaauw]

Getting a segmentation fault in v2.05.80 when reading an old-version schedule from the database. The old-format schedule was stored using a development version of the REST API plugin; I don't think the crash could happen when reading a schedule stored by from v2.05.79 or earlier.

Better add some sanity checks anyway.

$ gdb /usr/bin/deCONZ core-deCONZ-sig11-user1000-group1000-pid2656-time1597505417
(...)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `/usr/bin/deCONZ --http-port=80 --dbg-info=2 --dbg-aps=2 --dbg-error=1'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x75fe247c in QString::split(QString const&, QString::SplitBehavior, Qt::CaseSensitivity) const ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
[Current thread is 1 (Thread 0x76fbea00 (LWP 2656))]
(gdb) bt
#0  0x75fe247c in QString::split(QString const&, QString::SplitBehavior, Qt::CaseSensitivity) const ()
   from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#1  0x6bd9d2e8 in DeRestPluginPrivate::deserialiseThermostatTransitions(QString const&, QList<QVariant>*) ()
   from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#2  0x6bd9eb3c in DeRestPluginPrivate::deserialiseThermostatSchedule(QString const&, QMap<QString, QVariant>*) ()
   from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#3  0x6bd5bf40 in DeRestPluginPrivate::sensorToMap(Sensor const*, QMap<QString, QVariant>&, ApiRequest const&) ()
   from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#4  0x6bd5cda4 in DeRestPluginPrivate::getAllSensors(ApiRequest const&, ApiResponse&) ()
   from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#5  0x6bd6d3a4 in DeRestPluginPrivate::handleSensorsApi(ApiRequest const&, ApiResponse&) ()
   from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#6  0x6bcc9dc0 in DeRestPlugin::handleHttpRequest(QHttpRequestHeader const&, QTcpSocket*) ()
   from /usr/share/deCONZ/plugins/libde_rest_plugin.so
#7  0x000bd06c in zmHttpClient::handleHttpRequest() ()
#8  0x7615fbfc in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5
#9  0x76402964 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Network.so.5
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[ebaauw]

Ok, I think I nailed setting and clearing the schedule through the API.

Starting from my favourite test schedule:

$ ph get /sensors/7/config/schedule
{
  "W127": [
    {
      "heatsetpoint": 1500,
      "localtime": "T00:00"
    },
    {
      "heatsetpoint": 800,
      "localtime": "T08:00"
    },
    {
      "heatsetpoint": 900,
      "localtime": "T09:00"
    },
    {
      "heatsetpoint": 1000,
      "localtime": "T10:00"
    },
    {
      "heatsetpoint": 1200,
      "localtime": "T12:00"
    },
    {
      "heatsetpoint": 1400,
      "localtime": "T14:00"
    },
    {
      "heatsetpoint": 1600,
      "localtime": "T16:00"
    },
    {
      "heatsetpoint": 1800,
      "localtime": "T18:00"
    },
    {
      "heatsetpoint": 2000,
      "localtime": "T20:00"
    },
    {
      "heatsetpoint": 2200,
      "localtime": "T22:00"
    }
  ]
}

Let's clear Mon-Thu:

$ ph delete -v /sensors/7/config/schedule/W120
[
  {
    "success": "/sensors/7/config/schedule/W120 deleted."
  }
]

The schedule now only contains Fri, Sat and Sun:

$ ph get /sensors/7/config/schedule
{
  "W7": [
    {
      "heatsetpoint": 1500,
      "localtime": "T00:00"
    },
    {
      "heatsetpoint": 800,
      "localtime": "T08:00"
    },
    {
      "heatsetpoint": 900,
      "localtime": "T09:00"
    },
    {
      "heatsetpoint": 1000,
      "localtime": "T10:00"
    },
    {
      "heatsetpoint": 1200,
      "localtime": "T12:00"
    },
    {
      "heatsetpoint": 1400,
      "localtime": "T14:00"
    },
    {
      "heatsetpoint": 1600,
      "localtime": "T16:00"
    },
    {
      "heatsetpoint": 1800,
      "localtime": "T18:00"
    },
    {
      "heatsetpoint": 2000,
      "localtime": "T20:00"
    },
    {
      "heatsetpoint": 2200,
      "localtime": "T22:00"
    }
  ]
}

Let's add Mon-Thu:

$ ph post -v /sensors/7/config/schedule/W120 '[
  {"localtime": "T00:00", "heatsetpoint": 1500},
  {"localtime": "T08:00", "heatsetpoint": 800},
  {"localtime": "T09:00", "heatsetpoint": 900},
  {"localtime": "T10:00", "heatsetpoint": 1000},
  {"localtime": "T12:00", "heatsetpoint": 1200},
  {"localtime": "T14:00", "heatsetpoint": 1400},
  {"localtime": "T16:00", "heatsetpoint": 1600},
  {"localtime": "T18:00", "heatsetpoint": 1800},
  {"localtime": "T20:00", "heatsetpoint": 2000},
  {"localtime": "T22:00", "heatsetpoint": 2200}
]'
[
  {
    "success": {
      "/config/schedule/W120": [
        {
          "heatsetpoint": 1500,
          "localtime": "T00:00"
        },
        {
          "heatsetpoint": 800,
          "localtime": "T08:00"
        },
        {
          "heatsetpoint": 900,
          "localtime": "T09:00"
        },
        {
          "heatsetpoint": 1000,
          "localtime": "T10:00"
        },
        {
          "heatsetpoint": 1200,
          "localtime": "T12:00"
        },
        {
          "heatsetpoint": 1400,
          "localtime": "T14:00"
        },
        {
          "heatsetpoint": 1600,
          "localtime": "T16:00"
        },
        {
          "heatsetpoint": 1800,
          "localtime": "T18:00"
        },
        {
          "heatsetpoint": 2000,
          "localtime": "T20:00"
        },
        {
          "heatsetpoint": 2200,
          "localtime": "T22:00"
        }
      ]
    }
  }
]

And back to the original 7-day schedule.

$ ph get /sensors/7/config/schedule
{
  "W127": [
    {
      "heatsetpoint": 1500,
      "localtime": "T00:00"
    },
    {
      "heatsetpoint": 800,
      "localtime": "T08:00"
    },
    {
      "heatsetpoint": 900,
      "localtime": "T09:00"
    },
    {
      "heatsetpoint": 1000,
      "localtime": "T10:00"
    },
    {
      "heatsetpoint": 1200,
      "localtime": "T12:00"
    },
    {
      "heatsetpoint": 1400,
      "localtime": "T14:00"
    },
    {
      "heatsetpoint": 1600,
      "localtime": "T16:00"
    },
    {
      "heatsetpoint": 1800,
      "localtime": "T18:00"
    },
    {
      "heatsetpoint": 2000,
      "localtime": "T20:00"
    },
    {
      "heatsetpoint": 2200,
      "localtime": "T22:00"
    }
  ]
}

Let's set a different schedule for Friday:

$ ph post -v /sensors/7/config/schedule/W4 '[
  {"localtime": "T00:05", "heatsetpoint": 1500},
  {"localtime": "T08:05", "heatsetpoint": 800},
  {"localtime": "T09:05", "heatsetpoint": 900},
  {"localtime": "T10:05", "heatsetpoint": 1000},
  {"localtime": "T12:05", "heatsetpoint": 1200},
  {"localtime": "T14:05", "heatsetpoint": 1400},
  {"localtime": "T16:05", "heatsetpoint": 1600},
  {"localtime": "T18:05", "heatsetpoint": 1800},
  {"localtime": "T20:05", "heatsetpoint": 2000},
  {"localtime": "T22:05", "heatsetpoint": 2200}
]'
[
  {
    "success": {
      "/config/schedule/W4": [
        {
          "heatsetpoint": 1500,
          "localtime": "T00:05"
        },
        {
          "heatsetpoint": 800,
          "localtime": "T08:05"
        },
        {
          "heatsetpoint": 900,
          "localtime": "T09:05"
        },
        {
          "heatsetpoint": 1000,
          "localtime": "T10:05"
        },
        {
          "heatsetpoint": 1200,
          "localtime": "T12:05"
        },
        {
          "heatsetpoint": 1400,
          "localtime": "T14:05"
        },
        {
          "heatsetpoint": 1600,
          "localtime": "T16:05"
        },
        {
          "heatsetpoint": 1800,
          "localtime": "T18:05"
        },
        {
          "heatsetpoint": 2000,
          "localtime": "T20:05"
        },
        {
          "heatsetpoint": 2200,
          "localtime": "T22:05"
        }
      ]
    }
  }
]

And we now have to weekly transition lists:

$ ph get /sensors/7/config/schedule
{
  "W123": [
    {
      "heatsetpoint": 1500,
      "localtime": "T00:00"
    },
    {
      "heatsetpoint": 800,
      "localtime": "T08:00"
    },
    {
      "heatsetpoint": 900,
      "localtime": "T09:00"
    },
    {
      "heatsetpoint": 1000,
      "localtime": "T10:00"
    },
    {
      "heatsetpoint": 1200,
      "localtime": "T12:00"
    },
    {
      "heatsetpoint": 1400,
      "localtime": "T14:00"
    },
    {
      "heatsetpoint": 1600,
      "localtime": "T16:00"
    },
    {
      "heatsetpoint": 1800,
      "localtime": "T18:00"
    },
    {
      "heatsetpoint": 2000,
      "localtime": "T20:00"
    },
    {
      "heatsetpoint": 2200,
      "localtime": "T22:00"
    }
  ],
  "W4": [
    {
      "heatsetpoint": 1500,
      "localtime": "T00:05"
    },
    {
      "heatsetpoint": 800,
      "localtime": "T08:05"
    },
    {
      "heatsetpoint": 900,
      "localtime": "T09:05"
    },
    {
      "heatsetpoint": 1000,
      "localtime": "T10:05"
    },
    {
      "heatsetpoint": 1200,
      "localtime": "T12:05"
    },
    {
      "heatsetpoint": 1400,
      "localtime": "T14:05"
    },
    {
      "heatsetpoint": 1600,
      "localtime": "T16:05"
    },
    {
      "heatsetpoint": 1800,
      "localtime": "T18:05"
    },
    {
      "heatsetpoint": 2000,
      "localtime": "T20:05"
    },
    {
      "heatsetpoint": 2200,
      "localtime": "T22:05"
    }
  ]
}

You'll also receive web socket notification for the new schedule:

Aug 16 13:14:12 pi6 dc_eventlog[632]: /sensors/7/config: {"schedule":{"W123":[{"heatsetpoint":1500,"localtime":"T00:00"},{"heatsetpoint":800,"localtime":"T08:00"},{"heatsetpoint":900,"localtime":"T09:00"},{"heatsetpoint":1000,"localtime":"T10:00"},{"heatsetpoint":1200,"localtime":"T12:00"},{"heatsetpoint":1400,"localtime":"T14:00"},{"heatsetpoint":1600,"localtime":"T16:00"},{"heatsetpoint":1800,"localtime":"T18:00"},{"heatsetpoint":2000,"localtime":"T20:00"},{"heatsetpoint":2200,"localtime":"T22:00"}],"W4":[{"heatsetpoint":1500,"localtime":"T00:00"},{"heatsetpoint":800,"localtime":"T08:05"},{"heatsetpoint":900,"localtime":"T09:05"},{"heatsetpoint":1000,"localtime":"T10:05"},{"heatsetpoint":1200,"localtime":"T12:05"},{"heatsetpoint":1400,"localtime":"T14:05"},{"heatsetpoint":1600,"localtime":"T16:05"},{"heatsetpoint":1800,"localtime":"T18:05"},{"heatsetpoint":2000,"localtime":"T20:05"},{"heatsetpoint":2200,"localtime":"T22:05"}]}}

[Miro1980]

Hello ebaauw,
really nice what you are doing with Rest API. I am also trying to set the schedule by using REST API. But it seems to be a great issue. I am using RESTClient-Firefox ( deconz-rest-plugin: swversion": "2.13.2"). GET works fine, but PUT does not work at all.
Perhaps you can provide a extended example for me.

This would be great.
Thanks a lot.

[Miro1980]

My Try:
URL: http://IP:Port/api/key/sensors/11/
Body:
{
"config": {

"schedule": {
  "W124": [{
    "heatsetpoint": 10,
    "localtime": "T07:08"
  }, {
    "heatsetpoint": 15,
    "localtime": "T10:11"
  }, {
    "heatsetpoint": 10,
    "localtime": "T13:02"
  }, {
    "heatsetpoint": 10,
    "localtime": "T14:03"
  }, {
    "heatsetpoint": 21,
    "localtime": "T21:00"
  }, {
    "heatsetpoint": 15,
    "localtime": "T22:00"
  }],
  "W3": [{
    "heatsetpoint": 20,
    "localtime": "T06:00"
  }, {
    "heatsetpoint": 21,
    "localtime": "T08:00"
  }, {
    "heatsetpoint": 15,
    "localtime": "T11:30"
  }, {
    "heatsetpoint": 15,
    "localtime": "T12:30"
  }, {
    "heatsetpoint": 20,
    "localtime": "T21:00"
  }, {
    "heatsetpoint": 15,
    "localtime": "T22:00"
  }],
},

}
}

USING - PUT: OUTPUT:
[{
"error": {
"address": "/sensors/11/config/schedule",
"description": "invalid value, , for parameter schedule",
"type": 7
}
}]

USING -POST: Output:
[{
"error": {
"address": "/sensors/11",
"description": "method, POST, not available for resource, /sensors/11",
"type": 4
}
}]

[SwoopX]

You guys need to read carefully :)

It requires a POST request to URL /sensors/7/config/schedule/<YOUR DAY BITMAP STARTING WITH W GOES HERE> and do not forget to change your sensor ID.