Announcement

Collapse
No announcement yet.

mcsMQTT Plugin

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

  • khriss75
    replied
    Originally posted by Michael McSharry View Post
    I am guessing. Rebuilding VR should be HS3 looking for all devices with Voice property enabled. Looks like HS3 does this every 10 seconds. Perhaps it is waiting for one to be created by the newly installed plugin.

    To test I deleted all HS devices and the mcsMQTT database. Disabled all plugins. Enabled mcsMQTT. No devices created. No messages in Speaker Client log after the initial one that the client had connected.

    I looked at setup, voice etc in HS3 menu and did not see anything that seemed like it would apply. Same for the speaker client.

    I get "The log database is currently x.xx MB in size" periodically reported as a log event. Likely similar to the VR messages, but have no idea how to configure this reporting.

    I suspect the next step would be with HST or perhaps Rupp. Sorry I could not help more.
    Thanks for reply. It is strange, on my other setup I can't see this message.
    HS seems to works well without any problem.

    I'll retry with a new fresh install.

    Leave a comment:


  • Michael McSharry
    replied
    I am guessing. Rebuilding VR should be HS3 looking for all devices with Voice property enabled. Looks like HS3 does this every 10 seconds. Perhaps it is waiting for one to be created by the newly installed plugin.

    To test I deleted all HS devices and the mcsMQTT database. Disabled all plugins. Enabled mcsMQTT. No devices created. No messages in Speaker Client log after the initial one that the client had connected.

    I looked at setup, voice etc in HS3 menu and did not see anything that seemed like it would apply. Same for the speaker client.

    I get "The log database is currently x.xx MB in size" periodically reported as a log event. Likely similar to the VR messages, but have no idea how to configure this reporting.

    I suspect the next step would be with HST or perhaps Rupp. Sorry I could not help more.

    Leave a comment:


  • khriss75
    replied
    I'm setting up a new HS system for my sister: new and fresh windows10 pc, new and fresh HS3 setup.
    After installing of mcsMQTT on Homeseer Speaker Host window i see this message: "Rebulding VR commands due to configuration change" (before plugin installation no messages).
    Not any devices created. Installed only HS3 and added mcsMQTT plugin.
    No errors in the log, only the message in HomeSeer Speaker window. This message is replicated exactly every 10 seconds. Seems that is not a problem but is there a way to eliminate it?

    thanks

    Leave a comment:


  • Freddan101
    replied
    Originally posted by goldriver View Post

    Freddan101 please seee post https://forums.homeseer.com/forum/li...nd#post1360374

    the problem is described there and the way to fix also
    Thank you. I copied the two files from the zip file (according to the linked thread), restarted HS and the updated plugin showed up in HS.

    Leave a comment:


  • goldriver
    replied
    Originally posted by Freddan101 View Post
    This morning I tried to upgrade the plugin to v5.1.1.3 through the updater but upgrade failed and the plugin disappeard from the "Installed Plug-ins" list. I get the same result when I try to re-install.

    I get this error in the log (Swedish).It says that the file can't be found. Tried to rename HSPI_MCSMQTT.exe and re-install but same result.

    Error, Creating plugin instance: HSPI_MCSMQTT.exe->Ett undantagsfel har inträffat i målet för en aktivering.->Det går inte att läsa in filen eller sammansättningen MCSMQTT_2020, Version=5.1.1.3, Culture=neutral, PublicKeyToken=null eller ett av dess beroenden. Det går inte att hitta filen.

    Anyone else experiencing this?
    Freddan101 please seee post https://forums.homeseer.com/forum/li...nd#post1360374

    the problem is described there and the way to fix also

    Leave a comment:


  • Freddan101
    replied
    This morning I tried to upgrade the plugin to v5.1.1.3 through the updater but upgrade failed and the plugin disappeard from the "Installed Plug-ins" list. I get the same result when I try to re-install.

    I get this error in the log (Swedish).It says that the file can't be found. Tried to rename HSPI_MCSMQTT.exe and re-install but same result.

    Error, Creating plugin instance: HSPI_MCSMQTT.exe->Ett undantagsfel har inträffat i målet för en aktivering.->Det går inte att läsa in filen eller sammansättningen MCSMQTT_2020, Version=5.1.1.3, Culture=neutral, PublicKeyToken=null eller ett av dess beroenden. Det går inte att hitta filen.

    Anyone else experiencing this?

    Leave a comment:


  • Michael McSharry
    replied
    The version number showing on the HS plugins page is only updated when HS restarts (or the Updater is used). The actual running version is visible in the General Page header line toward top of the page.

    Leave a comment:


  • goldriver
    replied
    Michael

    I just manually upgraded from 5.0.4 to 5.0.5 (copied files as per install.txt file refers to) and in the plugin management page the version did not upgrade I still have 5.0.3 is this normal ?

    I also manually ugraded last week from 5.0.3 to 5.0.4 but i did not put attention to this detail at that time so I have no clue if it changed at that time or not.

    I guess with the next automatic update from HS app store it will fix by itself ?

    Leave a comment:


  • 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:

Working...
X