It seems a bit strange.
I have another similar model, also TS011F, and it works well with that DTH.
Did you remove the old DTH and install the one I sent you?
Did you delete the device from the App, reset it and re-pair it with the DTH?
do you have settings in preference like this?
Hi @Mariano_Colmenarejo , can’t say thank you enough for the work you’re doing. Over the weekend I installed your Zigbee light drivers to use for the following bulbs and they would not connect using edge; just the default dht. Are these compatible bulbs compatible with your driver? if not, can they be added? Thanks
Wanted to say thanks for this. I’m only now finding my way around the edge drivers, but this one will definitely help my transition from webcore.
Like a few others, I have multitudes of Ecosmart bulbs and remotes. I am mostly able to recreate the incremental dimming and color temps with the four buttons, using a routine to reset the color temp when it exceeds a certain level from the fourth button So, not too bad.
Now, if only the Zigbee button driver would allow allow for the Ecosmart remote’s button 2 and 3 held capabilities, things would be near perfect.
Thanks again!
Yes - followed your instructions and got always the same result: each “outlet” created (virtual or not) controls the whole strip.
I can provide more logs if you want me to!
Details are:
Added to this driver version
I don’t think he left me any, but let me know if that’s the case
┌─────────────┬──────────────────────────────────────┐
│ Name │ Zigbee Light Multifunction Mc │
│ Version │ 2022-08-04T17:59:01.724743493 │
└─────────────┴──────────────────────────────────────┘
- id: "_TZB210_tmi0rihb/TS0505B"
deviceLabel: RGBW TS0505B
manufacturer: _TZB210_tmi0rihb
model: TS0505B
deviceProfileName: rgbw-level-colortemp-2700-6500
- id: "IKEA/TRADFRIbulbE26WSglobeopal1100lm"
deviceLabel: IKEA Bulb E26 WS
manufacturer: IKEA of Sweden
model: TRADFRIbulbE26WSglobeopal1100lm
deviceProfileName: level-colortemp-2200-4000
- id: "Ecosmart-ZBT-BR30-CCT"
deviceLabel: Ecosmart-ZBT-BR30
manufacturer: The Home Depot
model: Ecosmart-ZBT-BR30-CCT-Bulb
deviceProfileName: level-colortemp-2700-6500
Making circadin and progressive Off compatible would lose the possibility that with progressive Off it goes down to a different level of 0%, something that some users who requested it use.
I have to look at it more carefully, I’ll let you know if I could do it
- id: "IKEA/TRADFRIbulbE14WScandleopal470lm"
deviceLabel: IKEA Bulb E14 WS
manufacturer: IKEA of Sweden
model: TRADFRIbulbE14WScandleopal470lm
deviceProfileName: level-colortemp-2200-4000
- id: "IKEA/TRADFRIbulbE14WSglobeopal470lm"
deviceLabel: IKEA Bulb E14 WS
manufacturer: IKEA of Sweden
model: TRADFRIbulbE14WSglobeopal470lm
deviceProfileName: level-colortemp-2200-4000
Thanks for adding these bulbs! Yeah, I understand it may not be easy to get progressive off and circadian to work together. Unfortunately this currently makes me think of using something like SharTools rules to imitate circadian lighting. Although I could of course also use triggers that disable Circadian Lighting and enable Progressive Off.
@allmac,
Added these bulbs to this driver version
┌─────────────┬──────────────────────────────────────┐
│ Name │ Zigbee Light Multifunction Mc │
│ Version │ 2022-08-05T12:09:05.547191105 │
└─────────────┴──────────────────────────────────────┘
- id: "SYLVANIA Light"
deviceLabel: SYLVANIA Light
manufacturer: OSRAM
model: LIGHTIFY A19 ON/OFF/DIM 10 Year
deviceProfileName: switch-level
- id: "Light/Smartthings"
deviceLabel: Light Smartthings
manufacturer: LDS
model: ZBT-DIMLight-GLS0006
deviceProfileName: switch-level
- id: "Light/Gledopto"
deviceLabel: Light Gledopto
manufacturer: GLEDOPTO
model: GL-S-004Z
deviceProfileName: level-colortemp-2700-6500
Thank you very much.
Thank you! Works great!
Would it be possible to customize the Circadian Lighting graph? The current graph, is it the same regardless of the highest Kelvin for a particular light, or does it reach 4000K at the same time (and then flattens the curve if it can’t go higher)?
One interesting idea about this is the implementation of Circadian/Adaptive Lighting NodeRed for Home Assistant: Circadian/Adaptive Lighting NodeRed - Share your Projects! - Home Assistant Community. He has an interesting idea of a faster, sharper curve from 2000-ish Kelvin up to 5500K during the golden hour of sunrise, but a slower decrease back to warmer (and less bright) light starting at sunset and increasingly darker and warmer until midnight.
And while at it, what are people’s ideas about color temperature indoord during the day? I mean, color temperature outdoors soon reaches 5600K, but that temperature is considered cool to use indoors. But maybe in a place like a home office it may still be a good idea?
Another request: lights that are switched on after 18:00 are currently using whatever color temperature and brightness they had when they last were on. But if they were switched on in the middle of the day and then switched off, they use the midday values rather than the end values at 18:00. That kind of makes the Circadian Lighting not work after 6pm.
Currently I use SharpTools rules for the times after 18:00 in the evenings. But a suggestion is to use the end values all the way until the next morning, as that is normally how what one would expect (or even being able to gradually change to even warmer light later in the evening).
Hi @westis
I’m going to expand a bit, but…
I think everything is customizable and I am open to improving everything possible, but I have to find a balance between optimal functionality for most users and the complication of executing the driver, which runs in the hub and has to perform many other features with new local execution and CPU and memory resources are limited.
I imagine that you have also read in this thread posts from the September, October how the lighting, level and color temperature curve is calculated, based on the configurable parameters, (minimum and maximum level and maximum color temperature), between 6 a.m. and 6 p.m, a standard day length of 12 hours, which is what almost everything I have read applies to circadian lighting, with the aim of imitation of natural light cycles when they cannot be obtained naturally due to spend a lot of time indoors and/or living in extreme latitudes during the winter and summer seasons.
Could something better be adapted to the real sunrise and sunset of the location?:
Yes, but it would not make sense at latitudes higher or lower than +/- 50º or +/- 55º and it would be necessary to implement and add an autonomous sunrise and sunset calculation code, since the driver does not have access to that platform data .
Could the ramp lighting up at sunrise and down at sunset be modified or customized?:
It could, but it doesn’t seem to me that it provides a substantial improvement in functionality and purpose, compared to the complexity of use. Add more preferences…, there are already many and as it happened to you, the understanding of each one of them is complicated.
Is it possible to have a minimum color temperature value for each bulb profile?
Yes it would be possible.
I would have to add another preference in each profile to accommodate that minimum ColorTemperature.
2700k I think is a value that works well in all profiles and is a warm enough value for the circadian function.
If more users are interested in this, I could try to do it
Could it be done that turning on the switch outside of circadian hours turns on the 6 p.m. values?:
Yes it could.
I chose to turn on the last known value because I think that at night in most cases what is needed is to see clearly and with the minimum level and minimum color temperature values it is hardly possible, let me explain:
I think that making everything fit 100% to each user and situation is not always easy or feasible.
I can see how maximum and minimum levels could be useful, as well as maximum and minimum color temperatures.
Some bulbs will reach maximum brightness at an actual level of much less that 100%. With LED controllers sometimes LED strips will reach optimum dim level of around 10%
With color temperatures, I would find it useful for automations if those values could exceed the default ranges. Although, I don’t imagine there would be many others who would find those as useful.
I’m not asking you to do this, just stating how I would use these additional settings, if they existed.
The maximum and minimum ranges of color temperature are already limited in the presentation of the device profiles, then in the app both for the automations and for the detail view the limits are not allowed to exceed them
This would be a different use than the one I was referring to for circadian function.
That the real level generated by the device does not coincide with the standard zigbee values for level, I don’t know if setting a maximum and minimum level would solve it.
Ahh, yes, sorry about confusing subjects, but yes, I understand what you mean relating to color temperature, in that case.
As far as light brightness levels, now that I think about it, this is more of a dimmer switch problem, or with an LED controller (voltage/amperage etc.) issue, in any case, and not that of the bulb driver.
Thanks for the followup!
@Mariano_Colmenarejo Now, I know what Circadian Lighting is, and it’s very nice! I had to change my UTC offset, before It worked, but now I undertstand the discussion.
I see that my CCT LED lights have a deeper yellow after selecting the 2000K - 6500 profile, after finding it for the Gledopto controller Edge driver settings.
I think maybe it would be a nice option, to go to a lower color temperature, being that CCT LED strips are not very precise.
Just adding something on-topic.
Good stuff!
Thank you so much for extensive reply!
Yeah, I understand there must be a limit as to what the user should be able to customize. If it’s not easy to use people won’t use it.
Thanks. Yeah, I understand the graph and how it’s calculated. Although in my case with bulbs peaking at 4000K, using a percentage of the bulbs max Kelvin will lower the entire scale. I would suggest the graph to more mimic actual outdoor color temperatures, which may mean that I’d get to 4000K at 8am. Then there could be a “ceiling” to use the bulbs maximum color temperature, even when the calculation says higher, until it’s back to lower than 4000K again.
In practice, that would mean that we would reach the bulbs maximum Kelvin sooner, even with bulbs reaching up to 5600K (as it could reach much higher outdoors).
Would a cap like that be easy to introduce? That is, calculation is based on a set maximum color temperature, that may or may not be higher than the maximum color temperature of the bulb. If the calculated value is higher than what the bulb can do, then use the maximum value of the bulb.
Yeah, it’s easy enough to set up rules to automatically set desired color temperature from 6pm to 6am for each light source. I’d rather not adjust that manually, but have it automated throughout the day. As it is now I’d have to manually adjust more often than if the 6pm settings would stay also after 6pm (as I don’t want 4000K at 9pm if that light hasn’t been on since midday).
Hi @westis
The algorithm hits 4000k +/- 150k at about 8am. with bulbs that reach a maximum between 5000k or 6000k.
It would be complicated to make that cap you ask for, since I would have to modify the algorithm to use the maximum temperature of the profile and the maximum temperature for the circadian function
I think that making a perfect circadian function with a bulb that has a range of 2000k to 4000k is not the most correct.
said with all due respect, If that function were so important to me, I would buy bulbs with a range more adjusted to reality.
You also have the driver code available on github and to can make a custom driver
I think with the complexity (in a good way) of this driver, it would be good to be able to reset values to the device default. Maybe it’s possible to do this without removing the device and adding back, I don’t know.
I find myself experimenting with the options, and get lost on what I have changed… Or maybe I should just take a screenshot of the default values.
but, just an idea.
This driver deserves a community wiki of it’s own, I believe, a reference to list devices compatible with available features, and a description of how they are intended to work.
There is just so much… It’s really incredible!
Hi @blkwll
Preference settings cannot be changed dynamically from the driver code.
The only way to change the values is by entering them manually in the app and i think with the CLI too.
I think it works like this:
Preference values are stored in a table, device.preferences.
The values in this table for a device are only cleared when the device is uninstalled from the hub and all of its data in the tables is cleared.
When reinstalling the device in the hub, the default values established in the profile that is assigned to the device in the driver are restored.
If you change device to another driver, the device.preferences values in the driver from which it was uninstalled are not lost when executing the removed lifecycle.
In such a way that if we go back to the previous driver, the values that the device.preferences had are recovered.
