Aqara Single Switch Module T1 (With Neutral)

[EarlOfBurton]

Device

• Product name: Aqara Single Switch Module T1 (With Neutral)
• Manufacturer: LUMI
• Model identifier: lumi.switch.n0agi1
• Device type : Please remove all unrelated device types.
  • Switch

Product page: https://www.aqara.com/en/single_switch_T1_with-neutral.html

Screenshots

Node

Basic

Phoscon

Device temperature configuration

02_device_temperature_configuration

Identify

Groups 1/2

Groups 2/2

Scenes 1/4

Scenes 2/4

Scenes 3/4

Scenes 4/4

On/Off 1/2

On/Off 2/2

Alarms

Time

Simple Metering 1/2

Simple Metering 2/2

Electrical Measurement

Lumi specific

OTAU

15 Home Automation On/Off

1F Home Automation On/Off

29 Home Automation On/Off

F2 Green Power

Home Automation On/Off

[Smanar]

Hello, It s not working natively ?
Or it create too much devices, or it s just because it miss power measurement ?

[EarlOfBurton]

Hi @Smanar, thanks for the reply. It is missing the simple metering and electrical measurement, as well as temperature and so on. The only feature that is on deconz is "on/off", that works. Kind regards.

[SwoopX]

Device temperature is not exposed via API. I highly doubt the simple metering and electrical measurement clusters are truly available and usable. Like I got to know Xiaomi, any power/consumption values are taken from the analog input (basic) clusters. You can verify that by turning the wtisch on and reading the attribute 0x0055 from both endpoints (double click on the value, then press read and not read config).

Additionally, we would need like 15 mins of log data, having info level 2 enabled. During that timeframe, please also make sure that you turn the the switch on and off a couple of times.

[EarlOfBurton]

Hello @SwoopX,
I did the logging, with INFO_L2 and ERROR_L2 activated. I hope that is what you need. Otherwise I could do a log run once more.
the device name is "aqara_t1_with_neutral_1" and there is no other device in this test (unless raspbee2).

Attached as load to the Aqara T1 is a 60 Watt "old school" bulb, so that there may come some useful reading out of the data.

I think the "at the moment" power measurement is in the "Electrical Measurement Cluster" as id 0x050B "Active Power" and needs to be divided by 10 to get the Watt-reading (maybe the id 0x0605 "AC Power Divisor" that reads "10" has that meaning.

The summation power over time that adds up is in the "Simple Metering Cluster", under id 0x000 "Current Summation Delivered", needs to be divided by 1000 (id "0x0302", "Divisor") and reads in kWh.

The hardware device has two terminals to add an external (old school) switch as well, that toggles the current "zigbee" state. I suppose this is so that you always can "hardware" switch or have a "smooth" transition from and old school installation to a smart home.
I also performed a few "on", "off", and "toggle" cycles via deCONZ via the "On/Off Cluster" at about timestamp 16:56:00.

I made a 20 seconds video clip (aqara_t1.mp4, see attached to this github-document) for you to see the test environment and the "external switch contacts" in action.

Also the log file is attached to this github-document as 20200217_deconz_log_aqara_single_switch_t1_with_neutral.txt-file, I hope this is how you like to have the raw data.
20200217_deconz_log_aqara_single_switch_t1_with_neutral.txt

aqara_t1.mp4

Thanks for all the work of you and your colleagues!
Kind regards

[SwoopX]

Thanks for providing the requested info. The results are ... rather unexpected.

Now first I'm really surprised to only see the on/off attribute reports, and literally nothing else. However, this might be related to the fact that Aqara and Mija ZB3.0 devices do seem to behave very differently and the Aqara's tending to more adhere to the expected zigbee behavior.

Can you please manually bind the simple metering, electrical measurement and lumi specific cluster as described in here https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/How-to...#manually-bind-server-clusters ? Then, please wait some minutes and take another log of 10 mins. The log settings are fine for the moment.

[EarlOfBurton]

Hi @SwoopX ,
I hope I set the manual bindings right.
If you needed/wanted, I could setup a remote vnc connection to this raspi/deconz via WAN. It is a test environment only, so it would be possible to "mess around".

Attached you will find the file 20210219_log_aqara_single_switch_t1_with_neutral.txt with INFO_L2 and ERROR_L2 activated as debug levels.

About 19:20:xx: Bound all three simple metering, electrical measurement and lumi specific
About 19:31:xx started logging with 60W classic light blub as load
About 19:33:xx switching light about 10x on and off with "onboard" button on the device
About 19:33:50 keeping the light off for one minute (to get different measurement values)
About 19:35:00 turning the light on and off with the "external switch terminals" about 10 times
About 19:35:50 keeping the light turned on for different measurement values
About 19:38:00 turning off/on/toggle via deCONZ about 10 times - "last state" of this session: "off"
About 19:38:50 keeping turning the light "on" via deCONZ for measurement values
About 19:45:00 turned light off for different values
About 19:48:00 logging ended

Kind regards.

20210219_log_aqara_single_switch_t1_with_neutral.txt

[github-actions]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[EarlOfBurton]

Bump to keep it alive.

[SwoopX]

Although I somehow doubt that it will make and difference, I peeked at z2m for this device. There it is handled pretty much standard, so I added the code for the power and consumption sensors to be created. The interesting part will be to see if anything will drip in or not.

[andudi]

I just tried the pull request #4660 above:

• my Aqara T1 Switch is now found as OnOff switch output
• the power/energy sensor is not found
• the input swiches are not found as well

is there some progress soon?
can this be improved in the plugin code? or must it be done in deconz itself?

thanks for clarify, I am willing to help if needed.

[SwoopX]

I got no clue what you're trying to say, except for the absent measurement sensors. Can you please share a screenshot of the lumi specific cluster?

[andudi]

@SwoopX I do not have screenshots, but I have some console results for now:

I captured the binding process with the CLI plugin, it looks like this:

<-EP 0x0149 0x0149 1 (01)
<-EP 0x0149 0x0149 41 (29)
<-EP 0x0149 0x0149 21 (15)
<-EP 0x0149 0x0149 31 (1F)
<-EP 0x0149 0x0149 242 (F2)
<-CLUSTER 0x0149 0x0149 ep 0x01 profile 0x0104 deviceid 0x0100 deviceversion 0x01
<-CLUSTER 0x0149 0x0149 0x01 In 0x0000 BASIC_CLUSTER_ID
<-CLUSTER 0x0149 0x0149 0x01 In 0x0002 unknown
<-CLUSTER 0x0149 0x0149 0x01 In 0x0003 IDENTIFY_CLUSTER_ID
<-CLUSTER 0x0149 0x0149 0x01 In 0x0004 GROUPS_CLUSTER_ID
<-CLUSTER 0x0149 0x0149 0x01 In 0x0005 SCENES_CLUSTER_ID
<-CLUSTER 0x0149 0x0149 0x01 In 0x0006 ONOFF_CLUSTER_ID
<-CLUSTER 0x0149 0x0149 0x01 In 0x0009 ALARMS_CLUSTER_ID
<-CLUSTER 0x0149 0x0149 0x01 In 0x000A TIME_CLUSTER_ID
<-CLUSTER 0x0149 0x0149 0x01 In 0x0702 SIMPLE_METERING_CLUSTER_ID
<-CLUSTER 0x0149 0x0149 0x01 In 0x0B04 unknown
<-CLUSTER 0x0149 0x0149 0x01 In 0xFCC0 unknown
<-CLUSTER 0x0149 0x0149 0x01 Out 0x0019 OTAU_CLUSTER_ID
<-CLUSTER 0x0149 0x0149 ep 0x29 profile 0x0104 deviceid 0x0100 deviceversion 0x01
<-CLUSTER 0x0149 0x0149 0x29 In 0x0012 unknown
<-APS attr 0x0149 1 0x0000 0x0005 0x42 lumi.switch.n0agl1
<-ZCL serverToClient 0x0149 1 for cluster 0x0004 8A F0 FF
<-APS attr 0x0149 1 0x0000 0x0005 0x42 lumi.switch.n0agl1
<-APS attr 0x0149 1 0x0000 0x0006 0x42 Aug 8 2020
<-CLUSTER 0x0149 0x0149 ep 0x15 profile 0x0104 deviceid 0x0100 deviceversion 0x01
<-CLUSTER 0x0149 0x0149 0x15 In 0x000C unknown
<-CLUSTER 0x0149 0x0149 ep 0x1F profile 0x0104 deviceid 0x0100 deviceversion 0x01
<-CLUSTER 0x0149 0x0149 0x1F In 0x000C unknown
<-ZCL serverToClient 0x0149 1 for cluster 0x0004 FF 01 F0 FF
<-CLUSTER 0x0149 0x0149 ep 0xF2 profile 0xA1E0 deviceid 0x0061 deviceversion 0x01
<-CLUSTER 0x0149 0x0149 0xF2 Out 0x0021 unknown
<-BIND 0x0149 1 0 1 0x54EF44100009DACE 0x01 0x0000 0xFFF0
<-LQI 0x0000 01 0 1 0x54EF44100009DACE 0x0149 1 1 2 00 01 FF
<-LQI 0x0000 01 0 1 0x54EF44100009DACE 0x0149 1 1 2 00 01 FF
<-LQI 0x0000 01 0 1 0x54EF44100009DACE 0x0149 1 1 2 00 01 FF

It looks similar than what can be found in the deCONZ pictures of @EarlOfBurton above, the onoff cluster is present as well as the 0x0702 metering cluster and the interesting 0x0B04 power cluster.

Then I read sensors and ligths with the rest plugin:
"3" : {
"etag" : "65a6f4b3fc50490aa4ea80d35eb578f7",
"hascolor" : false,
"lastannounced" : null,
"lastseen" : "2021-04-14T16:40Z",
"manufacturername" : "LUMI",
"modelid" : "lumi.switch.n0agl1",
"name" : "On/Off light 3",
"state" : {
"alert" : "none",
"on" : false,
"reachable" : true
},
"swversion" : "Aug 8 2020",
"type" : "On/Off light",
"uniqueid" : "54:ef:44:10:00:09:da:ce-01"
}

One new entry in the lights list, but no new sensors are bound yet!!!

Swtich on/off is already possible by button, device switch, with REST and even with Phoscon.

At every switch, the new state is sent to the gate and can be shown with the REST or CLI:

<-LQI 0x0000 01 0 1 0x54EF44100009DACE 0x0149 1 1 2 00 01 FF
<-ZCL attribute report 0x0149 0x0006 1 00 00 10 01
->ZCL default response seq id 0x09 command id 0x0A, status 0x00
<-LQI 0x0000 01 0 1 0x54EF44100009DACE 0x0149 1 1 2 00 01 FF
<-LQI 0x0000 01 0 1 0x54EF44100009DACE 0x0149 1 1 2 00 01 FF
<-ZCL attribute report 0x0149 0x0006 1 00 00 10 00
->ZCL default response seq id 0x0A command id 0x0A, status 0x00
<-LQI 0x0000 01 0 1 0x54EF44100009DACE 0x0149 1 1 2 00 01 FF

Then I sent the "read attribute" command to the interesting power cluster 0x0B04 (the gate is still open):

$ echo "r 0x0149 1 0x0B04 0x050B" | nc localhost 5008
r 0x0149 1 0x0B04 0x050B
--> send OK
<-APS attr 0x0149 1 0x0B04 0x050B 0x29 28 00
<-LQI 0x0000 01 0 1 0x54EF44100009DACE 0x0149 1 1 2 00 01 FF
<-APS attr 0x0149 1 0x0B04 0x0505 0x08 05 86 0B 05 00 29 28 00
<-APS attr 0x0149 1 0x0702 0x0000 0x25 00 00 00 00 00 00 00 04 86
<-APS attr 0x0149 1 0x0B04 0x050B 0x29 28 00
<-APS attr 0x0149 1 0x0702 0x0000 0x25 00 00 00 00 00 00
<-APS attr 0x0149 1 0x0B04 0x050B 0x29 28 00
<-APS attr 0x0149 1 0x0702 0x0000 0x25 00 00 00 00 00 00
<-APS attr 0x0149 1 0x0702 0x0000 0x25 00 00 00 00 00 00
<-APS attr 0x0149 1 0x0B04 0x050B 0x29 28 00
<-APS attr 0x0149 1 0x0702 0x0000 0x25 00 00 00 00 00 00
<-LQI 0x0000 01 0 1 0x54EF44100009DACE 0x0149 1 1 2 00 01 FF
<-APS attr 0x0149 1 0x0B04 0x050B 0x29 28 00
<-ZCL attribute report 0x0149 0x0006 1 00 00 10 00
->ZCL default response seq id 0x0E command id 0x0A, status 0x00
<-APS attr 0x0149 1 0x0702 0x0000 0x25 00 00 00 00 00 00
<-APS attr 0x0149 1 0x0B04 0x050B 0x29 00 00
<-APS attr 0x0149 1 0x0702 0x0000 0x25 00 00 00 00 00 00
<-APS attr 0x0149 1 0x0B04 0x050B 0x29 00 00
<-ZCL attribute report 0x0149 0x0006 1 00 00 10 01
->ZCL default response seq id 0x0F command id 0x0A, status 0x00
<-APS attr 0x0149 1 0x0702 0x0000 0x25 00 00 00 00 00 00
<-APS attr 0x0149 1 0x0B04 0x050B 0x29 28 00
<-APS attr 0x0149 1 0x0702 0x0000 0x25 00 00 00 00 00 00
<-APS attr 0x0149 1 0x0B04 0x050B 0x29 28 00

From now, the device sends its power (0x0B04) and total energie (0x0702) from itself perjodically (ca 2sec) as well as the switch state when changed.

You can see the power is changing from 0028 (=40dez = 4.0W) to 0000 (0W) when switching off and back to 28 when switching on.

Now lets see the sensors table in the REST API:

"11" : {
"config" : {
"battery" : null,
"on" : true,
"reachable" : true,
"temperature" : null
},
"ep" : 1,
"etag" : "afb6c2422921b344de69aeff940911dc",
"lastseen" : "2021-04-14T16:47Z",
"manufacturername" : "LUMI",
"modelid" : "lumi.switch.n0agl1",
"name" : "Power 11",
"state" : {
"current" : null,
"lastupdated" : "2021-04-14T16:47:01.293",
"power" : 40,
"voltage" : null
},
"type" : "ZHAPower",
"uniqueid" : "54:ef:44:10:00:09:da:ce-01-0b04"
},

Again, the actual power is 4.0W, the factor can be found in another attribute to 1/10.

Another REST sensor show the total energy in kWh, but it is reseted at every restart of the device...

My conclusion:

• the metering devices can be bound while reading one of the hidden attributes during the gate is open
• even when the REST API is showing the meters, Phoscon App do not! (yet?)
• when failing, place the antenna very close to the gate

[SwoopX]

Ah, shxx. That one is on me. Forgot that the Xiaomi's are excluded from the automatic bindings.

Another REST sensor show the total energy in kWh, but it is reseted at every restart of the device...

Interesting. My smart plug keeps the values even after a device reset. However, I assume the divisor for the consumption is correct, so that doesn't require any changes and the values are in Wh already.

even when the REST API is showing the meters, Phoscon App do not! (yet?)

Correct. Phoscon doesn't show any power/consumption in general.

[cobch]

I have installed the aqara switch module T1 today but no report of power in deconz. What is the status of power report in deconz? I am running HA via raspberry pi.

[andudi]

Am Montag, 27. Dezember 2021, 19:31:49 CET schrieb cobch:

I have installed the aqara switch module T1 today but no report of power in deconz. What is the status of power report in deconz? I am running HA via raspberry pi.

I can just say that it works for me but I use my own home system. I read/write to the deconz direct over the REST API by curl commands. But in Phoscon the Power Sensor is not shown, just the (Light)Switch. Maybe the feature is only available in low level access?

[cobch]

@andudi I first did not make the correct wiring and that was why the power did not report correctly... I manage to installed the switch and even the power off memory so it is automatically on after a power outage. Thanks for your help (-:

[MrStrategy]

I would also like to know how to get power and energy via the rest interface,
Unfortunately I'm not so much in the details to fully understand everything discussed within this thread.

Actually I'm using the deconz / phoscon applications to bring Xiaomi (and other zigbee) devices into my home automation.
I'm using the rest interface to gather all the needed data. And it works quite well for all the deviced I used so far (mainly temperature sensors and some lights)

In my current setup I'm interacting with the Phoscon frontend to add the devices and to manage them.
I can do the same with the Aqara SSM-U01 and it is added as a On/Off switch in the lights section. This seems to be correct according to what i read so far,

Now I try to summarize what I read in this thread:

1. The power / energy monitoring will never show up in phoscon as it is not intended to be shown there.
   The phoscon app is an abstraction layer above deconz focusing on light control. So the sensor data of power and energy is not there.

2. The REST API contains the data based on the underlying deconz system. If the sensors data is defined within deconz it should be available in the REST API even if it does not show up in phoscon.
   (In my scenario there is no additional sensor data in the REST messages and the light message does not contain any data with regards to energy / power.)

3. @SwoopX stated:

Ah, shxx. That one is on me. Forgot that the Xiaomi's are excluded from the automatic bindings.

Does this mean the process by simply adding the sensor via Phoscon is not sufficient to get the power / energy data in the REST API? Do I need to open up the deconz app and expose the specific measurements there?

I'm currently running the deconz app headless (platform minimal) and there was no need till now to use the deconz itself. So i do have no experience and cannot quickly validate my assumptions.
Maybe some ou you experts can confirm above or give me some tips how to proceed?

Thanks.

[andudi]

hei Matthias I used the following CURL syntax on my raspi: # first I define some shortcuts: $ path=localhost:80/api/<application ID> $ format="json_pp -json_opt pretty,canonical" # now I can get the config: curl $path/config | $format # and the list of lights: $ curl $path/lights | $format { "1" : { ... }, "2" : { "etag" : "dd48815737a735c8c840123f30e326b4", "hascolor" : false, "lastannounced" : "2022-01-06T21:13:34Z", "lastseen" : "2022-01-24T19:28Z", "manufacturername" : "LUMI", "modelid" : "lumi.switch.n0agl1", "name" : "On/Off light 2", "state" : { "alert" : "none", "on" : false, "reachable" : true }, "swversion" : "Aug 8 2020", "type" : "On/Off light", "uniqueid" : "54:eg:77:10:00:09:da:ce-01" }, } # I can now switch on/off the switch like $ curl -X PUT $path/lights/2/state -d '{"on":true}' | $format # and I can read out the sensor states with energy consumption and actual power curl $path/sensors | $format { "12" : { "config" : { "on" : true, "reachable" : true, "temperature" : 0 }, "ep" : 1, "etag" : "1774c82ed1c27f12392d945029c88d26", "lastannounced" : "2022-01-06T21:13:34Z", "lastseen" : "2022-01-24T19:30Z", "manufacturername" : "LUMI", "modelid" : "lumi.switch.n0agl1", "name" : "Consumption 12", "state" : { "consumption" : 548, "lastupdated" : "2022-01-24T19:30:38.874" }, "swversion" : "Aug 8 2020", "type" : "ZHAConsumption", "uniqueid" : "54:eg:77:10:00:09:da:ce-01-0702" }, "13" : { "config" : { "on" : true, "reachable" : true, "temperature" : 0 }, "ep" : 1, "etag" : "8707559f80087435bba8123a4bca4a46", "lastannounced" : "2022-01-06T21:13:34Z", "lastseen" : "2022-01-24T19:30Z", "manufacturername" : "LUMI", "modelid" : "lumi.switch.n0agl1", "name" : "Power 13", "state" : { "lastupdated" : "2022-01-24T19:30:38.912", "power" : 0 }, "swversion" : "Aug 8 2020", "type" : "ZHAPower", "uniqueid" : "54:eg:77:10:00:09:da:ce-01-0b04" }, } since the consumption is resetting while rebooting the device, I think it is not really interesting feature, but to know the actual power can be nice Andreas Am Freitag, 21. Januar 2022, 14:06:36 CET schrieb Matthias:

…

I would also like to know how to get power and energy via the rest interface, Unfortunately I'm not so much in the details to fully understand everything discussed within this thread. Actually I'm using the deconz / phoscon applications to bring Xiaomi (and other zigbee) devices into my home automation. I'm using the rest interface to gather all the needed data. And it works quite well for all the deviced I used so far (mainly temperature sensors and some lights) In my current setup I'm interacting with the Phoscon frontend to add the devices and to manage them. I can do the same with the Aqara SSM-U01 and it is added as a On/Off switch in the lights section. This seems to be correct according to what i read so far, Now I try to summarize what I read in this thread: 1. The power / energy monitoring will never show up in phoscon as it is not intended to be shown there. The phoscon app is an abstraction layer above deconz focusing on light control. So the sensor data of power and energy is not there.

[MrStrategy]

Hey Andreas,

thanks for sharing the feedback and the actual code.
Unfortunately I could not get it to work with the commands you provided but I finally found a solution:

1. Connect the aqara switch via Phoscon web frontend to deconz (this is what I always do).
2. Open up deCONZ GUI and perform the read commands on the nodes 0x0B04 and 0x0702 as you have recommended it earlier in this thread I already get some values in deCONZ with regards to power and consumption.
3. Checking the API via commandline or phoscon showed no power or consumption readings.
4. This did the trick for me: Open phoscon app again and search for Sensors -> Others.
   The search ended showing the green message new sensors were found. No new sensors are shown in Phoscon but the readings for power and consumption are now available in the REST API...

I'm not sure if step 3 is really necessary, but I do have only 3 devices and it took me some hours to figure out the actual process. For the first two devices I got the data rather by accident and on the third device I finally found above process.

It would be nice if someone else with the same problem could confirm the process and also check if step 3 is really necessary...

BR
Matthias

[andudi]

cool if you found a solution. I recently buyed a second device, and it just worked after binding with the Phoscon web frontend without problems, the sensors are just shown in the REST API like the first one...

[Smanar]

It's more complicated on HA ^^ yes, but I have the command line to use in a link to the forum to add a DDF for HA.
But the problem is more to create it #4328 (comment)

I don't want to start from scratch for this one, if you can at least share screen capture on the auto generated DDF, it will help me.
In the GUI, select the node, make "edit DDF" and go in tab "preview" you will not be able to make copy/paste, but even screen capture can help me.

Or easier we can complete your DDF.
Check if you have a ZHAPower field, and if you have inside current, power or other missing field.
First need to check if you have a missing or a not working field.

I tried to change DDF by clicking Edit DDF on device but I cannot find any DDF when browsing for them

Yes, it's normal, but deconz will auto generate an incomplete one, but used as squeleton.

For information we will mimic this one https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/xiaomi/xiaomi_zncz04lm_smart_plug_v24.json

[flopp999]

It's more complicated on HA ^^ yes, but I have the command line to use in a link to the forum to add a DDF for HA. But the problem is more to create it #4328 (comment)

I don't want to start from scratch for this one, if you can at least share screen capture on the auto generated DDF, it will help me. In the GUI, select the node, make "edit DDF" and go in tab "preview" you will not be able to make copy/paste, but even screen capture can help me.

Or easier we can complete your DDF. Check if you have a ZHAPower field, and if you have inside current, power or other missing field. First need to check if you have a missing or a not working field.

I tried to change DDF by clicking Edit DDF on device but I cannot find any DDF when browsing for them

Yes, it's normal, but deconz will auto generate an incomplete one, but used as squeleton.

For information we will mimic this one https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/xiaomi/xiaomi_zncz04lm_smart_plug_v24.json

I can complete it but I will upload hoe it looks now

{
  "schema": "devcap1.schema.json",
  "manufacturername": "$MF_LUMI",
  "modelid": "lumi.switch.n0agl1",
  "product": "lumi.switch.n0agl1",
  "sleeper": false,
  "status": "Draft",
  "subdevices": [
    {
      "type": "$TYPE_ON_OFF_LIGHT",
      "restapi": "/lights",
      "uuid": [
        "$address.ext",
        "0x01"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "state/alert",
          "description": "The currently active alert effect.",
          "default": "none"
        },
        {
          "name": "state/on",
          "description": "True when device is on; false when off.",
          "refresh.interval": 5
        },
        {
          "name": "state/reachable"
        }
      ]
    },
    {
      "type": "$TYPE_POWER_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0b04"
      ],
      "fingerprint": {
        "profile": "0x0104",
        "device": "0x0100",
        "endpoint": "0x01",
        "in": [
          "0x0000",
          "0x0B04"
        ]
      },
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/power",
          "description": "The measured power (in W).",
          "refresh.interval": 300,
          "default": 0
        }
      ]
    },
    {
      "type": "$TYPE_CONSUMPTION_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0702"
      ],
      "fingerprint": {
        "profile": "0x0104",
        "device": "0x0100",
        "endpoint": "0x01",
        "in": [
          "0x0000",
          "0x0702"
        ]
      },
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/consumption",
          "description": "The measured consumption (in Wh).",
          "refresh.interval": 300,
          "default": 0
        },
        {
          "name": "state/lastupdated"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0006",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x10",
          "min": 1,
          "max": 300
        }
      ]
    },
    {
      "bind": "groupcast",
      "config.group": 195,
      "src.ep": 1,
      "cl": "0x0B04"
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0B04"
    }
  ]
}

[Smanar]

I can complete it but I will upload hoe it looks now

How you have do that ? the copy/paste don't work on HA ...

So I presume you have the same device than here #4328 (comment) ? So I m using same cluster (0x000C) and endpoint (0x15 and 0x1F)

{
  "schema": "devcap1.schema.json",
  "manufacturername": "$MF_LUMI",
  "modelid": "lumi.switch.n0agl1",
  "product": "lumi.switch.n0agl1",
  "matchexpr": "R.endpoints.includes(0x15) && R.endpoints.includes(0x1F)",
  "sleeper": false,
  "status": "Gold",
  "subdevices": [
    {
      "type": "$TYPE_ON_OFF_LIGHT",
      "restapi": "/lights",
      "uuid": [
        "$address.ext",
        "0x01"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "state/alert",
          "default": "none"
        },
        {
          "name": "state/on",
          "refresh.interval": 5
        },
        {
          "name": "state/reachable"
        }
      ]
    },
     {
      "type": "$TYPE_POWER_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x15",
        "0x000C"
      ],
      "fingerprint": {
        "profile": "0x0104",
        "device": "0x0051",
        "endpoint": "0x15",
        "in": [
          "0x000C"
        ]
      },
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "config/temperature"
        },
        {
          "name": "state/current",
          "parse": {
            "at": "0x00F7",
            "eval": "Item.val = Math.round(Attr.val);",
            "fn": "xiaomi:special",
            "idx": "0x97"
          },
          "read": {
            "fn": "none"
          }
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/power",
          "refresh.interval": 10,
          "read": {
            "at": "0x0055",
            "cl": "0x000C",
            "ep": 21,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0055",
            "cl": "0x000C",
            "ep": 21,
            "eval": "Item.val = Math.round(Attr.val);"
          }
        },
        {
          "name": "state/voltage",
          "parse": {
            "at": "0x00F7",
            "eval": "Item.val = Math.round(Attr.val / 10);",
            "fn": "xiaomi:special",
            "idx": "0x96"
          },
          "read": {
            "fn": "none"
          }
        }
      ]
    },
    {
      "type": "$TYPE_CONSUMPTION_SENSOR",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x1F",
        "0x000C"
      ],
      "fingerprint": {
        "profile": "0x0104",
        "device": "0x0051",
        "endpoint": "0x1F",
        "in": [
          "0x000C"
        ]
      },
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "config/temperature"
        },
        {
          "name": "state/consumption",
          "refresh.interval": 300,
          "read": {
            "at": "0x0055",
            "cl": "0x000C",
            "ep": 31,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0055",
            "cl": "0x000C",
            "ep": 31,
            "eval": "Item.val = Math.round(Attr.val * 1000);"
          }
        },
        {
          "name": "state/lastupdated"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0006",
      "report": [
        {
          "at": "0x0000",
          "dt": "0x10",
          "min": 1,
          "max": 300
        }
      ]
    }
  ]
}

To install it you can use the hidden folder in the "data" docker folder (it's a persistent one)
/data/.local/share/dresden-elektronik/deCONZ/devices/

Long story here https://forum.phoscon.de/t/how-to-add-edit-a-ddf-on-home-assistant-using-text-editor/1839

I have added a check
"matchexpr": "R.endpoints.includes(0x15) && R.endpoints.includes(0x1F)",

To don't broke your previous device, but if your device don't have endpoint 0x15 and 0x1F the DDF will be not used.

[flopp999]

How you have do that ? the copy/paste don't work on HA ...
I run VNC directly to deCONZ GUI on port 5900
picture from Configuration

[flopp999]

Thanks.
I have finally added the text into a file in that folder.
I selected my device and Edit DDF, open the new JSON and clicked "Hot reload".

Now I need to wait I guess?

[flopp999]

After I restarted deCONZ today it seems that it uses the old JSON and the one I selected yesterday

[Smanar]

The auto generated one ?
You can't delete it ? There is a priority list, some folder are prioritary on other.

Else you can just make "hot relaod" it will be active immediatly (up you restart deconz) else you will have an error message if you can't load it.

[flopp999]

The auto generated one ? You can't delete it ? There is a priority list, some folder are prioritary on other.
Yes the auto generated one.

Else you can just make "hot relaod" it will be active immediatly (up you restart deconz) else you will have an error message if you can't load it.

Will try to hot reload with the new JSON I uploaded and see what happens.
I have deleted the device, maybe that was wrong :)

[flopp999]

this is how I do
Edit DDF
Open new file DDF JSON
check in Preview and I see that it has been updated and I see the name of the JSON
File -> Hot reload
I see DDF reloaded for devices

Next time I press Edit DDF on the same device, as I just did above on, it will be back to the auto generated

Could this be user rights for the new JSON or any other user rights for other files?

[Smanar]

Could this be user rights for the new JSON or any other user rights for other files?

I think you will an error message.
But you forget to save your change before making "hot relaod" ?

It seems that it needs a file named xiaomi_firmware.json

Yeah, good catch, I don't found the file neither, without it the swversion will be bugged, but it don't prevent the device working.
The DDf need to use the file "xiaomi_swversion.js" instead (but need too to be in "Xiaomi" folder, so will see later)

[flopp999]

I now tried
Edit DDF
Open new JSON
Check Preview and it looks correct
Clicked Save
Hot Reload

But next time I click on Edit DDF it will not open the new JSON it will open an Untitled file

[flopp999]

I have two old of the same device that works with the auto generated DDF.
I found below data in ZLL.db

("sid", "name", "type", "modelid", "manufacturername", "uniqueid", "swversion", "state", "config", "fingerprint", "deletedState", "mode", "lastseen", "lastannounced") VALUES ('61', 'Power 61', 'ZHAPower', 'lumi.switch.n0agl1', 'LUMI', '04:cf:8c:df:3c:8e:40:61-01-0b04', 'Aug 8 2020', '{"lastupdated":"2022-11-03T17:36:43.984","power":0}', '{"on":true,"reachable":true}', '{"d":256,"ep":1,"in":[0,2820],"p":260}', 'normal', '1', '2022-11-03T17:36Z', '2022-10-27T12:53:32Z');
("sid", "name", "type", "modelid", "manufacturername", "uniqueid", "swversion", "state", "config", "fingerprint", "deletedState", "mode", "lastseen", "lastannounced") VALUES ('79', 'Consumption 79', 'ZHAConsumption', 'lumi.switch.n0agl1', 'LUMI', '54:ef:44:10:00:09:bd:c3-01-0702', 'Aug 8 2020', '{"consumption":5169,"lastupdated":"2022-11-03T17:36:04.450"}', '{"on":true,"reachable":true}', '{"d":256,"ep":1,"in":[0,1794],"p":260}', 'normal', '1', '2022-11-03T17:36Z', '2022-09-02T18:34:25Z');
("sid", "name", "type", "modelid", "manufacturername", "uniqueid", "swversion", "state", "config", "fingerprint", "deletedState", "mode", "lastseen", "lastannounced") VALUES ('80', 'Power 80', 'ZHAPower', 'lumi.switch.n0agl1', 'LUMI', '54:ef:44:10:00:09:bd:c3-01-0b04', 'Aug 8 2020', '{"lastupdated":"2022-11-03T17:36:04.451","power":10}', '{"on":true,"reachable":true}', '{"d":256,"ep":1,"in":[0,2820],"p":260}', 'normal', '1', '2022-11-03T17:36Z', '2022-09-02T18:34:25Z');
("sid", "name", "type", "modelid", "manufacturername", "uniqueid", "swversion", "state", "config", "fingerprint", "deletedState", "mode", "lastseen", "lastannounced") VALUES ('51', 'Consumption 51', 'ZHAConsumption', 'lumi.switch.n0agl1', 'LUMI', '04:cf:8c:df:3c:8e:40:61-01-0702', 'Aug 8 2020', '{"consumption":3127,"lastupdated":"2022-11-03T17:37:40.716"}', '{"on":true,"reachable":true}', '{"d":256,"ep":1,"in":[0,1794],"p":260}', 'normal', '1', '2022-11-03T17:36Z', '2022-10-27T12:53:32Z');

[flopp999]

Is there a file where I can see what DDF a device is assigned to?

[Smanar]

Is there a file where I can see what DDF a device is assigned to?

Yes I think it's probably the issue.
Enable logs with "info" and "ddf", or just "ddf" (in deconz/help/debug view/)
And make hor reload, you will see if a DDF is found for the device.

I think the DDF don't matche the devices, can you take a look if there is not a typo here.

  "manufacturername": "LUMI",
  "modelid": "lumi.switch.n0agl1",
  "matchexpr": "R.endpoints.includes(0x15) && R.endpoints.includes(0x1F)",

You need to have "LUMI", "lumi.switch.n0agl1" and the endpoint 0x15 and 0x1F

[flopp999]

Yes I think it's probably the issue. Enable logs with "info" and "ddf", or just "ddf" (in deconz/help/debug view/) And make hor reload, you will see if a DDF is found for the device.

This I got when I pressed Edit DDF

failed to evaluate matchexpr for 54:ef:44:10:00:19:31:1b: R.endpoints.includes(0x15) && R.endpoints.includes(0x1F), err: TypeError: Property 'includes' of object 1,21,31,41,242 is not a function

then I pressed Save and then when I pressed Hot reload I got this:

10:39:15:055 failed to evaluate matchexpr for 04:cf:8c:df:3c:78:8b:4c: R.endpoints.includes(0x15) && R.endpoints.includes(0x1F), err: TypeError: Property 'includes' of object 1,242 is not a function
10:39:15:061 failed to evaluate matchexpr for 04:cf:8c:df:3c:8e:40:61: R.endpoints.includes(0x15) && R.endpoints.includes(0x1F), err: TypeError: Property 'includes' of object 1,21,31,41,242 is not a function
10:39:15:066 failed to evaluate matchexpr for 54:ef:44:10:00:09:bd:c3: R.endpoints.includes(0x15) && R.endpoints.includes(0x1F), err: TypeError: Property 'includes' of object 1,21,31,41,242 is not a function
10:39:15:073 failed to evaluate matchexpr for 54:ef:44:10:00:19:31:1b: R.endpoints.includes(0x15) && R.endpoints.includes(0x1F), err: TypeError: Property 'includes' of object 1,21,31,41,242 is not a function
10:39:15:079 failed to evaluate matchexpr for 54:ef:44:10:00:18:59:09: R.endpoints.includes(0x15) && R.endpoints.includes(0x1F), err: TypeError: Property 'includes' of object 1,41,21,31,242 is not a function
10:39:15:083 failed to evaluate matchexpr for 54:ef:44:10:00:18:59:83: R.endpoints.includes(0x15) && R.endpoints.includes(0x1F), err: TypeError: Property 'includes' of object 1,41,21,31,242 is not a function

[flopp999]

No typo except "$MF_" but I think that is an variable right?

"schema": "devcap1.schema.json",
  "manufacturername": "$MF_LUMI",
  "modelid": "lumi.switch.n0agl1",
  "product": "lumi.switch.n0agl1",
  "sleeper": false,
  "status": "Gold",
  "matchexpr": "R.endpoints.includes(0x15) && R.endpoints.includes(0x1F)",
  "path": "/devices/xiaomi_ssm-u01_t1_switch.json",
  "subdevices": [

[flopp999]

I removed this line
"matchexpr": "R.endpoints.includes(0x15) && R.endpoints.includes(0x1F)",
restart deCONZ and now I can see that the devices use the new JSON

[flopp999]

It seems that the data is coming to deCONZ but no item for simple metering and electrical meas.

Device 04:cf:8c:df:3c:8e:40:61 is the old Aqara T1 that is now using new JSON but it shows Simple met and electrical meas.
I may need to wait and see if the new devices also get those two items

[flopp999]

@Smanar I now saw that I got new devices in Home Assistant, power and consumption, so it works, YEAH

Thank you so much

Can I send you a coffee or paypal?

[Smanar]

Can I send you a coffee or paypal?

Thx for the offer ^^, I have a link in my plugin for domoticz repo on my github profile, but it's not finished for me.

"matchexpr": "R.endpoints.includes(0x15) && R.endpoints.includes(0x1F)",

And your device have it (it s the big number, you have 01 15 1F 29 and F2), I don't see why the check is not working, I will ask in dev channel to be sure.

This check is here to keep a compatibility whith old and new device, you have both model on your side ? and both are working with the new DDF ?

BTW what is your deconz version ?
failed to evaluate matchexpr for 54:ef:44:10:00:19:31:1b: R.endpoints.includes(0x15) && R.endpoints.includes(0x1F), err: TypeError: Property 'includes' of object 1,21,31,41,242 is not a function

Look like your version don't support it.

[flopp999]

I have totally 5 Aqara T1. All of them are working fine now with new JSON. I can delete all off them if that help you to develop/solve it.
Book1.csv
3 years OLD: 04:cf:8c:df:3c:8e:40:61 and 54:ef:44:10:00:09:bd:c3
NEW: 54:ef:44:10:00:18:59:09 , 54:ef:44:10:00:18:59:83 and 54:ef:44:10:00:19:31:1b

[flopp999]

I noticed that I got 2 power and 2 consumption for the old ones but that is because I removed the line in JSON, that you will check with dev how to solve

[Smanar]

I noticed that I got 2 power and 2 consumption for the old ones but that is because I removed the line in JSON

I think it's because you have the one created by legacy code, and the one with the DDF.
Ols one finishing by 0702 or 0b04 (old cluster) and new one finishing by 1f-00C and 15-000c (new cluster but different endpoint).
So yes I think it can solved with deleting it before, but even old one will (try to) work with the DDF core after that.

I m still waiting help to see If I m doing something wrong with endpoints.includes(), but it's used for others devices with the same synthax

[SwoopX]

@flopp999
Although the matchexpr stanza is absolutely not required in this DDF, I'd be curious to understand if the below would work:

"matchexpr": "R.endpoints.indexOf(0x15) + R.endpoints.indexOf(0x1F) >= 0 ? true : false;",

For me, the error mentioned above shows an array of integers, and .includes() would be legitly applicable to arrays (or strings). Maybe that is another of the qt JSEngine hiccups...

[flopp999]

"matchexpr": "R.endpoints.indexOf(0x15) + R.endpoints.indexOf(0x1F) >= 0 ? true : false;",

this is what I got in Debug View:
matchexpr: R.endpoints.indexOf(0x15) + R.endpoints.indexOf(0x1F) >= 0 ? true : false; --> true
So it means that it can handle ints?

[Smanar]

Although the matchexpr stanza is absolutely not required in this DDF, I'd be curious to understand if the below would work:

Honnestly I haven't thoses devices and too much to read in the issue, but I don't want to break first version that use the classic cluster 0x0b04 and 0x0702 (if they exist) it's for that I wana use this check.

And BTW if its not working mean there is the issue too on 2 others DDF that use the same check.

So it means that it can handle ints?

Yes, I think, its like this code

a = [8,7];
b = a.indexOf(7) + a.indexOf(8) >= 0 ? true : false;
b -> true

But @SwoopX if you know better than me thoses device, you can confirm me, we don't need the matchexpr check ?

[SwoopX]

The point here is that you only need matchexpr if you must conduct a check on endpoints. That is the case for the device at hand as it doesn't change its endpoints in any way based on the screenshots available throughout this issue. Consequently, it is unnecessary and as @flopp999 already tested and confirmed, the device works fine without that stanza.

For the sake of completeness, that would be the correct stanza to use (as it is independent of any order within the array):
"matchexpr": "(R.endpoints.indexOf(0x15) !== -1) && (R.endpoints.indexOf(0x1F) !== -1);",

However, you guys seemed to have accidentally solved the issue ghosting around the 2 Xiaomi smart plugs 🙂

[Smanar]

However, you guys seemed to have accidentally solved the issue ghosting around the 2 Xiaomi smart plugs

It seem ^^, I will make the PR for this switch I let you correct the 2 other PRs.