I cant get this figured out..

[cdrom1028]

I am stuck. My setup is as follows:
Hass.io RPi w/ Mosquitto broker Addon <-> Bridge RPi w/ Docker Based mqtt-bridge & MQTT Client <-> Smartthings w/ MQTT Bridge device Handler and SmartApp

1. In HA I have 2 switches defined and when I toggle them off and on I can see the MQTT messages on both the HA Pi and the the Bridge Pi via mosquitto_sub.

switch:

• platform: mqtt
  name: "Christmas Tree"
  icon: 'mdi:pine-tree'
  state_topic: "smartthings/Christmas Tree/switch"
  command_topic: "smartthings/Christmas Tree/switch"
  payload_on: "on"
  payload_off: "off"
  retain: true
• platform: mqtt
  name: 'Desk'
  state_topic: "smartthings/Desk/switch"
  command_topic: "smartthings/Desk/switch"
  payload_on: "on"
  payload_off: "off"
  retain: true

pi@RasPi-4:~$ mosquitto_sub -V mqttv311 -h 192.168.1.97 -p 1883 -u user -P pass -v -t "smartthings/#" -c -q 2 --id mqtt-test

smartthings/Christmas Tree/switch off
smartthings/Desk/switch off
smartthings/Desk/switch on
smartthings/Christmas Tree/switch on
smartthings/Desk/switch off
smartthings/Christmas Tree/switch off

2. On the Bridge Pi I can also see the all the correct Subscriptions coming from smatthings in the docker logs for the bridge

[email protected] start /usr/src/app
node server.js

info: Starting SmartThings MQTT Bridge - v3.0.0
info: Loading configuration
info: Loading previous state
info: Perfoming configuration migration
info: Saving current state
info: Connecting to MQTT at mqtt://192.168.1.97:1883
info: Configuring autosave
info: Configuring API
info: Listening at http://localhost:8080
info: Saving current state
info: Subscribing to smartthings/Garage Door/door/cmd, smartthings/Garage Door/door/set_state, smartthings/Contacts/notify/cmd, smartthings/Contacts/notify/set_state, smartthings/System/notify/cmd, smartthings/System/notify/set_state, smartthings/Garage Workbench Light/switch/cmd, smartthings/Garage Workbench Light/switch/set_state, smartthings/Kitchen Sink/switch/cmd, smartthings/Kitchen Sink/switch/set_state, smartthings/OutDoor_Lights_1/switch/cmd, smartthings/OutDoor_Lights_1/switch/set_state, smartthings/Christmas Tree/switch/cmd, smartthings/Christmas Tree/switch/set_state, smartthings/Attic Fan/switch/cmd, smartthings/Attic Fan/switch/set_state, smartthings/Desk/switch/cmd, smartthings/Desk/switch/set_state
info: Saving current state
info: Saving current state
info: Subscribing to smartthings/Garage Door/door/cmd, smartthings/Garage Door/door/set_state, smartthings/Contacts/notify/cmd, smartthings/Contacts/notify/set_state, smartthings/System/notify/cmd, smartthings/System/notify/set_state, smartthings/Garage Workbench Light/switch/cmd, smartthings/Garage Workbench Light/switch/set_state, smartthings/Kitchen Sink/switch/cmd, smartthings/Kitchen Sink/switch/set_state, smartthings/OutDoor_Lights_1/switch/cmd, smartthings/OutDoor_Lights_1/switch/set_state, smartthings/Christmas Tree/switch/cmd, smartthings/Christmas Tree/switch/set_state, smartthings/Attic Fan/switch/cmd, smartthings/Attic Fan/switch/set_state, smartthings/Desk/switch/cmd, smartthings/Desk/switch/set_state

I can actually see what looks like proper communications from Smartthings to the Bridge and from HA to the Bridge but something is not letting the communications go all the way from HA to ST. If anyone has any Ideas it would be very appreciated. I solved most of my issues thus far and frankly I am stuck on this last little bit.

--------------- Bridge Config ----------------
mqtt:
host: mqtt://192.168.1.97:1883
preface: smartthings
state_read_suffix: state
state_write_suffix: set_state
command_suffix: cmd
username: user
password: pass
port: 8080

--------------- Hassio Config ----------------
mqtt:
broker: '192.168.1.97'
keepalive: 60
port: 1883
client_id: HA-MQTT
username: user
password: pass
discovery: true
discovery_prefix: smartthings

[JohanLeirnes]

This is the exact same issue I am having. Maby Samsung changed something so the smartapp cannot send the command that is receives from mqtt to the smartthings hub.

#184

[JohanLeirnes]

I can add that i have had this smartapp running for the past year and a half without issue and now suddenly it stopped working.

[stjohnjohnson]

Usually when this happens, the IP/MAC address is wrong. I’m afraid I don’t know what else could be causing this.

On Sun, Jan 13, 2019 at 15:26 Johan Lindström ***@***.***> wrote: I can add that i have had this smartapp running for the past year and a half without issue and now suddenly it stopped working. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAl98cvsg2B4OG0NPX38bCa4bThElPEAks5vC8CmgaJpZM4ZnTwh> .

-- - St. John

[stjohnjohnson]

In your logs, I don’t see any messages from MQTT to the bridge. Also include your device and smart app logs. On Sun, Jan 13, 2019 at 19:24 St. John Johnson <[email protected]> wrote:

Usually when this happens, the IP/MAC address is wrong. I’m afraid I don’t know what else could be causing this. On Sun, Jan 13, 2019 at 15:26 Johan Lindström ***@***.***> wrote: > I can add that i have had this smartapp running for the past year and a > half without issue and now suddenly it stopped working. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#188 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAl98cvsg2B4OG0NPX38bCa4bThElPEAks5vC8CmgaJpZM4ZnTwh> > . > -- - St. John

-- - St. John

[JohanLeirnes]

Here i have an example.

The first is a incoming message from Home assistant via MQTT to the bridge. It received the package as seen in the log but the light did not turn on.

The second and third message is me turning on and off the light from the Smartthings app.
These changes appears in the mqtt stream and in Home Assistant.��

Has there been a change in what topic is used for cmd?

0|smartthi | info: Incoming message from MQTT: smartthings/Taklampa pannrum/switch/cmd = on
0|smartthi | info: Incoming message from SmartThings: smartthings/Taklampa pannrum/switch/state = on
0|smartthi | info: Incoming message from SmartThings: smartthings/Taklampa pannrum/switch/state = off

[JohanLeirnes]

If i check live logging on the smartthings ide i see nothing when I send messages via MQTT. The only thing related to the brigde is data sent from smartthings to the brige (notifications).

And those work.

[stjohnjohnson]

Hmm, very strange. I don't think anything has changed. Did you get a new version of the container or is the the same as before?

[stjohnjohnson]

You should try to resave the settings in the smartthings app and device

[YellowGTO]

I have this exact same issue. Because I had to nuke my entire ST and HA setup last time, I've installed Hass.io in a hypervisor and have been taking snapshots along the way. I restored a working configuration after it died this time and it was still dead. I was able to get this working again by going to marketplace > SmartApps > and creating a new automation app and readding all the lights.

[JohanLeirnes]

Is the smartapp the thing that is telling Smartthings to command a device to do something? I will try to add a new smartapp and see if that fixes it.

[JohanLeirnes]

I've removed the old Smartapp and added it again but still same error for me.

I can see that the bridge receives the mqtt message but it does not seem to relay it to the Smartthings hub.

[YellowGTO]

I've removed the old Smartapp and added it again but still same error for me.

I can see that the bridge receives the mqtt message but it does not seem to relay it to the Smartthings hub.

So, I just spent another dozen hours battling this issue when it happened again.

1. Try this. ST app> Automation > Smartapps > Select your bridge and delete. (all bridges)

2. ST app > Marketplace > My Apps > MQTT bridge.
   Select 1 smart switch for testing, go to the bottom name it something and connect it to your hub.

3. Open the bridge in HA. Cycle the power from you switch and refresh the log.
   If you see the device state change then try controlling the light from HA.

Note:

1. can't have too many devices on one bridge (ST app side). I have a levels bridge and a switch bridge with the respective devices connected. When I add all 33 of my devices to 1 bridge it will eventually stop working correctly, this last problem I lost dimmable functionally after a few hours.

2. Solid way to check the correct mac is set in ST. Ping the MQTT bridge then arp -a and copy the mac for the IP.

[JohanLeirnes]

hmmm that was it. when i only add a switch i can control it.

So there is a maximum number of devices this smartapp can handle.

[JohanLeirnes]

@stjohnjohnson reducing the number of devices on the bridge seem to fix the problem. Any idea why this is?

[YellowGTO]

No idea. That took me at least 30 hours and 8 jillion rollbacks to figure out though lol.

[stjohnjohnson]

My only thought could be some payload limit on express or smart things side.

On Thu, Jan 24, 2019 at 20:07 YellowGTO ***@***.***> wrote: No idea. That took me at least 30 hours and 8 jillion rollbacks to figure out though lol. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAl98R_gGHcLDyLzDGJ-4RhT57fmmPyAks5vGoMLgaJpZM4ZnTwh> .

-- - St. John

[moishap]

In my case, running homeassistant, mosquitto and the bridge on the same host, I could read the states and sensors of SmartThings from Homeassistant / MQTT, but I could not trigger the ST switches. I tracked it down to mqtt-bridge giving me the duplicate subscriptions (and I think I just saw the PR for it)

info: Subscribing to smartthings/Button/battery, smartthings/Button/battery, smartthings/Motion/battery, smartthings/Motion/battery, smartthings/ZXT120/battery, smartthings/ZXT120/battery, smartthings/Button/button, smartthings/Button/button, smartthings/ZXT120/coolingSetpoint, smartthings/ZXT120/coolingSetpoint, smartthings/ZXT120/heatingSetpoint, smartthings/ZXT120/heatingSetpoint, smartthings/Motion/motion, smartthings/Motion/motion, smartthings/Contacts/notify, smartthings/Contacts/notify, smartthings/System/notify, smartthings/System/notify, smartthings/Intermatic/switch, smartthings/Intermatic/switch, smartthings/Sonoff/switch, smartthings/Sonoff/switch, smartthings/ZXT120/switch, smartthings/ZXT120/switch, smartthings/Button/temperature, smartthings/Button/temperature, smartthings/Motion/temperature, smartthings/Motion/temperature, smartthings/ZXT120/temperature, smartthings/ZXT120/temperature, smartthings/ZXT120/temperature, smartthings/ZXT120/temperature, smartthings/ZXT120/thermostatFanMode, smartthings/ZXT120/thermostatFanMode, smartthings/ZXT120/thermostatMode, smartthings/ZXT120/thermostatMode, smartthings/ZXT120/thermostatOperatingState, smartthings/ZXT120/thermostatOperatingState, smartthings/ZXT120/thermostatSetpoint, smartthings/ZXT120/thermostatSetpoint

but not actually subscribing with mosquitto. I figured that string is way too long. I created multiple SmartApps on my Android ST - one app for motion sensor, one for switches, etc and subscriptions now being sent out and brifge is "open" in both directions now :-)

[iprak]

@moishap I not using HASS but instead directly interacting with ESP8266 devices (Espurna firmware). I do not have read/write suffixes defined and noted duplicate subscriptions which I called out in #191. The read/write suffixes are not defined by default so you might seeing the same issue.

[rwarner]

I know this is almost a year old, however I was doing some network reconfiguration at home and ran into this same issue of one-way traffic only occurring from ST->HASS(Mqtt-broker)

I ended up looking at this for a solid multiple days and I think I ended up figuring out my solution and thought I would add in my experience:

I ended up setting up different VLANs on my network recently (Management / IoT / Guest / Main / etc..) After doing so and changing IPs and such, I could not for the life of me get the Smart Things hub to execute any commands via the MQTT bridge. Everything would work from ST -> HASS but not the other way around HASS -> ST. Everything always seemed to lead back to the Mac / IP address. Looking into obtaining the mac address via "arp" I discovered that ARP only works on the local subnet (from my limited google knowledge). I changed the ST hub over to the same subnet as my HASS / MQTT-broker instance and it worked.

I can only assume the ST hub MAC address verification relies perhaps on something similar or exactly the same as ARP to verify the message. This was blocking all my communication due to it being on a different subnet.

Hope this helps someone... I now have a headache.