This is my mqtt conf at z2mqtt.
Maybe you are missing :1883
server: mqtt://192.168.0.28:1883
user: blahblah
password: blehbleh
no, its user instead of username, but thanks, now all works fine.
When some devices are not working perfectly (and in meantime I added more AC connected devices), what do I have to do? Press RECONFIGURE on the troubled device, or ?
Please try not to go too much off-topic, Zigbee2MQTT specific questions are better asked in their discussions at https://github.com/Koenkk/zigbee2mqtt/discussions and Z2M specific problems/bugs to https://github.com/Koenkk/zigbee2mqtt/issues/ …or just start a new thread if the question is not directly related to this dongle.
Hi!
Could you please help on on that…
I bought a ZBDongle-P several months ago to replace my previous BitronVideo dongle. The new device worked fine from the start, I flashed with newer and newer FW-s more times, currently with the latest Koenk FW…
"manufacturer": "Texas Instruments",
"model": "CC1352/CC2652, Z-Stack 3.30+ (build 20220219)",
"class": "zigpy_znp.zigbee.device.ZNPCoordinator"
…it also works without any problems.
I just have one question what I definitely remember that saw somewhere before but now I can not find it.
From the start of its usage I always had/have 2 devices/entities as coordinator. One ZNP based and one unknown. The Zigbee mesh/network shows me that my Zigbee devices connected to the ZNP based controller/gateway but in this case what is the other? Do I need it at all? Could it be just an older bug related result, which currently is just a garbage? I have no problem with the whole setup, but sometimes I like to do some polish/sophisticate my settings, and ‘now’ I have catched this point.
The ZNP one:
And the other one:
Sorry if I’m redundant, I tried to search it everywhere but simply can not find now, but as I wrote I definitely remember that I saw somewhere before from other persons also.
Lot of thanks for any advice in advance!
That “unknown” Zigbee Coordinator that you see will surely be garbage left over from your old Zigbee Coordinator adapter. At least it should not be there. Must be a bug in ZHA integration so post new issue to → https://github.com/home-assistant/core/issues (it looks like a similar issue is posted here → https://github.com/home-assistant/core/issues/46258)
1 Like
@Hedda thanks for the answer!
I have found one not same, but also interesting situation which also answered by you…
…so I could imagine two things:
I’m sure that I had deleted my old controller before I added the new one. I’m also sure that I tried it more times, as I remember that never understood why I have 2 controller right after ZHA initialization. But as this never lead me to any error I left it.
- But this was ‘long time’ ago, maybe firth the first SONOFF firmware… maybe this could be one reason of the result.
- ZHA device handling could be also the reason as this was really months ago.
- And could be also the result of that before I attached USB controllers to HA Docker container by their basic
/dev/ttypath. But later as I saw lot of suggestions about not to use them through such way but use them through their discrete device IDs, I changed my device attachments also.
Maybe all these 3 reasons could lead me the mentioned situation.
Because your answer I have deleted the unknown device, restarted HA, and still seems everything fine, and the deleted device have not re-appeared yet.
But I also show you an interesting thing:
$ lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 7825:a2a4 Other World Computing External SATA Hard Drive Adapter cable PA023U3
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 003: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 nov 15 13:09 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 nov 15 13:09 /dev/ttyUSB1
$ ls /dev/serial/by-id/
usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_88a22df07c29ec119cf76d7840c9ce8d-if00-port0
usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_745441651e94eb119abd32703d98b6d1-if00-port0
There are 2 very same devices while I have really 2 but different USB dongles on the corresponding RPi4:
- The SONOFF - ZBDongle-P,
- and one Aeotec - Z-Stick 7 (ZWA010-C | ZST10-700).
Both of them show the same device ID, name, etc, however they are really 2 discrete and different devices.
Could this be the reason of the earlier problem? Could the 2 device made some collision like result? They worked always, paralelly, but with the mentioned ‘superficial problem’. This is basically the 3. theory in my list above.
Thanks for your answer, in advance!
Well, I think the semantics is explained poorly there. While I guess it sort is true that their ZBDongle-E is technically “supported” from Itead/Sonoff point-of-view as a company as it works and should be usable for most people, but it is a fact that Zigbee2MQTT still does not list the ZBDongle-E as recommended and so far only list it as “experimental”.
So the user experience at this time is likely not to be as good as someone using the ZBDongle-P instead, for the reasons that Zigbee2MQTT codebase does not yet offer feature parity for all Zigbee Coordinator and Zigbee stacks chips from different manufacturers. At least the function for restoring the backup image is missing for Silicon Labs EmberZNet EZSP based adapters (and the Zigbee2MQTT codebase lacks some development regression tests in its ezsp adapter code), as well as stability in Zigbee2MQTT with Silicon Labs EmberZNet EZSP based adapters is not quite as stable as a Texas Instruments ZStack 3 ZNP based adapter due to not being as mature. See these three links for reference:
Hey everyone. It’s my frist post here. I’ve just buy ZBDongle-E - i fucked up? There is some new firmware? My HA discover the dongle and i try to integrate sonoff and zigbee tuya curtain module. I think that i’ve got bad range and i don’t know how to get better of that.
To sum up…
- there is some firmeware to update the dongle? What it’s give?
- There is some options to get better range (i know this option with usb cable).
- Did ZBDongle-E got good support now? Or still ZBDongle-P is better?
You posted in the wrong thread then, instead see this other thread which covers the ZBDongle-E model and many questions related to it → ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus V2” (model "ZBDongle-E") based on Silicon Labs EFR32MG21 +20dBm radio SoC/MCU
Read and follow guidelines in this other thread → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage
I noticed there is a new firmware v20221226. I can’t remember, will updating the firmware wipe all paired devices?
Didn’t for me. Just updated and all is still working. I used the method without opening the case
Awesome, thanks!. I haven’t used that method yet. Can you point me where to get the tools for the method?
Edit:
Nevermind. found it listed in the first post
1 Like
Not tested myself yet but seen Koenkk released Z-Stack_3.x.0 coordinator 20221226 Zigbee firmware:
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin
It is built from Texas Instruments SimpleLink SDK 6.10.01.01 which in turn got these bug-fixes/changes:
Note that adapters based on Texas Instruments CC2652 and CC1352 chips can be flashed by putting them in the bootloader (see your adapter manual on how to do this or use the sonoff parameter with the cc2538-bsl flasher tool). When it is bootloader mode one of the following tools can be used to flash firmware image to it:
- ZigStar GW Multi tool (multi-platform GUI tool)
- CC2538-BSL (multi-platform Python-based command line tool) (instructions)
- Texas Instruments FLASH PROGRAMMER 2 (Windows only)
If your OS is unable to find the device chances are that your OS can’t communicate with its virtual COM port because lacking drivers:
Sometimes it wipes the NVRAM during the firmware upgrade and sometimes it does not, so the general recommendation is to always do a backup before upgrading firmware. If you are using a later version of Zigbee2MQTT or Home Assistant’s ZHA integration in a Home Assistant Operating System or Container installation then they perform Zigbee network backup for you. You can otherwise do a Zigbee network backup report/save via their GUI interface or alternatively manually with either zigpy-cli or zigpy-znp
https://github.com/zigpy/zigpy-cli
https://github.com/zigpy/zigpy-znp/blob/dfbc7a44ea217f99c1715c07042494afaa5dde33/TOOLS.md
2 Likes
Thank you for the info! I backed up my coordinator last night in case something goes wrong. Will try updating the firmware later tonight or this weekend.
Updated the firmware using the python method. Super easy and all my devices showed back up in Z2M. Yay!
HI every body.
I’m having difficulties with Flash Programer. it does not communicate with Sonoff Dongle Plus. I’m pretty sure I pressed the boot button before putting it in the usb port. I select the path to the file etc. I’ve done this on more than one machine (PC and lap Top) and I have the same results! the error message is: >Initiate access to target: COM5 using 2-pin cJTAG.
ACK/NAK not received. Expected 0x00 0xCC or 0x00 0x33, received 0x78 0x00.
ACK/NAK not received. Expected 0x00 0xCC or 0x00 0x33, received 0x80 0x78.
No response from device. Device may not be in bootloader mode. Reset device and try again.
If problem persists, check connection and baud rate.
Connecting over serial bootloader failed: No response from device. Device may not be in bootloader mode. Reset device and try again.
If problem persists, check connection and baud rate.
If you have a Windows PC.
Have a look in comment #2 on this thread, where Hedda describes the FW upgrade. I have used the method numerous times, works every time and less than 2 min, when you got the initial things installed.
That error message means that it is not in bootloader mode. Be sure to press AND hold the bootloader button, (and not only press then forget to hold).
You of course also have to make sure that no other application is connected to the adapter or trying to open a connection to it at the same time, so if running the commands from your Home Assistant instance via terminal then you need to temporarily stop/disable the ZHA (Zigbee Home Automation) integration or the Zigbee2MQTT add-on if you are using that.
If you can stand up a working Python 3 install, the easiest tool to use in my mind is the CC2538-BSL boot loader/flash tool. The tool will scan the system for the first instance of an eligible device and automatically put it into boot loader mode.
The command is very straightforward…
python3 cc2538-bsl.py --bootloader-sonoff-usb -e -w -v image-name.hex
–bootloader-sonoff-usb is specific to the Dongle-P and activates boot loader mode without needing to take the device apart.
-e Erases before writing, which is necessary when overwriting to make sure the current firmware is completely wiped.
-w Tells the utility to write.
-v Performs a checksum verification after writing.
If for some reason the tool cannot find the serial port, add the following:
-p Serial port (i.e. /dev/tty.usbserial-110 or “COMx” for windows)
python3 cc2538-bsl.py --bootloader-sonoff-usb -e -w -v -p /dev/tty.usbserial-110 image-name.hex
1 Like