Closed BigWumpus closed 5 years ago
That looks like a new model of the cube. Could you please post deCONZ GUI screenshots of:
Yes, it is the 2017 edition with Aqara printed on. Some pictures...
On the surface, it would seem they only changed the Model Identifier. Could you try my latest commit from PR #612?
Can you test if the buttonevent
values are still the same (see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/138#issuecomment-324714123 and https://github.com/dresden-elektronik/deconz-rest-plugin/issues/138#issuecomment-325101635).
Sorry, I can't check it, because I don't want to compile the whole story. May it be in the next beta? Is PhosConz also related?
Is PhosConz also related?
Yes, Phoscon uses the REST API to talk to deCONZ.
So, i inserted the changes, compile it and it is running. In Phoscon i can see a state, i can figure out the moves, 1xflips, 2xflips, 2xclapps, shaking, OK. But there is no information about the angle while turning.
I cant pair the Cube I just ordered from Aliexpress. The motion sensors worked fine on first try. I run deCONZ in Docker. Version 2.05.28. This is the only data I can get when I try to pair it:
20:24:37:380 device announce 0x00158D000231E577 (0xF017) mac capabilities 0x80, 20:24:37:380 set fast probe address to 0x00158D000231E577 (0xF017), 20:24:37:428 ZCL attribute report 0x00158D000231E577 for cluster 0x0000, ep 0x01, 20:24:37:380 0xE43E nwk changed to 0xF017, 20:24:37:428 0x00158D000231E577 skip Xiaomi attribute 0x0005, 20:24:38:331 [2] get active endpoints for 0x00158d000231e577, 20:24:38:436 ZCL attribute report 0x00158D000231E577 for cluster 0x0000, ep 0x01, 20:24:38:436 0x00158D000231E577 extract Xiaomi special, 20:24:38:436 01 battery 2945 (0x0B81), 20:24:38:436 03 temperature 27 °C, 20:24:38:436 04 unknown 424 (0x01A8), 20:24:38:436 05 unknown 177 (0x00B1), 20:24:38:436 06 unknown 4294967296 (0x0000000100000000), 20:24:38:436 97 unknown 0 (0x0000), 20:24:38:436 98 unknown 0 (0x0000), 20:24:38:436 99 unknown 0 (0x0000), 20:24:38:436 9a unknown 4 (0x0004)
If I twist and turn the Cube after this event log, I get these:
20:25:56:520 ZCL attribute report 0x00158D000231E577 for cluster 0x000C, ep 0x03, 20:25:56:968 ZCL attribute report 0x00158D000231E577 for cluster 0x000C, ep 0x03, 20:26:11:003 ZCL attribute report 0x00158D000231E577 for cluster 0x0012, ep 0x02, 20:26:18:557 ZCL attribute report 0x00158D000231E577 for cluster 0x0012, ep 0x02, 20:26:20:926 ZCL attribute report 0x00158D000231E577 for cluster 0x0012, ep 0x02
But no Sensors show up when I check with a REST client. Only the 2 motion sensors I paired show up there. Is there a fix coming soon ?
Having browsed through the thread I'm still a bit confused. Is there a pre-compiled version that supports the Aqara cubes (Ubuntu) through the REST API now? (Both face-up, gestures and rotation) Will I get the latest beta doing a apt-get update/upgrade after install?
If this is still work in progress, I apologise for pushing. Is just that I got 5 Aqara cubes that I want to put to use :-)
Would the .deb packages for rpi https://www.dresden-elektronik.de/rpi/deconz/beta/ work on Ubuntu? Probably different architectures. Found this: https://www.dresden-elektronik.de/deconz/ubuntu/beta/ :-)
As far as I know, these packages are specific for Raspbian (Debian) and the ARM processor used in the Raspberry Pi. Note that these packages consist of the deCONZ core programme and the pre-compiled REST API plugin.
As mentioned in the README, compiling the REST API plugin yourself is only supported on Raspbian. For Windows and Ubuntu, you need to wait for a released package. Looks like v2.05.28 is available for both these platforms, see https://www.dresden-elektronik.de/deconz. Still no macOS version ;-(
Thanks Erik. I also found the Win betas https://www.dresden-elektronik.de/deconz/win/ (Is there a top level link to these betas?)
Took the 2.05.28 for a spin, but the Aqara cube is still a no go on the REST API. Only /sensor/2&3 from Cube P1 (Mi Pink) are listed when doing a /sensors GET
Also tried a second Aqara cube:
All looks well in the Cluster info regarding the Present values for Multi Input & Analog Input. That is except for the Node Info Name which is empty:
NWK/IEEE values are unique though.
Took the 2.05.28 for a spin, but the Aqara cube is still a no go on the REST API. Only /sensor/2&3 from Cube P1 (Mi Pink) are listed when doing a /sensors GET
The Xiaomi battery-powered devices are notoriously difficult to pair:
@manup, I see the Model Identifier attribute (0x0005) from the Xiaomi magic report is simply ignored. Couldn't we use this to set modelId
in case it's still empty?
My cubes are just 25cm from the ConBee while I'm testing this out on Win :-) The only two fields that differ between Mi and Aqara are: Mi:
Aqara:
@manup, I see the Model Identifier attribute (0x0005) from the Xiaomi magic report is simply ignored. Couldn't we use this to set modelId in case it's still empty?
I wonder, it should already be set in the simple descriptor basic cluster (that's why it is visible in the cluster info panel).
I forgot to mention that after pairing the Mi cube, I changed it's name with a REST PUT. It's original name was probably LUMI, as thas is still the name REST returns:
{
"1": {
"config": {
"configured": true,
"on": true,
"sunriseoffset": 30,
"sunsetoffset": -30
},
"etag": "78cf1a569aecc2ec324d6d8334c0bf2c",
"manufacturername": "Philips",
"modelid": "PHDL00",
"name": "Cube P1",
"state": {
"dark": false,
"daylight": true,
"lastupdated": "2018-06-09T11:17:43",
"status": 170
},
"swversion": "1.0",
"type": "Daylight",
"uniqueid": "00:21:2e:ff:ff:02:2e:82-01"
},
"2": {
"config": {
"battery": 100,
"on": true,
"reachable": true,
"temperature": 2800
},
"ep": 2,
"etag": "c2fd68479e9657b162a2e6c53e2a9d16",
"manufacturername": "LUMI",
"mode": 1,
"modelid": "lumi.sensor_cube",
"name": "Cube P1",
"state": {
"buttonevent": 7000,
"lastupdated": "2018-06-09T11:32:40"
},
"type": "ZHASwitch",
"uniqueid": "00:15:8d:00:01:02:50:dc-02-0012"
},
"3": {
"config": {
"battery": 100,
"on": true,
"reachable": true,
"temperature": 2800
},
"ep": 3,
"etag": "c2fd68479e9657b162a2e6c53e2a9d16",
"manufacturername": "LUMI",
"mode": 1,
"modelid": "lumi.sensor_cube",
"name": "Cube P1",
"state": {
"buttonevent": -6724,
"lastupdated": "2018-06-09T11:21:10"
},
"type": "ZHASwitch",
"uniqueid": "00:15:8d:00:01:02:50:dc-03-000c"
}
}
((sensors/1 is nothing I have added. Is it a default device of some sorts?)
The reason manufacturername is now empty in the Basic Cluster Info, could be that I tried several times to rename the Node In the Nams Field in deCONZ, but that does not work:
I deleted and re-paired the Mi cube. Only difference since the 2.05.20 include I did was:
@olemr could you double-check that the Manufacturer Code in the Node Info panel reads 0x1037 for all your cubes?
If they are, make sure the network is open and re-read the Basic cluster. In the old web app, select Show advanced settings and Set the open duration to 10mins.
If this doesn't help, reset the cube and try again. It might take several attempts.
I deleted and re-paired the Mi cube. Only difference sisns the 2.05.20 include I did was
That's no difference caused by the deCONZ version, but by what data was read successfully during pairing. You might also see differences in device type (e.g. ffff vs 5f03 for endpoint 3) and supported clusters between re-pair attempts.
sensors/1 is nothing I have added. Is it a default device of some sorts?
That's the built-in Daylight sensor.
The reason manufacturername is now empty in the Basic Cluster Info, could be that I tried several times to rename the Node In the Nams Field in deCONZ, but that does not work
No. It's emptied every time deCONZ restarts. It's not sync-ed with the corresponding REST API attribute (which is persisted in the database across restarts).
My bad, the PR to support the Aqara cube was merged after v2.05.28, so you'll have to wait for .29.
My bad, the PR to support for the Aqara cube was merged after v2.05.28, so you'll have to wait for .29.
OK. All good things come to those who wait. Thank you so much for your assistance so far.
While waiting for 2.05.29, I can set up my openHAB http binding and rules using the Mi cube.
Any ETA on .29? Glad that the issue was identified and a fix is incoming.
.29 should arrive on Monday
Missed monday with 1min :-) Aqara cube is now working fine. (quick test) Free-fall gesture also working. Thanks!
Am I supposed to be getting 2 devices when adding this cube? Tried twice, and both times it creates two entries:
"15": {
"config": {
"battery": 78,
"on": true,
"reachable": true,
"temperature": 2000
},
"ep": 2,
"etag": "df1c65d716ce548045ff171159597e30",
"manufacturername": "LUMI",
"mode": 1,
"modelid": "lumi.sensor_cube.aqgl01",
"name": "lumi.sensor_cube.aqgl01 15",
"state": {
"buttonevent": null,
"lastupdated": "none"
},
"type": "ZHASwitch",
"uniqueid": "00:15:8d:00:02:31:e5:77-02-0012"
},
"16": {
"config": {
"battery": 78,
"on": true,
"reachable": true,
"temperature": 2000
},
"ep": 3,
"etag": "df1c65d716ce548045ff171159597e30",
"manufacturername": "LUMI",
"mode": 1,
"modelid": "lumi.sensor_cube.aqgl01",
"name": "lumi.sensor_cube.aqgl01 16",
"state": {
"buttonevent": null,
"lastupdated": "none"
},
"type": "ZHASwitch",
"uniqueid": "00:15:8d:00:02:31:e5:77-03-000c"
At least its a step in the right direction. With 2.05.28 I couldnt even add them at all. I tried to add it twice. resetting the Cube before pairing again.
Yes, the first resource is for the Multistate Input on endpoint 2, the second resource is for the Analog Input cluster on endpoint 3. The first reports the discrete actions: flip, push, shake, drop, double tap; the second reports the analogue action: turn (buttonevent
actually holds the angle). See https://github.com/dresden-elektronik/deconz-rest-plugin/issues/138#issuecomment-325101635.
Ok, thanks for the explanation! Now to get this to work in Node Red through Home Assistant :)
Just an observation: when going from .29 (Ubuntu beta) to .32 both my Aqara cubes had to be re-joined. All Ikea lights and the Mi cube 'survived' the upgrade. (but Mi sensor 2&3 swapped place) (Had to generate a new API key also, but that is maybe to be expected?)
systemd deconz.service file had also moved to: /usr/lib/systemd/system/deconz.service and had to be re-edited for right port and user.
Just an observation: when going from .29 (Ubuntu beta) to .32 both my Aqara cubes had to be re-joined. All Ikea lights and the Mi cube 'survived' the upgrade. (but Mi sensor 2&3 swapped place) (Had to generate a new API key also, but that is maybe to be expected?)
Strange, normally this shouldn't happen also the apikeys and everything else must survive the update, they are stored in the sqlite database file zll.db
.
systemd deconz.service file had also moved to: /usr/lib/systemd/system/deconz.service and had to be re-edited for right port and user.
The former location was wrong and shouldn't be used by service files provided by a package. So the right place to put you custom port/user configuration is in fact the former location in /etc/systemd/system, these "user" service files also will survive updates and won't be overwritten.
Strange, normally this shouldn't happen
But it did. That's why I wanted to mention it in case there is a bug. (The Aqara cube support only appeared in version .29)
I had my config in /etc/systemd/system/deconz.service , but after the update the file was just gone. So what you are saying, if I now copy the file from /usr/lib/systemd/system/deconz.service to /etc/systemd/system/deconz.service that is where I should keep my config?
I also did a full apt-get update/upgrade just after the dpkg -i without paying too much attention to sequence of events so I'm not sure which updates did what.
pls. s. @manup's comment in #561 It is meant as a way to customize or augment the vendor's default config.
e.g. to make debug options persistent
below /etc/systemd/system
create both dir and file as per below
deconz.service.d/
└── local.conf
content of local.conf
# https://www.freedesktop.org/software/systemd/man/systemd.unit.html
# """Example 2. Overriding vendor settings"""
[Service]
# enable debug
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80 --dbg-info=1 --dbg-aps=2 --dbg-zcl=1
Hi,
really interesting posts. I am also trying to use the Cube with a Conbee. I am really new in the deconz part just got the stick 1 week ago. Here are some questions:
Thanks a lot.
Cu kami
Is there a beta for windows with .29 or so?2
https://www.dresden-elektronik.de/deconz/win/
You can use the REST API to interface from other applications. https://dresden-elektronik.github.io/deconz-rest-doc/
Here is what I did using openHab: https://community.openhab.org/t/xiaomi-mihome-no-events-from-aqara-cube-mi-cubes-are-ok/45730/5?u=omr rule
Hi, I am happy that deconz pairs and understands the Aqara Cube now! I tried to set up a rule using the REST API in order to use the cube as a light switch. The rule is created, but nothing happens. The rule is never triggered, even though the correct sensor values are shown deconz GUI, web app and REST API. Has anyone tried the same with a better result? I only have a few devices and I would prefer to stay with deconz instead of changing to some bigger solutions (openHAB, etc.). Thanks!
Has anyone tried the same with a better result?
I've had no problems using the Cube in deCONZ rules. Make sure the rule has two conditions, one eq
for state.buttonevent
and one dx
for state.lastupdated
. Also make sure to use the correct sensor resource: the one with uniqueid
ending in -02-0012
for the flip, push, shake, and drop events (with x00y
values); the one with -03-000c
for turning (with analogue values).
even though the correct sensor values are shown deconz GUI, web app and REST API.
Where are you looking in the GUI? And where the web app? Did you see new values of state.buttonevent
and state.lastupdated
in the REST API? Best monitor the web socket output to see the changes in real time.
I tried to set up a rule using the REST API in order to use the cube as a light switch.
Could you list the rule?
I have played with the parameters and now it works! Sensor sources and conditions were correct. I only need the digital states so far, haven't even checked whether the analogue source works correctly. I used action method "BIND" as written in the documentation though. Changing that to "PUT" solves the problem. My rule looks like that:
{
"actions": [{
"address": "/groups/1/action",
"body": {
"toggle": true
},
"method": "PUT"
}],
"conditions": [{
"address": "/sensors/4/state/buttonevent",
"operator": "eq",
"value": "7007"
}, {
"address": "/sensors/4/state/lastupdated",
"operator": "dx"
}],
"name": "Toggle lights"
}
Thanks for your advice!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I got a new magic cube, but I can'T connect it really. It is always 0x0000. Cluster Info "0000 Basic": 0005 Model identifier lumi.sensor_cube.aqgl01 RaspBee-GW on Pi2B with deconz-latest-beta installed today