UI Feature request

[Illusion]

Hi Wes,

 

Thanks for continuing to improve the product. I send everyone interested in Insteon your way.

 

I would like the ability to turn off the shake to return to home screen function on the iPhone.

 

Each year I use my iPhone in the yard to turn the sprinklers on and off as I make annual adjustments/repairs. Often I run the 'then' and 'else' of a favorite program several times in as many minutes. As such I try to leave my phone awake, but whenever I put the phone back on my belt clip it thinks I am shaking and I am returned to the home screen. It takes several operations in Mobilinc to get back to the run options for the selected program. I have resorted to locking the phone immediately after each operation. Unlocking/locking the phone is certainly not quick, but it is much faster than digging down to the desired program screen.

[InsteonNut]

Hi Illusion,

 

Thanks for the feedback. This option can be added to MobiLinc. I'll add it to the feature request list.

 

Thanks!

Wes

[Illusion]

Thank you, sir!

[oberkc]

I am a new user to mobilinc and like a lot of the features, finding many to be superior to conductor. My primary interest in the use of mobilinc is in the use of widgets as switches. I don't find it as satisfying to be compelled to take more than a single press to turn on or off a light or scene or fan or other device. In effect, I want to use my android tablet as a replacement for a keypad in a desktop enclosure.

 

With this in mind, I offer a couple of suggestions:

 

widgets should have the ability to define a default action (on, off, toggle, show menu....)

widgets should show (or give option to show) status

widgets should have ability to assign a different display name than assigned as part of the ISY

 

I have also noticed that some of my devices and scenes are not available for use in widgets.

[InsteonNut]

Hi oberkc,

 

Comments:

 

widgets should have the ability to define a default action (on, off, toggle, show menu....)

- We are considering this. We have deep concerns about accidental activation of commands on mobile devices without confirmation.

 

widgets should show (or give option to show) status

- This is not usable under Android as Android widgets are designed today. The frequency of updates for widgets is very slow (min 30 minutes) and would almost certainty result in frequently incorrect status.

 

widgets should have ability to assign a different display name than assigned as part of the ISY

- Thanks for this feedback. Under your use case why does the ISY name need to be different than a display name?

 

I have also noticed that some of my devices and scenes are not available for use in widgets.

- What are these devices or scenes? Devices or scenes with devices that are not controllable will not be available for use as a widget.

[oberkc]

We are considering this. We have deep concerns about accidental activation of commands on mobile devices without confirmation.

That is why I suggested that one of the options be to "show menu" (as is now) to allow a defualt action to require more than one keystroke for when other users desire this security against accidental activation. BTW, conductor has this.

 

This is not usable under Android as Android widgets are designed today. The frequency of updates for widgets is very slow (min 30 minutes) and would almost certainty result in frequently incorrect status.

 

Could this not be user configurable? Other apps that I have are such.

 

Under your use case why does the ISY name need to be different than a display name?

 

In my case (and, apparently based on my experience of this forum, many others) I have a naming convention that includes device type, location, and purpose (ex KP FYR Exterior Light). Such a naming convention has less value to me on a widget ("Exterior Light" might be sufficient. I notice, also, that the widget name is truncated, so I cannot even see the entire ISY name (might show up as "KP FYR Exte"). Perhaps I am the only one, but the ability to assign a different widget name would be nice.

 

Devices or scenes with devices that are not controllable will not be available for use as a widget.

I considered this possibility. One of my missing scenes is one that includes an IOLinc sensor and keypad button. Another scene is a single-device scene, including only a keypad button (secondary). Both scenes are controllable by the ISY admin page. Combined with status capability, I would use this beyond control to include quick-glance display of device or scene status (garage door open, door unlocked, lights left on). The larger picture is that I want to duplicate the capability of an insteon keypad...one touch control...status display.

 

I am using an android tablet as a single display capabile of showing and/or controlling time/alarm/weather/streaming audio/phone/ lights/surveillance/email/text/calendar/tasks. Think: Sony Dash or chumby on steroids. At this point, the only thing falling short of desires is the lighting part. The tablet is always on, always plugged in, always on wifi. Data usage is not a practical concern.

[InsteonNut]

That is why I suggested that one of the options be to "show menu" (as is now) to allow a default action to require more than one keystroke for when other users desire this security against accidental activation. BTW, conductor has this.

 

Should we decide to implement this, this is how we would do it with grave warnings and risk about accidental activation. We are still not convinced that this is a good thing to allow. What happens in the case where you hand your phone to a friend or family member and they swipe and accidentally open your garage door?

 

 

Widgets are not active 100% of the time. They are scheduled to be updated. The minimum time as allowed by Android is 30 minutes. Any app that appears to be updating more frequently is using a different method to appear like it's updated. In order to reach out to the network and connect with your ISY for status it would be on a 30 minute interval at best (as limited by Android) and would have the effect of additional battery drain for status you couldn't trust as being current. I completely understand your use case, however, the Android widget concept is not going to support what you'd like to see here regardless of any Wi-Fi/Power/data constraints or lack there of.

 

For your naming convention are you using folders to organize your devices/scenes/programs? We find that if you use folders for organization you can remove all the navigation/identifying type language from the name of the device and just name the device what it is: Kitchen Lights for example. You still keep your organization rooted in folders in the ISY but the added benefit is the day to day UI is cleaner.

 

For your non-showing widgets, this is expected. The devices you identified are not controllable. The KPL is a partial exception here only because it is in a scene. You cannot directly control the status of the KPL as an individual device and that's why MobiLinc has chosen to not show you these devices or scenes as widgets as it believes these to be uncontrollable. For a scene to appear as a widget option as least one device in the scene must be controllable.

 

Wes

[oberkc]

For your naming convention are you using folders to organize your devices/scenes/programs?

 

yes

 

We find that if you use folders for organization you can remove all the navigation/identifying type language from the name of the device and just name the device what it is:

 

Yes, I suppose I can do this. However, I continue to maintain it would be nice to have the feature to give a widget a unique name, rather than forcing users to limit the naming convention.

 

For your non-showing widgets, this is expected.

 

yes...so I have learned. I find this to be a shortcoming for my purposes. I guess I better continue to rely on conductor for these types of scenes and hope that it keeps working.

 

What happens in the case where you hand your phone to a friend or family member and they swipe and accidentally open your garage door?

 

Perhaps I was not clear. I suggested making a default action as an OPTION.

[InsteonNut]

oberkc,

 

We are considering a couple of widget changes that will hopefully address or mitigate your concerns:

 

- Allow a custom name to be used for the widget.

- Include scenes for widget selection that only have KPL buttons in the scene.

- Allow users to remove unwanted commands from Widget selection. However, confirmation of the command to send will still be present due to safety and liability concerns we have in cases where you or another user, unaware of the consequences, swipes to change pages and accidentally activates your widget.

 

Wes

[dss]

We are considering this. We have deep concerns about accidental activation of commands on mobile devices without confirmation.

That is why I suggested that one of the options be to "show menu" (as is now) to allow a defualt action to require more than one keystroke for when other users desire this security against accidental activation. BTW, conductor has this.

 

This is not usable under Android as Android widgets are designed today. The frequency of updates for widgets is very slow (min 30 minutes) and would almost certainty result in frequently incorrect status.

 

In regards about accidental activation I think yes certainly you could think of worse case scenarios that you wouldn't want to implement it as the default but I think it should be an option and for garage doors and door locks whoever sets it up should be careful about it as they would with setting up a keypadlinc button, TouchLinc and Table-Top Touch Screen Controller. Perhaps you would want a two step control when controlling something critical like locks or garage doors but lights make them one touch. I too would like to use a tablet as a dedicated home control interface (Nexus 7 at $199 beats any TouchLinc 2490C7 or Table-Top Touch Screen Controller 12006) and I would like to have widgets that duplicate the function of a TouchLinc or Table Top Touch Screen Controller that show actual status and one press control of lights. Having no status and menu pop ups is really clunky for a dedicated touch control. The 2490C7 and 12006 have icons that control lights with one touch and show status as little LED lights seems like you should be able to use widgets and a Nexus 7 to do the same as what the 2490C7 and 12006 do.

 

It seems like widgets that I have refresh more frequently than every 30 minutes. I use the Elixir 2 Widget and it shows CPU load which seems to refresh perhaps every few seconds. I will open the multitask button, swipe closed a few apps and when I come back to the home page the CPU load % has changed. Don't know if it is real-time but just a few seconds and certainly not 30 minutes.

 

Also on the topic I would like to request an Android tablet version of Mobilinc because I think people are going to catch on that a Nexus 7 will make a great automation controller and at $199 you could have several around the house. I'm thinking of purchasing a frame for one and mount it on the wall.

[dss]

oberkc

 

In regards to the Widgets you can try Conductor of Insteon:

https://play.google.com/store/apps/deta ... R1Y3RvciJd

 

It has widgets that change with one click and displays status updates.

 

You can use both Mobilinc and Conductor since they both just feed off of the ISY. You can't rename the widget though.

[InsteonNut]

dss,

 

It seems like widgets that I have refresh more frequently than every 30 minutes. I use the Elixir 2 Widget and it shows CPU load which seems to refresh perhaps every few seconds. I will open the multitask button, swipe closed a few apps and when I come back to the home page the CPU load % has changed. Don't know if it is real-time but just a few seconds and certainly not 30 minutes.

 

They are using a timer-based method to update widgets working around the native Android/Widget limitation of 30 minutes min for refresh. This method is very costly in several areas not to mention not officially supported or recommended to be used for Widgets. There are certain limits imposed by the OS using this method that might preclude a long network-timeout attempt to reach the ISY. Also, it might require that the main app maintain a constant connection (or frequent connect/disconnect requests - every few seconds) to the ISY to poll the current status. If the Android device were to disconnect from Wi-Fi and sit on a cellular connection, that's quite a bit of data chewing up your bandwidth plans not to mention severe battery drain issues. We believe technically this is possible to do, however, it would require us to use methods not officially supported, against the Android UI guide, and well as introduce severe battery drain issues.

 

I do completely understand the want for widgets to act like real-time status devices, but I'm not sure how Widgets are implemented today will meet the needs you and others are looking for at a performance that is acceptable.

 

If we were to explore building a separate Widget/app to support this specific table-top/wall mount use case (Wi-Fi only, plugged-in, near real-time status, non-confirming issuing of control commands) would the Android community be willing to pay separately for something like this?

 

Also on the topic I would like to request an Android tablet version of Mobilinc because I think people are going to catch on that a Nexus 7 will make a great automation controller and at $199 you could have several around the house. I'm thinking of purchasing a frame for one and mount it on the wall.

 

We have our Android tablet plans on hold for now. The current demand in the table space is heavily dominated by the iPad. Demand for MobiLinc HD on Android tablets is quite low. As demand and a market space increases for Android tablets we will reevaluate our plans.

 

Wes

[dss]

dss,

 

If we were to explore building a separate Widget/app to support this specific table-top/wall mount use case (Wi-Fi only, plugged-in, near real-time status, non-confirming issuing of control commands) would the Android community be willing to pay separately for something like this?

 

We have our Android tablet plans on hold for now. The current demand in the table space is heavily dominated by the iPad. Demand for MobiLinc HD on Android tablets is quite low. As demand and a market space increases for Android tablets we will reevaluate our plans.

 

Wes

 

I would pay separately for (Wi-Fi only, plugged-in, near real-time status, non-confirming issuing of control commands). Actually Conductor for Insteon have widgets that already do this so I guess I already have.

 

Hopefully the Nexus 7 will improve demand for Android Tablets and home automation in particular. I have an iPad too but for the DIY home automation I find Android tablets better specifically because of widget support. With the iPad you just have a dead desktop of icons and you have to click one of them to do or see anything and it takes up the whole screen. With Android Tablets there are various widgets that can be put on the home screen. Current weather and forecast, , large clock display, calendars from Gmail, streaming news ticker, Google Voice messages, traffic maps, Todo lists and Insteon device status. I can just glance at the desktop and get a wealth of information without having to click into each app.

[Illusion]

Thanks Wes,

 

I appreciate the update that includes the requested feature!

[InsteonNut]

Great! Glad you noticed your request made it in the update

 

Wes

[joshdub]

I would also pay separately for the specific wall-mount use case. I am wall mounting a nexus 7, and having these types of widgets would be really useful.