Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael McSharry
    replied
    Correct, not something coming from mcsMQTT.

    Leave a comment:


  • Jeeves
    replied
    Originally posted by Michael McSharry View Post
    I did the test and submitted a bug report #190 for HS4 in Github. It turns out the virtual device behavior is different based upon how it was being accessed in HS3 plugin vs. HS4 plugin. HS4 does very poorly with managing VD ranges when being viewd by HS3 plugin, but also fails to act upon CAPI requests for HS4 plugin. I did the workaround to store in the feature rather than letting HS do it if the device is virtual.

    Update at http://mcsSprinklers.com/HSPI_mcsMQTT_5_15_4_1.zip
    I am seeing VD values updating. Thank you for your hard work!
    I am seeing an error in the logs, but it's a Homeseer error, I don't suspect it's mcsMQTT's doing.

    Click image for larger version

Name:	hs4_vd-mqtt-HSerror.png
Views:	50
Size:	36.2 KB
ID:	1465981

    Leave a comment:


  • Jeeves
    replied
    Originally posted by Michael McSharry View Post
    I did the test and submitted a bug report #190 for HS4 in Github. It turns out the virtual device behavior is different based upon how it was being accessed in HS3 plugin vs. HS4 plugin. HS4 does very poorly with managing VD ranges when being viewd by HS3 plugin, but also fails to act upon CAPI requests for HS4 plugin. I did the workaround to store in the feature rather than letting HS do it if the device is virtual.

    Update at http://mcsSprinklers.com/HSPI_mcsMQTT_5_15_4_1.zip
    As always, I appreciate your commitment and support.
    I'll test and report back.

    Leave a comment:


  • Michael McSharry
    replied
    I did the test and submitted a bug report #190 for HS4 in Github. It turns out the virtual device behavior is different based upon how it was being accessed in HS3 plugin vs. HS4 plugin. HS4 does very poorly with managing VD ranges when being viewd by HS3 plugin, but also fails to act upon CAPI requests for HS4 plugin. I did the workaround to store in the feature rather than letting HS do it if the device is virtual.

    Update at http://mcsSprinklers.com/HSPI_mcsMQTT_5_15_4_1.zip

    Leave a comment:


  • Michael McSharry
    replied
    I have used VDs in my testing, but I think that was primarily for reporting HS status. Tomorrow I will try to replicate your scenario. The HS log info is created by HS and smells like it is trying to call a non-existent plugin to set the commanded value. While this should be handled by HS, I should be able to evaluate if the device is virtual and then update the value directly.

    Leave a comment:


  • Jeeves
    replied
    Originally posted by Michael McSharry View Post


    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.
    I think I'm following what you're saying. For this instance I can remove the device and let mcsMQTT own it, I'd prefer not to do that for all my existing devices.
    It would definitely be unfortunate if mcsMQTT can't update virtual devices as I've got a bunch that I hadn't got around to integrating yet.

    Originally posted by Michael McSharry View Post
    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.
    I was doing what I could to avoid the color picker control add that looked like it was an issue itself and was working around it. The expressions I'm using add and remove (as I need) the # currently.

    My intent was to have a status device that worked in decimal which upon change, an event split the device value into r,g,b which then issued those values to the specific color controls for RGB strips. This would work around the color picker problem I (and others) were having previously. I'll test this with an mqtt controlled device rather than a VD.

    Leave a comment:


  • Michael McSharry
    replied
    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.
    Code:
    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.

    Leave a comment:


  • Jeeves
    replied
    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!

    Leave a comment:


  • Jeeves
    replied
    Originally posted by Michael McSharry View Post
    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.
    Code:
    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.

    Leave a comment:


  • Michael McSharry
    replied
    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.
    Code:
    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.

    Leave a comment:


  • Jeeves
    replied
    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?

    Leave a comment:


  • Jeeves
    replied
    Originally posted by Michael McSharry View Post
    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:

    Leave a comment:


  • Michael McSharry
    replied
    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.

    Leave a comment:


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

    Click image for larger version  Name:	image_99582.png Views:	5 Size:	301.0 KB ID:	1460727‚Äč


    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

    Leave a comment:


  • Jeeves
    replied
    Originally posted by Michael McSharry View Post
    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.

    Attached Files

    Leave a comment:

Working...
X