NFC Tags and Automation

I know NFC is compatible either through REST or other means (custom apps/bindings etc). I’m more wondering if anyone is using it in their daily automation and how.

My thoughts were around a way to allow automations without requiring the app or a ui to those not always in the house.

Ideas that came to mine were rest urls encoded to tags with labels around the house for tap here to blank or other things along that line.

Would love to hear what others are doing with NFC or have tried and failed.

Just a few things to consider:

  • The guest’s devices will need to be on the same LAN or you’ll have to encode authentication in the URL to go through myopenhab.org which risks exposing your myopenhab.org username/password.

  • I find this to work best for big things like setting a scene instead of little things like flipping a light.

  • Unless something has changed, there isn’t a TOGGLE command so either you’ll have to get clever with proxy String Items and rules or you’ll have to create two tags for each switch, one for on and one for off.

In the hierarchy of convenience, NFC tags are near the middle:

  1. completely automated, no direct human interaction required
  2. voice command through a smart assistant speaker
  3. widgets on a phone app
  4. dedicated wall mounted tablet
  5. NFC tags
  6. phone app/web based UI

4 and 5 are pretty much the same as in both cases you need to physically move somewhere and interact with a device. I put NFC under the dedicated tablet because you have to have your phone on you to interact with NFC tags. I put phone widgets a little higher than tablet and NFC tags because you don’t need to physically move somewhere to control something. Your rankings may vary.

I used to have a bunch of NFC tags but most of them controlled stuff on my phone (e.g. using Tasker to set up my phone in driving mode). I’ve long since abandoned them all as not being worth the effort. Instead I focus on making stuff fully automated instead of controlled. For guests I make sure that everything can also be controlled in the traditional non-smart way too (e.g. flip the wall switch).

2 Likes

Definitely as I have a guest network that is allowed access to parts of openhab that isnt a problem. That said I can also setup a proxy server for relay of urls (and transform if needed) to openhab. This would be restricted to on prem.

There is not by default but there is a toggle block in one of the block library addons in the marketplace

I agree with this. 98% of the items are in this category also.

As far as my thoughts the default actions on devices of opening browser etc is annoying. It would seem in all cases a specific app would be needed.
It seems that the biggest potential use without custom stuff is the ability to open the Guest Page easily.

In all my NFC applications I also pair QR codes with them to allow non-NFC devices to do the same thing.

That’s not going to directly help you here. With NFC tags you are limited with what’s exposed through the REST API. That’s why you’d need to do something clever like, for example:

  • create a String Item to receive the NFC commands
  • configure the NFC tag to send a toggle command
  • that triggers a rule which interprets the toggle command and issues the correct command to the “real” Switch.

The rest api exposes rules and scripts are rules also

Testing in postman this works.

POST http://openhab:8080/rest/rules/467a630d41/runnow

The uuid in the url is a script not traditional rule. Thus You could call a script. That thus can be a simple script to toggle something.

Yes indeed you could run a rule directly. However, you have to be logged in as an admin user to do so. Regular users only have access to Items I believe.

For that reason, that’s not super standard but certainly in the realm of possibilities. But without an Item you loose the ability to know what state you are in for some use cases so I wouldn’t rely on only running scripts directly all the time (assuming you’ve managed the authentication so these NFC users can issue the call to run the rule in the first place). There will be cases, for example, where you might need to set an Item with a value representing a scene (e.g. home/away, TV mode, etc.) and you don’t want to lose that state.

In general, Items are easier to manage and maintain than rules so rather than creating a bunch of rules whose sole job and sole difference is to toggle a single Item I would create one String Item. The NFC tag would command that String Item with the name of the Item to toggle which would trigger the one toggle rule which will implement toggling the Item whose name matches that which was commanded to the String Item. One new Item and one rule to support all your toggling needs.

However, there is one part of that statement that needs comment. A Script is a traditional rule too. From a technical perspective, what makes a rule a Script is that it has only a single Script Action and it is tagged with “Script”. This lets MainUI show these differently but from core openHAB’s perspective (and therefore the REST API), there is no difference between the two. They are both just rules.

That is right i forgot the specific separation.

True. That said in an effort to further decouple the openhab implementation and mine (for others) the option I would most likely to is a proxy.

At that point the request from the tag can be open in any format desired. Then the proxy will map that to a OpenHab rest api query and would also have creds to pass in.

Most of the things that I might expose to tags and others I have rules/scripts for.

I do think though for added functionality in items that I don’t have stuff setup for the utility item and singular rule would definitely simplify things.

Im thinking in any setup

TAG URLS ------> PROXY SERVER ---------> OpenHab

TAG URL EXAMPLE
================================
http://xyz.com/trigger/door-lock 
================================

PROXY CONVERSION EXAMPLE
===============================================
http://openhab:8080/rest/rules/xyz123xyz/runnow
HTTP AUTH in header
===============================================

In this the end user only can know of the proxy (one already exists on network

Though all of this is still bound by the native behaviors of phones to open a browser. So the UX is still sub optimal.

There’s an unofficial binding for listening to HTTP requests that may be of use to you.

It also allows calls to be made through myopenhab with a token. I haven’t tried it, though.

I echo this statement. I bought some NFC tags to play around with using the openHAB Android app, but the limitation always comes back to the NFC tag being located in one spot, and me needing to stop at that spot, tap the tag, and then wait for the app to carry out commands. It defeats the purpose of being able to control openHAB from wherever I am at the moment.

If guests are the focus, then I would just make a simple sitemap with the items you want them to be able to control, and then give them the URL via NFC or QR code. Alternatively, you could have them download the Android app, which should autodiscover your default sitemap when they’re on your guest network (I’m not sure whether or not the iOS app also does this).

In general my plan is to “automate” and anticipate everything. That said not there yet.

I do have a guest sitemap/page and that is accessible by them. That said I have some guests (parents inlaws) that the app route or using the sitemap may be problematic. I recently got them to understand and use qr codes.

I recommend only automating behaviours that you want to happen 99% of the time. Particularly if there are other people in your house who also need to wrap their heads around these behaviours. When automation gets too complex (too many inputs resulting in too many outcomes), it can be more frustrating than helpful.

I suspect that you already know this, but I’m saying it anyway. :wink:

It took me about a year of tweaking to get my system where I want it. However, I live by myself, which makes it way easier to anticipate human unpredictability.

Just to make sure we’re talking about the same thing, this is a sitemap:

Sitemaps were the main control interface in OH2, but have been deprecated in OH3. New users who’ve only seen OH3 often think that pages and sitemaps are the same thing (which is understandable), so I just want to make sure that’s not happening.

You can create a sitemap in MainUI. Go to “Pages” and press the “+” button at the bottom right corner of the webpage, then select “Create sitemap”.

image

The reason I mention this is that sitemaps are designed to be VERY simple. If your guests can use smartphones to read QR codes, they can figure out a webpage with 5-6 toggle switches.