Announcement

Collapse
No announcement yet.

HS4 device does not send OFF to MQTT-broker

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

  • tnesheim
    replied
    Originally posted by Michael McSharry View Post
    Update attached to deal with subscription mapped to a VD.
    Thanks, now it works fine...bidirectional MQTT updating and EastTrigger actions passing strings device-to-device.

    Leave a comment:


  • Michael McSharry
    replied
    Update attached to deal with subscription mapped to a VD.
    Attached Files

    Leave a comment:


  • tnesheim
    replied
    Thanks!
    Ok, then my MQTT-problems comes down to one user error and one bug...looking forward to testing the enhancement.

    Leave a comment:


  • Michael McSharry
    replied
    #20 is about the subscribe and not the publish so it is a different thing than $$STATUS vs. $$LABEL.

    #20 is about is HS4 GitHub Issue #190 where virtual devices do not respond to CAPI SendControlForFeatureByValue. I tried to work around the bug in mcsMQTT. This work around did not consider non-numeric payloads with VSP. I'll post later after I make this enhancement.

    Leave a comment:


  • tnesheim
    replied
    Hi
    The update did not make any difference:

    I have now changed to $$LABEL in the MQTT-setup. If you look at the figure in post 18# I can do a change to the "number of blades", fan speed that is, and this is reflected in the HS-VD.

    I now want to update the z-wave-device (not shown here) with the new setting from SystViftCP, and I use the EasyTrigger " Set device to another device" to do this. Nothing happen to the z-wave device when I run the event. However, If I do the change directly in the SystViftCP and then run the event, the z-wave device changes.

    Test sequence:
    1) I set the SystViftCP-VD to "max" from HS, and the following happens:
    Click image for larger version  Name:	Screenshot 2021-06-21 at 09.13.06.png Views:	0 Size:	279.8 KB ID:	1480416

    I go to the other device and set the fan speed to "min", this (apparently) reflected in the HS-VS, and I gett the following:

    Click image for larger version  Name:	Screenshot 2021-06-21 at 09.14.45.png Views:	0 Size:	284.0 KB ID:	1480417

    Observe that the Status is changed from "max" to "min", but the value is unchanged at "3". I think this is the reason why the EasyTrigger does not work when I try use the VD-status to change the fan speed in the z-wave device.

    If I do the changes directly in the HS-VD then the status-value-pair are in sync, but not if the change is initiated from the other MQTT-client.

    If I go one more step and run the "command" &hs.SetDeviceString(132, "", True) the following appears:
    Click image for larger version  Name:	Screenshot 2021-06-21 at 10.37.33.png Views:	0 Size:	280.9 KB ID:	1480423 Now the value and status pair is in sync. To me it looks like the MQTT-plugin sets the device string/label instead of the device status when receiving a subscribed payload?

    Leave a comment:


  • Michael McSharry
    replied
    The significant lines from the $$STATUS debug are below. You have both value and string events checkboxes enabled so you get two events and two publish for each action. This ends up sending a number and a string to the publish topic that is setup. I suspect you will want to only send

    $$STATUS is a replacement variable that uses mcsMQTT VSP. Since mcsMQTT does not have VSP for non-plugin devices I do not expect anything deterministic to happen when it is used. $$LABEL and $$VALUE have context with HS.

    What I did do with the attached is first look to see if HS has a status to report and will use that otherwise the plugin will use the text on the control for the case of the $$LABEL: replacement. $$LABEL: or $$VALUE: are the only two that you should be using for non-plugin devices in the publish template. You should only be using the DeviceValue trigger for things that have VSP's setup in HS.

    Let me know if this works better for you. Can you also explain why Easy Trigger is sensitive to what you have setup in mcsMQTT. Everything should be based on the the DeviceValue.

    Code:
    start max to to med
    19/06/2021 18:09:01 44059 | HSEvent VALUE_CHANGE| 1024| | 5| 3| 132
    19/06/2021 18:09:01 44064 | Publish TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP=5
    
    string change event to med
    18:09:01 44070 | HSEvent STRING_CHANGE| 64| | med| 132
    19/06/2021 18:09:01 44070 | Publish TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP=med
    19/06/2021 18:09:01 44070 | ActOnMessageForTrigger QueueSize=0 ,Topic TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP/set,Payload med
    
    change to min
    
    8:09:04 46648 | HSEvent VALUE_CHANGE| 1024| | 1| 5| 132
    19/06/2021 18:09:04 46649 | Publish TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP=1
    
    18:09:04 46657 | HSEvent STRING_CHANGE| 64| | min| 132
    19/06/2021 18:09:04 46657 | Publish TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP=min
    19/06/2021 18:09:04 46658 | ActOnMessageForTrigger QueueSize=0 ,Topic TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP/set,Payload min
    
    change to max
    
    18:09:06 48978 | HSEvent VALUE_CHANGE| 1024| | 3| 1| 132
    19/06/2021 18:09:06 48980 | Publish TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP=3
    
    18:09:06 48987 | HSEvent STRING_CHANGE| 64| | max| 132
    19/06/2021 18:09:06 48987 | Publish TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP=max
    19/06/2021 18:09:06 48988 | ActOnMessageForTrigger QueueSize=0 ,Topic TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP/set,Payload max
    
    change to med
    
    18:09:08 50799 | HSEvent VALUE_CHANGE| 1024| | 5| 3| 132
    19/06/2021 18:09:08 50801 | Publish TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP=5
    
    18:09:08 50808 | HSEvent STRING_CHANGE| 64| | med| 132
    19/06/2021 18:09:08 50808 | Publish TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP=med
    19/06/2021 18:09:08 50808 | ActOnMessageForTrigger QueueSize=0 ,Topic TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP/set,Payload med
    
    change to max
    
    18:09:13 55969 | HSEvent VALUE_CHANGE| 1024| | 3| 1| 132
    19/06/2021 18:09:13 55971 | Publish TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP=3
    
    18:09:13 55980 | HSEvent STRING_CHANGE| 64| | max| 132
    19/06/2021 18:09:13 55980 | Publish TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP=max
    19/06/2021 18:09:13 55980 | ActOnMessageForTrigger QueueSize=0 ,Topic TNi3/mcsMQTT/Struktur/Setpunkter/SystViftCP/set,Payload max

    Leave a comment:


  • tnesheim
    replied
    Finally, just for the reference, this is my top view setup:

    The blue fan is a tri-state switch that reflects(number of solid blades) the state of the HS-VS, or if I press the fan sends a state to the HS-VD. The HS-VD is in turn used in various events in HS.

    Leave a comment:


  • tnesheim
    replied
    I will now restart the mcsMQTT-plugin and start logging. The VD-device starts with the initial value "max", and I will press med-min max-med-min max
    The following attachemts will have logs using "MQTT Publish Payload Template" =

    $$STATUS: Here the "VD status field" in the VD-GUI (first snap in post #16) follows the press of the buttons. The broker respons correspondingly, Works ok in the first cycle, going from initial max -> med -> min -> max -> med -> no response(does not show min, stays at med). To me it looks like the state with the lowest value stops working after one assertion., similar to the start of this poste where I refere to "off" not working.

    $$VSP: no reaction in "VD status field" nor broker

    $$LABEL: continuous working behaviour in both "VD status field" and broker. (as earlier stated the $$LABEL option is not compatible with EasyTrigger)


    Using the $$STATUS-option worked fine from around des20/jan20 where we had a few "debug sessions" and you issued several fixes. I think it was after the "blacklist feature" the problems started..or atleast when I noticed the problem.
    Attached Files

    Leave a comment:


  • tnesheim
    replied
    Hi
    Here is a detailed description of the "whole thing":

    The VD:
    Click image for larger version

Name:	Screenshot 2021-06-19 at 18.02.17.png
Views:	49
Size:	20.6 KB
ID:	1480186
    with the following device settings:
    Click image for larger version

Name:	Screenshot 2021-06-19 at 18.03.23.png
Views:	48
Size:	216.9 KB
ID:	1480187
    and the corresponding MQTT-setup:
    Click image for larger version

Name:	Screenshot 2021-06-19 at 18.04.42.png
Views:	45
Size:	481.5 KB
ID:	1480188

    Leave a comment:


  • Michael McSharry
    replied
    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.

    Leave a comment:


  • tnesheim
    replied
    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

    Leave a comment:


  • Michael McSharry
    replied
    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

    Leave a comment:


  • tnesheim
    replied
    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.

    Leave a comment:


  • Michael McSharry
    replied
    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.

    Leave a comment:


  • tnesheim
    replied
    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

    Leave a comment:

Working...
X