Control devices problem with sub and pub

[frankis78]

I have been using this plugin for a while and it works great.
But i find my self ending up only using the plugin to publish and recieve messages, instead of adding devices to the subscription, but instead creating a virtual device to interact with the payloads.

The reason is for example.
I recieve a Sub message, and i create a device from that, with buttons.
That create example a device with following buttons:
0 Locked
1 Unlocked
2 Not locked

To be able to control it, and also after all if imperihome should recognize it as a lock, i would need to use 0 and 100
So i would need
0 Unlock
100 Lock

Can anyone tell me how to manage status and commands in the same Sub/Pub device? Since Sub have example Unlocked but we want to send Unlock back.

Cause i have always problem to deal with statuses that is different than the command. (I understand if a Sub send ON, then you simply send ON or OFF back, cause it is the same)

If anyone can shed a glance on this i would be greatful, else i will continue to create virtual devices/events :-)

[Michael McSharry]

I think the explanation at https://forums.homeseer.com/forum/li...ds-status-only will answer your question. If not then we can continue the discussion.

In essence use the Value Status Pair definitions to match your needs. Your status states (text ends in "ED") are reported by an external node. mcsMQTT creates a numeric association with each to map into HS3. The numeric values have no particular significance so you can change them to whatever. For example use numbers 1,2 and 3. This is done on the Edit tab of the subscribed device in mcsMQTT. Change LOCKED from 0 to 3. Look at tool tip or manual for syntax to change/delete/add association values.

You want specific numbers for control which in your case are LOCK=0, UNLOCK=100. You do this from HS Device Management for the same mcsMQTT-created device that now has 3 status states of LOCKED, UNLOCKED and NOT LOCKED. Add two new status 0=LOCK and 100=UNLOCK. Make the original 3 status-only and the two new ones control. This should result in 2 buttons on the GUI. You may need to edit the Value Graphics Pair to get the graphics you want for the two control buttons.

When you click a button the MQTT message will have a payload of 0 or 100. When the node reports its status change it will return something like UNLOCKED for which mcsMQTT will store a value of 1 in HS3 and HS3 will show UNLOCKED in the status for the device on the browser page.

[frankis78]

Thanks,
Just for clearifying,
1. Create a device on the Sub and then enter the mcsMQTT-created device
- HS Device Control/Status UI : should this be button or text or unspecified?
- HS Device VSP List : remove and recreate the Sub statuses with other numbers, like 3,4,5
- HS Device MISC Properties : Tick the button "status only"
- Add a publish payload template

2. Go to the homeseer device and you will see values already made as status 3,4,5
- Create 2 new statuses with control functions 0 Unlock , 100 Lock

[Michael McSharry]

mcsMQTT has been collecting topic payloads so when the Accept checkbox is selected it will normally have the device type assigned to List type. This means a list of Value-Status-Pairs that are status-only. This is the best place to start so if List type is not selected then make that selection and complete the VSP text box by adding or editing the values of those that are assigned. In the prior example you would enter "Locked=3" in the VSP text box to change the value from 0 to 3.

You should not need to use the MISC properties if List type is selected.

If you leave the payload template blank then it will publish the DeviceValue which I think is what you desire. If you want it to publish "Lock" then use "$$STATUS:" for the payload template.

Otherwise you are correct in your description of the process. You may be able to do it other ways such as with MISC button and different device types. I just don't remember what limits HS provides from Device Management on what can be user-edited vs. plugin-edited.

[frankis78]

All works ok, until i add something in HS Device Publish Topic
Then i get this dropdown:


So final question is: Can i manually change it from control to status, and add my own control statuses?
Sorry for asking, but i dealt a bit with this earlier, with what i can change, and not change, based on what mscMQTT have created and not, which in the end broke the mscMQTT created device.
I mean since mscMQTT have created these control functions based that it see a publish payload template, then im afraid it will break when i remove these functions and add my own.

[Michael McSharry]

I just did a test to refresh my memory. A few things that are different than my original guidance.
For payload template the default is Status, so if you want number published then use $$VALUE: for the payload template.
The device type should be Button if you want buttons in the GUI. It should be List if you want the pulldown list.
The Device Management edits give you full control of the Status-Control. You should use status for the "ED" states. You should use control for the Lock/Unlock states.

You first need to use VSP box on mcsMQTT to change the UNLOCKED to be a non-zero value pairing. You want 0 to be available for Device Management addition for UNLOCK.
I do not know if it makes any difference, but I set the control use property when adding states in Device Management. I used off and on, but others are available.

[frankis78]

So , finally i also refreshed my memory, why this wouldnt work correctly
So basically all steps is taken, and all works, BUT
When it is the actual lock status that speaks the last word, it changes the buttons, so that they are not active anymore, and in example imperihome, it will will lock the door, but just after it will open the door again, cause the lock is not locked anymore. (Status is not set anymore)
So all in all, it wasnt 0 and 100 that was the problem, cause the actual problem is that status changes after it is set.



I also tested to add status and control as 2 different thing with same value, and still didnt change.



Only way to fix this, is to be able to set a publish payload on the device in the mscMQTT plugin, as that would fix it.
So leave all as it is, and if you have 3 or 4 payload messages recieved, you can decide to set a publish alias on example only 2 of them

[Michael McSharry]

What I think you are suggesting is that the VSP definition in mcsMQTT should be able to recognize UNLOCKED and change it to UNLOCK value that us used to create the button. If I have interpreted your suggestion correctly then I think this capability already exists in mcsMQTT. You would just setup a regular expression to remove the ED from the received payload. This is toward the top of the Edit tab.

From the manual an example is given to remove suffix seconds. In your case seconds would be ED
2. Remove suffix “ seconds” suffix from a Payload of “1234 seconds”
Pattern: seconds
Extract Checkbox: Unchecked
Replace:
Result: 1234
Note: replace suffix of “ seconds” with null. Note alternate method using general rather than specific suffix in next example


I suspect you will need to manually edit the mcsMQTT VSP to add LOCK and UNLOCK, then delete UNLOCKED and LOCKED. In Device Management you will do the same thing you showed in the middle screen shot in your last post with 4 lines and the value of the LOCK and LOCKED being the same and LOCK is control and LOCKED is status.

With this approach there will only be 2 DeviceValues so Imperihome should be happy. The lock node will report LOCKED and UNLOCKED and the regular expression in mcsMQTT will change it to LOCK and UNLOCK before it does the lookup to store the value in HS. What I do not know it how you want to handle the 3rd status state from the lock node.

[frankis78]

I did what you suggested, and it worked. Statuses are ok, buttons are ok, it sends payload.
Probblem now is that it send LOCK instead of lock , so the payload is wrong , since it should be with lowercase.
Then i went into the HS device and tested to change the uppercase to lowercase letters , but after that it doesent send payload at all.
My general finding is that you cannot change anything manually on those statuses/buttons that are created by mcs

Here you can see the first picture that work, but with wrong uppercase letters


Here you can see after i changed it, and when it no longer sends payload




So my suggestion to come around this , is to have a mapping table for ingoing and outgoing messages.
I think this is the only way to fix this, and im sure guys with garage doors etc would be happy, and in this way you could also map a non sence payload to something totally different. Ex "Not Locked" = "Unlocked"

So if you get these native payloads, then change it to :

Native Ingoing: Outgoing:
0 UNLOCKED = Unlock unlock
1 LOCKED = Lock lock

[Michael McSharry]

I can allow a use to specify VSP status and VSP control text. I don't think I can provide multiple status or control text (e.g. Unlock & unlock) because HS will not accept multiple text for the same value.

Another approach is to remove the workaround that I implemented when I was getting the wrong CAPI label from HS on the command. If we assume that HS returns the proper value then this becomes the easiest approach. No regular expression is needed and the user just needs to do the edit in HS Device Management. I showed the setup I tested in the attachments. The plugin update is at http://mcsSprinklers.com/mcsMQTT_3_4_16_1.zip.

                               'hs bug the wrong label is returned, replace it with internal value
                                sValue = oCAPI.Label
                                Dim oList As Dictionary(Of String, Integer) = oMQTT.GetVGP()
                                For Each kvp As KeyValuePair(Of String, Integer) In oList
                                    If kvp.Value = oCAPI.ControlValue Then
                                            sValue = kvp.Key
                                            Exit For
                                    End If
                                Next

So in summary, assuming that none of the things you have been doing the past couple days happened then the VSP values in mcsMQTT would be defined automatically by the plugin as it saw the status responses. The only thing that a user needs to do to have a different control button/text than the status text is to add the two buttons with the desired text in the correct case. Make the original definitions status and the new ones control. The same values will tie the button command and the display status together. When MQTT message is received then mcsMQTT will update the value based upon the mcsMQTT VSP status match and HS will update the status and button highlight. This should be reflected in imperihome too.

[frankis78]

Yes basically this is very simple solution , because the issue before was that when i touched the VSP status created by this plugin, and changed the text/status/control in HS Device, to anything other than the initial VSP , then it failed.
So if you have changed that behavior, and allow us to set another control on the HS Device, then it would be good.
If i understand you correctly, you then leave the VSP as a status (Which shouldnt be changed in HS Device), and then we can add another control to it in HS Device.

I also cannot see why this plugin should do anything else than send and recieve payloads, and leave the control to HS. Which means we can edit the HS Device.
(Maybe there was a bug earlier)

[Michael McSharry]

Earlier it was a workaround because HS was not returning the correct label. I don't know what HS version I was testing or if the behavior was only on Linux. I only tested with Windows today. Early-on it was much learning to figure out what MISC properties were needed to get the desired UI effects. Now know a little more about the HS control and status property implications of the VSP.

[frankis78]

I tried to install the 16_1 version, but it say virus when i download it, so i couldnt download it.

[Michael McSharry]

I just uploaded the latest .exe file at http://mcsSprinklers.com/HSPI_MCSMQTT34164.zip. The updater should also have the prior one.

[frankis78]

Have you done the update in this version compare to the 16_0 version?
Because i tested the 16_0 version, but it sent only the status from the device that was made from msc , and not from the control units that i made (With same value)
But if you have made a change in this 16.4 version, i will test it asap