yes but since at some point in processing you have to map an incoming packet to a thing, I thought it might be done that way. It was pure speculation but would have explained my findings (as said I didn’t know 65535 is invalid). So how do you map with multiple controllers - use the serial port?
Also wonder about the other way round: I currently have 2 or 3 different ZigBee controllers in my box - all online - and I’ve recently reset another Aqara sensor. Scanning showed it to be found for the iTead controller.
Is it pure coincidence which coordinator the sensor will use or is there anything I can do to influence which one it finds (other than to temporarily disable the others) ?
Will the initial network join work all the time or just when I scan (like with zwave inclusion mode which is enabled by entering thing-add mode) ?
If always then what if there’s another controller around I cannot disable (like a Hue bridge or my neighbor’s bridge) ?
Simple answer - yes - if you have multiple networks, then you will have a different dongle for each network, and each network will therefore be on a different serial port. The long answer is more complex in that technically it’s possible for a controller to run multiple networks, but that’s not supported in the binding.
You should only enable discovery on one coordinator at a time. Unfortunately OpenHAB doesn’t support this, so yes, it will be luck of the draw (actually based on the network with the best signal at the location of the joining device).
I’m not sure I completely understand this… Do you mean is join enabled all the time? If so, no, that’s not possible in modern ZigBee networks - join is only enabled for a maximum of 254 seconds at a time. However the binding will disable it quicker than this (from memory it is only opened for 60 seconds).
The stick with the no flow control firmware has reverted to 65535 in the UI but like a fool I had failed to put debug on so I can’t say why other than the no flow control firmware does something differently.
I see that as a user I cannot select the coordinator(s) to do discovery on in OH (I understand your comment such that the API doesn’t support it so you cannot do anything about it either), but just to make sure, does that mean that to first disable all coordinator things in OH except the one I want then scan is a safe (deterministic) process ? Or would I have to unplug the unwanted ones ?
@robmac Good!
These tings is starting to make some sense.
With the clarification from @chris about panid 65535 and the experiences @Hedda posted from around the homeautomation communities about firmware, flow control and shielding on the sticks we have something to work on.
I hope to find some time tonight for flashing with software flow control and testing.
No, not yet. Too many females to attend to, the fourlegged ones have started to give birth. And my dearest served old fashioned Norwegian fish soup with cob, salmon and shrimps. And some glasses wine. I am stuffed and pretty shot now.
Software flow control provides some control over the flow of message strings.
If this flow was flawless we could use “no flow control”.
I might dig out my oscilloscope to see if I can see something.
Only long term use will reveal the stability.
It is a cheap design, so I do not expect too much.
Flow control is there to prevent overflow of data being sent from one end or the other overflowing receive buffers on the other end. This can happen if (for example) your PC running OH gets busy for some time, then it may be that the NCP is sending data that overflows the buffers in the receiving chip if the computer doesn’t service it quick enough.
This will happen occasionally in pretty much all systems - hence flow control is highly desirable to prevent corrupted data which the system would then need to try and recover from. If it can’t recover, then the binding would need to reset the NCP and start the network up again.
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…
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?
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:
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:
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.
