I’d like to exchange item values from a (planned) remote OH2 Installation into my local OH2.
I know, I could use the mqtt-eventbus, but I am a bit reluctant for two things:
security issues for opening the mqtt-port
all my local items being pushed over
ad 1)
Are there any security issues, if I open the mqtt-port in my firewall? Or is the connection opened by the Client? (I intend to use cloudmqtt.com as a broker for that).
I just want to exchange temperatures and other low level stuff via items, but I don’t want to be vulnerable at my home installation with this.
ad 2)
I configured two (internal) instances and experienced, that the slave installation sends all their slave items to my master Installation, while the master installation also sends all items to the broker (they appear in the brokers’ log and I can subscribe to the masters’ items).
in the Master mqtt-eventbus.cfg I left the sending configuration out on purpose:
broker=mqttoh2
# statePublishTopic=/openHAB/master/${item}/state
# commandPublishTopic=/openHAB/slave/${item}/command
# item name which can be used for posting the received value to the event bus.
stateSubscribeTopic=/openHAB/slave/${item}/state
# commandSubscribeTopic=
There are always security issues with opening any port on your firewall. And unfortunately OH doesn’t directly support encrypted MQTT (at least with 1.x, hopfully the up and coming 2.x binding will) so I would be very hesitant to connect two OH instances nakedly over MQTT across the internet.
I would be just as hesitant to use an external MQTT broker also because your traffic between OH and the broker would not be encrypted. I consider OH events to be sensitive and would not let those outside of my network without encryption. And I would not expose a service through my firewall without some sort of authentication. Username and password is OK, certificates are better.
So what is a user to do? I can think of several options, in order of decreasing attractiveness:
Configure a VPN between your remote server and your local server. This will provide strong authentication using certificates and encrypted traffic across the Internet and will let the two instances of OH talk to the MQTT broker unencrypted over the encrypted VPN tunnel. OpenVPN is a popular server that, though it is complicated to set up and configure, has tons of tutorials and documents out there to help you set it up. Many mid level and higher consumer gateways support setup of OpenVPN in your gateway.
Establish an ssh tunnel between your remote server and your MQTT broker (assuming your local OH is on the same LAN so no tunnel is needed). Configure ssh to only allow using ssh certs for logging in rather than passwords. As with OpenVPN, this lets the remote OH talk to the MQTT broker unencrypted through an encrypted tunnel. SSH would be easier to set up as well compared to OpenVPN, but it only allows tunneling on a single port; OpenVPN makes the remote server look like it is on your LAN.
Write a simple proxy MQTT client to forward the OH messages encrypted over the Internet. You would have a Broker deployed on both the remote and local sides. The client would subscribe to the broker on their local LAN normally and subscribe to the remote broker over the internet using certs for authentication and encryption. The clients would receive messages coming one way and republish the same messages to the other side.
I can’t answer anything about the behavior you are seeing with the publishing of the messages. I don’t use Event Bus.
I’ll have a thought or two on VPN. I figured, perhaps I can do without to safe some bandwidth, but of course you’re right. If there’s no encrypted communication, it’s not safe enough. Primarily its just weather data and non-important stuff. But the external OH2 would be on a mountain cottage with limited cellular connection. Sending a bunch of MQTT data won’t be a problem, but I’m sceptical for a stable VPN… Perhaps I let it just batch-send some encrypted data via email or stuff. It’s not vital Information, but I’d like to have a look on some temperatures or some low level information.
(I’ll open a new thread for the eventbus stuff, I guess)…
So, if you are not controlling anything up there then you can configure the remote OH using Event Bus and configure individual Items on your local MQTT to subscribe to the Item’s topics individually. Since it is non-sensitive information then using CloudMQTT could be a good option. Your remote OH has no controllers and you wouldn’t need to open any ports to publish the data to the broker. Likewise, you wouldn’t have to open any ports on your main OH and since you are only subscribing to topics, no data from your main OH will leak out of your network.
I’d be happier if the messages were encrypted even with this configuration but you are at least not opening any ports whatsoever on either network and your main automation OH will remain safe behind its firewall. As long as you have no actuators in the remote instance this is reasonably safe.
ok. that sounds like a plan!
I really don’t want to control anything. Only thing I could change were some electrical outlets (e.g. for fan heaters)… but that’s too risky as it’s an old wooden cottage! It’s safer to freeze a bit, until the stove is burning…
