Author
Topic: Grasshopper 3.0.0.15 Released (Read 4156 times)

- Modes functionality added to both clients (Home, Away, etc)- Adding retry logic to camera and other functions to get around weird limitations in http client for store apps. Need to do more testing still- Fixing bug where if you selected a background image and then moved or removed the image from the phone would cause the app to start in an invalid state and not render the page because the rendering code gets cancelled because of the file not found exception.

Found a nasty bug when using a custom image for background. If you move or remove the file so it is not found it causes a crash that will put the app in a bad state and wont render the UI properly. I'll have a fix in the next update but if you do this the only way to fix it is a reinstall since you won't be able to get to the UI to actually change the setting. :-)

If you click the icon at the bottom right and nothing opens it means when it couldn't find the minimum state variables needed to display the UI. My code only checks high level info when deciding to even show the icon in the bottom right for performance reasons. So it is possible for it to display the icon but not be openable. If other devices are opening properly it is probably not a bug. If you want me to look at it setup a readonly account and email me. Then i can debug and tell you the exact reason why.

Would it be possible to disable the local access check? My phones are all kept in a guest network, so it can only access the Vera through the internet. Since my Vera also requires authentication to operate on local networks, this isn't much of a problem, but Grasshopper first tries to access through the local net wasting a lot of time before concluding that it can't access the Vera directly. Skipping the local check by putting it on 4G increases speed dramatically, so my guess it is the failed lookup for the local device that is the issue here.

The short answer is yes it will improve overall performance. But there is a lot going on to make the connection stay as reliable as possible, so i don't know exactly how much it will change. Also keep in mind there are also other checks that track that all servers are not working and it will try to then refresh that server list (because the vera folks randomly change those sometimes... very poor design), so there is overhead when that happens. This is all there to try to keep the connection working all the time... if possible.

But i like the idea of a remote only access since it removes some extra network calls. I'll add it to a future update.

Also keep in mind there are also other checks that track that all servers are not working and it will try to then refresh that server list (because the vera folks randomly change those sometimes... very poor design), so there is overhead when that happens.

Tell me about it. I noticed that I can't access the device directly when I secure it: you have to access it through an home.getvera.com. The server won't even reply or redirect when you do this. So when getvera or my internet connection go down, I can't operate the Z-wave network, no matter what access level my device has on the network (or login directly through the embedded WiFi). Credentials aren't cached on the device. And I think the access tokens are embedded in the URL, a very solid way of hiding them....

Since i'm working on enhancements to the windows 10 client i'm going to add a new feature to signify what kind of server connectivity you want to allow per unit. Currently those options will be All, Local and Remote. This will allow a user to streamline the network checks the app does. Some of these features i will back port to 8.1 as i have more time.