I like the aesthetics, but on the whole it is a bit disappointing:
(As far as I can tell) can’t bind directly to a smart bulb or group, so you’re reliant on the switch triggering an HA automation.
Although the buttons have *_hold actions to capture long-presses, they only trigger after you release the button, so you can’t do “fade while the button is being held, stop fading when released” type actions.
So, is anyone aware of any switches that are better, but look similar / third party firmwares / tips for setting these up better?
Direct binding goes poorly when mix-matching manufacturers. It does not have a standard protocol and different companies do it different. Note that most Tuya firmware is written by multiple manufacturers, so Tuya itself is not a mfgr, it is a type.
Um, Tuya is a probably described as a supplier of generic devices that many ‘manufacturers’ customise with their own branding, but rely on the consistent underlying protocols and firmware to provide their needs.
It’s a whole ecosystem that is designed to interoperate, with the Tuya cloud behind the scenes.
Most suppliers are actually only box-pushers, relying on the expertise of the Tuya people to manufacture their boxes and manuals and icons on the standard control software to differentiate their products from the other ‘manufacturers’ that also use the Tuya ecosystem. Economy of scale and generic solutions are the strong points here.
Go to the website for Tuya and see for yourself, how you can ‘design’ your own solution using their standard building blocks, with a point and click type selection, and then proceed to order for manufacture. Add your own branding and voila - yet another cheap Chinese device, ready to be hacked within an inch of it’s life for HomeAssistant aficionados.
This is where Tasmota/ESPHome/Arduino and other third party firmware hacks can add missing functionality. These are the building blocks you substitute for the Tuya ones. Roll your own functionality using generic hardware. The sky is your limit once you realise this.
Yes, define your buttons as switches, set the timing parameters, count the number of presses, throw in some MQTT functionality, flash some LEDs, and do whatever you want! The underlying hardware is the same, it is just how you harness it.
Knowledge is power, and putting existing devices to new uses is quite empowering, and satisfies the lust for tinkering.
That looks good, thanks. This device isn’t listed as supported, so I guess I will need to crack it open and check the chipset (and probably get a second one to tinker about with since my wife will probably be upset if I brick the bedroom light switch!
Does this seem relevant? I found it with a Google search for “tuya ts0043” (Noted the comment somewhere that ‘wife file for divorce time’ was faster than ‘device switch press response time’)!!!
Stepping back to look at the bigger picture: Where is the problem?
Is the device not providing the correct functionality you need (get another device), interpreting a switch toggle as a button press or something like that in hardware (get different firmware)? Is the data it is emitting when the state changes incorrect (change the firmware configuration)? Is the way that signal is being interpreted in HomeAssistant integration incirrect (change the integration)? Is the way you use the signal state change incorrect (change your yaml, etc)?
I searched again using Google ‘tuya ts0043 firmware’ to find what chipset Tuya were using to see if it had a customised version available. The AI hints it threw up were most interesting. Scrolled down a few lines and saw the OpenHAB community solved similar issues a number of years ago, so I suspect the issue is not hardware, but careful configuration and suitable software, and maybe a bit more robust research.
The problem with AI is that (aside for its propensity to make up complete BS and pass it off as reality), it generates a different answer each time. So you telling me what prompt you gave it for a really helpful answer doesn’t help me - I get a completely different answer which is not helpful and doesn’t mention OpenHAB at all.
The non-AI google results to OpenHAB appear to be just talking about getting the device to work at all, and don’t address the problems I raised in my original post.
Doesn’t appear to be relevant?
This just appears to be talking about pairing the device with the coordinator, so not relevant to my original post?
Per my original post:
As far as I can tell, this device can’t bind directly to a smart bulb or group, so you’re reliant on the switch triggering an HA automation. I can bind the switch to a group, but it doesn’t actually appear to do anything to the other devices in the group when I press a button. If I try to bind the switch directly to a light bulb, no “clusters” appear next to the binding, so I can’t actually add the binding.
Each button has a _single, _double and _hold action. The _single and _double actions work as you might expect (they are triggered after a single or double tap). If you hold the button, nothing happens until you release it, and then you get a _hold action. This means you can’t have an automation to “do stuff while the button is being held down, then stop once released”. When I bought the switch, I was hoping to be able to do single tap to turn a light on/off, hold to gradually fade and then stop fading on release, but this appears not to be possible with this device.
So my questions were:
Is anyone aware of a very similar looking device which doesn’t have these problems?
Are there any third party firmwares that might solve these problems?
Is there a better way of setting up the device that might solve these problems?
I’m afraid you won’t find a lot of battery powered switches that support long-push (as it will drain the battery too quick )
But i know one…the ikea E1743 (brightness_move_up/down)
But it doesn’t look similar to what you want at all
Yeah, I tried to search the zigbee devices repository for all battery devices which match your requirements for you and came up short.
You’re looking for something which has support for both a hold AND a release action (like this). Unfortunately there don’t seem to be any touch switches returned in the results. To make things worse, you cannot search for hold_release in the main page since those are properties of the action exposes - you have to click on each individual device & search.
Sorry mate, looks like you’re either gonna have to go wired or else have to forget about stopping the dim command on release.
@FireFury you’ve correctly identified that you need binds for a reliable smart home, well done!
I’m surprised your device does not support bindings, are you using ZHA or Z2M? The latter offers better device support sometimes.
These kinds of devices sole purpose is binding to a light bulb, normally they have it… And I also expect the hold action to appear as soon as you hold it, not when you release it.
Note that some devices (notably IKEA) can only bind to groups or can only bind to devices individually. (eg. E1743)
As others have pointed out, most Tuya devices are usually almost identical, regardless of the design and branding (But again, I expect them to have bindings). It’s very rare to find differences in their firmware/behavior. So I suggest also checking non-Tuya devices: IKEA, Aqara, SONOFF, Philips.
Regarding custom firmware: thanks @aceindy for the shoutout! I stumbled across this thread by accident. Romasku’s firmware currently supports only mains-powered devices (namely switches and switch-modules), but you can check out adjacent custom firmware:
You can’t bind the switch directly to the light bulb. If I go to the switch’s bindings and select the light bulb as the destination, no clusters are listed.
You can bind the switch to a group (go to the switch’s bindings, select the group as the destination and pick the OnOff cluster). This appears to bind successfully, but pressing the button does nothing to the bulb which is a member of the group.
You can’t add the device to a group through the Groups page of Z2M - you can go through the motions in the UI, but then it tells you the command failed (and yes, I was poking the buttons to keep the device awake while doing that, didn’t seem to make any difference).
If I look at the Clusters tab for the light switch, it lists genOnOff as an input cluster, rather than an output cluster… which sounds completely broken to me. I’m not sure if that is a Z2M bug or a bug with the device though, but it may well explain why binding isn’t working at all, if it thinks it is binding an input instead of an output.
)
