Announcement

**w.vuyk** · December 30, 2018, 10:10 AM

Ltek,

I do not think comparing Phoscon with the plugin will do much good. I am not using Phoscon here and never cared to check on that. If you have doubts on the shown value of a device, check the properties of the device, the JowiHue tab. You will find the currently known status of the devices as reported by deCONZ or the Philips Hue bridge. The plugin works with the REST API, Phoscon is just another inteface with its own flaws, pros and cons. And also still in development.

If the values shown on the JowiHue tab don't match with the current value of the device then there is an issue (and yes, sometimes they do mismatch)

If you do change something through an app like the philips app or Hue essentials, it can take up to 30 seconds before the device is updated. At the start of the plugin, in the log you will see a line on this once the connection is made. As most often this value is only delivered by polling, the plugin polls only once per 30 seconds, so the device value gets updated once per 30 seconds to the current bridge status.

As for the colorpicker on the Hue device, this color picker uses the value of the Hue device and thinks the value is a RGB value, which it is not. I asked Rich long time ago to let the plugin decide what value to use there, but I do not think it will be done.

The dim level changes with setting a RGB value as the brightness is a part of the conversion from RGB to Hue/Sat and brighness. You can disable this for voice comands on the configuration page of the plugin.

As for the groups not updating I am not sure yet, have to check the log. Are those groups created through the Bridge Maintenance page or Phoscon?

PS this log does not help much helas, could you try restarting and and enabling debug of detailed trace options?

**Ltek** · December 30, 2018, 01:42 PM

w.vuyk please see the attached TXT file. It includes new testing from this morning: test procedures in order (roughly, I tested some things a few times) of what you will in the attached Trace & normal logs.

Forget about Phoscon and the Hue Essentials app - I was using them as data points / baseline to ensure other things worked and JowiHue is not working -- which I again confirmed this morning.

Showstoppers...

1. HS3 Events dont set Hue properly.

2. HS3 UI not updating Hue to reflect true values (devices & groups coming from deConz)

... these must work for the plugin to be usable. With the Homeseer Zigbee plugin, they works perfectly for many months.

thx for the quick response and help

Attached Files

JowiHue_Logs_Trace+Reg.txt (106.6 KB, 2 views)

**bsobel** · December 30, 2018, 03:15 PM

"As for the colorpicker on the Hue device, this color picker uses the value of the Hue device and thinks the value is a RGB value, which it is not. I asked Rich long time ago to let the plugin decide what value to use there, but I do not think it will be done."

Dumb question, but can't you convert the Hue data into an RGB value which you then SetDeviceValue() with? Its what I do with my Tuya plugin...

**Ltek** · December 31, 2018, 11:21 AM

Originally posted by bsobel View Post

"As for the colorpicker on the Hue device, this color picker uses the value of the Hue device and thinks the value is a RGB value, which it is not. I asked Rich long time ago to let the plugin decide what value to use there, but I do not think it will be done."

Dumb question, but can't you convert the Hue data into an RGB value which you then SetDeviceValue() with? Its what I do with my Tuya plugin...

... and the color picker works perfectly fine on the native Homeseer Zigbee Plugin. In the HS3 web UI, the color picker has RGB values that get set/shown when you manually select the color.
... and the Hue gets set properly when using the JowiHue Scenes/Animations.

Please let us know if you are working on fixing the Hue issue... without it Events dont work, which is mostly what I use my color lights for.

**w.vuyk** · January 2, 2019, 08:06 AM

Ltek

In your log I am mainly seeing color picker actions from the device utility page? Those are not from events? It is easier to use a log without the device actions from the manage device page.

In your events, are you controlling the Light with the JowiHue actions or the Device actions? As with the Jowihue actions you can set Brightness, Sat and Hue in one go, With the device you can only set the value for the selected device (for hue a value between 0 and somewhere around 65653?). I think the JowiHue actions are the best tool to use here?

Wim

**w.vuyk** · January 2, 2019, 08:14 AM

Originally posted by bsobel View Post

Dumb question, but can't you convert the Hue data into an RGB value which you then SetDeviceValue() with? Its what I do with my Tuya plugin...

I prefer keeping the plugin to follow the values used by the gateways. The conversion done to RGB are resulting in differences due to the Gamut correction done by Philips that might result in confusion for users. Internally I am catching the colorpicker doing the conversion, but if I would put this value back to the hue device it would be a changed value compared to what was selected. to keep things simple I do not want to change this plugin to RGB as this really does mismatch how deCONZ and Philips are working.

Wim

**w.vuyk** · January 2, 2019, 01:40 PM

I have checked once more on the event part you ( Ltek ) were mentioning....

Here is what I am seeing on my events page:

Installed a test with the latest beta of HS3

Don't you just love those unannounced changes in HS?

Just because the plugin started supporting the color command from Alexa, HS now assumes the device will be holding RGB values! It is not!

Ltek, this is a beta HS change. I will have to find out how this unwanted change can be incorporated in the plugin. For the mean time I advice you to use the JowiHue action for setting the hue values. another way will be to remove the Color_use Color setting on the Graphic values tap of the properties.

Wim

**Ltek** · January 2, 2019, 09:12 PM

Originally posted by w.vuyk View Post

I have checked once more on the event part you ( Ltek ) were mentioning....

Don't you just love those unannounced changes in HS?

Just because the plugin started supporting the color command from Alexa, HS now assumes the device will be holding RGB values! It is not!

Ltek, this is a beta HS change. I will have to find out how this unwanted change can be incorporated in the plugin. For the mean time I advice you to use the JowiHue action for setting the hue values. another way will be to remove the Color_use Color setting on the Graphic values tap of the properties.

Understood. That dialog was changes several betas ago (at least 4+ months). I think, not sure, it changed to accommodate a fix in the Zigbee plugin - so that plugin would work. Please have JowiHue use the HS3 color picker in 'JowiHue Actions / Set Lights'. Its 1000x easier, and faster, and more flexible, then having to use a separate, 3rd party tool to find/choose RGB value, then another tool to convert to HSL values for JH.

**w.vuyk** · January 3, 2019, 05:07 AM

I am now in contact with HST why this change had to influence this plugin.

You really do not need to use converters, using the preset or scene functions on the creativity page you can set the color of a light to your likings by using RGB selectors or set the color with any app, and take a snapshot to copy your favorite color into the plugin.

It is the eyes you need, not a converter

*edit* As this might sound different than I ment to say - I set my lights on the eye, I look at the bulb, set the colors as I like them and take the snapshot for a new preset...

Attached Files

**Ltek** · January 3, 2019, 10:36 AM

Found Another Bug...
Copy a Native HS3 Event = ALL settings n new Copy are wiped clean / blank inside JH Plugin 'Set Color' action (Set Scenes still stay). While native HS3 actions are 100% intact for their colors.

back to Color chooser points...

The issue is not the JH Scenes. Using JH Scenes in this case is very unnecessary and adds a 10x more time and complexity. A plugin should make things easier, not harder than the native UI :-)
... I dont want to make one, or multiple (multiple would be needed for basic times sequence like I show in my example of a real life event) a JH scene for every HS3 Event

See the attached screenshot of an event using JH devices, not JH Scenes... I show both Opend & Closed sections for each native HS3 actions (using JH devices) and JH actions. You can see the difference...

First is the native HS3 device action -- you can see the color when the event section (even when the section is closed you can see the color)

Second is the JH action filled in -- no way to bring up a color palate or see what the color looks like

Third is the JH action new, not yet filled in -- same issue

Attached Files

**randy** · January 3, 2019, 01:37 PM

I'm not picking any sides here and I'm not even sure there is a "side".

A color picker is a horrible device for this purpose, because it has a brightness component to it. Hue and Brightness are not commingled in any of these lights. There are three components to setting these bulbs as far as the plug-in is concerned - Hule, Saturation and Brightness. A color picker controls all of these via one setting. The actual settings are exactly as Wim represents them in the plug-in.

Even this is an oversimplification, at least as it relates to Philips Hue bulbs. Hue bulbs are quite complex, they have 5 LED groups - Red, Green, Blue, Warm White and Cool White. The Hue, Saturation and Brightness as shown above is how colors are set. The Color Temperature involves only the Warm White and Cool White LEDs. That is why the Phoscon interface cannot correctly set Color Temperature on these bulbs. The plug-in can and the Hue app can.

Since the vast majority of users want to set the color (or color temperature) of a light, then be able to vary the brightness after those are set, a Color Picker is a horrible choice. In addition to those problems, there are also huge hue inconsistencies among the different Zigbee devices I have tested. The Philips bulbs are clearly the closest to the chosen hue, but they are not even close in certain areas along the 0-65535 hue range. This further renders a color picker choice as all but useless.

What we could probably use is a "Hue Picker" and a "Color Temperature" picker, to come close to how these lights are set. An RGB color picker is not even close, because hue is actually set with one color at full brightness and the others at less. This is also true when hue and saturation are set together. In simple math a color picker has 16 million values, but hue/saturation is only represented by 65 thousand.

I have to agree with Wim that the best way to set a lights color is to set it by your eye and either use that for a preset or as a hue value in an Event. On mine I have two groups of presets, one for Hue bulbs and a second for RGBWW strips controlled by the Dresden controllers. They are vastly different, so I had to match them by eye and snapshot them as presets.

What is probably practical from the standpoint of supporting the vast majority of color settable lighting a true HSB picker like most of the apps use

This device sets the hue around the outer edge and the saturation as you move toward the center and has absolutely no relationship to brightness. If such a device was available, then Wim and others could use it to set and display the actual color of the bulb. Even this device would still only be correct if the light manufacturer used firmware that accurately translates.

It is also important to note that hue by itself is best represented by the icon Wim uses that has no saturation component.

The bottom line is that there is currently no good solution using HomeSeer color control devices as it relates to lighting. Any method a plug-in developer uses will be a compromise and will have virtually equal numbers of supporters and detractors. My choice would be to abandon the Color Picker and replace it with a linear hue picker. Even this will be a problem when representing the actual setting of a bulb by color temperature. While it is easy for most of us to visualize color temperature on a scale from 3000-6500K, it is very difficult to visualize how that is represented by hue and saturation.

Here is a 6500K cool white:

Here is 3000K warm white:

There is no way most of us can visualize the actual color temperature (on the Kelvin scale) looking at the hue and saturation values. I spent my life dealing with color, having worked in the video field since the late '60s. I completely understand how additive (light) and subtractive (pigment) colors work. While I can reasonable visualize what 8731 represents with regard to hue and can almost visualize what mixing 106/255 (42%) of this color with white would look like, it is nowhere close to how Hue actually sets color temperature by mixing cool white and warm white LEDs.

**w.vuyk** · January 3, 2019, 02:02 PM

Originally posted by Ltek View Post

Found Another Bug...
Copy a Native HS3 Event = ALL settings n new Copy are wiped clean / blank inside JH Plugin 'Set Color' action (Set Scenes still stay). While native HS3 actions are 100% intact for their colors.

back to Color chooser points...

The issue is not the JH Scenes. Using JH Scenes in this case is very unnecessary and adds a 10x more time and complexity. A plugin should make things easier, not harder than the native UI :-)
... I dont want to make one, or multiple (multiple would be needed for basic times sequence like I show in my example of a real life event) a JH scene for every HS3 Event

See the attached screenshot of an event using JH devices, not JH Scenes... I show both Opend & Closed sections for each native HS3 actions (using JH devices) and JH actions. You can see the difference...

First is the native HS3 device action -- you can see the color when the event section (even when the section is closed you can see the color)

Second is the JH action filled in -- no way to bring up a color palate or see what the color looks like

Third is the JH action new, not yet filled in -- same issue

Ltek ,

You are misunderstanding me here.
I am pointing to the presets, not scenes. You create one preset and can use the preset for setting any other light (color enabled) in the JowiHue actions.
Scenes are bound to a light, or set of lights, which indeed could result in many scenes when you wan to assign a color "Deep Gold" to different lights during a day. Scenes are good to use fo a specific setting for any room, where different lights use different colors , but are combined to one scene. Or for use in animations.

Using the preset makes it possible to create a color setting only once and use it on any light that has the capabilities to use that setting (color/color temperature etc).

Here is what I try to tell you in a event:

Thanks, you have made my issue with RGB very clear in good wording :-)

My main issue is indeed that the use of RGB is influencing the brightness setting, something I find very annoying as one want to set a color but keep the brightness, causing the RGB to never match. The preset are somewhat a compensation for it...

**Ltek** · January 3, 2019, 02:59 PM

Originally posted by w.vuyk;n1272001

[USER="66641"

Ltek[/USER] ,

You are misunderstanding me here.
I am pointing to the presets, not scenes. You create one preset and can use the preset for setting any other light (color enabled) in the JowiHue actions.
Scenes are bound to a light, or set of lights, which indeed could result in many scenes when you wan to assign a color "Deep Gold" to different lights during a day. Scenes are good to use fo a specific setting for any room, where different lights use different colors , but are combined to one scene. Or for use in animations.

Using the preset makes it possible to create a color setting only once and use it on any light that has the capabilities to use that setting (color/color temperature etc).

Here is what I try to tell you in a event:

Thanks, you have made my issue with RGB very clear in good wording :-)

My main issue is indeed that the use of RGB is influencing the brightness setting, something I find very annoying as one want to set a color but keep the brightness, causing the RGB to never match. The preset are somewhat a compensation for it...

w.vuyk

Yup, I get it how Presets work. And if you are using a single color in many scenes/events, totally helpful. When only using color in one or two scenes, it actually complicates things:
a) I need to remember what the Preset Name
b) I cant see the actual color (visually or RGB Hex) on the event itself
c) If only using that color once (or twice) it far less efficient and has many additional steps vs doing it directly in the HS3 native event. Approx 5x the time and clicks... multiple screens and dialogs/popups that require modal popups (click to open, type input, click to close); switches HS3 screen, create events, several more drops downs or modal popups, etc.
... the issue is both efficiency and consistency -- yes, HS3 has many issues already in its own native stuff. The expectation is that the UI would be consistent... we could easily create a single event action on color light and then see that color in the event itself just like we can with native HS3 stuff.

Exc explanation and completely agree. I'd at least like to see the consistency, as I mention to above. At least the HS3 color picker can input RGB values and we can see, visually, what the color looks like, on the event action itself; not have to remember a name or go back to the JH Preset and fiddle.
Most people have many of the same light brand... and, if the lights are different brands, we can still us the same RGB Hex value as a starting point and adjust visually when needed. I use the HS3 color picker a ton, all my lights are Sylvania Lightify and it works great for me.

**logman** · January 3, 2019, 05:26 PM

Totally agree with Randy and Wim here. When you start working outside of the Primary Colors, setting the lights by eyeball and then using the snapshot feature is the way to go for non-Philips lights. For Philips lights I set them in the Hue app and save that as a Scene in the Hue app. That scene then becomes available in JowiHue and I call it from there in my events. Works great and the colors are consistent from event to event no matter the brightness setting.

If you are picky about color accuracy then you likely are going to be using Philips bulbs... Or you will be eventually. I haven't found anything yet that can hold a candle to them and I've tried them all. Only downside I've found is their cost (ouch!), but I'm willing to pay up until something as good comes along at a better price point. Not going to hold my breath just yet.

--Barry

Announcement

Bugs in Devices & Groups... several

Bugs in Devices & Groups... several

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment