SmartThings Android App Updates - Version 1.8.18.21 (Sept. ‘24)

[orangebucket (Graham)]

I haven’t had a good look around yet, but …

• Temperature and humidity devices are now showing both attributes in the status as telegraphed by a recent PR on the Edge driver. However this is also true on the previous version of the app as it is presumably the plugin that has been updated.
• The irritating dots incorrectly suggesting changes in the ‘How to use’ section have not been fixed.
• Installed SmartApps on the Routines page still give network errors.
• The ‘Contact us’ page has been tarted up and includes ‘Phone diagnostics’ and ‘News and tips’. This might just be a sign of the dreaded ‘Samsung Members’ infestation on the particular handset I am using.

[JKnight (Keeping SmartThings limping along since 2013.)]

Not sure if this is new with this update, but I just noticed it while I was looking around for what else they broke with the update. I have a (semi) persistent orange exclamation mark next to “Get your location from this phone”, even though I have the feature turned on and I think it is still working as expected. The exclamation temporarily goes away if you click into it, or any other settings, but comes back anytime you navigate out of settings and then return.

[orangebucket (Graham)]

@JKnight

I now have a persistent orange exclamation mark next to “Get your location from this phone”

I knew exactly the one you meant straight away. I don’t think it is new and it doesn’t seem to be at all persistent for me, but I’ve certainly seen it appearing for no obvious reason, including immediately after updating the app.

The dot on “How to use” seems to have got more frequent.

[orangebucket (Graham)]

For a long time now, setting the Security Mode has also called commands to arm/disarm any device in the Location with the securitySystem capability. It was working well when first discovered, went through a long period where it seemed to be unreliable when the Security Mode was set by an automation, went through a spell of being rock solid earlier this year, and is now unreliable again.

Relatively recently (but still many months ago) this behaviour was finally acknowledged in the Home Monitor settings, except the description provided clearly implied that setting the securitySystemStatus of a device should also change the Security Mode. It didn’t. I don’t know when they fixed it, but it works now.

[Andreas_Roedl]

Rewritten previous comment by ChatGPT.

[Mariano_Colmenarejo]

Hi @nayelyz

For a few days now I’ve seen that some device states in the App get out of sync with the actual state of the device and its state on the platform.
I’ve seen this several times in a light that turns on with a routine when opening the door only if it’s off. The routine wasn’t activated because the app had the ON state and the light was actually Off.

In these devices that have commands to change the state of the device, like a switch, it’s impossible to resynchronize them, because the App tries to send the command with the state that the device already has on the platform and someone blocks it and the command doesn’t reach the driver. I can see in the CLI logs that no command arrives.

I’ve seen that this desynchronization occurs more easily if you change the state several times in a row in the app when a network error appears, but not always.

New video by Mariano Colmenarejo

The only way I’ve seen to be able to resynchronize them quickly is to create a manual routine that sends a state change command (On or Off) when a network error appears. This way the state of the device changes and it resynchronizes.

New video by Mariano Colmenarejo

Even if you refresh device in the app and the driver sends the event again with the device correct status, since that On or Off status already exists on the platform, it is not propagated to the App nor does it change the timestamp of the last event on the web advanced users.

This problem appears with zwave and zigbee devices

[nayelyz (SmartThings Developer Support)]

@Mariano_Colmenarejo

I can see in the CLI logs that no command arrives.

Which command do you mean, the one from the app or the “response” from the device?
To report the issue the video is perfect, but we’re missing the info below, so, please, replicate the issue and help us with that info:

1. Video showing the error
2. Driver logs
3. Hub logs

1. In the my.smartthings, enter “your hubs”
2. Enter the corresponding Hub
3. Click on “Dump Hub Logs”
4. Change the reason for requesting hub logs if needed
5. Click on “Dump Hub Logs”
6. Confirm that the request is sumited
   Note: If you have more than one Hub, the name of the one involved in the issue.

4. If you send a command from the app but it’s never showed in the driver logs, we need the app logs as well:

1. Go to Menu > Gear Icon > About SmartThings
2. Tap the SmartThings logo 10 times.
3. This will open the developer’s space > tap ‘report a problem’
4. This will send you to the report page. Select a frequency and write a short description of the issue.
5. Click on “Report” and a log file will be generated for you to send over email, please do to build@smartthings.com

[Mariano_Colmenarejo]

@nayelyz

Which command do you mean, the one from the app or the “response” from the device?

the command on or off from the app does not received in the driver

[nayelyz (SmartThings Developer Support)]

Hi, @Mariano_Colmenarejo.

Following up, could you provide the information above so we can open the report, please?

[Mariano_Colmenarejo]

@nayelyz

Following up, could you provide the information above so we can open the report, please?

Hi @nayelyz

Since that day, when the problem could be easily reproduced, I have not been able to reproduce the problem again to give more information.

I think it has to do with the filters, the propagation of repetitive or frequent events, which have been introduced into the platform.

If an event is lost at some moment and it does not reach the App and it reaches other endpoints, they become desynchronized and remain in that way until who knows when.

For example, when the driver sends an event of a periodic attribute report, which in switches are by default every 300 seconds, those events emitted by the driver do not all reach the different endpoints on the platform.
Since the event has state_change = false, then if the reported state has not changed from the previous value, that event:

• Will not be updated in the event history
• Will not be updated in the attribute status in advanced users
• Will not be updated in the App details view

However, if an unknown amount of time has passed, I’ve seen around 1 hour or less, even though state_change = false and the state has not changed, that new event:

• Will have its timestamp updated in the advanced users attribute status web and consequently should also be updated in the App
• Will not be updated in the event history.

This can be easily verified by looking at the logs with the CLI and the timestamps on the advanced users web, device attributes.

In fact, the last time the On state of the real device and the attribute on the web got out of sync with the state in the App, I left it like that and it synchronized itself after about an hour or so. When some filter met the condition and let the On state propagate and it reached the App again.

This makes no sense, because when it was out of sync and you did several refreshes in the App and you could see in the CLI logs that the driver emitted the On value, it never reached the App, because in the advanced users web the attribute already had the On state and the App gave a network error.
If there had not been something that prevented this periodic or manual refresh of the state, with a simple App refresh everything would have been synchronized.

These filters drive me crazy when I want to debug changes in a driver sometimes.

For example, I am trying to fix the forbidden information in HTML of the clusters and command class of the devices in zigbee and zwave thing driver.

The deviceInfo capability, which I used to send that information in HTML, now when I send it in plain text there is something that prevents that attribute from being seen in the event history, even though I see it in the App and on the advanced users web.

I created another new capability (commandClass), identical and I send the same information to both and the new capability is updated in all endpoints, Attribute status in web, event history and app and yet the deviceInfo attribute never appears in the event history.

It must be that the AI ​​that Samsung is going to apply to its entire platform is already underway and those of us who are not so intelligent do not understand it well.