4 of 5 Tradfri Control Outlets working, 1 remains "Unknown ZigBee Device"

Some Template requested info:

* Platform information:
  * Hardware: x86_64 / 4GB RAM / 6 GB Storage
  * OS: uname -1 -> 'Linux agent 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux'
  * Java Runtime Environment: zulu-8
  * openHAB version: 2.5.0.M4 (Build) (apt installed)

I bought 5 Tradfri control outlets, UK plug type, this month. When they arrived I had just set up OpenHab and I had not yet added any other devices successfully except for the HUSBZB-1 Zigbee controller (I only have Xiaomi sensors anyway, and I will not bother trying after reading other topics here, I’ll be getting a separate controller and using zigbee2mqtt for those…).

I used discovery in the HabAdmin UI and pressed the recessed button for 10s to activate pairing mode on the control outlets.

Four of them paired successfully after appearing first as Unknown Zigbee Device, then resolving to the “TRADFRI control outlet” profile. But, one of them did not successfully resolve to this profile.

I tried adding it anyway while it was unknown, but this did not help. So I deleted and tried again to pair, including attempting pair-then-turn-off-and-on, and a few other variations. This one plug will not resolve, it remains as “Unknown ZigBee Device”.

I’d be happy to do this manually by editing something in the jsondb entries, if I knew what I was doing, yet. :slight_smile: But, I was hoping there was some trick I did not yet know about, here…

Very grateful for any help offered. I was hoping to use these outlets first as repeaters to set up a Zigbee mesh worth adding sensors to, and also to start controlling small heaters to help reduce our oil consumption in our house. This plug was the last one for the coldest room, the others are needed as relays!

Contents of /var/lib/openhab2/jsondb/org.eclipse.smarthome.config.discovery.DiscoveryResult.json are below.

I think item “zigbee:device:16e549983db:086bd7fffe05378c” may be the plug as its mac address resembles 2 of the other plugs, though I do not know what the other two discovery results could be. I have 5 or so Xiaomi Aqara Temperature & Humidity Sensors which were previously set up on the same USB controller on HomeAssistant, 2 or 3 of which may be in range, more now that I’ve added the Tradfri Repeaters… but I have not been able to configure any successfully yet in OpenHab: possibly some of the discovery results represent these devices.

{
  "zigbee:device:16e549983db:00158d00040fbc25": {
    "class": "org.eclipse.smarthome.config.discovery.internal.DiscoveryResultImpl",
    "value": {
      "bridgeUID": {
        "segments": [
          "zigbee",
          "coordinator_ember",
          "16e549983db"
        ]
      },
      "thingUID": {
        "segments": [
          "zigbee",
          "device",
          "16e549983db",
          "00158d00040fbc25"
        ]
      },
      "thingTypeUID": {
        "segments": [
          "zigbee",
          "device"
        ]
      },
      "properties": {
        "zigbee_macaddress": "00158D00040FBC25"
      },
      "flag": "NEW",
      "label": "Unknown ZigBee Device 00158D00040FBC25",
      "timestamp": 1573478629421,
      "timeToLive": -1
    }
  },
  "zigbee:device:16e549983db:00158d00034d437d": {
    "class": "org.eclipse.smarthome.config.discovery.internal.DiscoveryResultImpl",
    "value": {
      "bridgeUID": {
        "segments": [
          "zigbee",
          "coordinator_ember",
          "16e549983db"
        ]
      },
      "thingUID": {
        "segments": [
          "zigbee",
          "device",
          "16e549983db",
          "00158d00034d437d"
        ]
      },
      "thingTypeUID": {
        "segments": [
          "zigbee",
          "device"
        ]
      },
      "properties": {
        "zigbee_macaddress": "00158D00034D437D"
      },
      "flag": "NEW",
      "label": "Unknown ZigBee Device 00158D00034D437D",
      "timestamp": 1573478629416,
      "timeToLive": -1
    }
  },
  "zigbee:device:16e549983db:086bd7fffe05378c": {
    "class": "org.eclipse.smarthome.config.discovery.internal.DiscoveryResultImpl",
    "value": {
      "bridgeUID": {
        "segments": [
          "zigbee",
          "coordinator_ember",
          "16e549983db"
        ]
      },
      "thingUID": {
        "segments": [
          "zigbee",
          "device",
          "16e549983db",
          "086bd7fffe05378c"
        ]
      },
      "thingTypeUID": {
        "segments": [
          "zigbee",
          "device"
        ]
      },
      "properties": {
        "zigbee_macaddress": "086BD7FFFE05378C"
      },
      "flag": "NEW",
      "label": "Unknown ZigBee Device 086BD7FFFE05378C",
      "timestamp": 1573478629412,
      "timeToLive": -1
    }
  }
}

You may try doing a factory reset. Google for a video on it. I had one that needed a factory reset prior to pairing while the second worked on first try.

Long overdue update: thanks for the advice Danny, but no method of reset that I could find documentation for would resolve this issue.

However, I ditched the OpenHAB zigbee system entirely and went with zigbee2mqtt instead, and all my devices have been working perfectly since then. Integrating them into OpenHAB is now a pain, because it seems HomeAssistant is the preferred partner to Z2M, but I’ll persevere.

I feel like the Zigbee story for OpenHAB and HomeAssistant is a bit of an undocumented fail - Zigbee2MQTT is ultimately what seems to get pointed at in the end.

1 Like

Yes I agree on the docs. I am struggling with deconz. Funny thing I already set it up. I just lost the notes I wrote and struggling to find the magic bullet again.

This is not the openHAB side of deconz, but the configuration of the deconz package. Once this is done it’s plug and play to openHAB.

Sorry - I missed the original post…

Did you get a debug log from the binding to see what was going on (As per the binding documentation)? If the device paired ok (as it seems), then the issue is that the binding is not getting responses to the requests it makes to discover the services the device supports. Without the logs though, it’s pretty hard to see what is happening and to suggest what can be done to help.