Just so I’m certain: if I were to configure a programmable S3B/900HP Coordinator radio’s UART as “Serial console enabled” in the settings, would that only direct the output to the console/screen instead of Tx, and only permit local input from the terminal instead of Rx?
I want to configure the coordinator radio to interact with a Raspberry Pi so it may communicate the status of 20-30 client nodes that the Coordinator oversees. I initially chose Serial Console Enable in the settings to printf/echo for debug purposes, but thought I might keep it for troubleshooting. Is it still possible to interact with the Pi in this case, or does that somehow intercept the lines, and will need to be disabled?
I use the programmables for a lot of things I can’t otherwise achieve. My client nodes have custom control applications deployed to operate multiple devices and read various sensor values and they do so independently even if signal is for whatever reason lost.
My coordinator does not do these things, but is responsible for accumulating all the client data snapshot strings and also issuing asynchronous commands generated by user events. I use a SQL database (Maria) to bridge that gap, and host it on the Pi, where space is plentiful. So another one of those reasons is the Pi has a lot of space, memory and CPU, and isn’t in a location with limited available power.
I think that’s a pretty solid case for the Pi, but if you’re aware of a SQL library that would fit on the programmable variant S3B/900HP, I’d love to hear of a reliable one as it would at least eliminate one intermediate step. I am assuming though that even if these are platform-independent, lightweight RESTful HTTP calls, what transports the data??? Serial?
What about the serial console enable? Does that need to be disabled? I’ve noticed if I am connected via USB+XBIB to the 900HP and running (old) XCTU and try to reset my device for an update, the Reset will not help discover the device if my Tx/Rx pins also happen to be attached to the Pi.
I think you misunderstand. I am saying that it would be better if you did not use the programmable version. That way you don’t need to create and load on an additional application just to be abler to send and receive data over the XBee Mesh network.
That is correct. The old XCTU or any software is going to be able to reset the modules when another device is controlling the data lines.
The code on the XBee needs to be written in C. It is not going to support a SQL data base.
“That is correct. The old XCTU or any software is going to be able to reset the modules when another device is controlling the data lines.” – do you mean “not going to”? just making sure.
I may still be misunderstanding what you’re saying. The Pi is only connected to the Coordinator, not any of the client nodes. As far as I understand, which it seems you are agreeing on, the only way to get SQL connectivity is going to be through an interface developed between the two devices over serial. You seem to be suggesting to simply use a non-programmable version but still put the Coordinator in API mode so the addressing flexibility is there for the Pi. Then just build API frames in the Pi accordingly for responses?
I guess that could work. I was not envisioning programmable clients and a non-programmable coordinator. Do you recommend a package on Raspbian to download and install to get the Xbee libraries set up? I have only developed them in the CW SDK thus far…
Do you recommend a package on Raspbian to download and install to get the Xbee libraries set up? I have only developed them in the CW SDK thus far…