Bridge receives command, but sometimes does not relay the message to Smartthings

[almostserious]

Everything is working fine. I can control devices from Smartthings via MQTT and also grant access to MQTT devices to Smartthings.

However, sometimes the Bridge receives a command from MQTT:
info: Incoming message from MQTT: smartthings/XXX/XXX = ZZZ

But the event seems not to be transmitted to smartthings as the same message from ST never arrives:
info: Incoming message from SmartThings: smartthings/XXX/XXX = ZZZ
Also the device state will not change.

I am using the QoS Level 2.
I was under the impression that this means that MQTT will wait for Smartthings to send a "received package". Or is it just that it waits until my MQTT Server sends this package? And it doesnt have anything to do with ST?

[stjohnjohnson]

It doesn't send duplicate messages, so if the state is already at that value, it won't send it again. just a guess

[almostserious]

In this case it was on a different state. Usually if its the case that its the same value i also get the message of skipping duplicate value. This is not the case here. Maybe it has to do with a timeout.. as 2 states are updates simultaneous. I added a delay and will test if that helps.

[vnguyen972]

I'm having the same issue... I can switch on a switch in Smartthings app but I cannot switch it on my sending a command via MQTT even though I see the message received by the bridge.
info: Incoming message from MQTT: smartthings/Theater Room Dimmer/switch = on
...but the switch doesn't change state (to ON)

Any pointer?

[airdrummingfool]

I've been seeing this issue recently as well. It seems to be pretty random; I can successfully toggle a switch multiple times in a row, and then one toggle just doesn't make it through. Another attempt a couple seconds later works fine.

Sometimes (maybe 20% of the time) I'll see the following error in the ST-MQTT-Bridge logs after a the bridge fails to send a message along:

error: Error from SmartThings Hub: Error: read ECONNRESET
error: {
    "errno": "ECONNRESET",
    "code": "ECONNRESET",
    "syscall": "read"
}
error:

[mbaran5]

I've been seeing this issue recently as well. It seems to be pretty random; I can successfully toggle a switch multiple times in a row, and then one toggle just doesn't make it through. Another attempt a couple seconds later works fine.

Sometimes (maybe 20% of the time) I'll see the following error in the ST-MQTT-Bridge logs after a the bridge fails to send a message along:

error: Error from SmartThings Hub: Error: read ECONNRESET
error: {
    "errno": "ECONNRESET",
    "code": "ECONNRESET",
    "syscall": "read"
}
error:

I have been getting this for about two months now. The only resolution is a hub reboot. The mqtt-bridge will run fine until a point where it doesnt. I check the PM2 logs and start seeing this error.

[airdrummingfool]

My problem went away on its own a few months ago, but returned a few days ago. It looks like the latest firmware update broke the communications mechanism that this bridge (and others like it) used to send updates to the hub.

Here's the error I get now:

error: Error from SmartThings Hub: Error: socket hang up
error: {
    "code": "ECONNRESET"
}
error:

A SmartThings employee posted that they were aware of the issue and working on it, and in the meantime proposed a workaround:

In the interim, a temporary fix is to pull the Ethernet cable from the back of the hub, leaving it unplugged for about 30 seconds (long enough for the status LED to turn either blinking or solid blue), then plugging the cable back in. For V3 hubs on Wi-Fi a reboot of your router/AP should do the trick. This will force a disconnect/reconnect to the SmartThings cloud and you should be able to receive LAN traffic on port 39500.

Unfortunately, this fix didn't work for me. Someone else suggested changing the IP of the ST hub on the local network, then unplugging the LAN cable, waiting 30 seconds, plugging it back in, then restoring the original IP, unplugging the LAN cable again for 30 seconds. This also didn't work for me. Update: I sent another command and the hub started responding, so this fix seems to work.