Aqara Motor B1 does not report anymore

[wvuyk]

Describe the bug

Related to #3508.

When this issue was originally closed all was working well. But something has changed during the last few versions.
If deCONZ is started sending commands do not get a response on the device anymore. When the Analog Output cluster is read once after starting deCONZ REST API commands start to get response from the Aqara motor. Mainly "lift"=nn commands are sent.
But the REST API does not return any updates of the commands back:

After sending a "lift"=0:

After sending a "lift"=100:

Note that only "lastseen" is changed here. So it looks like reporting is not active anymore.

Steps to reproduce the behavior

Expected behavior

Reporting back in REST API

Screenshots

Environment

• Host system: PC
• Running method: Windows
• Firmware version: 26650700
• deCONZ version: 2.09.01
• Device: ConBee II
• Do you use an USB extension cable: no -- only relevant for ConBee I/II
• Is there any other USB or serial devices connected to the host system? none

deCONZ Logs

Additional context

[ebaauw]

Did you try and power cycle the B1?

[wvuyk]

I think he has done this. The user is having 5 curtain motors and all are showing the same results. I have forwarded your suggestion to him just now so he can try it. Will report back when I have an answer

[wvuyk]

@ebaauw

No, taking out the battery and reinserting does not change anything, still a first read by hand on Analog output is needed here to have the device accepting commands. Anything we can try to understand what might go wrong?

[ebaauw]

Is this only after starting deCONZ, or after not interacting with the B1 for a while? This doesn't make sense to me, as the B1 is reachable, since they can read the Analog Output cluster.

We need to figure out if its the communication between the coordinator and the B1 or the REST API plugin. After starting deCONZ, can they write the Present Value attribute in the GUI to open/close the curtains, or do they need to read the value first?

What commands are they sending? Do they have deCONZ logging or Zigbee sniffing to see what Zigbee commands the REST API Plugin makes of these?

[wvuyk]

I can collect the commands send and webhook returns. He is running windows so tracing as far I know is not going to work out. Would love it if that would someday be enabled as my plugin has many Windows users Same for sniffing I am afraid.

Not executing commands is only after starting deCONZ longer no interaction is not a problem as far we checked. Once communication has been starting by the read, comands are accepted, but no updates are send on the current status as shown in the above JSON samples. Except for lastseen nothing is updated.

Commands send by my plugin are normally only "lift"=nn commands. I am not using open commands here.

[wvuyk]

@ebaauw

User has checked on the Present Value:

Stop - start deConz
Write a value to Present Value, the motor responds correct
Control the motor by JowiHue works now also without a read

But no updates on current position on the lift..

[ebaauw]

So it would seem that the API plugin doesn’t fully restore the resource until it receives a message from the device. Maybe a side effect of the /lights resources now (finally) being available on startup?

As for the updates: does the API update the state when reading the attribute in the GUI? If so, it’s probably a missing binding and/or attribute report configuration. If not, there’s something broken. Does the API update battery and lastupdated of the ZHABattery resource?

[wvuyk]

Attributes are changing in the GUI according to the user. Will check on the battery values

If this would be a side effect, would it not be the same for an IKEA blind? I have one here and it is functioning fine, after a restart of deCONZ commands are executed fine through the plugin.

[SwoopX]

Seems like #4139 is related to that. Interestingly, after a recent restart, the plug came up like this (note the name).

[ebaauw]

Attributes are changing in the GUI according to the user.

Then the reporting by the B1 to the coordinator is working. Definitely a REST API plugin issue.

note the name

Could mean that name wasn't written to the database (could happen if you restart deCONZ too soon after pairing), or that the resource wasn't properly restored. This seems consistent with having to trigger a message from the device to the gateway, so the API plugin initialises the resource in full.

would it not be the same for an IKEA blind

Both my mains-powered lumi.curtain and IKEA FYRTUR work fine in v2.9.0 and v2.9.1.

The Analog Output and Analog Input clusters use a float data type for Present Value. Historically this has been challenging for deCONZ (both core and REST API plugin). The standard Window Covering cluster uses integer data types.

[SwoopX]

Could mean that name wasn't written to the database (could happen if you restart deCONZ too soon after pairing), or that the resource wasn't properly restored. This seems consistent with having to trigger a message from the device to the gateway, so the API plugin initialises the resource in full.

No clue what might have happened here. I just checked the DB entries and it seems as if all resources were in state deleted since 5 days. However, I could swear that the device name turned to its NWK just yesterday... Regardless, I'll keep an eye on that (but that's a different topic).

Anyway, the reference made still shows similarities.

[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.

[wvuyk]

The issue is still in need of a solution? what can we do to get this solved?
How can we deliver a trace through using Windows? Why is this not made possible?

Current status:

When deCONZ is started, a read is needed of Present Value before any command is accepted. From then on commands are accepted, but reporting is not doen, so my plugin does not get the status updates.

The user has a Zigbee sniffer, ordered a China Aqara hub 2 and discovered he can do initial settings with the Xiaomi bridge. For one he found how the curtain can be controlled by hand (in id oxF0000, bit 0x20000. Bit is read only, but the aqara hub seems to have tricks to go around this.... Not sure if this is useful to anyone.

I am sure if sniffing helps for this issue, I can ask him?

[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.

[wvuyk]

bump is there anyone who can help here?

[wvuyk]

@Mimiix or @manup
How can I get some help in this? If deCONZ is started the aqara curtain motor B1 does not report through the REST-API. Once a read of any item in basic cluster is done, the motor functions normally and reports as it should.

We are willing to try to get any information to you, but as the user is runnnig on Windows, this is a difficult road. Is there any alternate soltion to get support here?

[Mimiix]

I have no clue where to start. @SwoopX or @ebaauw any comments?

[Krocko]

I have the same problem. The motor don‘t report the current state. Are there any news, or a workaround?

[wvuyk]

Why is this difficult? Anybody help us on how to get this issue clearer for any devs?

[Krocko]

@wvuyk is the state report working for you? For me not.

[Krocko]

Why? This problem is not solved and no more response from the devs in months.

[Mimiix]

Because the bot keeps everyone active. You just got the notified of the issue and so am i , so now i can (again) message Manuel about it.

I'm happy to put a label on it that doesn't auto close (and not notify anyone), but than it probably gets forgotten more easily.

I've (once again) messaged Manuel.

[mvalsgaard]

Any news on this?

[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.

[Krocko]

Really great! 👏🏻

[Mimiix]

I really can't do more than ping @manup everytime. No need to become sarcastic @Krocko.

[Krocko]

Months ago he said he is waiting for delivery. Since then no more reaction.

[Mimiix]

I am not saying I'm not agreeing, because I do. But as I said, I can't force him to look at it.

[manup]

Hi everyone, sorry I missed to update here. Unfortunately the motor controller shipped was not the Aqara B1 but the "X Gear".
Looking forward, the issue gets added to the v2.14.x milestone. If possible it would be great if somebody could send us the device for testing, or join for live session in Discord to create a DDF, after the v2.13 stable release.

[ilya-kozyrev]

Hi everyone, sorry I missed to update here. Unfortunately the motor controller shipped was not the Aqara B1 but the "X Gear".
Looking forward, the issue gets added to the v2.14.x milestone. If possible it would be great if somebody could send us the device for testing, or join for live session in Discord to create a DDF, after the v2.13 stable release.

Hi, big thanks for your contribution folks, I'll happy to help with life session, just ping me in this issue.

[Krocko]

@manup i am now on the latest stable v2.13.4. If you need someone for a live session, please ping me.

[manup]

Hi, thanks we can schedule a live session after Xmas, 27.12 or later would work for me

[Krocko]

No problem.

[ebaauw]

I don't have the B1, only the original mains-powered motor and now the roller shade driver E1.

Afaik, the B1 should report its current position through the Present Value attribute in the Analog Output cluster. The mains-powered motor uses the Windows Covering cluster, but also the Analog Output. I hacked the API plugin to ignore the Windows Covering reports, relying only on the Analog Output, and that worked. The E1 also only reports current position through Analog Output, and that works as well. Concluding, I think the API plugin logic is sound. That would mean that the issue is with the (configuration of the) B1.
Could you please check in the GUI whether the Present Value attribute in the Analog Output cluster is updated when moving the curtains? What about when reading the attribute?

Does the Lumi specific cluster (0xFCC0) carry u8 attribute 0x0009, Device Operation Mode? Could you please check its value (make sure to read it using the Attribute Editor popup window. If it's any other value than 1, could you write 1 to it, and see if Present Value in the Analog Output starts reporting after that? That magic seems to be needed for the E1.

Can you please confirm whether the API plugin exposes a ZHABattery for the B1? Looking at the code, it's supposed to, but I don't think it's working. Should be fixed in my latest PR.

Can someone please list the Xiaomi special attribute report from the deCONZ log? See #5330 for what I need (this is from the E1). I hope to find out how the battery is exposed, and whether it also exposes charging state, like the E1.

[ebaauw]

I think I might have found the issue. Symptoms:

• The B1 can no longer be controlled from the API, but can still be controlled from the GUI. The API actually returns a gateway busy error, but I suppose not all clients check nor report that;
• The B1 has another parent router than the coordinator.

I'll include a fix for this issue in my PR.

The issue is that writeAttribute() refuses to write to sleepy devices (Receiver on When Idle is false) unless it's seen a message from the device within the last 3 seconds. This is under the assumption that the device is asleep, and we dont want to fill the queues with messages that cannot be delivered. When the device has the coordinator as parent, the poll requests count as incoming messages. However, the gateway doesn't see the poll requests to another parent router. Saw a similar issue quite a while back, when trying to read the Time cluster attributes. Will provide the same workaround: whitelist the Analog Output, Multistate Output, and Lumi Specific clusters to skip the check.

[Mimiix]

@ebaauw could this also apply for the fyrtur issues people see when the fyrtus has another device than the coordinator as a parent?

[ebaauw]

No, the FYRTUR and KADRILJ use Window Covering cluster commands, rather than writing attributes in the Analog Output, Multistate Output and Lumi Specific clusters. Are they even seeing the same symptoms: device still contollable by the GUI, but not by the API (unless you read it first from the GUI)?

[Mimiix]

I'm not sure on that. The fyrtur seemed to have issues with controlling them over the api when they were connected with a router instead of the coordinator. I was never able to reproduce this.

[ebaauw]

Will provide the same workaround: whitelist the Analog Output, Multistate Output, and Lumi Specific clusters to skip the check.

Not too happy about that; the Output clusters are probably only used by Xiaomi window covering devices, but the Lumi Specific cluster is more common. Changed the workaround: now bluntly calling rx() before calling writeAttributes().

[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.

[github-actions]

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.