It's possible, this is what Automator.app does, and thus can render custom plug-ins. All the information is available to remote clients, it's just a matter of figuring out how it all works with Vera now.
You’re right, [tt]user_data2[/tt] does contain the rendering information. Search for the [tt]DeviceType/device_type[/tt] in [tt]static_data[/tt] and render all elements with [tt]“ControlHeader”: “1”[/tt] …
@garrettwp
Would you be willing to add the rendering for custom Luup plugins to AutHomation?
If I were using user_data2, this would be something I would have considered. However, I am using lu_sdata which contains a much smaller set of data. This is what MCV suggests when building control UI’s (this is suppose to be the new way). Origionally I was using user_data2 and when MCV updated their wiki and some digging, I decided to switch over to lu_sdata. The data from lu_sdata is only about 10.5KB for my setup and the user_data2 version is 320KB. So there is a huge savings in downloading the data as well as less resources are being used when parsing the data for the required information.
There is suppose to be a way of setting short codes in the plugins that would get generated in the lu_sdata. I do not know much about making plugins for vera, but if the plugins contained the short codes for what information needs to be displayed etc, I can parse that information. I also use the category number in the lu_sdata to determine the type of device it is. Not all plugins contain a category number. Maybe this is something we need to brainstorm to help make things more organized and to allow for third party interfaces work well with plugins.
On a different topic, I have been busy the last few days with work. I have not had a whole lot of time to work on AutHomation. But I do want to say that I am adding new layouts that will work better with larger screens (7inch and 10inch) for Android 2.3 and older. I overlooked some documentation on the android developers page for designing for different screen sizes and I am adding code to have a similar layout to the AutHomationHD version for these larger screen devices. So for all those nook and cheaper tablet users will soon have a similar experience that the Honeycomb version has to offer. Hopefully I can have something out in the next few days. There will be other minor fixes and changes added as well.
However, I am using lu_sdata which contains a much smaller set of data. This is what MCV suggests when building control UI's (this is suppose to be the new way)
IMHO MCV’s suggestion is flawed in the sense that [tt]lu_sdata[/tt] doesn’t contain rendering information for custom plugins that are using new UPnP services.
The data from lu_sdata is only about 10.5KB for my setup and the user_data2 version is 320KB.
Valid and important point, but the rendering information in [tt]user_data2[/tt] is quasi-static and could be cached.
There is suppose to be a way of setting short codes in the plugins that would get generated in the lu_sdata. I do not know much about making plugins for vera, but if the plugins contained the short codes for what information needs to be displayed etc, I can parse that information.
AFAIK there is no standardized way to get rendering information across using [tt]lu_sdata[/tt]. [tt]lu_sdata[/tt] even may contain data that isn’t meant to be rendered on the GUI.
[tt]user_data2[/tt] most definitely has WAY too much data in it, stuff like MAC addresses of stuff on your Network (etc), that are really part of the backend implementation, not something that should be exposed to a [remote] Control Point.
Looking at it, you can understand why they want to move people away from it, but the [tt]lu_sdata[/tt] implementation seems to have swung too far in the other direction (too little information for UI tools)
Not to forget the leakage or passwords for cameras and the leakage of custom Lua code for scenes and events.
One could probably install a custom handler that extracts the rendering information from user_data2 and provides the rendering information to the UI client.
Thanks for the positive comments. I am hoping to release both versions to the market soon. I’ve added some new features and rewrote some of the code. Also trying to add support across most of the android plateforms. I am also looking into googletv support. I have it running in the googletv emulator, have some usability kinks to work out. Hopefully I can release a new update in the next few days.
Alarms are on my todo list, however the way I get the data e.g. lu_sdata, not all of the required information is there. But it is on my list of features to add. As for AV control, I will add that to my list as well.
I love especially how fast it starts up, and the size of the switch buttons!
I love it!
Here’s some things that could be improved imvho:
If you are in the ‘Favorites’ view: When pushing the app to background, to open some other app: On return to AutHomation, the virtual keyboard is brought up.
(Does not matter if I return to AH using the task list or use the AH program icon to return).
After pressing a button the user interface gets tied up the some background stuff (presumably sending), where one is presented with a ‘working’ icon and some information about the sendout. During this time, the user interface reacts as if it was accepting commands, which it isn’t (at least not fully).
It would be nice if the request could be put into a queue, so one could switch on/off the same device without having to wait for the current job to finish.
This is mainly an issue if one accidently presses the wrong device during scroll etc.
It is quite common to accidently hit a dimmer device drag bar when scrolling, especially if one is scrolling just after switching on/off a device. (Maybe it is me that is a bit clumsy)
I use the non-hd version, along with ‘favorites’. Since I have a few devices, even the favorites gets to have quite many items.
Once idea that I would like, would be if one could add/create multiple favorites (e.g. ‘Upper Floor’ / ‘Basement’) to the start menu.
[quote=“vespaman, post:33, topic:169295”]This app is great!
I love especially how fast it starts up, and the size of the switch buttons!
I love it!
Here’s some things that could be improved imvho:
If you are in the ‘Favorites’ view: When pushing the app to background, to open some other app: On return to AutHomation, the virtual keyboard is brought up.
(Does not matter if I return to AH using the task list or use the AH program icon to return).
After pressing a button the user interface gets tied up the some background stuff (presumably sending), where one is presented with a ‘working’ icon and some information about the sendout. During this time, the user interface reacts as if it was accepting commands, which it isn’t (at least not fully).
It would be nice if the request could be put into a queue, so one could switch on/off the same device without having to wait for the current job to finish.
This is mainly an issue if one accidently presses the wrong device during scroll etc.
It is quite common to accidently hit a dimmer device drag bar when scrolling, especially if one is scrolling just after switching on/off a device. (Maybe it is me that is a bit clumsy)
I use the non-hd version, along with ‘favorites’. Since I have a few devices, even the favorites gets to have quite many items.
Once idea that I would like, would be if one could add/create multiple favorites (e.g. ‘Upper Floor’ / ‘Basement’) to the start menu.
Cheers!
Micael[/quote]
I put in a fix for the keyboard issue loading when resuming the app. You should be able to turn on several devices at a time. Though there may be some glitches in doing so due to how the code works. I will look into queue up tasks, however, this may/will require rewriting code and will require some thinking / brainstorming on the best way to do this. As for the slider for the dimmer, yes this can be an issue. I need to think of the best way to prevent this (not an easy task). What I can do is have the slider hide until you touch anywhere in the area of the device to have it display. I need to do some brainstorming here. For the time being, you can scroll by placing your finger to the left side of the screen.
I have no videos of the app in action. If I get time, I will try and make a video. Since the app has gone through various stages of design and since it is still considered in testing, making a video of it right now would not be a good idea.
I wanted to post that I was able to test my app on a co-workers kindle fire. I can say that the app works really well on the device. Choosing to force the tablet layout under the “App Settings” makes the experience pretty nice. I did notice a few little UI issues that I will need to fix. Between the Kindle Fire and BN Nook Tablet, I say they are great cheap controllers for Vera.
[quote=“garrettwp, post:36, topic:169295”]As for the slider for the dimmer, yes this can be an issue. I need to think of the best way to prevent this (not an easy task). What I can do is have the slider hide until you touch anywhere in the area of the device to have it display. I need to do some brainstorming here. For the time being, you can scroll by placing your finger to the left side of the screen.
Garrett[/quote]
Hiding dimmer slider is a good solution as far as I’m concerned (others may disagree, obviously).
