Announcement

Collapse
No announcement yet.

mcsMQTT Plugin

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Michael

    I've created a device from stat/mqtt/alive

    Seem to have an issue with the device adhering to the checkbox being turned off:

    Do not update device last change time
    if device value does not change:

    I've turned this off and sent the following:

    mosquitto_pub -d -t stat/mqtt/alive -m ping

    If I send it in a minutes time, the timestamp on the web page doesnt change. If I change the payload then it updates the data on the web page fine. I was going to run a crontab on the raspberrypi every 5 mins so I can keep tab of the device being alive. I know you have another way to do it which is fine but curious as to why this is happening ?

    Any ideas ?

    Thanks Pete
    HS 2.2.0.11

    Comment


      #17
      I'm a little stumped as to how to trigger an event from a received MQTT topic. Actually its probably not a topic, its a device I've created as a result of /stat/wemos-sonoff/POWER

      The device on the web page turns on and off fine as I ground the wemos PIN. What I cant seem to work out is how to trigger an event from this.

      What device value is on/off or do I need to define this myself ?

      I've gone into status graphics and set 0 to off and 1 to on....I cant seem to trigger an event from on or off/0 or 1 device status and value....

      Clearly missing something simple....

      Appreciate your guidance
      What is the payload on the Topic /stat/wemos-sonoff/POWER?

      If it is 0/1 then the DeviceValue will change between these two values. If you have status-graphics pairs setup for 0 and 1 values then the Status should show whatever graphics you setup for these two states.

      If it is OFF/ON then the DeviceValue should never change from 0 and the DeviceString will contain the payload.

      HS Events will support a change in DeviceValue. There are 3rd party plugins that will do DeviceString as the trigger.

      There are two things I have been considering. One is the case where non-numeric payloads are received. In this case then look up to see if a status pair has been defined by the user and then store the numeric value if it matches.

      The other is to expand the MQTT trigger to include the payload. This would allow trigger on a message reception based upon a payload for a topic rather than just a topic. This would allow two events to be setup where one is for an ON payload and the other for an OFF payload, as an example.

      I've created a device from stat/mqtt/alive

      Seem to have an issue with the device adhering to the checkbox being turned off:

      Do not update device last change time
      if device value does not change:

      I've turned this off and sent the following:

      mosquitto_pub -d -t stat/mqtt/alive -m ping

      If I send it in a minutes time, the timestamp on the web page doesnt change. If I change the payload then it updates the data on the web page fine. I was going to run a crontab on the raspberrypi every 5 mins so I can keep tab of the device being alive. I know you have another way to do it which is fine but curious as to why this is happening ?

      Any ideas ?
      I was not aware of HS3 providing the setting to control the device last change being used for device last refreshed. I will research the API and honor it in the next plugin update.

      Comment


        #18
        Originally posted by Michael McSharry View Post
        What is the payload on the Topic /stat/wemos-sonoff/POWER?

        If it is OFF/ON then the DeviceValue should never change from 0 and the DeviceString will contain the payload.


        There are two things I have been considering. One is the case where non-numeric payloads are received. In this case then look up to see if a status pair has been defined by the user and then store the numeric value if it matches.

        The other is to expand the MQTT trigger to include the payload. This would allow trigger on a message reception based upon a payload for a topic rather than just a topic. This would allow two events to be setup where one is for an ON payload and the other for an OFF payload, as an example.
        Michael

        OK, payload is ON or OFF, that's what the tasmota firmware sends, hence this is why devicevalue never changes. Understand I could use another plugin but I'd prefer not to as it would then require additional configuration for a single device to enable triggers to occur.

        So to expand the trigger on payload, that is something you would need to code ? I did read your documentation and I see you can trigger on topic but not payload. Is this something you could consider as it would make the triggering of events very simple if we could define the payload and not just the topic. This will make using your plugin with the sonoff tasmota firmware a total breeze to use.

        And thankyou for considering the change in code to honour the API. Again this means I can run a cronjob on the broker and track the "keepalive". I did note you have a trigger option if it doesnt get a message in a self determined timeframe.

        Cheers & regards..Pete
        HS 2.2.0.11

        Comment


          #19
          I made the updates discussed. I do not see the plugin in the updater yet. I have not updated the manual yet either. You can get it at http://mcsSprinklers.com/mcsMQTT_3_0_1_0.zip

          If you have a message received that has case-insensitive OPEN, CLOSED, ON, or OFF as the Payload when the Topic is accepted then the created device will create Device-Value-Graphic pairs and handle OPEN/ON as DeviceValue=1 and CLOSED/OFF as DeviceValue=0. In this case the DeviceString will not be updated and the Status shown will be from the Device-Value-Graphic that is setup. If you want different text or icons then they can be edited. If it not a number and not one of these four then the DeviceValue will not be updated. In the future I think I will expand this to map every text string received on a topic to a unique DeviceValue so they will be treated as an enumeration and DeviceValue changes can be used in events to achieve desired trigger results.

          For other non-numeric payloads the DeviceString will be updated and the Status will show up as the DeviceString. For all others the DeviceString will be cleared. Device Management of Devices can be used to provide suffix, prefix and some other formatting information for Status. For example, a number is treated by default as a Dim level. I change mine to add a suffix (e.g. Minutes) to provide a meaning to the number and remove the Dim prefix.

          DeviceLastChange is now explicitly updated based upon the device's checkbox. It will either update the date on a value change or upon new topic reception based upon the checkbox.

          MQTT Receive trigger how has provisions for the Payload. It likely means that you will need to redefine existing MQTT Receive Trigger Events.
          Last edited by Michael McSharry; December 20, 2017, 11:17 PM.

          Comment


            #20
            This plugin is great!

            How do you do the suffix part? I've been searching through the device config pages, and the plugin and can't find it. I have temperature and humidify values that are coming up as "DIM xx%", for the temperature one I would like to remove DIM and % and add F, for humidity I would like to get rid of the DIM.

            Thanks

            Originally posted by Michael McSharry View Post
            For other non-numeric payloads the DeviceString will be updated and the Status will show up as the DeviceString. For all others the DeviceString will be cleared. Device Management of Devices can be used to provide suffix, prefix and some other formatting information for Status. For example, a number is treated by default as a Dim level. I change mine to add a suffix (e.g. Minutes) to provide a meaning to the number and remove the Dim prefix.

            Comment


              #21
              Another thing I'm noticing tonight. When I set it up to link an existing device to mqtt (selecting A for an existing device) and control the device by turning it on and off, I never see those changes being sent. If I wait a while, apparently the 10 minute timer, the current status at the time is getting sent.

              Thoughts?

              Comment


                #22
                Originally posted by Michael McSharry View Post
                I made the updates discussed.
                Michael

                Stunning.....works exactly as you advised.

                After more tinkering I've simplified my setup even furthur thanks to your work. There is a whole lot more I could write but I'll leave it for now.

                Just did more event testing on incoming payload using a WEMOS to trigger an output on SONOFF Basic, awesome

                Cheers..Pete

                p.s your code is adhering to the API and I'm now getting "ping" updates from the broker via a cronjob :-)
                HS 2.2.0.11

                Comment


                  #23
                  How do you do the suffix part? I've been searching through the device config pages, and the plugin and can't find it. I have temperature and humidify values that are coming up as "DIM xx%", for the temperature one I would like to remove DIM and % and add F, for humidity I would like to get rid of the DIM.
                  From Device Management where all HS3 devices are listed you will see the Status of the device. Note I have last row with STATE:Uptime showing with "Minutes" suffix formatting. Clicking on the STATE:Uptime hyperlink brings up three tabs and the Status Graphics is shown. For this example I used "Minutes" for the suffix, Include Values for the checkbox and specified on decimal places. I also put a Value range, but dont know if that is needed or not.
                  Attached Files

                  Comment


                    #24
                    [qutoe]Another thing I'm noticing tonight. When I set it up to link an existing device to mqtt (selecting A for an existing device) and control the device by turning it on and off, I never see those changes being sent. If I wait a while, apparently the 10 minute timer, the current status at the time is getting sent.[/quote]

                    That should not be the case as the main purpose is to reflect the changes in devices as new messages in MQTT. mcsMQTT looks for all VALUE and STRING changes as part of the HSEvent callback from HS3.

                    I will reconfirm on my side, but it may be helpful to understand the nature of the device that you are using. Can you show the Advanced Tab for the device when it is ON and when it is OFF (or whatever states). I am interested in the Value and String properties.

                    Comment


                      #25
                      Looks like I fat-fingered the HSevent code. Fixed in 3.0.1.1 http://mcsSprinklers.com/mcsMQTT_3_0_1_1.zip to properly handle the event callback.

                      Comment


                        #26
                        Originally posted by Michael McSharry View Post
                        From Device Management where all HS3 devices are listed you will see the Status of the device. Note I have last row with STATE:Uptime showing with "Minutes" suffix formatting. Clicking on the STATE:Uptime hyperlink brings up three tabs and the Status Graphics is shown. For this example I used "Minutes" for the suffix, Include Values for the checkbox and specified on decimal places. I also put a Value range, but dont know if that is needed or not.
                        That is perfect! I wasn't adding a range, so I didn't see the prefix/suffix, working great now!!

                        Thanks.

                        Comment


                          #27
                          Originally posted by Michael McSharry View Post
                          Looks like I fat-fingered the HSevent code. Fixed in 3.0.1.1 http://mcsSprinklers.com/mcsMQTT_3_0_1_1.zip to properly handle the event callback.
                          I updated to 3.0.1.1 and it doesn't seem to be working yet. I'll continue testing though.

                          Thanks for the quick response on it.

                          Comment


                            #28
                            The device is a ZWave device, attached is the advanced paged for off and on

                            Thanks,

                            Dave
                            Attached Files

                            Comment


                              #29
                              There is nothing I can see from your data. What I did was added some debug code around the event processing. After installing http://mcsSprinklers.com/mcsMQTT_3_0_1_2.zip, enable debug on the mcsMQTT setup page. You will find mcsMQTT Debug.txt in the \Data folder. Just run a simple test of toggling the subject device. You can then disable debug and post the file.

                              Comment


                                #30
                                Something else I recognize is not as convenient as desired is how two HS3 Devices are used with one for status and the other for control. In my next update I will let the user specify the Ref property of MQTT control/cmnd Topics. This way one device will be setup based upon a Topic received and then the same Ref can be used when the command topic is entered.

                                With xAP there was more intelligence in the messages so once a device was known to understand xAPBSC schema then mcsXap plugin knew exactly how to setup a single HS Device to have both status and control. With MQTT the user needs to explicitly define the command Topic since standards do not exist for the structure of a command, but at least with this update a single HS3 Device will be able to be use bi-bidirectionally.

                                Comment

                                Working...
                                X