[deconz] fails to translate percentage type for light #8260
Comments
|
That‘s really surprising. There is a range check before the value is posted. I‘ll add some logging. Is this only happening for this light? |
|
Hard to say because deconz spams the log file with dozens of messages per second. I have multiple sensors and buttons but I don't see any exceptions as long as the lights stay off. So I assume it's probably (mostly) a lights problem. |
|
Please try if https://janessa.me/esh/org.openhab.binding.deconz-2.5.8-SNAPSHOT.jar, set the binding to DEBUG and show the DEBUG message just before the exception (val = '{}', scaledValue = '{}'). |
|
I added the jar to the Is it required to update openhab to 2.5.8 first? I'm currently running on 2.5.7. But even without your jar I noticed the binding is not crashing anymore. I'm wondering if something changed with the update of deconz to 2.05.80? |
|
Maybe. That exception looks strange. No idea why that happens. |
|
Sorry, I could not get the jar running. But with openHab 2.5.9 and deConz 2.05.82 I was able to get more details: I'm not sure if it's the same bug or just similar. Unfortunately I don't get a stacktrace anymore |
|
This can't be explained. I wrote a test with exactly your message and the test suceeds. Do you use manual configuration (things.conf) or managed (via Paper UI)? If textual: please show your configuration. If managed: please delete the thing and re-add it. |
|
I configure it via config files. For that specific light the config is: |
|
|
J-N-K
added
invalid
and removed
bug
|
Thank you! that did the trick :) I used the same light before with the HUE binding and there the color temperature is defined as I'm wondering why this inconsistency? Isn't that super confusing and error-prone? |
|
I think using Number and Setting the color temperature in K is much more intuitive than some abitrary 0-100% value. |
|
I have to chime in here. And I have to reopen this issue. We have a default system channel type FTR: I just migrate a color temperature light from hue to deCONZ and got the same error as mentioned above - my item type for hue lights was And later: |
|
A dimmer is plain wrong. On/off make no sense on color temperature. And For two lights with different ct range setting the same ct is impossible with 0-100%. |
|
I agree with you. It technically and physically is not correct. But in the terms of openHAB a Philips Hue and deCONZ both provide a |
Correctly: from cold (0%, highest Kelvin) to warm (100%, lowest Kelvin) |
|
Looking at your other PR, hue is not using the system-channel ATM. Which binding is using the system-channel? Probably none. In that case, the system-channel should be changed. |
|
As far as I know, the Shelly binding uses also dimmer for the color temperature. |
|
The question is: does it use the system-channel-type. I strongly oppose to implementing wrong behavior just because it‘s written somewhere. If no one uses the system-channelType, there is no reason to break a working implementation just to use a definition that we all agree is wrong. |
|
GitHub search only yields one hit: tpsmartlink. I will do a more detailed RegEx search tomorrow, when having my dev-env handy. |
|
Looks like every binding implements the color temperature channel in the above described openHAB style. Some of them provide an additional channel for |
|
But only tplinksmarthome uses the system channel. Anyway. It's wrong. If you feel deconz needs fixing, you can of course do that. Please remove me from the CODEOWNERS in that case. I do not support breaking correct implementations because of wrong modeling. |
|
I think we are heading into the wrong direction. I am neither claiming to change the existing channel nor the implementation. I am asking for adding a way to retrieve the same functionality like we are having in other bindings - which may be a new channel or a Profile for conversion or something completely different. I am asking for streamlining capabilities to make bindings more even. Sry, if my earlier posts did not sound like that. And yes, we can discuss changing system default channel type or adding a new one to support Kelvin temperature settings. I like to add this feature to Hue binding. Currently it is not possible for me to switch my color temperature bulbs from Hue, TRADFRI, tplinksmarthome or others vendors to deCONZ without a hassle. I have to touch the modelling of my house which which does not have to be. |
|
The system channel type for color temperature isn't much used, since it was introduced after most bindings where already developed and we never really enforced the usage of system channel types afterwards. I don't mind adding a separate system channel type for absolute color temperature in K", if the bulbs really support this. From my experiences with HSB values I only know that colors can widely differ, even if expected to be identical. Hopefully this is better for color temperature. |
|
10% is not the same for two different lights. And that does not depend on different implementations (like the HSB issue) but on different ranges in value. That‘s why I think it’s wrong. Value X should be the same (if lights were perfect) for each light. That’s true for a color temperature in K, but not for a color temperature in %. 0% could be 2000K for one light or 2200K (or even 3000K) for another light, but 2000K should be the same for every device. |
Please read above. 10% brightness isn't the same for different lights either, yet it perfectly makes sense and nobody claims it's wrong. |
cweitkamp
added
enhancement
|
I removed the "invalid" label for now and added the "enhancement" label. Maybe some volunteer will add the "normal" color temperature channel to the deCONZ binding in the future. I for myself found the solution in adding a new channel to the Hue binding (see #9939) which allows to control the color temperature in Kelvin. This in advance solves another problem for me and lets me put two color temperature bulbs of two different vendors in a Group to set an equal color temperature value for both of them - and yes, I now was forced to remodel my home, but that will not happen again. I hope others will benefit from my above solution too. |
Expected Behavior
deCONZ does not fail when light is on
Current Behavior
bridge constantly fails and goes offline:
Possible Solution
Steps to Reproduce (for Bugs)
Turn on light
Your Environment
The text was updated successfully, but these errors were encountered: