I have noticed that my AWS gateway consistently disconnects from its WiFi connection.
I will see the LED turn green for a while, then start blinking red. Sometimes, it will transition through some other colors, as well, before blinking red. But the last few times has been a direct transition.
It’s very repeatable.
I have tried three different WiFi networks including my mobile hotspot which I put right next to the gateway. I was wondering if it’s possibly a signal strength issue.
Is there anything else I could try? Has this behavior been observed with this device before?
Will the micro go into an error condition is there is no XBee in the socket?
I had removed it, and then when I put it back in, the disconnection/errors seemed to go away. I’m not claiming cause and effect, yet, but I thought I’d ask.
Yes, the gateway will flash errors if it’s not able to communicate with the XBee module. If you want to spoof the XBee module I guess you would also need to respond to requests being sent to the XBee module. I hadn’t thought of that before when you brought this up but this will definitely be required.
The Gateway is going to send some AT commands to the XBee to get some information so your serial device will need to handle them.
The first thing it will request is the Serial Low(SL), then it will request the network ID(ID), then it will request the Preamble ID(HP), then it will request the Tx Power(PL). After this the the Gateway needs to verify that the XBee module is still there and functional at all times so every 30 seconds it will send the Serial Low(SL) command to make sure the XBee module is still functional. You need to respond to these requests with an AT response frame packet, documented here: https://www.digi.com/resources/documentation/Digidocs/90002173/#reference/r_frame_0x88.htm%3FTocPath%3DFrame%20descriptions|_____8
When you receive data from the Gateway Module just check the Frame Type and if it is 0x08 then check the AT command bytes to see what the command is and respond appropriately.
No problem Jason. At this point it probably would have been cheaper to buy a sensor
If you put together a driver for this and felt so inclined I’m sure future users would greatly appreciate if you could share what you put together. I definitely see the benefit of being able to “spoof” sensors in this way. Would give users a way to test it out without buying several pieces of expensive hardware.
At this point it probably would have been cheaper to buy a sensor
Ha! I agree! I haven’t ruled that out, yet.
The long game here is to prep this gateway for use with an XBee form factor compression/analytics module that we have prototyped. I have done some write-ups and videos of using it with an XBee cellular module for inline data compression.
Our board fits right in between the modem and the XBee socket:
The idea with your gateway would likely focus more on analytics. I’d like to drop our module into the XBee socket and be able to send data up to AWS/Google/Azure through the ESP32 board.
The first demo would focus on simple unsupervised clustering and outlier detection on our board and only send info to the cloud when specific triggers happen.
If you have any recommendations for a path that could get me to something like that faster than what I’m doing, I’m all ears.
You’ve got your work cut out there. I wrote our gateway code that receives data from the sensors over XBee and then parses it, converts it to JSON, and then uploads it to those cloud platforms over MQTT. I couldn’t see a reasonable way to support all those cloud platforms on one device just due to memory storage and RAM availability. AWS requires x509 certificates for The MQTT connection which was really fun(). Google and Azure both use rotating keys so you have to send requests to update basic auth credentials so that’s also a pain in the butt.
I wish I could share the source code for the gateways, would certainly be a big benefit I’d think to a user such as yourself, but management close sourced the source code for all the gateways so my hands are tied. Not to say I can’t provide you a little support here and there though.
A word to the wise, don’t try to use off the shelf libraries for any of the cloud platforms(AWS, Azure, Google IoT, etc). They all work over MQTT. Just use the PubSubClient. It’ll do everything you need to do over The MQTT connection, although you will most certainly need to increase the transmit packet buffer size as it’s only 128 bytes by default. From there the main difference between the different platforms is authentication and topic/packet structure. I attempted to simplify user setup as much as possible so the gateways do most of the heavy lifting of obtaining credentials while the user just has to enter the Connection String for Azure, IAM credentials for AWS, or Region, Location, and OAuth Token for Google IoT.
I would not try to replicate all the work that is being done in the ESP32 firmware. The only component I am hoping to swap out is the XBee radio. Our board would still talk to the ESP32 though UART just like the current setup.
And, in fact, there’s probably room for a version that includes the XBee wireless module still. The XGZ board can function as a passthrough module providing some processing on the data before it hits the WiFi connection.
BTW - great work on this device. Very clean hardware and a pleasure to use. The quality is outstanding!
). Google and Azure both use rotating keys so you have to send requests to update basic auth credentials so that’s also a pain in the butt.