The security I’m talking about is opening up your networks to hackers. Any time you punch a hole through your firewall (i.e. expose a port to the internet) you have opened up a place for attack.
These attackers may not care to open your door, but they may want to get on your network so they can steal enough information to steal your identity, set up a platform from which to attack others, encrypt your hard drives and hold them for ransom, etc.
Given your professed level of skill, I highly recommend setting up a VPN. One potential solution that isn’t too hard to set up is Hamachi. I think it is still free and it might be easier to set up than OpenVPN, assuming your router doesn’t support OpenVPN out of the box.
Ok, I understand. I didn’t think about it that way, thanks for pointing that out. That type of security holes is definitely something that I want to make sure not to expose my home network to. So I will follow your advice.
When I got everything set up I’ll update here again with all details. And it will be in layman’s terms so it might serve as useful information for someone else later on that would like to do the same.
Hi @markus7017 ,
Unfortunately I was burned badly while a heavy contributor to this project last spring, and as a result it evaporated my interest in contributing. Hopefully there is a good person who can offer you assistance. Regards, John
Can anyone offer some assistance, im playing around with this but will ultimately use it to fix my Zwave network which right now relies on socat/ser2net and its just not reliable.
I’ve setup two Openhab 2.4.0 stable systems.
Garage: (192.168.0.3) Main instance - This already had a MQTT Broker running and has the MQTT 1.x binding
House: (192.168.0.33) Slave instance, I’ve installed the MQTT 1.x binding and configured mqtt.cfg in /etc/openhab2/services/mqtt.cfg as follows:
It appears I’ve got my slave configured incorrectly in the MQTT.cfg file as I see this:
07:29:20.022 [INFO ] [rt.mqtt.internal.MqttBrokerConnection] - Starting connection helper to periodically try restoring connection to broker 'mosquitto'
07:29:30.027 [INFO ] [rt.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'mosquitto'
07:29:30.044 [WARN ] [rt.mqtt.internal.MqttBrokerConnection] - MQTT connection to 'broker' was lost: Connection lost : ReasonCode 32109 : Cause : null
07:29:30.046 [INFO ] [rt.mqtt.internal.MqttBrokerConnection] - Starting connection helper to periodically try restoring connection to broker 'broker'
The ‘Garage’ where the broker runs (master) sees this in /var/log/mosquitto.log
1575664270: New client connected from 192.168.0.33 as House (c1, k60).
1575664280: New connection from 192.168.0.33 on port 1883.
1575664280: Client House already connected, closing old connection.
1575664280: Client House disconnected.
1575664280: New client connected from 192.168.0.33 as House (c1, k60, u'mosquitto').
1575664290: New connection from 192.168.0.33 on port 1883.
Can someone explain what I’m doing wrong please? or offer some guidance.
Are you using unique cleintIds for both openHAB instances? Only one clientId can be connected to the same broker at the same time. If a new client connects with the same ID, the broker will kick off the old client.
If they both have different client ID’s all I can recommend is to search for “ReasonCode 32109” and see if one of those threads or github issues has information to help.
The library that handles the MQTT connection is wholly different in the 2.x binding (Paho which is used by the 1.x binding is riddled with bugs and not being maintained very well by the originator so the 2.x binding moved to a different client library HiveMQ). If there is a bug here I doubt it will get fixed.
This isn’t strange. You are connecting to the broker, failing to connect so it tries to connect again. That’s how it’s supposed to work.
I can’t explain why it got uninstalled but that almost all of the time is caused by trying to use a mix of addons.cfg and the REST API to install add-ons.
But there is still a file under $OH_USERDATA/conf/org/openhab/mqtt.conf. The cfg files from services get loaded and rewritten out to that file and there has been a well known issue for a long time where when you wholly remove things from a file in services or remove a file from services, it doesn’t get removed from $OH_USERDATA.