Nous E8 Zigbee Smoke Sensor: Pairing fails despite correct LED sequence

Hello,

I’m experiencing difficulties pairing a Nous E8 Zigbee Smart Smoke Sensor with my deCONZ gateway. Although the device seems to enter its intended pairing mode, the sensor is never discovered by Phoscon.

The observed behavior is as follows:

  1. I start the sensor search in the Phoscon App.
  2. I press and hold the button on the Nous E8 for approximately 5–7 seconds.
  3. The red LED starts blinking.
  4. After about 5–15 seconds, the red LED light extinguishes, and nothing happens. The sensor isn’t found in Phoscon.
  5. Observation (for reference): If I press the button without an active sensor search in Phoscon, the red LED blinks for approximately 30–40 seconds before stopping.

The sensor simply fails to connect and is not recognized. Since the device does not appear in the deCONZ GUI, I cannot read the Model ID or Manufacturer Name, which prevents me from creating a formal Device Request (DDF) on GitHub.

My setup details:

  • Device: Nous E8 Zigbee Smart Smoke Sensor (Tuya)
  • Coordinator: ConBee II
  • ConBee II Firmware: 26780700
  • deCONZ/Gateway Version: 2.31.2
  • Operating System: Raspberry Pi Zero 2 W (main setup) and Windows 11 25H2 (test only)

Has anyone successfully paired this Nous E8 model and can confirm the required button sequence, or perhaps suggest which pairing category in Phoscon (e.g., Lights, Sensors, Switches) is the best one to try? I suspect the device is not joining the network correctly at all.

Thank you for your support.
Kind regards, Mike

Yep.
Phoscon display it only if it was in the API, but the device NEED to be visible in the GUI if included.
And the category have no impact on the GUI.

Hello Smanar,

Thanks for confirming my suspicion: if it’s not in the GUI, it’s not joining the network.

Since the device fails to join and I can’t get the Model ID/Manufacturer Name, what would you suggest as the next steps?

  1. Is there any debug or log information I can check to get the necessary device ID without it joining the network fully?
  2. If not, is this Nous/Tuya model simply incompatible right now, or are there known workarounds to force the initial network joining with such devices?

Any advice on how to proceed would be highly appreciated.

Kind regards, Mike

IDK, I m reading the manual, and it say exactly that.

You can take a look on logs with deconz on help/debug view with flag “info”/“info_l2”/“error”/“error_l2” and “aps”/"aps_L2’ if you see nothing.

You are trying with the sensor close the gateway ? (Yeah I know the inclusion need to be done at final place, but it’s to test)

After resetting Deconz and only trying to add the E8, two more nodes (0x7ABF, 0xDA13) appeared in the node list. Is it possible that two nodes were incorrectly detected?

I must have overlooked them in my production environment, which was my main problem creating a device request.

Validation test performed:
On node 0xDA13, I read the attributes via “Attributes > read.” Then the node LED in the Deconz GUI flashes blue. If I remove the battery from the smoke detector and execute “Read” again, the LED in node 0xDA13 flashes red. I interpret this as the “unreachable” status. If I reinsert the battery, the LED flashes blue again for “read.” Therefore, I assume it’s the smoke detector.

So I’ll try creating a new device request using the information from the screenshot.

@Smanar: Thank you for your support.

Yes, when you rest the device it trigger a new inclusion, so you will have a new Network ID (the 0xXXXX number), the previous one will be grayed after a time (not connected).

But on your capture you have 2 differents Mac adress, so it’s realy 2 differents devices.