Announcement

Collapse
No announcement yet.

payload status field and plugin restart requirements

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

    payload status field and plugin restart requirements

    I added a couple of z-wave wall switches... an example of one looks like this (this is the default as created by HomeSeer):

    Click image for larger version

Name:	Screenshot 2022-04-26 151108.png
Views:	83
Size:	29.0 KB
ID:	1540191

    I added an association using the 'Switch' feature after each device was added, and both times I needed to restart the plugin to get either device to work (pub/sub didn't work at all). I'm not sure if I needed to do so with the few other z-wave devices that I had added previously, simply because I was restarting HomeSeer many times for variety of other reasons. At any rate, is this the expected behavior?

    My other question is regarding the payload field in the associations table. I noticed that if an external system publishes a switch change, the field updates properly. If I toggle the same devices via the HomeSeer GUI, the field does not update (pub/sub works fine, it's just the payload field does no reflect any change). Not sure if it matters, but on the HomeSeer end all devices do have the 'Last Change Time Updates on Status Change Only' option checked/enabled, and in mcsMQTT each association has 'Value Change Event', 'Value Set Event', and 'Log' checked. The 'History' box is also checked for each in the Association Table.

    Thx.

    #2
    I do not have the same experience as you are seeing. I created a virtual device to conduct the test. Called it VD15 with the Device at 1801 and Feature at 1802. Use the General tab Enumerate HS Devices button to make mcsMQTT aware that a non-plugin device was added. This enabled me to see it in the Association tab. I clicked the "A" column checkbox.

    Click image for larger version  Name:	0.png Views:	0 Size:	26.0 KB ID:	1540268
    I then used the HS Devices page to toggle VD15 Control (1802). I saw messages in a client that was monitoring MQTT traffic.

    I added a Publish topic VD15

    Click image for larger version  Name:	1.png Views:	0 Size:	26.0 KB ID:	1540269 On my test client I sent a 0 payload to this topic. The HS Feature changed from On to Off.

    The log on my test client is below. The top part was step 1 to have HS toggle VD15 control. The bottom was the test client sending the command, HS changing the VD status and mcsMQTT publishing a message showing the changed status.

    Code:
    3:03:44 PM Topic MCS8/mcsMQTT/Unknown/Unknown/Control Payload 0
    3:04:01 PM Topic MCS8/mcsMQTT/Unknown/Unknown/Control Payload 100
    
    3:07:43 PM Topic VD15 Payload 0
    3:07:56 PM Topic MCS8/mcsMQTT/Unknown/Unknown/Control Payload 0
    You should be able to use an independent client to repeat these steps or this description may help what you are doing differently. Note that when "A" is used there is no subscribe topic. Not until this topic is specified will there be any ability to control your Zwave device from MQTT. If not able to resolve then additional debug can be added if the existing debug in mcsMQTT Debug.txt is not sufficient.

    I will need to do a similar evaluation for question 2. In general, I expect the Payload and LastDate columns to update if the topics are being shown on an active Association tab as data is received via MQTT. This table reflects only received topics so publishing something does not affect the table unless there is a response from an external client that results in something being changed.

    Comment


      #3
      For the second question...
      It appears the external system is able to deliver a MQTT message that results in the Association table being updated based upon what is stated in post Home This implies that the receive side that results in a table update is working as expected.

      The MISC flags and Event flags only affect the mcsMQTT to HS interface. It does not affect the MQTT to mcsMQTT interface. It looks as if the HS action is not resulting in anything that induces the client publishing MQTT messages to publish a status update. Independent client or the mcsMQTT Debug file would be the next place to look. Each received message is in the Debug Log starting with "ActOnMessageForTrigger"

      Comment


        #4
        Thanks Michael.

        The only difference here is that I was using real devices, not virtual. I do have a couple of virtual devices, but as mentioned I can't say for sure if I needed to restart the plugin to get them working. I definitely needed to do so with these last two z-wave switches. While trying to determine the issue, I used mosquitto_sub/pub to insure that the topics and payloads were as expected. It wasn't until I determined all was good that I decided to restart, which as mentioned took care of the issue.

        Re. the payload status, if I'm understanding your last post when I toggle a switch via HS and mcsMQTT publishes, the client system that I have just reacts to the payload locally (it's an OpenHAB system in this case), it doesn't publish anything in return. So if the payload field in the Associations table is only updated based on received topics, then that would explain why toggling an associated device using the HS GUI doesn't change the payload status. I was just more curious than anything.

        EDIT: I just noted your comment "Use the General tab Enumerate HS Devices button to make mcsMQTT aware that a non-plugin device was added". Should I be doing that? I added the z-wave device in HomeSeer, and then just added an association in mcsMQTT using the z-wave device ID, which seemed to work fine.

        Comment


          #5
          EDIT: I just noted your comment "Use the General tab Enumerate HS Devices button to make mcsMQTT aware that a non-plugin device was added". Should I be doing that? I added the z-wave device in HomeSeer, and then just added an association in mcsMQTT using the z-wave device ID, which seemed to work fine.
          As long as the device appears in the Association table then no need to enumerate the devices.

          the client system that I have just reacts to the payload locally (it's an OpenHAB system in this case), it doesn't publish anything in return
          How does OpenHAB make external entities aware of the state of its devices as they change?

          The only difference here is that I was using real devices, not virtual.
          This only determines if CAPI is use by mcsMQTT to request an action. For virtual devices the mcsMQTT action is to store into the DeviceValue of the virtual device. For real devices, mcsMQTT makes a CAPI request to the subject plugin to act upon a change request. With real devices the expectation is that the hardware being controlled by the plugin will provide some type of acknowledge and the interfacing plugin will update the HS Device Feature. This update will be recognized by HS and it will issue a HSEvent callback to all subscribed listeners that the Device Feature has been touched. When DeviceValue has been change either by the Interfacing plugin or as a VirtualDevice then an HSEvent callback will be raised.

          The next step is to assure debug has been enabled on mcsMQTT General tab (top) and look at the debug file to know what mcsMQTT is seeing in the transaction.

          Comment


            #6
            Originally posted by Michael McSharry View Post
            As long as the device appears in the Association table then no need to enumerate the devices.
            I thought that might be the case, so we know that not using the enumerate button wasn't the issue.


            Originally posted by Michael McSharry View Post
            How does OpenHAB make external entities aware of the state of its devices as they change?
            Via the openHAB cloud. While I use openHAB for a myriad of the things, with respect to HomeSeer it provides the linkage to Google Assistant. I simply set up (more or less) the equivalent to HomeSeer's virtual device on openHAB for any HomeSeer device that I wish to control via Google (or if I choose, via openHAB's GUI). So "hey Google... turn on the living room lamp" will turn on openHAB's "living room lamp", which will update openHAB's cloud and publish to the broker, which will trigger mcsMQTT to turn the lamp on. And of course, toggling a device on HomeSeer will set the openHAB device/cloud so that Google knows the device's current state. I'm aware that the MyHS setup can likely do that, but I've been using openHAB with Google for some years and it's been quite solid.


            Originally posted by Michael McSharry View Post
            The next step is to assure debug has been enabled on mcsMQTT General tab (top) and look at the debug file to know what mcsMQTT is seeing in the transaction.
            I have a couple more z-wave devices to add, so I'll do that and report back.

            Comment

            Working...
            X