Adding HS Control Buttons.... Still resisting controlling

[LZHenry]

With your past training and suggestions things are starting to "sink in". Did a LOT of reading of the manual and NOW many things make sense.

Last item...should be something fundamental I missed.

Can not get the HS control buttons to CONTROL States

MQTT message arrives with four values; 0,1,2,3
Device created using "a"
Enter a publish topic
Select "Button" radio box
Enter substitution relationships for the values in the VSP box:
0=0;Zero
1=1;ONE
2=2;TWO
3=3;THREE

YES... HS device changes values based on incoming MQTT message
NO ...value will NOT change while using a "button" (or when changed to "List" definition)


Configuring the "wrong" way, by creating control buttons using the HS device menu results with working controls.

Please, I must be missing something very easy... LZH

[Michael McSharry]

What was different from what mcsMQTT setup in HS for the four VSP states vs. what you did to make it work?

[LZHenry]

Went to take a Saturday nap and with a clear mind solved my oversight.

Result: A mcsMQTT device that has command buttons does not command/change the "local HS device value" but issues a publish. The receiving device is then responsible for a response to HS to change the value. Not the way I wanted it to work, but I will adapt.

Michael, I think I can leave you alone to tackle real issues; thank you for responding to these questions this week. I would not now have a properly working communication without your kind help. If you can think of testing help you may need with new features, let me know. LZH

[qwiksilver96]

Went to take a Saturday nap and with a clear mind solved my oversight.

Result: A mcsMQTT device that has command buttons does not command/change the "local HS device value" but issues a publish. The receiving device is then responsible for a response to HS to change the value. Not the way I wanted it to work, but I will adapt.

Michael, I think I can leave you alone to tackle real issues; thank you for responding to these questions this week. I would not now have a properly working communication without your kind help. If you can think of testing help you may need with new features, let me know. LZH

I have struggled with this for several days to now find this explanation. I don't understand why a device that was created by the plugin does not update the device's value. I see an entry in the HS log stating: "Device Control Device: Virtual Test to On (1) by/from: CAPI Control Handler" yet the device status does not change to reflect the VSP and VGP configured in the Graphics tab. The advanced tab shows no change in the Value or Status fields. Shouldn't the device value and status reflect the button presses?

Frank

[qwiksilver96]

screenshots...

[Michael McSharry]

mcsMQTT will update DeviceValue using the payload received in the subscribe topic.
mcsMQTT will send a MQTT message to the publish topic when the device is commanded to change (via CAPI) such as with the button on HS Devices/deviceutility page

The system concept is that sending a message will be recognized by the receiving widget that will update its hardware output and publish a status update. This status update will be received by mcsMQTT to update DeviceValue so HS reflects the state of the widget's hardware output. The intent is that HS is always in sync with the status of the hardware that is using these subscribe and publish topics.

If you manually create a virtual device with a pair of buttons then HS owns the "hardware" that this virtual device represents. When you command it to change then HS recognizes it owns the "hardware" associated with this device. Being virtual the only thing it needs to do is update status (DeviceValue) to reflect the commanded state.

In your case you do not have a widget this is updating status on the ha/cmnd/test topic based upon it subscribing to topic ha/stat/test. If I take the leap and assume you are trying to communicate between HA and HS so that HS is able to control something in HA then HA will need to publish on ha/stat/test the updated status following receipt of the ha/cmnd/test topic. If this is not happening then HS has no way to know what the status of device 744 should be. It could guess that HA is alive and well and has acted upon the ha/cmnd/test request, but this would lead to uncertainty if HS is actually reflecting what HA has.

[qwiksilver96]

mcsMQTT will update DeviceValue using the payload received in the subscribe topic.
mcsMQTT will send a MQTT message to the publish topic when the device is commanded to change (via CAPI) such as with the button on HS Devices/deviceutility page

The system concept is that sending a message will be recognized by the receiving widget that will update its hardware output and publish a status update. This status update will be received by mcsMQTT to update DeviceValue so HS reflects the state of the widget's hardware output. The intent is that HS is always in sync with the status of the hardware that is using these subscribe and publish topics.

If you manually create a virtual device with a pair of buttons then HS owns the "hardware" that this virtual device represents. When you command it to change then HS recognizes it owns the "hardware" associated with this device. Being virtual the only thing it needs to do is update status (DeviceValue) to reflect the commanded state.

In your case you do not have a widget this is updating status on the ha/cmnd/test topic based upon it subscribing to topic ha/stat/test. If I take the leap and assume you are trying to communicate between HA and HS so that HS is able to control something in HA then HA will need to publish on ha/stat/test the updated status following receipt of the ha/cmnd/test topic. If this is not happening then HS has no way to know what the status of device 744 should be. It could guess that HA is alive and well and has acted upon the ha/cmnd/test request, but this would lead to uncertainty if HS is actually reflecting what HA has.

Thank you for the response Michael and a HUGE THANK YOU for your contribution to the HS community, and all without asking for compensation. I very much appreciate what you contribute!

Here's what I am trying to achieve:

1. I add a Tasmota device to my network and configure it for use with MQTT and specific topic / payload structure. This could be true for any MQTT enable device.
2. I publish and on and off payload via the device topic
3. Go to homeseer and open the MQTT plugin "Associations" tab and filter on the topic for the device.
4. Tick the "a" box for the topic received for that specific device
   1. This then creates the device in HS
   2. I subsequently configure the device parameters such as room, etc in the MQTT plugin config page for that specific device by clicking on the "REF" button
   3. I see that the VSP is correctly created and then go to "Device Management" and open the properties for the newly created device and verify everything appears to be configured correctly.
5. I then go back to the "Device Management" dashboard and attempt to turn on / off the device and everything works great. The device switches on and off.

All of this makes sense because the device reports it's status change back to the MQTT plugin and everything works as it should.

How can this same behavior be achieved for a virtual device such as an override switch that is created by the plugin with no physical device associated with this virtual device? I want to mimic an on and off state without a physical device by utilizing the same sequence as 1-5 above. Is that possible? More specifically, when the device state (value) is changed via MQTT OR in HS via the web interface or via an event or a script, I would like for the device to change it's status / value in HS.

Again Michael, THANK YOU for everything you contribute.

Best,
Frank

[qwiksilver96]

Here's a real example I created. When I send either 1 or 0 via topic "ha/virtual/allow_ofc_deskfan_automation", the device value and state do not change. When I click on the "ON" and "OFF" buttons, no change occurs to either state or value.

[qwiksilver96]

But I do see this in the HS LOG:

[Michael McSharry]

I could add a Virtual Control/Status UI or provide Edit tab setting, but then I question why is there a subscribe topic if nothing is going to be received to update HS.

What I suggest is using an HS event to manage either the publish message or the DeviceValue. What I would do is
1.Create a virtual device with HS DeviceManagement that has the control buttons that you want
2. In mcsMQTT associate this non-plugin device and assign a Publish topic
3. When something changes the virtual device from HS then mcsMQTT will see it and publish the message that was setup. HS should manage the DeviceValue of the virtual device.

[qwiksilver96]

I could add a Virtual Control/Status UI or provide Edit tab setting, but then I question why is there a subscribe topic if nothing is going to be received to update HS.

What I suggest is using an HS event to manage either the publish message or the DeviceValue. What I would do is
1.Create a virtual device with HS DeviceManagement that has the control buttons that you want
2. In mcsMQTT associate this non-plugin device and assign a Publish topic
3. When something changes the virtual device from HS then mcsMQTT will see it and publish the message that was setup. HS should manage the DeviceValue of the virtual device.

I send MQTT from a third party android app (MQTT Lens) to control the devices also. It is the main way I control all devices (physical and virtual)

[Michael McSharry]

Should be the same process, but also include the subscribe topic. This will show the topic as being blue rather than pink on the Association and Edit tabs. In essence you want ownership of virtual devices to be HS so HS has responsibility to update DeviceValue based upon any source of change request.

How many virtual devices do you have that you want to be MQTT-enabled?

[qwiksilver96]

Okay, I was able to get it working. The key is sending and receiving on the same topic AND setting the publish template to $$VALUE:

I was also able to configure the VSP and VSG by using the 2nd format detailed in the ToolTip that pops up for the "Publish Payload Template" text box. I apologize for taking your time Michael for somethings that I should have been able to figure out on my own. I was up late last night and wasn't thinking too clearly. Once I slept on it and took some time to work through it, I managed to get it working perfectly.

Thank you again Michael.

Frank

[qwiksilver96]

Should be the same process, but also include the subscribe topic. This will show the topic as being blue rather than pink on the Association and Edit tabs. In essence you want ownership of virtual devices to be HS so HS has responsibility to update DeviceValue based upon any source of change request.

How many virtual devices do you have that you want to be MQTT-enabled?

I may have dozens when all is said and done. I like a lot of control over my automations and virtual devices can provide that control.

[Michael McSharry]

Okay, I was able to get it working. The key is sending and receiving on the same topic AND setting the publish template to $$VALUE

I had not considered that route. Just shows two heads are better than one.