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.
Hi,
yes, I would suggest using the iphone app âshortcutsâ and homey webhooks for this (they are default on).
Steps:
- 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.
- 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
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.
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 . Never too old to learn something I assume.