APP Android version 1.7.85.25 issues

ygerlovin · June 22, 2022, 5:41pm

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

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
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
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 · June 23, 2022, 12:01am

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 · June 23, 2022, 5:51am

@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 · June 23, 2022, 3:19pm

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 · June 23, 2022, 5:08pm

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.

ygerlovin · June 23, 2022, 5:13pm

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 · June 28, 2022, 5:05pm

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 · June 28, 2022, 5:22pm

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.

philh30 · June 28, 2022, 5:31pm

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

philh30 · June 28, 2022, 5:55pm

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 · June 28, 2022, 7:43pm

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.

philh30 · June 28, 2022, 8:18pm

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 · June 28, 2022, 8:40pm

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

Mariano_Colmenarejo · August 17, 2022, 2:45pm

Hi @nayelyz,

I have seen that another behavior of the app has changed for the worse, although it does not seem from the version, rather from some plugin or from the API, I don’t know:

Before when you made a driver change, for example to zigbee Thing Mc, which does not have stock capabilities or has different capabilities. All the automations that had that device were marked as unknown “action” or “Condition”, but they were not deleted since the device ID had not changed.
When you went back to the working driver, you hadn’t lost any automation.
Now:
- if the device is alone in the automation, it is deleted and there is no trace
- If there are more devices in the automation:
  - You can’t see the automation on the device that changed the driver.
  - In the other devices that were in the automation it is disabled, but unusable. Can be enabled, but cannot be opened for editing gives the message: “This routine has expired or has been removed by another member. Any changes you have made will be discarded”

With this, it only remains to delete the automation and rebuild it.

The method of adding a virtual device to the automation so as not to lose it has been lost.

We no longer only have to be aware when they update the App, any day new things happen in the app, some fix things and others break things

nayelyz · August 17, 2022, 3:44pm

Hi, @Mariano_Colmenarejo.

Let me see if I understand, the original profile has a collection of capabilities and the new one doesn’t have the same ones, but there’s a difference, for example:

You delete and add more capabilities
You keep the original capabilities but add others.

In both cases, does the automation become completely unusable?
I would think it is expected in the case where capabilities are deleted and the device had routines using them because the metadata changed and it would prevent issues there, but let me check more info about it.

I just want to make sure I understand the configuration you set to try to replicate the behavior you described.

blkwll · August 17, 2022, 4:03pm

I can confirm that that if the routine has a capability present in a driver, and the driver is changed to another without that capability, the routine disappears from the device of the changed driver.

The routine remains present in the other devices referenced in the routine, but they are not functional or editable, and must be deleted by a long-press>delete.

This, so far, is all I’ve been able to observe.

Mariano_Colmenarejo · August 17, 2022, 4:13pm

Indeed they become unusable, but before as the device has not disappeared, they were only marked as disabled and were not lost, they could be recovered.
Now the device disappears from the automation and the automation is marked as disabled, but it is unrecoverable and is only visible on the device, routines. They do not appear in the automations menu

andresg · August 18, 2022, 10:36pm

Hi, @Mariano_Colmenarejo

Take into account that, even though we identify devices with their deviceId, a driver has a very important role in the device ‘identity’. I mean, it is what defines how they are handled. I wouldn’t expect that a major change like switching one driver to another would leave everything else related to that device as if nothing happened. Nevertheless I have to say that I share your concern with the team and they say that, since the Groovy sunset is coming (and the migration that comes with it), they are working on having Rules automatically updated whenever a device gains or loses a capability due to a driver switching.

orangebucket · August 18, 2022, 11:23pm

Please don’t. You will destroy SmartThings by doing that.

OK, if we are actually talking about app Routines which are already automatically messed with, fill your boots. The damage is already done there, and I get the thinking even though I consider it is horribly wrong.

However if we are talking about Rules explicitly created by users then don’t you dare touch them. They are that way for a reason and you have no way of knowing if an action a user takes is going to be a one off, or step 1 of a multi-step process lasting hours or days.

Mariano_Colmenarejo · August 19, 2022, 7:18am

Hi @andresg,

Precisely as we are going to enter a period that many users will have to look for a driver for their devices with custom dth since they will be orphaned and according to @alissa.dornbos says, they will be assigned a type zigbee or zwave thing, which has no capabilities, and will make all their rules disappear or become unusable, as it is now.

Please, can’t you at least leave it like before? that if the device does not uninstall, the routines are disabled, but they can be recovered by editing them again.

There will be users, who need to configure parameters of their zwave devices, since the stock drivers do not have many configuration parameters available. When they switch to a driver to change some configuration parameter they will lose all their routines. This makes no sense!!

APP Android version 1.7.85.25 issues

Customers

Developers

Download the SmartThings App