Announcement

Collapse
No announcement yet.

Sorry for being unable to figure it out, but can I get some starting tips?

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

    Sorry for being unable to figure it out, but can I get some starting tips?

    Hi there. So I finally have some time to set up mcsMQTT, so I can communicate between the HS4 install in the basement and the HTPiHubG1v2 running HS4 in the barn. The goal is to fully migrate from my HS2 server running on Windows Server 2003 so I can shut it down...

    I've been reading through section 4 of the PDF, but there's so much terminology I'm not catching on to, and I've been floundering for the last couple days. I have the mcsMQTT plugin installed on both HS4 hosts, and I have the internal broker set up. The broker is running on the HS4 PC, and the HTPi is able to communicate with the broker, so that part is set.

    Could I impose on someone to either point me to a sample or tutorial on how to get started with two HS4 installs running mcsMQTT, controlling each other's devices? Specifically I want to be able to have the HS4 PC (named Henry) control the Z-Wave relay switch devices connected to the HTPi, and have the devices mirrored on the HS4 PC (doesn't matter what floor/room they are, so "HTPiHubG1v2" would be fine) for scripting purposes.

    Thank you,
    Chris

    #2
    As an example, starting with a Z-wave switch feature on HTPi using the Association tab of the HTPi MQTT Page of mcsMQTT. Since it is not a mcsMQTT device you will want to enable viewing of non-plugin devices near the top of the page. You may want to use the "Filter by HS Device Categories" to reduce the number of items in the Association table at the bottom. Use the "Show Selected Associations" button to view the table.

    Identify the row where the switch feature you want to control is shown. Click on the "a" column checkbox of this row to associate a MQTT Topic to this feature. The row will be expanded to provide three textboxes. The top one is the MQTT Topic that will be used to remotely command this switch feature. The middle one is the MQTT Topic that the HTPi will use to report any changes of the status of the switch. The bottom row will be any special formatting to be used in the status reporting message.

    Copy the contents of the middle text box, paste it into the top textbox and then suffix with /set. You are free to change the Topic text, but for simplicity at this time I will show the default. Now do something with the switch so its status will be updated on the HTPi. This will cause a MQTT message to be sent and then visible on Henry. I will just guess that the switch was turned On and the HS Status reported will by On in the MQTT message payload.

    On Henry go to the Association tab. In this case you want to see Received MQTT Topics at the top with the checkbox. Click the Show Selected Associations button and the Zwave switch status row should be visible including "On" in the payload coumn. Click the "a" column checkbox to create a HS Device and Feature on Henry. The row will have expanded to allow entry of a Publish topic that will be used to control the remote switch on HTPi. It will also have a text box for special formatting of the payload. In the publish textbox copy the MQTT Receive topic showing on the HTPi row for this switch. It will be the one where you added the /set suffix.

    On Henry view the HS Devices page and you will see a Device Feature with an On and Off button for control. Click the Off button and the zwave light should turn off.

    HS Uses Device Values and Value Status Pairs to synthesize Status. If may be necessary to use the payload template text box(es) to get the desired information in the payload. For example, when the switch reports On, it may be sending 100. We can continue this discussion when you get to this point to take the next step.

    Comment


      #3
      Thank you very much, Michael! What I was missing was the "/set" on the publish, and the fact that you have to perform an action on the "remote" HTPi host first before it will show up as an Association on the "local" Henry host where you can check the "A" column box.

      The two fake test devices that I'm working with on HTPi are called
      "Virtual Floor Virtual Room Virtual Device 1"
      and Virtual Device 2. Interestingly, both of those devices are showing up as features under a single device, as attached.

      I configured the two features individually to accept 0 and 100 as off and on, respectively, including updating the graphics icons, and the Device Status page on the opposite computer is updated immediately!

      I don't see anything in the HomeSeer log on Henry when the device is locally controlled at HTPi, though. The device on Henry is updated, but there's no mention in the HomeSeer log.

      Thanks,
      Chris

      Comment


        #4
        I don't see anything in the HomeSeer log on Henry when the device is locally controlled at HTPi, though. The device on Henry is updated, but there's no mention in the HomeSeer log.
        The sequence that I described was for "Specifically I want to be able to have the HS4 PC (named Henry) control the Z-Wave relay switch devices connected to the HTPi". One step at a time. I assume that the Henry device was updated on the Devices page, but nothing shown in the log.

        On Henry you have a mcsMQTT-created device. It will change DeviceValue/Status based upon the Topic published by HTPi. mcsMQTT will record this to the HS log, but when I look at the source I see it is conditional about History being saved. This means you need to have History saved for at least one day on the History tab and have the "d" column checkbox checked for the device on Henry. I don't remember why this was the logic implemented.
        Code:
         If bUpdateLastChange OrElse bValueChange Then
            hs.UpdatePropertyByRef(iRef, Devices.EProperty.LastChange, Now)
            If oMQTT.History AndAlso gLogCheckedHistory AndAlso bValueChange Then
                hsWritelog(PLUGIN_NAME, "Device " & iRef.ToString & "(" & hs.GetPropertyByRef(iRef, HomeSeer.PluginSdk.Devices.EProperty.Location2).ToString & " " & hs.GetPropertyByRef(iRef, HomeSeer.PluginSdk.Devices.EProperty.Location).ToString & " " & hs.GetPropertyByRef(iRef, HomeSeer.PluginSdk.Devices.EProperty.Name).ToString & ") Changed from " & sPreviousValue & " to " & sLogValue)
            End If
        Else
             hs.UpdatePropertyByRef(iRef, Devices.EProperty.LastChange, dLastChange)
        End If
        Interestingly, both of those devices are showing up as features under a single device, as attached.
        mcsMQTT will create a Device for a parent topic and put all children topics under the same device. If HTPi publishes as XYZ/123/a and XYZ/123/b then a and b will be create as children under XYZ/123 HS Device. If it publishes as XYZ/ABC/a and XYZ/123/b then it will create two parent devices. You can change this relationship by using the mcsMQTT Edit tab (click on the REF button of the row you want to change parent). There is a grouping text box and enter the desired parent Ref in this text box.

        Comment


          #5
          Originally posted by Michael McSharry View Post
          The sequence that I described was for "Specifically I want to be able to have the HS4 PC (named Henry) control the Z-Wave relay switch devices connected to the HTPi". One step at a time. I assume that the Henry device was updated on the Devices page, but nothing shown in the log.
          Ok, yes, sorry. And yes, the Henry device being updated is working, thank you! I am also able to control the test virtual devices through the Alexa app on my phone, so that next step for me is complete.

          Originally posted by Michael McSharry View Post
          On Henry you have a mcsMQTT-created device. It will change DeviceValue/Status based upon the Topic published by HTPi. mcsMQTT will record this to the HS log, but when I look at the source I see it is conditional about History being saved. This means you need to have History saved for at least one day on the History tab and have the "d" column checkbox checked for the device on Henry. I don't remember why this was the logic implemented.
          Interesting. Ok, the default HS Device history option selected is "Save history Of only devices marked With D or I column checkbox", and I checked the "D" column on those devices, so I should be set.

          Originally posted by Michael McSharry View Post
          mcsMQTT will create a Device for a parent topic and put all children topics under the same device. If HTPi publishes as XYZ/123/a and XYZ/123/b then a and b will be create as children under XYZ/123 HS Device. If it publishes as XYZ/ABC/a and XYZ/123/b then it will create two parent devices. You can change this relationship by using the mcsMQTT Edit tab (click on the REF button of the row you want to change parent). There is a grouping text box and enter the desired parent Ref in this text box.
          Ah, I see. Ok, no problem. I'm figuring on having a dozen and a half devices in the barn where the HTPi is located, where each of the two floors is its own room, so I just might leave all of them as features under the same parent then, rather than have like two or three parents with a half-dozen features under each.

          At this point, I should be set well enough to move forward with the Z-Wave switches. I have a JDS TimeCommander out in the barn, too, with digital inputs and relay outputs, and a couple-hundred-line schedule. I wrote a mnemonic-based serial interface for it to do command/responses with HS, and I could definitely see getting MQTT involved, but that'll be for another show.

          Thanks again! And if you have a "tip jar", let me know, I'll throw some your way!

          Chris

          Comment

          Working...
          X