Lights randomly turn on and off

[hoomanb]

When I have the bridge running on my Raspberry pi lights turn on and off randomly.
For example I turn a light on via the Smartthings app then it turns off after a few minutes.
Or sometimes lights just go on automatically.

Notes:

1. I don't have ANY automations running in Home Assistant OR Smartthings for those lights.
2. This ONLY happens when the bridge is running.
3. I have lights that have MQTT (and used directly by HA but also set up in Smartthings via different protocols) - They also turn on and off randomly when the bridge is running.

[finnysamuel]

I upgraded my Python to 3.5 yesterday. From yesterday, this happens to me too.
Logs show:
info: Incoming message from SmartThings: smartthings/Stair Light/switch/state = off

I also see this message for my locks:
info: Skipping duplicate message from: smartthings/Front Door/lock/cmd = locked

[hoomanb]

I am running Python 3.5 too (a fresh install of of both Hassbian and Hass.io).

[finnysamuel]

I changed the value of 'retain' to false in my configuration. And also reinstalled the smartthings-mqtt-bridge in my pi. Did not help

[hoomanb]

Same here. I tried a number of configurations including retain false.

[finnysamuel]

I think I just found a way to reproduce the issue. This is the scenario in my GE Z-Wave Dimmer Switch:

• MQTT Light state is initially ON
• An automation runs to change the brightness to 100 (while the light is ON)
  data:
  entity_id: light.stair_light
  brightness: 100
• I manually switch off the light from the light switch.
• After sometime the light turns on automatically, as MQTT is receiving a "rogue" on command
  info: Incoming message from MQTT: smartthings/Stair Light/switch/cmd = on

(I believe - not tested - the rogue command stops if I switch off the light from home-assistant)

[hoomanb]

I couldn't 100% verify this either - but it does seem the command stops if I only handle the light from home assistant.
But I do wanna use the SmartThing app or the hardware switch on the light so couldn't rely on that solution.

[finnysamuel]

And it always happens just after the log for subscribing to the topics!!
info: Subscribing to smartthings/Basement/temperature/cmd, smartthings/Ho.....

[finnysamuel]

https://community.home-assistant.io/t/smartthings-mqtt-bridge/269/148 - Seems that others also had the issue.. But not sure if they tried with the automation combination..

[jlareau]

I was experiencing similar issues, where every fifteen minutes some of my lights would change their states all by themselves. After looking through the code for my MQTT Bridge in the Smart App, I realized that there was a method named installed() which was setting up a 15 minute timer that called the initialize() method over and over. Initialize is what spawns the "subscribing to topics" message that causes Home Assistant to receive rogue MQTT cmd topic messages, thus turning on or off your lights unexpectedly. I commented out the line of code that started the timer (since initialize() was being called on its own in that same method anyway), and I tried several times to restart the hub / home assistant, but I kept seeing initialize() get called every fifteen minutes anyway. Eventually, after carefully reading the SmartThings API docs, I discovered that the installed() method is only ever called once, when you first install the smart app on your phone (or through the website). So I had to uninstall the smart app and reinstall it (kind of a pain because I had to go back through and subscribe all my devices again) but I stopped seeing the "Subscribing to..." message after an initial one. As far as I can tell, there are no adverse affects, and I suspect that the reason the original author of the bridge put that in there was for an automatic subscription feature, whereby any new devices you added would be picked up by the bridge after fifteen minutes or so. Now, let's say you do have to add new devices...you can trigger the "Subscribing..." message just by saving any changes to the bridge via the smart app. Of course, this does then cause the rogue MQTT commands again, so this is more of a band-aid than a fix for whatever the underlying issue is with the initialize() code. I'm guessing that there may have been a change to Home Assistant recently (sometime after v0.56) because I used to run this bridge just fine prior to upgrading to v0.60, or possibly it's something with running Hass.IO because before I used to run Home Assistant via Hassbian and it worked fine then too. Hope this makes sense and helps someone.

[AYapejian]

It was awhile back now but I believe @jlareau ended up exactly where I did. When I removed the repetitive subscribe issue went away but I also saw that some updates I'd never get or would take days to show up ( battery / temp if I remember correctly ). The Smartthings platform is very limiting ( and a large disappointment imho ) but this project is a great bandaid for those stuck with the platform.

[AYapejian]

Oh, and to be a little more constructive, I was skimming one of the openhab smartthings projects which is largely similiar to this solution. However they seem to implement some state calls as well, could probably poll for state and post to mqtt as a work around or something like that on initial thought. FYI for those interested in looking into it: https://github.com/BobRak/OpenHAB-Smartthings/blob/master/org.openhab.binding.smartthings/src/main/smartthings/DeviceHandlers/OpenHabDeviceHandler.groovy

[vladtepz]

I've had this issue too, I believe it only happens if you use the state/cmd/set_state suffixes.

My workaround was to not use the suffixes and has been working as intended.

Don't get me wrong, I'd rather use the suffixes, so I hope this can be fixed, just figured I'd mention it as a quick workaround.

[PhilRW]

I'm having the same issues. Here's what I did and so far it seems to be working for me (but time will tell):

• Made this change to the code (I closed the PR but could repoen it if it works for others).
• Used this utility to clear out the smrtthings/# topic

It should be noted that I am using retain: false and separate state and cmd topics suffixes in my mqtt-bridge config.yml

[GeorgeIoak]

I'm experiences the "random" light on/off issues as well. My lights have dimmers and I'm what looks like an incorrect level retained in the bridge. I currently have retain: true but just to be clear right now I don't even have HA running so this is just communication between the Bridge and SmartThings

info: Subscribing to smartthings/Porch RGB Strip Lights/hue/cmd, smartthings/Porch RGB Strip Lights/hue, smartthings/Por
ch RGB Strip Lights/level/cmd, smartthings/Porch RGB Strip Lights/level, smartthings/Kitchen Table Light/level/cmd, smar
tthings/Kitchen Table Light/level, smartthings/Kitchen Table Light/switch/cmd, smartthings/Kitchen Table Light/switch, s
martthings/Porch RGB Strip Lights/switch/cmd, smartthings/Porch RGB Strip Lights/switch, smartthings/Contacts/notify/cmd
, smartthings/Contacts/notify, smartthings/System/notify/cmd, smartthings/System/notify, smartthings/Porch RGB Strip Lig
hts/saturation/cmd, smartthings/Porch RGB Strip Lights/saturation, smartthings/Porch RGB Strip Lights/color/cmd, smartth
ings/Porch RGB Strip Lights/color
info: Incoming message from MQTT: smartthings/Kitchen Table Light/level/cmd = 74
info: Skipping duplicate message from: smartthings/Kitchen Table Light/level/cmd = 74
info: Incoming message from MQTT: smartthings/Kitchen Table Light/level = 66
info: Incoming message from MQTT: smartthings/Kitchen Table Light/switch/cmd = on
info: Skipping duplicate message from: smartthings/Kitchen Table Light/switch/cmd = on
info: Incoming message from MQTT: smartthings/Kitchen Table Light/switch = on
info: Skipping duplicate message from: smartthings/Kitchen Table Light/switch = on
info: Incoming message from MQTT: smartthings/Porch RGB Strip Lights/switch/cmd = on
info: Incoming message from SmartThings: smartthings/Kitchen Table Light/level/state = 66

@PhilRW I'm going to try your change but wanted to confirm first. You have 3 changes:

• Modify the server.js file
• Clear out the smartthings/# topic
• Set retain: false

[AYapejian]

@PhilRW Thanks for the update, I've not looked at this much really since my last comment as I'm almost off the Smartthings platform. Just a question to throw out there though. Why does the bridge even need an internal state machine? It seems to me that HA should worry about handling cases where turn_on is sent to an already on device and the bridge should simply shuffle commands back and forth. Only reason I can think of is to avoid network congestion but I find it hard to believe anyone in a home setting would even be coming close to some sort of network bottleneck.

[cmconner156]

Thanks for your findings PhilRW, testing now, but I'm hopeful this gets rid of the ghost in my home automation!

[cmconner156]

@PhilRW , just curious, how do you handle restart state? Since I implemented this workaround, when I restart HomeAssistant, everything is off, so I lose state. Right now I created a python script to post everything from state.json to MQTT bridge, but I feel like there has to be a better way.

[PhilRW]

At the moment I don’t handle it. Perhaps we should add this.

[kevbry]

I know this thread is long past its best before date, but is anyone who's having this problem using Lutron dimmers/switches? While I was testing out some integrations tonight I noticed that every 10-15 minutes all my Lutron switches will replay all of their status changes from the previous 10-15 minutes. It doesn't actually change the state of the switch, it just replays all of the status change events in order, which end up getting sent in to the bridge if that switch is in your mqtt config. None of my other switches or zigbee lights do this, so I assume it's some kind of weirdness in the Lutron smart app.

[hoomanb]

I'm not using Lutron. So I don't think it's related to Lutron specifically.

[InstigatorX]

@cmconner156 Can you post the python script you refer to?

[Siege36]

I'm having this issue as well. Noticed it happens every 15 minutes, it repeats the last message sent through HA. any solutions so far? having my garage door open after I shut it is not ideal.