Announcement

Collapse
No announcement yet.

mcsMQTT Plugin

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

  • Inshakoor
    replied
    Moved my topic to its own thread here.

    Leave a comment:


  • Michael McSharry
    replied
    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.

    Leave a comment:


  • Inshakoor
    replied
    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!

    Leave a comment:


  • Michael McSharry
    replied
    #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.

    Leave a comment:


  • Inshakoor
    replied
    Good Morning,

    First off, thank you for making such a detailed and in depth HS3 plugin. I set it up over this weekend and the configuration was pretty smooth. I love not having to use a virtual device . I have 2 things I'd like to run by the group to get some thoughts on:

    1) After setting up all the subscriptions and published items, some of them didn't seem to be getting any information. The resolution seems to be to erase both the topic names and recreate them or delete the association and create it again. Has anyone else experienced this? I fear that there are more like this that I haven't found yet. In fairness, I used the associations page to create the devices and I just went down a list and copied and pasted the previous names I already had and sometimes I'd click on the topic name before the name would auto populate. Could that have messed anything up?

    2) I am seeing a lot of logs in HS3 showing "mcsMQTT Unable to find CAPI control X for device XX". Will these errors impact performance? Am I doing something wrong? Did I associate a topic to a device that's not supported?

    Any suggestions are greatly appreciated. Thanks all!

    HomeSeer Version: HS3 Pro Edition 3.0.0.548
    Operating System: Microsoft Windows 10 Pro - Work Station
    Enabled Plug-Ins
    3.1.3.33206: Blue-Iris
    3.0.0.33: Ecobee
    3.0.0.41: EnvisaLink
    5.0.0.22: Global Cache
    4.2.3.0: mcsMQTT
    1.2019.211.1740: MyQ
    3.0.1.252: Z-Wave

    Leave a comment:


  • mloebl
    replied
    Originally posted by ServiceXp View Post

    Thank You Sir.

    This worked for me too, thank you! The version in the updater seems broken.

    Leave a comment:


  • khriss75
    replied
    This is not a blocking point for me, only for information, a my curiosity... I'm agree with your opinion about the selectable devices for log.
    Thank You so much for reply!

    Leave a comment:


  • Michael McSharry
    replied
    My understanding of the HS log is for explicitly directed messages and no provision exists in the mcsMQTT plugin to send things to the log based upon MQTT traffic. This could flood the log for those who have quite a bit of MQTT traffic. For example a temperature change for a sensor reporting through MQTT. What may make sense is to make the HS log an Edit tab setting for a device so a user is able to select just what they are interested or perhaps some form of logic around the Association tab History column setting. I'm leaning toward the second of these two.

    Leave a comment:


  • khriss75
    replied
    I think I'm missing something reading your mqttplugin manual, but I can't find the way to enable device's HS log.
    I'd like to see on HS log, when a lamp (via mqtt) switch ON or OFF.
    "Do not log commands from this device:" in device configuration tab is unchecked.
    The only solution is the mqtt history?

    EDIT:
    If I manage the device from HS webpage I can see the log data:
    set-26 10:05:33 Device Control Device: BATHROOM light_bathroom to OFF (0) by/from: CAPI Control Handler
    But if the command arrive from Arduino (+ethernet shield) where I connected a switch no log.

    Leave a comment:


  • ServiceXp
    replied
    Originally posted by Michael McSharry View Post
    Fixed in http://mcsSprinklers.com/mcsMQTT_4_1_7_2.zip. Only HSPI_MCSMQTT.exe changed in the zip.
    Thank You Sir.

    Leave a comment:


  • Michael McSharry
    replied
    Fixed in http://mcsSprinklers.com/mcsMQTT_4_1_7_2.zip. Only HSPI_MCSMQTT.exe changed in the zip.

    Leave a comment:


  • ServiceXp
    replied
    I upgraded to version 4.1.7.1 and It seams as if mcsMQTT can no longer connect to the broker. I have confirmed the broker is up and running and other clients have no problem.



    Attached Files

    Leave a comment:


  • khriss75
    replied
    Originally posted by Michael McSharry;n1322570

    Are you running a version at or after 4.1.2.3? The latest is at [url
    http://mcsSprinklers.com/mcsMQTT_4_1_5_0.zip[/url]
    Thanks, I was on 4.1.2.2 (from HS update), moved to 4.1.5.0 and now ok

    Leave a comment:


  • Michael McSharry
    replied
    The change log at the sticky at the top of this forum contains the following problem report: PR300 8/16/2019 4.1.2.3 Event action substitution variables broke

    Are you running a version at or after 4.1.2.3? The latest is at http://mcsSprinklers.com/mcsMQTT_4_1_5_0.zip

    Leave a comment:


  • khriss75
    replied
    Same situation of rogerbl: If I use a "Send Mqtt message" via EVENT with a Device value don't work.

    Send Mqtt message-->
    Code:
    HS3/cmnd/totale_impulsi_da_HS=$$DVR:(980):
    Mqtt payload is not the DEVICE980 value but is
    Code:
    $$DVR:(980):
    Thanks for your help!
    Last edited by khriss75; August 23rd, 2019, 02:35 AM. Reason: Formatting message

    Leave a comment:

Working...
X