APP Android version 1.7.85.25 issues

[Mariano_Colmenarejo]

@Mariano_Colmenarejo

@nayelyz

I modified the presentation of a capability
legendabsolute60149.switchAllOnOff1.
Let’s see if it’s true that it updates itself for all users of the Zigbee Multi Switch Mc driver and the toggle switch that turns all the switches on and off changes color with the status of the alternatives.

I already tried this presentation with another capability legendabsolute60149.switchAllOnOff, in a test driver as I told you and it worked fine with a new VID

Hi @nayelyz, So that you can see it tomorrow.

The presentation of the capability legendabsolute60149.switchAllOnOff1 modified and updated with CLI 48 hours ago, continues to show the same as before the modification.

I have also deleted the cache of the app about 20 times in these 48 hours and it doesn’t deign to show me the new presentation either.

I don’t know if any Zigbee Multi Switch Mc user has noticed that the All Switch On-Off button is no longer always blue.

The twin capability legendabsolute60149.switchAllOnOff, in which I generated a new vid after modified and updated, works perfectly with new alternatives.

[Paul_Oliver (PCO)]

This how mine looks in the off position.

[nayelyz (Developer Support Team)]

@Mariano_Colmenarejo

The presentation of the capability legendabsolute60149.switchAllOnOff1 modified and updated with CLI 48 hours ago, continues to show the same as before the modification.

Ok, thanks for the info. I also found a report about the presentation not being updated correctly even after the 12 hours.
It originated from some comments here. So, for now, the workaround of creating new capabilities would be the solution, I don’t know if deleting the device and pairing it again helps in this case but it also makes you lose all your routines…

I’ll make some tests to update the behavior reported there.

[Nik83 (Nikolai R)]

@Mariano_Colmenarejo

720×1600 65.5 KB

i Have this problem to with ALL my buttens too

[Mariano_Colmenarejo]

@nayelyz

for now, the workaround of creating new capabilities would be the solution

I have created 3 new VIDs, one for each profile, with the alternatives and everything has been updated correctly.

It would be necessary to give an acceptable solution to this problem with the presentation updates of the capabilities.

I’ve published new version it on the shared channel

┌─────────────┬──────────────────────────────────────┐
│ Name        │ Zigbee Multi Switch Mc               │
│ Version     │ 2022-06-21T11:22:45.884747294        │
└─────────────┴──────────────────────────────────────┘

[ygerlovin (Yakov Gerlovin)]

@nayelyz

@nayelyz

Thanks for sharing this issue. I’m already checking it with the engineering team. Just to confirm, this is a Z-Wave device working with Edge, right?

It seems all devices, working with Edge are affected, ZW,Zigbee, LAN.
Happens on 85 and 86 Android versions.
This issue is especially frustrating for virtual devices, as they don’t have physical device to respond with new attribute values.

Could you please share the plans regarding this issue? Is this behaviour intended or it is a bug that is going to be fixed?
I’m considering to remove refresh capability from most devices and modify refresh handler to emit events for all capabilities for the rest

[nayelyz (Developer Support Team)]

@ygerlovin

Could you please share the plans regarding this issue? Is this behaviour intended or it is a bug that is going to be fixed?

The team keeps analyzing the issue so there’s no definite answer on what’s causing it and if it’s expected.

@ygerlovin

I’m considering to remove refresh capability from most devices and modify refresh handler to emit events for all capabilities for the rest

So, you defined the Refresh capability in your device profile but you didn’t define a custom handler for that command?

When you scroll down the page, do you see if the driver sends (and receives the response) messages to get the status of those capabilities?

It seems the app will make an automatic process when you scroll down the details page even if you don’t include the Refresh capability, and we discovered the issue is happening there as well.

[ygerlovin (Yakov Gerlovin)]

@nayelyz

@nayelyz

So, you defined the Refresh capability in your device profile but you didn’t define a custom handler for that command?

I do define refresh handler, I just do not update ALL the capabilities (only some of the capabilities).
This is for multiple reasons:

1. It is not always possible to read all attributes. In fact, for Tuya devices that are working with proprietary cluster, I just send a single Query all command and hope for the best. I process every message I get from the device, but the device might not update all attributes, so not necessary all capabilities are updated
2. For virtual devices it make sense to update only some fields. For example, vDevices Controller not always shows a list of created devices, as it is a relatively heavy operation. It however allows user to refresh to show the complete list. There was no reason to emit events for other capabilities
3. Even when working with physical devices, there are could be capabilities that might not be worth of refreshing. Some devices update energy measurement every 5 or 10 min, it make little sense to read energy measurement in smaller intervals

[nayelyz (Developer Support Team)]

Thank you for sharing these use cases. I’ll share them with the engineering team in the report of the issue so they can see the uses of null values for capabilities.

[ygerlovin (Yakov Gerlovin)]

@nayelyz
Sorry for not being clear.
There are no null values. All capabilities have real values set before the refresh.
Refresh handler only updates some capabilities.
The capabilities not being updated, show broken cloud

[nayelyz (Developer Support Team)]

@ygerlovin

There are no null values. All capabilities have real values set before the refresh.

Aaah, got it, then this is a normal use case.
In my tests, I used a stock driver and it didn’t support the Refresh capability. When this happens, there should be a process that makes the refresh automatically but it was receiving not valid values and that’s why it might have shown the cloud disconnected icon.
Perhaps, as a workaround for those capabilities, you can use the device cache to get the last known value (get_latest_state, here’s an example) and send them in a capability event (device:emit_event())

[ygerlovin (Yakov Gerlovin)]

Thank you @nayelyz .

@nayelyz

Perhaps, as a workaround for those capabilities, you can use the device cache to get the last known value (get_latest_state, here’s an example ) and send them in a capability event (device:emit_event())

I’m aware of this workaround, thank you.
Refresh worked fine on previous Android version, so for now, I’d like to understand whether it is expected behaviour that is going to stay or it is just a bug that is going to be fixed.

[ygerlovin (Yakov Gerlovin)]

One more thing to consider:
There are limitations for events rate per device, per driver and per hub.
Sending unnecessary events from cached state is not scalable

[philh30]

colorControl is no longer functional on detail view.

switch (and other capabilities) on detail view now changes state before the device generates an event.

[nayelyz (Developer Support Team)]

@philh30

colorControl is no longer functional on detail view.

What do you mean? it is not showing the buttons, you don’t receive the events or it shows an error?

@philh30

switch (and other capabilities) on detail view now changes state before the device generates an event.

Can you elaborate, please? So, instead of showing a “loading icon”, it just changes state and you don’t receive the event until after that?
I just tested a Switch and I see the events right when the state changes.

[philh30]

colorControl from detail view almost always generates a network error - same for Edge, DTH and Hue. On Edge, it doesn’t seem to be triggering the capability handler. Here’s Hue (the stock hub to hub integration):

switch when toggled on detail view immediately changes state without waiting for the event. This is best viewed on a slow to respond or non-responsive device.

@nayelyz

So, instead of showing a “loading icon”, it just changes state and you don’t receive the event until after that?

Yes

[philh30]

For colorControl, it appears that at least part of the issue is that detail view is now sending two separate commands - a setHue and a setSaturation. Scenes/automations continue to work and generate a single setColor command. I’m guessing the behavior of detail view has been changed and used to generate a setColor command. The Edge z-wave library only includes a default handler for setColor. Meanwhile, the zigbee library includes default handlers for all three commands.

For Hue, the “Recently used colors” work, but the color selection wheel generates the network error.

[nayelyz (Developer Support Team)]

@philh30

it appears that at least part of the issue is that detail view is now sending two separate commands - a setHue and a setSaturation .

Ok, so you get the network error because you’re not handling these events, correct?

@philh30

For Hue, the “Recently used colors” work, but the color selection wheel generates the network error.

In this case, are you also receiving the event but not handling it or you receive the network error directly? This is important because in each case, the issue is caused by different factors.

If it’s because of the capability event handlers, then, please add the missing ones as custom handlers. I’ll report this new behavior, if it’s expected, then, the default libraries (for Z-Wave) need to be updated.

[philh30]

@nayelyz

In this case, are you also receiving the event but not handling it or you receive the network error directly?

In that case I meant Hue as in the stock Philips Hue hub to hub integration.

Pretty sure I understand this now to be two separate issues:

• The color wheel generates an immediate network error. Same behavior with Z-wave Edge, ZigBee DTH, and the stock Philips Hue integration. I don’t see any command being generated on the Edge driver, so I have nothing to handle.

• The recent colors work, but now generate setHue/setSaturatuon commands instead of setColor. This is not handled in the default z-wave library. I’m actually not getting an error in the app when I fail to handle those commands. The app shows the color change immediately and pretends like everything worked (same behavior as what I noted for switch above).

[Mariano_Colmenarejo]

@philh30

The recent colors work, but now generate setHue/setSaturatuon commands instead of setColor.

Is correct @philh30, Looking at the logs of a driver zigbee, I think too the problem is that in the details view the colorControl capability does NOT send the setColor command, which causes the MoveTo Hue and Sat command to be sent to the device, as it happened before and as it happens when you do it from an automation.

This log is for a setColor command from automation

2022-06-28T20:26:00.288237824+00:00 DEBUG Zigbee Light Multifunction Mc  Luz Cocina device thread event handled
2022-06-28T20:26:00.298239491+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> received command: {"args":{"color":{"hue":4.407713413238525,"saturation":96.03174591064452}},"capability":"colorControl","command":"setColor","component":"main","positional_args":[{"hue":4.407713413238525,"saturation":96.03174591064452}]}
2022-06-28T20:26:00.305824158+00:00 TRACE Zigbee Light Multifunction Mc  Found CapabilityCommandDispatcher handler in zigbee_light_multifunctions -> XY Color Bulb
2022-06-28T20:26:00.311125158+00:00 PRINT Zigbee Light Multifunction Mc  <<<< set_color_handler XY >>>>
2022-06-28T20:26:00.318653158+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x79E2, dest_endpoint: 0x01, profile: 0x0104, cluster: Level >, < ZCLMessageBody || < ZCLHeader 
|| frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x04 >, < MoveToLevelWithOnOff || level: 0xFE, transition_time: 0xFFFF, options_mask: 0x00, options_override: 0x00 > > >
2022-06-28T20:26:00.351429825+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x79E2, dest_endpoint: 0x01, profile: 0x0104, cluster: ColorControl >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x07 >, < MoveToColor || color_x: 0xB108, color_y: 0x4D1C, transition_time: 0x0000, options_mask: 0x00, options_override: 0x00 > > 
>

What it does now is that it sends the Hue command and then the Saturation command separately with what:

• first you see a color with the hue command and the last saturation value
• Then send the saturation value with the last hue value
• Result, you see 2 colors different from the one you sent to device

This log is for a set a color from color control in detaill view

2022-06-28T20:04:09.896616298+00:00 TRACE Zigbee Light Multifunction Mc  Received event with handler capability
2022-06-28T20:04:09.925495965+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> received command: {"args":{"hue":96.11},"capability":"colorControl","command":"setHue","component":"main","positional_args":[96.11]}
2022-06-28T20:04:09.934124632+00:00 TRACE Zigbee Light Multifunction Mc  Found CapabilityCommandDispatcher handler in zigbee_light_multifunctions -> XY Color Bulb
2022-06-28T20:04:09.945218298+00:00 PRINT Zigbee Light Multifunction Mc  <<<< set_hue_handler XY >>>>
2022-06-28T20:04:09.955065965+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x79E2, dest_endpoint: 0x01, profile: 0x0104, cluster: Level >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x04 >, < MoveToLevelWithOnOff || level: 0xFE, transition_time: 0xFFFF, options_mask: 0x00, options_override: 0x00 > > >
2022-06-28T20:04:09.993801298+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x79E2, dest_endpoint: 0x01, profile: 0x0104, cluster: ColorControl >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x07 >, < MoveToColor || color_x: 0x9079, color_y: 0x4085, transition_time: 0x0000, options_mask: 0x00, options_override: 0x00 > > >
2022-06-28T20:04:10.013006298+00:00 DEBUG Zigbee Light Multifunction Mc  Luz Cocina device thread event handled
2022-06-28T20:04:10.028769632+00:00 TRACE Zigbee Light Multifunction Mc  Received event with handler capability
2022-06-28T20:04:10.068521298+00:00 DEBUG Zigbee Light Multifunction Mc  Luz Cocina device thread event handled
2022-06-28T20:04:10.083288298+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> received command: {"args":{"saturation":34.1},"capability":"colorControl","command":"setSaturation","component":"main","positional_args":[34.1]}
2022-06-28T20:04:10.090489298+00:00 TRACE Zigbee Light Multifunction Mc  Found CapabilityCommandDispatcher handler in zigbee_light_multifunctions -> XY Color Bulb
2022-06-28T20:04:10.100050965+00:00 PRINT Zigbee Light Multifunction Mc  <<<< set_saturation_handler XY >>>>
2022-06-28T20:04:10.107863965+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x79E2, dest_endpoint: 0x01, profile: 0x0104, cluster: Level >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x04 >, < MoveToLevelWithOnOff || level: 0xFE, transition_time: 0xFFFF, options_mask: 0x00, options_override: 0x00 > > >
2022-06-28T20:04:10.132558632+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x79E2, dest_endpoint: 0x01, profile: 0x0104, cluster: ColorControl >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x07 >, < MoveToColor || color_x: 0x5B2C, color_y: 0x384C, transition_time: 0x0000, options_mask: 0x00, options_override: 0x00 > > >

UPDATE:

From my.smartthings.com it works fine too. Send setColor command:

2022-06-28T21:30:02.115697746+00:00 TRACE Zigbee Light Multifunction Mc  Received event with handler capability
2022-06-28T21:30:02.145258079+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> received command: {"args":{"color":{"hue":84,"saturation":72}},"capability":"colorControl","command":"setColor","component":"main","positional_args":[{"hue":84,"saturation":72}]}
2022-06-28T21:30:02.152266746+00:00 TRACE Zigbee Light Multifunction Mc  Found CapabilityCommandDispatcher handler in zigbee_light_multifunctions -> XY Color Bulb
2022-06-28T21:30:02.165157412+00:00 PRINT Zigbee Light Multifunction Mc  <<<< set_color_handler XY >>>>
2022-06-28T21:30:02.174485746+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x79E2, dest_endpoint: 0x01, profile: 0x0104, cluster: Level >, < ZCLMessageBody || < ZCLHeader 
|| frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x04 >, < MoveToLevelWithOnOff || level: 0xFE, transition_time: 0xFFFF, options_mask: 0x00, options_override: 0x00 > > >
2022-06-28T21:30:02.216891746+00:00 INFO Zigbee Light Multifunction Mc  <ZigbeeDevice: 175500e5-e3eb-425e-bd32-9b7cdfb3899a [0x79E2] (Luz Cocina)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x79E2, dest_endpoint: 0x01, profile: 0x0104, cluster: ColorControl >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x01, seqno: 0x00, ZCLCommandId: 0x07 >, < MoveToColor || color_x: 0x65B9, color_y: 0x24A1, transition_time: 0x0000, options_mask: 0x00, options_override: 0x00 > > 
>