Stuck on OFFLINE with Sonoff Zigbee dongle

Stepiiis · October 12, 2024, 6:09pm

Platform information:
- Hardware: Raspberry Pi 5/4GB RAM/32GB flash SD card
- OS: Raspberry Pi OS
- Java Runtime Environment: from the official docker image

root@raspberrypi:/openhab# java --version
openjdk 17.0.11 2024-04-16
OpenJDK Runtime Environment (build 17.0.11+9-Debian-1deb11u1)
OpenJDK Server VM (build 17.0.11+9-Debian-1deb11u1, mixed mode, sharing)

openHAB version: 4.1.3
Issue of the topic: The “Sonoff Zigbee 3.0 USB Dongle Plus E” seems to be working and OpenHAB is communicating with it according to the logs, but there seems to be a communication error during the initialization phase which I cant understand. The logs periodically show a sequence of calls which i have saved into this pastebin. What particularly struck me is the periodic showing of [DEBUG] [gbee.handler.ZigBeeCoordinatorHandler] - Mesh Update Period 86400.
Please post configurations (if applicable):

Bridge zigbee:coordinator_ember:stick "Sonoff Zigbee 3.0 USB Dongle Plus E" [zigbee_port="/dev/ttyACM0", 
zigbee_baud=115200,
zigbee_flowcontrol=1,
zigbee_childtimeout=864000,
zigbee_concentrator=1,
zigbee_meshupdateperiod=86400,
zigbee_panid=2584,
zigbee_extendedpanid="D8BECD0939990A18",
zigbee_networkkey="15 CF 39 A3 92 E2 58 7A 0F BB B8 4D 95 50 24 CA"
]

Relevant part of docker compose:

version: '3.7'

services:
  openhab:
    image: "openhab/openhab:4.1.3"
    restart: always
    container_name: openhab
    network_mode: host
    volumes:
      - "/etc/localtime:/etc/localtime:ro"
      - "/etc/timezone:/etc/timezone:ro"
      - "./openhab/openhab_addons:/openhab/addons"
      - "./openhab/openhab_conf:/openhab/conf"
      - "./openhab/openhab_conf/.ssh:/openhab_conf/.ssh"
      - "./openhab/openhab_userdata:/openhab/userdata"
    environment:
      CRYPTO_POLICY: "unlimited"
      EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Berlin -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0"
      OPENHAB_HTTP_PORT: "8080"
      OPENHAB_HTTPS_PORT: "8443"
    devices:
      - /dev/ttyACM0:/dev/ttyACM0

volumes:
  openhab_addons:
    driver: local
  openhab_conf:
    driver: local
  openhab_userdata:
    driver: local

justaoldman · October 12, 2024, 6:26pm

Hi,
Welcome to the community!
Search the forum and you will find where is/was a known issue with dongles and Rpi4 related to power consumption. Some of the earlier revisions of the Rpi4 had a design flaw related to usb power.
Also, another one related to RF interference.
For the first issue the most recommended solution was to move the dongle to a powered usb hub.
The second on the most recommended solution was to use a usb extension cable to move the dongle farther away from your Rpi4
Also, another issue related to plugging the dongle in to a usb3.0 port instead of a usb2.0 port.
and
Obviously, the last issue most common recommendation was move dongle to a usb2.0 port.
You may want to review those known issues and insure you are not having any of those type problems.

Stepiiis · October 13, 2024, 7:49am

Hello and thank you!

I have searched the forum and only found the issue related to RF interference and could not find similiar message in the log, which would indicate such issue.
The dongle is connected to the USB3.0 port, I forgot to mention that in the OP.

Powercycling of the dongle due to low power from the USB port would explain the repeated logs.
I will try and get my hand at a USB powered hub to test out if that is the issue.

Cheers

Stepiiis · October 13, 2024, 9:40am

I have tested the powered usb hub and putting it further away from the RPi and the logs look the same.

Stepiiis · October 13, 2024, 9:45am

And my mistake, I have previously said its RPi 4, but It’s actually RPi 5. I have edited the OP to reflect this mistake.

justaoldman · October 13, 2024, 4:13pm

Hi,
Have you confirmed the firmware version of your dongle is the correct one tested for openhab
from here?

github.com/itead/Sonoff_Zigbee_Dongle_Firmware

Dongle-E/NCP/README.md

master


[TOC]


# Dongle-E Zigbee NCP Firmware

Silicon Labs EmberZNet NCP Zigbee Coordinator firmware with Silicon Labs standard EZSP (EmberZNet Serial Protocol) interface.

This Zigbee NCP firmware has only been tested on the EFR32MG21 based "Zigbee 3.0 USB Dongle Plus V2 model "ZBDongle-E" hardware from ITead.

* https://itead.cc/product/zigbee-3-0-usb-dongle/

## Recommended firmware
At the time of writting (2022-06-30) EmberZNet Zigbee version 6.10.3.0 firmware is recommended for the ZHA integration in Home Assistant (which depends on the open source zigpy and bellows libraries):

* ncp-uart-sw_EZNet6.10.3_V1.0.1.gbl

The same firmware version has also been confirmed to work with OpenHAB Zigbee Binding, Zigbee2MQTT, IoBroker, Zigbee Plugin for Domoticz, and Zigbee Plugin for Jeedom.

## EmberZNet Zigbee NCP Configuration Parameter values table

This file has been truncated. show original

Also, the other thing you may want to double check is the instructions linked below that are required for docker based install and use of USB for OpenHab.

Stepiiis · October 13, 2024, 8:17pm

I did not update the firmware. I did notice the link to this repo in the OpenHAB docs for the Zigbee binding. I missed the part related to this being mandatory. I will try and update to the recommended version.

ad Docker and USBs: I have had trouble running the command which is required when using USB devices with docker from my docker-compose because OpenHAB refused to start up correctly if I combined it with the default entrypoint command and started throwing exceptions upon startup so I have to run it manualy if I rebuild the container. This sucks for now, but will deal with it later once I find what causes the connection issues.

If anyone knows what could cause the problem, this is what I added to the dockerfile

    command: >
        gosu openhab tini -s ./start.sh 
        && /bin/chmod o+rw /dev/ttyACM0

It’s what I identified as the entrypoint of the container based on running docker ps --no-trunc. I did not include the /entrypoint part before gosu openhab tini -s ./start.sh, because if I included it, it showed another /entrypoint in the docker ps output in the COMMAND section. Like this:

"/entrypoint /entrypoint gosu openhab tini -s ./start.sh && /bin/chmod o+rw /dev/ttyACM0"

Which suprisingly also didn’t work and cause similar unknown exceptions in the log.

Stepiiis · October 13, 2024, 8:37pm

I have tried to identify which version of firmware is running on the dongle and the python script linked in the docs cant identify it and yields this:

$ ./ncp.py scan
Exception: <class 'TypeError'> /dev/ttyACM0 
Exception: <class 'IndexError'> /dev/ttyAMA10 
{"ports": [{"port": "/dev/ttyACM0", "vid": "1A86", "pid": "55D4", "deviceType": "unknown"}, {"port": "/dev/ttyAMA10", "deviceType": "unknown"}]}

The dongle is connected to /dev/ttyACM0. I have run the script directly on the RPi, not inside any container.

Stepiiis · October 14, 2024, 7:48am

There is an open PR in the firmware manager repo which adds support for this version of the dongle. I have pulled the changes and this is the output:

$ ./ncp.py scan
Connecting to.. /dev/ttyACM0 115200 True False 
Exception: <class 'IndexError'> /dev/ttyAMA10 
{"ports": [{"port": "/dev/ttyACM0", "vid": "1A86", "pid": "55D4", "deviceType": "zigbee", "stackVersion": "6.10.3-297"}, {"port": "/dev/ttyAMA10", "deviceType": "unknown"}]}

Later I have tried flashing the firmware to the recommended version from ITead, which lead to this:

$ ./ncp.py flash -p /dev/ttyACM0 -f ncp-uart-sw_EZNet6.10.3_V1.0.1.gbl
Restarting NCP into Bootloader mode...
SONOFF stick
Gecko Bootloader v1.12.00

Successfully restarted into bootloader mode! Starting upload of NCP image... 
Finished!
Rebooting NCP...
$ ./ncp.py scan
Connecting to.. /dev/ttyACM0 115200 True False 
Exception: <class 'IndexError'> /dev/ttyAMA10 
{"ports": [{"port": "/dev/ttyACM0", "vid": "1A86", "pid": "55D4", "deviceType": "zigbee", "stackVersion": "6.10.3-297"}, {"port": "/dev/ttyAMA10", "deviceType": "unknown"}]}

This indicates, that the version which was on the device is the one recommended in the link to firmware in OH docs and it might not be the firmware that is faulty because the issue prevails.

justaoldman · October 14, 2024, 5:24pm

HI,
At this point you have pretty much eliminated most to the most common issues that occur.
The only thing left is docker and the dongle itself. You might try and toss a fresh sd card in and throw a pure openhabian install and Openhab last stable build to remove any docker related challenges.
Otherwise maybe the binding maintainer may have suggestions.
I think he is traveling currently but if he does see this he could at least speak to any firmware version related questions you may have.

brianlay · October 14, 2024, 7:01pm

You might going in a different direction by using

I found the OpenHAB binding to be somewhat limited and Z2M is easy to set up.

Stepiiis · October 15, 2024, 9:06am

Thank you, I will try that in a few weeks once I get to the device physically. For the next two weeks I can only connect via SSH so I will try and throw in a fresh install.

If that won’t help, I will wait for the maintainer to come back.

Stepiiis · October 15, 2024, 9:08am

Thank you, I have heard of this and will check it out. What do you see as the main limitations of the zigbee binding, that the Z2M doesn’t have? I have understood it as an in-between bridge.

brianlay · October 15, 2024, 11:12am

Device support list on Z2M is much larger than the OH ZigBee binding.
OTA device firmware update is much simpler with Z2M.

chris · October 15, 2024, 3:25pm

Unfortunately the info here isn’t very useful. Can you please set logging to DEBUG level and provide a longer log - this log is only 10 seconds long.

While it is correct that Z2M has support for devices that don’t meet the zigbee spec, the “device support list” is not really relevant. The zigbee binding doesn’t maintain a proper list of devices - it supports devices that conform to the spec and we don’t try and list all these . I believe Z2M is a lot more hassle than the OH binding, so both have advantages and disadvantages.

Anyway, if you can supply a DEBUG log I will try and work out what is wrong.

Stepiiis · October 15, 2024, 5:26pm

I have set the logging of the zigbee binding to debug and restarted the OH contianer and let it run for a couple of minutes.

This is the full log. openhab.log (384.7 KB)

Thank you to all for your help.

chris · October 15, 2024, 5:41pm

Thanks. It looks like the device isn’t communicating, but we need to change some logging settings…

Do you see the following (or something similar) in the log settings? If so, can you change the ones I put the star against to DEBUG and try again. Currently I just see the main binding - i.e. the first one I starred.

Thanks
Chris

Stepiiis · October 15, 2024, 6:00pm

Thanks for the quick reply. I have set all of them to debug and restarted the container. The log file is over 1MB so I cant attach it here. I have uploaded it to mega.

chris · October 15, 2024, 6:37pm

Thanks - that’s useful.

Try a reinitialisation on the dongle - click the advanced options, then reinit controller (1 then 2 in the image below).

Stepiiis · October 15, 2024, 7:33pm

I have configured the bridge via file, so I could not flip this switch in the config, however I have tried adding the dongle as another thing via UI config and the device came online! Does this mean I have to rely on the configuration via UI, or can I flip this setting inside the config file? I did not find any information related to this switch in the binding docs.