How to expose one of my sitemap to neighbours?

depends on how your neighbour has access to your network. If she’s using your guest-Wifi or if she only has external access.

if you neighbour is 100% external, it would be indeed the safest way to use myhopenhab and perhaps the App.

If it’s local (or Guest-wifi) - or you have the possibility to secure your network and you don’t mind some work, you should consider using a reverse proxy, which points to a specific sitemap:
https://docs.openhab.org/installation/security.html#nginx-reverse-proxy

  • 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?

This will be a bit convoluted but it should work in a way you can revoke access when you have home.

Prerequisites:

Expose the gate item through myopenhab.org.

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.

This works well for one or two Items.

2 Likes

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… :wink:

[1] Button could be either one

  • RF 433MHz button
  • Fibaro
  • Wifi
  • MiHome
1 Like

I have 61 neighbours :smile:

1 Like

what about habpanel?

and if you want some security=Ngnix

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?

“easy” :wink:

https://docs.openhab.org/installation/security.html#nginx-reverse-proxy

or there’s a tutorial including some discussions here:

I will try with IFTTT

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.

proxy_pass http://localhost:8080/basicui/app?sitemap=sitemap-name

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.

1 Like

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:

  1. 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.

  2. The app would would use the myopenhab API (https://docs.openhab.org/configuration/restdocs.html) to open the gate. (and for me open the garage door).

Not sure if this a great idea, but I know my gate is too far away from the house for guest network access to work.

If I create the mobile app, I’ll just get the gate to open as they arrive.

C.

I was looking at exposing a few items to IFTTT but it appears there is not a reliable way of doing this or I am doing something wrong

using Expert section in OpenHab Cloud configure Binding in PaperUI I added some items, but not all that are selected are available in IFTTT

Ive tried this with varying selections allowing a few days for IFTTT to “update” .

Is it possible the “core” .conf file for these items being shared via myopenhab need a clean sheet/reset ?

I have tried a reboot of the server to check if that is the cause/fix, it seems not

You do this by adding a list of the items to the Cloud Connector configuration:

https://docs.openhab.org/addons/ios/openhabcloud/readme.html#configuration

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.

1 Like

As usual your assistance is precise and most appreciated many thanks. Do strings or numbers have different method of update ? I was only

gDevice.sendCommand(OFF)

For switch item, Where a number item would need a Numeric value in () ?

Yes. That is all there is to it.


Over 1 year ago… Let’s try again :slight_smile:
May be something appear new in OH since that time?

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

Communicating via MQTT or the API?

@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.