Question on Future Operation if App is Discontinued

[GregBury]

I am potentially about to pull the trigger on my selection of Agave vs. Mobilinc.  The cost of Agave is certainly not a kings ransom, but I figured I would ask if someone knows what would happen with the functionality if the app becomes no longer supported.  I am assuming that the "Basic Limited" package would continue to function.  I am not clear about the access to the ISY remotely would still work if the "Extended" package was purchased.  Since it does not include ISY Portal Access, I am not clear if these is some type of DNS or a cloud component that is controlled by Agave and would cease to function if the app was unsupported.  

The remote access may continue to work if the ISY Portal Access is purchased possibly as this looks to be a way to directly link to the portal rather than needing a direct way to get to the ISY.  Currently I am somewhat confused about any advantage that the ISY Portal Access Extension has over the "Extended" package operation other than the stated notifications function.   

I ask this because it does not look like there has been much development or activity here.  Although not too much money, there is some time setting it up, making it right.  

Thanks.

[Geddy]

Best to tag the developer (@James Peterson) in the post to get their attention. James seems to reply quickly on here, and notice the app on iOS was updated 2 months ago (showing v1.5.110 on the app store). But assume James would be best able to address issues you bring up.

 

[James Peterson]

1 hour ago, GregBury said:

I am potentially pull the trigger on my selection of Agave vs. Mobilinc.  The cost of Agave is certainly not a kings ransom, but I figured I would ask if someone knows what would happen with the functionality if the app becomes no longer supported.  I am assuming that the "Basic Limited" package would continue to function.  I am not clear about the access to the ISY remotely would still work if the "Extended" package was purchased.  Since it does not include ISY Portal Access, I am not clear if these is some type of DNS or a cloud component that is controlled by Agave and would cease to function if the app was unsupported.  

The remote access may continue to work if the ISY Portal Access is purchased possibly as this looks to be a way to directly link to the portal rather than needing a direct way to get to the ISY.  Currently I am somewhat confused about any advantage that the ISY Portal Access Extension has over the "Extended" package operation other than the stated notifications function.   

I ask this because it does not look like there has been much development or activity here.  Although not too much money, there is some time setting it up, making it right.  

Thanks.

To put it simply.  "IF" I were to give up development on Agave it should remain working indefinitely as long as the app stores support it.  The only service that may suffer would be the family manager as that is tied to a remote server and requires uptime.  I would leave it up and or give over maintenance to a 3rd party.  I would most likely give over Agave to a third party as well.  As it stands..  I am working on Agave in my spare time, but right now that is very limited.  I take care of bugs as they come on and as I can figure them out.  New features are on hold until a path for the NS platform can be utilized.  At which time I will continue 2.0 dev.  

I will answer other questions, but I just wanted to make it as clear as possible.  

[LFMc]

3 hours ago, GregBury said:

I am potentially pull the trigger on my selection of Agave vs. Mobilinc.

What was the answer to this from Mobilinc? 

[lilyoyo1]

5 minutes ago, LFMc said:

What was the answer to this from Mobilinc? 

I suspect mobilinc would be the same. Anything connected to mobilinc's servers would be affected. Anything locally managed would continue until UDI's firmware advanced to where mobilinc no longer worked

[Goose66]

1 hour ago, James Peterson said:

New features are on hold until a path for the NS platform can be utilized.  At which time I will continue 2.0 dev.

Is this an ongoing discussion with Michel Kohamin with a predictable end date or more of a wait and see thing? 

[LFMc]

7 minutes ago, lilyoyo1 said:

I suspect mobilinc would be the same

You missed the point. James responded in about 3 hours. I am curious as to how long it is before the originator of this thread @GregBurygets an answer from Mobilinc (and if they do respond, what is the answer?). 

[James Peterson]

32 minutes ago, Goose66 said:

Is this an ongoing discussion with Michel Kohamin with a predictable end date or more of a wait and see thing? 

I think MK is satisfied with where the NS system is going.  As for UI developers such as myself (I can not speak for Wes),  Agave (in its current form) needs to have an approximate idea of what type of device it is looking at to display the correct interface.  For the ISY, it does not matter what type of device it is since it simply display the controls for the device in an orderly cell format no matter what it is.  This works great if you are not worried about the UI.  Agave is not that way.  Until there is cooperation in the NS developer arena to use the node hints I can not say when NS will be supported.  

 

That being said.  I am open to ideas.  I have been wrong before. 

[apostolakisl]

3 minutes ago, James Peterson said:

I think MK is satisfied with where the NS system is going.  As for UI developers such as myself (I can not speak for Wes),  Agave (in its current form) needs to have an approximate idea of what type of device it is looking at to display the correct interface.  For the ISY, it does not matter what type of device it is since it simply display the controls for the device in an orderly cell format no matter what it is.  This works great if you are not worried about the UI.  Agave is not that way.  Until there is cooperation in the NS developer arena to use the node hints I can not say when NS will be supported.  

 

That being said.  I am open to ideas.  I have been wrong before. 

Would it be possible to have a node configuration page on Agave.  All the various pieces of data would list in order in Agave on this configuration page for any given node.  You would have a check box next to each one and checking the box would cause that piece of data to display in the Agave UI for that node.  And there would be a label option where you can label them on that config page.

[lilyoyo1]

1 hour ago, LFMc said:

You missed the point. James responded in about 3 hours. I am curious as to how long it is before the originator of this thread @GregBurygets an answer from Mobilinc (and if they do respond, what is the answer?). 

I didnt miss any point. He posted on Agave's thread without anything to alert Wes (mobilinc) that they were even mentioned. You responded on the same thread as well. Being that this is an open forum, answers can come from anyone. If you specifically wanted information from Mobilinc, you should have tagged them or posted on that sub forum

How can he respond to something he doesnt know anything about? Besides, Mobilinc has been around since the beginning. I am less worried about that going somewhere vs. any other app

[larryllix]

1 hour ago, LFMc said:

You missed the point. James responded in about 3 hours. I am curious as to how long it is before the originator of this thread @GregBurygets an answer from Mobilinc (and if they do respond, what is the answer?). 

When did anybody notify mobilinc? 

[simplextech]

2 hours ago, James Peterson said:

I think MK is satisfied with where the NS system is going.  As for UI developers such as myself (I can not speak for Wes),  Agave (in its current form) needs to have an approximate idea of what type of device it is looking at to display the correct interface.  For the ISY, it does not matter what type of device it is since it simply display the controls for the device in an orderly cell format no matter what it is.  This works great if you are not worried about the UI.  Agave is not that way.  Until there is cooperation in the NS developer arena to use the node hints I can not say when NS will be supported.  

 

That being said.  I am open to ideas.  I have been wrong before. 

Here's the hints information so far:

https://github.com/UniversalDevicesInc/hints

None of the app developers are using any of it to date.  Some of us follow it I also don't have Agave so I can't test anything.  Without the mobile app developers being on board and saying yes you'll support hints then it's a chicken and egg problem.  Hints were starting to be developed and never utilized...... so I think motivation and interest with elsewhere.

[GregBury]

Well I suppose I need to stand corrected with respect to the activity here.  Given what I had seen I did not expect such a quick response from as many users. 

Thank you for the clarification (@James Peterson).  I have a basic working knowledge of data link, transport, and transport network layers, but I will admit to only scratching the surface.  I was not clear if the hub could be accessed inside my LAN from an outside location without another working service in the cloud.  Thanks again.

Also to be clear, I have not asked this same question to those at Mobilinc or users at this time.  My Agave trial ended yesterday and I am attempting to understand all capabilities of Agave currently.  I have a few days left on my Mobilinc X trial and will do the same when that ends.  I have many more questions there as the trial is for the subscription, but I would only be interested in the "Direct" option.  That discussion is beyond the scope here, but I will try to report back information on the answers if there is interest.  

I am leaning towards Agave and very much hope that this product continues to be supported by James and the community.  

[mwester]

2 hours ago, simplextech said:

Here's the hints information so far:

https://github.com/UniversalDevicesInc/hints

None of the app developers are using any of it to date.  Some of us follow it I also don't have Agave so I can't test anything.  Without the mobile app developers being on board and saying yes you'll support hints then it's a chicken and egg problem.  Hints were starting to be developed and never utilized...... so I think motivation and interest with elsewhere.

<opinion worth="very little">  Part of the problem, and a reason I'm not all that interested in node server development any more, is that it's complete chaos.  There's a very base low-level standard (the node server model), but nothing above that.  It's kind of like the developers of internet protocols had stopped after defining ICMP and UDP layers, and left it at that, claiming that anything more would stifle creativity... in fact, what we need are some boundaries within which to be creative, and after one gets beyond the most basic node servers, well there are no standards or boundaries.  Chaos rules, and when chaos is dominant, developers (such as those working on the UIs) look elsewhere to invest their creativity and talents.

So, why not do as the internet protocols do (so to speak) -- hints are all well and good, but perhaps if a group of interested parties were to hammer out a set of specs for a layer above the base node server, we could make progress.  Perhaps starting with defining the standard base set of fields, units of measure, and the hints for a Thermostat?  Another group might knock out a minimal set of things that all weather node servers need to provide.  Perhaps all nodes could benefit with a standard that defines consistent behavior for common elements for nodes -- such as a common name and common update frequency for a heartbeat, or common behavior for an "online" indicator.

Once we have a standard set of definitions -- which would include the various node server XML file snippets as reference documents, along with perhaps a reference python library, well, at that point, it becomes a lot easier to build a node server that's actually going to be useful and even interchangeable -- wouldn't it be great, for example, if you could toss your junk hobby weatherstation and replace it with a Davis unit that you got for Christmas *without* having to re-write every program that uses weather information?

Relative to hints, and mobile apps - this would make writing a mobile app not only a lot easier, it would make supporting the mobile app a lot more practical.

</opinion>

 

 

[larryllix]

1 hour ago, mwester said:

<opinion worth="very little">  Part of the problem, and a reason I'm not all that interested in node server development any more, is that it's complete chaos.  There's a very base low-level standard (the node server model), but nothing above that.  It's kind of like the developers of internet protocols had stopped after defining ICMP and UDP layers, and left it at that, claiming that anything more would stifle creativity... in fact, what we need are some boundaries within which to be creative, and after one gets beyond the most basic node servers, well there are no standards or boundaries.  Chaos rules, and when chaos is dominant, developers (such as those working on the UIs) look elsewhere to invest their creativity and talents.

So, why not do as the internet protocols do (so to speak) -- hints are all well and good, but perhaps if a group of interested parties were to hammer out a set of specs for a layer above the base node server, we could make progress.  Perhaps starting with defining the standard base set of fields, units of measure, and the hints for a Thermostat?  Another group might knock out a minimal set of things that all weather node servers need to provide.  Perhaps all nodes could benefit with a standard that defines consistent behavior for common elements for nodes -- such as a common name and common update frequency for a heartbeat, or common behavior for an "online" indicator.

Once we have a standard set of definitions -- which would include the various node server XML file snippets as reference documents, along with perhaps a reference python library, well, at that point, it becomes a lot easier to build a node server that's actually going to be useful and even interchangeable -- wouldn't it be great, for example, if you could toss your junk hobby weatherstation and replace it with a Davis unit that you got for Christmas *without* having to re-write every program that uses weather information?

Relative to hints, and mobile apps - this would make writing a mobile app not only a lot easier, it would make supporting the mobile app a lot more practical.

</opinion>

 

 

Thinking of the newbie end also, people asking for help, the first things is to ask, "exactly what model do you have".
A few times I have tried to help Zwave users with answers that become complete nonsense when not Insteon, or Insteon model number x. I doubt some of it can be consistent completely though.

eg. ecobee will only allow a three minute poll period max. New users are appalled by how slow that is and would want a faster polling frequency. This is likely possible on other brands but is never going to happen on ecobee stats. After all the initial dev excitement is over three minutes is not a big deal for a temperature to change anyway.

[simplextech]

1 hour ago, mwester said:

So, why not do as the internet protocols do (so to speak) -- hints are all well and good, but perhaps if a group of interested parties were to hammer out a set of specs for a layer above the base node server, we could make progress.  Perhaps starting with defining the standard base set of fields, units of measure, and the hints for a Thermostat?  Another group might knock out a minimal set of things that all weather node servers need to provide.  Perhaps all nodes could benefit with a standard that defines consistent behavior for common elements for nodes -- such as a common name and common update frequency for a heartbeat, or common behavior for an "online" indicator.

<opinion worth="not much"> <rambling="mostly"> I agree there needs to be some baseline that all nodeservers should follow or be rejected.  The example I saw before was for a light bulb that would only turn on.  In that instance there's the ADR guidelines that should be followed.  This doesn't stifle creativity but it does ensure minimal functionality to meet minimal expectations.  A serious problem currently is a lacking of documentation, howto information, basic guides and definitions of guidelines and back to hints.  There was a good start made at hints and then it kinda faded away... some of the hints make sensor and are very generic and others are very specific towards a specific nodeserver implementation which probably led to arguments and confusion and chaos resulting in a half done effort. 

Third parties especially UI development is hard and time consuming which equal a lot of money.  If money can't be recouped then time(money) won't be spent on adding features/functionality that will possible break on the next release or at the whim of a nodeserver developer who isn't following any standards because there aren't any.  This circles around to a nodeserver audit/review of qualifications and a QC process before turning things lose into the wild.  Again this whole structure and process takes time(money) and when nodeservers are free there's no money to invest that time. 

So yeah currently nodeserver and third party development is stifled due to a lack of a baseline standard being in place.  Has this prevented or stopped nodeserver development?  No, but it's resulted in a lot of wild west free for all nodeservers that some reflect information one way, others do it another way, there's no code style guide being followed so reading through code is often a challenge itself.  Documentation on what methods are available can something be done what can't be done a common problem for all nodeserver development is the node id length and it has to be all lower case. 

In time I think a lot of this is going to get resolved, worked out but it's going to be a bumpy ride and then it's been what... nearly 5 years in the making and I'm brand new to all of this with the ISY and yet the same problems exist now as they did years ago so maybe it's going to be a really long ride.... are we there yet? are we there yet? are we there yet? or maybe it's time to step back and determine what the end goal is and design a structure that meets that?

[LFMc]

14 hours ago, GregBury said:

Also to be clear, I have not asked this same question to those at Mobilinc or users at this time.  My Agave trial ended yesterday and I am attempting to understand all capabilities of Agave currently.  I have a few days left on my Mobilinc X trial and will do the same when that ends. 

Thanks Greg. Always good to see a full head-to-head comparison of products and the support that goes with them.  Also your major point is well taken, the dependence on the "cloud". Abandoned-ware is one thing, but products that cease to work is another. These are tough questions and most vendors avoid discussing them.  I look forward to what you find out from the other vendor. 

[Goose66]

21 hours ago, James Peterson said:

Until there is cooperation in the NS developer arena to use the node hints I can not say when NS will be supported.  

That being said.  I am open to ideas.  I have been wrong before. 

So Michel's approach (and I can't say I disagree) is that for the ISY he wants to keep it as open and flexible as possible on both ends and not become the arbiter of standards. This is my preferred approach - everybody should stay in their lane where possible. That said, a defacto standard may emerge at some point, but I don't think hints will be it. It was a step in the right direction but there has been no consensus on how it should be used.

My idea that I mentioned in another thread is that you (Agave) could come up with a framework that allows the node developers to describe the user interface appropriate for their nodes. Similar to the nodedef.xml document that describes the nodes to the ISY, the UI descriptor could define a small, lean (e.g. on/off) interface for tiled and/or list views, and a more robust interface for full screen views. It could even reserve certain driver values and commands for an advanced generic list view, so three tiers. You would define what's possible for the UI at each tier, and that could grow and expand. Just as the ISY does, you would maintain and publish the descriptors for the device types supported natively by the ISY, and nodeserver developers could specify one of those and conform to it or could roll their own for each node type. For example, for a ceiling fan node, the nodeserver developer may specify in the UI descriptor to use the native ceiling fan UI in Agave, and make sure the drivers and commands of the node conform to that, but for a fireplace they may define their own UI. If the framework could eventually have a file of graphic icons and other resources that could be specified in the UI descriptors, that would be even better.

If it takes off, not only does Agave get positioned as the most robust UI for the ISY, but other UI developers may utilize the same format and it becomes the defacto standard. Maybe something like this could work its way into the Alexa and Google Home integrations as well. The worry is, of course, that UDI sees it happening and then decides to roll out their own standard and take it a different way. But from what I have heard from Michel on the subject to date, I wouldn't be too worried about that happening.

[Michel Kohanim]

@mwester,

As I have mentioned many times before, you cannot compare UDP/ICP/HTTP/TLS, all of which have very well defined use cases, with Home Automation/Things. And, as I am sure you are aware, we now have 100 + 1 standards dealing with the domain of things.

The problem is that we feel that we have liberated ourselves and, therefore, any mention of constraints, limitations, baselines, etc. makes us feel imprisoned yet again. It's kinda like a visceral reaction so I do apologize.

To this end, I don't mind at all having a group come up with a Conformance Layer (pretty much what you and @Goose66 describe with a minimum set of properties, UOMs, commands, etc. for things). Hints can also be used.

What I cannot agree to is to coming up with device types/categorizations just so that a UI/app can represent things properly. Again, apologies, it's just a visceral reaction.

With kind regards,
Michel

 

[Power Up]

Greg,  What did you finally choose?  I was facing the same choice feb 2020, I selected Agave and purchase over $100 in addons and still not completely sure it will do what I want.

So now I am looking into Mobilinc x. @James Peterson

I have 2 buildings on separate electric meters, and serviced by the same Wifi network.  I have  30 Insteon Din rails in building 1 and 4 insteon dimmers in building 2.

I purchased 2 ISY 994 units and set each up in with my laptop, portal, and Agave.

HOW do i gain access to both isys ONLINE?  can i write scenes to access both ISY units ? Can i write scenses from Agave or do i have to go to the facility and program with my laptop each time.       ISY newbie, sorry if this is and old Question or answered on here already as i could not find anything.

thanks

[DennisC]

Programing from Agave is not possible. However, you can access multiple ISY's from Agave and the admin console by adding the second address in start.jnlp if it's not automatically found . In Agave you just add a second profile.

[Power Up]

So I add a another profile, but will this allow a scene to turn on items in both Isy units?

[DennisC]

If you are trying to control something on both ISY's at the same time you will need to try and accomplish this with a Network Resource.

[GregBury]

On 2/15/2020 at 10:34 AM, Power Up said:

Greg,  What did you finally choose?  I was facing the same choice feb 2020, I selected Agave and purchase over $100 in addons and still not completely sure it will do what I want.

So now I am looking into Mobilinc x. @James Peterson

I have 2 buildings on separate electric meters, and serviced by the same Wifi network.  I have  30 Insteon Din rails in building 1 and 4 insteon dimmers in building 2.

I purchased 2 ISY 994 units and set each up in with my laptop, portal, and Agave.

HOW do i gain access to both isys ONLINE?  can i write scenes to access both ISY units ? Can i write scenses from Agave or do i have to go to the facility and program with my laptop each time.       ISY newbie, sorry if this is and old Question or answered on here already as i could not find anything.

thanks

@Power Up,

I chose Agave mostly due to the requirement to remove my UDI portal with Mobilinc even for testing. 

Frankly, the trial periods for both these products do not accurately depict what you will get.  In the case of Mobilinc, this is because there is no trial of the Direct option.  You are using the subscription model when in trial.  In the case of Agave, this is because you have access to all packages, but cannot tell what is part of the package.  For example, the Agave Extended Access promises access outside of your home network.  This is one of the reasons why I bought the Extended.  What is not clear at all is that you need to set up a DNS with a third party and open a port.  This is subject to more cost and more issues.  The way that it is presented is bordering on false advertising.  Really, the ISY portal option is required.

I feel your pain on purchasing all the Agave packages.  It is one thing to have a modular approach.  It is another to take typical program functionality used by most and divide into many pieces in order to make the cost seem low.  For example:

The Extended option does not seem to do much, but leads one to believe it is easy to set remote access by purchasing this package.

Thermostats are extra.  I knew this up-front, but it costs almost as much as the program itself?  The updates to thermostat settings are slow.

Programs and variables are separate?  Why not charge extra for scenes too?

Only one user allowed and no Google family option?  Yes, you can put another account on a phone, but leads to syncing issues.  If the family manager features are not needed, this seems like a money grab.

I do feel nickel and dimed here.  I would not mind as much if the program was a bit more polished and felt finished.  As it is, there are many things I preferred with my old Insteon app.  That is saying something since that was clunky in it's own right.  At least it was free and did not require any subscription.

[GregBury]

Reading my post from last night again this morning, I see that this came accoss as fairly negative.  Although all of this is true, there are certainly positive aspects of Agave and it will be the program I use since these positives outweigh negatives.  

I will give a more balanced analysis in the future from my viewpoint and follow-up on the questions concerning Mobilinc response speed to my questions.