Announcement

Collapse
No announcement yet.

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

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

    #16
    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.

    Comment


      #17
      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.

      Comment


        #18
        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

        Comment


          #19
          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.

          Comment


            #20
            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:	51
Size:	36.2 KB
ID:	1465981

            Comment


              #21
              Correct, not something coming from mcsMQTT.

              Comment

              Working...
              X