I test a Zigbee socket for less than 10 €

⚠ Safety Warning

This test describes the home automation behaviour of a generic Zigbee socket below €10 (integration, measurements, Zigbee traffic, etc.). It does not constitute an electrical safety test bench within the meaning of independent laboratories.

This type of low-cost socket, without a strong brand or clearly verifiable certification, is not not suitable high-consumer or critical appliances (washing machines, tumble dryers, radiators, water heaters, ovens, etc.). For these uses, I recommend products from identified manufacturers, with serious documentation, explicit certifications and reputation to defend.

I now reserve this type of equipment for modest charges, in scenarios where a possible default would remain limited. Everyone remains responsible for their choices: do not take this test as a security validation, but as a home automation feedback.

I am now testing a Zigbee jack for less than €10, a generic model purchased from several different sellers, with no real brand highlighted.

I wanted to check if this type of first prize take could really find its place in Zigbee2MQTT and Home Assistant, without blowing up my budget or degrading my Zigbee network.

At this price, I am mainly looking for a simple socket, able to make on/off cleanly, to reassemble coherent measurements, and to remain reliable over time, for reasonable charges Not for the worst consumers in the house.

🎯 My objectives

I need a connected socket to control a charge and track its power consumption.

I therefore chose this generic model, sold in several very similar forms depending on the shops.

My idea is simple: check if this very economical take can really serve on a daily basis, without complicating my life in Zigbee2MQTT and Home Assistant, limiting it to prudent uses.

I also want to understand how far I can trust him. A connected socket is not just a home automation gadget. It is a device connected to the mains, which must hold the load, measure correctly, and not become a weak point in the house. On this point, I cannot replace laboratory tests: my tests remain those of an informed user, not a certification body.

🔍 I check the received model

  • On the technical sheet : the reference is not really clear.
  • On the carton : the packaging is identical from one seller to another.
  • Type of equipment : Zigbee wall socket with consumption measurement.
  • Protocol : Zigbee.
  • Power supply : sector.
  • Intended installation : Testing in Home Assistant.
  • Measuring ranges : power, current, voltage, energy.
  • Dimensions / IP : compact format, indoor use.

I also note the presence of a CE marking on the label.

I take it up, of course, but without giving him blind trust. The subject of fake logos or ‘China Export’ markings very close to the real CE logo reminds us that we cannot just use a pictogram on a cardboard to talk about security.

On this type of first-rate material, I like to remain cautious and look above all at the actual behaviour of the product, bearing in mind that this does not replace tests conducted by independent laboratories.

🛒 Where to buy this equipment?

I cannot speak here of a real trade mark in the classical sense of the word. It is a generic product, visibly distributed by several different sellers with the same photos, the same promises and, ultimately, products that look identical.

The price recorded varies between €8 and €10, depending on the periods, promotions and probably also the mood of the sellers.

This is exactly the type of purchase where a lottery share is accepted.

On sales sites, there is no clear distinction between a good series and a less successful series.

Everything looks the same to the eye. However, behind the same shell, the behavior can vary depending on the batch, firmware or manufacturing quality.

I still give the link to the Sigalou Lab Sheet TS011F to the seller from whom I bought the test.

📦 Unpacking and First Impressions

At the reception, the cardboard is at the size of the socket.

The product is properly kept inside, so I cannot say that the packaging is sloppy.

On the other hand, a detail quickly leaps to the eye: the ink on the label is drooling on almost all the models I have received. At first glance, it almost feels like the boxes are coming dirty. In fact, it is above all a print linked to a very average print quality.

The catch, itself, surprises me rather well. Plastic is serious, and I find it close to that of some major brands.

I don’t feel the hollow gadget or ultra-low-end plastic effect at all. This is even one of the first good points of this product.

The instructions for use, on the other hand, frankly deserve the medal of the useless document. There is, so I cannot say that he is absent, but he brings almost nothing. Fortunately, in a Zigbee2MQTT and Home Assistant environment, I do without difficulty.

Comparison with the Nous A7Z

I like the Nous A7Z that I have been using for several years, here is a small physical comparison (La Nous is always on the right in the image).

 

 

🔧 Power On

I simply start my test: I'm plugging in the plug.

As soon as the power is turned on, the blue LED on the button starts flashing immediately. This is exactly the behaviour I was hoping to see. This means that the socket enters directly into pairing mode, without complicated manipulation.

I find this important, especially for a generic product. When a low-cost device wastes me time from the first minute, it already leaves with a disability.

This is not the case here. The plug behaves properly from the first connection.

🔗 I pair in Zigbee2MQTT

  • I am authorising Zigbee2MQTT to be paired.
  • I'm plugging in the plug.
  • The blue LED flashes immediately.
  • The catch shall be detected without delay.
  • I rename it as Testing.
  • I enable the update of the Home Assistant Entity ID.

The association is going exactly as I had hoped. In a few seconds.

I do not need to start over, unplug, or try exotic manipulations. Everything is done naturally, which is always nice on a generic product without serious documentation.

In Zigbee2MQTT, the socket is recognized as TS011F with the definition TS011F_plug_3.

TS011F is exactly the same Zigbee model as the We Plug A7Z which I like, which I tested here: I'm testing the Zigbee We A7Z plug

It appears as a Tuya plug with polling consumption monitoring. This detail is very interesting, because it partly explains its behaviour and some measurement peculiarities.

🏠 Integration in Home Assistant

Once renamed, I go to Home Assistant.

I go through the parameters, then the development tools, then the view of the states. I just type taken, and I'll see you right away Testing. I then click on the equipment sheet to look in detail at everything it sets out.

In Device Information, I find the essential elements: Smart plug (with power monitoring by polling) (TS011F_plug_3), the manufacturer Tuya, connection via Zigbee2MQTT Bridge, firmware 500+TZSKT11RM106 and equipment indicated at 2.

For a generic take, I find the integration clean, readable and reassuring.

I also see maps of controls, sensors, configuration, activity and diagnostics. This view is very useful because it shows that the socket is not just visible in Home Assistant: it is properly integrated, with clearly separated and actionable functions.

📊 Exhibitions Zigbee2MQTT

I then look at the list of exhibitions in Zigbee2MQTT, because it is she who tells me precisely what I will be able to exploit in Home Assistant and in my automations. And there, the plug turns out to be rather complete for a model sold at this price.

  • State : on/off condition of the socket.
  • Countdown : stop after a defined period of time.
  • Power outage memory : behavior after power outage.
  • Indicator mode : LED management.
  • Power : instant power.
  • Current : instant current.
  • Voltage : measured voltage.
  • Energy : Cumulative energy.
  • Child lock : locking the physical button.
  • Linkquality : Zigbee link quality.

I am always attentive to this point, because some economic catches are much less talkative.

Here I find the essentials for serious use.

I can pilot, measure, diagnose, and adjust some practical behaviors without special DIY.

The catch is also recognized as router. This point counts a lot in a Zigbee installation, because a plug that is permanently connected is not only used to control a load.

It also strengthens the network's network. This is a bonus that I always appreciate.

⚙ Parameters I Set

I like it when a device offers options, but I like it even more when I can keep it simple. On this catch, I do not need to change everything to achieve consistent behaviour. So I keep a deliberately sober configuration.

 

 

  • Countdown : I'll leave it at 0.
  • Power outage memory : I put on Restore.
  • Indicator mode : I put on off/on.
  • Child lock : I leave on Off.

  • Calibrations and offsets : I am not touching it.

The setting Restore for the return after cut seems logical to me. If the socket was turned on before a cut, it comes back on. If it was switched off, it remains switched off. This is exactly the behaviour I expect in a serious home automation installation.

I also leave the Child lock disabled. My daughters have grown up, so I no longer need to lock the physical button. This detail may seem anecdotal, but it is also this kind of option that shows that a catch like this can adapt to very different life contexts.

As for the calibration parameters, I prefer not to touch them as long as the measurements seem consistent to me. I'm not here trying to turn this socket into a laboratory instrument. Above all, I want a simple, usable and reliable device for everyday home use.

🧠 What the reference TS011F _plug _3 hides

The reference TS011F_plug_3 is not an unimportant detail. Zigbee2MQTT describes it as a take with consumption measurement by polling.

Clearly, it is not always the catch that spontaneously pushes all its measures. It is often questioned by Zigbee2MQTT at regular intervals to recover voltage, current, power and energy.

This point explains the presence of the parameter measurement poll interval in the specific parameters. It makes it possible to define the frequency of querying the measurements. By default, the logic remains reasonable (60s), and in my case I prefer to keep this standard behavior rather than wanting to force more aggressive updates. It should be noted that this can be deactivated if it is not useful. This saves Zigbee network traffic.

I read that this reference also has a small reputation in home automation communities. Some series work perfectly. Others go back from blocked measurements to zero, or behave less cleanly depending on the firmware or versions of the integration. This is exactly the kind of important nuance to know before buying multiple copies of the same model.

In my case, with the firmware 500+TZSKT11RM106, the socket behaves correctly. Measurements go back up, the on/off works, and the overall integration is clean. So I obviously came across a good series, which further reinforces the good surprise side of this test.

⚠ My Doubt About First Prize Takes

I also prefer to remain honest on one point: this type of catch at very low prices is still a source of concern.

The CE marking is present, but it is not enough for me to resolve all the questions. I cannot know, at the time of purchase, whether I come across a perfectly controlled production or a more approximate batch.

So I always keep simple questions in mind: How will the socket behave if I go up in amperage? Will it heat up? Staying well in time? Getting safe? Aging properly?

Without concrete proof of default on my copy, I will not play the alarmist, but I find it healthy to keep this reasonable doubt.

I am also wary of overly simplistic speeches. We are often told that you have to buy more locally to avoid these risks, while many more expensive products are also made in China.

In my view, the real issue is not only the country of manufacture. It is above all the level of control, the specification and the consistency between the series. And now, who can know?

Probably not the final buyer, but independent laboratories and serious brands that pay for real checks.

In the end, I simply conclude that this doubt persists without it having to turn into paranoia.

I test, I observe, I keep common sense, and I no longer use this type of socket on the most demanding or critical devices. This is probably the most reasonable position on this kind of product.

🔌 I'm testing the physical button

I then check the physical button. He does exactly what I expect: a real local on/off. I press, the plug turns on or off. It is not a simple configuration button disguised as a command. It is a real manual control, usable on a daily basis.

For me, this point is very important. A connected socket that remains usable locally retains a form of common sense. In case of network problems, maintenance or just to go fast, I can always act directly on it.

⚡ I look at the electrical measurements

I then move on to the first values raised by the plug. When empty, I find a tension around 221 to 222 V, a power to 0 W, a current at 0 A and an energy to 0 kWh at the time of start-up. All this seems to me to be consistent.

I am obviously not comparing this socket to a professional metrology device, but for domestic use, the readings look clean and credible.

This is exactly what I expect from a consumption tracking plug in Home Assistant. When I want to know if my refrigerator is running or not, this is more than enough.

My feeling at this stage is pretty good: the measurements are consistent, the display is clear, and I don’t need to touch the calibrations to get something workable. At this price, it is already a very good basis.

🩺 I check the health of the Zigbee network

As this plug works with measurements taken by polling, I also wanted to check that it does not spam my Zigbee network. This is important because some sockets or settings can quickly add unnecessary traffic to an already loaded network.

To do this, I use the functionality Health by Zigbee2MQTT. It allows me to look at the total number of messages processed, as well as the number of messages per second. I just filter on Testing to observe his actual behavior.

The result is good. On my capture, I see 89 messages and approximately 0.0557 message per second. For me, it is very good. I don't see any signs of network spam or abnormal behavior. It will have to be confirmed with longer use.

This is reassuring, as it confirms that this catch can remain in production without visibly degrading the health of the Zigbee network.

🧹 I keep a clean record in Home Assistant

Once the tests have been completed, I disable the entities I no longer need in Home Assistant. I prefer to keep a clean, readable interface, and avoid multiplying unnecessary sensors or controls in my daily life. If I need to reactivate them one day, I can always adjust this afterwards in Zigbee2MQTT.

On the final view, I find a clear sheet with the information on the device, the main control, the useful sensors, the configuration retained, the recent activity and the diagnostic part. I really like this step, because it turns a simple technical test into a real clean integration for sustainable use.

This is also a point that is often missing in home automation product testing. Many show the pairing, but not the final state in production. However, it is often here that we see whether a device is really pleasant to live with or not.

🔍 What communities say

Issues raised: some TS011F series no longer correctly expose measurements, remain stuck at zero, or behave differently depending on the firmware and versions of the Zigbee integration.

What I get from it: with this type of Tuya jack first prize, there is always a bit of chance. When buying, there is really nothing to distinguish between a good series and a bad one. My copy behaves correctly, but this variability is part of the game.

My tips: I always start with a unit test, I check the exposures, I monitor the measurements, I look at the health of the network, and I never buy in large quantities until I have validated a first copy. And now, I reserve the tests with strong loads for products from identified brands, designed for this and accompanied by clear certifications.

💬 My opinion after commissioning

✅ Forts: very low price, immediate pairing, correct plastic, consistent measurements, physical on/off button, Zigbee2MQTT integration and own Home Assistant, useful router role, reasonable Zigbee traffic.

❌ Weak: no real brand, ridiculous notice, poorly printed label, quality difficult to judge at the time of purchase, reasonable doubt about the consistency between the series and the actual performance over time, lack of solid safety guarantees for high loads.

My verdict: I find this catch frankly interesting for its price for modest uses.

This is a good surprise, especially because she does the work without complicating my life. I still have an important reserve, as always with the first prize catches without real traceability or solid certification.

Without becoming paranoid, I simply prefer to remain lucid.

As long as you know what you are buying, that you are testing properly, and that you keep common sense, this can find its place in a low-budget home automation installation. but not on the most critical devices or the heaviest loads.

I add a Door Sensor to my Nuki Smart Lock Ultra

📘🔐 Special file: Nuki Smart Lock Ultra

This article is part of my complete file from installation to accessories to home automation.

When I installed the Nuki Smart Lock Ultra on my front door, I have already made a leap forward comfort side: More key to look for, opening from the smartphone, integration into Home Assistant (my home automation platform) … in short, everyday life has become much more fluid.

Then I added the Keypad 2 NFC, Here, the family definitively adopted the lock: Each one has its own code, its own logic, its own habits.

But there was one question that I asked myself a little too often:

“OK, the lock is locked … but is ‑ what the door Is it really closed?”

That is when I decided to add the Nuki Door Sensor.

🧲 Why a Door Sensor on an already connected lock?

Without Door Sensor, the Nuki Ultra knows very well in which position the lock is located: locked, unlocked, in action.

On the other hand, it does not know nothing of the State physics of the door: Closed, open … all this remains invisible without a dedicated sensor.

As a result, you can end up with:

  • a Door poorly closed but locked (yes, it is possible …);
  • automatisms that lock when the door is not stopped;
  • zero alert if the door remains open “a little too long”.

The Door Sensor brings this missing information to the Smart Lock: it allows Nuki to know if the door is closed or open, and to take this into account in the app, notifications and integrations (Home Assistant, other systems).

🚪 Why not a Zigbee or Matter door/window sensor?

That was my first idea: I could have checked that the door was closed with a Zigbee or Matter home automation sensor, connected to Home Assistant (or any other home automation box), as I already do for other doors and windows.

And Yes, it works. But the real difference with the Door Sensor Nuki’s position is that this equipment is part of theNuki Ecosystem :

  • the Door Sensor communicates continuously with the lock;
  • the Lock adapts his behavior depending on the condition of the door (open/closed);
  • everything is configured in the same place, in theNuki App, without going through Home Assistant.

For example, the lock will not move until the door is closed, and conversely, as soon as the door is closed, the lock can lock automatically.

Obviously, all this is configured via the Nuki app, in an integrated and independent way, without the need to open Home Assistant. For a beginner, it is much simpler: a single app, a single universe.

🧩 What does the Nuki Door Sensor look like?

Door Sensor Nuki

The Door Sensor It consists of two components:

  • one Magnetic Sensor (the “big” module), to be fixed on the framework the door;
  • one magnet discreet, to be fixed directly on the door.

Both are mounted on the inner side, like the Smart Lock. The sensor measures the magnetic field issued by the magnet and, based on this measurement, determines whether the door is considered closed or open.

⚠ Important:

  • the Door Sensor is planned for the wooden or plastic doors ;
  • the metal doors and sliding doors are not supported (the metal disrupts the measurement, and the sliding doors are completely out of the intended geometry).

If your front door is made of metal, this sensor is not suitable: it will then be necessary to start on another solution (classic home automation sensor + logic in Home Assistant, for example).

🧪 Nuki sensor vs “classic” aperture sensors (binary ON/OFF)

This is where Nuki makes a choice technological very different from our famous small door/window sensors Zigbee/Z-Wave at 10–20 €.

🔌 How does a conventional magnetic contact (Reed) work?

Conventional door/window sensors are usually based on a Reed Switch :

  • the magnet is close → the metal slats of the Reed touch → the circuit is closed ;
  • the magnet moves away → the slats separate → the circuit is open.

Reed switch

This is binary, ultra simple, very robust … but limited:

  • the sensor only “includes” ON/OFF (near/not close);
  • He can't tell the difference between slightly ajar and wide open door : as soon as the tipping distance is exceeded, it is “open”, point.

It is perfect for many uses (perimeter alarm, simple opening info), but we remain on a logic all or nothing which does not take into account the small mechanical nuances of the door.

💶 What Nuki does more (and why it's more expensive)

The Door Sensor Nuki’s switch is not limited to a simple binary Reed switch: he uses a Magnetic Sensor more sophisticated measuring theMagnetic field strength generated by the magnet.

Nuki does not specify whether it is a Hall effect sensor or a magnetoresistive sensor.

During calibration, the sensor records the signal value in different positions:

  • door closed ;
  • door open (with a gradual shift between the two).

Next, Nuki defines internal thresholds to decide whether, at a moment T, the door should be considered as closed or open. You only see “closed/open” in the application, but behind it the logic takes into account several intermediate values.

The system is therefore finer a simple gross ON/OFF: it takes into account a range of values, which improves the tolerance to micro‑variations (door play, expansion, slight position deviations, etc.).

I had the feeling that this sensor has a form of Learning capacity : the first tests were average and, little by little, it seems to “understand” the state of the door more and more.

Specifically, the technology chosen and the intelligence behind it explain:

  • the higher price from Door Sensor compared to a simple alarm contact;
  • the fact that it is thought of as “integrated” accessory the Nuki ecosystem (in terms of design, app, notifications, Matter, etc.), and not as a generic 2-wire sensor.

For a beginner, this can be summarised as follows: a conventional Reed sensor answers just “yes/no”, Door Sensor Nuki observes a little more finely what happens, and in addition he discusses directly with the lock.

🛠 Installation on my door: simple, but to be treated

Installation wizard

As for the Smart Lock Ultra, Nuki offers a very well done assistant in the app. But there are still some subtleties that deserve to be well respected.

🧽 1. Surface preparation

Nuki recommends:

  • from cleanse the bonding area (alcohol/soft cleaner);
  • check that the surface is flat and dry, so that the sensor mounting plate adheres properly.

A sensor that has a slight play on its base is the door open to false positives … (in every sense of the word).

📍 2. Positioning of sensor and magnet

Official rules:

  • the sensor attaches to the framework ;
  • l’magnet on the door, inner side.

Two large possible configs :

  • Door and frame at same level → mounted magnet in parallel the sensor;
Mounting variant A Mounting variant A - other view
  • Door recessed or protruding → magnet mounted at 90° on the song of the door, but always in front of the sensor.
Mounting variant B Mounting variant B - other view

And above all:

the distance between the sensor and the magnet shall be between 0.5 and 3 cm, door closed.

Door Sensor mounting diagram

Nuki also gives a visual cue with the LED and the small mark on the sensor to align the bottom of the magnet in the right place. For a beginner, really follow the diagram: Do not place “eye”, follow the markers.

🔋 3. Powering on and pairing

The sensor works on a battery ER14250. When it is first put into service (withdrawn tongue), it is put into service. maintenance mode, ready to be added.

From the Nuki app:

  • Menu → Manage devices → Accessories → Nuki Door Sensor ;
  • the assistant is followed, the lock detects the sensor using Bluetooth;
  • once paired, we clips the sensor on its mounting plate.

If you want to reset/modify the installation later, you can use the anti-‑sabotage button on the back to return it to maintenance mode. To put it simply: If you change the place of the sensor, remember to put it back in this mode before starting the procedure again.

🔁 Calibration: the step where you don’t have to rush

Calibration screen

Calibration is the moment when the Door Sensor “learns” what a door is closed and a door open on YOUR specific installation.

The assistant asks you, step by step:

  1. from close the door → sensor records the ‘closed door’ value;
  2. dopen the door according to the instructions → the sensor records the values associated with the open position.

Nuki insists very clearly on one point in his doc:

it is necessary move the door slowly during these steps, so that the sensor correctly detects variations in the magnetic field.

For a beginner: Do not skip this step, take the time to follow exactly what the app is asking for, without forcing or going too fast.

😅 My galleys (and how I got away with it)

I'm not going to lie: I did not behave perfectly at first.

For example, I had:

  • physically closed door, displayed “open” in the app;
  • or a state that took time to update.

Going to see la Nuki Troubleshooting Doc, the main common causes are:

  • sensor/magnet distance a little too limited (I have often been too close);
  • Boiled Door too fast when calibrating (yes, it is written in the doc and everywhere and I was going too fast);
  • light mechanical play in the door;
  • sensor badly plated on its support (yes, I moved the sensor several times and the double-sided one needed to be redone).

On this last point, there is a trap with a small sensor anti-snapping (or “anti-sabotage”).

Anti-snapping sensor

If the double-sided is not nickel, this small sensor blocks everything and a special state appears:

Door Sensor removed

“Removed” is very clear: the sensor no longer touches its base completely, it is necessary to redo the holding of the double-sided to have instead, on this screen, the normal state of the Door Sensor and battery:

Door Sensor OK

If Nuki has provided for this status to be displayed “removed”, is that many users have had the concern. Well thought out, but it surprises the first time.

What I did to stabilise all this:

  • relaunch a recalibration since: Smart Lock → Settings → Manage Door Sensor → Calibrate Door Sensor ;
  • be much more slow in door movements (yes, really slow);
  • adjust the position of the magnet a little to stay well within the 0.5–3 cm range;
  • check that the sensor was properly clipped without play.

Once this combo was respected, the behavior became frankly reliable.

📱 What it changes in the Nuki app

Once the Door Sensor operational, the Nuki app no longer merely displays:

  • 🔒 locked / unlocked (state of the lock),

but also:

  • 🚪 Closed door / Open Door (Door condition).

Door state in the Nuki app

Combinations of the following type can therefore be seen:

  • Door closed + lock locked → perfect;
  • Door closed + lock unlocked → someone is at home;
  • Door open + lock locked → to be monitored;
  • Door open + lock unlocked → door really open.

🔔 Notifications and Alerts

Door Sensor Notifications

The app allows you to configure notifications related to the condition of the door:

  • alerts if the door remains open too long;
  • alerts if the lock tries to lock while the door is not closed.

For a front door, this is exactly the kind of detail that ends up counting on a daily basis. Everyone can choose what they want to do: be notified all the time, only in absence mode, or not at all.

🤓 And on the home automation side, what does it look like?

As I explained in I connect the Nuki Smart Lock Ultra to my home automation :

Nuki Entities in Home Assistant

The status of the door (Open or Closed) can be found in Home Assistant, whether in MQTT or Matter.

Indeed, on the side of home automation integrations (Nuki Hub, MQTT, Home Assistant), we see that the Door Sensor is exposed as separate entity, in addition to the lock:

  • an entity lock.xxx for the Smart Lock;
  • an entity binary_sensor.xxx_door (or equivalent) for the condition of the door.

Some Matter/SmartThings drivers consider that anything that is not “closed” is treated as “open”. In other words, if it is not explicitly closed, it is considered open.

From there, we can imagine scenarios in Home Assistant:

  • prevent an automatism from locking if doorState!= closed ;
  • trigger an alert if the door switches to “open” while the house is in “Absent” mode;
  • turn on the ‘closed → open’ transition input lighting after dark.

For beginners: You don't have to get into this from day one. The Door Sensor already works very well with the Nuki app alone. The Home Assistant part is a second stage to go further.

✅ My opinion after installation

After a few weeks of use, my feeling is clear:

  • The Door Sensor is the brick that was missing for the Nuki Smart Lock Ultra to have a coherent view of the whole lock + door.
  • The technological difference with a simple magnetic contact explains the price : we are no longer in the small generic binary sensor, but in an integrated module, calibrated, designed to work hand in hand with the lock.
  • On the usage side, the ‘door remained open’ notifications and the possibility to exploit the state of the door in Home Assistant bring a real plus in comfort and security.
  • The real plus is that the lock lock locks a few seconds after the door is closed: it’s impressive, totally brilliant … and you get used to it way too quickly!

I turned my SkyConnect Zigbee into a Thread for Matter

In Home Assistant, a Nabucasa coordinator (SkyConnect, ZBT-1, ZBT-2, …) can either Zigbee, or Thread, but not as a universal radio to do everything at once. In this test, a first key remained dedicated to the Zigbee in production, and a second key was reconfigured for Thread to prepare a Matter over Thread network without breaking the existing one.
Here is the full HTML code of the article, already written in the first person and with the descriptive titles:

📌 Context

My goal was simple: check if a second SkyConnect could become a Thread adapter directly from Home Assistant, without plugging the key into a PC and without touching the already operational Zigbee. I chose this cautious approach because my home automation installation was already working properly, and I did not want to shake everything up.

To avoid any risk, I left the Zigbee key intact. The new key served as a test bed for me, which allowed me to clearly document the behaviour of Home Assistant and to keep my own feedback.

💡 Difference Between Thread and Matter

Thread and Matter They don't mean the same thing. Thread is the radio network used by some low-power devices, while Matter is the standard that allows these devices to speak the same language in Home Assistant. SkyConnect therefore does not “do” Matter on its own: it provides the Thread radio layer, and Home Assistant then manages the Matter integration.

🚦 I start from a SkyConnect already in production

Initially, a SkyConnect was already in service for the Zigbee. I had a second, new key that had never been used before. It was this second key that I plugged into my Home Assistant machine for the experiment.

The choice to separate roles allowed me to clearly compare behaviours: on the one hand the production Zigbee, on the other a radio dedicated to Thread. It was also, in my view, the safest way to test a protocol change without a service interruption.

🔎 I let Home Assistant detect the new key

Once plugged in, Home Assistant detected my new SkyConnect in the Integrations page, in the Discoveries section. The card displayed “Home Assistant SkyConnect / Home Assistant Connect ZBT-1” with a button Add.

At the same time, the other SkyConnect remained present in the configured integrations. This confirmed to me that production was not impacted and that Home Assistant already managed the two instances as two separate devices.

🖱 I start adding from the dashboard

The new map appeared in the ‘Discoveries’ area. I clicked on Add to launch the configuration wizard for this second key.

We can see with this simplicity invented by Nabucasa, I did not need to go through a manual flash or an external tool. The configuration started directly from the Home Assistant web interface.

🧭 I choose the protocol of the key

After clicking on Add, Home Assistant asked me to choose the protocol of the key. Two options were proposed: Use as Zigbee Adapter and Use as Thread Adapter.

This choice confirmed an important point for me: The SkyConnect is assigned to a specific role. I had to choose either Zigbee for a classic network or Thread to prepare Matter over Thread.

🧵 Why I choose Thread

I chose Thread to test the Matter over Thread use case. My objective was not to replace the existing Zigbee, but to validate the creation of a dedicated Thread radio in Home Assistant.

It is also, in my view, the right logic if we want to maintain a stable installation: one dongle keeps the Zigbee in production, the other serves as the basis for Thread.

⚙ I let Home Assistant install OpenThread

Once Thread was selected, Home Assistant launched the adapter update.

At this point, my key was being transformed into a Thread adapter. The procedure advanced in Home Assistant without outside intervention.

 

📈 I monitor the progress of the flash

The progress bar showed the progress of the installation, in particular at 5 %. This confirmed to me that the key was indeed being flashed with the OpenThread firmware.

 

🛠 I complete the configuration of Thread

After the flash, Home Assistant went to the “Configuration of Thread” step.

I then saw messages like “Installing app” and then “Starting app”, signs that the Thread stack was being deployed.

This is when Home Assistant orchestrates the OpenThread Border Router service. In practice, my key becomes the system’s Thread radio, and Home Assistant takes care of the associated network layer.

The Thread network is not just a cosmetic setting. This is a real network setup, with a radio adapter that becomes able to play the role of border router for Matter-enabled Thread devices.

At the end of the procedure, I add the MATTER information so as not to confuse the keys.

My new key appeared with the firmware OpenThread RCP 2.7.2.0. This confirmed that the Thread reconfiguration was successful.

Home Assistant then displayed two separate devices in the Devices tab: a classic ‘Home Assistant SkyConnect’ and a ‘Home Assistant SkyConnect MATTER’. The integration map also indicated “2 devices”.

🧠 I read what it teaches me

This separation is convenient because it visually shows both roles. One key remains associated with historical use, the other becomes the radio dedicated to Thread/Matter.

For feedback, this is a strong point: The reader immediately understands that the migration created a second logical instance in Home Assistant, without breaking the first use.

🔬 What this test proves to me

This experience has shown me that it is possible to convert a second SkyConnect to a Thread adapter directly from Home Assistant. The procedure is integrated, guided, and does not require complex manipulations outside the interface.

She also showed me that Home Assistant knows how to manage the separation between Zigbee and Thread in a clear way. This is particularly reassuring when a Zigbee plant is already in production.

⚠ I keep a limit in mind

However, it should be borne in mind that a SkyConnect does not become a stand-alone hub Matter. Matter remains managed by the Matter integration of Home Assistant; The key here provides Thread connectivity, not all Matter logic alone.

In other words, SkyConnect fulfils for Thread the role that a coordinator fulfils for Zigbee: It opens and connects the network to Home Assistant. The difference is that Zigbee talks about a coordinator, while Thread relies on a border router, and Home Assistant then manages Matter above.

📝 Review and conclusion

Perhaps the most interesting thing about this test is the simplicity of the flow. I kept a key in Zigbee for stability, added the second one as a discovery, then reconfigured it into Thread with just a few clicks.

For someone who wants to test Matter over Thread without touching their existing installation, it is a clean and reassuring method. It avoids disassembly, manual flash and the risk of shutdown on the main Zigbee network.

In the end, the transformation worked as expected. Home Assistant detected my new SkyConnect, offered me the choice of Zigbee or Thread, installed OpenThread, and then showed me a key switched to MATTER/Thread mode with OpenThread RCP firmware.

Above all, this feedback shows me that it is possible to organise your radio roles properly in Home Assistant: one key for Zigbee production, another for experimenting with Thread and preparing Matter over Thread.

I am testing the NEW smoke detector Zigbee Heimann HS1SA-E-PLUS

🎯 My objectives

I have had smoke detectors for a very long time.  Heimann HS1SA-E to protect my home, this economic module gives me full satisfaction for basic use.

When writing my comparison of Zigbee smoke detectors, I asked Heimann whether they were considering an evolution of that product.

And surprisingly, an update of the HS1SA-E was being developed, they sent me three copies of the new product which should be the HS1SA-E-PLUS with a lot of evolutions in the Zigbee exhibitions, as I will explain later.

Three products because one of the great novelties is the interconnection of detectors, so I will test this.

 

🔍 HS1SA-E or HS1SA-E-PLUS?

The HS1SA-E is on the left and the HS1SA-E-PLUS is on the right, unless the opposite is the case. I am kidding of course, they are completely identical from the outside.

To find out who is who, you have to compare the labels inside.

I received a pre-release, both are mentioned HS1SA-E, I think the reference of the new one would be changed in the marketed versions.

In the image, the new one is on the left, with the QR Code, it is mentioned Manufacture Date: 12/2025.

Here is the complete label, once unfolded:

I take the opportunity to raise the certifications present

  • UKCA : Replaces the CE marking in the United Kingdom ‑.

Indicates that the detector complies with UK regulations on product safety, EMC, radio, etc.

Mandatory for placing on the market in Great ‑ Britain (England, Scotland, Wales).

  • Marking house (Building)

Product symbol for residential use (dwellings).

It is often seen on smoke detectors that comply with home safety standards in Europe.

Above all, points to the area of use, rather than an autonomous legal certification.

  • Zigbee : Zigbee logo with "certified product" label.

Attests that the device has passed the Zigbee Alliance compliance tests for Zigbee 3.0 (interoperability, radio protocol, security).

Globally relevant for the home automation ecosystem, not country-specific.

  • EC : Regulatory marking for the EU and EEA countries (Norway, Iceland, Liechtenstein) and often accepted in Switzerland.

Indicates compliance with European directives (safety, EMC, RED radio, etc.), allowing placing on the market in all these countries.

Notified body number ‘2531’

Identifies the body that has assessed conformity (here a European Notified Laboratory for the Radio Equipment/Construction Products Directive).

This number complements the EC and is recognised in the EU/EEA.

  • EN14604:2005/AC:2008 European standard specifying requirements for smoke detectors for household use.

Mandatory or highly recommended in most EU countries for residential smoke detectors (France, Germany, Belgium, etc.).

Recognised also by some non-EU countries that adopt EN standards.

  • DBI Certification (logo eye/flamm e + "DBI CERTIFICATION")

Danish organization ("Dansk Brand- og sikringsteknisk Institut") accredited to certify fire safety products.

Certification especially relevant for Denmark and the Nordic countries where insurance/authorities can value it.

Strengthens the credibility of the product on European markets, without being mandatory everywhere.

  • Barred bin

WEEE (Waste Electrical and Electronic Equipment) symbol.

Indicates that the detector should not be disposed of with household waste but in a specific recycling channel.

Used in the EU, the UK ‑ and more widely in Europe.

🔍 I check the received model

  • On the technical sheet : HS1SA-E (to become HS1SA-E-PLUS) Zigbee 3.0 optical smoke detector ,
  • On the carton : Heimann HS1SA-E (which will become HS1SA-E-PLUS) clearly indicated
  • Type of equipment : Smoke detector
  • Protocol : Zigbee
  • Power supply : CR123A battery (3V), estimated duration 10 years
  • Intended installation : Ceiling, living rooms

📦 Unpacking and First Impressions

📦 Product Description

The detector is compact, comes with a bracket to glue or screw to the ceiling. A metal plate system, a set of screws and a reset tool.

The new model offers an awesome magnetic plate system with two magnets and 3M double-sided

 

🛒 Where to buy this equipment?

Here is the link to the page dedicated to HS1SA-E-PLUS. I referenced the sellers and prices.

🏡 Where I install it

For reliable measurements, I choose the ceiling in the center of the room. I avoid corners, kitchens or garages for false positives because of kitchen smoke or dust.

🔋 I spot the yellow tab that has to isolate the battery

Yellow tongue insulating the battery I remove the base (just unscrew a few degrees), then I pull the tab to power the detector.

🔗 I integrate this detector with Zigbee2MQTT

I put Zigbee2MQTT in pairing mode when I remove the tab, but nothing happens (this is not automatic on this model).

So I find the small hole on the side, I slide a trombone into it to press for a few seconds until the LED flashes green.

The pairing starts immediately and, in a few seconds, the module is integrated!

Below are the 3 new products detected in HS1SA-E-PLUS and at the top, the previous product recognized in HS1SA-E.

🖊 I am renaming the device

in Heimann Test 01 to continue the tests.

 

Exhibition details of Zigbee2MQTT

Exhibition details of Zigbee2MQTT

🔋 Battery

The exhibition Battery corresponds to percentage of battery remaining reassembled by the detector. In practice, it is the simplest indicator for monitoring day-to-day autonomy, e.g. 100% Just after installation.

I display it on my Home Assistant dashboard to quickly spot an abnormal drop. When the level passes low (typically under 20%), I plan to replace the CR123A battery before having any unwanted beeps or loss of supervision. One can choose to do a digital test on this exhibition or use the exhibition Battery low which is binary, each its preference, the device gives the choice.

🔎 Identify

The exhibition Identify is used to identify physically the detector. When I trigger this action, the detector starts a flashing LED so I know which one is which.

This is very useful if I install several identical detectors in the house. I can rename them cleanly in Zigbee2MQTT without making a mistake.

🌡 Temperature

The exhibition Temperature goes up a measured temperature by the detector (in °C). This is not the main function of a smoke detector, but it is a practical fact, e.g. 20.9°C.

I can display it on the dashboard, or use it in a simple automation (ventilation, window, heating). I keep in mind that this is not a dedicated precision probe, but rather a bonus for contextualising the environment.

🔥 Smoke

The exhibition Smoke indicates whether the detector has detected smoke as a binary state (True/False). As long as there is nothing to report, I see “False” on the dashboard.

This is the most important exposure for safety, as I use it to trigger notifications and emergency scenarios. For example: immediate push notification, ignition of lights, opening of flaps, and possibly triggering of additional sirens.

🪫 Battery low

The exhibition Battery low is a binary indicator that signals whether the battery is almost empty. Even if the “Battery” value can still show a percentage, this status is an excellent alert trigger as it represents a “critical” threshold on the device side.

I use it to send a priority notification and to avoid delaying battery replacement. The objective is clear: Do not wait until the detector switches to regular beep mode or becomes unstable on the network.

🧪 Test

The exhibition Testing indicates whether the detector is performing a test. It is a binary state (True/False) that becomes “True” during the test phase and then returns to “False” afterwards.

I use it to check that my automations respond correctly to a test without triggering a general panic. This mode is designed to be used in dashboard, notification and automation.

🛠 Fault state

The exhibition Fault state corresponds todefault state of the detector. It indicates whether the device is in a normal state, or whether it is recovering from a type of problem (depending on the possible ‘fault types’).

I display it on my security dashboard because a defect can be as important as an alarm. If this status changes, I plan an on-site check (battery, fouling, positioning) and I monitor Zigbee stability.

🔇 Muted

The exhibition Muted indicates whether the detector is currently in silent mode or in normal condition. The important clarification is that this status is mostly relevant when the detector has been silenced during an alarm state, and not as a mere permanent “silent mode”.

I use it to visually confirm that a mute has been applied after a false positive. It is also very convenient to avoid “believing” that the alarm is switched off when it is not.

✅ Trigger Selftest

The exhibition Trigger selftest triggers a remote self-test of the detector. The idea is simple: I can check periodically that the device is responding, without physically pressing the button.

The self-test lasts long enough (approximately 21 seconds) for the automation to have time to act. In my case, when I run a self-test, I watch that Testing switches to “True”, that Smoke does not switch to “True”, and I listen to the test beeps (2 times 3 beeps) to validate the correct operation.

🤫 Temporary Mute

The exhibition Temporary mute allows for ask the detector to switch to remote mute mode. It is a very useful command when the alarm sounds for a non-dangerous cause, but it must be used with common sense: I always check that there is no real fire start before turning off the sound.

Behavior depends on the context.

  • In low battery status, if I click on Temporary mute, the button can automatically return to its original state: this is normal, as the low-battery warning sound can only be switched off for 12 hours, then the device resumes its warning.
  • In alarm status (smoke), I can activate or deactivate the mute, which is ideal to manage a false positive (steam, dust) while keeping my hand from the dashboard and without pressing the button on the device.

💡 Heartbeat indicator

The exhibition Heartbeat indicator is used to activate or deactivate the indicator light (heartbeat). The aim is to manage the flashing of the LED, which is often useful to confirm that the device is alive, but sometimes annoying in a room.

The documentation recommends not disabling it “blindly”: if I switch off the LED, I compensate with a periodic check (programmed self-test) and an unavailable device detection (offline) in Home Assistant.

🔗 Interconnectable

The exhibition Interconnectable is planned for theinterconnection between detectors (logical “if one detects, the others react”). The explanation provided indicates that this exposure is thought of as an automation trigger, simpler and more flexible than relying solely on “Smoke” or “Test” to control external sirens.

I would use it to create a global alert: if a single detector triggers, I ring other devices (sirens, speakers, other detectors) so that the alert is audible everywhere.

At this stage, I need to test with at least two detectors to test this.

📈 Smoke level

The exhibition Smoke level goes up a measured smoke level as a numeric value (e.g. 0.00 under normal conditions). This is finer information than a simple “Smoke = True/False”.

I can use it for prevention: display the trend on a dashboard, or trigger a ‘pre-alert’ notification if the level rises gradually before the alarm is triggered.

I also have a air quality monitor In the room, I will be able to see if the smoke detector reacts when the air quality monitor informs me that the indoor air quality has become poor.

📏 Smoke unit

The exhibition Smoke unit specifies theunit associated with the measure ‘Smoke level’. In the documentation, this unit is designed to facilitate scripts and automations, especially because the product is intended for international use.

Concretely, it prevents me from making assumptions in my automations. I can also adjust my thresholds if I change my model later, keeping a consistent logic.

🧼 Chamber contamination

The exhibition Chamber contamination indicates the level offouling of the smoke detection chamber.

The possible values are:

  • normal : Clean room, optimal detection.
  • light_contamination : Light contamination, watch.
  • medium_contamination : Medium contamination, clean soon.
  • critical_contamination : Critical contamination, clean or replace immediately.

I can use it to schedule an automatic notification as soon as light_contamination, and a strong alert to critical_contamination. This prevents the dust from rendering the detector inoperative without my noticing it.

📢 Siren for automation only

The exhibition Siren for automation only allows for control the siren via a home automation action.

This feature is just great for home automation enthusiasts. Three buttons can be activated: stop, smokesiren or Cosiren, so we have a choice between two ringtones. Too bad, it is a bit limited, but it is already huge to build scenarios.

I intend to use it only in a controlled setting: tests, scenarios, or interconnection. This allows me, for example, to trigger the siren of a detector from an automation, without waiting for it to detect smoke itself.

📦 Reported packages

The exhibition Reported packages is a meter that indicates how many Zigbee packets the device published over a 24-hour period. This is a very useful diagnostic data if I find that the battery is emptying too quickly.

In this context, “reported” means sent / transmitted : this is the total number of Zigbee packets that the detector sent to the network over a day. These packets correspond to ‘reporting’ messages (automatic states such as battery, temperature, smoke level, link quality, etc.). Each time the detector goes up a state, a change, or a periodic heartbeat, it counts +1 packet.

If this meter becomes abnormally high, I must look for the cause (unstable network, too chatty parameters, radio interference).

🔁 Rejoin count

The exhibition Rejoin count indicates how many times The detector joined the Zigbee network again.

In diagnosis, it is a clear indicator of stability: the more it goes up, the more likely my network is to be limited to where the detector is. If I see frequent joins, I add a Zigbee router (plug, router bulb) nearby or I bring the coordinator closer.

I am gaining both alert reliability and battery life.

🔄 Reboot count

The exhibition Reboot count counts the number of restarts of the apparatus. It is still a purely diagnostic fact, but it can help detect unstable behaviour.

If this meter increases, I suspect a weak battery, a firmware problem, or an unstable internal power supply. In any case, I prefer to investigate quickly, because a smoke detector must remain reliable continuously.

📶 Linkquality

The exhibition Linkquality represents the quality of the Zigbee link (LQI). It is not a direct “safety” indicator, but it is an excellent thermometer to know if the detector communicates easily with the network.

If the LQI is too low or fluctuates a lot, I review the placement or add a Zigbee router. I keep in mind that good Zigbee communications increase the chances of alerts and statuses rising quickly, especially in real-life situations.

Details of Zigbee2MQTT parameters

🧩 Temperature calibration

The exhibition Temperature calibration allows foradjust the absolute temperature reported by the detector. By entering an offset value (e.g. +1.5°C or -0.5°C), I compensate for measured deviations from a reliable reference probe.

I use it to refine the measurements in a specific room, especially if I compare it with other in-house sensors. This calibration is set to within 0.1°C. This is very useful to compensate for the positioning of the sensors, often on the ceiling, and therefore with a few degrees more than the temperature at human height.

Attention: this calibration directly impacts all temperature deferrals, so I test after setting and note the value for reproducibility.

🎯 Temperature precision

This parameter defines the number of decimal places displayed for temperature (e.g. 0 for integer, 1 for 21.0°C, 2 for 21.05°C). It controls the accuracy of the deferral without changing the actual measurement.

I choose 1 or 2 decimal places for a display readable on dashboard without unnecessary overload. More decimals = slightly longer reports (minor impact conso), but increased visual accuracy for fine trends.

⏱ Identify timeout

This setting fixes the duration in seconds during which the detector flashes its LED during an Identify command (range 1 to 30 seconds, default value 3 seconds).

I adapt it to my needs: short (5s) for fast location, long (20s) if I struggle to spot among several detectors. This avoids relaunching the Identifier several times during installation or maintenance.

 

🏠 I find the detector in Home Assistant

I can find my equipment there right away.

Controls are present.

I find all available sensors

In Configuration, I find the OTA update option (great!) and the identification command that flashes the detector.

Finally in Diagnosis, I have all the elements. Please note that at home I have automatically activated Linkquality and Last Seen, if it may be of interest, I have produced a Retex which explains this:

I notice that two elements have the same name Battery, I do not know if it is a concern for integration or some other reason, I will have to be careful to rename them so as not to get confused.

 

📑 For archive: instructions for use

 

🔗 I pair in Zigbee2MQTT

  • I pass Z2M in peering mode
  • I remove the tongue from the battery 5s, the led flashes green a few times but nothing happens.
  • and put it back for quick pairing
  • Detected as "HS1SA-E" or "smoke _zigbee"
  • Entities: battery, smoke, tamper, linkquality, test
 friendly_name: _fumee _chambre device_class: smoke smoke: binary_sensor.smoke battery_low: binary_sensor.battery_low test: button.test

🏠 Integration in Home Assistant

I can find the device in HA: entities smoke (smoke state), battery, test. Alarm badge with siren and push notification. Everything works perfectly.

📊 My first measurements

Date Smoked state Battery % Testing Notes
02/03/2026 Clear 100% okay Installation
03/03/2026 Clear 100% okay Stable

⚙ Automations I am considering

  • Alert : If smoke detected, siren home + SMS + opening shutters
  • Comfort : Automatic monthly test + low battery alert

📅 Installation and monitoring of batteries

  • Installed on 02/03/2026 (Parental room)

💬 My opinion after commissioning

✅ Forts: Quick detection, perfect Z2M/HA integration, long battery life, affordable price.

❌ Weak: No CO, moderate siren, no outside.

My verdict: Excellent for home automation Zigbee! Recommended for all beginners fire safety.

 

I'm testing the smoke detector Zigbee US E8

🎯 My objectives

I need to monitor my house for fire risks as soon as the first smokes appear.

The Zigbee Smoke Detector We E8 is ideal for this mission, it is part of the 3 Zigbee equipments of the consumer range. In order to decide between them, I made a comparison:

The data of the E8 enable accurate alerts in Zigbee2MQTT and Home Assistant, such as sirens, push notifications and automatic ventilation.

The security of my home is thus strengthened in a simple and effective way.

This device complies with European standards EN14604 for autonomous smoke detectors (DAAF), as well as CE and RoHS certifications, ensuring its compliance with European safety standards.

The Photoelectric Smoke Detector We E8 home ZigBee detects a fire by detecting smoke in the air and triggers an audible and luminous alarm as soon as a certain concentration threshold is reached. It is designed for residential buildings and its single-source detection chamber is protected against false positives caused by dust, insects or moisture.

The internal ‘maze’ design allows for rapid fire detection, while limiting undesirable triggers. The case is made of fireproof plastic with a glossy finish. Read More

I'm testing the Sonoff MINI DUO Zigbee MINI-ZB2GS

Compact 16A double relay for my lights

The Sonoff MINI DUO Zigbee (reference MINI-ZB2GS) is a Zigbee 3.0 dual relay micro-module with neutral, designed to fit behind a standard wall switch and drive two circuits up to a total of 16A.

MINI DUO Zigbee: why I'm testing it

I was looking for a Zigbee Dual Relay Micro Module capable of controlling two lighting circuits while remaining very compact, to be installed behind an existing switch. The Sonoff MINI DUO Zigbee (MINI-ZB2GS) promises 10A per channel, 16A in total, true Zigbee repeater mode and simple integration into modern Zigbee ecosystems.

Perfect for managing the kitchen and living room, the two switches are next to each other, with the neutral and a common phase.

Read More