Push / Pop value of an mcsMQTT owned device?

[ericg]

I'd like to be able to push the value of an mcsMQTT owned device (using EasyTrigger) to a stack, then restore its value later. I have not been able to do this.

(I'm not sure whether I should post this here, or in the EasyTrigger forum.)

My use case: I am using three Athom RGB bulbs (which communicate via tasmota hosted MQTT) as a crude, but effective, system status signaling device. Whenever something new and significant happens, I want it to be announced by a new color code combination of the three lamps. Then, when the new situation has been dealt with, I'd like the bulbs to again display whatever they were showing originally.

After much stumbling, I can now make the three bulbs display whatever I want, using the Power and HSBColor commands. To test the push/pop feature, I first set a bulb green, pushed the cmnd Power device, and set the bulb to red. Ten seconds later, I popped the device value, hoping that the bulb would still remain lit:



When I run the event, the bulb changes immediately to red, but 10 seconds later, the bulb is turned off. This is unexpected, as I thought I was pushing a "power on" status, which should have popped to continue with power on. I can control the device power reliably via On/Off/Blink buttons on the HS Device Management page. (I want to push and pop HSB color status also, but I thought I'd start with power. Baby steps.)

So, is there a bug somewhere, and if so, is there a reasonable workaround? Am I trying to use a feature that doesn't exist? And is this an mcsMQTT issue, or an EasyTrigger issue?

Thanks for any assistance.

[Michael McSharry]

I assume your push operation is to save the DeviceValue and t he pop operation is to retrieve it.

To send MQTT messages you can command a DeviceValue change through the CAPI interface such is done when you make a selection on the HS Devices page. A second method is to use HS Event with Send MQTT Message Action. The third is via scripting.

If I recall correctly, Tasmota color control is via JSON payloads. When using CAPI mcsMQTT will typically format the JSON based upon the Edit tab entries for Publish Payload Template and Control/Status UI. When using the other two methods the user will need to format the JSON payload to what Tasmota is expecting.

I am traveling until the 18th so do not have access to my system to evaluate specific tests. I can try to help when available until then. mcsMQTT.pdf also has much describing the process for sending MQTT messages.

[Michael McSharry]

Another piece of pertinent information is that the HS Color Picker control provides a RRGGBB representation of the color in CAPI ControlString. This means you will be pushing and popping this representation of the light's color since ControlString and not ControlValue are used by the Color Picker.

[ericg]

Thanks, Michael McSharry , I sincerely appreciate your efforts to help me. I'll be looking at your posts carefully, but at first reading, I'd like to make a few observations:

• I am completely satisfied with my basic device monitoring and control of the RGB bulb. A bulb's entries on my Device List page looks like this:

The color picker on Ref 544 is working fine. I can change the hue with the slider for Ref 545. The Ref 546 slider changes the saturation as expected, and the Ref 547 brightness function is controlled quite well by its slider. Whatever the current HSB combination, I can turn the bulb on or off, or even blink it via the buttons of Ref 503. So, I can do all the basic things I want from the HS Device Management page.

• Similarly, I have a collection of events defined to turn on/off the bulb, set its HSB parameters, control blinking, etc. The events accomplish this via the the Send MQTT Message option on the dropdown list. Events are all good.
• So far, I don't use scripting, don't much care about it.
• The mcsMQTT Edit page indicates that the Ref 503 payload (power, not color) is indeed stored in HS Device Value, not the string. So it seems reasonable to push/pop that device value as desired:

• My only problem is this: Ref 503 has a value of either 0, 1, or 3, corresponding to the three buttons shown. Ref 503 was created by mcsMQTT. It functions as both control and status. I'm thinking that I should be able to use the EasyTrigger Push event action to save the current state of Ref 503. Then I mess around, do whatever I like with the bulb. When I'm done, I execute the EasyTrigger Pop event action, expecting Ref 503 to assume the value it had just prior to the push. In actuality, when I do the Pop event action, Ref 503 is always set to 0 (Off), rather than the value it had when I did the Push.

In conclusion, If I use the CAPI buttons to set the value of Ref 503, the appropriate control message goes to the bulb, and it does what is expected. If I use Send MQTT Message in an event to exercise similar control, Ref 503 display is updated, and the bulb responds as expected. I would think that I could (EasyTrigger) push the value of Ref 503 in an event, and restore that value at some later time. Actually, I can try to push anything, but what gets restored is 0 (Off).

I haven't even tried to push / pop colors yet.

[Michael McSharry]

Thank You for the fully explanation and the screen shots. I do not use Easy Trigger so do not know what its Push and Pop actions actually do. Based upon their name it seems reasonable that the plugin implements LIFO stack and seems that it would put DeviceValue on the stack. For this one POWER/On-Off-Blink case it looks as if you have isolated the problem with the push/pop action of with your expectation of how it should work vs. how it works.

Since you are using the MQTT Send Message approach to publish messages then you already have the formatting worked out. Once you prove the concept with POWER it should apply in the same manner for others.