deconz-rest-plugin
deconz-rest-plugin copied to clipboard
Aqara smart smoke detector - JY-GZ-01AQ
Device
- Product name: Aqara Smart Smoke Detector
- Manufacturer: Aqara
- Model identifier: JY-GZ-01AQ
- Device type :
- Sensor
Screenshots
![Screenshot 2022-03-14 at 15 51 52](https://user-images.githubusercontent.com/5030836/158198354-fc7bcf20-b032-4f84-ae66-6248fbaa04bc.png)
![Screenshot 2022-03-14 at 15 50 45](https://user-images.githubusercontent.com/5030836/158198364-3bc791c7-6ec8-4e37-9181-648c282c11ce.png)
![Screenshot 2022-03-14 at 15 50 01](https://user-images.githubusercontent.com/5030836/158198367-74e72697-f210-4140-8d5d-4c47c2c24358.png)
![Screenshot 2022-03-14 at 15 49 03](https://user-images.githubusercontent.com/5030836/158198369-819f9df9-98bb-4b71-9abc-9b43293d1a89.png)
![Screenshot 2022-03-14 at 15 45 53](https://user-images.githubusercontent.com/5030836/158198372-8508304d-dbe1-478f-8744-c7348990bd1c.png)
![Screenshot 2022-03-14 at 15 20 33](https://user-images.githubusercontent.com/5030836/158198379-7648da00-87a8-4f52-81c2-41a115a39620.png)
![Screenshot 2022-03-14 at 14 49 11](https://user-images.githubusercontent.com/5030836/158198385-6a7479a4-6a62-4047-a74a-0a5dd172273f.png)
![Screenshot 2022-03-14 at 14 49 03](https://user-images.githubusercontent.com/5030836/158198386-dde56405-7b7f-4e53-8b5e-862b061f9310.png)
Missing screenshots.
Please add them all.
Some reference here also: https://zigbee.blakadder.com/Aqara_JY-GZ-01AQ.html
In the original post please. Add all clusters as requested.
Missing screenshots.
Please add them all.
Added them all, please let me know if you need more information.
Hello, this device realy look classic. Do want to make a try with DDF ? You can start from scratch https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/DDF-cheat-sheet Or edit an existning one, like this one https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/frient/smszb-120_smoke_detector.json But you need to make so much change on it, and I don't find another one more clear.
Hello, this device realy look classic. Do want to make a try with DDF ? You can start from scratch https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/DDF-cheat-sheet Or edit an existning one, like this one https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/frient/smszb-120_smoke_detector.json But you need to make so much change on it, and I don't find another one more clear.
That's a new path for me, but I will give it a try :) Will loop back here if there has been any succes.
thanks
Sure, If you can at least make something for the device be reconized, just copy/paste your DDF (and save the file, to have the file path), I can finish it using text editor.
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.
As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.
@roelvandermade You have give up ?
Not given up but more into a lack of time and understanding. Will dive back into it in a few weeks. Will let you know then how far I’ve come and where I got stuck.
-- Sent using a mobile device
On 13 Apr 2022, at 12:28, Smanar @.***> wrote:
@roelvandermade You have give up ?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
Sure, I can't help you for time, but I can if you need more guidance.
I received two of these smoke sensors today and am trying to follow up on the github thread that has been closed a while ago due to lack of response.
This is my first attempt to use the DDF editor to at least deliver the basic file @Smanar was asking for. But I just do not get how to use the DDF editor. I select the device that I need to add and choose “edit DDF” this opens an Untitled file with prefilled modelid lumi.sensor_smoke.acn03 and Manufacturer LUMI as basic information. Then I enable the sleeper option and drag the ZHAFire to the left side of the window.
I checked the attributes and assume all I should change maybe is the settings for the fire attribute? Here is where I get lost and do not know where to go from here. I have set the file on bronze and enabled bronze in the DDF options of deCONZ. I saved the file at this point and did a hot reload. Rescanned the devices and nothing seems to have changed.
When opening the ddf file on the device again the file I saved is opened so it has loaded it. I see the option to select the different parse options, including Xiaomi: special. But have no clue what to set in this. I have tried to read through documentation but am stuck here.
How can I get this moving forward to the REST API?
Thanks,
Wim
Hello have started a DDF can use this one as base
{
"schema": "devcap1.schema.json",
"manufacturername": "LUMI",
"modelid": "lumi.sensor_smoke.acn03",
"vendor": "Xiaomi",
"product": "JY-GZ-01AQ smoke sensor",
"sleeper": true,
"status": "Gold",
"subdevices": [
{
"type": "$TYPE_FIRE_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0500"
],
"fingerprint": {
"profile": "0x0104",
"device": "0x0402",
"endpoint": "0x01",
"in": [
"0x0000",
"0x0001",
"0x0500"
]
},
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"refresh.interval": 84000,
"read": {
"at": "0x0006",
"cl": "0x0000",
"ep": 1,
"fn": "zcl"
},
"parse": {
"at": "0x0006",
"cl": "0x0000",
"ep": 1,
"eval": "Item.val = Attr.val",
"fn": "zcl"
}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/battery"
},
{
"name": "config/enrolled"
},
{
"name": "config/on"
},
{
"name": "config/pending"
},
{
"name": "config/reachable"
},
{
"name": "state/fire"
},
{
"name": "state/lastupdated"
},
{
"name": "state/lowbattery"
},
{
"name": "state/test"
}
]
},
{
"type": "Warning device",
"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",
"refresh.interval": 84000,
"read": {
"at": "0x0006",
"cl": "0x0000",
"ep": 1,
"fn": "zcl"
},
"parse": {
"at": "0x0006",
"cl": "0x0000",
"ep": 1,
"eval": "Item.val = Attr.val",
"fn": "zcl"
}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "state/alert"
},
{
"name": "state/reachable"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0001",
"report": [
{
"at": "0x0020",
"dt": "0x20",
"min": 300,
"max": 43200,
"change": "0x00000001"
}
]
},
{
"bind": "unicast",
"src.ep": 35,
"cl": "0x0500"
}
]
}
You can compare it with your "preview" tab, or can show screen capture.
- I have created 1 "ZHAFire" and a "Warning device"
- I m using classic method for IAS cluster
- not sure for sleeper, as this device have a siren too nope ?
- It seem this device ned a special magic during inclusion, or it s for advanced condig ...
- I don't see the Xiaomi specail cluster on capture, so I m using classic method, but I suspect an invisible cluster (need to use it for previous remark)
- For battery I m using the attribute 0x0020, but you have both at 0 on your capture (0x0020 and 0x0021), so need to find a better method or check if the value are realy 0.
I will check on this. I believe I saw a xiaomi cluster in my version (different firmware?) If I see those I will post the images here. Will be back on this
I tried to use your version, but it did not change, I do not see the warning device here, not sure if it is needed. But there is a sirene sound when testing, so I guess something should be there. I do see the Lumi specific cluster. I will post all images from my device after performing read on each of them:
Basic cluster:
IAS zone:
Power configuration
Lumi specific part 1
Lumi specific part 2
Does this change things?
DDF should be stripped down a bit like that:
{
"schema": "devcap1.schema.json",
"manufacturername": "$MF_LUMI",
"modelid": "lumi.sensor_smoke.acn03",
"vendor": "Xiaomi",
"product": "Aqara smoke sensor JY-GZ-01AQ",
"sleeper": true,
"status": "Gold",
"subdevices": [
{
"type": "$TYPE_FIRE_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0500"
],
"fingerprint": {
"profile": "0x0104",
"device": "0x0402",
"endpoint": "0x01",
"in": [
"0x0000",
"0x0001",
"0x0500"
]
},
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid",
"awake": true
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"awake": true,
"parse": {
"at": "0x00f7",
"ep": 1,
"fn": "xiaomi:special",
"idx": "0x08",
"script": "xiaomi_swversion.js"
},
"read": {
"fn": "none"
}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/battery",
"awake": true,
"parse": {
"at": "0x00f7",
"ep": 1,
"fn": "xiaomi:special",
"idx": "0x01",
"script": "xiaomi_battery.js"
}
},
{
"name": "config/enrolled"
},
{
"name": "config/ledindication",
"refresh.interval": 300,
"parse": {
"at": "0x013c",
"cl": "0xfcc0",
"ep": 1,
"eval": "Item.val = Attr.val == 1 ? true : false",
"fn": "zcl",
"mf": "0x115f"
},
"read": {
"at": "0x013c",
"cl": "0xfcc0",
"ep": 1,
"fn": "zcl",
"mf": "0x115f"
},
"write": {
"at": "0x013c",
"cl": "0xfcc0",
"dt": "0x20",
"ep": 1,
"eval": "Item.val ? false : true",
"fn": "zcl",
"mf": "0x115f"
},
"values": [
[true, "Device LED will flash every 60 seconds"],
[false, "Device LED off"]
],
"default": true
},
{
"name": "config/on"
},
{
"name": "config/pending"
},
{
"name": "config/reachable"
},
{
"name": "state/fire"
},
{
"name": "state/lastupdated"
},
{
"name": "state/lowbattery"
},
{
"name": "state/test"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 01,
"cl": "0x0500"
}
]
}
The device doesn't have any IAS WD cluster, so no warning device.
If the name stay an hexa number (like 0x770B) It mean the DDF is not used.
- So check model id / manufacture name
- Try a "hot relaod" in the menu
@SwoopX
The device doesn't have any IAS WD cluster, so no warning device.
For that I m reading he have, but use the Lumi specific cluster, not a basic device, not sure all will be possible using only DDF
The attribute 0x013c is not used on Z2M
I updated the DDF using @SwoopX 's sample. The DDF could not be read, until I changed the bindings section to use "src.ep": "01",
instead of "src.ep": 01,
. Here it could be read and the name changed to Fire 142. So the DDF is used resulting in REST API reply:
{
"config": {
"battery": 0,
"ledindication": false,
"on": true,
"pending": [],
"reachable": false
},
"ep": 1,
"etag": "f7271de847e69a4fdfff0b5827549bc8",
"lastannounced": null,
"lastseen": "2022-07-26T14:46Z",
"manufacturername": "LUMI",
"modelid": "lumi.sensor_smoke.acn03",
"name": "Fire 142 Fire",
"state": {
"fire": null,
"lastupdated": "none",
"lowbattery": null,
"test": null
},
"type": "ZHAFire",
"uniqueid": "54:ef:44:10:00:48:2d:c2-01-0500"
}
But the battery value is never updated. And if I check the preview, the bindings section is empty. So I guess reporting is not yet active? I have added a binding for battery as shown in the DDF Cheat sheet. I did that maybe 15 minutes ago, so it could be a bit longer before a first report would be send I guess? Would I need more bindings other then the battery for this device?
The DDF at its current state:
{
"schema": "devcap1.schema.json",
"manufacturername": "$MF_LUMI",
"modelid": "lumi.sensor_smoke.acn03",
"vendor": "Xiaomi",
"product": "Aqara smoke sensor JY-GZ-01AQ",
"sleeper": true,
"status": "Gold",
"path": "/devices/lumi.sensor_smoke.acn03.json",
"subdevices": [
{
"type": "$TYPE_FIRE_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0500"
],
"fingerprint": {
"profile": "0x0104",
"device": "0x0402",
"endpoint": "0x01",
"in": [
"0x0000",
"0x0001",
"0x0500"
]
},
"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/battery",
"awake": true,
"parse": {
"at": "0x00f7",
"ep": 1,
"fn": "xiaomi:special",
"idx": "0x01",
"script": "xiaomi_battery.js"
},
"default": 0
},
{
"name": "config/enrolled",
"public": false
},
{
"name": "config/ledindication",
"refresh.interval": 300,
"read": {
"at": "0x013c",
"cl": "0xfcc0",
"ep": 1,
"fn": "zcl",
"mf": "0x115f"
},
"write": {
"at": "0x013c",
"cl": "0xfcc0",
"dt": "0x20",
"ep": 1,
"eval": "Item.val ? false : true",
"fn": "zcl",
"mf": "0x115f"
},
"parse": {
"at": "0x013c",
"cl": "0xfcc0",
"ep": 1,
"eval": "Item.val = Attr.val == 1 ? true : false",
"fn": "zcl",
"mf": "0x115f"
},
"default": true
},
{
"name": "config/on"
},
{
"name": "config/pending"
},
{
"name": "config/reachable"
},
{
"name": "state/fire"
},
{
"name": "state/lastupdated"
},
{
"name": "state/lowbattery"
},
{
"name": "state/test"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0001",
"report": [
{
"at": "0x0020",
"dt": "0x20",
"min": 300,
"max": 43200,
"change": "0x00000001"
}
]
}
]
}
But the battery value is never updated
Its my bad, on your first capture, the lumi cluster was not present, but I m sure now it use this one for the battery (as on cluster 0x0001 both value are 0), so need to change the DDF part for battery, need to remove the bind and use probably something like
{
"name": "config/battery",
"parse": {"fn": "xiaomi:special", "at": "0xff01", "idx": "0x01", "script": "xiaomi_battery.js"}
},
Please use the suggested DDF as above while applying the necessary fix. There is no need to try to apply any other bindings or attribute reporting, as it will fail or be ignored in 90% of the case.
The reason why you do not see any battery values is that the required script is not in the same location as the DDF. Also, the swversion will not show up unless the new deconz version is out, but preperations are made.
It will be interesting to see, if the device follows zigbee enrollment process or if that fails (can be checked in the IAS zone cluster).
Hi,
Have been trying the suggested DDF's with the battery-fix and am getting mixed results but not all of them feel like the final and best configuration.
My results now are;
- the device is showing up in Phoscon and deCONZ with a light-flash trigger identification working when executed in deCONZ's 'Identify cluster'. I have no clue how to have it identify itself (or test itself) with an audible signal from within deCONZ and/or HA
- the battery status SEEMS to be updating (see screenshot) (I have added the xiaomi_battery.js script taken from [https://raw.githubusercontent.com/dresden-elektronik/deconz-rest-plugin/master/devices/xiaomi/xiaomi_battery.js])
- the sensor status also SEEMS to be updating (see screenshot)
- the Smoke Sensor switch-button does not work (it used to work during testing several settings/ddf's but cannot reproduce this anymore somehow, though I was able to toggle the switch but it didn't do anything further).
So my questions now are;
- how can we be certain the battery and sensor status are indeed accurate and updated?
- Do we need to flip switches/configurations in the Cluster-zone settings, or is it all just the DDF file for identification and configuration?
- how can we have the smoke sensor identify itself with an audible signal from within deCONZ or HA?
attached the screenshot from HomeAssistant and attached my current DDF.
@SwoopX regarding your IAS Zone enrollment, I have also added a screenshot regarding that, it seems to be enrolled successfully, though I am unsure at this stage if that is due to my fiddling around, or not.
thanks! Roel.
{
"schema": "devcap1.schema.json",
"manufacturername": "$MF_LUMI",
"modelid": "lumi.sensor_smoke.acn03",
"vendor": "Xiaomi",
"product": "Aqara smoke sensor JY-GZ-01AQ v2",
"sleeper": true,
"status": "Gold",
"path": "/devices/aqara_smart_smoke_sensor.json",
"subdevices": [
{
"type": "$TYPE_FIRE_SENSOR",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0500"
],
"fingerprint": {
"profile": "0x0104",
"device": "0x0402",
"endpoint": "0x01",
"in": [
"0x0000",
"0x0001",
"0x0500"
]
},
"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/battery",
"parse": {
"at": "0xff01",
"fn": "xiaomi:special",
"idx": "0x01",
"script": "xiaomi_battery.js"
},
"default": 0
},
{
"name": "config/enrolled",
"public": false
},
{
"name": "config/ledindication",
"refresh.interval": 300,
"read": {
"at": "0x013c",
"cl": "0xfcc0",
"ep": 1,
"fn": "zcl",
"mf": "0x115f"
},
"write": {
"at": "0x013c",
"cl": "0xfcc0",
"dt": "0x20",
"ep": 1,
"eval": "Item.val ? false : true",
"fn": "zcl",
"mf": "0x115f"
},
"parse": {
"at": "0x013c",
"cl": "0xfcc0",
"ep": 1,
"eval": "Item.val = Attr.val == 1 ? true : false",
"fn": "zcl",
"mf": "0x115f"
},
"default": true
},
{
"name": "config/on"
},
{
"name": "config/pending"
},
{
"name": "config/reachable"
},
{
"name": "state/fire"
},
{
"name": "state/lastupdated"
},
{
"name": "state/lowbattery"
},
{
"name": "state/test"
}
]
},
{
"type": "Warning device",
"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/reachable"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 1,
"cl": "0x0001",
"report": [
{
"at": "0x0020",
"dt": "0x20",
"min": 300,
"max": 43200,
"change": "0x00000001"
}
]
},
{
"bind": "unicast",
"src.ep": 35,
"cl": "0x0500"
}
]
}
![Screenshot 2022-08-02 at 18 51 02](https://user-images.githubusercontent.com/5030836/182430623-826e2713-c2a7-4882-8eb8-b2ca47e360d6.png)
how can we be certain the battery and sensor status are indeed accurate and updated?
Good question ^^, (you can see request in logs but idk if you can trust them) can try with an end of life battery ? And with the cluster IAS you have too a state/lowbattery
Do we need to flip switches/configurations in the Cluster-zone settings, or is it all just the DDF file for identification and configuration?
Not sure to understand, but the DDF is here to make ALL the needed stuff (it s trying at least), on a final DDF the user will not need to use the GUI.
how can we have the smoke sensor identify itself with an audible signal from within deCONZ or HA?
Have you try the "Warning device" light entry ? You have some possible values to use here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/4432#issuecomment-782841021 (But I m ok, it s not the identify cluster)
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.
As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.
Anyone an idea if this device will be officially supported? Currently I'm not able to pair it.
Can try the json on previous post. No one have made PR so the DDF is not present on official version.
How to pair this device? I pressed the button 3 times, the LED is blinking green but nothing happens.
Ah ok I found out. The device will automatically pair with deconz but we cannot see the success in phoscon, only in the deconz vnc view.
Ah ok I found out. The device will automatically pair with deconz but we cannot see the success in phoscon, only in the deconz vnc view.
I never use phoscon, as it don't support all device. All devices can be see on deconz event not supported in the API The important part is the support in the API, if it have worked
- The device is visible in the API, using third app or phoscon/help/debug view/sensors
- The node name in deconz change from 0xXXXX to a real name.