RGB Light Control - STAT's Fine, CMND Doesn't work

[Jeeves]

I am doing ToHex and FromHex on publish and receive;

Based on the log: it gets the Hex #1c44a3 converts it to 1852579 (which is within the range of 1-16777215) and pushes that to the Device #1121.
However, the log says Range=0 to 0, which doesn't match the UI.

nValue=0, ControlValue=0, Range=0 to 0

03/03/2021 18:46:10 2905228 | Update Accepted 1121 to #1c44a3 StatusType=0 Payload=#1c44a3 RegExValue=#1c44a3
03/03/2021 18:46:10 2905228 | Update Accepted 1121 to #1c44a3 StatusType=0 Payload=#1c44a3 RegExValue=#1c44a3
03/03/2021 18:46:10 2905234 | Non-plugin Update Expression <<FromHex("$$PAYLOAD:")>> on payload #1c44a3
03/03/2021 18:46:10 2905236 | ApplyExpression FromHex("#1c44a3") Result=1852579
03/03/2021 18:46:10 2905236 | Substituted Payload 1852579, Expression Result 1852579
03/03/2021 18:46:10 2905254 | Command nonPlugin Device 1121 to 1852579
03/03/2021 18:46:10 2905254 | Command 1121 to 1852579, nValue=0, ControlValue=0, Range=0 to 0, ControlType=ColorPicker, ControlString=, Label=, ControlUse=ColorControl, UpdateLastChange=False
03/03/2021 18:46:10 2905254 | Command nonPlugin Device 1121 to 1852579
03/03/2021 18:46:10 2905254 | Command 1121 to 1852579, nValue=0, ControlValue=0, Range=0 to 0, ControlType=ColorPicker, ControlString=, Label=, ControlUse=ColorControl, UpdateLastChange=False

All said; Device 1121 doesn't change.

[Michael McSharry]

The plugin iterates through all the CAPI controls defined for device 1121. The lines that contain "ControlType=" contain the information from the CAPI control that describes the control of the device. In the debug code I see I showed the min twice rather than the min and max, but we can assume the max is 16777215 based upon the HS screen shot. This is only cosmetic debug info that has been fixed.

The issue appears to be that the payload value (nValue) rather than the result of the expression (sValue) is being used. Give the attached a try. It goes in the \bin\mcsMQTT folder for the HS4 mcsMQTT plugin. Restart plugin after replacing it.

[Jeeves]

The plugin iterates through all the CAPI controls defined for device 1121. The lines that contain "ControlType=" contain the information from the CAPI control that describes the control of the device. In the debug code I see I showed the min twice rather than the min and max, but we can assume the max is 16777215 based upon the HS screen shot. This is only cosmetic debug info that has been fixed.

The issue appears to be that the payload value (nValue) rather than the result of the expression (sValue) is being used. Give the attached a try. It goes in the \bin\mcsMQTT folder for the HS4 mcsMQTT plugin. Restart plugin after replacing it.

Replaced the file; Restarted the plugin. No value change in HS4. The cosmetic bug is fixed however. No reference to sValue is seen.

Here's the output:

03/03/2021 21:25:31 206327 | Update Accepted 1121 to #90a31b StatusType=0 Payload=#90a31b RegExValue=#90a31b
03/03/2021 21:25:31 206333 | Non-plugin Update Expression <<FromHex("$$PAYLOAD:")>> on payload #90a31b
03/03/2021 21:25:31 206335 | ApplyExpression FromHex("#90a31b") Result=9478939
03/03/2021 21:25:31 206335 | Substituted Payload 9478939, Expression Result 9478939
03/03/2021 21:25:31 206359 | Command nonPlugin Device 1121 to 9478939
03/03/2021 21:25:31 206359 | Command 1121 to 9478939, nValue=0, ControlValue=0, Range=0 to 16777215, ControlType=ColorPicker, ControlString=, Label=, ControlUse=ColorControl, UpdateLastChange=False
03/03/2021 21:25:31 206365 | ActOnMessageForTrigger QueueSize=0 ,Topic cmnd/hs4/master/rgb/color,Payload #90a31b

[Michael McSharry]

I tested it this time. All looks good to me with the attached.

[Jeeves]

I tested it this time. All looks good to me with the attached.

The log looks much better:

Command 1121 to 10527517, nValue=10527517, TargetValue=0, Range=0 to 16777215

However I'm getting an error. The HS device value does not change.

03/04/2021 12:59:29 52509 | Non-plugin Update Expression <<FromHex("$$PAYLOAD:")>> on payload #a0a31d
03/04/2021 12:59:29 52573 | ApplyExpression FromHex("#a0a31d") Result=10527517
03/04/2021 12:59:29 52573 | Substituted Payload 10527517, Expression Result 10527517
03/04/2021 12:59:29 52577 | Command nonPlugin Device 1121 to 10527517
03/04/2021 12:59:29 52577 | Command 1121 to 10527517, nValue=10527517, TargetValue=0, Range=0 to 16777215, ControlType=ColorPicker, ControlString=, Label=, ControlUse=ColorControl, UpdateLastChange=False, bUpdateValue=True, HSValue=2007886
03/04/2021 12:59:29 52579 | HSEvent LOG| 2| 03/04/2021 12:59:29| Warning| Error during SendControlForFeatureByValue - Exception during fDEBUG_PI_CALLS for 1121 : 10527517 - Object reference not set to an instance of an object| | 0| Plugin| 0| 03/04/2021 12:59:29

[Michael McSharry]

This looks to be a message that started with HS having issue with trying to update device 1121 to value of 10527517 in their procedure SendControlForFeatureByValue.

Look in the HS log for more info. Also confirm that feature 1121 works as expected.

[Jeeves]

This looks to be a message that started with HS having issue with trying to update device 1121 to value of 10527517 in their procedure SendControlForFeatureByValue.

Look in the HS log for more info. Also confirm that feature 1121 works as expected.

Feature 1121 works as expected. I can change the color of the light as expected through the HS4 interface.

The only thing shown in HS4 logs is effectively the same entry.

I created two events, one that sets the value by hex, the other that sets it by decimal.
However, when saving the decimal event the event is switched and saved as hex.

[Jeeves]

I also tried to use "SetDeviceValueByRef" with both dec and hex, neither of these worked:




I see some HS3 conversations regarding similar problems;
The only solution provided here, is a work around (convert the hex to RGB, change the RGB values individually):

https://forums.homeseer.com/forum/ho...lor-w-rgb-bulb

[Michael McSharry]

I have a history with mcsMQTT managing color space devices where some use RRGGBB as a hex, some use R G B as hex independently, some use R G B as decimal, some use HSB, some use XY and there may be some others. In all these case they are plugin devices and not HS Zwave devices. I am not a zwave user so have no experience as to what HS ZWave plugin is expecting for color control. I do know that CAPI and not setDevice is needed to change a device other than the virtual devices. It seems to me that HS ZWave plugin is expecting something other than what you are providing via mcsMQTT expression manipulation. I believe when HS colorpicker is used to control a device it will send #RRGGBB. This is all from memory and there have been so many variants of color control that it is hard to generalize. It also seems interesting that the HS log error has debug code and this is a HS3 Zwave plugin so one would not expect debug of this nature in a mature plugin.

When was doing the testing of this today I was using mcsSprinklers plugin as the non-plugin device being controlled via mcsMQTT. I had no issues with it. It is also a HS3 plugin.

[Jeeves]

I have a history with mcsMQTT managing color space devices where some use RRGGBB as a hex, some use R G B as hex independently, some use R G B as decimal, some use HSB, some use XY and there may be some others. In all these case they are plugin devices and not HS Zwave devices. I am not a zwave user so have no experience as to what HS ZWave plugin is expecting for color control. I do know that CAPI and not setDevice is needed to change a device other than the virtual devices. It seems to me that HS ZWave plugin is expecting something other than what you are providing via mcsMQTT expression manipulation. I believe when HS colorpicker is used to control a device it will send #RRGGBB. This is all from memory and there have been so many variants of color control that it is hard to generalize. It also seems interesting that the HS log error has debug code and this is a HS3 Zwave plugin so one would not expect debug of this nature in a mature plugin.

When was doing the testing of this today I was using mcsSprinklers plugin as the non-plugin device being controlled via mcsMQTT. I had no issues with it. It is also a HS3 plugin.

Yeah, this seems problematic. It doesn't want to accept the hex nor the decimal. Status pages seem to indicate it would respond to decimal values, though that's clearly not the case.

Based on the MQTT publish, the custom color picker creates an all caps-hex RGB. Clearly that isn't accepted as control.

I think my best solution may be to write a script which takes in an RGB Hex (#AABBCC) that breaks it out to it's R, G, B elements. It's unnecessarily kludgy, but I'm not sure I see an alternative.
This page presents a solution much like I describe:
https://forums.homeseer.com/forum/ho...-of-rgb-device

With a little testing (as usual, the HS3 pages are more useful) it's appearing more and more that this is a Homeseer problem:

[Jeeves]

Not that I suspect it matters much, but I am on the latest HS4.
Not that I expect you to have a solution, but you are very knowledgeable and have done lots of dev on the HS platform; Have you seen any other instances where the device (in this case a zwave device) accepts a value but does not issue a change to the physical device itself?

[Michael McSharry]

Only a virtual device will change its status based upon hs.SetDeviceValue.

Plugin devices are controlled with CAPI. It is something like below where the control use should be something like color control for a RGB device. 123456 is just a example number.

Dim oCAPI as CAPIControl = hs.CAPIGetSingleControlByUse(refOfDevice,HomeSeerAPI.ePairControlUse._ColorControl)
oCAPI.ControlValue = 123456
hs.CAPIControlHandler(oCAPI)

It is up to the plugin as to how it accepts CAPI control. In my color device I use a number that is stored in DeviceValue RR*255*255 + GG*255 + BB. I do not know what HS Zwave pluign does for device with color capability.

The error that is showing in the HS log occurs on the statement which is the HS4 API equivalent of the last two lines above for CAPI
hs.SendControlForFeatureByValue(refOfFeature, 12346)

I believe I put in a request that the HS4 API be expanded to include the ability to control the DeviceString in addition to control of the DeviceValue and in that case it would be possible to communicate with the plugin with text such as "#WWRRGGBB", but of course the plugin would need to be expecting something like this.

[Jeeves]

Only a virtual device will change its status based upon hs.SetDeviceValue.

Plugin devices are controlled with CAPI. It is something like below where the control use should be something like color control for a RGB device. 123456 is just a example number.

Dim oCAPI as CAPIControl = hs.CAPIGetSingleControlByUse(refOfDevice,HomeSeerAPI.ePairControlUse._ColorControl)
oCAPI.ControlValue = 123456
hs.CAPIControlHandler(oCAPI)

It is up to the plugin as to how it accepts CAPI control. In my color device I use a number that is stored in DeviceValue RR*255*255 + GG*255 + BB. I do not know what HS Zwave pluign does for device with color capability.

The error that is showing in the HS log occurs on the statement which is the HS4 API equivalent of the last two lines above for CAPI
hs.SendControlForFeatureByValue(refOfFeature, 12346)

I believe I put in a request that the HS4 API be expanded to include the ability to control the DeviceString in addition to control of the DeviceValue and in that case it would be possible to communicate with the plugin with text such as "#WWRRGGBB", but of course the plugin would need to be expecting something like this.

I appreciate the response. I am quite unfamiliar with the inner workings (CAPI in particular) and thank you for detailing that difference. I was unaware the command I was testing with would only work on virtual devices.

[Jeeves]

I'm finally getting back to this (I apologize for dredging up an old topic).

As usual, I'm attempting to understand what I'm doing wrong.

I created a virtual device (#1527) and set it's values to be 1 - 30000000. The Current value is 1.

I associated the device with mcsMQTT and defined the following:

Sub. Topic: cmnd/hs4/rgb/color_control
Pub. Topic: hs4/rgb/color_control

MQTT Payload Template:#<<ToHex("$$VALUE:")>>
Expression: <<FromHex("$$VALUE:")>>

I use my IoT Dashboard to send a color which is published as a hex color.

mcsMQTT Debug log shows it is received and converted accordingly:

03/28/2021 21:50:11 1186457 | Update Accepted 1527 to #45c9ad StatusType=0 Payload=#45c9ad RegExValue=#45c9ad
03/28/2021 21:50:11 1186459 | Non-plugin Update Expression <<FromHex("$$PAYLOAD:")>> on payload #45c9ad
03/28/2021 21:50:11 1186460 | FromHex #45c9ad
03/28/2021 21:50:11 1186460 | ApplyExpression FromHex("#45c9ad") Result=4573613
03/28/2021 21:50:11 1186460 | Substituted Payload 4573613, Expression Result 4573613
03/28/2021 21:50:11 1186463 | Command nonPlugin Device 1527 to 4573613
03/28/2021 21:50:11 1186463 | Command 1527 to 4573613, nValue=4573613, TargetValue=1, Range=1 to 30000000, ControlType=Button, ControlString=, Label=, ControlUse=NotSpecified, UpdateLastChange=False, bUpdateValue=True, HSValue=1

However, this does not update the non-plugin (Virtual) device, it will stay at 1.

The Homeseer log says:

Error during SendControlForFeatureByValue - Exception during fDEBUG_PI_CALLS for 1527 : 4573613 - Object reference not set to an instance of an object

I am on HS4 plugin, v5.13.3.1.

Thank you!

[Michael McSharry]

The command that was executed is the request to update device 1527 to a value of 4573613. Normally CAPI is used to request a plugin update some hardware device. I do not know if HS has handled the case of non-hardware virtual device where it does not pass off the action to the plugin, but needs to do the update itself.

hs.SendControlForFeatureByValue(iRef, nValue)

A preferred approach is let mcsMQTT own the device. The sequence is to start by sending cmnd/hs4/rgb/color_control so mcsMQTT will observe it and make it available for association to HS using the "A" checkbox on the Association tab. To do this you should remove the record of the virtual device relationship you setup. After the expression and template are setup as well as the pub topic then the next time mcsMQTT sees this topic it will update the HS DeviceValue directly.

You will probably find it easier to use the Control/Status UI on the Edit tab as ColorPicker so it can handle the RRGGBB conversion implicitly rather than you needing to use the two hex functions. The only thing to be concerned with it the leading #. Some widgets use it and some do not. If it needs to be added or removed then expression and/or payload template can be used.