I just checked my production network (Running on a Bitronvideo stick) and compared openhab:zigbee netbackup to UI.
The panid is the same. openhab:zigbee netbackup report in hex while UI shows in dec so you have to convert. It is the first value after COORDINATOR.
However the network key is not the same…
Yes that is also FFFF but if it was different on the stick surely the network would no longer work unless the devices included again?
FYI, a Silabs engineer (on his own personal time not representing the company) replied to that Flow Control discussion and said that he uses software flow control in his own firmware builds, but it sounds as if he maybe suggesting to try building a firmware with an even higher baud rate speed than 115200?
https://github.com/xsp1989/zigbeeFirmware/issues/15
That Silicon Labs engineer wrote this in regards to using higher speeds for NCP serial communication:
“Indeed the USB stick does not have HW flow control lines connected. it would have had the cost of 2 extra PCB traces as the CH340 supports it. Sad and a missed opportunity. So at least XModem flow control should be used, but it would even be better to pick a higher baudrate, which is possible as well.”
“With a bootloader update followed by NCP update, one can safely push higher baudrate variants, but i will test this first, as I do not know the limitation the CH340 may impose here, need to test that”
FYI, CH340 USB-to-Serial chips should support communication baud rates from 50 baud to 2 Mbaud:
http://www.wch-ic.com/products/CH340.html
It also sounds as might need another round of tuning HFXO Capacitor Bank calibration value (CTune).
“Setting the CTUNE to 128 is as arbitrary as setting it anything else unless you know what you are doing. CTUNE value can be calculated from the datasheet of the HFXO used, so if anyone knows what XTal is used (and have a link to its datasheet) I am happy to calculate the optimal CTUNE value for it.”
Too bad ITead didn’t add SMA (or IPEX) connector + external antenna or used a ceramic chip antenna.
Solder points for PCB trace antenna look too small for an average DIY thinker like myself for soldering on a RG316 SMA-Female to PCB solder pigtail antenna cable, but maybe others are willing to do it?
There are guides to solder SMA connector PCB trace antenna path so can use external antenna, ex:
https://www.instructables.com/External-Antenna-for-ESP8266/
https://community.home-assistant.io/t/how-to-add-an-external-antenna-to-an-esp-board/131601
https://community.openhab.org/t/esp8266-antenna-mod-extend-wifi-range/78982
Most of those guides use RG316 SMA-Female to PCB solder pigtail cable and a 2.4GHz WiFi antenna:
https://www.amazon.com/Pigtail-Antenna-Extension-Connector-Lsgoodcare/dp/B072LFYHHN
Note that there are of couse a huge difference in quality between different external antennas for Zigbee:
PS: New dongles with only integrated antenna should use a ceramic antenna, not a PCB trace antenna.
I spotted that post regarding higher baud and was thinking it would need a large network to require more than 115200.
If it was faster then the rest of the hardware downstream would also have to cope with the flow so it could be one of those things that sounds good but for most of us would add little value.
It does feel like a limit few of us will suffer from but I might eat my words in a few months when 30 devices swamps the serial interface.
suddenly the panid had changed to 65535 (and zigbee netbackup shows FFFF).
The bulb dimmer works from UI
The other parameters are what they was at initialization on the Bitron stick before I restored to the Itead stick.
It can not be much traffic on this network as it is only one Ikea bulb.
I did restart openhab today and checked the panid after the restart, but had the right value. Mybe I was too quick checking after the openhab restart?
I did not activate debug logs, and nothing is seen in the logs.
openhab> zigbee ncpstate
Ember NCP state : EMBER_JOINED_NETWORK
Local Node Type : EMBER_COORDINATOR
IEEE Address : 847127FFFEC9A4E1
Custom IEEE Address : FFFFFFFFFFFFFFFF
NWK Address : 0000
Network PAN Id : 3039
Network EPAN Id : 1234567890ABCDEF
Radio Channel : 11
Network Manager Id : 0000
Radio TX Power : -1
Join Method : EMBER_USE_MAC_ASSOCIATION
Board Name :
Manufacturer Name :
Stack Version : 6.7.9.0
Custom Version :
openhab> zigbee netbackup
2021-04-23T15:53:32Z>COORDINATOR>FFFF>1234567890ABCDEF>CHANNEL_11>0123456789ABCDEF0123456789ABCDEF>00>>0000313C>5A6967426565416C6C69616E63653039>>>00000000
So zigbee netbackup do not show the correct panid.
But zigbee ncpstate do.
So that is the same as I am seeing. Nothing other than info or debug in the logs so no true errors or warnings in my log. Any in your logs?
Nope.
Same for me, GUI shows Pan ID 65535, ncpstate shows the right one.
I’ve configured that (again) in GUI, now my sensors are “gone” as UI tells me.
It’s really not relevant. The network runs at 250kb/s so 115k is always more than enough. Most sticks operate at even lower rates on the serial link as actual data is always significantly lower than the OTA rate.
1 Like
I spent quite a bit of time yesterday debugging some stuff for a customer and started loads of networks and don’t see any issue with the PANID so I’m a bit confused by this. On the other hand, I’m sitting here wondering why there is so much discussion about it - it’s an advanced parameter that shouldn’t really be touched…
If someone provides some logs showing startup of the binding I’ll take a look though as clearly it shouldn’t be showing 65535.
So, when we execute openhab:zigbee netbackup the values is read out of the stick every time?
And the same for openhab:zigbee ncpstate?
Please remember that PAN ID really doesn’t change often - if at all. The only time it will change is if there is another local PAN that has a conflict - ie two PANs have the same short PANID. If that happens, then the system will change the PANID - I don’t think it is possible to change this manually (I’m not sure if people are trying to do this, but it isn’t recommended at all).
The ncpstate commands etc always read data from the driver.
The actual panid has not changed Chris and neither are there any warnings or errors in my logs just debug messages that all looks like reporting of successful activity.
It is just a test observation that it shows differently and as you have debugged the network code in the binding it looks like an observation of this stick’s behaviour not the binding. If it has no adverse side effects beyond the odd value displaying then I will be ignoring it.
Maybe we’re looking in the wrong place.
I’d also guess PAN ID as you say doesn’t change (as ncpstate confirms, too) and the problem is possibly not in the network or binding but somehow related to the interface or transfer between binding and UI ?
As mentioned on the split thread I also have an issue that I cannot set a zigbee parameter to a value inside the acceptable range apparently because the UI itself dislikes it. Seems it has it’s own idea of contraints that would need to be fulfilled. Dunno where to configure that, though.
Could it also be the UI that “resets” PAN ID ? I remember that phenomenon from PaperUI, and still occasionally see it in Main UI: you read the set of parameters of a device and when you want to write it back UI suddenly complains about some value being unacceptable (although you didn’t touch that one). Sometimes it’s a data type mismatch where one of them thinks it’s a signed integer and the other one interprets it as unsigned or vice versa. Or a similar thing.
Also mind that as testers, we’re also creating new OH things fairly often. What if I create a coordinator thing for a coordinator with an existing network config (& Pan ID) ?
Yes, I agree with @robmac .
When we see panid at FFFF it is the symptom. Not the real disease.
My litle test network is still working as I can change the dimming on the bulb.
However it also mean we can not perform a relaible backup and restore.
I have not found a way to recover (the settings as seen in UI) when it happens.
I do not think it is a real panid collision.
I also see the panid set at FFFF sometimes when I initalized the Itead stick for a new test network. I will see if I can capture a debug log of this.
So, I set up my little test network again. As expected it was working.
But after a openhab restart, panid was reported as 65535.
This time I had debug logging on.
openhab.log (753.1 KB)
edit, some related snippets:
2021-04-24 22:22:39.942 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - bundle org.openhab.binding.zigbee:3.1.0.202103220326 (231)[org.openhab.binding.zigbee.discovery.ZigBeeDiscoveryService(260)] : dm ZigBeeCoordinatorHandler tracking 3 MultipleDynamic added {org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler}={service.id=449, service.bundleid=236, service.scope=singleton} (exit)
2021-04-24 22:22:39.960 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initializing ZigBee network [zigbee:coordinator_ember:beef].
2021-04-24 22:22:39.961 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Channel 16
2021-04-24 22:22:39.961 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - PANID 1025
2021-04-24 22:22:39.962 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - EPANID 0000000012341234
2021-04-24 22:22:39.962 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network Key 00112233445566778899AABBCCDDEEFF
2021-04-24 22:22:39.962 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link Key 5A6967426565416C6C69616E63653039
2021-04-24 22:22:39.962 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Config: zigbee_initialise found, initializeNetwork=false
2021-04-24 22:22:39.963 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network Key String 00112233445566778899AABBCCDDEEFF
2021-04-24 22:22:39.963 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network key final array 00112233445566778899AABBCCDDEEFF
2021-04-24 22:22:39.963 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link Key String 5A6967426565416C6C69616E63653039
2021-04-24 22:22:39.964 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link key final array 5A6967426565416C6C69616E63653039
2021-04-24 22:22:39.964 [DEBUG] [ng.zigbee.ember.handler.EmberHandler] - Initializing ZigBee Ember serial bridge handler.
2021-04-24 22:22:39.979 [DEBUG] [ng.zigbee.ember.handler.EmberHandler] - ZigBee Ember Coordinator opening Port:'/dev/ttyUSB0' PAN:401, EPAN:0000000012341234, Channel:16
2021-04-24 22:22:39.979 [DEBUG] [ng.zigbee.ember.handler.EmberHandler] - Ember end device poll timeout set to (169 * 2^9) = 86528 seconds
2021-04-24 22:22:39.982 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Scheduling ZigBee start
2021-04-24 22:22:39.983 [DEBUG] [e.ember.internal.EmberHandlerFactory] - bundle org.openhab.binding.zigbee.ember:3.1.0.202103220328 (236)[org.openhab.binding.zigbee.ember.internal.EmberHandlerFactory(272)] : dm $000 tracking 2 SingleStatic added {org.openhab.core.io.transport.serial.SerialPortManager}={service.id=446, service.bundleid=243, service.scope=bundle, component.name=org.openhab.core.io.transport.serial.internal.SerialPortManagerImpl, component.id=281} (exit)
2021-04-24 22:22:45.160 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - Ember initial network parameters are EmberNetworkParameters [extendedPanId=0000000012341234, panId=FFFF, radioTxPower=-1, radioChannel=16, joinMethod=EMBER_USE_MAC_ASSOCIATION, nwkManagerId=0000, nwkUpdateId=0, channels=07FFF800]
2021-04-24 22:22:45.219 [DEBUG] [stems.zigbee.internal.ClusterMatcher] - ClusterMatcher adding server cluster 0000
2021-04-24 22:22:45.220 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee Initialise: Previous device configuration was: channel=CHANNEL_16, PanID=65535, EPanId=0000000012341234
2021-04-24 22:22:45.220 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Config: zigbee_trustcentremode=TC_JOIN_SECURE
I also do this very often - I don’t see this issue - as I said earlier I did a load of testing, creating a number of new networks over the past couple of days, and never saw this issue. It would be good if you could provide a log showing when the PANID is set to FFFF.
Hi, @chris I hope you have seen my previous post and the log attached.
I wanted to see if I could get the same error on firmwareVersion 6.5.5.0.
So I reinitalized a Itead stick that I briefly tested before.
Set channel:16, panid:1026 (0x402), ext-panid: FEDCBA9876543210 networkkey:FFEEDDCCBBAA99887766554433221100
But the stick newer came online, I had to restart openhab, and that worked to get it online.
openhab-init-itead6550.log (801.0 KB)
This is where I deleted the other Itead stick (with 6.7.9.0 firmware, so from there on):
2021-04-26 00:02:45.834 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Serial port '/dev/ttyUSB0' closed.
There must bee something with the reinitalization that do not take the parametres from UI and transfer them into the stick. Now I see a panid and a extended panid that looks familiar, so I assume was in the stick. These are not the values I set before restart. The networkkey, ch was the values I intended to use.
This is the log after the restart:
openhab.log (381.6 KB)
I will try to look later - I’ve not seen the log. However if you want to reinitialise a stick, then you should click the reinitialise button in the configuration.
I’ll check the log tonight.