Ebay recall of "Tuya Wifi/Zigbee Smart Fire Smoke Detector Alarm Fire 80db Sound Alarm Sensor"


I bought a couple of Tuya Wifi/Zigbee Smart Fire Smoke detectors on ebay a few months ago. They are recongized by ZHA as TS0205 by _TZ3210_up3pngle and TS0601 by _TZE200_ntcy3xu1 .

Yesterday ebay notified me that the aforementioned objects have been recalled because of a safety hazard for human health or security of the user. ebay told me if I had questions to contact the seller or the producer.

So I asked the seller what’s up with this recall of his object and the seller told me “Don’t worry, you can use this product normally”.

I couldn’t find any recall announcement about tuya/zigbee smoke detector, does anybody know about this recall from ebay, what’s the reason for it?

Thank you

Loooooong discussion on these devices in the Z2M github.

Looks like the devices randomly drop off the zigbee network. Won’t stop them from alarming but they won’t report when they do if they’re offline. Personally, I’d be looking for a different device. And i also don’t design automations to impact life safety.

So the reporting to HA for me is nice to have but - a device that is a life safety device behaving… ‘unexpectedly’? It’s gone. Won’t have it in the house. Life safety devices like smokes MUST work 100% every time and thr minute they stop I replace it

I’d say that very first thing when it comes to fire safety is NOT to use wifi, zigbee… or any wireless thing. Only WIRED solutions. Period.
EDIT: ok, perhaps only exception is to make noise each time sensor goes offline. Which can be PITA pretty quickly.

1 Like

Oh thanks a lot for the link. So the reason of the recall is that the device disconnects from zigbee and the problem is specific to the TS0205 by _TZ3210_up3pngle and does not affect the TS0601 by _TZE200_ntcy3xu1. (I’ve got both, they’re identical from the looks)

The TS0205 by _TZ3210_up3pngle has no zha quirk already preinstalled in HAOS, so it shows up as a motion sensor. I left it like that as a test still worked fine.

The disconnection from zigbee network isn’t actually happening with my device so far with ZHA, it has been connected steady for several days.

I have an automation that notifies me if battery devices go offline for more than a few days and I didn’t get that.

So I guess either I’ve been lucky, or it’ll disconnect soon. I suppose I can keep it monitored.

1 Like

For the cross alert interconnect yes I totally agree - unless it’s a purpose built wireless interconnect like what Halo had (man I miss then. Was a really good device) but that purpose built network was pricey… For a reason it was engineered to pass NFPA interconnected smoke standards.

There should be nothing in HA that should rely on the smoke signal such as unlocking a door on that smoke, for instance. But thats kind of out of scope here.

As to the devices themselves. Misbehaving smoke is a Gone smoke.

Fair enough, but nobody in my area has any smoke detector whatsoever, not even zigbee or wifi.

All I care about is not to decrease security of my place, by keeping those recalled smoke detectors installed for the time being, until I have time to look into replacing them with a more reliable product that isn’t reported to randomly disconnect from the zigbee network. And maybe I’ve been lucky and my detectors don’t actually disconnect. They kept responding to the periodic zha ping so far.

Overall perfection is not the goal of those zigbee smoke detectors, increasing security is the goal of those zigbee devices my view.

Good point. So in my case I use the HA binary sensor of those zigbee smoke detectors purely to send a notification to mobile phones. So worse case scenario if my devices are affected by the recall and they disconnect from zigbee, seem to be that I get no mobile notification on the android alarm channel, but they will still make a loud alarm sound locally, which may be heard if I’m nearby.

1 Like

Ok, if they sound alarm locally then it’s “kinda” ok… the point is that when we install something we automatically depend on that, sometimes too much. Unreliable sensor will give you false sense of security.
There are wireless systems, but, As Nathan wrote, they are proprietary, many times on two frequencies (for anit-jamming purposes), and, of course, expensive :slight_smile:
Similar like those el-cheapo alarm system sets on aliexpress: for very cheap you get it all: main panel with GSM, wireless sensors, wireless siren… you name it. BUT… (of course there’s a “but”): when 9V battery in sensor goes empty nothing is reported anywhere… it just won’t trigger alarm. If you’re lucky you’ll notice when you trigger sensor and led on the sensor won’t turn on…

Well I have an automation for when battery goes out, that covers the case that the device disconnected as it seems is happening to the recalled device. It’s not a guarantee that the device is communicating when it should, but at least it covers the battery going out.

Like said in my case and in this area, the option is either this one, or nothing, so there’s little to lose here. So I’m already doing much better than average just having the idea of installing any smoke sensor at all, let alone zigbee that notifies me on the phone with the alarm channel that bypasses also the silent mode of android.

About this device still sounding the alarm locally, for the record, I don’t know for sure myself. I just supposed it after reading the first answer above that “won’t stop them from alarming”.

All I know for sure is that my zigbee device never disconnected from zigbee yet, its last seen is updated to current time every 2 hours or so pretty much like the TS0601 by _TZE200_ntcy3xu1 that maybe wasn’t recalled. If the device disconnects I should see it unavailable in ZHA with a last_seen older than 12 hours or so. So I guess either ZHA isn’t triggering the bug, or I got a lucky batch…

Thanks everyone for the help figuring out what the recall was about.