Announcement

Collapse
No announcement yet.

Bugs in Devices & Groups... several

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

  • #46
    There is something the Homeseer Zigbee plugin developer is doing you are not. I'd imagine he'd share the secret if you asked.
    The secret is already answered for in post #2.... The HomeSeer manage device page is expecting that the value of the device is a RGB value when the color picker is placed, which it is not? Please accept this is not going to be resolved. The value of the Hue is correct, according to deCONZ and Philips bridges. I have placed the color picker on this device long time ago, to help users to easy pick a color, never to show a correct color. HST has changed the behaviour of the color picker once they added the zigbee plugin, other plugin owners have never been consulted on this.

    I will make a change to the plugin to remove the colorpicker so you will not get confused by it anymore.

    As posted in an answer #8, the action on an event using a color picker is another undocumented and unannounced change. I already told that I am in contact with HST on this? Haven't heard back on this for some time though.

    JowiHue Action 'Set Light' then input RGB or XY or any value - none of the values were retained.
    I have been testing the empty boxes here, and all action are retained. Again do not understand your RGB input remark as there is no RGB input possible here?
    -- Wim

    Plugins:RFXCOM, HSTouch Server, Squeezebox, BLGData, Restart, Jon00's Perfmon and Network monitor, WeatherXML, BLBackup, TenScripting, BC4, Pushover, PHLocation, JowiHue, Zwave, Sonos
    650 devices ---- 336 events ----- 40 scripts

    Comment


    • #47
      I guess the HS3 Zigbee plugin must be converting a the XY value from the Lightify Hub into RGB Color Picker value so it works within HS3's UI. ... Cuz it work perfectly in the native HS3 Zigbee plugin.


      JowiHue Action / Set Lights - manually entering values...

      * XY values disappear (I even rebooted and tested again)... XY values clear out, never saved.

      * Hue Value saves in event but never sets on the device - maybe not getting sent from event to device? Bri & Sat are saved and shown on device correctly, as well as teh last update value changing properly. Attached screenshots for numeric Hue value (on the device) is wrong, and the last update time/date has not changed like the Sat value did.


      Native HS3 Action / Control a Device... using JowiHue created device
      * Does NOT work, at all.
      * oddly the device works fine (even using the color picker) when directly controlling it from HS3 "Device Management" screen.
      ... Isn't the event is simply calling the HS3 device? If yes, then it should work just as if I'm on the Device Management screen, no?

      Thx for sticking with this. I'm looking forward to this working. It is better than it was... using Presets didnt work at all before and now they do :-)


      Attached Files

      Comment


      • #48
        Originally posted by Ltek View Post
        Also -- See screenshot for testing of Events. Possibly some bugs in how JowHue is called from an Event. Only 1 test method worked: JowiHue Set Light / Presets. These did not work: HS3 Device using Color Picker; JowiHue Action 'Set Light' then input RGB or XY or any value - none of the values were retained.
        I've noticed this bug too, but I believe it is a Homeseer ASP/AJAX postback issue causing this. Restarting Chrome, using Firefox or restarting HS will often solve this problem. Homeseer (or some other plugin) has some resource leaks that eventually cause AJAX issues that affect postback actions. It seems to show up first when creating complex events, as in your example.

        --Barry

        Comment


        • #49
          Originally posted by Ltek View Post
          I guess the HS3 Zigbee plugin must be converting a the XY value from the Lightify Hub into RGB Color Picker value so it works within HS3's UI. ... Cuz it work perfectly in the native HS3 Zigbee plugin.
          The HS3 "Zigbee" plugin, and I'm loathe to call it a Zigbee plugin, is actually just using the Lightify API which uses RGB values. The Lightify API natively supports these colors: red, green, blue, yellow, purple, orange and pink. To change a light to red, you send this curl command:

          Code:
           
           curl --location --request PATCH "https://na.lightify-api.com/v4/devices/123456-d01" \   --header "Authorization: Bearer " \   --header "Content-Type: application/json" \   --data "{   \"color\": \"red\" }"
          To set an "RGBW" color that is not native, you send a command with a mix of RGBW colors. So to do a reddish-orange color you would send this command:

          Code:
           
           curl --location --request PATCH "https://na.lightify-api.com/v4/devices/123456-d01" \   --header "Authorization: Bearer " \   --header "Content-Type: application/json" \   --data "{   \"colorRGBW\": {     \"red\": 255,     \"green\": 126,     \"blue\": 0,     \"white\": 0   } }"
          So while in the background HS3 is sending the above command to the Lightify API, in the UI they are showing the Hexadecimal equivalent in the color picker which is #FF4B00.

          Read through the documentation for the Lightify API and nowhere are the words "Hue" or "Saturation" API commands available.

          https://docs.lightify-api.com/#intro

          --Barry

          Comment


          • #50
            logman
            Thx, useful info.
            Looks like you are saying that HS3 is already able to translate RGB into Hex for the Color Picker? Do I understand correctly?

            What's your thought on options to getting this to work proper in HS3 ... or a workaround in deConz and/or JowiHue?
            ... deConz Feature Request asking for XY <--> RGB translations to happen in deConz and any comms with HS3 to be in RGB. deConz would translate the RGB <--> XY ... then when HS3 gets the data, it will translate the RGB into Hex -- thus, HS3 Color Picker will?

            though I'm trying to figure this out, I dont think getting the HS3 color picker to work is that important. BUT, I would like to be able to visually see the Hex value and the resulting color directly on the Device. It helps color match different bulbs to visually see the color onscreen and know what the Hex is

            I'm more concerned about the HS3 Events problems : 'Set Lights' XY settings not sticking and HS3 JowiHue devices not working at all.

            Comment


            • #51
              Originally posted by w.vuyk View Post
              The secret is already answered for in post #2.... The HomeSeer manage device page is expecting that the value of the device is a RGB value when the color picker is placed, which it is not? Please accept this is not going to be resolved. The value of the Hue is correct, according to deCONZ and Philips bridges. I have placed the color picker on this device long time ago, to help users to easy pick a color, never to show a correct color. HST has changed the behaviour of the color picker once they added the zigbee plugin, other plugin owners have never been consulted on this.

              I will make a change to the plugin to remove the colorpicker so you will not get confused by it anymore.

              As posted in an answer #8, the action on an event using a color picker is another undocumented and unannounced change. I already told that I am in contact with HST on this? Haven't heard back on this for some time though.



              I have been testing the empty boxes here, and all action are retained. Again do not understand your RGB input remark as there is no RGB input possible here?
              I am curious why you won't at least attempt to translate the color, there are plenty of C# libraries that do the Hue to RGB translation, I can happily send you to one if you like.

              Comment


              • #52
                Originally posted by Ltek View Post
                logman
                Thx, useful info.
                Looks like you are saying that HS3 is already able to translate RGB into Hex for the Color Picker? Do I understand correctly?
                Yes, that is my understanding. And that's precisely the problem: HS is expecting to see RGB values, not Hue/Sat values.

                The Lightify Gateway/Bridge controls Osram Lights using RGBW commands like I posted above, whether using your Sylvania phone App or by using API calls (Homeseer Zigbee plugin). If you change a bulb color in the phone app, the color is updated in HS with the new RGB values which is then converted to HEX in the colorpicker. (The colorpicker also shows you the current RGB values too when you click on it.)

                Meanwhile deCONZ controls the Osram lights using Hue and Saturation commands, not RGB commands. The deCONZ API passes the Hue and Sat values to JowiHue and HS tries to parse those values as if they were RGB. Wim has asked Rich with Homeseer to let plugin devs decide how the colorpicker behaves, but they haven't responded to his request.

                One way to solve the problem is for Wim to do API calls to the Lightify gateway, same as he does with the Philips bridge. But that would be duplicating what is already available with the Homeseer plugin, and it's probably not worth his time and effort. Not many people use the Osram bulbs, and the bulbs don't handle or represent pastel colors very well. He has stated more than once that he prefers to keep his plugin more aligned with deCONZ and Philips standards, which are both Hue/Sat type controllers.

                Keep in mind the name of this plugin is JowiHue, not JowiRGB.

                Also keep in mind that I'm no where near an expert on this color stuff, so everything I just said could be 100% wrong.

                --Barry

                Comment


                • #53
                  as bsobel points out, I think the shortest (and most reliable) path to a fix for the color is for JowiHue to do Hue <--> RGB <--> XY translations then communicate with RGB to HS3 and XY or Hue (depending on the light) to deConz.

                  I'm sure there are many coding libraries for this and there are tons of free web sites that do it too. I've been using this one...http://colorizer.org/

                  Comment


                  • #54
                    Originally posted by Ltek View Post
                    as bsobel points out, I think the shortest (and most reliable) path to a fix for the color is for JowiHue to do Hue <--> RGB <--> XY translations then communicate with RGB to HS3 and XY or Hue (depending on the light) to deConz.

                    I'm sure there are many coding libraries for this and there are tons of free web sites that do it too. I've been using this one...http://colorizer.org/
                    No coding library is really necessary for this, as it is a fairly simple formula to convert Hue to RGB. Here is a short tutorial explaining the math. Problem is that would not give an accurate representation for Philips Hue bulbs, which have 5 components of color mix (RGB + Warm White + Cool White).

                    The easiest and most reliable fix that you are looking for would be for HS to let the plugin dev decide what sort of color picker (if any) the plugin uses and how it behaves. Even then the colors represented are not going to be 100% accurate and will vary from brand to brand.

                    The very best, most accurate and repeatable way to set the color of any brand of light is by eyeball and then use the "Snapshot" feature Wim has provided us, which will save the color as a new preset available in all your events. I really don't understand the importance of the color picker given the tools provided. (In fact I have disabled mine so that the Homeseer pages load faster.)

                    --Barry

                    Comment


                    • #55
                      Originally posted by logman View Post

                      No coding library is really necessary for this, as it is a fairly simple formula to convert Hue to RGB. Here is a short tutorial explaining the math. Problem is that would not give an accurate representation for Philips Hue bulbs, which have 5 components of color mix (RGB + Warm White + Cool White).

                      The easiest and most reliable fix that you are looking for would be for HS to let the plugin dev decide what sort of color picker (if any) the plugin uses and how it behaves. Even then the colors represented are not going to be 100% accurate and will vary from brand to brand.

                      The very best, most accurate and repeatable way to set the color of any brand of light is by eyeball and then use the "Snapshot" feature Wim has provided us, which will save the color as a new preset available in all your events. I really don't understand the importance of the color picker given the tools provided. (In fact I have disabled mine so that the Homeseer pages load faster.)

                      --Barry
                      Barry the libraries Im referring to do the color translation specifically against the Hue bulbs not genericlly. You provide the Hue model number so it knows what translations are available. It’s under a permissive open source license and adding it would take a few hours. I use it genericlly (no bulb provided) to convert Tuya bulbs to RGB which work similarly to the Hues.

                      Comment


                      • #56
                        Originally posted by bsobel View Post

                        I am curious why you won't at least attempt to translate the color, there are plenty of C# libraries that do the Hue to RGB translation, I can happily send you to one if you like.
                        bsobel

                        The translation of the color is no issue here. Please check the earlier posts on this? It is already native in the plugin.

                        If you check on the usage of presets and scenes (CIE Colorspace settings) you will see the RGB conversions are available in the plugin and are working perfectly. The conversion from HUE/Sat and brightess is done by calculations as recommended by Philips, including the Gamut corrections. The issue here is that (said it about 10 times by now ) HST is responsible of building the color picker on the device management page. And they take the value of the device and just assume this will be a RGB value. But in the case of this plugin it is a Hue value. So the color on the colorpicker will always be off / not valid.....

                        I have asked HST to allow the plugin to return the correct RGB during buld of the page, but they are not willing to do that, Instead they insist the device must hold a RGB value. And I can imagine their point of view as this extra call could slow down the build of the page even more as it already is.

                        Another issue I asked HST is to explain why the action on a event for a HUE device is now also showing a colorpicker and why the action when this event is triggered is not calling SetMultiIO, which any other device action is doing. My impression is that HST has solved this call in an alternative way, not documented anywhere. As this happens only in the HS beta version I am hoping they will document/announce this someday. I have appoached HST on this, but after a while it became silent. Tried to survive the caht few days again, but still there is silence. So I am in dry area here....

                        Changing the Hue device to RGB would have impact on all users of this plugin, so I think it would be irresponsible to change this now. Alternatively I could add a 5th device to a color bulb that would display the RGB value of the bulb, only to solve a display issue. I already hate having to supply 4 devices for one bulb. And the 5th device would not have added value in my eyes, so I do not want to do this either as it is really overkill for a display issue that - once events do take over normal control - is really only minor. Please look at it in perspective?



                        To understand the Gamut recalculation a bit, know that Philips has defined three Gamuts so far, A, B and C for their lights. The most current Philips lights are Gamut C nowadays, but the first versions of bulbs were a mix of mainly Gamuts A and B. If you look at other brands, like IKEA and OSRAM/Lightify, those are somwhere between Gamut A and B at best, and most often do not work well with Saturation (IKEA can even freeze on Saturation levels or on Hue values out of its own range). All these considirations are builtin in the plugin to my best abilities. I think at this point the plugin is doing its job there close to "very good". Perfect will never exist I am afraid.

                        If you check the graph, you will understand that a RGB value put in by an user, will often have to be corrected to the light's ca[pabilities. A Philips light will automatically be adjusted to the nearest point in the colorgraph. For Philips lights this is automatically done, IKEA will tilt on that, so the plugin has to make sure the correct values are sent and thus has to correct the RGB value. You can check this effect in the Presets CIE Colorspace setting. If you select a RGB color, the resulting RGB value once choses will be corrected to a near point in that graph. It does the same for OSRAM/Lightify lights.


                        Click image for larger version

Name:	Pasted Image.png
Views:	16
Size:	275.5 KB
ID:	1279254

                        I hope you have a better understanding now of my reasons to my objections to simply change the device? Main reason being that I do want to prevent many users to have to change their events because of a display error.

                        Wim

                        -- Wim

                        Plugins:RFXCOM, HSTouch Server, Squeezebox, BLGData, Restart, Jon00's Perfmon and Network monitor, WeatherXML, BLBackup, TenScripting, BC4, Pushover, PHLocation, JowiHue, Zwave, Sonos
                        650 devices ---- 336 events ----- 40 scripts

                        Comment


                        • #57
                          Originally posted by Ltek View Post
                          logman
                          I dont think getting the HS3 color picker to work is that important. BUT, I would like to be able to visually see the Hex value and the resulting color directly on the Device. It helps color match different bulbs to visually see the color onscreen and know what the Hex is

                          I'm more concerned about the HS3 Events problems : 'Set Lights' XY settings not sticking and HS3 JowiHue devices not working at all.
                          Ltek

                          On the XY settings, what is the decimal point usage on your HS3 system and which decimal point are you inputting when filing in the x and y boxes? Any chance there is a mismatch?

                          With HS devices not working at all: What do you mean there, is this about the event controlling the Hue device? Then you know the status on this one?
                          Or is it the saturation not really setting? Is that for all lights, or only the older lights? As in that case the answer to bsobel above might point to the issue, but n that case IKEA was pointed at.

                          Wim
                          -- Wim

                          Plugins:RFXCOM, HSTouch Server, Squeezebox, BLGData, Restart, Jon00's Perfmon and Network monitor, WeatherXML, BLBackup, TenScripting, BC4, Pushover, PHLocation, JowiHue, Zwave, Sonos
                          650 devices ---- 336 events ----- 40 scripts

                          Comment


                          • #58
                            Originally posted by w.vuyk View Post
                            Changing the Hue device to RGB would have impact on all users of this plugin, so I think it would be irresponsible to change this now. Alternatively I could add a 5th device to a color bulb that would display the RGB value of the bulb, only to solve a display issue. I already hate having to supply 4 devices for one bulb. And the 5th device would not have added value in my eyes, so I do not want to do this either as it is really overkill for a display issue that - once events do take over normal control - is really only minor. Please look at it in perspective?

                            ___

                            On the XY settings, what is the decimal point usage on your HS3 system and which decimal point are you inputting when filing in the x and y boxes? Any chance there is a mismatch?

                            With HS devices not working at all: What do you mean there, is this about the event controlling the Hue device? Then you know the status on this one?
                            Or is it the saturation not really setting? Is that for all lights, or only the older lights? As in that case the answer to bsobel above might point to the issue, but n that case IKEA was pointed at.
                            Color Picker / HS3 Device issue:
                            Completely agree with you on not adding another Device... Maybe one alternative: using the Extra Data Store to store values JowiHue needs while storing RGB value (so HS3 is happy) as the main value of the device?

                            XY Settings (and Kelvin color temperature)
                            test... first clear all the settings in the JH Device. then enter 10 or 10.3 or 10.38 -- they all clear out

                            btw, Color Loop does save values, but nothing happens.

                            I'm on HS3 Standard Edition 3.0.0.495 (Windows) -- beta version. Just updated from prior beta, same result as this on.
                            -- Had to go beta since I was having several HS3 bugs cause problems. Can you test this version to see if you have the same problems with the input fields? Maybe a bug in the beta?

                            Comment


                            • #59
                              Originally posted by Ltek View Post

                              Color Picker / HS3 Device issue:
                              Completely agree with you on not adding another Device... Maybe one alternative: using the Extra Data Store to store values JowiHue needs while storing RGB value (so HS3 is happy) as the main value of the device?
                              He's right, any change here break existing events, so the above won't help...

                              Comment


                              • #60
                                Originally posted by w.vuyk View Post
                                I hope you have a better understanding now of my reasons to my objections to simply change the device? Main reason being that I do want to prevent many users to have to change their events because of a display error.
                                Wim
                                Wasn't trying to frustrate you, appreciate the long response. Completely agree that you should not break existing users. For what its worth I'd make the option to do the conversion to/form RGB optional and let folks who are really bothered by the color picker issue enable it (knowing they it breaks their events). The long term answer I'd suggest is not to have HS call the plugin for conversion, but rather to add calls to allow a plugin to generate their own custom HTML controls for use on the device config page. Maybe if we go to Rich together we can get him to consider such a change, that would give the most flexibility moving forward...

                                Comment

                                Working...
                                X