Problems using Zigbee multi switch mc

Devices & Integrations Community Created Device Types
1

Ah, I’ve come across a bit of a problem with this.

On a different switch in the house, a 2 gang switch, I’m able to use a status of “pushed” to trigger a routine. This enables me to have attach a virtual light to it and means I can turn the switch into two separate devices that Google Home can address.

It ends up going into a loop without this “pushed” status. Using on/off as the trigger will put it into a loop quite often.

I’ve added this new driver and it does work but I’m now setting up the routines so that I can conitrol each 3 parts of this switch independently and without the “pushed” status they quickly get into on/off loops.

image
image1915×590 19.5 KB

You can see here a section of the routine which uses pushed.

2

Hi

You don’t need to create virtual devices, you can create child devices independently in preferences for switch2, switch3 and all switches on/off

1000018410
1000018410864×1920 136 KB

1 Like
3

Oh that’s fantastic. I’ve switched the other switch to that driver too and it means I can get rid of the routines and things are simpler.

Now my only little issue is how slow the app is when I switch them on or off, it spins for quite a few seconds - is that the 300 setting that could be changed to update more frequently?

4

That’s a problem with the app, sometimes it goes fast, other times it goes very very slow, other times it shows a status in the mosaic and another in the details view and sometimes need to close it and reopen it for app to work properly. Hopefully they’ll fix it someday

I say that it is the fault of the smartthings servers or app, because I can see with the CLI the logs that reach the driver from the app and from the device and the driver as soon as it receives the command sends it to the device and the device responds in tenths of a second and the driver emits the new status to the platform immediately and it takes several seconds later to be seen in the App.

In this example was received a on command at 09:53:21.611199876Z and the new On event to a default response was emitted at 09:53:21.749589001Z, in 0.13 sec.
A second on report attribute message was received and was emitted a new On command at 09:53:21.883414459Z, total 0.27 sec to emit two On events.
In app the On response was show more of 4 sec after

2024-09-26T09:53:21.611199876Z INFO Zigbee Switch Mc hub handled command: 23b34f80-16bf-47c1-938a-80497f29bb0e:main:switch:on
2024-09-26T09:53:21.612313167Z INFO Zigbee Switch Mc hub sending: Zigbee message (23b34f80-16bf-47c1-938a-80497f29bb0e): <src_addr: 0x00, src_endpoint: 0x1, dest_addr: 0x158d, dest_endpoint: 0xb, profile: 0x104, cluster: 0x06, data: [01, 00, 01]>
2024-09-26T09:53:21.724922209Z TRACE Zigbee Switch Mc Received event with handler zigbee
2024-09-26T09:53:21.725825667Z INFO Zigbee Switch Mc <ZigbeeDevice: 23b34f80-16bf-47c1-938a-80497f29bb0e [0x158D] (Lidl Plug)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x158D, src_endpoint: 0x0B, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: OnOff >, lqi: 0xC8, rssi: -61, body_length: 0x0005, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x08, seqno: 0x5D, ZCLCommandId: 0x0B >, < DefaultResponse || cmd: 0x01, ZclStatus: SUCCESS > > >
2024-09-26T09:53:21.748542626Z TRACE Zigbee Switch Mc Found ZigbeeMessageDispatcher handler in Zigbee_Switch_Mc
2024-09-26T09:53:21.749589001Z INFO Zigbee Switch Mc Executing ZclGlobalCommandHandler: cluster: OnOff, command: DefaultResponse
2024-09-26T09:53:21.751073834ZINFO Zigbee Switch Mc <ZigbeeDevice: 23b34f80-16bf-47c1-938a-80497f29bb0e [0x158D] (Lidl Plug)> emitting event: {“attribute_id”:“switch”,“capability_id”:“switch”,“component_id”:“main”,“state”:{“value”:“on”}}
2024-09-26T09:53:21.784288667Z DEBUG Zigbee Switch Mc Lidl Plug device thread event handled
2024-09-26T09:53:21.819439584Z TRACE Zigbee Switch Mc Received event with handler zigbee
2024-09-26T09:53:21.826222542Z INFO Zigbee Switch Mc <ZigbeeDevice: 23b34f80-16bf-47c1-938a-80497f29bb0e [0x158D] (Lidl Plug)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x158D, src_endpoint: 0x0B, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: OnOff >, lqi: 0xC8, rssi: -62, body_length: 0x0007, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x66, ZCLCommandId: 0x0A >, < ReportAttribute || < AttributeRecord || AttributeId: 0x0000, DataType: Boolean, OnOff: true
2024-09-26T09:53:21.850691376Z TRACE Zigbee Switch Mc Found ZigbeeMessageDispatcher handler in Zigbee_Switch_Mc
2024-09-26T09:53:21.851588459Z INFO Zigbee Switch Mc Executing ZclClusterAttributeValueHandler: cluster: OnOff, attribute: OnOff
2024-09-26T09:53:21.852935126Z INFO Zigbee Switch Mc <ZigbeeDevice: 23b34f80-16bf-47c1-938a-80497f29bb0e [0x158D] (Lidl Plug)> emitting event: {“attribute_id”:“signalMetrics”,“capability_id”:“legendabsolute60149.signalMetrics”,“component_id”:“main”,“state”:{“value”:“2024/09/26 Time: 11:53, LQI: 200 … rssi: -62”},“visibility”:{“displayed”:false}}
2024-09-26T09:53:21.869761084Z INFO Zigbee Switch Mc <ZigbeeDevice: 23b34f80-16bf-47c1-938a-80497f29bb0e [0x158D] (Lidl Plug)> emitting event: {“attribute_id”:“switch”,“capability_id”:“switch”,“component_id”:“main”,“state”:{“value”:“on”}}
2024-09-26T09:53:21.883414459Z INFO Zigbee Switch Mc <ZigbeeDevice: 23b34f80-16bf-47c1-938a-80497f29bb0e [0x158D] (Lidl Plug)> emitting event: {“attribute_id”:“power”,“capability_id”:“powerMeter”,“component_id”:“main”,“state”:{“unit”:“W”,“value”:1000}}

The periodic reports setting is to reduce the number of messages that the devices send periodically to report their current status to the hub and not show them offline.

By default in the lua libraries of the firmware, messages are configured every 300 sec for the onOff cluster. I have it set to 1200 sec in my devices and it works well. It sends 4 times less messages to each device, this should free up work for the hub and reduce message traffic on the zigbee network when user has a lot off devices

2 Likes
5

Just a reminder: the edge driver request threads should only have two posts per device. One for the request with all the information from the first post in the request thread, and then one from someone else with a link to the edge driver that will work.

If you have any further questions or problems about the suggested edge driver, please either start a new thread or post in the existing thread for that edge driver.

Otherwise, the request threads become unusable.

I have moved the off-topic discussion to its own thread here, so you don’t have to do anything about this one. :sunglasses: