Continuing the discussion from Hub Update 1.1.6:
I don't know why I bother releasing apps any more..
So... bye bye āModes Plusā
Bye bye āScheduled Switch ā
Ok... should I be flattered that you guys are copying me, or, more likely, just give up and wait for you to do everything? 
I think Iāll just go back to using the apps I write and not bother to release anything...
Andy
It would be flattery if true. 
I think you should keep up publishing good apps, that's my opinion!
"copying is the most sincere form of flattery"
beside that, without you suggestion maybe those things would not have happened.
and in the meanwhile some advanced users took benefit from your work
Maybe a public "roadmap" of things expected in the upcoming release would help avoid duplication. I think most people would appreciate knowing what's being worked on to either not try it themselves or not contact support about it. Some people will complain if something ends up not being included but you can avoid that too much by only publishing the very next release, not 2 or 3 down the road. Just a thought.
To continue what @dwery was saying, some of us novices benefit from your apps too @Cobra. HE published apps are a mystery but yours can be pulled down and studied. How else are people supposed to learn, except from the masters. 
Now that really IS flattery (sadly untrue though!)
Actually... now that Iāve thought about it...
This has given me a new response to feature requests...
ā Just wait a while and it will be in a native HE app!ā
Andy
Ryan, whilst I agree it would be nice, I understand why this is not done.
Managing peopleās expectations is often difficult - Even if a statement is caveted with āit might not happenā some people will still regard this as a firm promis and express disappointment if something doesnāt happen.
My original post was, of course, intended to be ātongue - in - cheekā
Just my rather warped ābritishā humour.
Andy
Just think about all the free time you'll have to make up some more great apps! 
Maybe from where you're sitting but DEFINITELY not from where I'm sitting. I know more than the average Joe and folks like you make me realize how much there is to know and how little of it I actually do.
Oh, I got it. I'm sure you did exactly what I would have done....threw your hands up, swore a few times, wanted to throw your computer out a window for a minute or two....I get it.
And yeah...I know....but I figure with the community being small at the moment and so much development happening so quickly, this is bound to happen a lot more. But yes, managing people's expectations is like herding cats...it doesn't accomplish much but you get scratched and bitten a lot in the process. 
Chuck won a bet today by correctly predicting that the very first post in response to the announcement of 1.1.6 would be "what happened to Lock Code Manager?". That in turn prompted Mike to give a detailed explanation of why LCM didn't make it into the release.
My first reaction to this post was "what roadmap?" 
The truth is that we are working on many things, none of which can be discussed publicly yet, and none of which if public would help @Cobra know what not to work on.
Hey @Cobra, maybe you should have a public roadmap --> give us some great ideas for the next release 
Aside from the obvious frustration this causes developers what I still find very concerning is that the Hubitat released versions become closed source and not available to either learn from or adapt.
I can see an increasingly closed hub materialising in many aspects.
Hey Andy .. how about making the ST hub link bi-directional ? 
Iām sorry, I donāt take feature requests anymore.
āJust wait a while and....ā
Andy
It's not "increasingly closed", it's just a closed source product. No change there. But, in the meantime, we have opened up more and more avenues for developers to do great things. Two recent examples being Maker API and Endpoint Triggers for RM and HTTP Get action for RM.
@krlaframboise already did that with Other Hub: [RELEASE] Other Hub SmartThings Integration 2.0
LMAO....now that's thinking outside the box. It reminds me of the French ruler who, upon seeing his subjects running through the streets cried out, "I must find out where my people are going, so that I can lead them." (and yes, I realize you were joking)
I'm sure things are moving very quickly and I have no idea what development model you guys are using so I won't presume to tell you how to do your jobs. Like I said, just a thought.
Correct me if I'm wrong but I believe Other Hub is bi-directional for HE devices controlled by ST but I don't believe it is for ST devices to be controlled in HE. If it is truly bi-directional, I'd love to hear how you set that up.
OtherHub still requires you to link via virtual devices. I canāt for example control a device in ST from Hubitat directly. For example use one ofthe ST cloud <> cloud integrations from Hubitat for control .. rather than just status reporting.
Itās a real hindrance for people migrating to Hubitat when an equivalent app/driver is not availabl. Take Harmony which may be such an example as they currently dont endorse new integrations.
Kevin,
On ST I still use āone2manyā to do a lot of my switching and controlling things like harmony routines.
(Controlled by the virtual switch from HE)
(Probably another HE app rendered obsolete soon - one to many) 
Andy
I donāt want to hijack your thread Andy and I too use lots of workarounds, particularly MQTT. These link mechanisms are required because there are cloud<>cloud integrations architected by ST that can never be ported to HE.
Hubitat should support using ST as a āperipheralā in this respect to allow HE users to use their hub as their main controller for scheduling, logic and control/dashboard. Controlling these devices from RM etc. Implementing the link one way is just leverage to try and force people away from ST I feel. For more capable users yes...itās doable but messy. For aspiring new users wanting to migrate Hubitat could (should) make it so much easier.
You havenāt!
This thread was designed to provide some humour but also to provoke discussion.
I agree, for new users, migration can be a difficult thing, but in defence of HE, I would ask what does anyone else do to help move from a rival platform?
Having said that.. I like the idea of using ST as a peripheral
I didnāt do as much developement in ST as I have done for HE so Iām not sure what āconnectionsā can be made to control ST devices from HE
Andy
Ah, we had no motive like this. When we first got the hub working, I needed a way to send events from ST to Hubitat because we lacked drivers for several devices I needed. Such a thing materialized, and I used it for a few months until we had all of the drivers and I could cut the cord. That code was already done, and we realized that others might find it useful, so we dusted it off, added some more capabilities to it, and published it.
Doing a full two-way integration with ST just hasn't been high on our list, and we don't have unlimited resources. The people most likely to use such a thing are the ones (we think) who are also most likely to not absolutely need it, because they have higher levels of skills. Could be wrong about that. But we certainly realize and can see that doing a migration is not easy, and we have all done it ourselves. There is a natural tendency to look at our own experiences as at least part of a guide to what works and what is really needed. It's not a perfect world.
Download the Hubitat app
