APP Android version 1.7.85.25 issues

@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.

This how mine looks in the off position.

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.

1 Like

i Have this problem to with ALL my buttens too :frowning:

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        │
└─────────────┴──────────────────────────────────────┘




2 Likes

@nayelyz

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

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

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.

@nayelyz

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

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.

@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

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())

Thank you @nayelyz .

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.

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

1 Like

colorControl is no longer functional on detail view.

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

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

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.

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.

Yes

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.

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

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.

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).