Is the new subscription model actually producing updates?

My quality check is also not very sophisticated either: try if it works, if not fix it .

Karl

Wait, what, that’s not the approved method? Oops.


Sent from my iPhone using Tapatalk Pro

I still believe the key challenge is the number of very good resources working on indigo. Packaging it one way or the other will not address the fact that there are only 2 core - very good ones- developers.

Somehow we -the user community -have to come up with a way to increase the revenue so that indigo can increase the resources.

The plugin store is a good way. But they need 100k a year more revenue to add a full time very good developer.

I would be happy to discuss ways of doing that.

Karl

Sent from my iPhone using Tapatalk

Matt/Jay,

Just a suggestion given that device support seems to be a common complaint. Take 7.2.0 (I have no idea when the next update is planned) but couldn't device be added via an automatic update method or at least separate it from releases? That would put new devices as being supported quicker than the current model.

I also think that the random update of new devices is Indigo's achilles heal.
I appreciate that just 2 developers put a strain on what can and can't get done and they need to pay the bills so perhaps an extra person is not a viable option even with the new subscription model.
It is a Catch 22, increase the subs and get a 3rd person but loss more customers who don't see why they should pay extra and find a "cheaper" option. (tried that and their really is no better HA as far as I am concerned).
I would love to see a monthly device definition update (large or small) especially for the more common manufacturers but everything takes time and somethings have to take precedence over others but when a device is still not included after several requests and months go by I am sure that some do go off and look for alternatives which leads to reduced revenue.

[matt (support)]

The goal is to have feature releases (7.3, 7.4, etc.) much more frequently so this is less of an issue. Auto updating with new device profiles is definitely something we have thought about (and continue to consider), but the devil is in the details of course: it will take non-trivial time to engineer auto-update, often times there are code changes needed for new profiles, QA permutations become more complex (Indigo Server version + Z-Wave device profile versions), etc. We also hope to open up more dynamic/generic Z-Wave support so even if there aren't device profiles a new module will still be usable. A step in that direction was the raw Z-Wave triggers introduced in Indigo 7, as well as the lower level APIs that some plugins are now taking advantage of to extend Indigo's Z-Wave support.

Don't forget about the iOS app too.

Indigo Touch v2 was released 3 years ago, and the last bug fix update was a year ago. There are tons of features that the mobile app could use, but even some bug fixes like it not using the entire iPhone X screen size which has been out for over a year is missing.

Don't forget about the iOS app too.

Indigo Touch v2 was released 3 years ago, and the last bug fix update was a year ago. There are tons of features that the mobile app could use, but even some bug fixes like it not using the entire iPhone X screen size which has been out for over a year is missing.

Personally I’d rather they discontinued the indigo touch app and got a third party to take over developing it.. it’d give them more time to concentrate on the core product and if it were a port of RogueProeliator’s epic Domopad Android app it’d be much more functional too. But perhaps I’m over simplifying matters.

Personally I’d rather they discontinued the indigo touch app and got a third party to take over developing it.. it’d give them more time to concentrate on the core product and if it were a port of RogueProeliator’s epic Domopad Android app it’d be much more functional too. But perhaps I’m over simplifying matters.

Yea, I'd be for having an open well documented rest api and an oauth scheme to access reflector or local server directly along with SSE for certain situations instead of constant polls that anyone could build a mobile client on top of.

Indeed. Ideally though I’d rather that was more as an indigo client rather than control app though.. almost all my manual control is done with HomeKit these days. But I’d freakin’ love a client app that could handle most if not all of the functionality of the Mac app.. I’d pay good money for that. I’m not joking when I say I’d be willing to pay up to £100 for it

Hey, if I could see full device details, and turn off and off schedules/actions/triggers etc I'd be happy. The ability to edit those and I'd happily (let durosity) pay a lot of money for that.

I'm also using Homekit for 95% of the iOS indigo control. I'd love to have cool control pages but know that they wouldn't get used even if I could find the time to build them.


Sent from my iPhone using Tapatalk

[jay (support)]

An update to IT is pretty high on the priority list, just after we release 7.3 (very soon now). And OAuth support (to enable an Alexa Skill and a Google Home integration, etc) is also very high on the list.

Please don't ditch the iOS app. I use it all the time and prefer this to talking to Siri ( at this time at least). Talking to Sirit is great, but having a quick and silent interface to Indigo is crucial to me.

[jay (support)]

Please don't ditch the iOS app.

LOL - not gonna happen.