This is the forum archive of Homey. For more information about Homey, visit the Official Homey website.
The Homey Community has been moved to https://community.athom.com.
This forum is now read-only for archive purposes.
The Homey Community has been moved to https://community.athom.com.
This forum is now read-only for archive purposes.
Dimming variable - the perfect flow?
cbh
Member
Hi,
As many others, I have a dimmable unit that can be controlled from different (physical) switches and remotes.
It is relatively easy to make flows using scenes etc. making a single push on a button toggle on/off and "long press" de-/increase intensity using some bolean variables and a couple of flows (see below).
But:
If the lamp is to be controlled from different switches/remotes, the number of flows explodes - and I don't like that (period!).
I'm sure it must be possible to integrate a lot in the same flow - especially using formulas in Better Logic - but I've not succeeded in doing it yet :-(
Therefore: Here's my try - it works, but it isn't exactly the most beautiful ever seen...
How can I improve it?
Regards,
Chr.
The setup is:
1x Fibaro Dimmer 2
1x Remotec remote (Button 6)
Flows:
1: On/off-flow according to bolean variable "L_K_on-off" (Light in the Kitchen) with intensity set with the variable "L_K_Dim-intensity"
2: Flip bolean variable "L_K_on-off" when pressing button 6 on remote
3: Flip bolean variable "L_K_Dim-dir" when releasing button 6 on the remote
4: Increase intensity by adding 0.03 to the variable "L_K_Dim-intensity" (The formula in is round((L_K_Dim_intensity+0.03)*100)/100) as long as the value is less than 0.8 (as the upper limit in the Fibaro DImmer 2 is kalibrated to 0.83)
5: Decrease intensity, same show as #4 but different.
6: Safety-flow: If variable "L_K_Dim-intensity" goes outside the limits, it is forced to 0.2
As many others, I have a dimmable unit that can be controlled from different (physical) switches and remotes.
It is relatively easy to make flows using scenes etc. making a single push on a button toggle on/off and "long press" de-/increase intensity using some bolean variables and a couple of flows (see below).
But:
If the lamp is to be controlled from different switches/remotes, the number of flows explodes - and I don't like that (period!).
I'm sure it must be possible to integrate a lot in the same flow - especially using formulas in Better Logic - but I've not succeeded in doing it yet :-(
Therefore: Here's my try - it works, but it isn't exactly the most beautiful ever seen...
How can I improve it?
Regards,
Chr.
The setup is:
1x Fibaro Dimmer 2
1x Remotec remote (Button 6)
Flows:
1: On/off-flow according to bolean variable "L_K_on-off" (Light in the Kitchen) with intensity set with the variable "L_K_Dim-intensity"
2: Flip bolean variable "L_K_on-off" when pressing button 6 on remote
3: Flip bolean variable "L_K_Dim-dir" when releasing button 6 on the remote
4: Increase intensity by adding 0.03 to the variable "L_K_Dim-intensity" (The formula in is round((L_K_Dim_intensity+0.03)*100)/100) as long as the value is less than 0.8 (as the upper limit in the Fibaro DImmer 2 is kalibrated to 0.83)
5: Decrease intensity, same show as #4 but different.
6: Safety-flow: If variable "L_K_Dim-intensity" goes outside the limits, it is forced to 0.2
Comments
Recently @Phuturist pleased the community with the creation of an app for all kind of Mi-home products under which also Yeelights. The app works fine at this time but only holds basic settings for color, hue and saturation.
Besides that the yeelights (in their native app) work with scenery modes, it would be nice to simply dim these lights via homey.
Not trying to steal this topic, but pulling it somewhat broader to dimming of lights via variables, would be a nice ideas I guess.
Anyone having nice ideas about this? My personal ideas are far, far down since I spend last few days on sales tax statements....
I was wondering, how do you control the speed between the 0.03 increase of intensity?? Setting a delay of the shortest available delay (1 second) is quite long I think??
Thanks :-)
You're quite right - it's a tricky bit as well.
I've tried using both the Remotec Remote and the Logichome ZHC-5010-switches with this flow and "discovered" (read: been told by someone as I didn't understand it) how the z-wave standards can be applied in different ways afterall.
My flow is based on the action "Held down" in both cases.
However, this is implemented in two different ways:
The ZHC-5010 sends one signal each time the button is "held down" (more than 0.5 sec) - and nothing more until it has been released again.
The Remotec Remote, on the contrary, sends a signal, that the button is "held down" every 0.2 second as long as the button is "held down".
My flow included 24 "steps" (in-/decrease of intensity with 0.03 in the range 0.08-0.80); with the Remotec Remote dimming from one end to the other takes app. five secs (24 * 0.2 sec).
Unfortunately, it is rather impractical to implement the flow on the ZHC-5010, as this will take 24 times "more than 0.5 sec + releasing the button". Of course, you would actually never get anywhere with my flow, as the dimming direction changes every time you release the button making you go one step ahead and then one step back forever...
Consequently, my flows are more "classic" with the ZHC-5010, as I have assigned one button to be one step up when pressed once and antoher one step down when pressed once.
(The manufacturer of ZHC-5010 is aware of this and has put in on the list of considerations for future updates, btw).
On the re-triggering of Z-wave remotes, you are right.
I'm just working on a new app to provide support of the Z-wave device of Hank-tech.com, including 2 scene controllers.
Also these scene controllers only send the "key held" trigger only once... so it depends on the implementation by the manufacturer.
But considering these flows, I'll have a look if it is possible to implement it from driver / app side ....
/Sent from my phone
The better logic solution is working ok but it takes about 2 seconds to calculate and send commands to my lights, I think that's 1.8 seconds too slow.
The clearest way is that Athom starts to support changing values with an amount or percentage without using logic or better logic cards. So something like 'Increase the brightness by 0.05 points' or "decrease the brightness by 10%'.
@chh Why are you calculating *100/100? If you use the round calculation you already bypass the problem with 0.000001 off values after calculations.
Edit. I had to try the single calculation, before I had two. You can increase or decrease the variable with this: (round((L_K_Dim_intensity+0.03),2) and (round((L_K_Dim_intensity-0.03),2) it is a bit shorter
Also I think that you can use the tags of your devices for the on or off states. So only run the flow if the device is on or off. That cleans your bolean variables and it's flows.
I found a workaround for adding the dim variable label from the device itself as the variable betterlogic should calculate with. Because when you manually dim the device the variable value is not right. Also I did the change of intensity in the safety flow. Because it takes 0,5 sec for the variable been set.
As suggested, one Boolean variable has been discarded and the new "or"-option made it easier to keep the variable inside the limits.
Probably a deeper knowledge of the possibilities in json could make the calculation of the dimming direction directly related to the Boolean value itself instead of the then/else-option - but from six to four flows is something, after all...
Flow 1: On/off-flow.
The two cards regarding the unit "Kitchen (ZH..." concerning LED-status are to get around the missing multichannel associations at present.
The brown tag is on/off-status of the dimmer named "L-Kitchen" and the blue tag the variable "L_K_Dim_intensity" the intensity (brightness) of the light (surprise!)
Flow 2: The dimming flow itself.
The calculations are:
Up: "round((L_K_Dim_intensity *1.1),2)" and
Down: "round((L_K_Dim_intensity *0.9),2)".
As you may notice, I've changed from adding/subtracting an absolute value to multiplying in order to make it easier to fine tune the dimming in the low end and to speed up the dimming in the other.
Flow 3: Flipping direction.
Releasing the button flips the dimming direction.
This flow could be omitted, if satisfied with a "all-the-way-up-then-all-the-way-down-then-all-etc..."-solution.
Flow 4: Limits
If the result of the calculation in flow #2 ("L_K_Dim_intensity" ) is higher than the upper limit or smaller than the lower limit, the variable "L_K_Dim-dir" is flipped and the "L_K_Dim_intensity" should now move into the "safe" direction.
(There's a theoretical chance, that the variable reach a value just below the limits and the next calculation will not bring it inside the limit again, that is, if the variable happens to be exactly 0.09 as the last value when going "down", therefore I've chosen the logic "<=" to avoid a limbo).
A few questions, are you using the dim variable of the device itself in the betterlogic calculation? Because when you use the betterlogic variable, the variable doesn't change when you manually control (dim) the light.
When I put the brightness change in the key hold down flow, the brightness always walks behind 1 step, perhaps because of the slow speed of klikaanklikuit?
So I think this method will only work with a z-wave device. Now I have to use double press for this flow to work with KAKU.
Went the other way around in my private logic: that the dim level should always be set using the better logic variable - no matter which action triggered the change - but using the actual value is better, of course...
Have changed my formula to use the actual level as basis for the calculation ("#Dim level (L-Kitchen)" in my case...) - and now it looks like:
Can't figure out, though, if there's a way to do the calculation using only the "#Dim level (L-Kitchen)" variable and eliminate the better logic variable "L_K_Dim_intensity" entirely?
(or, actuallty, a way to make the non-existing option "Increase brightness by xx %" in a single card)
(oh, think if this was added to the app someday...)
Adding an option "Increase brightness by xx %" in a single card) would not be that difficult; but as long as it is not a default card it will need to be added for each device manually to the app... Similar to the 'change duration over time' card I added for the dimmer-2....
Using the tag actually delays the process significantly...
As far as I can see, the reason is, that changing the flow to use the tag, not the better logic variable, introduce two extra communication steps: the central controller ask the dimmer for the present status, which the dimmer then returns.
Depending on the number of nodes the communcation goes through, this adds up pretty quickly...
Thinking about it, the problem you mention @LJSVV, is only a problem when you start dimming (and the light has been dimmed manually since you dimmed using a flow setting the brightness with the better logic variable) - as soon as the loop has run once, the brightness will be equal to the better logic variabel and things will run smoothly.
I agree, that if the light has been dimmed to something very low manually, and you then want to fine tune it with a remote and the better logic variable is something very high, then you will get in trouble.
However, the delay introduced (at least in my network) disqualify using the tag...