MQTT and Insteon - continuous commands sent

I am trying to connect OH2 to Mosquitto to take commands and activate Insteon devices. I am able to trigger actions from a remote app by writing commands to a topic, and OH will see that, and then trigger the switch to turn on. When I trigger it externally, it updates the appropriate topics, and when I trigger it locally, it does the same - so it is working…

The issue I have is that OH is continuously sending the “ON” command after the initial state change. I have checked - I am pretty sure that is not the expected behavior.

Here is the OH switch definition (line breaks are from me, just to ease reading in this forum)

 // Office light 
Switch	officeLight	"Office Light"	
{mqtt=">[mqtt:/myhouse/basement/office/switch1/state:state:OFF:default],
>[mqtt:/myhouse/basement/office/switch1/state:state:ON:default],
<[mqtt:/myhouse/basement/office/switch1/command:command:default]",
insteonplm="1b.8e.5b:F00.00.02#switch"}

Here is my services/mqtt.cfg file:

mosquitto.url=tcp://localhost:1883
mosquitto.user=redacted
mosquitto.pwd=redacted
mosquitto.qos=1
mosquitto.retain=false

And here is the configuration from the remote application (Home Assistant)

- platform: mqtt
  name: testSwitch
  state_topic: "/myhouse/basement/office/switch1/state"
  command_topic: "/myhouse/basement/office/switch1/command"
  payload_on: "ON"
  payload_off: "OFF"
  optimistic: false
  qos: 0
  retain: false

Here is a sample of the logfile showing the frequency of re-sending the “ON” state (actually, it is the last published state, so if i publish OFF, it repeatedly sends OFF)

2017-07-24 08:57:06.070 [INFO ] [onplm.internal.device.MessageHandler] - SwitchRequestReplyHandler: set device 1B.8E.5B to ON
2017-07-24 08:57:11.084 [INFO ] [onplm.internal.device.MessageHandler] - SwitchRequestReplyHandler: set device 1B.8E.5B to ON
2017-07-24 08:57:16.125 [INFO ] [onplm.internal.device.MessageHandler] - SwitchRequestReplyHandler: set device 1B.8E.5B to ON
2017-07-24 08:57:21.078 [INFO ] [onplm.internal.device.MessageHandler] - SwitchRequestReplyHandler: set device 1B.8E.5B to ON
2017-07-24 08:57:26.131 [INFO ] [onplm.internal.device.MessageHandler] - SwitchRequestReplyHandler: set device 1B.8E.5B to ON
2017-07-24 08:57:31.132 [INFO ] [onplm.internal.device.MessageHandler] - SwitchRequestReplyHandler: set device 1B.8E.5B to ON
2017-07-24 08:57:36.135 [INFO ] [onplm.internal.device.MessageHandler] - SwitchRequestReplyHandler: set device 1B.8E.5B to ON
2017-07-24 08:57:41.122 [INFO ] [onplm.internal.device.MessageHandler] - SwitchRequestReplyHandler: set device 1B.8E.5B to ON
2017-07-24 08:57:46.124 [INFO ] [onplm.internal.device.MessageHandler] - SwitchRequestReplyHandler: set device 1B.8E.5B to ON
2017-07-24 08:57:51.128 [INFO ] [onplm.internal.device.MessageHandler] - SwitchRequestReplyHandler: set device 1B.8E.5B to ON
2017-07-24 08:57:56.128 [INFO ] [onplm.internal.device.MessageHandler] - SwitchRequestReplyHandler: set device 1B.8E.5B to ON

I think it is related to the QOS setting, but I am pretty new to this so any guidance would be appreciated.

Thanks!

Bob

That’s my guess too. You have one side configured with qos=1 and the other side is qos=0. Did you configure your broker resend interval to 5 seconds (Mosquitto defaults to 20 seconds)?

I left the default mosquito settings in place, and I don’t have any other times defined anywhere, except in the PLM polling interval to 300 (but this is polling the PLM, and should not have anything to do with the broker, at least in my thought process - which could very well be wrong).

My thought process is that the app uses QOS 0 - so it should write it only once. Since it is written only once, it should not trigger the ON command again from the MQTT client on OH. When I subscribe to the same topic with mqtt-spy, the topic does not update after the expected change, so there is no apparent-to-me reason for OH to trigger the ON message again…

I am sure that there is something i am missing here, and it is clearly noob related, but i feel like I am TTHHIISSS close to getting it right :slight_smile:

If I understand correctly, you are using OH to control Insteon devices from HA via MQTT? HA->MQTT->OH->InsteonPLM->Device

QOS settings shouldn’t cause an issue, even if they are missmatched. The client’s QOS settings are what is used.
Are you seeing repeated entries in your event log for the “officelight” switch.

BTW you just totally blew my mind with the multi binding linking on your item. Apparently I’ve never read that far down the documentation. :grin: