that reaffirms what tckr said in reply to my question. Bummer, would be nice to use. That bug may alter my component selection here soon.
Was going to use an i2c slave device with the xbee as a master to facilitate more I/O ports… but since that bug exists and hence I won’t be able to request/transmit the I/O port data from the i2c slave device… I might have to go with ditching the i2c slave device cheaper solution and instead go with just doubling the amount of xbee router devices I will be using in order to facilitate more I/O ports without using micropython.
This bug won’t be fixed anytime soon for ZigBee mesh devices im guessing, yeah?
Is there a reason you can’t continue running with ATAP=4? If you don’t have anything connected to the serial port of these routers, then it shouldn’t matter what ATAP setting you’re using. If you need to send data out that serial port, you can just have MicroPython print() statements pass it out.
mmmm… yes there is a reason.
which is…
I need all the devices in API mode to establish a network right?
My concise system overview is as follows:
network of ~ 20 XBee3 modules, coordinator, else routers…
PC running main Python program that holds the GUI stuff and defines most of the functionality, xbee onboard pin manipulation stuff… then at first I was going to have micropython flashed on each router module in which, at start up each device would send a message at start-up containing its MAC to the coordinator which would be processed in the Python program and then the router would be assigned a new NI through that MAC address as an identifier(I’ve almost successfully bypassed this due to the firmware bug issue by just having the JN=1 for each router and would do all that reassignment through that API frame parsing in python instead of using start-up micropython transmit functionality… after that start-up subprocess is complete for the whole network, there would be more micropython that would essentially be waiting to have i2c pin status requested and sent into the python program from router to coordinator.
back to your question… so my current understanding (which at any point could have major fundamental holes) is that yes, the way I have the system implemented currently, all the modules would need to be in API mode because… well in API that is how you have a multi-node network established right? in ATAP=4 mode you can’t like open the coordinator device and then discover router devices into the network… you cant establish a multi-node network with ATAP=4 mode right? Like when I run my python program that basically opens the coordinator and then simply discovers the router modules via their NI string… if not in API mode the program just immediately says “hey you’re not in API mode so don’t come back until you are.”
but yes. for multi-node network establishment you need API mode… not serial point-to-point mode (ATAP=1 or 4)
unless I fundamentally rework the flow of my design… which im trying to avoid after a couple months of work lol.
The nodes on a network can have any combination of ATAP settings. The coordinator can use ATAP=1 and the routers can use ATAP=4.
ATAP is only used to control how the serial port of the XBee works. 0=“transparent” mode (raw, unframed data), 1 and 2 are API modes (framed data) and 4 is MicroPython (REPL and running program output on serial port).
ok I lied, when I switch the routers to ATAP=4 and then run the python where it discovers them like usual, program runs fine…
what the fudge. the intro documentation makes you think API is for multi-node… AT is for 2 devices in total.
guess not.
ok so…
in my network of 3 devices (1 coord, 2 routers)
if both routers are in AT modes Coordinator in API… python program ive developed works fine.
if all 3 in AT mode… then I get that immediate error saying Unsupported operating mode: AT mode
So the coordinator is what matters with the whole api vs at modes??? only the coordinator lol?
so I can indeed have the coordinator in API mode…
and all the routers in AT=4 or AT=1 mode and poof all the things ive been going on about the past week don’t matter at all?
I can send all the stuff I want in python or micropython, transmit receive between the two no problem??
whats the point of having the routers in api vs at modes then… why aren’t routers/end devices just always in AT modes without the option to switch if they can do it all in AT modes?..
but then I guess the firmware transmit workout I did yesterday/today with having the JN=1 on each router device so it sends an API packet wont work if the routers are in AT mode… cuz then they won’t send the API packet that I’ve parsed…
so I can just go back to my micropython start-up thing maybe
thanks btw
It’s much simpler than that. Re-read my message about what ATAP means.
AT mode (0) means the serial port is configured for transparent data.
API mode (1, 2) means the serial port is configured for framed data.
MicroPython mode (4) means the serial port is configured for the MicroPython REPL and running program.
Different customers will use different modes for their deployed network. In general, if you have another microprocessor interfaced to the XBee via its serial port, you’ll want to run in “API mode” so you’re sending and receiving API frames. If you have a “dumb” device that can’t parse data, you typically run in “AT mode” to transparently send/receive serial data.
It has nothing to do with whether it’s a coordinator or a router. It has everything to do with what you’re going to connect to the serial port. Your coordinator has a PC running Python code expecting an XBee module in API mode. Your routers don’t (as far as I can tell) have ANYTHING wired to the serial port. So your routers can use ATAP=4 mode to work around the current XBee3 Zigbee bug where xbee.discover() doesn’t work otherwise.
BTW, please send a link to the introductory documentation that wasn’t clear, and we’ll try to improve on it.