Question to the developer of firmware

[frfstu]

Question to the developer of firmware for SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2.

The system has:

1. SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2. with firmware 7.1.1.0 build 273
2. Zigbee2MQTT version 1.30.3 commit: https://github.com/Koenkk/zigbee2mqtt/commit/24c6b2e2

How correct is the formation of the zigbee network in this particular configuration? To clarify, I previously used Coordinator zStack3x0 with firmware 20220219 (https://github.com/Koenkk/Z-Stack-firmware/blob/6e3b68404136c8cf87979212665e6505bd9a0e3b/coordinator/Z-Stack_3.x.0/bin/CC1352P2_CC2652P_launchpad_coordinator_20220219.zip) with that the same version of Zigbee2MQTT, during the operation of which the fan device was connected directly to the Coordinator, and the remaining devices were already connected to it, establishing connections between themselves from two to four devices, thereby forming the same mesh network of interconnections based on a stronger communication signal between interacting devices. In the case of SONOFF, there is a tendency to connect most of the devices directly to the Coordinator (at the same time, the signal strength has become noticeably higher, which is generally good in conditions of "noisy" apartments with neighboring wi-fi access points, countless bluetooth devices, but there is also a minus in the form network "thoughtfulness" when loading device logos and at least rare but sometimes appearing pop-up messages about an error in connecting devices to the Coordinator) which, apparently, obviously unnecessarily loads it with exchange processes that must be performed by routers.

Loading device logos for devices https://www.zigbee2mqtt.io/devices/TS011F_plug_1.html#tuya-ts011f_plug_1, https://www.zigbee2mqtt.io/devices/ZP-LZ-FR2U.html#moes-zp-lz-fr2u, https://www.zigbee2mqtt.io/devices/QBKG04LM.html#xiaomi-qbkg04lm

[MattWestb]

The IT coordinator firmware is having most of the advanced Zigbee 3 child handling disabled that is making many new end device cant or having problem connecting direly to it. EZSP is 100% and is Zigbee certificated with then standard setting is being used. Some end devices can having problem then the coordinator is off line and jumping to one new router and is darning its batteries (Verified with older firmware of IKEA controllers and all Philips HUE) and its blocking EZSP having end devices as direct children for not getting this problems, Also having one very good radio transmitter and receiver is both good and bad then its being very "dominant" and is making the network not balanced so must manufactures is using lower power setting for better stability of the network. Also all coordinators is only doing the forming of the network mesh and then is living its life and shall dynamic finding the best paths for all devices but if you is having interference then it can being problem for the network getting all working OK then its impossible reviving signals from all needed devices for in the network. You can also see on the LQI that the coordinator is having very strong signal and is making it dominant and the links is not symmetric so very likely is the routers having not so good radio as the coordinator but you need waiting and look how its working in the long run the mesh is doing the routing.

[MattWestb]

One EZSP with one IKEA module (16 dbm) in ZHA in my small RCP test network and is having links between all router and the end device is using the best they can finding. The network is using the routing and is having good redundancy and all end device is having no problem committing in the network but is 6 on the same channel (Zigbee and thread networks). (round is end device oval is routes and the coordinator is square) PS: End devices is blocked from having the coordinator as direct parent and is forced using routers.

[xsp1989]

We are currently not responsible for maintaining and dealing with SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2 issues. If there are no other issues, this issue will be closed. Sonoff issues can be raised on itead’s GitHub

[frfstu]

Mattthanks for the very detailed answer! I will observe how the network works with this coordinator.

[frfstu]

xsp1989What do you immediately start to hysteria?! I just asked if this behavior of the network is normal or not? In addition, I indicated some details of my observations, hoping that they will be useful to you.

[MattWestb]

@frfstu Also if looking on your network map is the devices using the shortest (less hope) route to the coordinator = good but i dont knowing if the mesh routing is working if the coordinator is being down so devices can communicating with the network.

I was 3 weeks on holiday in Spain and was having my coordinator offline and all device was online in one hour after coming back = the mesh was working very well and also healing if somthing is happening but its not possible if having one star network like your is then its one single point of failure.

Also itead is not making great support but its different companies so not possible helping with itead specific problems in there products (ZHA devs have requesting information from them of firmware settings and not getting any replay = not interested).

[xsp1989]

xsp1989What do you immediately start to hysteria?! I just asked if this behavior of the network is normal or not? In addition, I indicated some details of my observations, hoping that they will be useful to you.

If you feel that what I said offended you, I would like to say sorry to you. But the problem you mentioned is related to sonoff, but we are the official warehouse of easyiot. If it is a sonoff dongle, you can contact the relevant personnel of sonoff to solve it. SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2 is not designed and produced by us.

[frfstu]

@MattWestb I understand what you are talking about! In principle, the devices in my network communicate with each other, but the priority communication channel goes directly to the coordinator, and this is how we understand the main point of failure. Well, you need to think about something, discuss it, for this I touched on this topic, because the case is not an isolated one and firmware developers can at least understand how to fix it by reading about it.

[MattWestb]

If having one router is having strong signal its using the route with less hopes for getting low delay and i see that your mesh is having indirect links to other routers but is not being used then the direct road is better so its looks OK

Silabs have some very good papers with routing in dens network and how its working with the routing but i cant finding it for the moment. I posting one link then im finding it.

[frfstu]

@xsp1989 Maybe I too "went too far" and I want to apologize for it! But you understand me, I already have three coordinators, including one of them from your production, and he has the same problems (and in some cases even more ambitious ones), and you yourself wrote to me in your answers that the problem has a very strange origin. These fixes are waiting for a whole crowd of people, because the problem affects an unlimited number of enthusiasts and specialists in the field of automation and all use the same devices in one way or another. I already contacted sonoff until they answered me, but I am a patient and persistent person, if necessary, I will stir up this topic so that they will lose sleep and will remember me in a cold sweat.

[xsp1989]

@frfstu According to your problem description, I understand that many devices will be directly connected to the coordinator instead of the router. If I understand wrong, please point it out. I think this should be related to the routing algorithm of each device, but the routing code is not public, which is very unfriendly to our application developers. I have seen a problem in the sliconlabs forum. It is about the mixed networking of MG13 and MG21 devices. The devices will tend to take the route of MG13 (maybe I remember wrongly, maybe it is MG21). This is the difference between the two caused by routing algorithms or parameters. If you don't want more devices to connect to the coordinator, maybe you can find a way to reduce the coordinator's transmission power to reduce the proportion of signal strength in the routing algorithm. Of course, this is not necessarily feasible.

[frfstu]

@xsp1989 That is, if I understood everything correctly, "children" greedily make a critical part of the code inaccessible for the good of the common cause?! Well, then this is a topic for the entire zigbee community, because it jeopardizes the development of technology and introduces some kind of sabotage. I tried to reduce the signal strength in the zigbee2MQTT settings, but this did not affect it in any way. Perhaps this is due to the fact that the Transmit power parameter is available for adjustment only if the Z-Stack coordinator is used "Transmit power of adapter, only available for Z-Stack (CC253*/CC2652/CC1352) adapters, CC2652 = 5dbm, CC1352 max is = 20dbm (5dbm default)" and it works there (when you set parameter 5, routing between devices happens exactly as intended).

[MattWestb]

Making changes in the core Zigbee stack code is not recommended then it can braking the mesh network functionality completely and most manufactures is not open with the code then its private property and they have invested many years and money in it. If you like digging Silabs code is here https://github.com/SiliconLabs/gecko_sdk

Also some interesting reading so you can understand way its working like its doing: an1138-zigbee-mesh-network-performance.pdf

[xsp1989]

@frfstu It is the chip manufacturer who does not disclose the network layer code. As a product competitiveness of chip manufacturers, such as TI, Sliconlabs, etc., there is an open source protocol stack called ZBOSS, but zigbee3.0 is no longer open source.

[frfstu]

@xsp1989 Look! Important clarification about ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20221202110211-if00! Your firmware 7.0.2.0 build 406 supporting EZSP v8 is faster and more stable with Zigbee2MQTT than even version 7.1.1-17 - these are key points for compatibility. Today I discovered that openHAB ZigBee Binding began to support EZSP v8 (even yesterday the system wrote to me that it only supports EZSP v4). In total, we have firmware version 7 that supports Zigbee2MQTT, works fast and uses EZSP v8, which in turn is now supported in openHAB ZigBee Binding! Just fix this and the system will be fully functional and ready even for production!

When adding a coordinator to the openHAB ZigBee Binding, it loops at the initialization stage and at this moment the Zigbee2MQTT operation crashes and this message appears in the logs:

2023-04-26 16:19:41.728 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:

java.lang.NullPointerException: null

at com.zsmartsystems.zigbee.dongle.ember.EmberNcp.getConfiguration(EmberNcp.java:457) ~[?:?]

at com.zsmartsystems.zigbee.dongle.ember.internal.EmberStackConfiguration.getConfiguration(EmberStackConfiguration.java:72) ~[?:?]

at com.zsmartsystems.zigbee.dongle.ember.ZigBeeDongleEzsp.initialize(ZigBeeDongleEzsp.java:439) ~[?:?]

at com.zsmartsystems.zigbee.ZigBeeNetworkManager.initialize(ZigBeeNetworkManager.java:418) ~[?:?]

at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.initialiseZigBee(ZigBeeCoordinatorHandler.java:431) ~[?:?]

at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.lambda$2(ZigBeeCoordinatorHandler.java:557) ~[?:?]

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]

at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]

at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]

at java.lang.Thread.run(Thread.java:829) [?:?]

When the coordinator is removed from the openHAB ZigBee Binding, normal Zigbee2MQTT operation resumes within a few seconds.

[MattWestb]

First the stable production EZSP is 6.7.8.X and the golden candidate is 6.10.3.X from the EZSP community (My and other ZHA user that have the most real life experience of this hard and software). All newer version is not near the stability of them and you is on your own then playing with them. If like having one more resent version i can only recommending RCP 4..2.2 with EZSP 7.2.2 that have the most bug fixes implanted after 6.10.X but is still more or less beta versions then many parts is / can having problem.

For your problems with Z2M and openHAB pleas addressing this to respective system and not to to the cooker of the firmware for one other product you is having.

[Hedda]

Just fix this and the system will be fully functional and ready even for production!

@frfstu please try to understand my replies to the same questions you posted here -> https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/issues/22

You have to grasp the concept that the issue is not in the firmware or hardware, but instead, the fact is that it is the application side that needs to be updated to support newer EZSP API versions, and also the fact that it is not the people or companies that develop and release firmware or hardware that is actually developing the applications!

So please stop complaining to firmware and hardware developers as there is no one here that is developing those applications!

https://www.openhab.org/addons/bindings/zigbee/

Also, as those applications (and binding/plugin/addon) in question are free and open-source software hobby projects you simply have to wait until the unpaid volunteers that application in their spare time have implemented support for the newer EZSP API versions. And if you are going to ask then post a polite request asking them nicely, do not demand as you have no ethical right to do so! You need to go address the openHAB community and its developer(s) of the openHAB ZigBee Binding:

https://community.openhab.org

See:

https://github.com/openhab/org.openhab.binding.zigbee/

Again, check out this related example request for openHAB binding for ZigBee:

https://github.com/openhab/org.openhab.binding.zigbee/issues/778

[Hedda]

Also, as those applications (and binding/plugin/addon) in question are free and open-source software hobby projects you simply have to wait until the unpaid volunteers that application in their spare time have implemented support for the newer EZSP API versions.

@frfstu Noticed that you are now spamming openHAB ZigBee Binding with this demand instead of waiting or asking nicely:

https://github.com/openhab/org.openhab.binding.zigbee/issues/802

https://github.com/openhab/org.openhab.binding.zigbee/issues/803

FYI, see openHAB ZigBee Binding's developer has an open code pull request -> openhab/org.openhab.binding.zigbee#804

Note that even after https://github.com/openhab/org.openhab.binding.zigbee/pull/804 is merged you then need to wait until there is a new release version of the openHAB ZigBee Bidning package in the org.openhab.binding.zigbee repository that contains that code/library update, and after that, you will also need to wait further until they bump the ZigBee libraries in openhab-core and then wait some more until they release a new version of openHAB that contains that new release version of that openHAB ZigBee Bidning package, which all in all will realistically probably take several months or more from now:

https://github.com/openhab/org.openhab.binding.zigbee/tags

https://github.com/openhab/openhab-core/search?q=zigbee&type=commits

https://github.com/openhab/openhab-core/tags

PS: Off-topic but highly recommend you step back and take time to read these articles before posting more to FOSS communities:

http://www.catb.org/~esr/faqs/smart-questions.html

https://en.wikipedia.org/wiki/Free_and_open-source_software

[Hedda]

@frfstu Noticed that you are now spamming openHAB ZigBee Binding with this demand instead of waiting or asking nicely:

openhab/org.openhab.binding.zigbee#802

openhab/org.openhab.binding.zigbee#803

FYI, see openHAB ZigBee Binding's developer has an open code pull request -> openhab/org.openhab.binding.zigbee#804

FYI, if I understand it correctly, openHAB ZigBee Binding add-on that is included in OpenHAB 4.0 (openHAB 4.0.0 and later) has been updated to ZSS library to version 1.4.11 which should mean that now support for EZSP v9, EZSP v10, and EZSP v11 versions.

https://github.com/openhab/openhab-distro/releases/tag/4.0.0

https://github.com/openhab/org.openhab.binding.zigbee/pull/804

https://github.com/zsmartsystems/com.zsmartsystems.zigbee/issues/1332

https://github.com/zsmartsystems/com.zsmartsystems.zigbee/pull/1378

https://github.com/zsmartsystems/com.zsmartsystems.zigbee/pull/1384

Again, if run into any issue with openHAB (or Zigbee2MQTT) then you need to address such issues with their developers, not here:

https://community.openhab.org

https://github.com/openhab/org.openhab.binding.zigbee/issues

https://github.com/Koenkk/zigbee2mqtt/discussions

https://github.com/Koenkk/zigbee2mqtt/issues

[Hedda]

@xsp1989 in my humble opinion, this issue can definitely be closed now,

[xsp1989]

I think so too, so I'll close this question first.