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:
completely automated, no direct human interaction required
voice command through a smart assistant speaker
widgets on a phone app
dedicated wall mounted tablet
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).
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.
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.
TAG URLS ------> PROXY SERVER ---------> OpenHab
TAG URL EXAMPLE
PROXY CONVERSION EXAMPLE
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.
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”.
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.