No announcement yet.

Cant toggle a device via MQTT with identical payloads (flip-flop event)

  • Filter
  • Time
  • Show
Clear All
new posts

  • Cant toggle a device via MQTT with identical payloads (flip-flop event)

    Folks, this has me a tad baffled but I'm seeing something interesting. If I send an identical topic and payload to toggle a device, I see the first event occur but never the 2nd and subsequent one. The events below:

    topic: stat/superhouse/buttons payload 20:34

    If topic received and the output is off then turn the output on. - works fine

    topic: stat/superhouse/buttons payload 20:34

    If the topic is received and the output is on (from the above on event) then turn it off - doesnt work.

    I notice in MQTT plugin for the topic I see the updated timestamp but it wont run the off event if the on event has run. If I change the payload and send the different payload the lights turn off (the event runs ok). I want to do this as I want HS to track the output status, and not the MQTT device hence the toggle event (with same payload)...

    Any idea ?


    oops, event screen grab below

  • #2
    Click image for larger version

Name:	mqtt_buttons.JPG
Views:	19
Size:	125.1 KB
ID:	1245133


    • #3
      I am trying here to replicate sort of your scenario. Here though using a Sonoff SV ESPURNA 1.13.1 firmware and related to my under the counter kitchen LED lamps.

      Using only Mosquitto to send commands and receive status via mcsMQTT

      I can sort of only see what I am doing looking at the debug log...(console in Tasmota)

      If I toggle a lamp then it goes on or off sending this.

      Note here use the mosquitto command set instead of cmnd and no Arduinio plugin commands.

      Toggle OFF

      Sub: KitchenLEDs/data:relay/0
      Toggle command ==> KitchenLEDs/relay/0/set

      [813001] [MQTT] Received KitchenLEDs/relay/0/set => 2
      [813010] [MQTT] Sending KitchenLEDs => 0 (PID 1471)
      [813023] [MQTT] Publish ACK for PID 1471
      [813042] [MQTT] Received KitchenLEDs => 0
      [813112] [MQTT] Sending KitchenLEDs/data => {"relay/0":"0","time":"2018-09-02 06:42:36" *
      [813125] [MQTT] Publish ACK for PID 1472
      [005882] [NTP] UTC Time : 2018-09-02 11:45:49
      [005884] [NTP] Local Time: 2018-09-02 06:45:49
      [008952] [MQTT] Sending KitchenLEDs/status => 1 (PID 1473) **
      [008958] [MQTT] Publish ACK for PID 1473
      [009057] [MQTT] Sending KitchenLEDs/data => {"app":"ESPURNA","version":"1.13.1","board":"ITEAD_SONOFF _SV "06:45:52","
      [009088] [MQTT] Publish ACK for PID 1474

      Toggle ON

      [292533] [MQTT] Received KitchenLEDs/relay/0/set => 2
      [292537] [RELAY] #0 scheduled ON in 0 ms
      [292540] [RELAY] #0 set to ON
      [292544] [MQTT] Sending KitchenLEDs => 1 (PID 1475)
      [292553] [MQTT] Publish ACK for PID 1475
      [292645] [MQTT] Sending KitchenLEDs/data => {"relay/0":"1","time":"2018-09-02 06:50:35" *
      [292656] [MQTT] Received KitchenLEDs => 1
      [292671] [MQTT] Publish ACK for PID 1476
      [308960] [MQTT] Sending KitchenLEDs/status => 1 (PID 1477) **
      [308969] [MQTT] Publish ACK for PID 1477
      [309066] [MQTT] Sending KitchenLEDs/data => {"app":"ESPURNA","version":"1.13.1","board":"ITEAD_SONOFF _SV "
      [309096] [MQTT] Publish ACK for PID 1478

      IE: Above the status doesn't change when toggling such that I cannot utilize a variable to timestamp the change?

      I can read the data sentence that shows the change with a time stamp.

      Not sure though if I am totally understanding what you are doing relating to the same timestamp payload of 20:34.

      Is this a dynamic or static payload?


      Click image for larger version  Name:	association.jpg Views:	1 Size:	45.0 KB ID:	1245143

      toggle on

      Click image for larger version  Name:	toggle.jpg Views:	1 Size:	21.4 KB ID:	1245140

      toggle off

      Click image for larger version  Name:	toggleoff.jpg Views:	1 Size:	18.8 KB ID:	1245142

      Did a quickie test here. I used the 120 VAC wall switch to power on and off of the Sonoff SV and the LED lamps.

      When I did this to turn on the power and have the relay configured to on when powering up the HS3 variable status did change fine (LED png picture changed and slider changed above).
      Last edited by Pete; September 2nd, 2018, 07:46 AM.
      - Pete

      Auto mator
      Homeseer 3 Pro - (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.4X
      Homeseer Zee2 (Lite) - (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.4X

      X10, UPB, Zigbee, ZWave and Wifi MQTT automation.


      • #4

        I'm sending the exact same topic and payload. 20 is the device ID and 34 is the arduino mega PIN ie: 20:34

        WHen I ground the Mega pin it sends stat/superhouse/buttons 20:34 every time, i see that in the mosquitto broker

        I have the plugin open and watching the received MQTT messages, I see the message via the correct timestamp so I know the plugin is seeing it. It does not run the event. I suspect it has something to do with the topic and payload not changing which is weird but I see the timestamp increment.

        I have tried to toggle an arduino output on another board, wont toggle. I then changed the output to one of my TH-16 sonoff devices, exactly same thing, the event wont run....



        • #5

          That is the issue I had when toggling the Sonoff SV on or off using the ESPURNA 1.13.1 firmware.

          I am sending the same command to toggle the relay.


          and could not create a control button that would change status.

          IE: cannot do a trigger with a status here but can do a trigger with a change in data.

          It shows that it is status is either OFF or DIM and not OFF or ON.


          Reference ID 2320
          Status 0 = OFF
          Value 0 = "LEDs"


          Reference ID 2320
          Status 1 = Dim
          Value 1 = "LEDs"

          So switched to using a "control type" slider for on and off.

          I do not see it change in the status though and cannot utilize that.

          Rather I use the KitchenLEDs/data:relay/0 for status with a time stamp.

          relay is GPIO "0" zero.

          ESPURNA mosquitto read is ==> relay/0:1 or relay/0:0

          Tasmota mosquitto read is Power<x> ==> Show current power state of relay<x> as On or Off

          So this is my event and trigger.

          I use relay 0 with a toggle of 0 or 1.

          Click image for larger version  Name:	sstatus event.jpg Views:	1 Size:	35.9 KB ID:	1245170
          data shows: "relay/0":"1" or "relay/0":"0"

          I only see a mosquitto data change and no mosquitto status change but that is with the ESPURNA 1.13.1 firmware.

          Is this what you are doing?

          Just tested this with the Garage door Sonoff WiFi basic toggling the relay on or off with mcsTasmota firmware and see:

          /GarageDoor1/POWER mosquitto message and an on an off payload.

          cmnd/GarageDoor1/POWER toggles the relay


          /GarageDoor1/POWER reads the relay status

          POWER = relay gpio 0 toggling on and off.

          Click image for larger version  Name:	power.jpg Views:	1 Size:	11.3 KB ID:	1245181
          Last edited by Pete; September 2nd, 2018, 10:53 AM.
          - Pete

          Auto mator
          Homeseer 3 Pro - (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU - Mono 6.4X
          Homeseer Zee2 (Lite) - (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.4X

          X10, UPB, Zigbee, ZWave and Wifi MQTT automation.


          • #6
            Payload 20:34 implies to me that the device type in mcsMQTT is text, but you also have event condition of Off and On. I do not understand the value/status mapping to get On and Off values in the HS device.

            For Text type devices it assess if the payload is numeric and will store that value in DeviceValue, otherwise it will store the value currently in the HS DeviceValue. This allows the event to be triggered based upon receiving text. DeviceLastChange property of the device is updated based upon a payload text change or the MISC property of the device clear for SET_DOES_NOT_CHANGE_LAST_CHANGE

            For Button type devices the plugin stores the payload in DeviceValue and null in DeviceString. Event trigger flag is set. DeviceLastChange property of the device is updated based upon a payload value change or the MISC property of the device clear for SET_DOES_NOT_CHANGE_LAST_CHANGE


            • #7

              Can you provide guidance then, I can code the payload to be whatever it needs to be HOWEVER at this stage the payload will be the same value on each button press as I wanted the remote light controller to not be aware of light state, simple send me a msg when the button is pressed. ie: topic /stat/whatever/button20 payload "press"

              Reading your text above, do I actually need to create a device to receive the topic/payload ? I'm sure I've setup an event that simply receives an MQTT topic and am using an event to toggle a HS device. Ive done this test WITHOUT creating a device for the inbound topic/payload and creating a device to receive the topic, same result.

              Never has the: Do not update device last change timeif device value does not change: been accepted


              • #8
                I thought the trigger was a device change, but looking again I see it is an mcsMQTT receive topic event. In this case mcsMQTT looks for match in topic and payload and does a callback to HS to indicate the event occurred. There is info in the debug log for when the topic matches, the event satisfied both topic and payload conditions and when the event callback is done. HS has no cognizant of why mcsMQTT sent the trigger callback so I do not see why it would ignore the second trigger unless these is is an issue with the AND condition on the event. You can look in the debug log to confirm mcsMQTT is doing its part, but likely is if it is since it is able to trigger one of your events.

                The approach you have used with mcsMQTT event trigger seems to be the best way to do what you want. A work-around approach is to associate the message with a device. Likely the mcsMQTT type will be text. Each time the message is received a value change event trigger will be raised so you should be able to trigger on any change of the device.

                Before going the device route I would look more closely at the AND condition of the event you have setup. It could be that you are not really doing what you need to make this part of the event trigger return a true condition.


                • #9

                  Changed the event:

                  topic: stat/superhouse/button34 with a topic of "press" - this is done with mosquitto_pub on the broker: mosquitto_pub -m "press" -t stat/superhouse/button34

                  with my toggle event it turns the device on but wont turn it off. I also replaced the arduino device test with a virtual device I've just created, same thing.

                  Is there a chance you can create this scenario yourself just to confirm that this should work...? I just cant see why this shouldn't work....


                  • #10
                    I can try to replicate


                    • #11

                      Homeseer version: HS3 Standard Edition (Windows) and your latest plugin


                      • #12
                        I had optimized the event trigger pattern matching, but it failed for the case where the same message parameters occur in multiple events. I removed this optimization in and you should now be able to toggle your device. or wait for it to appear in updater.


                        • #13
                          Thanks Michael, really appreciate the change, works as advised....

                          One question with the plugin and I hope I'm asking it in a precise manner. If I were to write some arduino code and when it connects to the broker and updates its status as connected, what do you think would be the best way to push out all of the output statuses to the topics associated with the device ? Would that be a windows script that would be run on HS when the board sends its connect message to HS (via the broker) ? or could I somehow do this in the plugin ?

                          Hope that makes sense. The arduino plugin does this, when the remote arduino board connects the plugin pushes out configuration and status information.

                          The issue is "state", the input now being the same payload ensure the press button light switch does not need to know state, just thinking now about outputs...

                          Kind Regards..Pete...


                          • #14
                            The purpose of the Retain flag in the MQTT protocol is to assure clients get their subscribed information when they come online. There is a global one on the General Tab and there is a device-by-device override of the global on the Edit tab. The default is for Retain to be false. You will want to set it to true for your desired arduino devices.

                            In essence what is happening is that mcsMQTT will publish a status change with Retain true. If the node that subscribes to this topic is online then the broker will send the status update. If it is not online then the broker will hold the status and deliver it when the node comes online.


                            • #15

                              WHat happens if the topic and payload are received ie: turn GPIO1 on the arduino and the arduino does turn it on.......the arduino drops power and comes back by setting the retain flag on the message it will get the last message that was sent to the topic on restart ?