Add support for round Xiaomi Mijia wireless switch.

[elfman03]

The Xiaomi Mijia wireless switch is a round button. Like a lot of the other LUMI devices, it does not report its clusters correctly and needs to be defined via xml to register correctly. This patterns an xml file based on the other similar Xiaomi devices.

I verified that it works with a Xiaomi Mijia button that I have.

Signed-off-by: Chris Elford elfman03@gmail.com (github: elfman03) Signed-off-by: Chris Elford elfman03@gmail.com

[elfman03]

I believe I removed all the ones you were concerned about.

If desired, I could probably also remove the name="zigbee_inputclusters" 6 property. I had hoped that line would prevent the binding from temporarily promoting switch_onoff (channel 6) to zigbee:switch_level (channel 8).
2021-11-18 21:50:27.970 [DEBUG] [er.ZigBeeChannelConverterFactoryImpl] - 00158D000186EC2E: Removing channel zigbee:switch_onoff in favor of zigbee:switch_level But it appears that it still promotes to zigbee:switch_level then falls back to channel 6 after a minute or so. So that zigbee_inputclusters line might not actually be doing anything useful and could be a candidate for removal if desired.

[cdjackson]

I'm a bit surprised that you say you can also remove the cluster - if you remove that, then this XML is not really doing anything. What does this device actually return for the simple descriptor? Is there really a need for this XML?

[elfman03]

I'll do some more iterations of testing early next week with different modes and report back.

My impression from the few iterations yesterday was that even empty it still provides a visual indicator that pairing has progressed to a point you can stop fiddling with the pairing button in scan mode because a new named line shows up which indicates the necessary data has propagated rather than the zigbee:generic which shows up on earlier attempts.

[cdjackson]

I don't want to add a static thing definition just so that you get a specific thing type - that's not the way this binding works. It is meant to automatically detect channels - not to use static thing types unless something isn't working correctly with the channel detection. In ZWave we have to maintain a database, and it's a real pain and give the zigbee binding was written after new features were added to OH to support dynamic channel generation, that's what we use.

Once the data that is used for thing selection is received, it is added as properties - this includes the modelId, vendor, and some version identifiers, so there is already data to identify the device and the only extra thing you get is the thing type.

Please provide the full debug log of the initialisation so we can see what's happening and see what is defined. If there's no need for the static thing then we shouldn't have it.

[elfman03]

On further testing, it looks like the endpoint and channel definition are both needed as in the latest patch from last week. Without them while the device gets close to completely detecting, but it gets stuck thinking it is a switch_level rather than a switch_onoff and doesn't seem to eventually fall back to switch_onoff.

2021-11-27 14:10:48.701 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: IeeeAddressRequest [0000/0 -> 3493/0, cluster=0001, TID=22, nwkAddrOfInterest=3493, requestType=1, startIndex=0]
2021-11-27 14:10:48.702 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0000/0, destinationAddress=3493/0, profile=0000, cluster=0001, addressMode=DEVICE, radius=8, apsSecurity=false, ackRequest=true, apsCounter=2F, rssi=--, lqi=--, payload=22 93 34 01 00]
2021-11-27 14:10:48.704 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH TX EZSP: EzspSendUnicastRequest [networkId=0, type=EMBER_OUTGOING_DIRECT, indexOrDestination=3493, apsFrame=EmberApsFrame [profileId=0000, clusterId=0001, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_RETRY, EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY], groupId=0, sequence=2F], messageTag=22, messageContents=22 93 34 01 00]
2021-11-27 14:10:48.708 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-11-27 14:10:48.713 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=5, ackNum=4, reTx=false, data=D5 00 34 00 93 34 00 00 01 00 00 00 40 11 00 00 2F 22 05 22 93 34 01 00]
2021-11-27 14:10:48.714 [DEBUG] [transaction.ZigBeeTransactionManager] - Transaction Manager: Send Next transaction. outstandingTransactions=1, outstandingQueues=0, sleepy=0/3
2021-11-27 14:10:48.723 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=4, ackNum=6, reTx=false, data=D5 80 34 00 54]
2021-11-27 14:10:48.728 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=5, ackNum=4, reTx=false, data=D5 00 34 00 93 34 00 00 01 00 00 00 40 11 00 00 2F 22 05 22 93 34 01 00]
2021-11-27 14:10:48.729 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH took EZSP frame from receive queue. Queue length 0
2021-11-27 14:10:48.730 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspSendUnicastResponse [networkId=0, status=EMBER_SUCCESS, sequence=54]
2021-11-27 14:10:48.731 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH added EZSP frame to receive queue. Queue length 0
2021-11-27 14:10:48.732 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=5, notRdy=false]
2021-11-27 14:10:48.738 [DEBUG] [er.ZigBeeChannelConverterFactoryImpl] - 00158D000186EC2E: Removing channel zigbee:switch_onoff in favor of zigbee:switch_level
2021-11-27 14:10:48.744 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=5, ackNum=6, reTx=false, data=D5 90 3F 00 93 34 00 00 01 00 00 00 40 11 00 00 54 22 00 00]
2021-11-27 14:10:48.745 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH took EZSP frame from receive queue. Queue length 0
2021-11-27 14:10:48.746 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspMessageSentHandler [networkId=0, type=EMBER_OUTGOING_DIRECT, indexOrDestination=3493, apsFrame=EmberApsFrame [profileId=0000, clusterId=0001, sourceEndpoint=0, destinationEndpoint=0, options=[EMBER_APS_OPTION_RETRY, EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY], groupId=0, sequence=54], messageTag=22, status=EMBER_SUCCESS, messageContents=]

log attached.

openhab.zip

[cdjackson]

endpoint and channel definition are both needed

Well, the log shows this should not be needed as the simple descriptor already defines the endpoint -:

SimpleDescriptorResponse [5C53/0 -> 0000/0, cluster=8004, TID=12, status=SUCCESS, nwkAddrOfInterest=5C53, length=30, simpleDescriptor=SimpleDescriptor [endpoint=1, profileId=0104, deviceId=0104, deviceVersion=1, inputClusterList=[0000, 0003, FFFF, 0019], outputClusterList=[0000, 0004, 0003, 0006, 0008, 0005, 0019]]]

it gets stuck thinking it is a switch_level rather than a switch_onoff and doesn't seem to eventually fall back to switch_onoff.

The binding is designed to provide channels based on the devices features, and it does sound that's working ok? As we see above, the simple descriptor defines that it supports both the level control and onoff clusters, so we end up with a level type channel.

I'm not sure if you really gain anything you adding a static definition just to change the level to onoff? I just prefer to avoid static definitions if at all possible and it seems here that there is no functionality missing - or am I missing something obvious? :)

[elfman03]

As nearly as I can tell, it doesn't actually support the level control despite it's detection. The device doesn't come online as a device_level.

If you don't want the patch, it's fine, I'll just build from source whenever I need to update openhab.

[cdjackson]

Again though, I’m trying to work out what this gains? You have the onoff cluster, so it should work just fine shouldn’t it? I appreciate that changing this from level to onoff is a bit neater, but it doesn’t change anything functionally.

Maybe it doesn’t support level control, although you say “as far as you can tell”. Adding this PR to remove it means that a) if you are wrong, or b) if there is a different version that does support it, users will not be able to. I just think that if the device works as it is detected, then why make this aesthetic change?

On 28 Nov 2021, at 12:06, elfman03 @.***> wrote:

 As nearly as I can tell, it doesn't actually support the level control despite it's detection. The device doesn't come online as a device_level.

If you don't want the patch, it's fine, I'll just build from source whenever I need to update openhab.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[elfman03]

As near as I can tell, the underlying binding removes the onoff channel when its all auto detected.

[er.ZigBeeChannelConverterFactoryImpl] - 00158D000186EC2E: Removing channel zigbee:switch_onoff in favor of zigbee:switch_level 2021-11-27 14:10:48.744 [DEBUG]

[cdjackson]

As near as I can tell, the underlying binding removes the onoff channel when its all auto detected.

Yes, of course, but that doesn't matter. You have the level control channel and in OH channels inherit their functionality - so a color channel inherits the functions of a level control and on off channels, and a level control inherits the functionality of an onoff channel. So you can still send an OnOff command to a dimmer channel, and if the onoff command is received in a level control channel, the state will be set to on or off.

Functionally, it should be the same. We don't just remove the onoff channel and not give users any way to interact with onoff functions of a device.

[elfman03]

I don't know what else to log to help understand why it doesn't come online without this xml.

[cdjackson]

What is the actual problem? It sounds like it is detected and you get the channel, so what is the problem you’re seeing? Do you have a log showing what is received (not during initialisation, but in operation). If the device is offline then that could be caused for other issues.

Sent from my iPhone

On 28 Nov 2021, at 14:01, elfman03 @.***> wrote:

 I don't know what else to log to help understand why it doesn't come online without this xml.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[elfman03]

I attached a ziplog that included both detection and then button presses this afternoon. At button press time, it gets

2021-11-27 14:10:00.315 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspIncomingMessageHandler [networkId=0, type=EMBER_INCOMING_UNICAST, apsFrame=EmberApsFrame [profileId=0104, clusterId=0006, sourceEndpoint=1, destinationEndpoint=1, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY], groupId=0, sequence=78], lastHopLqi=255, lastHopRssi=-46, sender=3493, bindingIndex=255, addressIndex=255, messageContents=18 04 0A 00 00 10 01]
2021-11-27 14:10:00.316 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH added EZSP frame to receive queue. Queue length 0
2021-11-27 14:10:00.318 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=3493/1, destinationAddress=0000/1, profile=0104, cluster=0006, addressMode=DEVICE, radius=0, apsSecurity=false, ackRequest=false, apsCounter=78, rssi=-46, lqi=FF, payload=18 04 0A 00 00 10 01]
2021-11-27 14:10:00.320 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=1, notRdy=false]
2021-11-27 14:10:00.322 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 00158D000186EC2E: Node update. NWK Address=3493
2021-11-27 14:10:00.324 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 00158D000186EC2E: Node 3493 is not updated
2021-11-27 14:10:00.325 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=4, commandId=10]
2021-11-27 14:10:00.326 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [On/Off: 3493/1 -> 0000/1, cluster=0006, TID=04, reports=[AttributeReport [attributeDataType=BOOLEAN, attributeIdentifier=0, attributeValue=true]]]
2021-11-27 14:10:00.327 [DEBUG] [transaction.ZigBeeTransactionManager] - notifyTransactionCommand: ReportAttributesCommand [On/Off: 3493/1 -> 0000/1, cluster=0006, TID=04, reports=[AttributeReport [attributeDataType=BOOLEAN, attributeIdentifier=0, attributeValue=true]]] 
2021-11-27 14:10:01.182 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-11-27 14:10:01.185 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=6, ackNum=1, reTx=false, data=A6 00 18]
2021-11-27 14:10:01.191 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=1, ackNum=7, reTx=false, data=A6 80 18 02]
2021-11-27 14:10:01.192 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=6, ackNum=1, reTx=false, data=A6 00 18]
2021-11-27 14:10:01.193 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH took EZSP frame from receive queue. Queue length 0
2021-11-27 14:10:01.194 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH added EZSP frame to receive queue. Queue length 0
2021-11-27 14:10:01.195 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=2, notRdy=false]
2021-11-27 14:10:02.195 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-11-27 14:10:02.198 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=7, ackNum=2, reTx=false, data=A7 00 18]
2021-11-27 14:10:02.204 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=2, ackNum=0, reTx=false, data=A7 80 18 02]
2021-11-27 14:10:02.205 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=7, ackNum=2, reTx=false, data=A7 00 18]
2021-11-27 14:10:02.206 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH took EZSP frame from receive queue. Queue length 0
2021-11-27 14:10:02.207 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH added EZSP frame to receive queue. Queue length 0
2021-11-27 14:10:02.208 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=3, notRdy=false]
2021-11-27 14:10:03.210 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-11-27 14:10:03.215 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=0, ackNum=3, reTx=false, data=A8 00 18]
2021-11-27 14:10:03.221 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=3, ackNum=1, reTx=false, data=A8 80 18 02]
2021-11-27 14:10:03.221 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=0, ackNum=3, reTx=false, data=A8 00 18]
2021-11-27 14:10:03.222 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH took EZSP frame from receive queue. Queue length 0
2021-11-27 14:10:03.223 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH added EZSP frame to receive queue. Queue length 0
2021-11-27 14:10:03.225 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=4, notRdy=false]
2021-11-27 14:10:03.573 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=4, ackNum=1, reTx=false, data=A8 90 45 00 04 01 00 00 01 01 00 01 00 00 79 FF D2 93 34 FF FF 19 18 05 0A 05 00 42 12 6C 75 6D 69 2E 73 65 6E 73 6F 72 5F 73 77 69 74 63 68]
2021-11-27 14:10:03.580 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH took EZSP frame from receive queue. Queue length 0
2021-11-27 14:10:03.581 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspIncomingMessageHandler [networkId=0, type=EMBER_INCOMING_UNICAST, apsFrame=EmberApsFrame [profileId=0104, clusterId=0000, sourceEndpoint=1, destinationEndpoint=1, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY], groupId=0, sequence=79], lastHopLqi=255, lastHopRssi=-46, sender=3493, bindingIndex=255, addressIndex=255, messageContents=18 05 0A 05 00 42 12 6C 75 6D 69 2E 73 65 6E 73 6F 72 5F 73 77 69 74 63 68]
2021-11-27 14:10:03.582 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=3493/1, destinationAddress=0000/1, profile=0104, cluster=0000, addressMode=DEVICE, radius=0, apsSecurity=false, ackRequest=false, apsCounter=79, rssi=-46, lqi=FF, payload=18 05 0A 05 00 42 12 6C 75 6D 69 2E 73 65 6E 73 6F 72 5F 73 77 69 74 63 68]
2021-11-27 14:10:03.583 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 00158D000186EC2E: Node update. NWK Address=3493
2021-11-27 14:10:03.584 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH added EZSP frame to receive queue. Queue length 0
2021-11-27 14:10:03.585 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 00158D000186EC2E: Node 3493 is not updated
2021-11-27 14:10:03.586 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=5, notRdy=false]
2021-11-27 14:10:03.587 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=5, commandId=10]
2021-11-27 14:10:03.596 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Basic: 3493/1 -> 0000/1, cluster=0000, TID=05, reports=[AttributeReport [attributeDataType=CHARACTER_STRING, attributeIdentifier=5, attributeValue=lumi.sensor_switch]]]
2021-11-27 14:10:03.601 [DEBUG] [transaction.ZigBeeTransactionManager] - notifyTransactionCommand: ReportAttributesCommand [Basic: 3493/1 -> 0000/1, cluster=0000, TID=05, reports=[AttributeReport [attributeDataType=CHARACTER_STRING, attributeIdentifier=5, attributeValue=lumi.sensor_switch]]] 
2021-11-27 14:10:04.225 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-11-27 14:10:04.226 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=1, ackNum=5, reTx=false, data=A9 00 18]
2021-11-27 14:10:04.231 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=5, ackNum=2, reTx=false, data=A9 80 18 02]
2021-11-27 14:10:04.232 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=1, ackNum=5, reTx=false, data=A9 00 18]
2021-11-27 14:10:04.233 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH took EZSP frame from receive queue. Queue length 0
2021-11-27 14:10:04.234 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH added EZSP frame to receive queue. Queue length 0
2021-11-27 14:10:04.235 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=6, notRdy=false]
2021-11-27 14:10:05.232 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: TX EZSP queue size: 1
2021-11-27 14:10:05.235 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameData [frmNum=2, ackNum=6, reTx=false, data=AA 00 18]
2021-11-27 14:10:05.241 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=6, ackNum=3, reTx=false, data=AA 80 18 02]
2021-11-27 14:10:05.244 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH: Frame acked and removed AshFrameData [frmNum=2, ackNum=6, reTx=false, data=AA 00 18]
2021-11-27 14:10:05.245 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH took EZSP frame from receive queue. Queue length 0
2021-11-27 14:10:05.246 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - ASH added EZSP frame to receive queue. Queue length 0

[cdjackson]

I attached a ziplog that included both detection and then button presses this afternoon. At button press time, it gets

Sorry - your comment earlier was about discovery and I was focussed on that when I looked at that log.

At button press time, it gets

Ok, I think I understand the problem with this device. The device is using attribute reporting when it is running as a client - normally a client should use the various commands (eg the OnOff command). When running as a server, the binding therefore does not listen to attribute updates - it expects the client to send the respective commands, and this device doesn't do that.

Leave this with me for a few days to think about.

[elfman03]

Thanks!

[t-8ch]

@cdjackson

Ok, I think I understand the problem with this device. The device is using attribute reporting when it is running as a client

FYI this seems to be a recurring theme with Xiaomi devices. (See #346 and the other static thing definitions for xiaomi)

[elfman03]

Any update on this? Any additional changes needed by me?

[cdjackson]

Sorry for the slow response @elfman03 . I think this is fine - especially as pointed out by @t-8ch this is done like this already in other devices.