Announcement

Collapse
No announcement yet.

MQTT Plug-in (by Dzjee) v1.5

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • MQTT Plug-in (by Dzjee) v1.5

    I've been using this plug-in for a while now and it seems to work fine except... there is a delay between a device changing state and the plug-in publishing to the broker.

    So, if in Homeseer I setup a virtual device and give it On and Off and then in the Plug-ins/MQTT/Publish I setup that device to publish a topic and tick value then on device change the plug-in publishes it to the broker. Simple.

    I've setup verbose debug on the broker so I can see the publish from Homeseer but the publish can take anything from 15 seconds to never to reach the broker.

    IF I shutdown and restart the plug-in or go into the plug-ins/MQTT/control and manually publish something (anything) then the plug-in will work just fine for a while but after a period its back to delay or no-show.

    Anyone got any idea's?

  • #2
    I do not know how this plugin handles value changes. McsMQT plugin uses the callback from HS3 so publishing should be almost instantaneous

    Comment


    • #3
      Originally posted by Michael McSharry View Post
      I do not know how this plugin handles value changes. McsMQT plugin uses the callback from HS3 so publishing should be almost instantaneous
      I'm going to have a look at that plug-in again, but from memory is wants to create its own devices and doesn't allow me to just link a topic to a devices value or status.

      And as a side, shouldn't MQTT and CoAP for that matter be natively supported?
      Last edited by GEN; February 11th, 2018, 02:46 PM.

      Comment


      • #4
        mcsMQTT discovers all messages that have been published at the selected broker and you have the ability to "A"ccept any (or none) of these to be mapped to HS3 devices with a checkbox entry. It is more of a GUI interface while with the other MQTT plugin you need to enter the text of a published message for a HS3 device to be created.

        HS3 was around before MQTT. We cannot expect HST to support every protocol that surfaces. It started with X10 as its preferred protocol and now has moved to ZWave with the general model of others being supported by third parties.

        Comment


        • #5
          Originally posted by Michael McSharry View Post
          mcsMQTT discovers all messages that have been published at the selected broker and you have the ability to "A"ccept any (or none) of these to be mapped to HS3 devices with a checkbox entry. It is more of a GUI interface while with the other MQTT plugin you need to enter the text of a published message for a HS3 device to be created.
          I've spent a few hours with mcsMQTT this morning and I still cannot bend it to my will. Initially I couldn't get it to successfully authenticate with Mosquitto so I turned auth off which is ok for testing.

          Next, my requirement is simple, a HS device that I can change its deviceString from OFF to ON (value 0 to 1) and have that deviceString published to the topic of my choice.

          In the mcsMQTT Config page I can add a device at the bottom with the correct cmnd/ topic and that creates me a device in HS. I cannot however control that device in HS via the web interface, and if I change it via something like hs.CAPIControlHandler(hs.CAPIGetSingleControl(74,true ,"off",false,true)) HS shows me the change but nothing goes anywhere via MQTT.

          So if there is a quick start guide for getting mcsMQTT working with a simple virtual device that publishes on change then please point it out and I'll give it another shot?

          Otherwise its back to MQTT which does exactly what I want just not all the time.

          Comment


          • #6

            Comment


            • #7
              Ahh, that makes more sense now, I can see how that's should work.

              In the meantime, and being frustrated with not being able to dig into what's causing the delays with the MQTT plugin I just wrote my own. It was good to code some vb.net again as its been a while but since the scripting is vb it seems like a good idea. I used "Device_Type_String" in a virtual device to set "MQTT:cmnd/sonoffsw1/POWER1" and enumerate devices in InitIO looking for MQTT: in the device_type_string. If there's any reason why I shouldn't be using device_type_string then please let me know? Then just callback.registerEventCB on value change and catch our MQTT devices ByRef in HSEvent. The MQTT part took the longest as I'd not done anything with sockets for a while. Its really dirty and only works with ON and OFF (isOn) but its works for now.

              I'm still going to give mcsMQTT another shot though because its clearly better, just not today but at the weekend when there's more time.

              I really appreciate all the help, its good to know its there when needed.
              Thanks
              Rich

              Comment


              • #8
                My memory is that device_type_string has no intrinsic purpose other than sorting for display. My plugins have used it to distinguish devices in the plugin. There are no HS control functions that use it. If I recall correctly this is set to MQTT in 'mcsMQTT'

                Comment


                • #9
                  Can i control existing devices

                  How can i control existing devices. When i subscribe to something it creates a new device.

                  I have lots of virtual devices set up that i used to control a different way (such as ifttt), but now i want to control them using MQTT

                  Is there any way to change the device reference to an existing device?

                  Comment

                  Working...
                  X