| Current | Previously... | Archives | About |
I have previously written about products from SwitchBot, and I remain a big fan of their robotic fingers, but their relatively new Candle Warmer Lamp needs a lot of work in the usability department.
Physically, the device is fine. It's essentially a lamp that melts a scented candle using the heat of a halogen bulb. The design is minimalist, but functional. All the "smart" controls are housed in a mid-cord dongle that also provides manual control of the device.
But the SwitchBot app that controls the candle warmer is a disaster. I wanted the device to turn itself off after a programmed number of minutes, and I simply could not figure out how that was accomplished in the byzantine-like app.
(And for those of you new here, I am no stranger to smart home programming.)
I reached out to SwitchBot tech support, asking if such a thing was even possible, and days later I received a reply that, while accurate, was vague and presumptive.
Fortunately, by the time they replied, I had figured out a workaround that accomplishes what I want.
In the automation tab of the app, I defined a Candle Warmer automation with a "When" trigger of the lamp being turned on.
The "Perform" sequence of the automation is:
I know, this seems like a no-brainer. But unless you've used the SwitchBot app, you can't appreciate how difficult they make this.
The automation is triggered when I press the power button on the lamp's cord. Presumably it would also be triggered by an automated action that turned on the lamp, but I haven't tried that.
The brightness level refers to the halogen bulb in the device. This determines how quickly it melts the scented wax. This setting is my preference, and I've included it in the automation to ensure it's set exactly as I want it to be.
I'm using the 10-minute "After" timer action. There is a "Delay" action available in the app too, but I cannot get it to function as I expect it to work. (And it was the option that tech support mentioned to me.)
I am using this as a triggered automation based on the device being turned on. The reason is that I don't believe (nor recommend) that devices like this should be put under full automatic control. This automation provides a bit of a safety net by limiting the device's runtime if it is turned on accidentally, either by an errant signal, or human error.