I can log into findvera.com on my home network PCs and any outside PC but the iPhone app will not allow me to log in at findvera.com/iphone or even findvera.com through Safari. I am getting my fairly usual long wait from Vera support. Any users have any ideas? Thank-you so much in advance. ;D
I can login to findvera.com on my iPhone over both the 3G Network and my home Wifi Network.
It’s slow when attempting to access over 3G, but it it eventually gets in and renders correctly.
I dont use the /iphone version of the interface, so the comments below only relate to the primary/mainstream pages.
Here are a few observations on the interaction with the findvera.com service, there might be some easy fixes in here, but some (like the first) will be harder to address:
a) Network ping RTT are 200-450ms for my iPhone to either ra1.findvera.com or findvera.com.
These are in the same datacenter, but appear to be using separate VIPs and/or Servers.
450ms RTT was at ~7:00pm PDT
200ms RTT was at ~8:45pm PDT
For comparison, the RTT time from my Vera to findvera.com is approx 87ms. We’d need ATT to do something about the larger Latency #'s that “add” to this equation, esp since that impacts every Network app, not just this stuff.
For the rest of the tests below, I used Firefox/Firebug and I “cranked up” the Latency on my home network (CA, USA) to make it look closer to the iPhone figures.
b) SSL and HTTP Keep-Alive
How short is the Server side keep-alive timeout? I was seeing some stuff in Firefox/Firebug and Wireshark that implied it was set very low. It looks like it might have been 1sec, but I must be reading that incorrectly. I do see a number of cases where more SSL Negotiations are going on The browser max, assuming keep-alive, should be “2-4” (depending upon browser), but seeing “8” or more in some cases, which is costly with (a) above. If this is going on, combined with (a) it could add several seconds to the page load times and extending it a little will ease that pain.
c) Web page/payload size (findvera.com)
The main (regular) findvera.com page is 263KB, which breaks down as roughly:
images - 13 (101k) -
javascript lib - 4 (149k)
main html - 1 (8k)
css - 1 (4k)
A few general suggestions that might help here:
c1) enable mod_gzip, or run a compression tool over the main JS Library (123KB)
We’ve seen these shrink to 10% of their original size in some of our tests.
c2) glue all the JS Libs together to avoid the serial loading/executing effect
This will help folks with higher latency environments or geographies. In my render, Firebug shows about 1/2 (2s) of the total page load time (4s) being spent in loading/executing these 4 JS libraries.
c3) shrink or otherwise eliminate layout.jpg (88KB)
d) Web page/payload size - (ra1.findvera.com)
The authenticated (ra1.findvera.com) page is 257KB, which breaks down as roughly:
images - 12 (91k) -
javascript lib - 4 (149k)
main html - 1 (6k)
css - 1 (9k)
A lot of this content is logically shared with that loaded in the findvera.com “startup” page (non-authenticated), but because these are being loaded from a different web address (ra1.findvera.com vs findvera.com) the browser is reloading them all.
If possible, load the secondary content (images, JS etc) from the findvera.com address to avoid having the browser reload it.
e) Web page/payload size - (ra1.findvera.com “Control” page)
The “Control” page of (ra1.findvera.com) is large at 1.26MB.
257KB, which breaks down as roughly:
images - 12 (258k)
javascript lib - 4 (637k, including Json)
main html - 2 (88k)
css - 3 (54k)
Obviously this page has the greatest gains to be had if Compression of the Json can be done, and the images and other JS libraries “slimmed” somewhat. It’s going to load very slowly on an iPhone.
As a general comment, I’ve gotten great support from the MCV Team. My focus is probably a little different since I’m looking more to integrate with My Alarm system (via LUA) than the more typical Lights-and-Power type stuff most want it for… well, ok, at least for now 
In all my interactions, they’ve been eager to help, and skilled to do so. They replaced the entire Serial Proxy after a long and detailed debugging session, they’ve responded to forum feedback and have evolved their product, and they’re online at all sorts of odd hours. They also have a clear path, albeit a busy one, to make the device extremely extensible.
Personally I don’t think we need a separate forum for these discussions. I think everyone could benefit from more details on the problems being experienced so they can work on fixing them, and we can share experiences (and pains!) to see if there are common threads
[ul][li]How long did it take?[/li]
[li]What version are you running?[/li]
[li]Was a support ticket filed?[/li]
[li]If it didn’t work, what did the screen look like (a picture, 1000 words and all that)?[/li]
[li]iPhone spec, but Edge, 3G or Wifi?[/li][/ul]
The more information we can give them, the more likely they can target the “right” bit of code to fix it up. Something we’ll all benefit from.
Hey Folks:
Micasaverde support had me clear the cache & cookies from my iPhone which did the trick. Everything works great now. I freely admit that I am not overly intelligent in these kinds of details. For instance, while I appreciate greatly the first post in response to my original question above ::), it’s all Greek to me!
Sorry about that, my response above was intended for the Web Engineers on the MCV team, but also to indicate that ATT is contributing it’s own set of issues.
I’ll lower my caffiene levels now
Short version: Lots of stuff being downloaded translates to a slow browsing experience, and they can improve upon that with some simple changes…