Hass.io Mqtt Bridge problem

Devices & Integrations
1

I can not get the bridge to work.

Here is my Hass.io setup:

configuration.yaml

mqtt:
broker: 192.168.10.5
port: 1883
client_id: hass
discovery: true
discovery_prefix: homeassistant

Here is the addon Mqtt-broker options

{
“plain”: true,
“ssl”: false,
“anonymous”: true,
“logins”: [],
“customize”: {
“active”: true,
“folder”: “mosquitto”
},
“certfile”: “fullchain.pem”,
“keyfile”: “privkey.pem”
}

My settings for the smartthings device are:

ip address: 192.168.10.5
port: 1883
Mac address: REDACKED

When the MQTT-Broker addon starts here is the log:

starting version 3.2.2
1507562632: mosquitto version 1.4.12 (build date 2017-06-01 13:03:48+0000) starting
1507562632: Config loaded from /etc/mosquitto.conf.
1507562632: Opening ipv4 listen socket on port 1883.
1507562632: Opening ipv6 listen socket on port 1883.
1507562632: Warning: Mosquitto should not be run as root/administrator.
1507562632: New connection from 172.30.32.1 on port 1883.
1507562633: Socket error on client , disconnecting.
1507562633: New connection from 172.30.32.1 on port 1883.
1507562633: New client connected from 172.30.32.1 as hass (c1, k60).

When I turn the front lights on from the Android App I get the following logged in IDE:

12:43:32 PM: debug Sending ‘{“path”:"/push",“body”:{“name”:“Outside - Front Lights”,“value”:“on”,“type”:“switch”}}’ to device

12:43:32 PM: debug Forwarding device event to bridge: {“path”:"/push",“body”:{“name”:“Outside - Front Lights”,“value”:“on”,“type”:“switch”}}

Followed by the following in the MQTT-Broker addon logs:

1507567453: New connection from 192.168.10.50 on port 1883.
1507567453: Socket error on client , disconnecting.

Again, any help would be greatly appreciated

2

It sounds like it’s connecting to the bridge correctly, but there may be an authentication error between mqtt and the bridge.
I’ve got my Smartthings Device handler running on port 8080, and here’s my MQQT hass.io bridge settings:
{
“broker_host”: “xxx.xxx.xxx.xxx”,
“broker_port”: 1883,
“preface”: “smartthings”,
“state_suffix”: “state”,
“command_suffix”: “cmd”,
“login”: “testuser”,
“password”: “mypw”,
“bridge_port”: 8080
}
The hass.io brige “bridge_port” must match the Smartthings Device handler port.
The next part is to get the hass.io MQTT talking to the hass.io bridge. Here’s how I’ve set my MQTT:
{
“plain”: true,
“ssl”: false,
“anonymous”: true,
“logins”: [
{“username”: “testuser”, “password”: “mypw”}
],
“customize”: {
“active”: false,
“folder”: “mosquitto”
}
}
Notice the username and passwords are matching between the hass.io MQTT and Bridge. Give port 8080 a shot, see what happens.

3

Thank you very much!

One quick question. Where are you inserting the following config?

In the MQTT Broker Addon?

Thanks again

4

Those go in the smartthings bridge plugin inside hass.io that was written by vkorn.
https://github.com/vkorn/hassio-addons/tree/master/smartthings
You are using the bridge, correct?

5

@Ryan_Ray_Neff Do you have certfile and keyfile setup in your Mosquitto broker config?

  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem"

I’m having a hard time getting this running as well. I’m running hass.io on my Raspberry PI with the Mosquitto broker add-on and the smartthings-bridge add-on

6

I nuked my install and started over using duckdns, and the baked-in letsencrypt. I have the certfile and keyfile in my MQTT config now - but I’m not able to get the Hass.io bridge to connect to smartthings over port 8080. Ugh. Did you happen to get this running in the last 10 days?

7

Yea I eventually got this running mine was related to the IP

8

(All references to ‘Hass’ are to Hass.io, it kept defaulting it to a link and wont let me post with multiple links because Im a new user)
My SmartThings logs (in Hass) shows

info: subscribing to smartthings/Bed Fan Light/level/cmd, smarrthings/Light Stand/switch/cmd, smartthings/Car Charger/switch/cmd, smartthings/Bed Fan Light/switch/cmd
info: Incoming message from SmartThings: s,artthings/ Car Charger/switch/state = off

My MQTT Broker logs (in Hass) show

1509543132: New connection from 192.168.0.200 on port 1883.
1509543132: New client connected from 192.168.0.200 as home-assistant-1 (c1, k60, u’user’).

But the state of the switches on Hass interface don’t match up and don’t do anything when toggled.

Before I switched over to HassI had them set up like this (sorry for the formatting, I can’t figure it out in this editor)…

switch:
- platform: mqtt
name: “Car Charger”
state_topic: “smartthings/Car Charger/switch”
command_topic: “smartthings/Car Charger/switch”
payload_on: “on”
payload_off: “off”
retain: true

But I don’t remember if the logs used to say cmd at the end of them like that? Changing that too

switch:
- platform: mqtt
name: “Car Charger”
state_topic: “smartthings/Car Charger/switch/state”
command_topic: “smartthings/Car Charger/switch/cmd”
payload_on: “on”
payload_off: “off”
retain: true

Works but doesn’t seem right? Is it? But figured I’d post it here since I spent a lot of time trying to figure it out

9

@shogan94
Looking at your Smartthings Log, it looks like it’s connecting correctly.

When I don’t include state or cmd at the end of my state_topic and command_topic, my lights would show up in the hassio interface, but toggling the switches wouldn’t do anything. Your second code block with the cmd and state suffix’s looks correct to me. The other thing I had problems with, is the retain:true flag. Since I was controlling those things from both smartthings and hassio, I saw some really weird behavior. Occasionally the raspberry pi would get disconnected, and then automatically reconnect and the retain true flag was causing lights to toggle at random. Setting the flag to false didn’t work quite as expected. The setting for true wasn’t overwritten in the database, so I had to uninstall/re-install my mqtt broker to get the retain:false flag to apply properly.

1 Like
10

Thanks, yes it is working correctly and I actually experienced the same thing! So I will have to try setting retain: false on all of them and see if that helps any.

Thanks for that.

11

Hey Ryan,

I’ve finally gotten my setup to work properly, and have also seen the odd lights turning on and off as well. I put the retain: false in after my switches in configuration.yaml, but that didn’t seem to help. You mentioned uninstalling and reinstalling the mqtt broker, which I will be doing.

Big question is how did you check the database for this?

12

@bwthor

Honestly - I didn’t check the database. I found another thread where someone mentioned it. I assumed that was the issue based on the behavior I was seeing, and then trial and error. Since Hass.io is built on Reson OS, I hear it’s kind of a pain to check the database. (I think you have to enable developer mode) Uninstalling/reinstalling the MQTT broker through the Hass.io GUI was super easy though, about 10 minutes total. It’s been a few weeks since I did that uninstall/reinstall fix, and I’ve had 0 problems with the random lights since then. It’s working so well I’ve started migrating all my automatons over from smartthings into hassio.

13

So far so good for me too after the reinstall of the mqtt broker. Still not confident in the new Hass.io setup though. Keeping the wife happy is #1 with this home automation stuff. Don’t make things any more difficult than they need to be.

14

Thank you- this finally fixed my setup. I was experiencing the same thing after switching from the Raspbian HA install to Hass.io. I discovered the problems weren’t quite random though, some events were firing on exact 15 minute intervals. I believe the messages weren’t being sent by either SmartThings or Home Assistant, they seemed to be originating in the MQTT-Bridge. I wonder if the Hass.io Mosquito broker or Smarththings-MQTT-Bridge add-ons introduced some bugs or incompatibilities with the “retain: true” flag because I wan’t having any problems with my Raspbian build.

I’d still love to know what caused this, even if it no longer haunts me.

1 Like
15

Probably a dumb question, but do you have to expose your hass install to the internet if using this? I’m trying to use smartthings as my “bridge” to the outside world while keeping my hass install local only (or accessed via VPN).

16

You do not need to expose hass.io to the internet to use this. However, smartthings must be on the same wifi network as hass.io.

17

And if SmartThings cloud goes down as it has been these past few weeks, then since the MQTT broker is hosted in the cloud, hass.io won’t respond to requests.

what are the chances it could be hosted locally in device? Slim to none i would imagine. My other option would be to use usb z-wave controller on hass.io as “master” and perhaps let smartthings join existing z-wave network? then most things should remain online except for zigbee or other smartthings specific devices. I would love to go the other way and have hass.io be secondary, but that doesn’t seem to work.

18

In my experience, it’s pretty rare for Smartthings to got down. I think there was a few hours around christmas - which is the longest outage I’m aware of. (I didn’t notice it at the time, only heard about it afterward) The Hass.io MQTT broker runs locally, so you can still use that from within your network. Using a z-wave stick on your hass.io Pi works great - I’ve tried it and liked it. I kept all my z-wave devices routed through my smartthings hub because I’m lazy. If you wanted to access z-wave devices on your hass.io remotely, you’d have to setup Duckdns. On the upside, letsencrypt certification became a “baked in” feature of the duckdns plugin, so it’s pretty secure. (You will still have to setup port forwarding on your router though)

Other than the problems I’ve mentioned in this thread - the hass.io MQTT broker has been super reliable for me. I regularly use both the Smartthings app and the hass.io interface to access remotely, because neither one does 100% of the things I want.

19

Thanks for the feedback.

I’ve had SmartThings for about 1.5 months and I’ve experienced two outages. I’m hesitant to put anything import on SmartThings such as locks or garage door for fear of an outage resetting the status (and giving me a false indication of the door being unlocked) or worse, actually opening or unlocking them.

I get htat hass.io mqtt broker runs locally, but the smartthings device handler is based in the cloud and so if ST cloud goes down, then again, we are ultimately down and at heir mercy. I really wish ST would allow x amount of memory for items to run locally, no matter what they are… this would solve everything. I think my next attempt will be to move everything to z-wave stick again and try and join smartthings to the network.

I wonder if the devices could be multi-directional? Ultimately, I’m using ST for it’s bridge to Google Home and Amazon Echo and a few other things, but if I could run z-wave locally on hass, then use mqtt broker to go back to ST (and never actually join the z-wave networks together) then that may solve the problem. If ST cloud is down, Echo and Google wouldn’t respond, but that would be OK… automations and my local access would not be affected. I could also use the ST device for Zigbee items should I ever go down that route. My guess is the mqtt broker is one way… ST to hass.io (or openhab/whatever).

20

Hi there,
I am running into a wierd issue looks more like some kind of ghost command being sent

This is in my config.yaml file

switch:

  • platform: mqtt
    name: "Office"
    state_topic: "smartthings/Office/switch/state"
    command_topic: "smartthings/Office/switch/cmd"
    payload_off: "off"
    payload_on: "on"
    optimistic: true
    retain: true

So what happens is that i turn the lights off
In HA = switch turns off all good
After a while (unable to know exactly when) the lights would turn on automatically
Look at my live logging in smarthings, seem that i did receive a “on” request coming from the mqtt broker

Did anyone experience this?