I give up!

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?" :upside_down_face:

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 :crazy_face:


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.

RAFLMAO @bravenel

Thanks Bruce! this made my day!
(Or night as it’s almost 1am here :slight_smile:)



Hey Andy .. how about making the ST hub link bi-directional ? :wink:

I’m sorry, I don’t take feature requests anymore.
“Just wait a while and....”



1 Like

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) :stuck_out_tongue:

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.

1 Like

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.

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) :slight_smile:


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


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.

.. also in defence of Hubitat There is an aspect of my suggestion to use ST as a peripheral that doesn’t sit well ...

Suggesting it’s useful for the cloud integrations that ST can provide (if HE doesn’t) in a way negates the local model that HE performs so well. It’s likely that control of ST devices requires cloud access, at least for ST to complete and so you start to introduce those dependencies on the ST cloud again. True HE can have similar issues with say IFTTT but becoming decoupled from this for your home automation implementation is a great objective.

I think it would be a nice thing to offer, and if your app was open source even a nice thing for someone to pick up and enhance.

However I do take your point about appealing to the more technical users who can as you say work around the problem themselves.

A nice MQTT integration would be useful too as that again is messy and high maintenance currently.

Absolutely it can only be done through the ST cloud. And, as long as one is integrated with ST that brings their cloud into the picture. There are also many good integrations that use the cloud, and we aren't averse to supporting them as time goes on. But, people should have their eyes wide open about the implications of it. Alexa and Google Home are two good examples.

We all use the cloud for many things, for hub registration, for updates, for Dashboards, etc. etc. The main thing about local is to get your primary core automations to run locally, and to keep on running irrespective of the cloud. You may not know what's happening at your house if the internet goes down when you're away, but the hub should just keep on doing its thing. And it does.


Agree 101% on this .. it’s essential that you are in control of your home for functionality and security purposes without the Internet being required.... and that is a fundamental design failing of many other systems.

I even try and go one stage further and ensure all key features can operate even if my controller or network fail. Lighting, heating, security, audio visual etc. Islands of functionality enhanced by smart integration.

When your away and your family can’t turn a light on by the switch or the TV remote doesn’t work then the whole smart home experience is instantly alienated with the family .. we’ve all been there I’m sure...

1 Like

Well...maybe you could expand the app to tackle the reverse, turning switches on or off based on mode (i.e., allow bidirectional "snycing" of the switch states, useful if you're, say, using another platform and syncing mode via virtual swithces...and also because I'm not sure what would happen if one mode switch is turned on, then at some point a different mode is selected via the regular/non-switch method, and the previous mode switch is turned on again).

If this is already handled by the new Mode Manager and/or yours, then nevermind. (And if it really isn't but is a good idea, I'll probably be able to say "nevermind" in a firmware update or two anyway.:slight_smile: )

Can't you just do this with RM?

Doesn't do months or specific days. Yet. Uh oh, now I've gone and done it...
Don't take your toys and go home Andy. We still need you! :smile::wink:

1 Like

I could, but if there's a way to do it without creating a rule for each mode/switch, I haven't figured it out. I'm a former webCoRE junkie trying to learn RM and...I'm not there yet. :joy:

EDIT: I just realized the lighting apps can also do this (turn on/off switches with mode changes). I used Hubitat Simple Lighting and still had to create one child app for each mode, but it was probably less clicking than anything I know how to do in RM.