Deconz-rest-plugin: [Request Device Support] Aqara Curtain motor B1

[cacherocks]

Node Info

Basic cluster 0000

Identify cluster 0003

Windows covering cluster 0102

Analog Output (Basic) cluster 000D

Multistate Output (Basic) cluster 0013

Power Configuration cluster 0001

Node

Description

Works both with the battery and from power supply. Review.

[ebaauw]

It looks like the previous (mains powered) Aqara curtain controller (lumi.curtain), except that this is an end device instead of a router. The REST API plugin exposes a curtain controller as a /lights resource. We probably need to whitelist this device, because _Receiver on when idle_ is false.

I'm a bit worried that the _Windows Covering_ cluster doesn't provide _Current Position Lift Percentage_. It probably reports the position on the _Analog Output_ cluster. The REST API plugin already picks that up (the lumi.curtain uses both _Current Position Lift Percentage_ and the _Analog Output_ cluster), but for controlling the curtain, only the _Windows Covering_ cluster is used.

Can you check that the _Present Value_ of the _Analog Output_ cluster reports 0 when the curtains are closed and 100 when open?

Can you also check that it responds to the _Open_, _Close_, _Stop_ and _Go to lift percentage_ commands from the _Windows Covering_ cluster? Can you set _Reversed_ in _Config/Status_ to change the direction for _Open_ en _Close_ (in case you installed the band to pull the curtains the other way round)?

I'm afraid we need for the API v2 /devices resource scheme to expose the battery percentage; config.battery is available only to /sensors resources.

[cacherocks]

Ok, in the next 2-3 days I will check everything and write the result on all issues.

[cacherocks]

• If the curtains do not move, then the buttons from the cluster do not control them, but receive the answer "success".
• If the curtains are in the process of closing or opening, then the buttons from the cluster control (Open, Close and Stop). Lift value and lift percentage buttons do not work, but they get the answer "success"
• Present Value of the Analog Output cluster changes only from 0.00 to 1.00 during the opening of the curtains and returns to 0.00 again after opening. In the process of closing the curtains 0.00 does not change.
• I can not set the Reversed in Config/Status because Record button is inactive, below is a screenshot. My curtains open from the center to the edges.
  
• The values of open and closed are preserved from the aqara hub after binding to deconz.

[ebaauw]

• If the curtains do not move, then the buttons from the cluster do not control them, but receive the answer "success".
• If the curtains are in the process of closing or opening, then the buttons from the cluster control (Open, Close and Stop). Lift value and lift percentage buttons do not work, but they get the answer "success"

Odd. Does the curtain controller connect to the RaspBee/ConBee directly, or did it select another parent node?

Present Value of the Analog Output cluster changes only from 0.00 to 1.00 during the opening of the curtains and returns to 0.00 again after opening. In the process of closing the curtains 0.00 does not change.

On the old controller, it changes from 0.00 (closed) to 100.00 (open), after calibrating the controller. Just like _Current Position Life Percentage_. Does the controller react when you try and write _Present Value_? Does the _Multistate Output_ report anything?

I can not set the Reversed in Config/Status because Record button is inactive, below is a screenshot.

My bad, it's a read-only attribute. The setting is through _Mode_.

The values of open and closed are preserved from the aqara hub after binding to deconz.

Do you mean the calibration of the open and close position? Yes, that's handled by the motor itself, "behind" the ZigBee module. On the old model, you need to detach the ZigBee module to access the (other) reset button for the motor and make it re-calibrate.

[cacherocks]

Odd. Does the curtain controller connect to the RaspBee/ConBee directly, or did it select another parent node?

Directly, search and add through "add new light" via Phoscon.

My bad, it's a read-only attribute. The setting is through _Mode_.

I can set the checkbox and save the Reversed in Mode

Do you mean the calibration of the open and close position?

Yes.

On the old controller, it changes from 0.00 (closed) to 100.00 (open), after calibrating the controller. Just like _Current Position Life Percentage_. Does the controller react when you try and write _Present Value_? Does the _Multistate Output_ report anything?

No react, no report.

[deven2020]

Hi

Can you confirm if this works with deconz/conbee 2? I am planning to get one.

Appreciate your feedback.

[freenetwork]

Hello. This curtain is working?

[cacherocks]

Hello. This curtain is working?

Hi
Can you confirm if this works with deconz/conbee 2? I am planning to get one.
Appreciate your feedback.

Hi, unfortunately not, I'm still waiting for B1 support to be added to the deconz. Maybe support will appear in 2.05.67. Like this issue to show the importance of adding support for B1.

[cacherocks]

@ebaauw Should we expect support for Aqara B1 in Deconz 2.05.67?

[ebaauw]

Should we expect support for Aqara B1 in Deconz 2.05.67?

I’m not the person to answer that question. I am just a deCONZ user, who on occasion contributes to this open source

Should we expect support for Aqara B1?

To support the B1, we first need to understand how to control it, i.e. what ZigBee commands make it open, close, and hold the curtains, and how it reports the current curtain position. If it’s not through the _Window Covering_ nor through the _Analog Output_ cluster, I wouldn’t know how.

[freenetwork]

I test zigbee2mqtt and change config from aqara curtain for aqara curtain b1. It is working. But without battery state

I want to say that the control commands work with the previous non-battery version

One problem i cant get responce with current position

[cacherocks]

I want to say that the control commands work with the previous non-battery version

So it will be enough to clone the settings from the old version of the "lumi.curtain" for the new version of the b1 "lumi.curtain.hagl04", good news.

[ebaauw]

Not according to your own tests. We must understand how to control the B1 from the GUI, before we can support it in the API.

[freenetwork]

https://github.com/freenetwork/ZNCLDJ12LM

I capture packets. Controls messages use previous

[ebaauw]

Thanks. Very insightful.

• While battery powered, the B1 seems to poll it's parent every second.
• I see an attribute report for the Xiaomi special attribute with payload:
  01 21 b80b 04 21 9813 05 21 5d00 06 24 1ae108257c08 21 0c01 0a 21 0000 65 20 63 66 20 c3 67 20 0c 68 21 0202 64 20 00
• I see an attribute report for the the _Battery Level_ of the _Power Management cluster - that's a Xiaomi first;
• Unfortunately, that's were adhering to the standard seems to stop. It looks like Xioami use a bunch of manufacturer specific boolean attributes on the _Basic_ cluster to control the B1:
  
  
  
  • 0xff27 for store/clear position;
  
  
  • 0xff28 for enable/disable reverse curtain;
  
  
  • 0xff29 for enable/disable auto close.
  
  

Unfortunately, you didn't capture opening nor closing the B1. I bet they use special attributes for that as well. And for reporting the current position.

First order of business is defining these attributes in general.xml and see if the B1 can be controlled using the deCONZ GUI.

[freenetwork]

Ok. I try today.

I did not capture the opening and closing since the motor was on the table. it is not calibrated and in packets it would not be possible to determine correctly the current position. I’ll try at home today when the motor is on the ledge and write there

[freenetwork]

My radio broadcast is very full. For this status message is difficult to choose. I take screenshoots from wireshark. Control message work from old model.
I will try a new pairing at work, I hope the calibration from the motors will not disappear.
Unfortunately, I reset my gateway to get developer mode. And now the broadcast is very clogged with messages so that I catch a new key again

Open for 26 percent. It is current position response.

Open for 46 percent. It is current position response.

[cacherocks]

Working config Aqara B1 for Homebridge based on Xiaomi hub:
YinHangCode/homebridge-mi-aqara#272

[cacherocks]

Working config Aqara B1 for Home Assistant based on Xiaomi hub:
home-assistant/home-assistant#25942

[ebaauw]

@cacherocks, that won’t be of any help. These integrate with the API offered by the Xiaomi hub. For deCONZ support, we need to integrate with the B1 itself over ZigBee.

[cacherocks]

@cacherocks, that won’t be of any help. These integrate with the API offered by the Xiaomi hub. For deCONZ support, we need to integrate with the B1 itself over ZigBee.

ok, what other data is needed, at least for the test addition of the motor to the deconz? Even without a battery, the main thing is motor control. The data that @freenetwork provided is not enough?

[cacherocks]

@freenetwork says that the control commands for version B1 are the same as for the old version of the motor. It turns out that you just need to copy everything from lumi.curtain to lumi.curtain.hagl04. Obtaining data on the battery charge can be omitted, it is not as interesting as managing curtains. Please do a PR with a copy of the data from lumi.curtain to lumi.curtain.hagl04.

[ebaauw]

Please do a PR with a copy of the data from lumi.curtain to lumi.curtain.hagl04.

The code checks if the model identifier starts with lumi.curtain, so it already matches lumi.curtain.hagl04.

[ArkadiuszNiemiec]

I have just tried to pair my new B1 but it did not want to connect to Deconz. @ebaauw how can I help? I have the dongle for sniffer.

[ebaauw]

I’m afraid you need to sniff the ZigBee commands that the Aqara hub sends to the controller. As mentioned above, I suspect they use manufacturer-specific attributes to control and report the motor.

As for pairing: it should appear in the deCONZ GUI, see screenshots above.

[ArkadiuszNiemiec]

@ebaauw oh, ok. I was looking into Deconz web interface. I am away for two weeks so cannot do it now but I will update as soon as possible. Thank you for your great work :smile:
Edit: I am still learning but I hope that I will be able to contribute soon.

[bkorda]

How is the progress guys?

[ArkadiuszNiemiec]

How is the progress guys?

I gave up, sorry. Moved to zigbee2mqtt, it works there.

[bkorda]

How is the progress guys?

I gave up, sorry. Moved to zigbee2mqtt, it works there.

It's so sad. I wanna buy this one, but it stops me.

[netRunner0]

How is the progress guys?

I gave up, sorry. Moved to zigbee2mqtt, it works there.

It's so sad. I wanna buy this one, but it stops me.

Homebridge+mi hub

[bkorda]

How is the progress guys?

I gave up, sorry. Moved to zigbee2mqtt, it works there.

It's so sad. I wanna buy this one, but it stops me.

Homebridge+mi hub

It's not an option.

[rale]

Based on the packet captures and what I read so far, it looks like 0x0055 on Analog Output cluster should be what controls opening/closing. Unfortunately, it doesn't seem like I can write to that attribute with deconz gui. Unlike other data types, there's just no input field when I open it.

Also, hitting 'read' on this screen seems to crash deconz. Is this just a bug in deconz handling of float attributes then?

[ebaauw]

Indeed, I’m seeing the same for other devices with an _Analog Output_ or _Analog Input_ cluster. We’ve had issues with the deCONZ core program not handling more exotic data types before, but no crash. It does handle attribute reports for float values correctly, though.

If you’re comfortable reading packets captured by a sniffer, you might try the deconz-cli-plugin to write _Present Value_. I’m not sure how to encode float values, though. Best close the curtains manually and sniff the attribute report to see what the value looks like in the payload.

The lumi.curtain also advertises an _Analog Output_ cluster, whose _Present Value_ mirrors the _Current Position Lift Percentage_ from the _Window Covering_ cluster. I haven’t tried writing that attribute, though.

[rale]

Thanks for pointing me to the cli plugin. I was able to confirm that I can set position via 0x0055 on analog output. The values are just 32-bit floating points.

For example, this will set it to 90%:
zclattr 0xD8FD 1 0x000d 025500390000b44200

And this will do 50%:
zclattr 0xD8FD 1 0x000d 025500390000484200

[ebaauw]

That's the good news we've been waiting for!
Is 100.00 fully opened or fully closed?

I'm sorry, I fail to understand the payload: there seems to be a superfluous 00 at the end?

 |   | |       | |
 |   | |       | + ???
 |   | |       + Value: 0x42b40000 (90.0)
 |   | + Data type: 0x39 (float)
 |   + Attribute: 0x0055 (Present Value)
 + Command: 0x02 (Write Attributes)

0x42b40000 = 0b 0 10000101 01101000000000000000000 = 1.40625 * 2^6 = 90.0
                |        |                       + fraction: 0xb40000 / 2^23 = 1.40625
                |        + exponent: 0x85 - 127 = 6
                + sign: positive

0x42480000 = 0b 0 10000100 10010000000000000000000 = 1.5625 * 2^5 = 50.0
                |        |                       + fraction: 0xc80000 / 2^23 = 1.5625
                |        + exponent: 0x84 - 127 = 5
                + sign: positive

[ebaauw]

Could you try my commit above?

It should create a /lights resource for the B1, of type Window covering device, when you search for new devices from Phoscon or open the network from the old web app. state.on and state.bri should reflect the motor's state, but updating these attributes hasn't yet been implemented.

[rale]

Looks good, I have a light entry now. And you're correct, the extra 00 on the end wasn't needed, you can drop that.

As for the direction, 100 = fully opened, 0 = fully closed.

[bkorda]

So when do you plan support b1 motors in release (stable) version?

[FletchNZ]

Yeah, I would also be keen on getting this change pushed to production. Thanks heaps for your hard work and getting this supported!

[ebaauw]

Above commit should add support for controlling the B1 by setting state.bri. It works for my old model lumi.curtain, but can some-one (@rale maybe) please test it on an actual B1?

Setting state.on still doesn't work - I need to refactor DeRestPluginPrivate::setLightState(), so state.on can be translated to state.bri.

@manup, I had to duplicate the body from DeRestPluginPrivate::writeAttribute() code, since deCONZ::ZclAttribute doesn't handle deCONZ::ZclSingleFloat correctly (it sends 8 bytes instead of 4). Same happens when trying to write the attribute in the GUI.

[ebaauw]

Above commit provides full support for the B1:

• Setting state.bri writes the _Present Value_ attribute in the _Analog Output_ cluster;
• Setting state.on is handled like setting state.bri (as the B1 doesn't support _Up_ nor _Down_).
• Setting state.bri_inc to 0 results in an error, (as the B1 doesn't support _Stop_).

[ebaauw]

Can some-one please test and confirm that the B1 works in 2.05.75?

[rale]

It looks like state.bri is working correctly, but state.on is not.

Both true and false for on seem to result in bri being set to 0:

$ curl -X PUT -d '{"on":false }' -s http://127.0.0.1:8080/api/xxxxxxxxxx/lights/1/state | python -m json.tool
[
    {
        "success": {
            "/lights/1/state/bri": 0
        }
    }
]
$ curl -X PUT -d '{"on":true }' -s http://127.0.0.1:8080/api/xxxxxxxxxx/lights/1/state | python -m json.tool
[
    {
        "success": {
            "/lights/1/state/bri": 0
        }
    }
]

Setting on to true and bri to a value at the same time returns the intended bri value, but actually results in curtains moving to 0.

$ curl -X PUT -d '{"on": true, "bri":120 }' -s http://127.0.0.1:8080/api/xxxxxxxxxx/lights/1/state |  python -m json.tool
[
    {
        "success": {
            "/lights/1/state/bri": 120
        }
    }
]

[ebaauw]

Thanks for testing!

It looks like state.bri is working correctly

That's good news.

but state.on is not.

As the B1 has no _Open_ or _Close_ commands, on should be treated as bri 254 (true) or 0 (false). Looks like something is still going wrong there, between mapping on to bri, mapping bri to lift percentage, and inverting the lift percentage, because Xiaomi has the open and closed values reversed.

Both true and false for on seem to result in bri being set to 0

Do the curtains move alright, open for setting on to true, and close for setting on to false? Or do they move to 0 in both cases?

Setting on to true and bri to a value at the same time returns the intended bri value, but actually results in curtains moving to 0.

Not good. on should be ignored when bri is given.

[rale]

Do the curtains move alright, open for setting on to true, and close for setting on to false? Or do they move to 0 in both cases?

They move to 0 in both cases.

[ebaauw]

Can some-one please test and confirm that the B1 works in 2.05.76?

[krastek]

Just a quick feedback:
I use Conbee II with Home Assistant 0.109.2 on top of RaspberryPi3. I updated the firmware to 2.05.76 and have successfuly addedd B1 to the system.
I can open, close, set the position of the curtain from HA. The state is always reported as closed and position as 0.
Deconz GUI gives me no possibility of moving the curtain. It doesn't report the correct state of the curtain either - it is always on with full brightness.
Thank you for pushing this forward!

[ebaauw]

The B1 doesn’t use the _Window Covering_ cluster. Set _Present Value_ of the _Analog Output_ cluster from the GUI.

Can you read that cluster in the GUI, and see if the state gets updated in HA? Can you check what the API responds when GETting the B1’s /lights resource?

[krastek]

Disclaimer: Please note that my knowledge on the subject of digging information from deconz is virtually non existent. I just happen to be using HA+Conbee and wanting to have a usable Aqara B1.
Getting to your questions:
I managed to "read" Analog Output Cluster/Present value and it got picked by HA.
Unfortunately I don't know how to check the thing with API. I can do it, if I get instructions, though, but I won't be offended, if you'd prefer to get the information from someone with better understanding of all this.

[ebaauw]

I managed to "read" Analog Output Cluster/Present value and it got picked by HA.

So that's good news: at least the value gets propagated from the device through deCONZ through the REST API to HA. What worries me is that the device doesn't send a report attributes notification when it changes state. This is Xiaomi, it doesn't support configuration; it should just work. Could you power cycle the motor (disconnect the battery for 10 sec), fully open/close it (so it gets a feel for the distance to scale the percentage) and see if it updates after that?

Unfortunately I don't know how to check the thing with API. You need to do a GET of the corresponding /lights resource. I use ph for that, which is a little tool I wrote to troubleshoot for Homebridge Hue, but any REST API client (like postman or even curl) would do. See the README for a link to the API documentation.

[krastek]

I'm sorry, I haven't had time for this matter lately.
Just a quick update: I tried to power on/off the device. Unfortunately it didn't help to solve "no status reports" problem.
I'll try to get to the API business this weekend.

[stale[bot]]

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.

[arthurGrigo]

I'm sorry, I haven't had time for this matter lately.
Just a quick update: I tried to power on/off the device. Unfortunately it didn't help to solve "no status reports" problem.
I'll try to get to the API business this weekend.

Really interested in the B1 support. Could you test it already? @krastek

[stale[bot]]

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.

[NMGAndy]

Hi! Is the motor supported now?

[krastek]

Nothing has changed since my last reply - you can open/close/set position, but you don't get a status of the device.

[krastek]

This topic has already been closed, but I'll post a reply to @ebaauw request to do GET on /lights.
Here's what I receive:
{
"etag": "a405b9b8ded0f0747f539b6fd08f214f",
"hascolor": false,
"lastannounced": "2020-10-29T15:19:00Z",
"lastseen": "2020-10-29T15:42Z",
"manufacturername": "LUMI",
"modelid": "lumi.curtain.hagl04",
"name": "Zasłony - Sypialnia",
"state": {
"bri": 25,
"lift": 10,
"on": true,
"open": true,
"reachable": true
},
"swversion": null,
"type": "Window covering device",
"uniqueid": "04:cf:8c:df:3c:75:46:c1-01"
}
"lift" doesn't reflect curtain's current postition unless I do a "read" of the "Present Value" in deconz firt.
"llift" resets to 100 every time I change curtain's position.

[ebaauw]

"lift" doesn't reflect curtain's current postition unless I do a "read" of the "Present Value" in deconz firt.

Does _Present Value_ already reflect the actual position before the _Read_, or only after it?

"llift" resets to 100 every time I change curtain's position.

Can you check the value of the _Current Position Lift Percentage_ in the _WIndow Covering cluster? What happens if you read this attribute (after you read the _Present Value_ in the _Analog Output_ cluster)?

My guess is:

• either the B1 doesn't report _Present Value_, in which case we need to check whether binding and attribute reporting can be configured;
• or the B1 reports _Present Value_, but also _Current Position Lift Percentage_, which doesn't reflect the current position. In this case, the REST API needs to ignore the report for _Current Position Lift Percentage_.

To figure out what's happening, we would need a sniffer log of the Zigbee traffic; alternatively, run deCONZ with --dbg-info=2 and look for the APS-DATA.indication messages from the B1 in the log.

[krastek]

Does Present Value already reflect the actual position before the Read, or only after it?

Only after.

Can you check the value of the Current Position Lift Percentage in the _WIndow Covering cluster? What happens if you read this attribute (after you read the Present Value in the Analog Output cluster)?

Attribute unsupported.

To figure out what's happening, we would need a sniffer log of the Zigbee traffic; alternatively, run deCONZ with --dbg-info=2 and look for the APS-DATA.indication messages from the B1 in the log.

I'll need more time for that, so I hope I'll manage to do that this weekend.

[ebaauw]

OK, so it looks like the B1 simply isn't reporting the _Present Value_. Could you try in the GUI to set up a binding from the _Analog Output_ cluster to the coordinator, and to configure reporting for _Present Value_ (values 1/300/1 should be OK). See the _User Manual_ under _Help_ how to do this. If this works, could you try the same for the _Power Configuration_ cluster and the _Battery Percentage Remaining_ attribute (with values 7200/7200/0).

[krastek]

Should the binding be created to Home automation configuration tool or dresden elektronik configuration tool?

[SwoopX]

First one.
https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/How-to...#manually-bind-server-clusters

[krastek]

I did the binding and then tried to configure the reporting, but unfortunately the attribute is unreportable.

[ebaauw]

Unfortunately, that doesn’t come as a big surprise for a Xiaomi device. I cannot imagine that the B1 doesn’t report the current position somehow, but without having access to the device it will be hard for me to find out how. Really need a sniffer log, or debug log from deCONZ.

I assume just creating the binding didn’t result in the position being reported?

[SwoopX]

According to z2m, the binding should be sufficient and the device sends those attributes.

[krastek]

According to z2m, the binding should be sufficient and the device sends those attributes.

I double checked that. The binding alone changes nothing: I don't see values udating in HA unless I do a "Read" in decons.

I run deconz with debug 2. Here are several entries starting with aps-data.indication. I was gathering data while making the curtain go to positions 0,10,20,50

`
16:58:37:948 APS-DATA.indication from child 0x0100
16:58:37:949 Node data 0x04cf8cdf3c7546c1 profileId: 0x0104, clusterId: 0x000D
16:58:37:949 0x04CF8CDF3C7546C1: update ZCL value 0x01/0x000D/0x0055 after 0 s
16:58:37:950 ZCL attribute report 0x04CF8CDF3C7546C1 for cluster: 0x000D, ep: 0x01, frame control: 0x18, mfcode: 0x0000
16:58:37:950 payload: 5500390000004000f02300000200

16:58:37:954 APS-DATA.indication from child 0x0100
16:58:37:955 Node data 0x04cf8cdf3c7546c1 profileId: 0x0104, clusterId: 0x000D
16:58:37:955 0x04CF8CDF3C7546C1: update ZCL value 0x01/0x000D/0x0055 after 0 s
16:58:37:956 ZCL attribute report 0x04CF8CDF3C7546C1 for cluster: 0x000D, ep: 0x01, frame control: 0x18, mfcode: 0x0000
16:58:37:956 payload: 5500390000000000f02300000200
16:58:37:956 Websocket 172.30.32.1:33290 send message: {"e":"changed","id":"3","r":"lights","state":{"bri":254,"lift":100,"on":true,"open":false,"reachable":true},"t":"event","uniqueid":"04:cf:8c:df:3c:75:46:c1-01"} (ret = 160)
16:58:37:961 Websocket 172.30.32.1:33290 send message: {"e":"changed","id":"3","r":"lights","state":{"bri":254,"lift":100,"on":true,"open":false,"reachable":true},"t":"event","uniqueid":"04:cf:8c:df:3c:75:46:c1-01"} (ret = 160)
16:58:37:962 discard light state push for 3: state/bri (already pushed)

17:01:16:259 APS-DATA.indication from child 0x0100
17:01:16:259 Node data 0x04cf8cdf3c7546c1 profileId: 0x0104, clusterId: 0x000D
17:01:16:260 0x04CF8CDF3C7546C1: update ZCL value 0x01/0x000D/0x0055 after 0 s
17:01:16:260 ZCL attribute report 0x04CF8CDF3C7546C1 for cluster: 0x000D, ep: 0x01, frame control: 0x18, mfcode: 0x0000
17:01:16:260 payload: 5500390000004000f02300000200

17:04:34:158 APS-DATA.indication from child 0x0100
17:04:34:158 verify 0x04cf8cdf3c7546c1 is child node after 865072 s
17:04:34:158 Node data 0x04cf8cdf3c7546c1 profileId: 0x0104, clusterId: 0x000D
17:04:34:159 0x04CF8CDF3C7546C1: update ZCL value 0x01/0x000D/0x0055 after 0 s
17:04:34:165 ZCL attribute report 0x04CF8CDF3C7546C1 for cluster: 0x000D, ep: 0x01, frame control: 0x18, mfcode: 0x0000
17:04:34:165 payload: 5500390000004000f02300000200
17:04:34:170 Websocket 172.30.32.1:33290 send message: {"e":"changed","id":"3","r":"lights","state":{"bri":248,"lift":98,"on":true,"open":true,"reachable":true},"t":"event","uniqueid":"04:cf:8c:df:3c:75:46:c1-01"} (ret = 158)
17:04:34:171 verify neighbor status: APP_SUCCESS (0x00)
17:04:34:172 discard light state push for 3: state/open (already pushed)
17:04:34:173 discard light state push for 3: state/bri (already pushed)
1
7:04:34:175 APS-DATA.indication from child 0x0100
17:04:34:175 Node data 0x04cf8cdf3c7546c1 profileId: 0x0104, clusterId: 0x000D
17:04:34:176 0x04CF8CDF3C7546C1: update ZCL value 0x01/0x000D/0x0055 after 0 s
17:04:34:185 ZCL attribute report 0x04CF8CDF3C7546C1 for cluster: 0x000D, ep: 0x01, frame control: 0x18, mfcode: 0x0000
17:04:34:185 payload: 5500390000000000f02300000200
17:04:34:191 Websocket 172.30.32.1:33290 send message: {"e":"changed","id":"3","r":"lights","state":{"bri":254,"lift":100,"on":true,"open":false,"reachable":true},"t":"event","uniqueid":"04:cf:8c:df:3c:75:46:c1-01"} (ret = 160)
17:04:34:193 discard light state push for 3: state/open (already pushed)

postion: 20
17:09:11:342 APS-DATA.indication from child 0x0100
17:09:11:342 Node data 0x04cf8cdf3c7546c1 profileId: 0x0104, clusterId: 0x000D
17:09:11:343 0x04CF8CDF3C7546C1: update ZCL value 0x01/0x000D/0x0055 after 0 s
17:09:11:349 ZCL attribute report 0x04CF8CDF3C7546C1 for cluster: 0x000D, ep: 0x01, frame control: 0x18, mfcode: 0x0000
17:09:11:349 payload: 5500390000004000f02300000200

postion: 0
17:11:10:942 APS-DATA.indication from child 0x0100
17:11:10:943 Node data 0x04cf8cdf3c7546c1 profileId: 0x0104, clusterId: 0x000D
17:11:10:943 0x04CF8CDF3C7546C1: update ZCL value 0x01/0x000D/0x0055 after 0 s
17:11:10:948 ZCL attribute report 0x04CF8CDF3C7546C1 for cluster: 0x000D, ep: 0x01, frame control: 0x18, mfcode: 0x0000
17:11:10:948 payload: 5500390000000000f02300000200

postion: 50
17:13:41:565 APS-DATA.indication from child 0x0100
17:13:41:565 Node data 0x04cf8cdf3c7546c1 profileId: 0x0104, clusterId: 0x000D
17:13:41:566 0x04CF8CDF3C7546C1: update ZCL value 0x01/0x000D/0x0055 after 0 s
17:13:41:570 ZCL attribute report 0x04CF8CDF3C7546C1 for cluster: 0x000D, ep: 0x01, frame control: 0x18, mfcode: 0x0000
17:13:41:570 payload: 5500390000004000f02300000200
17:13:41:572 Websocket 172.30.32.1:33290 send message: {"e":"changed","id":"3","r":"lights","state":{"bri":248,"lift":98,"on":true,"open":true,"reachable":true},"t":"event","uniqueid":"04:cf:8c:df:3c:75:46:c1-01"} (ret = 158)
17:13:41:573 APS-DATA.indication from child 0x0100
17:13:41:573 Node data 0x04cf8cdf3c7546c1 profileId: 0x0104, clusterId: 0x000D
17:13:41:574 0x04CF8CDF3C7546C1: update ZCL value 0x01/0x000D/0x0055 after 0 s
17:13:41:577 ZCL attribute report 0x04CF8CDF3C7546C1 for cluster: 0x000D, ep: 0x01, frame control: 0x18, mfcode: 0x0000
17:13:41:577 payload: 5500390000000000f02300000200
17:13:41:580 Websocket 172.30.32.1:33290 send message: {"e":"changed","id":"3","r":"lights","state":{"bri":254,"lift":100,"on":true,"open":false,"reachable":true},"t":"event","uniqueid":"04:cf:8c:df:3c:75:46:c1-01"} (ret = 160)
17:13:41:582 discard light state push for 3: state/bri (already pushed)
17:13:41:584 discard light state push for 3: state/lift (already pushed)
17:13:41:585 discard light state push for 3: state/open (already pushed)
17:13:41:586 discard light state push for 3: state/bri (already pushed)
`

BTW: can I access deconz log file somehow? Right now the only way to access log is throughs HA's GUI which is not very convenient.

[ebaauw]

So the B1 does send attribute reports for 0x0055 and 0x00F0. I’m not good at manually deciphering float values, but I’m seeing two different values, corresponding to a lift value of 98 and 100. Oddly the second report arrives within 10ms of the first, overwriting the 98.

[krastek]

Is it a good thing? Given the fact that the reported values are incorrect? I mean in some cases 100 was truly what was requested, but most of the time I asked for 90, 80, 50 (in HA it will be 10, 20, 50), so even 98 that occurs in the reports from time to time is incorrect.

[ebaauw]

It's a good thing that the B1 is reporting something; it's a bad thing that it's reporting nonsense. I'd try a full reset, not just of the Zigbee module, but also of the motor, and a recalibration of the open and close positions. I don't have a B1 myself and I'm at a loss what's happening otherwise.