This settings give me following results:
1st click on ON dimmer starts at 5% and ends at 50%
2nd click on ON button anytime (time to get to 50% is set to 5 minutes) before dimmer riches set maximum level of 50% it goes instantly to 50%, for example dimming is going up and it’s at 22% second click on ON brings light to 50%.
When the light is at maximum setting, and i want to turn it off, pressing OFF button blinks for a second and reports status of OFF, than display button as ON but it keep dimming down to 0% (for 1 minute) until it turns Light OFF, and changes status to OFF.
Seccond click during dimming Down will instantly turn Light OFF.
Double click does not work, it needs about 1 second in between 1st and 2nd click.
I would only change order of settings when that becomes available, and maybe verbage on that last option ”If switch pushed Running GoTo" to your own explanation
This sequence semms runs correctly:
Current state = OFF → click switch → start diiming from 5% to% 0% > click switch during dimmin → go to 50% and dimming stoppped.
Current status ON max dimming → click switch → start dimming to 0% in 1 min → click switch → go to 0% and dimming stopped.
Actions Go To: End, Off, Stop only take efffect when dimming current status is "running" If current status of dimming process is “stopped” then diimming process starts in the direction of the received command turn “On” or "Turn Off ".
For better operation with automations, another option Go To : “Change” could be added, which stops the process in progress and starts the opposite dimming from the current level:
Current status 30% dimming to 50% → clich switch → start diiming from 30% to 0% in programmed off time
Current status 30% dimming to 0% → clich switch → start diiming from 30% to 50% in programmed On time
For tthat his to work, you need the option to go to "Change" and put the Off-End-Level setting back that I removed because it could be the case that if the end level off is not 0% the light will never turn off and it could create confusion, but I see that this is what you want
I understand that if “end level is not 0%” it will never turn off. Someone might like that feature, someone might not. I want to be able to eventually turn off the bulb.
Even now that would be achieved by second press (if switch pushed running goto: end/stop/off, if OFF option is selected), but manually only.
If those 3 settings can be exposed to automations, Progressive ON, Progressive OFF, and If switch pushed running goto, than we could call those actions in automations. My understanding from another developer, who creates Edge drivers for Zooz switches, has some device settings available for Automations, that those actions need to be added to device presentation. I don’t know if how easy or hard this is.
For this, it is necessary to create custom capabilities and in that, for now, I only know that they exist.
I am modifying some things to see if it is worth to you and also to the others.
I’ll tell you when I have
I publish the version 2.1 of the edge Driver Zigbee Level Color Temperature Bulb:
Added “Turn OFF End Level” setting
When “Turn OFF End Level” is > 0, then the bulb can be turned OFF with Off command and bulb current level is = “Turn OFF End Level”.
Added Go To: “Change” option, which reverses the direction of the dimming when switch pushed in dimming process.
This allows a simple automation with a progressive Turn ON with x settings and a progressive Turn OFF with y settings, even if the ON or OFF commands reach the device during the dimming process.
Changed the Minimum dimming time from 0.5 min (30 sec) to 0.1 min (6 sec). With different dimming timer increments for times <=40 sec
In order for the actions to be executed more quickly, the recalculation of dimming variables has been restricted to the installation with preference values and when any preference is changed. Let’s hope the infoChange life cycle improves!
With edge Driver, the infoChanged lifecycle is generated when you click save each changeof a preference value. How code is executed with the change of any value, is recommended when more than one value is changed in preferences:
Change a value, click save and exit
Enter again to change another value.
Allow time between changes if several are going to be done
Hopefully this improves after the beta version.
I tested your particular Porch bulb use with these preferences and automations:
You will tell me!
@Mariano_Colmenarejo thank you for creating such a great driver. I have seen something similar like this previously only for some Osram RGBW Lights, that have firmware with some special capabilities (pulsing, random colors, etc.)
Great job. I think that SmartThings should consider this as official “ZigBee White Color Temperature Bulb” driver. I can see from some samples that you can just keep adding other bulbs’ profiles, and they should work without no problems to some extent.
I am not pushing for features that only I need, I am trying to help you to develop driver that will fit almost everyone, or in another words that will cover almost any Zigbee White temperature bulb.
There are still a couple of quirks to fix.
As I have previously mentioned, Temperature range needs to be fixed, as you said possibly with subdrivers. I can’t find post, but if I remember correctly, @nayelyz said that, that issue can be fixed by specifying in device capabilities. All of mine, and i know that others’ can be different like Lidl, White Temperature bulbs have range from 2700-6500K. Maybe @nayelyz can help with this, as in best interest for all SmartThings users.
This is the same bulb, Old Groovy DTH temperature range in Automations
If you see that you make a change and you do not see that they are applied, even if the value is in preferences, it is because sometimes infoChanged does not send the change.
It can be seen in the logcat with the CLI, which print the old and new value when there is a change and sometimes it does not appear in the logcat.
Just change it back.
@Mariano_Colmenarejo Porch lights work as you described, dim up and down on motion change. They go on/off at sunrise/sunset change.
However, I am do have additional actions in my automations, Color Temperature change, 2700K when there is no motion, and 4500K when there is motion. That is not possible with progressive OFF, as app logic is as soon as you select OFF action it disables Color Temperature. It can’t be changed back to 2700K. By disabling Progressive OFF, i can go back to 50% 2700K, but is instant. I’ll have to play with this a little bit. I don’t think that your can do anything about it.
Unless… We can have Progressive Color Temperature (increase/decrease) to set K values.
Anyway your driver’s features are good enough for now. They work as intended. I can live with my porch lights being controlled different way.
Maybe we shouldn’t turn this driver in to smart app.
From my ignorance of the global operation of the system, but seeing that the end of this new stage, in beta phase, is to have many drivers running locally in the hub, which has limited resources, memory, processor, I don’t know if this type of driver fits into the new structure, especially thinking of users with many devices, I choose to make this type of driver an option and explain:
These drivers are small apps that consume hub resources, memory for variables, processor cycles …, this one in particular needs 18 extra table-type variables more than the normal driver. These tables store 18 values for each device installed in the driver, whether its dimmer functions are used or not. These variables are created when the device is installed and must be deleted when it is uninstalled.
They are special functions that are required for specific devices, 2, 3, I use it only in a light bulb, not for all applicable dimmers in our home. It can also be used for zigbee dimmer switches.
With the so simple tool that the app has to change one driver for another, this type of driver can be installed in just 15 sec in the devices we need and in the rest of the devices use the stock driver that consumes less resources from the hub.
That’s why I doubted whether to publish it as a different driver id than the normal one instead of a version.
That way you can only install it on the bulbs or dimmer you need.
Surely professionals who know the smartthings ecosystem have solutions to standardize this type of dimming functions or perhaps what I say does not make sense and the hub can handle this and much more.
I only try to solve my automation needs and those that other users propose in the community, with the tools that I have at my disposal.
It is what I appreciate the most about the smartthings platform and its community, I can personalize, share, ask, they respond to me and by the way I learn, I have fun and I keep up to date.
I know that for others the automation of their home is a necessity not a hoby
It is a matter of adding model and testing, nothing is damaged, if it does not work it is deleted from the driver in 5 minutes.
If you have an individual zigbee 3.0 dimmer switch you can try to see if it works.
I don’t have any to test.
Most zigbee devices pair very easily with these drivers.
Uninstall them from the app and they stay in pairing mode. searching nearby and without disassembling it, even through repeaters they are installed perfectly.
The zwaves are more complicated to handle