or you could just setup a simple webserver (nginx) with a frontend and just use the REST API to expose those items and features you’d like your neighbour to have.
or you could just add some external MQTT Broker and let you neighbour use MQTT messages to trigger some action?
Create a users account for the neighbor in your myopenhab.org account.
Have the neighbor create an account and connect the openHAB channel using their myopenhab.org credentials.
Create an IFTTT applet to control the gate.
When you return you can remove the neighbor from your myopenhab.org, stop exposing the item through myopenhab.org, and remove the connection to IFTTT without relying on the neighbor to do it themselves. If you want to give them access again at a later date the best is probably to just stop exposing the Item through myopenhab.org. Then later you can restore access by re-exposing the Item.
sorry, I just read it’s “only” about a gate. What bindings and/or devices do you have already integrated? If it’s “just” the gate, you could give your neighbour a little button[1], which triggers your gate. That way you don’t have to do anything but just give your neighbour some wireless device which integrates with your openHAB. Works of course only, if your neighbour is in range of one of your technology - and saves you only work, if you already have a wireless technology in place…
How is this possible? I am already using ngninx but I could not find a way to restrict access to a single sitemap. Do you have a working setup for this?
Sorry, but I can NOT find any “easy” solution in the 2 referenced links. They only offer the access to the main OH2 landing webpage
proxy_pass http://localhost:8080/;
which is NOT a restriction to a specific sitemap.
Furthermore in the thread of your second link (which I already knew) the statement from rlkoshak rather points to my problem instead of being the solution:
So once again my question: Is it possible to configure nginx to only grant access to one specific sitemap (and not all of OH2)? I have nginx already up and running with SSL and authentication. But the question is to rectrict access only to a specific sitemap.
That is a different problem I was talking about in that thread. That is referring to the problem where one wants to use a reverse proxy to access OH using a URL like https://my.domain.net/openhab
I believe all you have to do is set the proxy_pass like the above.
I have the same issue, I want give friends and family access to the gate.
I haven’t started yet, however, my plan is going to be as follows:
Create a custom web app, probably something very simple in php, or maybe Mulesoft Community Editon. This app would be password protected, probably have some rate limiting, and my other security features such as IP address ranges - I might even create a mobile app based on it.
The Items must receive at least one update or command after being added to the Cloud Connector config before they will show up in IFTTT. Did you force an update for all of those Items and they still do not show up? The fact that any Items show up shows that it is working.
Many things are new, but no authentication mechanism.
You need to use a reverse proxy with credentials defined as outlined in the (current) security documentation. I assume you already checked there before posting here.
Due to the fact that there are 61 neighbors the safest would be having a 2nd OH instance for „public“ with nginx secured. Either shared user or individuals and keep your internal seperated.
Minimal setup only required item(s) etc.
I have multiple instances running (for high availability) and they share the same code which works with all bindings/devices etc.
so I do not see why it shouldn‘t work if limiting the public to one or few items
@Bruce_Osborne actually neither. Both are fully configured and connected to the various bindings, receive updates etc. The difference is, only one is executing actions which is triggerd by a “master switch”. So basically one is active and the 2nd one is just listening and in standby. Once the master switch is changed, the other instance can seemlessly take over.
But coming back to this thread, I would think same can be achieved. The only challenge I see is once they are on the sitemap, they could in principle also access paper UI etc. if active.