Is it possibly to make an apple shortcut, that reads a NFC tag, and start a homey flow by sending the value inside the flow

I would like to use my iphone reading a NFC tag, and sending the NFC value to a homey flow, so i can make the Flow to different things depending of the NFC tag value.

1 Like

Hi,

yes, I would suggest using the iphone app “shortcuts” and homey webhooks for this (they are default on).

Steps:

  1. Create a Homey Flow with Webhook Trigger:
  • Open the Homey app.
  • Go to Flows and create a new flow.
  • Add the “When” card: Webhook received.
  • Name the webhook, e.g., nfc_tag.
  • Add “Then” actions based on the NFC tag value, such as turning on lights or setting specific actions.
  1. Read NFC Tag with iPhone:
  • Use the Shortcuts app:
    • Create a new Shortcut.
    • Add the “NFC” action and scan your NFC tag to associate it with the Shortcut.
  • Add the “Get Contents of URL” action in the Shortcut to send a webhook request.
    • Use the URL format:
https://webhook.homey.app/[yourcloudid]/nfc_tag?tag=front_door

Replace [yourcloudid] with your Homey Cloud ID, you can find it in the url when you go to https://my.homey.app/

You can either use a different webhook for each NFC-Tag, or use different “tag=” for each. The tag parameter is automatically captured as a variable in the Flow:

Add a “And” condition to check the value of the tag parameter:

  • Choose Logic > Is exactly.
  • Set the variable to tag (it will be available automatically).
  • Enter the specific value to match (e.g., front_door).

Sorry, need to ask now a question on my own, @homey team:
I’ve just tested this on my own. I am not sure if it is a good idea, because the webhooks are acutally public accessible. Meaning if someone gets the knowledge of your webhook, he can just trigger it without having to login.
So make sure you do not trigger any crutial stuff with that…

To make it more safe I would suggest using only the local URL (by using your homey’s IP as address). But then you would need to turn off the webhook capabilty as you can not distinguish between local calls and calls from the web inside a flow.

I think the main point is “sending the NFC value to a homey flow”, which (AFAIK) isn’t possible.

Athom apparently assumes that MongoDB ObjectId’s, which are used as cloudId, are random and/or safe to use as a secret, neither of which is true. I remember trying to discuss this years ago, and Athom simply didn’t care :man_shrugging:t3:

beside the discussion if they are “safe” as they are long enough and random: You don’t have to guess them. Anyone in the network path of the request can read them as they are contained within the URL. Just sniff the traffic and you get any URL even if the request itself is https.

So yes, using webhook are completly insecure and you should only use it for stuff where you don’t care if someone else is accessing it.

The community app “webhooks” together with using some token in the request header or body (which is encrypted in https) would make it safe, but a bit harder to configure.
Add a field “token” to the request header in the shortcuts app with a token only you know (use random 64 caracters for example), and read it out add additional “when” in the flow using the app “webhooks”.

TS can use local webhooks, when the “NFC phone” is part of the same subnet as Homey during the procedure.

1 Like

I use webhook relays (azure) in series. Traffic between them and homey is https. Traffic between iphone (or other systems like shelly) and the whrelay is https and use ‘post’ method. the post body payload contains extra credentials which webhook relay authenticates before transforming to the ‘get’ method and relaying the modified payload to homey.

The wh relay itself besides the extra authentication, checks on sender (app) type and blocks unknown http endpoints

This means that the real homey url is never used on an end user device.

Still experimenting with extra certificates.

And how do you block homey from direct access via the normal webhooks?

The webhook is flowing via vpn tunnel to firewall and from there to homey. The fw only accepts webhooks from relay, the rest is dropped.

But indeed, if you do not have the possibility to have the homey behind a fw or you are using homey cloud then if someone knows the homey webhook id then you can have a security breach.
With https, everything is tls encrypted except the domain name.
So everything after webhook.homey.app (the id and event code) cannot be seen by the man in the middle. But as the id cannot be changed, it is wise to still use a trusted webhook relay as a public webhook endpoint

Also, do not use browsers to send the webhook as the complete url including id is cached in this browser.

Oh wow, I did not know that. Somehoe I always assumed that the full url is transferred unencrypted. Ok, made my apps more secure than needed :rofl:. Never too old to learn something I assume.