Announcement

Collapse
No announcement yet.

HS4 device does not send OFF to MQTT-broker

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

    HS4 device does not send OFF to MQTT-broker

    Hi
    I have a device(830) controlling an outdoor flood light, with the commands On / Off. I have made an non-plugin device where the On/Off-commands are both published and subscribed from my broker. This used to work fine untill a 5-6(I think) few weeks ago. From my other client(a smart panel) I can control the HS4 device(830) through MQTT, and I can turn ON the device in HS4 and this is reflected on the other client, but I cannot turn it OFF(!) The OFF-command will simply not publish. Log file is attached.
    Attached Files

    #2
    I extracted several of the Device 830 transactions. In bold are the ones initiated by HS. In red are the ones from MQTT subscription. Read the bold top-down. Read the red bottom-up. I do not see any issues with a HS change followed by a message published. Likewise received messages update Device 830.

    I do see at 14/06/2021 21:38:54 97757 on OFF event reported but no MQTT message. I will look at the logic to get some ideas.


    Code:
    14/06/2021 21:38:27 71084 | [B]HSEvent VALUE_CHANGE[/B]| 1024| DC7B7766-077-Q346| 255| 0| [B]830[/B]
    14/06/2021 21:38:27 71087 | [B]Publish TNi3/mcsMQTT/Ute/Garasje/Garasjelys_ute=255[/B]
    14/06/2021 21:38:27 71091 | Update Accepted 830 to On StatusType=0 Payload=On RegExValue=On
    14/06/2021 21:38:27 71092 | Non-plugin Update Expression on payload On
    14/06/2021 21:38:27 71096 | [COLOR=#d35400]Command nonPlugin Device 830 to On[/COLOR]
    14/06/2021 21:38:27 71096 | Command 830 to On, nValue=0, TargetValue=0, Range=Nothing, ControlType=Button, ControlString=Off, Label=Off, ControlUse=Off, UpdateLastChange=False, bUpdateValue=True, HSValue=255
    14/06/2021 21:38:27 71097 | Command 830 to On, nValue=0, TargetValue=255, Range=Nothing, ControlType=Button, ControlString=On, Label=On, ControlUse=On, UpdateLastChange=False, bUpdateValue=True, HSValue=255
    14/06/2021 21:38:27 71097 | [COLOR=#d35400]ActOnMessageForTrigger QueueSize=0 ,Topic TNi3/mcsMQTT/Ute/Garasje/Garasjelys_ute/set,Payload On[/COLOR]
    
    
    14/06/2021 21:38:41 85411 | [COLOR=#d35400]Update Accepted 830 to Off[/COLOR] StatusType=0 Payload=Off RegExValue=Off
    14/06/2021 21:38:41 85412 | Non-plugin Update Expression on payload Off
    14/06/2021 21:38:41 85416 | Command nonPlugin Device 830 to Off
    14/06/2021 21:38:41 85416 | Command 830 to Off, nValue=0, TargetValue=0, Range=Nothing, ControlType=Button, ControlString=Off, Label=Off, ControlUse=Off, UpdateLastChange=False, bUpdateValue=False, HSValue=0
    14/06/2021 21:38:41 85417 | [COLOR=#d35400]ActOnMessageForTrigger QueueSize=0 ,Topic TNi3/mcsMQTT/Ute/Garasje/Garasjelys_ute/set,Payload Off[/COLOR]
    
    
    14/06/2021 21:38:48 92596 | [COLOR=#d35400]Update Accepted 830 to On[/COLOR] StatusType=0 Payload=On RegExValue=On
    14/06/2021 21:38:48 92597 | Non-plugin Update Expression on payload On
    14/06/2021 21:38:48 92599 | Command nonPlugin Device 830 to On
    14/06/2021 21:38:48 92599 | Command 830 to On, nValue=0, TargetValue=0, Range=Nothing, ControlType=Button, ControlString=Off, Label=Off, ControlUse=Off, UpdateLastChange=False, bUpdateValue=False, HSValue=0
    14/06/2021 21:38:48 92599 | Command 830 to On, nValue=0, TargetValue=255, Range=Nothing, ControlType=Button, ControlString=On, Label=On, ControlUse=On, UpdateLastChange=False, bUpdateValue=False, HSValue=0
    14/06/2021 21:38:48 92600 | [COLOR=#d35400]ActOnMessageForTrigger QueueSize=0 ,Topic TNi3/mcsMQTT/Ute/Garasje/Garasjelys_ute/set,Payload On[/COLOR]
    14/06/2021 21:38:48 92682 | HSEvent VALUE_CHANGE| 1024| DC7B7766-077-Q346| 255| 0| 830
    14/06/2021 21:38:49 92684 | Publish TNi3/mcsMQTT/Ute/Garasje/Garasjelys_ute=255
    14/06/2021 21:38:49 92691 | Update Accepted 830 to On StatusType=0 Payload=On RegExValue=On
    14/06/2021 21:38:49 92694 | Non-plugin Update Expression on payload On
    14/06/2021 21:38:49 92703 | Command nonPlugin Device 830 to On
    14/06/2021 21:38:49 92703 | Command 830 to On, nValue=0, TargetValue=0, Range=Nothing, ControlType=Button, ControlString=Off, Label=Off, ControlUse=Off, UpdateLastChange=False, bUpdateValue=True, HSValue=255
    14/06/2021 21:38:49 92703 | Command 830 to On, nValue=0, TargetValue=255, Range=Nothing, ControlType=Button, ControlString=On, Label=On, ControlUse=On, UpdateLastChange=False, bUpdateValue=True, HSValue=255
    14/06/2021 21:38:49 92705 | ActOnMessageForTrigger QueueSize=0 ,Topic TNi3/mcsMQTT/Ute/Garasje/Garasjelys_ute/set,Payload On
    
    14/06/2021 21:38:53 97650 | Update Accepted 830 to Off StatusType=0 Payload=Off RegExValue=Off
    14/06/2021 21:38:53 97652 | Non-plugin Update Expression on payload Off
    14/06/2021 21:38:53 97658 | Command nonPlugin Device 830 to Off
    14/06/2021 21:38:53 97658 | Command 830 to Off, nValue=0, TargetValue=0, Range=Nothing, ControlType=Button, ControlString=Off, Label=Off, ControlUse=Off, UpdateLastChange=False, bUpdateValue=True, HSValue=255
    14/06/2021 21:38:53 97660 | ActOnMessageForTrigger QueueSize=0 ,Topic TNi3/mcsMQTT/Ute/Garasje/Garasjelys_ute/set,Payload Off
    
    14/06/2021 21:38:54 97757 | [B]HSEvent VALUE_CHANGE| 1024| DC7B7766-077-Q346| 0| 255| 830[/B]
    
    14/06/2021 21:38:57 101597 | [B]HSEvent VALUE_CHANGE| 1024| DC7B7766-077-Q346| 255| 0| 830[/B]
    14/06/2021 21:38:57 101599 | [B]Publish TNi3/mcsMQTT/Ute/Garasje/Garasjelys_ute=255[/B]
    14/06/2021 21:38:57 101601 | [COLOR=#d35400]Update Accepted 830 to On[/COLOR] StatusType=0 Payload=On RegExValue=On
    14/06/2021 21:38:57 101602 | Non-plugin Update Expression on payload On
    14/06/2021 21:38:57 101606 | Command nonPlugin Device 830 to On
    14/06/2021 21:38:57 101606 | Command 830 to On, nValue=0, TargetValue=0, Range=Nothing, ControlType=Button, ControlString=Off, Label=Off, ControlUse=Off, UpdateLastChange=False, bUpdateValue=True, HSValue=255
    14/06/2021 21:38:57 101606 | Command 830 to On, nValue=0, TargetValue=255, Range=Nothing, ControlType=Button, ControlString=On, Label=On, ControlUse=On, UpdateLastChange=False, bUpdateValue=True, HSValue=255
    14/06/2021 21:38:57 101606 | [COLOR=#d35400]ActOnMessageForTrigger QueueSize=0 ,Topic TNi3/mcsMQTT/Ute/Garasje/Garasjelys_ute/set,Payload On[/COLOR]

    Comment


      #3
      In the source is the following conditional which explains the above because the message was received one second before the HSEvent notification from HS. No message is published to break-up a potential positive feedback loop.
      Code:
      If DateDiff(DateInterval.Second, .LastDate, Now) > 5 Then 
          bDo = True
      End If
      What this means is that the debug I extracted has no cases of OFF being set by HS that was not due to OFF update from the MQTT message. Is there something in your system that is responding to a OFF status to immediately change 830 to ON or otherwise inhibiting the OFF transition event change notification from HS?

      I do see the following I missed before where HS is reporting a change to OFF and no MQTT message published, but again it is within the 5 second window from the lasts received message for Device 830.
      Code:
      14/06/2021 21:38:31    74882    | HSEvent VALUE_CHANGE| 1024| DC7B7766-077-Q346| 0| 255| 830
      The corollary to this is at 14/06/2021 21:38:41 85411 where a MQTT message was received and mcsMQTT update the HS device, but no HSEVENT following this action. This implies that HS really never was aware of the Device 830 change with acknowledgement with either VALUE_CHANGE or VALUE_SET. The best rationale for this is that "Off" is not recognized by HS. It is case-sensitive. When looking at Status/Graphics what is the text for the OFF (0) state? If it is not "Off" then this explains the problem. If this is the case then it can be fixed by either editing HS Virtual Device to be "Off" or changing the MQTT client to publish "Off". The text does not matter, but it needs to be consistent.

      Comment


        #4
        Hi
        "What this means is that the debug I extracted has no cases of OFF being set by HS that was not due to OFF update from the MQTT message. Is there something in your system that is responding to a OFF status to immediately change 830 to ON or otherwise inhibiting the OFF transition event change notification from HS?"

        There should be no such mechanism doing so. Then recording the log I did press the on/off-buttons on the device a few times quickly back and forth.

        "When looking at Status/Graphics what is the text for the OFF (0) state? If it is not "Off" then this explains the problem. If this is the case then it can be fixed by either editing HS Virtual Device to be "Off" or changing the MQTT client to publish "Off". The text does not matter, but it needs to be consistent."

        The "Off" is consistent all over. I even changed the status text to "Of" throughout the chain, but it did not make any difference.


        I do notice something related to triggering of the MQTT. I do need to have the "Value Change Event" checked at all times to make the MQTT trigger. If use the value (instead of status) the broker responds correctly displaying 0 for off and 255 for on.

        I then put in the $$STATUS in the MQTT Publish Payload Template and checks the "String Change Event" and uncheks the "Value Change Event". Nothing happens.

        I check "Value Change Event" and the Statuses are published (not the Off though)

        If I only have the "String Change Event" cheked nothing happens, neither when pressing On nor Off.

        Comment


          #5
          Hi
          I now changed the HS-device(It is a z-wave device) to publish to the broker only. To make this work I need to have the "Value Change Event" checked, even if I put status in the payload using the $$STATUS: The "String Change Event" does not seem to work.

          Comment


            #6
            Hi
            I have now changed the communication chain to use values only instead of status.This works fine bi-directionally on both VD and Z-wave devices. But I would prefer to use the statuses since they inherently give reflects the state/function they represent.

            To me it seems that there is an issue with the "string event change"

            Comment


              #7
              HS maintains two properties for a device feature for which will carry dynamic data. One is DeviceValue and the other is DeviceString. It will generate Event callbacks on either changing or just the DeviceValue being set. A "String Event Change" will pass the new contents of DeviceString. The two DeviceValue callbacks will pass the contents of DeviceValue. DeviceValue is a double precision number. DeviceString is text.

              It is possible to setup relationships between DeviceValue and Status/Label. The Status/Label is not the DeviceString, but specific text mapped specifically to a DeviceValue or set of DeviceValues. These are called Value Status Pairs. These are the things you want to use when publishing "OFF" vs. 0. The publish payload template on the mcsMQTT Edit tab is what is used to identify what device feature property is to be included in the payload. It is likely that what you want to use is $$LABEL: if you want the Status/Label published. $$VALUE: would be used for the DeviceValue number. It is also possible to use the Reference-specific such as $$DSR830): to publish the Status that shows as HS renders the Devices page. This is a little less-flexible since the reference number needs to be included in the publish template. The $$LABEL: will be the text of the control (button) that shows on the HS Devices page.

              There was a similar discussion at https://forums.homeseer.com/forum/li...y-value-is-not of which the following is specifically applicable to this discussion for current version of mcsMQTT.

              Code:
              For devices reporting via HSEvent:
              $$VSP: uses the VSP Key setup in mcsMQTT (i.e. 1st item in the VSP entry of edit edit)
              $$STATUS: uses the VSP Status setup in mcsMQTT (i.e. 3rd item in the VSP entry of edit page) 
              $$LABEL: uses the CAPI Label from HS
              $$VALUE: uses the HS Value Change parameter of HSEvent
              $$PREVIOUS: uses the HS Current Value parameter of HSEvent
              $$PUBLISHED: uses the last published payload

              Comment


                #8
                Hi
                (updated: forgot to check the "Last Change Time Updates on Status Change Only")

                Makes sense! Seems to work fine now, thanks! I´ll give it a few days and I´ll update my system.

                Comment


                  #9
                  So, just to be sure. Here is a snap of the settings my Z-wave device:

                  Click image for larger version  Name:	Label.jpg Views:	0 Size:	40.1 KB ID:	1479659
                  If I understand correctly the $$LABEL: corresponds to the staus circled red?
                  Attached Files

                  Comment


                    #10
                    This is snapshot from a VD: Click image for larger version  Name:	Screenshot 2021-06-15 at 19.18.33.png Views:	0 Size:	206.4 KB ID:	1479663
                    In the MQTT-setup I use $$STATUS and that works fine...so is this because I have defined the "status" in the "Edit Status/Graphic" part of the screen? Ideally I should use $$LABEL also for this device?
                    Attached Files

                    Comment


                      #11
                      If I understand correctly the $$LABEL: corresponds to the staus circled red?
                      Yes. This will also be the label text on the button. If you defined it to be independent status and control rather than both then the label will be the text entered for control. The status would only be available via $$DSR: substitution variable or via $$STATUS: if it is a plugin device and the VSP on Edit tab was setup with a status value in 3rd parameter.

                      When HS commands a plugin device it passes $$LABEL: parameter so the plugin knows what button was pushed. When HS reports a DeviceValue Change such as for a non-plugin device the only information provided is the Ref and Value. There is no text so if text is going to be sent it needs to be derived from the Ref and Value.

                      [quote]
                      In the MQTT-setup I use $$STATUS and that works fine...so is this because I have defined the "status" in the "Edit Status/Graphic" part of the screen? Ideally I should use $$LABEL also for this device?
                      [/quote

                      HS has a bug for the case of a dropdown selector. When it is used to control a device then HS always passes the label at the top of the selector rather than the label of the selection the user made. This is why $$VSP: and $$STATUS: are good options in-lieu of $$LABEL: for plugin devices. $$VSP is what is received in the MQTT Topic description. $$STATUS is what you want HS to show.

                      Comment


                        #12
                        Hi
                        It seems to be fine to use $$LABEL as "MQTT Publish Payload Template" for VDs and z-wave devices, and the desired "label" are reflected correctly at the other clients.

                        But what are the mechanisms the other way then subscribing from HS? If I modify a "label" at the other client "where" is this received at the HS VD?
                        I would guess that since the "label" is published a using $$LABEL it is also returned through this path? If so, are there some internal functionality inside the HS VD providing alignment between the value, status and label?

                        There are some apparent complications using EasyTrigger " action "Set device to another device" involving a HS z-wave device and a VD modified from a MQTT-client using the $$LABEL:

                        My scenario is as follows:

                        1) I have a VD called VentFan that has the values: min/med/max. I publish this to the broker, and I also subscribe to pick up any modifications made on my smart panel.

                        2) Every morning an event run (using EasyTrigger Set device to another device) that sets the fan speed of my ventilation equal to the VantFan.

                        -------
                        The problem:

                        1) If I use $$LABEL the min/med/max are transferred both ways. However, cannot use the VD in events actions
                        2) If I use $$STATUS the min/med/max are not transferred both ways. VD works in events actions.

                        Comment


                          #13
                          But what are the mechanisms the other way then subscribing from HS? If I modify a "label" at the other client "where" is this received at the HS VD?
                          The payload received in the MQTT message establishes the VSP Status. The Value by default in incremental. If the Edit tab VSP is edited to add a 3rd parameter then this parameter is used for the HS Control label. If it is not edited then the Control label is the same as the Status.

                          In your scenario I expect 3 rows in Edit tab for VSP. This will produce three button control labels with the same names..
                          min=0
                          mid=1
                          max=2

                          Easy Trigger will generate a CAPI control with values 0, 1 and 2. In your Edit tab Publish Payload Template you will want to send min, mid or max. This means you will want $$VSP: as the replacement. $$LABEL: will use whatever HS CAPI is providing. I expect it to be min/mid/max as well, but don't know for certain.

                          If you used the Edit tab with the following then you have defined a $$STATUS: replacement and then it can be used as well.
                          min=0;min
                          mid=1;mid
                          max=2;max

                          Comment


                            #14
                            Hi
                            Just to be sure…I use (mostly) non-plug-in devices for MQTT, and ny problem apples to that. Are your explaination above targeted on a non-plug-in device?


                            Sent from my iPhone using Tapatalk

                            Comment


                              #15
                              When you indicated subscribe I assumed plug-in device so that is what I described.

                              For a non plug-in device mcsMQTT will use CAPI to find the value associated with the payload text. I am away until tomorrow so cannot look at the specific properties it looks for,, but I remember looking at multiple properties in the search.

                              Comment

                              Working...
                              X