Hi,
I was wondering since it seems like tedee and it's web API are working with other systems already:
How do I do that exactly with hubitat? I don't even need a fancy device page or something (eventhough this would be nice of course). I only would like to use the lock(s) in rules, like: in case of a fire alert -> unlock doors.
I can't claim any experience or knowledge of these devices, but the API seems simple enough and well documented, and existing examples in other HA system are always useful. If there are no drivers for HE already, the process isn't normally too difficult once you are familiar with REST API's such as this.
I guess I'm mostly trying to instil some positivity, if you are wanting some pointers on writing some drivers yourself, then we may need to understand your experience / inclination for developing drivers or whether you are looking for someone else to do this for you (and others)...
1 Like
I have no experience what so ever. I actually was hoping that there would be some way to add the locks API token and then just simply use these http requests in a rule directly?
Apologies, I must have somehow missed your response.
The short answer is no, unfortunately that will not work in this case, you really need to have a driver for these.
I am guessing you may have had experience with other api's or integrations where a key is all you need, and I have had similar experience with systems such as Philips Hue. These are relatively low risk, in the scheme of things, and so can take a "lighter" touch with security. You could store the key in a rule, taking the risk that it could be displayed on screen unencrypted / unprotected from people seeing or intercepting it and re-using it to turn your lights off again...
When it comes to locks and security systems in general, you want a higher level of security for the communications. So even their "low-key" version requires you to renew you api key every 4 hours, using another key to do the renewal, where the second key expires every 14 days. So it is not really feasible to have pre-built rules to store the key for the various calls you may want to make. Even with using variables, there is still a security risk in storing such sensitive information in these.
There are other technical reasons as well, including the complexity of some of the calls, the need / want to store the state of locks and assess the success or failure of commands that are issued. From what I have seen I don't think RM would be up to catering for all of this.
Simon
Thanks Simon for your input. What I don't understand though: from the documentation it seems like I could use "Postman" with a created token/key. And how is that suppose to "update" that token?
And yes, putting the token into hubitat in plain text is kind of a risk. I don't know how for example postman or IFTTT is handling such thing though. Since Tedee is still promising that they will come up with a local API next year and a lot of potential customers are looking forward to this, I am still eager to integrate it into hubitat though. Unfortunatly they do not offer all the stuff I want to do with the lock in their App. For example I would like to lock the door only when all the people from the house have left the homezone or locking the door, when night mode is triggered. Other thing I would like to accomplish: When the smoke/water sensor triggers the door should be unlocked and an emergency PIN on the upcoming keypad shall be activated.
Acutally, the rules are pretty simple and the tasks for the http request are as well (I think). The only thing missing is the link between hubitat and the lock...
If somebody capable of coding a devicehandler is up for the task, I am happy to help and test! 
I would expect you would need to provide the token in something like Postman, after having made earlier calls to obtain it. The Code Flow section of the authentication documentation explains how you need to handle these tokens, which is not a workflow RM could fully cater for, I don't believe.
Hopefully someone can help you in getting a driver written.
Simon
Oh, I actually just read the first lines here:
https://tedee-tedee-api-doc.readthedocs-hosted.com/en/latest/getting-started.html#registration-and-authentication
And thought, after logging in, copying the token and putting it into postman, I would be set to just make https requests...
You see: I am totally not up for this task, eventhoug documentation seems to be great on it 
I only used Nuki via IFTTT once when using smartthings for some of the tasks described above 
Yeah, it's that other "dedicated section" that holds those details. But don't let me downplay it entirely, you could certainly step through the processes the walk you through and get to understand the API using postman. They are right, once you have obtained the token, you can run some API calls using it. The next step from that is then how do you make that able to happen without someone sitting there obtaining that token every 4 hours? Anyway, I shouldn't labour the point, I think you get what I am saying....
While I have an IT background and had a basic understanding of REST API's without having used them in any meaningful way, examples like this are a good learning experience, even if just for an awareness of how they work and how to use them.
The auth code flow actually requires a Hubitat app for the OAuth2 parts. Once you have the auth token you can do the refreshes and API accesses in either an app or driver, whichever is the best match for your use case. There's some detail here on the critical parts: https://docs.hubitat.com/index.php?title=App_OAuth
1 Like
Hmn, I got the info from Tedee that there is a new way of authentification as well:
https://tedee-tedee-api-doc.readthedocs-hosted.com/en/latest/howtos/authenticate.html#use-personal-access-key
does that help in any way, though?
