Ha!
Actually yes..
I have one of those - EXPENSIVE!!!
Andy
Hey, nothing like preaching to the converted. Oh yes.
1 Like
I try not to think about my support desk costs but they certainly eat into the profits!
@bravenel has a business to run. Honestly others here that help out with code DH or Apps are hobbiests having fun. You clearly don't write groovy apps for ST or Hubitat thinking you are going to make money... some of us "try" to do our best to help out when we can. My coding days are years ago. I've gotten good at hacking DH stuff together to get what I want out of it. However would I 'pay' to say have someone write the DH I really want for my GE motion dimmers? I really just want them to work the way I want them to work. So in this use case, if no one else does it...I do.
Actually maybe I stumbled onto something here. What if developers accepted "donations" for code? Then made available BUT officially supported by Hubitat. Or even if an app or DH could be "custom" requested to be added to hubitat for an additional fee? I'd pay for that DH to be written and integrated into Hubitat. Then others would benefit. In the same vain if someone else paid for something I would benefit. Hubitat would benefit from getting some extra $ beyond the initial sale of a hub. And while I'm sure the cost to write the code would exceed the price paid...there is some subsidy for the code and the whole system gets better. Just spitballing.
2 Likes
I'm going to add, much to the chagrin of others, I'm surprised you DON'T charge support.
1 Like
This is really the issue rather than just the support time involved.
You can't possibly, properly support code written by someone else - Nobody knows the code (or what it's supposed to do) like the author
4 Likes
Agreed. Hence my above ramble that kept going and realizing you'd have to do this directly with Hubitat to make it work.
I think a paid support option where at least the Hubitat team could help Identify that the issue IS a 3rd party app. Then let the user decide what to do after that. I still think the whole App "enable/disable" that has been brought up is a really good first start for support. Cudo's to @Cobra for just DOING IT for his apps. 
1 Like
This was sort of the plan with the ‘disable’ switches.
If a hub is running badly (slow etc) and Cobra Apps is disabled at the container level then at least you know it’s not that.
I would encourage all developers to have some way to disable their apps at the top level.
Happy to explain how I did it (it’s not that difficult really) if anyone needs help.
(Now I just have to copy/paste the code to 40 groovy text files! 
)
Andy
2 Likes
Can you post the 40 lines? I have 2 apps that I wouldn't mind adding this too.
It’s not 40 lines! 
I have 20 apps to do on both parent and child so 40 apps to do
You may need to change your app a little as you need to put all your device subscriptions into a single method.
Then create child and parent methods to unsubscribe and unschedule the app when the parent switch is on and reverse it when the switch is toggled
I really need to write this up but I’ll probably release my new versions of my apps with the code in the next week or so.
Andy
1 Like
The ability to disable custom drivers/apps for locked systems is all good & well, but, pretty useless in situations where connectivity on port 80/8080 is foobar.
The ability to disable custom drivers/apps should be on the web page accessible on port 8081, which always appears to be accessible even when the normal one is in a "locked" state. Along with a reboot button
J
2 Likes
Oops, reading has never been my strong suit...
1 Like
Lol.
Pm sent
Andy
this one feels like it might be the lowest implementation cost and quickest win.
to keep it simple maybe HE could even consider not restoring any schedules or subscriptions for user apps when rebooted using this option from the platform update tool menu.
this would not eliminate issues due to problematic user drivers but that could be a later extension to support suspending them as well on these reboots.
may be even take it a step further and make this reboot to disable all user apps a mandatory first step in the support process that users must follow to get support. that would enable easier self-support for users who need it while shifting some of the support cost for these cases.
nothings free off course. but could be one option to save a bunch of support cost with some dev time.
cheers.
1 Like
We call it technical services over here. Support covers our software, 3rd parties that are official partners and integrated officially (which for anyone thinking that's a good idea costs those 3rd party's 10's of thousands of dollars a year) and then if you want any help on our platform after the officially supported stuff (lets say, write me this custom thing, fix this other custom thing) it's contracted through services. Typically 2-3 hours minimum PM time plus actual time to implement (we provide estimates but we know how those go). If you want us to fix/enhance something our customers built and shared (we have a lot of custom development going on by our customers as well) we can do that for the same rate, but the rate goes up significantly if you want to re-publish the changes for all to have.
This scenario is a nightmare of trying to keep dedicated services people employed or having no development staff available for the actual product depending which way you go..
Oh, and even if you just want help configuring a non-standard thing it's all the same "Services" heading and you pay per hour.
1 Like
