Public Beta Build of Version 2.0 (Closed: Official Release in Market)

Apps & Remote Access Unmaintained
1

IMPORTANT: If you are upgrading from 1.3 or older, you will need to remove the previous version before installing.

Everyone, with the new public build of UI5 for Vera announced, I have decided to release a public beta build of the next version of AutHomation/AutHomationHD. This will be version 2.0. The main focus is to have a more unified UI across all platforms that allows me to manage the code in an easier way. Here are some features and I will be adding additional features before a final release:

What has changed:

  • New user interface (trying to make it more unified across platforms e.g. tablets, googletv, phones)
  • Added an “All” section to display both scenes and devices
  • Added an option to poll data in the background when the app is not running. (this is experimental and could drain your battery faster)
  • Many bug fixes and other tweaks
  • Cleaned up a lot of code and reworked it to allow for better management of adding additional support for devices

I will have to warn that there will be issues and bugs. For the most part, it has been pretty stable. With the new changes in the UI, I have been spending a lot of time trying to get majority of the features back in place. Now I will focus on adding more features and device support and fine tune the graphics. If you feel comfortable to try a beta release, please give it a go and provide me any feedback or issues that you may have.

Here is the download link:

https://www.wuala.com/garrettwp/Android/AutHomation/Public%20Test/?key=cqDXsXIbSidI

AutHomation = Android 2.3 and older
AutHomationHD = Android 3.0 and newer (Tablets, GoogleTV, etc)

  • Garrett

UPDATE Release Candidate:

Date: 2012/05/21

I am hoping that this will be the official release. If I do not see any new bugs in the next few days, I will release this into the play store.

Changes:
Minor bug fixes
Added option to turn off text to speech for Voice Recognition.
Added option to change the Voice Recognition error message (e.g. I’m sorry. I’m afraid I do not understand the request.")
Minor tweaks to the under the hood for Voice Recognition.

UPDATE Beta 9:

Date: 2012/05/13

It looks like we are getting very close to a stable build. I have been receiving less reports of issues. Hopefully we can get this pushed out to the market very soon. Let me know if there are any issues.

Changes:
More bug fixes
Added window covering and other minor voice actions to the voice recognition (Clicking on the ( i ) icon in the voice recognition dialog will give you a screen of actions to speak)

Window Covering:
[Open|Close] (device name)
(device name) [Up|Down|Stop]

Added the ability to have the camera image refresh at a specified interval (located in the settings section under devices. Default value is 30 seconds. I plan to have camera streaming in a future build. However testing it will be an issue since the option to have Vera tunnel the camera stream is not working for me.)

UPDATE Beta 8:

Date: 2012/04/29

Changes:
More bug fixes
Added more voice recognition commads:

Thermostat:
Mode:
[Set/Change/Adjust] thermostat name to [Auto|Cool|Heat|Off]
Fan Mode:
[Set/Change/Adjust] thermostat name [fan] to [Auto|On]
Cool Temperature:
[Set/Change/Adjust] thermostat name [cooling|cool temperature] to [temperature]
Heat Temperature:
[Set/Change/Adjust] thermostat name [heating|heat temperature] to [temperature]

Status Info:
Battery Level:
[What is] the [battery level] of device name
Temperature (thermostat, etc)
[What is] the [temperature] of device name

Poll device:

[Poll] device name

Refresh Data:
[Refresh data]

I will try and get a better write up done for the voice commands. If you have any requests, please let me know. I also forgot to mention that the voice recognition portion of the app can accessed via a home screen widget. It is just an icon that allows for direct access to the voice recognition. It can be added by adding a new widget to the home screen and selecting “AutHomation VR / AutHomationHD VR”.

UPDATE Beta 7:

Date: 2012/04/24

Changes:
Many bug fixes and force closure fixes
Voice Recognition (Experimental and a work in progress.)

Voice Recognition Info:
English only
May require Google Voice search found in market
Untested on AutHomation (Anroid 2.3 and older)
More commands to come

Usage:

Binary Lights:
[Turn On/Off] device name
[Turn] device name [On/Off]

Dimmable Lights:
[Set/Raise/Lower/Increase/Decrease] device name to [0-100]
[Set/Raise/Lower/Increase/Decrease] device name to [0-100] percent

Locks:
[Lock/Unlock] device name

Security Sensors:
[Arm/Bypass] device name

Scenes:
[Run/Start/Activate/Execute] scene name

Status Info:
[What is the status] of device / scene name
(supports binary lights, dimmable lights, locks, security sensors, scenes, temperature sensors, humidity sensors, energy devices)

Lots more to come with Voice Recognition. Please let me know how it works out for you. It works well if the device and scene names are pronounceable and not abbreviated. You can say part of the name e.g Kitchen Cabinet Lights → Cabinet Lights.

UPDATE Beta 6:

Date: 2012/04/15

Changes:
Many bug fixes
Fixed memory leaks
More UI adjustments
Added the ability to select either slider or buttons for dimmable devices and window coverings.

Added better device support for AutHomationHD (between phones, tablets and googletv)

This release is more to fix many bugs and memory leaks. No new major features were added.

UPDATE Beta 5:

Date: 2012/03/24

Changes:

Reworked UI for thermostats
Added slider for dimmers and window covering devices replacing the on/off buttons on the device tile
Added battery level support for battery powered devices (requires UI5 version 1.5.344 or newer)
Better connection failure handling
Minor UI tweaks
Bug fixes

UPDATE Beta 4:

Date: 2012/03/16

I have posted an updated beta (beta 4).
Changes:

More bugs fixes.
Support for window coverings.
More UI tweaks
Added error reporting when app crashes (can be disabled, but will help me make this app stable)
Added quick controls for alarm arming/disarming
Added quick controls for window coverings open/close
Added connection status indicator. When the app is refreshing, a “L” will display in the progress indicator for Local connection and a “R” will display for remote connection. (Credit goes to rakstar for this idea)

UPDATE Beta 3:

I have posted an updated beta (beta 3).
Changes:

Bug fixes,
UI changes and tweaks to accommodate some of the user’s requests
Added heater device support (Danfoss, etc) - Let me know if there are any issues.

2

Just downloaded it and trying it out on my Honeycomb Galaxy Tab. Looks good! I’ll report any issues I see.

3

Garret,
I have a private Android APP that I have been using for managing Vera. But I like the way yours is going so I will drop mine.
The primary feature of mine that I like is quick access to things with one hand.
I had a 3 level tree … Section … Room … Devices + Scenes.
The max number of items to scroll was at most #Sections, #Rooms In Current Section + (devices and scenes) from current selected room. If you clicked on any Section or Room node it collapsed the current room and opened the one you picked … if you picked the current expanded room it would collapse the device and scenes and you would have a simple Section/Room tree. I have close to 100 Scenes + devices. Something to think about.

Relative to polling in the in the background … I had a service to do all of the IO to Vera. And it constantly polled data … It’s lifecyle was the length of any activity + 10 minutes in case you came back quickly to change something else. I used the events to update the original cached state list of variables. The activities always worked off of that … The service would send events to the activity if data changed.

4

This may not be a new bug; I never tried with the previous version.

Changing the Arm/Bypass mode on my security sensors doesn’t cause them to change state on my security system. Tailing the LuaUPnP log shows silence when I press Arm or Bypass on the security sensor on AutHomation.

AutHomation shows “Command Sent. Response: OK” when I press Arm or Bypass. It should be getting back a job ID with this security sensor’s implementation. The security sensor is a child device of a Caddx Security plugin. Implementation is here, action is the usual urn:micasaverde-com:serviceId:SecuritySensor1::SetArmed.

If I watch the web interface while pressing Arm/Bypass on AutHomation, the Arm/Bypass symbols change on the device on the web browser in tandem, but the message is never sent to the security system. This suggests that AutHomation is just setting the Armed state variable rather than calling the SetArmed action.

The same action when done entirely on the web interface works as expected and I see messages in the LuaUPnP log.

I actually don’t use the Arm/Bypass feature for security sensors so I am not missing anything with it not working. This is actually the most serious issue I’ve had, and for me it’s a non-issue.

AutHomation HD Version: 2.0.1.2
Vera OS: 1.5.322
Android OS: Honeycomb
Android device: Samsung Galaxy Tab 7.7

Edit: ooh yeah, the variable is being changed directly:

06	03/04/12 12:50:08.274	Device_Variable::m_szValue_set device: 166 service: urn:micasaverde-com:serviceId:SecuritySensor1 variable: Armed was: 1 now: 0 #hooks: 0 upnp: 0 v:0xb88178/NONE duplicate:0 <0x2e614680>
5

Arming a Caddx security partition results in the error “Invalid Service”.

From the Luup log I can see why:

08	03/04/12 12:55:57.012	JobHandler_LuaUPnP::HandleActionRequest device: 94 service: urn:micasaverde-com:serviceId:AlarmPartition2 action: RequestQuickArmMode <0x2cfe7680>
08	03/04/12 12:55:57.012	JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:micasaverde-com:serviceId:AlarmPartition2 <0x2cfe7680>
08	03/04/12 12:55:57.012	JobHandler_LuaUPnP::HandleActionRequest argument DeviceNum=94 <0x2cfe7680>
08	03/04/12 12:55:57.012	JobHandler_LuaUPnP::HandleActionRequest argument action=RequestQuickArmMode <0x2cfe7680>
08	03/04/12 12:55:57.013	JobHandler_LuaUPnP::HandleActionRequest argument State=Stay <0x2cfe7680>
01	03/04/12 12:55:57.013	JobHandler_LuaUPnP::HandleActionRequest can't find urn:micasaverde-com:serviceId:AlarmPartition2 <0x2cfe7680>

The service Id is not “urn:micasaverde-com:serviceId:AlarmPartition2” on the Caddx plugin but “urn:micasaverde-com:serviceId:AlarmPartition1” (code). Control points like AutHomation can’t just hardcode these service IDs; they need to parse the device file looking for the service type, and use the matching service Id. (The Vera web interface gets this wrong too, FWIW.)

Edit: you know, I say that, but I’ve got a nagging feeling that I might be wrong about it. Who is in charge of service Ids? Think I need to do some more research about how UPnP interoperability was designed to work…

6

Futzle,

Thank you for your incite. I am using lu_sdata and this does not provide me any data for device type or service id. I have asked MCV to add this to the lu_sdata. I use lu_sdata as it is a fraction of the size of user_data2. This makes it faster to parse the data and keeps the bandwidth down as well. But I hit this limitation of knowing the device serviceid, etc. One suggestion I can do is that when first clicking on the device, I can retrieve the lu_action data and add that to the device data. This would only be a first time thing and will be able to get the proper service id to use. Any thoughts?

  • Garrett
7

Hi Garrett,

lu_sdata is, frankly, useless. Because it hides the service Id of state variables it can’t behave in a predictable way when there are two variables with the same name (“status”) in different namespaces. It doesn’t tell you what actions are available (or not) on a device. I think that it’s unavoidable to use lu_user_data2 at least once. Since these parts of the data are truly static, I agree that you need not call this often. Use the LoadTime attribute on both sdata and user_data2 to learn when the data is potentially out of date (from a Luup SAVE) and needs to be refreshed.

8

I use to use user_data, but even using the dateversion and loadtime, it would do a full sync more often than I would have liked. Also the data is very large and I am trying to avoid excessive bandwidth. But if I have to resort back to user_data and sdata, I will. If I call say, lu_action on the first open of a device, I can get the service id and action states without having to rely on user_data. So my options are do I use lu_action or do I go back to user_data and sdata? Thoughts?

  • Garrett

p.s. I appreciate you all providing me feedback. I want to make this app work for everyone and if I have to change the way I do things, I will. I want to make sure I go the best route possible without making an compromises.

9

Hi,

Looking great. But have an issue with the Danfoss thermostats

Shows up with “Error Thermostats is not configured” and the gui that pops up, shows cooling and heating, the “heat temp is correct” but the icon, shows as -1

Hope you can help.

And the “Virtual Switch” shows up as “?” as does the “Info container”

/cokeman

10

cokeman,

I still have not incorporated the danfoss thermostats yet.

As for “virtual switch” and “info container”, these plugins are not supported.

  • Garrett
11

It’s a dilemma, I admit. For my Vera, sdata is ten times smaller than user_data2, so your point is well made. There may be nothing else for it than to code it up and see. Personally my Android device is Wi-Fi only, so I’m less concerned about data usage than a phone owner would be about 3G data. Make sure you filter my opinions through that knowledge.

12

Thanks Futzle for your incite. I have to think about which route to go. Both methods supply similar data. User_data will be a little harder as the service id’s under ControlURLs are not in an array and makes parsing the data tricky. Now another problem is trying to figure out which serviceid to use as most of the devices provide multiple.

  • Garrett
13

[quote=“futzle, post:5, topic:170744”]The service Id is not “urn:micasaverde-com:serviceId:AlarmPartition2” on the Caddx plugin but “urn:micasaverde-com:serviceId:AlarmPartition1” (code).

Control points like AutHomation can’t just hardcode these service IDs; they need to parse the device file looking for the service type, and use the matching service Id. (The Vera web interface gets this wrong too, FWIW.)

Edit: you know, I say that, but I’ve got a nagging feeling that I might be wrong about it. Who is in charge of service Ids? Think I need to do some more research about how UPnP interoperability was designed to work…[/quote]
Um, the serviceId for “version 2” of the Alarm panel interface (or the standardization effort) was intended to be:
urn:micasaverde-com:serviceId:AlarmPartition2

The original interface, as implemented by the Paradox, the “original” DSC, and I think even the first incarnations of your GE was version 1. It had a serviceId of:
urn:micasaverde-com:serviceId:AlarmPartition1

The newer DSC code threw out compatibility, and eliminated it’s use of version 1. The Paradox implements both, so I suspect that your GE showing “version 1”, but implementing the “version 2” methods & state-Variables, might be a throwback to the time we were all transitioning the Alarm Partition implementations over.

Bottom line, we do need to have a standardized serviceId, otherwise the CP’s can’t know what methods and state-Variables exist within the device. Without standardized serviceId’s, even things like Light Switches wouldn’t work, although we can have whatever DeviceType (and friends we want, barring the CP’s that don’t handle that well)

I skimmed over the Vista, PowerMax, Elk, Paradox and DSC and they all implement the version 2 Alarm Panel serviceId:
urn:micasaverde-com:serviceId:AlarmPartition2

14

@garrettwp,
As to the size of the content, for transmission purposes, that’s why I originally created this:
http://bugs.micasaverde.com/view.php?id=1204

It’s a one-line configuration in Vera’s lighty, and things would be a lot faster for mobile devices…

with a little CPU used on either end (Vera and the Client) the compression ratio is quite high. It would save not only bandwidth, but also the time to transmit (since most phones are relatively bandwidth limited). Of course, it doesn’t fix the parse-time issues you’re looking to address as well.

15

I have used user_data2 and lu_status2. The only time I needed a resync was when Vera’s Luup engine was restarted. Not very often. So this is just a startup issue.
On my clients I always kept the JSON object from user_data2 and update it when I get new data from lu_status2. So my json object is continuously synchronized to Vera.

16

Richard,
Thanks for the info. I use a database to store the data and update the data in the database as new data arrives using lu_sdata with the loadtime and dataversion parameters. As of right now I have decided to stick with lu_sdata. Going with user_data would solve maybe an issue or two, but would not be worth the effort to rewrite. I still face the issue on what serviceid to use. I have asked MCV awhile ago to include the serviceId in the lu_sdata as well as the device_type. Hopefully that is something that can be added in the near future. They have already added additional data that should be available in the next beta.

  • Garrett
17

Is Version 2.0 dependent on UI5 ?
I have not downloaded yet because I assumed it was … But you know what they say about those that assume … :smiley:

18

No, it should not be dependent on UI5. It should work without issue in UI4 minus a few things that were introduced in UI5 for fixes. If you load it, let me know how it goes.

  • Garrett
19

I’ll fix up the Caddx plugin to use the same service id. Migrating it without messing with users will be tricky, but that’s my problem, not Garrett’s.

Edit: grammar

20

Version 2.0 beta works just fine on my V1@1.1.1338.