I’m pretty convinced it’s the way they are doing icon caching on the app. I’ve seen this before with some of my own teams - rather than caching the previous state and updating only what the user is viewing on the screen, or doing the state update in the background while the user is doing something else, they are most likely doing state updates all at once when the user opens the app or sends it to the front of the display. (So every time you open the app or bring it to the foreground, it makes hundreds of API calls one after the other to update state.)
The server-side can clearly handle as many devices as you can throw at it.
It’s super lazy, and you can see that’s probably what they are doing when you open the app from a ground state. Scroll to the bottom and it takes a full minute to catchup with icon updating. This really should be handled as a background task or just update the current user’s view.
There is an irony that if the dashboard just listed the devices and their online status they could do the whole lot with one API call. It is getting the attribute statuses that is time consuming.
Initial fetch, yes that’s true. The API calls should not take that long, it’s swapping out the graphics and updating the screens is still costly on a mobile device. It’s just clumsily coded, and I am sure hard to retro fit, but they need to.
Another bullet point in the “this can be done” column is the workaround that existed prior to last week: when you went to the full device list screen, everything was fine. (Because there were no pretty 1"x1" icons to update)
I think I remember a discussion like this… was derailed by not being suited for those who are color blind. Maybe some colors are more compatible than others?
As far as QP, the answer is one word… any word, or anything really.
Spot on @uberrob , I agree with everything you said. In the other thread about this I’m using an old tablet with the older app as the workaround. Maybe the developers ran out of beads on their Abacus when running their capacity calculations?
I had given that some thought but was unsure if that difference was adequate, the whole app also needs some major accessibility improvements inc ease of access from a screen reader
No clue. That particular job opening is interesting, though. It used to be filled by former Amazon director Robert Parker. But according to LinkedIn, he now works for Bright.AI which was founded by……SmartThings founder Alex Hawkinson.
I had formed the impression that SmartThings has more than one Director of Engineering. For example, Tom Manley is also described as Director of Engineering but that seems to be Hubs and Devices team.
I found this job interesting because it was for Client Engineering, and tied in with the other vacancy which involved mobile clients. Rightly or wrongly, I had formed the impression that much of the app stuff was coming out of Korea and wondered if there had been some organisational changes.
Certainly a grip needs to be gotten where the mobile, Windows and Web apps are concerned. There seems to be three different visions implemented in four different ways.
I have installed Home Assistant on a RPI4 with a 512GB SSD and no SD Card. I have already moved a large number of zigbee devices and am excited at how fast the process is compared to ST. Sure it is not easy as ST tried to make it but there are so many more options I am giddy with excitement to implement.
I found a zwave dimmer was excluded and when I tried to add it back I also found that I can no longer add it because of this stupid limit. GRRRRR Just another good reason to jump ship. Tried with Hubitat but it did not inspire me much, but Home Assistant looks pretty exciting and mostly NO CLOUD / LOCAL PROCESSING!!
