Announcement

Collapse
No announcement yet.

Accepted and Not Accepted count confusion in Statistics Tab

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

  • Accepted and Not Accepted count confusion in Statistics Tab

    I have mcsMQTT setup and properly controlling a "non plugin" HS Device, aka Purple Association. I have gone to the General Tab and set Listen for Only Accepted Messages. Everything works as I expect, I can turn lights on and off and get status messages back, except that all messages are marked not-accepted in the Statistics Tab.

    Additionally:
    • The messages are logged in history if I check Retain history of not-Accepted subscribed messages.
    • MQTT Received & not Accepted by mcsMQTT count increases for each received and processed message.
    • Last Received Topic and Payload are updated properly, but Last Received Topic Accepted and Payload Accepted remain blank.
    Am I misunderstanding what are considered Accepted and Non Accepted messages? I find it confusing that with Listen for Only Accepted Messages enabled, that I would be getting Not Accepted message counts.

    Thanks!
    Steven

  • #2
    "Listen for Only Accepted Messages" is intended to mean that mcsMQTT will only subscribe to messages that are explicitly identified. They can be identified by manual definition on Edit Tab or can have been previously discovered and Accepted on a prior start of mcsQTTT. Could it be that there has not been a restart of mcsMQTT since the General Tab Topic Discovery selected was changed to the the Listen for Only Accepted Messages option?

    When mcsMQTT processes a change in this setting it subscribes again to the MQTT Broker. It is up to the broker if prior subscriptions are honored or if the new subscribe list is the only one honored. If the broker accumulates subscriptions then the prior one of all topics ("#") is still in its list. When the mcsMQTT is disconnected from the broker either manually or via plugin restart then the ""#" will not be included in the list with the new setting and the broker should only forward the explicit list the mcsMQTT provides when it subscribes.

    Comment


    • #3
      I must still be misunderstanding something. So I uninstalled the plugin, deleted the data directory, deleted my broker and started all over from scratch.

      Process #1:
      • In Associations Tab, check include non plugin HS devices.
      • Click on the Ref # button next to the light switch I want to control.
      • In the pop up screen copy the Publish topic and paste it in subscribe topic with a suffix of /control
      • In general tab have Listen for Only Accepted Messages enabled.
      Results:
      • Publish messages go to broker fine (device changes)
      • Subscription sees no messages when I publish them
      • Restart Plugin
      • Subscriptions are delivered as Not Accepted and they do NOT control the device
      Reset everything again

      Process #2:
      • General set to Discover Published MQTT Messages
      • Publish a message to the /control endpoint
      • In Associations Tab, find topic in green, type Device ID into ref box
      Results
      • Publish messages go to broker fine (device changes)
      • Subscriptions are delivered as Not Accepted and they do control the device
      • Listen for Only Accepted Messages enabled in General tab
      • Plugin restarted
      • Publish messages go to broker fine (device changes)
      • Subscriptions are delivered as Not Accepted and they do control the device

      NOTE: Both of these processes ended up with a configuration that looked the same based on what I could see in the config screens but worked differently. Process 1 would never end up controlling the device.

      What I am trying to do is setup a standard light switch to publish status changes and process control messages. Process #2 seems to work, but I am concerned that mcsMQTT still is classifying the control message via the subscription as Not Accepted. What am I doing wrong?

      Thanks!
      Steven

      Click image for larger version

Name:	Association.PNG
Views:	1
Size:	202.5 KB
ID:	1273678
      Click image for larger version

Name:	popup.PNG
Views:	1
Size:	304.8 KB
ID:	1273679
      Click image for larger version

Name:	Statistics.PNG
Views:	3
Size:	120.0 KB
ID:	1273680

      Comment


      • #4
        I think the essential difficulty is the orientation. My guess is you publish something with /control in the topic to affect the lights. You have it setup to subscribe to something with /control in the topic. In your process #1 swap the subscribe and publish topics and you should be good.

        Comment


        • #5
          So it should not look like the picture I attached? It should be swapped? I don't think that works, the status changes publish fine from mcsMQTT.

          I am sending control messages externally to the /Control topic to turn the switch on and off.

          Thanks!
          Steven

          Comment


          • #6
            The edit tab shows mcsMQTT is subscribing to anybody who publishes a /control message. mcsMQTT is publishing a status message. Assuming that the light responds to a /control topic and will publish it's status without the /control as part of the topic then you should swap the subscribe and publish topics.

            Comment


            • #7
              Michael -- I appreciate you helping me work through this, but I just wasn't able to describe my issue well. So I threw the mcsMQTT.exe into dotPeek to see if I could figure out what was going on. It boils down to me using this plugin a little different then others I believe and a misunderstanding of terms.

              I now understand what you were trying to communicate to me, my light is not an external MQTT controlled light, its a native z wave light under homeseer control. I am using this system backwards from what other are using, in fact I am using it to build a simple Alexa Smarthome Skill to allow me to control homeseer without needing to use the myhs service or opening any holes in my network.

              What I found in the code is that if you have an Association set up to a physical device, not a mcsMQTT managed device the message will never be logged as an accepted message. It seems like those counters are set up to track when messages are sent to mcsMQTT virtual devices. In SetDeviceValueString if the device interface != mcsMQTT then the return value will always be 0 even if a CAPI device was found and successfully commanded.

              This just affects the counters and how messages might be logged, it does not affect the functionality. After determining this I reran my Process #1 and it succeeded, i must have had a typo somewhere.

              I now have Alexa discovering and controlling some of my zwave switches without needing myhs through your plugin, Amazon AWS IoT, and some AWS Lambdas!

              Please let me know if you have a donate link anywhere, being a software dev myself I understand the time and effort of supporting people like me. :-)

              Thanks!
              Steven

              Comment


              • #8
                I am glad you were able to figure it out and appreciate that you are using mcsMQTT is a bit different way. I just want to help others that have a similar interest so no need for a donation. Thank You for the consideration.

                Comment


                • #9
                  looking back at this thread (in morning rather than evening) I can see your description is very clear and it was me that was ignoring that your device is in HS and not external. Thank you for your persistence.

                  Comment

                  Working...
                  X