Yea, it opens up the link in a browser and it opens the door if its closed and closes it if open.
Use local url, so you have to be on the local wifi
1 Like
Answering my own question. If you are using NFC Tasks:
- Create a task profile with the URL to Hubitat, and whatever else you want it to do and save it.
- Create a new task, select the "Various" item and "Run Profile". Just select the profile you saved above.
Now when you scan the tag, you just get whatever you labeled that first profile to be, with no actual useful information. Anyone that you want to give access to that tag would need that first profile on their phone.
Did you ever get anywhere with this? I'm very interested in making this work as well. It seems on an endpoint trigger, the %device% is undefined, unlike other trigger sources. 
Thanks for that. Must have been a bit dense the other day since I am using the Maker API, but just for the HSM calls.
I ended up making a quick driver for multiple buttons and then adding devices for each family member so they had their own unique identifier.
In NFC Tasks (you don't need NFC Tools for everyone else), I added 3 user variables:
{VAR_URL} http://10.0.0.10/apps/api/15/devices/
{VAR_DEVICE} USER DEVICE FROM THE DRIVER
{VAR_ACCESS} ?access_token=OUATH
Using NFC Tools, made a GET task (this is for pushing button #1):
{VAR_URL}{VAR_DEVICE}push/1{VAR_ACCESS}
Now if anyone reads that tag, it's a bunch of useless variable names. If the user has NFC tasks installed and those variables set, they get the desired outcome.
Works really slick, and allows per-user filtering of the button presses to RM actions. Any random person gets or learns anything from the tag.
I know this thread is about a year old, but I think it's got enough good info to bump it back up to the top. We've got an August lock, and the auto-unlock feature leaves a LOT to be desired (it unlocks the door when I arrive home only about 1/3 of the time, and that's being generous). Having all this technology just on the other side of the door but still having to fumble for my keys or find the app on my phone was really aggravating. Using the information in this thread, I now have an NFC tag solution that works perfectly without even unlocking my phone (if someone gets as far as our front door and wants in, they're coming in whether they have my phone or not). I just tap the phone on the tag and the door locks/unlocks automatically.
I wanted to call special attention to the following folks for their invaluable advice in this thread:
- @spalexander68 for recommending NFC Tasks/NFC Tools Pro in reply #2. Works beautifully, and NFC Tools Pro is very fairly priced!
- @mark.cockcroft for the advice in reply #44 about using the Maker API combined with a virtual button and Button Controller app.
- @lpakula for the tip in post #45 about user variables in NFC Tasks and the GET task in NFC Tools.
Using all three of these ideas, I did the following:
- Created a virtual button in Hubitat.
- Set up a Button Controller with an IF/ELSE rule that locks/unlocks the door when the "button" is pressed, depending on whether it's currently locked or not.
- Used the Maker API app to create an endpoint that (locally only) can control that virtual button and send a device command when called.
- Used NFC Tasks to create a series of user variables (base local URL for the Hubitat, Maker app ID, virtual button ID, and OAuth token).
- Used NFC Tools Pro to set up an NFC tag (cheap pack from Amazon) to trigger a GET task using the "Send Device Command" URL from the Maker app, substituting the above variables so that only devices with all of the variables (most importantly the OAuth token) set up in NFC Tasks can trigger the virtual button press that locks/unlocks the door.
Maybe it goes without saying, but the above assumes you already have the August lock set up as a device in Hubitat. I may have missed a detail or two, but I wanted to (a) recap my success in the hope that it could help someone else and (b) thank those whose advice in this thread was crucial to getting this working. 
8 Likes
Lovely summary! So you place a tag somewhere near your front door and as long as your phone is nearby it automatically unlocks the door?
How close to the tag do you need the phone to be? I prefer if it has to be pretty close for my use case.
Any decent quality tags on Amazon? Ideally outdoor rated.
I've got mine stuck on the door frame between the screen door and the inside (main) door with double-sided tape. Both the tag and the door frame are white, so it blends right in and you don't notice it unless you're looking for it. It's just a plastic disc and should be completely weatherproof. I used these because they were the cheapest at the time, but they're now charging shipping and I'd get these instead, especially since they're self-adhesive, which the ones I bought aren't, despite being labeled as "stickers" (since updated).
The phone has to be pressed against the disc (e.g., like contactless payment at a store), not just in the vicinity. No worries about it inadvertently locking/unlocking as you walk past. It works great, but I still wouldn't lock the house without the physical key in my pocket, just in case. 
This worked like charm, super easy!
I assume I can export my variables to the wife's phone as a profile so they get the private variables without having to retype them into her phone?
For those who didn't figure out what is done, basically the url with the variables is written to the tag itself with the variables names in the data written to the tag.
As the tag is read by the task portion in the app, the app will substitute the variable names with the data you defined for those variables in your phone. Thus just reading the tag isn't enough, it just gives you an url like construct with variable names without any data. Really smart!
1 Like
Glad it worked for you!
I don't see any way to export the variables from NFC Tasks, but most of them (in my setup, anyway) are short and easy to recreate. The only one that's not is the OAuth token, and they can be copied/pasted into a text message and then deleted (or copied directly from Hubitat if you open it in a browser on your spouse's device).
This is excellent. Is it run locally?
Yes, the local end point does.
Brilliant. Also, lastly, I promise, does this work on iPhone too & can it be run if you're out of the home? i.e. you put an nfc tag in the car and want to run the automation on the way home.
You can, but you will need to use the cloud end point for it to work. Now, iOS is a whole deferent animal. Checkout @ogiewon post here for setting it up using shortcuts.
1 Like
Now that I've done this, is there a "unless I'm connected to the local network, run the automation on a local end point"? only thinking about response time / reliability
Hi guys. I'm not the saviest when it comes to end points and URL's etc. However, where do I find the device ID of a device. Is It the device network ID or the ZigBee ID or something completely different? Also, when I know this, and I enter it into the URL, do I remove the square brackets in the URL. Similarly, how do I enter a device command. Please can you send an example of how it should read as I cannot get this working for me 
Look in the URL of the device details page of the device you want to access via MakerAPI. You will see a numeric value in that URL which is the device ID you want.
You hit the nail on the head, there is nothing faster than local.
Sorry, so is there a way to get it to try locally before trying cloud? Thanks so much for your excellent help so far
Turn off your wifi and use data to replicate being away or create the same automation with the local end point. I would just turn off the wifi. Hope this helps.
