This is a very early alpha release so expect some bugs. In its current state, it mainly functions as a scene controller and a display for device statuses, but I’ll add more features when I get the time.
I’d appreciate any feedback from the community. Thanks!
EDIT: apk is not available on the site anymore, please install from the Android Market.
Rakstar, that’s great! I wish an android phone to test it on. One question, though… Why are you using ssh? You know you can do everything with the regular port 3451 data requests. And that way it works locally (over wi-fi) and the same code will also work remotely, using findvera.com. You only change the base address on the URL, but everything else is the same. Also, that way the user doesn’t need to set a root password. If you want to discuss how all this works, feel free to call me on the phone, or by instant message (go to micasaverde.com, click ‘support’).
micasaverde, I decided to use ssh so that it can be used with any DCERouter server – possibly LinuxMCE users too. My problem with port 3451 data requests is securing it when opened up for remote access – I know findvera.com resolves this, but LinuxMCE users will be completely exposed.
I guess I can make a Vera specific version too which requires a less intrusive setup. I’ll work on it when the updated firmware comes out.
I don’t this should be an issue to preserve support with LinuxMCE. Presumably in your code, you have a function responsible for sending the message, which could use the same declaration like LinuxMCE/Vera: MessageSend( long dwDeviceIDFrom, long dwDeviceIDTo, long dwPriority, long dwMessageType, long dwID, unsigned long dwParameterCount, … );
Then everywhere in your code you just call the function to send the message without worrying about the back-end. In that MessageSend function, it would just have an ‘if’ for Vera vs. LinuxMCE. So it’s only a couple lines of code that’s different. If your Android app uses C, you could also use the libDCECommon library.
What does make the Vera/LinuxMCE more difficult is that if you want to provide the user interactive, real-time feedback, so he can see for sure that his command is being processed, see a ‘busy’ indicator while it’s in process, and it turns to an ‘ok’ or ‘fail’, that makes the UI experience a lot better, but it requires vera’s zwave_status data, and there is no equivalent in LinuxMCE. So, for basic “blind send” cross Vera/LinuxMCE compatibility should be trivial, but it’s the interactive part that gets more complex.
It may be nice to have an app for Android but the regular findvera website works pretty well on my phone. I don’t even bother with the mobile version. I can’t set door codes with it. I have a G1. I like having a real keyboard.
I agree it would be nice to not have to scroll all over the place but I don’t want some dumbed down version. It has to have full funtionality. The regular website could be much better in this aspect also. I don’t know why it needs 2 scroll bars. It just makes it more difficult to see everything quickly. First I have to scroll the main page then vera’s inner page. It’s just a bad design.
This double scrolling is a pain in the @@@. Needs to be removed… I was using one of those tiny 7" laptops this weekend and it made it REALLY difficult and annoying.
Agreed… the current interface(s) is too full of “whitespace” and bloat, with overly large buttons and UI elements. The scrolling is entirely too cumbersome.
Imagine if the UI had more “hover” and “expanding tabs” functionality, so merely hovering over certain panels / areas revealed things like “More Options” instead of click-click-click!
I realize MCV’s going for a one-size-fits-all (-and-scales-well) look and feel - and have to appeal to mobile users and mouseless contexts - but in my opinion overshot that mark with so many pages and submenus.
We’re working on a completely new UI anyway which is flash-based. The double scroll bars are a pain. That only happens when accessing through findvera because, with the current design, the Vera web interface is running on your local Vera (not on findvera) and FindVera is just displaying a secure “window” (ie iframe) into your Vera. The outer scroll bars are from findvera for the iframe, and the inner ones are from Vera for Vera’s UI.
I’d like to throw a little suggestion into this thread since MCV said they are developing a new UI…
Could it be a little more customizable? The green cartoonish look is a little… ummm… for lack of a better word… embarassing… when onlookers are watching the user control their house. I can understand the need for a “simple” looking UI for some people. But others may want something a little more… professional looking. Even just a color scheme or “theme” option would be an improvement. I feel like I am trying to operate software targeted for a 5 year old learning how to spell.
I also do agree with LS that everything is just a little too big and too much bloated empty space.
Not trying to whine or flame here, the interface works for now… it’s just a suggestion for the future.
For my use I will probably never connect to any of the Vera’s directly (will ultimately have 21-25 of them if I launch this resort wide). It will always be through findvera.com and through a smartphone on occasion, so that interface is ultra important to me. Look forward to the changes, I understand you can’t do everything at once and this is an evolving project.
Hi Guys! Sorry for the hiatus but I’ve been very busy with my day job and haven’t had the time to update Home Buddy. I will try to get it working with the latest Vera firmware and add some more functionality. A couple of things I had in mind are Locale integration and a widget to activate scenes – if anyone has other suggestions, please post, I’d love to hear them! Thanks.
So you want suggestions? Beware of What You Wish For
Vera API for external and on-LAN access is pretty much the same - you just send the request via findvera.com, or directly with the same parameters. So, it would be priceless of your app could connect from outside of LAN, or even switch between WAN and LAN modes.
Access to cameras - they do low resolution static images, so bandwith shouldn’t be an issue
1. Vera API for external and on-LAN access is pretty much the same - you just send the request via findvera.com, or directly with the same parameters. So, it would be priceless of your app could connect from outside of LAN, or even switch between WAN and LAN modes.
That’s what I was planning to do. Instead of the SSH approach I used before, I’ll try to make the requests via http and the URL configurable.
2. Access to cameras - they do low resolution static images, so bandwith shouldn't be an issue
Unfortunately I don’t have an IP camera to test with, but once I get everything working I might consider getting one
I recommend the automatic switch over to wan if lan is not available. I implemented this on my Adobe Air
UI air4vera and it really works well. The source is available if you want it.
