@pauly, can you see the state elsewhere but the log? Is it showing on the device tile or in the device UX plugin page? Anywhere where you just look at it and say, oh ok it is heating now.
So, after the latest Android release I cleared cache and data. Uninstalled the app and made a new clean install.
Logged in and rearranged the home screen. It actually stuck for a few days. But suddenly yesterday when I was scrolling through the home screen, everything got reset. Back to classic app again
@blake.arnold Smartthings is making it impossible for people that want to change over to the new app. The new app has enough functionality for me to switch over, and I have tried many times. But the app and functionality already in there just doesn’t work good enough
FWIW, I use the new app on an Android 10 Google Pixel 2 phone and an Android 9 Samsung Tab S5e.
I see people reporting the problem of manual arrangements getting lost but I’ve never seen it myself. The order I’ve placed my Rooms and my devices within rooms has stuck for at least the last two months. Maybe longer.
Yesterday the home screen reset for me as well. All rooms and all devices showed up in a random order. At least the device order within the rooms stayed the same.
Also, is ST having issues with DST? My sunset routine ran at the same time as yesterday, even though our clocks moved forward an hour (sunset is at 7:35 instead of 6:35).
A couple of reports, not too many this time. See the following thread:
Home screen reset has been an issue for months now. Very worried about all of this. Am I the only one who feels like we may see the end of smartthings or am I being dramatic?
Just a little bit…
Nothing to do with the new app. Happens every year. It’ll all return to normal tomorrow.
Not agreed, this could’ve been avoided, yes it’s not related to the app itself but the platform.
I also noticed another thing with sunrise time in new app, in which it only updates once the sunrise time changes more than (and equals to) 5 minutes. i.e., it will stay at 7:42am in Toronto for a while until next time sunrise is changed to 7:37am. Today in my area, it is supposed to be 7:40 or 7:39, according to IDE, webcore, and internet:
While in the app my automation based on sunrise was instead executed on 7:42am:
While this is not a big deal for me and for most of the people, people who are relying on sunrise time to do their Automations in the new app would definitely struggle because of this.
Tagging @blake.arnold, not sure if you’re aware of this issue.
My comment was in relation to the issues that ST has had for years (even prior to the new app) regarding DST <> xST changovers. Many people see that their time-related actions are off by an hour the day after a changeover. They then settle down the next day on their own. Unless I’m misunderstanding something, your explanation of your issues with the new app have nothing to do with the DST <> xST switchovers that I was responding to.
Yes I was reporting another issue basically, related to sunrise time
I don’t see 5 minute jumps in sunset times at all.
I’ve got a set of outside lights that are programmed via Smart Lighting to come on at sunset. Here are the times I’m seeing in the activity list in the STSC app:
- Monday, March 2: 18:36
- Tuesday, March 3: 18:37
- Wednesday, March 4: 18:38
- Thursday, March 5: 18:39
- Friday, March 6: 18:39
- Saturday, March 7: 18:40
- Sunday, March 8: 19:41
Also note, no DST issue either
WebCoRE get its sunrise and sunset times from SmartThings. If I remember correctly it pulls them when a piston goes to use them and finds they haven’t been checked for more than ‘x’ hours. I can’t remember what ‘x’ is without looking.
If a webCoRE piston is next due to run at Sunrise or Sunset the next day, it will actually just add 24 hours to the current day’s Sunrise or Sunset time and use that as its wake up time. That means it will activate a couple of minutes earlier or later that the actual Sunrise or Sunset, and if early may activate twice. If webCoRE is running a piston that skips the weekend, it may be even more off when it wakes up. The standard webCoRE trick for those bothered by this is to have the piston run at, say, 4am every day to do nothing as this will set the Sunrise or Sunset timer correctly.
So if the automations are working anything like webCoRE, they may be setting a timer the previous day when all they had to work with was that day’s sunrise and sunset times. I’m not sure where a five minute jump might come from for a single day in areas where it is normally a couple of minutes, but it isn’t the first time I’ve seen it lately.
I used to have intermittent issues with Webcore pistons that use sunset or sunrise. The issue occurred more often at the change to/from DST. I managed to find a workaround by adding a few lines to the piston
every day at 60 minutes before sunset
This wakes up the piston, does nothing and then schedules the next wakeup based on the now accurate sunset or sunrise time.
I was referring to SmartThings app’s own Automations, and i think in smart lighting it’s pulling from the platform which is same as in IDE, which is correct time
Are you sure? As far as I know, webcore gets sunrise and sunset time from its weather API which is weather company, and according to Mr.W, sunrise and sunset times are refreshed at midnight. And you’re right about needs to refresh the piston that’s scheduled with sunrise and sunset times. Anyway this is off topic already.
What I’m saying is that from both IDE and webcore, sunrise and sunset actually changes everyday, wheres in Automations it stays the same for a few days:
Mar. 6, 6:49am:
I just read the code again. It turns out ‘x’ was eight hours but I think my description was OK. But yes, the on topic point of interest is what the Automations are up to. With the Groovy SmartApps we seem to know that the Weather Station app has to be running to keep sunrise and sunset in check. We don’t know if there is another mechanism at work for newer style apps like the Automations.
Will the new platform support HTTP based hubCommand before the old platform is decommissioned?
I have a security system, bulbs, sockets and presence detection that all rely on HTTP to operate in classic mode.
If the migration happens without that capability I will be forced to abandon Smartthings or lose the use of about 20 devices.