I am currently using the Smartphone Radar plugin for presence logic, which is great of couse, but I am wondering if you guys plan on implementing Apple's geofence features of iOS to allow location-based control of Devices or Schedules. Some apps already take advantage of this feature, and it seems pretty reliable. Thanks!

The FindMyIdevices plugin

http://www.perceptiveautomation.com/userforum/viewtopic.php?f=11&t=6960

uses the geolocation functions to tell Insteon all about your ICloud registered devices locations... unfortunately, I found that in my area, my phone appears to take walks up to two streets away while it's sitting in my charging cradle, and currently, while it's actually in my pocket in my office at work, Apple thinks it's across the street in the local shopping mall..., so I'm just settling for knowing whether my wifi sees it to tell when I'm home.

richy240 wrote:I am currently using the Smartphone Radar plugin for presence logic, which is great of couse, but I am wondering if you guys plan on implementing Apple's geofence features of iOS to allow location-based control of Devices or Schedules. Some apps already take advantage of this feature, and it seems pretty reliable. Thanks!

Find My iDevices allows you to set triggers based on how far away Find My iPhone reports your phone is from the origin point of the map... I'll be adding other Centers in the next version...

But this way you can say "If I am within 2 miles of my house" or ".5 miles from my work", etc....

- Benjamin

richy240 wrote:I am currently using the Smartphone Radar plugin for presence logic, which is great of couse, but I am wondering if you guys plan on implementing Apple's geofence features of iOS to allow location-based control of Devices or Schedules. Some apps already take advantage of this feature, and it seems pretty reliable. Thanks!

We haven't started looking at exactly what we're going to implement in the next revision of Indigo Touch - it's still far enough out on our roadmap that at this point we just have an unordered list of features. It is on the list, however.

johnpolasek wrote:The FindMyIdevices plugin

http://www.perceptiveautomation.com/userforum/viewtopic.php?f=11&t=6960

uses the geolocation functions to tell Insteon all about your ICloud registered devices locations... unfortunately, I found that in my area, my phone appears to take walks up to two streets away while it's sitting in my charging cradle, and currently, while it's actually in my pocket in my office at work, Apple thinks it's across the street in the local shopping mall..., so I'm just settling for knowing whether my wifi sees it to tell when I'm home.

Well then even if Indigo Touch supported geofences you might still be in the same boat, as this would probably rely on the same location awareness function.

bschollnick2 wrote:Find My iDevices allows you to set triggers based on how far away Find My iPhone reports your phone is from the origin point of the map... I'll be adding other Centers in the next version...

But this way you can say "If I am within 2 miles of my house" or ".5 miles from my work", etc....

- Benjamin

So before I go installing this, could you at least tell me if the distance trigger is separate from the timed checkins? That is, I could pass through a two-mile radius in no time, and if the check-in is set at 15-minute intervals, I could potentially arrive at my destination prior to an event being triggered (say, my porch light coming on as I approach my house). I agree that the distance could be made greater, and this would ultimately save electricity over Smartphone Radar as this only has home/away states (saving electricity is one of my goals of automation, since I could trigger my porch light, for instance, instead of leaving it on the whole time I am away from home), but I am curious about its accuracy and reliability. Smartphone Radar is EXTREMELY reliable, though not very accurate at all at judging location (except for the aforementioned home/away states of presence, and only then after considering the small 15-20 minute delay in its detection).

I hate to be picky, but I have quite a bit of stuff depending on the Smartphone Radar plugin and I would hate to rip apart my Schedules, Triggers and custom presence logic just to put it back together again a few days later. (Also, should I be asking this in the "proper" FMID thread?)

jay (support) wrote:We haven't started looking at exactly what we're going to implement in the next revision of Indigo Touch - it's still far enough out on our roadmap that at this point we just have an unordered list of features. It is on the list, however.

I could see this being a huge feature, and would have a few advantages over FMID (although FMID looks like a really, really nice plugin): supported functionality by Apple (doesn't depend on an "undocumented API"), doesn't expose my Apple ID password to a third party plugin (seems to be a big shortcoming to some folks, although I am only somewhat concerned), and it seems very reliable and not a timed approach (seems very "real-time" in my experience with other apps; this may prove to be moot if the distance trigger I mentioned above is accurate enough).

Thank you, everyone, for taking the time to reply. I am very impressed with that I've seen thus far and I am very excited to expand my automation system with additional devices and functionality.

I went ahead and installed FMID, and I've set up some distance triggers that send me emails as tests. I'll be evaluating this to replace Smartphone Radar over the next couple weeks.

Thanks again everyone.

richy240 wrote:I went ahead and installed FMID, and I've set up some distance triggers that send me emails as tests. I'll be evaluating this to replace Smartphone Radar over the next couple weeks.

Thanks again everyone.

Please let me know if you have any issues, questions or suggestions regarding FMID.... I am still adding new features, and I really don't get a lot of feedback.

- Ben

richy240 wrote:So before I go installing this, could you at least tell me if the distance trigger is separate from the timed checkins? That is, I could pass through a two-mile radius in no time, and if the check-in is set at 15-minute intervals, I could potentially arrive at my destination prior to an event being triggered (say, my porch light coming on as I approach my house). I agree that the distance could be made greater, and this would ultimately save electricity over Smartphone Radar as this only has home/away states (saving electricity is one of my goals of automation, since I could trigger my porch light, for instance, instead of leaving it on the whole time I am away from home), but I am curious about its accuracy and reliability. Smartphone Radar is EXTREMELY reliable, though not very accurate at all at judging location (except for the aforementioned home/away states of presence, and only then after considering the small 15-20 minute delay in its detection).

The Timed queries update the distance away. So yes, it's possible that you could be home before the system realizes it. But you can use a scheduled event to force an update, let's say every 2 minutes, between 5 pm and 5:15 pm.

Not perfect, but it does allow that flexibility...

- Ben

jay (support) wrote:We haven't started looking at exactly what we're going to implement in the next revision of Indigo Touch - it's still far enough out on our roadmap that at this point we just have an unordered list of features. It is on the list, however.

One feature that I'd really like to see would be RO visibility for the plugin states: I know that they are so ambiguous that it would probably be impossible to allow the user to CHANGE things like a hot tub start time or alarm condition, but a simple echo of the state list you show in the home window (as opposed to making the user anticipate and add a control page item for every state they might want later) would greatly enhance the program's capabilities.

We discussed adding the list of state values like we have in the Mac client but we think it would be of very little use. Quite the opposite in fact - I think it would end up being quite frustrating to see those devices but not be able to control them. Since plugins and graphical control pages are both features of Indigo Pro we feel that the best solution for the moment is to encourage the user to create their own UI.

Eventually, we want to add some ability for a plugin to define a control UI for it's custom devices but that's a rather large undertaking so it's not going to happen in the near to mid term.

bschollnick2 wrote:Please let me know if you have any issues, questions or suggestions regarding FMID.... I am still adding new features, and I really don't get a lot of feedback.

- Ben

Well from what I can tell the plugin works pretty well, although not as well as a real iOS geofence (that's not really your fault though, and more of a limitation of the tools we're given to work with by Apple outside of iOS, which, as you've stated, are unsupported). I do have some questions, concerns and observations though, and I will post them in the proper thread in the User Contributions forum.

jay (support) wrote:We discussed adding the list of state values like we have in the Mac client but we think it would be of very little use. Quite the opposite in fact - I think it would end up being quite frustrating to see those devices but not be able to control them.

Could I ask you to possibly reconsider that a bit? You are clearly correct when thinking only of things like stereo or sprinkler or hot tub CONTROLLER plugins. But there are an increasing number of plugins which create informational only devices that contain large number of rarely needed (making it difficult to justify the effort of creating controls or variables fro them), but occasionally wanted really badly states: "What does the NOAA Plus plugin think the chance of rain will be this weekend?", "How much rain did the RFX plugin rain gage say we got in June?", "What does the Weathersnoop plugin think the heat index is?", "Is my kid's smartphone radar plugin home or away?"... Need I go on? I know that a lot of this info could be gotten from other sources; Weather Channel, ICloud FindMyIPhone, WeatherSnoop web client, etc, or if anticipated, loaded onto a control page, but there's frustration involved if you KNOW it's there in Indigo but you've got to go look it up elsewhere or didn't think of putting it out here and so have to wait till you get within keyboard reach of the client...

johnpolasek wrote:

jay (support) wrote:We discussed adding the list of state values like we have in the Mac client but we think it would be of very little use. Quite the opposite in fact - I think it would end up being quite frustrating to see those devices but not be able to control them.

Could I ask you to possibly reconsider that a bit? You are clearly correct when thinking only of things like stereo or sprinkler or hot tub CONTROLLER plugins. But there are an increasing number of plugins which create informational only devices that contain large number of rarely needed (making it difficult to justify the effort of creating controls or variables fro them), but occasionally wanted really badly states: "What does the NOAA Plus plugin think the chance of rain will be this weekend?", "How much rain did the RFX plugin rain gage say we got in June?", "What does the Weathersnoop plugin think the heat index is?", "Is my kid's smartphone radar plugin home or away?"... Need I go on? I know that a lot of this info could be gotten from other sources; Weather Channel, ICloud FindMyIPhone, WeatherSnoop web client, etc, or if anticipated, loaded onto a control page, but there's frustration involved if you KNOW it's there in Indigo but you've got to go look it up elsewhere or didn't think of putting it out here and so have to wait till you get within keyboard reach of the client...

I concur!

The reason that I am not merging my plugins (eg. Thermostat Enhancement) into the standard Indigo module, is that it will hide all the informational states....

I would suggest having a "line" that has "State Information", and when the user clicks on it, it'll "slide" to a screen that lists the states and the values for them...

It shouldn't be hard....

But state information can be very important and useful information. For example, Weather Conditions! will have the information on the forecasts in the states.....

Either that, or we need some way to bundle up web pages for Indigo so that they can be included in the plugins... And we need the IWS updated for the new communications model. And Indigo touch needs to be able to see / use custom web pages, and plugins...

If I create a plugin, the user needs someway to get that information....

We definitely want to and will eventually provide a mechanism for plugins to show UI (control and/or states) from both Web browsers and Indigo Touch. But that is a big feature, and it isn't one we will get to until the next major rev of Indigo Touch.

We'd prefer to do it right and not hack in something that is just a temporary solution. We have several different high priority features, especially now with the plugin architecture. We appreciate the feedback on what features are important to both customers and 3rd party plugin developers, but understand that our development philosophy is to provide well designed and thought-out solutions, and not to just glob on additional functionality. In the long term, that will make Indigo a better platform for everyone.

Benjamin, we understand very well what the API provides, what we'd like it to provide, and the gap between.

If I create a plugin, the user needs someway to get that information....

The bottom line is this: state information can be accessed. Perhaps not as conveniently as some might wish but it's there and accessible. Holding back useful functionality (like enabling the built-in controls of subclassed devices) because it may hide informational state information, which is already fundamentally hidden in Indigo Touch/IWS seems quite counterproductive to me.

And, just as a reminder - you can create clipping files with control pages in them to distribute to your users if you choose. Again, it's not the perfect, but it's available (no need to whine about the limitations/problems with it - I'm just pointing out something that might help).

Updating Indigo Touch to include state information in some way is something we're going to look at for the next revision. That revision, as I mentioned on another thread, is still a long way out however so plan (or not) accordingly.