I completely disagree with this comment. Even with the major advances I have seen over my year with HE, I would still not call this a consumer platform. Your calling a hub that allows a user to create a program that could completely crash the entire system, designed for consumers.
I honestly don't feel the loss of time was over exaggerated. It is difficult to know how many people might have gotten more involved that decided not to. I find it extremely annoying to have to search community member posts to find details similar to what this thread contains. It just adds yet another bookmark for programming in HE, and you have to read the whole thread just in case someone posts something later with an improvement.
@MFornander, I'm not sure what devices or functionality you are looking to add to HE. There is a long list of supported devices and a lot of community members have created apps for tasks not handled by the factory install. However, as devices are created and this industry grows, helping new users get up to speed faster with better documentation would be a great strategy to combat the increasing competition. Especially now that the larger companies are looking at local automation too.
It may seem like splitting hairs, but I would argue there’s actually a big difference between “not ready for primetime” as a consumer platform that happens to allow for an individual development environment (the product of which can even be shared with others), and “developer platform.”
I believe Andy has stated pretty accurately what hubitat staff have made clear re: the platform’s overall priorities.
I am not a developer so I say the following with the utmost respect to those who give their time freely to other community members in order to make this a very cool place to be for DIYers interested in home automation.
Even though devs are willing to donate their time, hubitat as a company and platform may have perfectly valid reasons for not prioritizing or even rejecting those offers.
I'll also just throw out there that the wiki pages are editable/commentable by end users.
The fact that no budding developer took the time to update the docs either, as they we're learning "the hard way", reinforces Andy's comment that the learning curve isn't that steep.
Don't like the docs? Get to writing and submit updates. (Assuming you like working for free for a commercial hub/company.... ).
Is there a middle ground here where the Hubitat team turns the documentation into a editable surface by this community, or heck even on something like Github where we do pull requests for helping to keep it up to date and help document things like this that we all run into?
Hmm, yeah, that seems like a pretty high bar.
Create a new account, request edit permission, etc.
If someone sees an issue, it's so much easier to just suggest specific edits to the owners, like Gitlab, Matter most and others do. https://www.gitbook.com/ is a good example of this.
Invalid argument. You're telling me that cars aren't a consumer product? You can kill yourself and others just by operating a car. There are other reasons HE is not perfectly geared towards consumers but being able to write apps is not one of them. Every good product has an API or customization options.
What's the difference in between searching Discourse and searching through documentation?
Any suggestions for the issues I am seeing trying to get my Andersen Verliock translator and sensors moved over from Wink using a driver for it from ST? See discussion here - links to ST drivers are a few posts up (I'm definitely in over my head in doing a more complicated port from ST code )
We changed that awhile ago, sorry that post did not get updated. All you have to do is sign up for an account on docs.hubitat.com and start editing. There is still an approval process so your edits do not show up publicly immediately
What should I do with these commands from a SmartThings SmartApp? Not sure how to port it.
app?.deleteSetting("$name")
Giving this error in the logs:
groovy.lang.MissingMethodException: No signature of method: **************deleteSetting() is applicable for argument types: (org.codehaus.groovy.runtime.GStringImpl) values: [8a0fd8ce-6c50-4572-8da5-68d2204b7e2b_zones] on line 184 (deleteSetting)
And
revokeAccessToken()
gives a similar error - no signature of method
And
addRemoveDevices Exception: groovy.lang.MissingPropertyException: No such property: completedSetup for class: com.hubitat.app.ChildDeviceWrapper
I don't see anything in the hubitat developer documentation...
And the last one you didn't provide the code in question so it's not really something I can answer, though I suspect you need to look at the first post in this thread which has the syntax for addChildDevice which is not the same as SmartThings. I suspect that's the issue,
Thanks. The code is:
d = addChildDevice("lnjustin", getChildContName(), contDev?.key, null, [label: getDeviceLabelStr(contDev?.value?.name)])
d.completedSetup = true // this line is causing the error
I don't see anything in the addChildDevice syntax to indicate completedSetup?
completedSetup doesn't exist in HE as far as I'm aware. Just remove that line, you won't need it. Mind if I ask what you're porting? It's possible someone already did the heavy lifting for you!
).
)
