Deconz-rest-plugin: Deconz 2.05.85 and few devices issue

Created on 16 Oct 2020 · 26Comments · Source: dresden-elektronik/deconz-rest-plugin

Guys!

Deconz 2.05.85 and old aqara switches WXKG03LM with one single event (version with double and long press is works as it should), but this first version is not working like opple switches too, in this 85 deconz version. Switches is present in phoscon but there are no events from them.

Bug report

Source

SAOPP

All 26 comments

Same issue. Listening to events but nothing. Previous version was working ok.

Martinvdm on 16 Oct 2020

Yep same here....all Aqara Opple Switches 4x and 6x have no events. I'm back on 2.05.83...

easybeat on 16 Oct 2020

Pal, you know the protocol. The templates are there for a reason. I leave this one open since the latest beta has apparently some odd things going on. Interestingly, this seem to apply only for Xiaomi devices so far.

Folks, raising your voice is good, valid and appreciated. However, we need logs to investigate. Preferably, from the start of deconz shortly followed by some button presses of the troublesome devices.

SwoopX on 16 Oct 2020

Can you please give me the zigbee model ID of the devices? I guess the root cause is found and you should be able to correct that your selves.

SwoopX on 16 Oct 2020

I didn’t opened this issue, but will try to give you some logging tommorrow

Martinvdm on 16 Oct 2020

Double rocker have no events also. Model with 3 actions. So, two old models (one and two buttons) are not working now in 85th version.

SAOPP on 16 Oct 2020

@SwoopX I can't reading basic cluster, it simple not readed, nothing happened when I click on read button. Damn, I think I will switch to stable container... check it, and after this share with u mf code... or maybe someone will do it before me.

SAOPP on 16 Oct 2020

Query the API directly. The resource contains it.

SwoopX on 16 Oct 2020

It's from api:

{"config":{"battery":95,"on":true,"reachable":true,"temperature":3000},"ep":1,"etag":"408e973b35d8dbaef1b19af24a4e0fd6","lastseen":"2020-10-16T20:09Z","manufacturername":"LUMI","mode":1,"modelid":"lumi.sensor_86sw1","name":"corridor_aqara_switch","state":{"buttonevent":1002,"lastupdated":"2020-10-15T15:32:07.745"},"swversion":"20160517","type":"ZHASwitch","uniqueid":"00:15:8d:00:01:83:a6:01-01-0006"}

I don't see the md code over here.

SAOPP on 16 Oct 2020

Hm, got no clue where this is covered even in the old code... That's gonna be interesting. Btw, we described a fix for the Opple already.

SwoopX on 16 Oct 2020

👍1

Hm, I should have an lumi.sensor_86sw2 lying around. Will have a look tomorrow.

ebaauw on 16 Oct 2020

👍1

@SwoopX 'bout opple fix glad to hear it. So I'm not swithed to stable, I think I can wait for aqara fix too :D

SAOPP on 16 Oct 2020

The root cause will probably be here

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/7812ef1a9ccbb71402d648a2c4d7c99e02578ec5/de_web_plugin.cpp#L7568-L7593

SwoopX on 17 Oct 2020

Also aqara vibration sensor is broken too.

SAOPP on 17 Oct 2020

The lumi.sensor_86sw2 pairs and works just fine under 2.05.84. The lumi.vibration in my production network has been working just fine since the update to 2.05.84, last Sunday (6 days ago).

@SAOPP, please check in the GUI and/or deCONZ log that the switches/sensors do send messages. The node in the GUI should blink blue, and the attributes should update. The log should contain APS-DATA.indication messages; please list these here, including the asdu on the next line (run deCONZ with --dbg-info=2 --dbg-aps=2 --dbg-error=1). We're looking for something like:

Oct 17 10:11:17 pi5 deCONZ[29911]: 10:11:13:807 APS-DATA.indication srcAddr: 0x64af, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 255, rssi: -42
Oct 17 10:11:17 pi5 deCONZ[29911]: 10:11:13:807     asdu: 18070a0000100100001000

Please check the deCONZ log for "no button map" messages.

The root cause will probably be here

@SwoopX That code is ancient, what makes you think it would break now? I'm not quite sure why we don't use regular button maps for these switches. Could be that these were the first to use reporting for server _OnOff_ attributes, instead of sending client _OnOff_ commands, and maybe the button map didn't yet handle that when we added support for these switches. I don't remember the check for an empty button map in line 7568.

ebaauw on 17 Oct 2020

The full name of the vibration sensor is lumi.vibration.aq1, the button map only mentions lumi.vibration. @SwoopX, could that be the issue?

ebaauw on 17 Oct 2020

No, the code uses startsWith(), so it should be fine in that case.

SwoopX on 17 Oct 2020

After commenting out the i->buttonMap(buttonMapData, buttonMapForModelId).empty() check, the lumi.sensor_86sw2 works. Not sure I understand the button map code, but clearly, it doesn't initialise correctly, when no button map has been defined for the model. I tried to initialise m_buttonMap explicitly in Sensor::Sensor(), but that didn't help.

ebaauw on 17 Oct 2020

As for the vibration, I don't understand why it's included in the button maps. It should be exposed as a single ZHAVibration resource:

$ ph get /sensors/255
{
  "config": {
    "battery": 98,
    "on": true,
    "pending": [],
    "reachable": true,
    "sensitivity": 0,
    "sensitivitymax": 21,
    "temperature": 2600
  },
  "ep": 1,
  "etag": "64b1432242e2e220f64cb75597d7acfd",
  "lastseen": "2020-10-17T08:34Z",
  "manufacturername": "LUMI",
  "modelid": "lumi.vibration.aq1",
  "name": "Washroom Vibration",
  "state": {
    "lastupdated": "2020-10-17T08:08:44.561",
    "orientation": [
      3,
      1,
      86
    ],
    "tiltangle": 360,
    "vibration": false,
    "vibrationstrength": 65
  },
  "swversion": "20180130",
  "type": "ZHAVibration",
  "uniqueid": "00:15:8d:00:02:a5:21:24-01-0101"
}

No state.buttonevent, no button map. @SAOPP can you double-check how the vibration sensor is exposed on your system? If there is an issue with it, it's unrelated to the switch issue, best open a new issue.

ebaauw on 17 Oct 2020

Perhaps focus on the changes compared to the previous release. As in the previous version it was working.

Martinvdm on 17 Oct 2020

@ebaauw

@SwoopX That code is ancient, what makes you think it would break now?

Yes, must be ancient. I was a bit puzzled to see a button map check in there. Personally, I'd prefer to get rid of that part of the code and translate it into our regular button maps. Additionally, I suspected the .empty() check to be the reason. Interestingly, I use it elsewhere, but assign buttonMap(buttonMapData, buttonMapForModelId) to a vector first and then check it with .empty(). I'm more than happy to remove that check nevertheless.