EasyTrigger Push/pop Fails for mcsMQTT Device

[ericg]

I am unable to use the EasyTrigger push/pop event actions for devices created by mcsMQTT. I have documented the problem in the mcsMQTT forum; the most relevant post is here:

https://forums.homeseer.com/forum/li...65#post1488965

I started in the mcsMQTT forum because, on balance, it seemed that the problem related to the mcsMQTT plug-in. However, I really don't know whether my push/pop failure is embedded in mcsMQTT, or in EasyTrigger, or possibly in my own head. I have previously used EasyTrigger push/pop device values quite successfully in other contexts.

While I have great praise for mcsMQTT and its author Michael McSharry , Michael has limited ability to assist because he doesn't use EasyTrigger.

Is there anyone in this forum, hopefully conversant with both plug-ins, who might be able to help?

Thank you.

Current Date/Time: 8/13/2021 8:08:55 AM
HomeSeer Version: HS3 Pro Edition 3.0.0.548
Linux version: Linux hometrollerSEL 3.16.0-031600-generic #201408031935 SMP Sun Aug 3 23:56:17 UTC 2014 i686 i686 i686 GNU/Linux System Uptime: 4 Days 11 Hours 28 Minutes 4 Seconds
IP Address: 192.168.1.105
Number of Devices: 397
Number of Events: 295
Available Threads: 199
HSTouch Enabled: True
Event Threads: 2
Event Trigger Eval Queue: 0
Event Trigger Priority Eval Queue: 0
Device Exec Queue: 0
HSTouch Event Queue: 0
Email Send Queue: 0

Enabled Plug-Ins
1.0.0.166: Arduino Plugin
1.38.0.0: Big5
2.0.61.0: BLBackup
2.0.45.0: BLLAN
3.0.38.0: BLLock
1.0.1.0: BLTEDPro
3.1.3.0: Device History
3.0.0.73: EasyTrigger
5.17.3.2: mcsMQTT
3.0.2.22: OMNI
3.0.6644.26753: UltraLog3
3.0.1.252: Z-Wave

[spud]

Please set the log level to Debug from the EasyTrigger config page, then run your event. That will allow to see what value is pushed to the stack, and to waht value the plugin is trying to set the device after the pop.

[ericg]

spud , thanks for your quick response.

First, I must report that the original problem has gone away, and at the moment, I cannot explain why. But for now, at least, I can push and pop the bulb's power device reliably.

I am trying to use push/pop to save the current state of an RGB bulb so that I can temporarily command other values for power, hue, saturation, and brightness. Then I want to pop back to the original configuration. I believe there are two HS devices that I need to save and restore: power, and HSB color. The power device is the one that is suddenly push/pop working OK. I may have done something to make it work, but nothing comes to mind.

So I set up to test the other HS device (Ref 544), the value of which controls color. I set an arbitrary color for the bulb on the HS Device Management page, set EasyTrigger logging to debug mode (per your advice), then ran this event:



The bulb turned green, as expected, and 3 seconds later, it extinguished -- as not expected.

Here is the resultant EasyTrigger log information, filtered to include just the Bulb1 HSBColor (Ref 544) entries:


The last log entry shows the HSBColor being set to 0 (essentially off, 0 brightness), rather than the value 16711680 that was originally pushed.

If you need more information, please advise. Thanks.

[Michael McSharry]

I'm just an observer here, but two observations. They may or may not help the discussion.

1. The Pop action does a SetDevice. SetDeviceValue cannot be used to affect the desired change or a plugin device. It only applies to virtual devices or special cases where other tricks are being done. EasyTrigger must use a CAPI command to control plugin devices.
2. The Pop action will pop DeviceValue off of the stack. Controlling a Color Picker type device requires the CAPI control to be ControlString (hex string RRGGBB) and not ControlValue.

[spud]

I'm just an observer here, but two observations. They may or may not help the discussion.

1. The Pop action does a SetDevice. SetDeviceValue cannot be used to affect the desired change or a plugin device. It only applies to virtual devices or special cases where other tricks are being done. EasyTrigger must use a CAPI command to control plugin devices.
2. The Pop action will pop DeviceValue off of the stack. Controlling a Color Picker type device requires the CAPI control to be ControlString (hex string RRGGBB) and not ControlValue.

1. The pop action actually does use a CAPI command to try to control the device. If a control with this value does not exist it just does a SetDeviceValue. So I don't think that's the problem here.
2. You're right push/pop only work with values, not strings, so it won't work with color picker controls. I think that's the problem. ericg you may want to try to use the Hue/Saturation/Brightness devices to use with the push/pop actions to set the color of this device instead of using the color picker device.

[Michael McSharry]

What I did with HS3 mcsMQTT plugin is to see if ControlString is null and in that case use the ControlValue for the device that is setup with a color picker control. The assumption being made is that the CAPI control used by EasyTrigger will have a null entry for the ControlString property.

The updater package is at http://mcsSprinklers.com/mcsMQTT_5_18_0_2.zip. The updater override process can be used to install it. One of the places that describes this process is the first post at https://forums.homeseer.com/forum/hs...es-to-influxdb. Rather than this you can just install the twofiles that were updated and placed at http://mcsSprinklers.com/mcsMQTT_51802.zip Unzip them into the \bin\mcsMQTT folder.

If Hue, Saturation, and Brightness are individually updated then Tasmota will receive three different commands and will see some funny color effects with the first two. I have also experienced issues with a zigbee color bulb that was commanded to different states too quickly.

[ericg]

1. The pop action actually does use a CAPI command to try to control the device. If a control with this value does not exist it just does a SetDeviceValue. So I don't think that's the problem here.
2. You're right push/pop only work with values, not strings, so it won't work with color picker controls. I think that's the problem. ericg you may want to try to use the Hue/Saturation/Brightness devices to use with the push/pop actions to set the color of this device instead of using the color picker device.

spud , I tried your suggestion, and it worked! I can now push/pop separately (and reliably) not only the three HSB devices, but also the power control. That's a major step forward.

I tried organizing the above four parameters as an EasyTrigger group, hoping to push/pop the entire group with a single event action. That didn't work very well, but I think the problem traces to the bulb and its tasmota/MQTT code -- timing problems. So I built a Push Bulb event that pushes each of the four devices separately, and a matching Pop Bulb event that pops each device separately. Still no joy, but still ascribed to timing issues inside the bulb. I modified the Pop Bulb event to insert a 0.2 second delay between pops, and voila! The whole thing is now working almost perfectly. I say almost, because those 0.2 second delays create a "partially popped" visible effect that isn't too cool; but that's a minor problem.

Thanks so much for your help.

[ericg]

What I did with HS3 mcsMQTT plugin is to see if ControlString is null and in that case use the ControlValue for the device that is setup with a color picker control. The assumption being made is that the CAPI control used by EasyTrigger will have a null entry for the ControlString property.

The updater package is at http://mcsSprinklers.com/mcsMQTT_5_18_0_2.zip. The updater override process can be used to install it. One of the places that describes this process is the first post at https://forums.homeseer.com/forum/hs...es-to-influxdb. Rather than this you can just install the twofiles that were updated and placed at http://mcsSprinklers.com/mcsMQTT_51802.zip Unzip them into the \bin\mcsMQTT folder.

If Hue, Saturation, and Brightness are individually updated then Tasmota will receive three different commands and will see some funny color effects with the first two. I have also experienced issues with a zigbee color bulb that was commanded to different states too quickly.

Michael McSharry , if I'm a little slow here, please forgive me. I'm running mcsMQTT version 5.17.3.2. Does your post mean that you have just made a change (version 5.18.0.2) that might make it possible to push and pop my HSBColor color picker device? And if so, will I see this version shortly on the HS3 Plug-ins Manage page? Which version do you recommend I use?

Thanks.

-Eric

[Michael McSharry]

Yes install the 5.18.0.2 and it has the logic change to use ControlValue if ControlString is null. This should make it compatible with EasyTrigger, assuming EasyTrigger does leave ControlString null.

[Guest]

ericg, if you want to avoid the "partially popped" visible effect and don't mind some scripting, another option is to use the "color" topic and virtual devices to push/pop colors.
I use this approach to set/store/call "presets" in HStouch. It uses string instead of values so I don't think Easytrigger could be used unless Spud updates the PI.

See device details & video example below:



https://www.youtube.com/watch?v=6lvS1AVHZDg

it could probably be adapted to your use case with some minor changes.
Let me know if interested, I can share code.

Cheers,

[ericg]

What I did with HS3 mcsMQTT plugin is to see if ControlString is null and in that case use the ControlValue for the device that is setup with a color picker control. The assumption being made is that the CAPI control used by EasyTrigger will have a null entry for the ControlString property.

The updater package is at http://mcsSprinklers.com/mcsMQTT_5_18_0_2.zip. The updater override process can be used to install it. One of the places that describes this process is the first post at https://forums.homeseer.com/forum/hs...es-to-influxdb. Rather than this you can just install the twofiles that were updated and placed at http://mcsSprinklers.com/mcsMQTT_51802.zip Unzip them into the \bin\mcsMQTT folder.

If Hue, Saturation, and Brightness are individually updated then Tasmota will receive three different commands and will see some funny color effects with the first two. I have also experienced issues with a zigbee color bulb that was commanded to different states too quickly.

Michael McSharry , I have installed the two files you supplied. Outwardly, the results are the same as before; but I see no improvement.

(I apologize for taking this long to test. I'm something of a coward about stuffing new files into HS, mainly because my Linux skills are rudimentary, and I worry that I might do something to brick my Hometroller SEL.)

Here is a snapshot of the mcsMQTT folder after I replaced with the two files you gave me:


Here is the (debug mode) EasyTrigger log of what happened when I ran the same test script (Post #3):


What immediately followed in the HS log is this:


That's a statement of what I wanted to happen, but the value in (Ref 544) HSBColor just never got changed. The device details (Advanced tab) showed in Status and Value the green value I set after the initial push, nothing in String.

So, the only difference I see is that the original log had an EasyTrigger entry (last figure in Post #3) reported "Device 544 value changed from 65280 to 0." This log entry is now missing, replaced by a new CAPI entry (shown above).

Does that give you any ideas?

EDIT: I changed browser settings, replaced the screenshots that people were unable to see.

[Michael McSharry]

Your screenshots are not visible on my browser. Another good source of information is the mcsMQTT Debug rather than the HS Log as this should provide more visibility under the hood.

[ericg]

Michael McSharry , I'm sorry you can't see my screen shots -- that's tough. I use Chrome and MS Edge, and I have successfully displayed posts in question on both browsers. If there is some way I can accommodate, please let me know.

I took your advice to test with mcsMQTT Debug enabled. I got a log file whose interpretation is beyond me:

mcsMQTT Debug.txt

Anything else I can do?

[TC1]

Michael McSharry , I'm sorry you can't see my screen shots -- that's tough. I use Chrome and MS Edge, and I have successfully displayed posts in question on both browsers. If there is some way I can accommodate, please let me know.

FYI, I'm using the latest Chrome and I can't see the pictures either.

[ericg]

ericg, if you want to avoid the "partially popped" visible effect and don't mind some scripting, another option is to use the "color" topic and virtual devices to push/pop colors.
I use this approach to set/store/call "presets" in HStouch. It uses string instead of values so I don't think Easytrigger could be used unless Spud updates the PI.

See device details & video example below:



https://www.youtube.com/watch?v=6lvS1AVHZDg

it could probably be adapted to your use case with some minor changes.
Let me know if interested, I can share code.

Cheers,

Thanks for your contribution. As "keep it simple" policy, I try to avoid scripts as much as possible. The "partial pop" effect doesn't bother me much, though it would be nice to eliminate it. I'm still investigating possibilities.

I'll keep your offer in mind. Thanks again.