Announcement

Collapse
No announcement yet.

mcsMQTT Plugin

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

  • Guest's Avatar
    Guest replied
    isn't suppossed to have and updater overide text?

    Leave a comment:


  • Michael McSharry
    replied
    The Client ID is set to a globally unique ID and when mcsMQTT connects it sets the session to be a clean one with no attempt to retain any information from a prior connection. To accommodate your desire for a more easily identified client I change the Client ID to be mcsMQTT on XXX where XXX is the computer name where mcsMQTT is running. It is 3.4.11.0 that has been submitted to updater and available at http://mcsSprinklers.com/mcsMQTT_3_4_11_0.zip.

    Leave a comment:


  • jfla
    replied
    Hi, Michael

    how to name the client ID in the setup plugin?

    In my broker i want to see which client is connected

    Click image for larger version

Name:	Screen Shot 10-07-18 at 09.59 AM_LI.jpg
Views:	131
Size:	44.4 KB
ID:	1251777

    Thanks

    Jean-Francois.

    Leave a comment:


  • Michael McSharry
    replied
    Yes mcsMQTT will keep it local and speed it up. The sticky post st the top of the forum has some user-provided writeup for step by step. The mcsMQTT manual has a quick start chapter toward the beginning that covers typical use cases.

    Leave a comment:


  • dannieboiz
    replied
    Guys... I'm using BlueIris to send an MQTTT webhook to IFTTT then triggering over the web back to HomeSeer and trigger my VD. Would this be the answer to keep this traffic locally?

    Are there any MQTTT for HomeSeer for dummies?

    Leave a comment:


  • Michael McSharry
    replied
    I saw a STAT message for Node_16 and this is not what was shown as the control Topic for this Zwave endpoint. I also saw messages that looked to be controlling Node_4. It looks like Node_4 was not setup in mcsMQTT to associate with a device. The intent is to externally send a control Topic for Node_16 so debug data can be seen for it.


    7/16/2018 4:03:20 PM 1847 | ActoOnMessageFor Trigger Topic STAT/DESKTOP-38S1K8F/mcsMQTT/Node_16/Z-Wave/Switch_Multilevel_1,Payload=0


    7/16/2018 4:09:28 PM 369688 | ActoOnMessageFor Trigger Topic DESKTOP-38S1K8F/mcsMQTT/Node_4/Z-Wave/Switch_Multilevel_1_set,Payload=10
    7/16/2018 4:09:48 PM 389603 | ActoOnMessageFor Trigger Topic DESKTOP-38S1K8F/mcsMQTT/Node_4/Z-Wave/Switch_Multilevel_1_set,Payload=0
    7/16/2018 4:10:09 PM 409908 | ActoOnMessageFor Trigger Topic /stat/DESKTOP-38S1K8F/mcsMQTT/Node_4/Z-Wave/Switch_Multilevel_1_set,Payload=0
    7/16/2018 4:10:31 PM 432154 | ActoOnMessageFor Trigger Topic STAT/DESKTOP-38S1K8F/mcsMQTT/Node_4/Z-Wave/Switch_Multilevel_1_set,Payload=10
    7/16/2018 4:10:34 PM 435838 | ActoOnMessageFor Trigger Topic STAT/DESKTOP-38S1K8F/mcsMQTT/Node_4/Z-Wave/Switch_Multilevel_1_set,Payload=99

    Leave a comment:


  • geirra
    replied
    Originally posted by Michael McSharry View Post
    I need some help on your terminology. What I think you indicated is that the status topic (..._Multilevel_1) is being published on a change in Device 111, but when some external node publishes the control topic (..._Multilevel_1_set) there is no change in the Zwave device or HS device 111.

    Assuming this is the question, then the control topic payload needs to match something that the Zwave device can understand. If you provide the debug output for time when the control topic is published then more specific input can be provided. Debug is enabled on the General tab and the output in the file \Data\mcsMQTT\mcsMQTT Debug.txt.
    Thanks

    Yes, this is correct.
    The zwave dimmer is using 0 to 99 as values, i have tried to push, 0, 10 and 99 none where passed on

    In the logs below i have changed the device to switch4 HS ref 19
    other than that same syntax, verified that the messages are sent on the bus

    Log: https://pastebin.com/raw/UuarwQ6G

    Leave a comment:


  • Michael McSharry
    replied
    I need some help on your terminology. What I think you indicated is that the status topic (..._Multilevel_1) is being published on a change in Device 111, but when some external node publishes the control topic (..._Multilevel_1_set) there is no change in the Zwave device or HS device 111.

    Assuming this is the question, then the control topic payload needs to match something that the Zwave device can understand. If you provide the debug output for time when the control topic is published then more specific input can be provided. Debug is enabled on the General tab and the output in the file \Data\mcsMQTT\mcsMQTT Debug.txt.

    Leave a comment:


  • geirra
    replied
    Originally posted by Michael McSharry View Post
    I'm here to help whenever you have time.



    Switch --Zwave-->HS (e.g. Device 123)
    mcsMQTT Device 123 has Publish (status) topic HS/Dimmer/, Subscribe (status) topic setup for NR/Dimmer

    1. Switch turns ON -> HS Device 123 Value = 100
    2. HS Event Device 123 changed to 100 -> msMQTT
    3. mcsMQTT Publishes HS/Dimmer with payload 100
    4. Broker sends HS/Dimmer=100 to NR
    5. NR publishes NR/Dimmer=40 (set to 40% DIM)
    6. Broker sends NR/Dimmer=40 to mcsMQTT
    7. mcsMQTT sets Device 123 to 40

    mcsMQTT debug will time-stamp steps 2, 6 and 7 which are its interface boundaries. The debug checkbox on the General tab needs to be set to get this visibility.
    Step 2 will be "HSEvent Do= "
    Step 6 will be "ActoOnMessageFor Trigger Topic "
    Step 7 will be "Update Accepted "
    Wireshark or similar can measure the network traffic timing

    If my seven step flow is correct then I actually expect step 8 to generate another HS Event call to mcsMQTT to reflect a change to 40 and the flow would repeat again. It may be that my interpretation is not totally correct, but at least it should show intent and method to understand timing debug available.

    In the above there are no user events setup within HS to manage MQTT traffic. It is all done through devices. There are no virtual devices setup as everything is managed through the one real device.
    Probally something i have missed, but i got mcsMQTT to publish my zwave unit, but it does push the changes back.

    Set it up as below.


    What am i missing?

    Leave a comment:


  • qwiksilver96
    replied
    Originally posted by Michael McSharry View Post
    Do you need retain to be different on a event by event and device by device basis? Currently it is a global set on General tab. It also can be different for each device so when the value or string changes for the associated device the message will have the desired retain property.
    No need to retain differently on an event by event basis. For some reason, the setting in the general tab did not stick when I had previously turned it on. I checked the setting and noticed it was off. Enabled it and it is working as desired.

    Thank you,
    Frank

    Leave a comment:


  • Michael McSharry
    replied
    Do you need retain to be different on a event by event and device by device basis? Currently it is a global set on General tab. It also can be different for each device so when the value or string changes for the associated device the message will have the desired retain property.

    Leave a comment:


  • qwiksilver96
    replied
    Retained messages

    Micheal, is there a way to set messages to be retained when sent via an event? I know it can be done via a script, but I would like to simplify this. If not currently available, could the feature be added to the script dialog box?

    Best,
    Frank

    Leave a comment:


  • Michael McSharry
    replied
    Anywhere on the network is fine for Mosquitto.

    Leave a comment:


  • _ThaNerd_
    replied
    Does the mosquito have to be installed on a ubuntu server or can it be installed on a Windows server (the same server where I have hs3 installed)?

    Leave a comment:


  • Pete
    replied
    Thank you Michael.

    Leave a comment:

Working...
X