When setting up smart lighting in my house, I prefer that the lights can be controlled using wall switches. One of the use cases I have is that I would like to be able to control the dimming (and possibly color) of a smart RGBW bulb from a wall switch. So far, I have not found any ideal (and inexpensive) solutions. If someone is aware of one, please let me know.
However, I have an idea of how to make this work using Hubitat, a smart dimmer switch and a smart RGBW bulb, both of which are flashed to Tasmota. Here is what I am thinking:
The Tasmota code is modified for the Smart Dimmer Switch so that, rather than adjusting the PWM for the voltage driver when the brightness up/down buttons are pressed, the PWM is always left at 100%, but messages are sent to Hubitat indicating that the buttons are pressed.
An App on Hubitat receives the commands and then sends dimming commands to any of the bulbs that are to be controlled by the smart dimmer switch.
The Tasmota code is also modified so that if a user pressed the up/down brightness buttons simultaneously, it changes to "color mode" and then any further presses of the up/down buttons on the smart dimmer will cause the bulbs to change color (it could perhaps cycle through ~20 different colors) via messages through Hubitat. After 30 seconds of no presses, the switch would revert to "dimmer mode"
Create an App on Hubitat (as mentioned in #2 above) that manages the communication between the switch and bulbs.
The main advantage of this system is that I can use smart RGB bulbs, but the brightness can easily be changed using a wall switch for those who prefer not to use an app. Changing brightness is a common activityand it would often be easier to just use a wall switch rather than an app.
Has anybody done something like this before? Is this something others might be interested in? Any pitfalls of this idea that stop it from being feasible?
What tasmota smart dimmer are you thinking of using for this?
The problem is going to be about binding the bulb's level to the dimmer's level. Most dimmers, when the level is changed locally, do not report the level until the dimmer has finished changing. Otherwise there are too many things to report to the hub. This means that as you hold down the paddle to brighten or dim the bulb, the bulb won't change until you release the paddle. So you are changing the level in the blind.
This is not necessary if the device is a dimmer in hubitat you can link them with mirror or switch bindings.
This is not possible as I understand it with tasmota.
I am going to say something you really don't want to hear....this is never going to work the way you want it to. What you really want on the wall is not a smart dimmer but a button controller. Something like a hue dimmer or Lutron Pico. Something that allows you to modify the behavior of every button at your whim. Not hardware that is going to restrict what you can do with it, which every smart dimmer is going to do. The smart dimmer is never going to be paired to the bulbs in a meaningful way that you are going to like. Also, with Wifi RGBW bulbs, you have to make sure they support the startChangingLevel and stopChangingLevel commands or you are not going to be able to ramp the brightness of the bulb from within Hubitat. You'll only be able to set the level.
So, if you really want this functionality, i would consider using Sengled bulbs or a hue bridge with hue bulbs and a button controller on the wall, not a smart dimmer.
I am thinking that I could possibly modify the Tasmota code to require a button push and release for the dimming level to change. One message would then be sent per button push/release.
Useability would be affected by the time for the message to be sent to hubitat and then a message sent to the bulb. This would certainly be a useability problem if it took too long. I don't currently have a good idea how long it would take. However, I think this would avoid the issue you mentioned of changing the level in the blind, which I agree would be very problematic.
Ok. Thanks for letting me know.
I need to review the code in Tasmota in detail to understand why it could not be modified to do this. I don't understand, in principle, why it could not. However, I could surely be wrong. If you know of a specific limitation that would prohibit such functionality, I'd be interested to understand.
I am always happy to hear if something is not going to work before I sink time into it. Knowing what potential issues exist is very helpful.
I will look further into those. Although, admittedly, this project is more about amusement for myself to learn more about Hubitat and Tasmota, rather than just trying to find a solution. So I will keep digging into my idea a bit more. Also, if I can get it to work, it will likely be a much lower cost solution.
This is the one point you made I didn't understand. Why isn't setting the level sufficient? I was thinking I would have 6 to 10 levels, with each press of a button increasing or decreasing a level. In this scenario, why would I need the startChangingLevel and stopChangingLevel? I must not understand something correctly.
This isn't going to work unless you are able to get the tasmota light to recognize the startLevelChange and stopLevelChange commands, which i do not know that they do. Also, you are going to get the tasmota firmware to report button release? That's no small feat my friend.
When you beginning dimming or brightening a bulb in Hubitat, you do not issue a setLevel command. You use the "startChaningLevel" command. This tells the bulb to start brightening but it can be stopped before it reaches full (or min) brightness. The problem with issuing a setLevel is that there is no way to stop it. So, if your light was at for 50% and you held the upper paddle on your dimmer, what command would you issue to the Bulb in Hubitat? You can't issue a setLevel because Hubitat doesn't know what that number is yet. You have to release the paddle before it knows what level the lights is going to be. The only way around this is to start issuing a series of setLevel(currentLevel+changeAmount) type of commands repeatedly. I have tried this for wifi lights. It doesn't work. You always get the "run-away" effect where it doesn't stop when you want it to.
The way that hubitat does this with button controller is through the startChaning stopChanging commands, which would have to be supported by your wifi bulb in some way.
I mean, if you really want to try this, have at it. I'm just telling you, having been someone that has tried it, after days of effort i scraped the whole thing and went with bulbs supported directly by HE or Hue. Map out what you think you'd do and throw it up here and we can walk through it and see if it would make sense. And if you'd be able to do that. I've worked a lot with dimming/brightening over the last few months so i have a pretty good handle on how they work within Hubitat. I'm more than happy to walk through your ideas for how you would accomplish this on the Hubitat side of things.
If they use a secondary MCU, likethese do (TuyaMCU), the ESP8266 MCU doesn't actually receive the button presses and can't do what you want. If the actual button presses are received, no rewriting of Tasmota should be needed, and if it is, I'll happily do it.
This is possible as long as the button presses are handled directly by the ESP8266 or you write a new firmware for the secondary MCU (a LOT of work, but if it's the TuyaMCU you're writing for, I'd be interested to cooperate in writing it, it seems like a lot of fun and I have lots of wall touch switches with that MCU).
I did some research in the past, the TuyaMCU is in general (always?) one of these: https://www.st.com/resource/en/datasheet/stm32f103c8.pdf
And I guess this could be used to get started:
Didn't go further than that though since this is not a project to go about doing alone...
The bulbs with Tasmota should be able to be made to do this in a robust way with Rules directly in Tasmota, if not with Rules, so with Scripts (needs to be compiled in and is not available by default).
I'd say you COULD do it this way, but the startChangingLevel and stopChangingLevel makes for a much more smooth and it provides a MUCH better user experience. See @Ryan780 answer.
So to sum this up, as someone who has rewritten part of Tasmota and read most of the Tasmota code, I believe it is possible, although it requires a lot of work unless you find a dimmer without a secondary MCU. As I mentioned earlier, if you do decide that you want to write a firmware for the TuyaMCU, I'll happily assist and cooperate on it. I expect it to be a lot of work and not very easy, but as such, a lot of fun!
One thing I can mention, it is within the capability of Tasmota to send commands directly to another Tasmota device... So it is very much possible to make things VERY snappy...
How would you accomplish this on the ESP8266? I do not know of any way of sending these commands to tasmota dimmers. If you do, I'd like to see how it works.
You could have a rule start a timer which slowly increases/decreases the dimming level. The timer can be started by a custom command event, then stop that timer with another custom command event. This runs locally in Tasmota.
How? What command would you issue to the Tasmota dimmer to get this to happen? And what would you issue to get the dimmer to stop when you want it to? You can be as specific as your are able. If you don't know, then I would recommend that you not suggest this course of action to the OP.
This is not 100% complete, but works, but it will not give a 100% smooth increase/decrease, for that, scripting (which can use a 100ms frequency in execution) could be used:
Rule1 ON Event#startUp DO Backlog Fade 1; Speed 20; Var1 1; RuleTimer1 1; RuleTimer2 15; Dimmer +; ENDON
Rule1 + ON Rules#Timer=1 DO Backlog Fade 1; Speed 20; RuleTimer1 %var1%; Dimmer +; ENDON
Rule1 + ON Rules#Timer=2 DO Backlog Var1 0; RuleTimer1 0; RuleTimer2 0; ENDON
Rule1 + ON Event#stopDim DO Backlog Var1 0; RuleTimer1 0; RuleTimer2 0; RuleTimer3 0; RuleTimer4 0; ENDON
Rule1 1
Rule2 ON Event#startDown DO Backlog Fade 1; Speed 20; Var1 1; RuleTimer3 1; RuleTimer4 15; Dimmer -; ENDON
Rule2 + ON Rules#Timer=3 DO Backlog Fade 1; Speed 20; RuleTimer3 %var1%; Dimmer -; ENDON
Rule2 + ON Rules#Timer=4 DO Backlog Var1 0; RuleTimer3 0; RuleTimer4 0; ENDON
Rule2 1
Available commands:
Event startUp
Event startDown
Event stopDim
And I do know... You could probably also rework it to use the Delay command together with a custom event to get it nice and smooth.
It doesn't seem to me that new firmware would need to be written for the secondary MCU. Although I agree it would be fun....and a lot of work
I totally agree that would be much better, if possible.
I order the Treatlife dimmer and will get it in mid January. Unfortunately, getting some of the modules I want in Canada sometimes takes a bit of time. I will be able to start playing around with it then.
Thanks @markus . I appreciate it. And I am happy to receive information even if you are not completely sure, but it gives me an idea of where to look. I started working with designing and coding embedded systems in the mid 90's, so I'm used to investigating things and trying to figure out how to make things work, or finding out they don't. However, I am only a newbie to Tasmota and Hubitat so not sure of specific features or implementation details, and will likely ask some dumb questions. Your patience is appreciated. Thanks!
The TuyaMCU in general does not report that a button is pressed, instead it reports the event that happened, eg. once you release the button it will tell you: The dimmer was set to x%. It will not tell you when the button was first pressed... And for wall touch switches like those that I have, it will report to Tasmota once the relay has been switched and the button LED has been turned on. So for example, I can't say from Tasmota to the module, NO, don't turn on the relay and no, don't turn on the LED. Nor the reverse. If I want to force lights on/off for example, I can't...
The data from the TuyaMCU is sent through a serial connection, and is structured like this:
I'll try to get something similar here in China, they're made here, but can't seem to find them for sale here...
Hardly "simple" as you said. I stand by my original suggestion. Get a native bulb instead of a Tasmota one. They are less than $10 for white bulbs right now. Why go through all this hassle?
Yes, I never said "simple", I said possible. If the goal is to just solve the problem of having a dimmed bulb behave this way, sure, go get a pre-made solution. If the goal is to learn and have some fun with an MCU, then this is what I'd do. I could easily go buy all the pre-made solutions out there and use those, would that be as much fun for me? No, not for me. For someone else, maybe? Probably? It all depends on the goal. For me, the journey is just as important as the destination.
I had some fun and came up with a different way for the fading that is rather good, if someone tries it, do tell me about how it works:
// Use these three commands to start and stop
Event StartUp
Event StartDown
Var2 StopDim
// Delay between commands in Backlog in ms, default is 200, max is 255, use to calibrate
SetOption34 10
// Updated with the current Dimmer value
Mem1 0
// Step for each increase
Mem2 4
// delay in 10th of a second (1 = 100ms)
Mem3 1
// Fade speed to use (1 = fast, 20 = slow)
Mem4 15
Rule1 ON Dimmer#State DO Mem1 %value%; ENDON
Rule1 + ON Event#StartUp DO Backlog CalcRes 0; Fade 1; Speed %mem4%; Var1 %mem1%; Var2 Go; Add1 %mem2%; Var4 %mem2%; Event Go; ENDON
Rule1 + ON Event#Go DO Backlog Event %var1%; Event %var2%2; ENDON
Rule1 + ON Event#Go2 DO Backlog Dimmer %var1%; Add1 %var4%; Delay %mem3%; Event %var1%; Event %var2%; ENDON
Rule1 1
// Set dimmer to something so that Mem1 contain the start value
Dimmer 49
Rule2 ON Event#StartDown DO Backlog CalcRes 0; Fade 1; Speed %mem4%; Var1 %mem1%; Var2 Go; Sub1 %mem2%; Var4 %mem2%; Mult4 -1; Event Go; ENDON
Rule2 + ON Event#StopDim DO Backlog Var2 StopDim2; Fade 0; Speed 5; ENDON
Rule2 + ON Event#StopDim2 DO Backlog Fade 0; Speed 5; ENDON
Rule2 1
Rule3 ON Event#100 DO Var2 stopDim; ENDON ON Event#101 DO Var2 stopDim; ENDON ON Event#102 DO Var2 stopDim; ENDON ON Event#103 DO Var2 stopDim; ENDON ON Event#104 DO Var2 stopDim; ENDON ON Event#105 DO Var2 stopDim; ENDON ON Event#0 DO Var2 stopDim; ENDON ON Event#-1 DO Var2 stopDim; ENDON ON Event#-2 DO Var2 stopDim; ENDON ON Event#-3 DO Var2 stopDim; ENDON ON Event#-4 DO Var2 stopDim; ENDON ON Event#-5 DO Var2 stopDim; ENDON
Do remember, there are no if-statements, so this is what happens...
Knowing what potential issues exist is very helpful.
