No announcement yet.

mcsMQTT Plugin

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

  • #1) I assume you are trying to associate existing HS Devices with commands published via MQTT. mcsMQTT calls these non-plugin devices and will be showing in a pink on the Association tab. When the Associate checkbox is clicked a blank subscribe and a pre-populated publish text boxes are presented. The subscribe textbox needs to be filled in with the MQTT topic that will cause the HS device to be updated. This needs to be a unique subscribe topic as provisions do not exist for multiple devices being updated on a single topic other than the provisions made for JSON decoding for the plugin (green backround) Devices. I don't know about the timing relationship, but I would think whatever is showing in the text box when the Submit button is clicked will be what is taken as the topic. A page refresh would confirm.

    #2) The CAPI message is produced when there is a HS Device that was associated with a MQTT subscribe topic and the payload that was received on that topic is not one of the control options setup for that HS Device. For example, HS device may have controls for ON and OFF and the MQTT payload used to command this device was OPEN. This is likely why you are not seeing some devices being updated. If you enable the debug then I believe I put in the log the list of commands that a device is expecting. The log is produced in \data\mcsMQTT as a .txt file. It could be that the MQTT payload sometimes match what the Device is expecting and sometimes does not so it may look intermittent. In the cases where no update and not CAPI messages are in the HS log then look at the payload on the Association tab and confirm it is updating. If not then look closely at the subscription topic vs. what your external device is publishing.


    • Hey Michael,

      Thanks a lot for such a quick response. I realize this is gratis for all of us HS3 users and it's really appreciated.

      #1) Yes, I am associating existing HS3 devices with commands published via MQTT from node-red. I do nearly everything from node-red via MQTT. I was using a different HS3 plugin which was causing me grief until I found yours. I disabled the other plugin, installed yours, and just used the same topic names as I was using before, however I may have realized a mistake... I also named the publish topic the same name as my subscribed topic for each device. Not being what I would call savvy with MQTT, does that present a problem? Should I be using something like your example of $$room:/$$name?

      #2) For example, my back door sensor is 0 for closed and 1 for open. I can watch it in the Association Table update between the 2. But this morning (and this has happened with other devices as well), when I opened the door, the subscription never got the message that it was closed so it thought it was open and I got a bunch of emails saying it was open.

      HS3 LOGS

      Oct-27 11:53:22 mcsMQTT Unable to find CAPI control 1 for device 38
      Oct-27 11:53:22 EnvisaLink INFO Security status change: Not Ready
      Oct-27 11:53:22 EnvisaLink INFO Door status change: Opened

      mcsMQTT LOGS

      10/27/2019 11:53:22 AM 7228600 | HSEvent VALUE_CHANGE| 1024| Zone 4| 1| 0| 38
      10/27/2019 11:53:22 AM 7228615 | Update Accepted 38 to 1 StatusType=0 Payload= 1 RegExValue=1
      10/27/2019 11:53:22 AM 7228617 | Non-plugin Update Expression on payload 1
      10/27/2019 11:53:22 AM 7228617 | Command nonPlugin Device 38 to 1
      10/27/2019 11:53:22 AM 7228617 | Command 38 to 1, nValue=1, ControlValue=-1000, Range=Nothing, ControlType=Button, ControlString=, Label=Bypass, ControlUse=Not_Specified
      10/27/2019 11:53:22 AM 7228622 | Command numeric, but no CAPI matches value or range
      10/27/2019 11:53:22 AM 7228622 | Command with CAPI control not text or number box
      10/27/2019 11:53:22 AM 7228623 | ActoOnMessageForTrigger Topic HomeSeer/BackDoorSensor,Payload=1

      mcsMQTT Association Table

      Click image for larger version  Name:	AssociationTableExample.PNG Views:	0 Size:	11.8 KB ID:	1335917

      I think I'm seeing mcsMQTT get a value of -1000 that it wasn't expecting but in my HS3 device details, -1000 exists as Bypass.

      HS3 Back Door Sensor Values

      Click image for larger version  Name:	HS3_BackDoorSensorDetails.PNG Views:	0 Size:	20.4 KB ID:	1335919

      I don't know if the naming of both topics with the same name is the issue or if you can glean anything from what I've posted but I do appreciate your help. Thanks again, Michael!


      • I think you are correct on both counts. It is problematic to have the same subscribe and publish topics because the broker will echo back to the sender whatever it publishes. With Tasmota the convention is to include /cmnd in the topic if you want the Tasmota device to be controlled. Anything unique would prevent this loop.

        Your device 38 appears to have only one CAPI control of Bypass with value of -1000. If you want to put it in the Bypass state then NodeRed will need to send either Bypass or -1000 in the payload rather than 0 or 1. This begs the question of why only Bypass. Shouldn't you have a state for device 38 that is something other than Bypass?

        Also best to start a new topic so others that have similar issues can learn. It is lost 29 pages into the main mcsMQTT thread.


        • Moved my topic to its own thread here.