Add static definition for Xiaomi Wireless 2-Button Switch #379
Conversation
Signed-off-by: Pedro Garcia <[email protected]>
Signed-off-by: Pedro Garcia <[email protected]>
|
Thanks @puzzle-star ! Just to avoid misunderstandings: Using a static thing type definition for this switch is required, as the device does not correctly announce the clusters in its simple descriptors, right? I think it could be useful to have the reason documented with a comment in the thing type XML, wdyt? |
|
Right. It reports the wrong set of clusters, but suports the (non reported) switch cluster Ok to document in the XML (I assume there is a way it can be seen in the GUI). Will change it. |
|
@puzzle-star , how did you find out, that it was these clusters? I have another PR (#346) that implements static definitions for another xiaomi switch and I am wondering if I missed the "normal" commands, because I did not bind the relevant cluster. |
|
When the descriptors are retrieved, they will be shown in the logs - you can se then what clusters are supported by the endpoint (assuming they are reported in the descriptor - which is not always the case with these devices!).
… On 4 Feb 2019, at 07:28, Thomas Weißschuh ***@***.***> wrote:
@puzzle-star <https://github.com/puzzle-star> , how did you find out, that it was these clusters?
Did the button presses show up in the zigbee traces even without binding these clusters, or do you have a way to bind all clusters and see what happens when pressing a button.
I have another PR (#346 <#346>) that implements static definitions for another xiaomi switch and I am wondering if I missed the "normal" commands, because I did not bind the relevant cluster.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#379 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQ6N3Y5MlfSxdRA7ihc68vOYNOPnwks5vJ-EngaJpZM4af-wN>.
|
|
@cdjackson , I know about these. Afaik I have to subscribe to these clusters to receive their commands. |
|
Ok, you asked if the logging showed the clusters - so this was the answer to that question ;)
No - you can’t just subscribe (ie bind) to all clusters. A device will have a limit to the number of clusters that can be bound in its binding table - on some devices, this may be limited to a single entry (some Hue bulbs are like this) - other devices will allow 2 or 3, and some will allow many more. Subscribing to all clusters will likely cause problems, and then you also need to enable reporting.
… On 4 Feb 2019, at 11:15, Thomas Weißschuh ***@***.***> wrote:
@cdjackson <https://github.com/cdjackson> , I know about these. Afaik I have to subscribe to these clusters to receive their commands.
Is there a way of subscribing all clusters while developing a new config. Then I could press the button a look at the zigbee debug log to see which command was actually sent.
(This is how I found out about the attribute reports of the other switch).
So I don't have to try each cluster own-by-one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#379 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQ-cVZCE8HGq6Wrn7EEk43-UCewSCks5vKBZagaJpZM4af-wN>.
|
Signed-off-by: Pedro Garcia <[email protected]>
Signed-off-by: Pedro Garcia <[email protected]>
Signed-off-by: Pedro Garcia <[email protected]>
|
Hi @hsudbrock and @cdjackson
done :-) |
|
Thanks @puzzle-star - but - I'm not sure this is the best approach. Do we really think that users need to know about this? Personally, I don't think so - I would personally suggest to put this as a comment in the XML rather than putting it into the thing type description. Ideally, users don't need to know if this is a static thing type, or dynamic, or the reason why it's one or the other - they just need to know it works and I think this should not be provided to users. If @hsudbrock thinks that users need to know this information, then maybe I can be convinced, but my preference is not to have this displayed in the UI. |
|
Hi @cdjackson,
I tend to agree, but also I am seing the "add manually list" starting to grow, with lots of devices that cannot really be added manually, maybe a "Not to be added manually" note on a newline should anyway be added? |
|
We can fix this - there is an XML flag that can be added to stop it appearing in the list - I agree that we should add this (as we do in ZWave). I’ll dig it out...
… On 9 Feb 2019, at 10:26, Pedro ***@***.***> wrote:
Hi @cdjackson <https://github.com/cdjackson>,
Ideally, users don't need to know if this is a static thing type, or dynamic, or the reason why it's one or the other - they just need to know it works and I think this should not be provided to users.
I tend to agree, but also I am seing the "add manually list" starting to grow, with lots of devices that cannot really be added manually, maybe a "Not to be added manually" note on a newline should anyway be added?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#379 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQxm2mdikBet1ep5U8vcI9D86u4L1ks5vLqJsgaJpZM4af-wN>.
|
|
If we add I actually suggest that we do this for all static thing types - I meant to start doing this a while back, but forgot... |
|
OK. I think that approach is better, but I would suggest then to leave the comment in the description in a newline, separated by a "br" html tag. According to the thing xml documentation, this should be the way to have GUIs showing the first line in short representations. I would suggest to keep the description separated by a BR, and adding the listed="false" What do you think? |
|
Why do you think we need this in the description? Personally, I think it should be a comment in the XML - not part of the thing description. This is an implementation issue, and I don’t think the user should care about this.
… On 9 Feb 2019, at 10:33, Pedro ***@***.***> wrote:
OK. I think that approach is better, but I would suggest then to leave the comment in the description in a newline, spearated by "
" (according to the thing xml documentation, this should be the way to have GUIs showing the first line in short representations).
I would suggest to keep the description separated by a BR, and adding the listed="false"
What do you thing?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#379 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQ-4GyfnW_abfftC0Zz5BTuE3Xcnvks5vLqQRgaJpZM4af-wN>.
|
|
OK, then, will leave it in a comment in the XML, out of the description |
|
Thanks.
… On 9 Feb 2019, at 10:37, Pedro ***@***.***> wrote:
OK, then, will leave it in a comment in the XML, out of the description
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#379 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_kQ20N1Sj5dWvbfo5wrUb__UPJjdaSks5vLqTngaJpZM4af-wN>.
|
Signed-off-by: Pedro Garcia <[email protected]>
|
Done. Once this is merged, I will do a PR to add the listed="false" to the other static thing definitions, to clean up the list |
|
Thanks Pedro. |
No, my suggestion above was also to merely add a comment to the XML - sorry if what I wrote was ambiguous. Thanks for adding this thing type! |
|
Hi @hsudbrock , Already discussed and agreed with @cdjackson (and fixed) :-) |
This adds support for the non-standard Xiaomi lumi.sensor_86sw2, the two button wireless (battery powered) switches.
It adds three channels (switch_onoff cluster at endpoints 1, 2 and 3), for left button (switch_1), right button (switch_2) and both buttons at the same time (switch_3)