So it was time to update the software.
the previous version of my software was rather basic. I would send it a basic commaind using AT mode in Xbee and it would dump a delimited string holding each analog sensors’ value.
No digital input, output or pulsewidth capability.
No ability to poll at a different frequency.
There were other limitations that had been bothering me for some time.
It was time to modify bothe the arduino code and the node/js polling/database code.
The new version has the following capabilities:
Arduino
Now, the arduino is not configured stastically by the local code, but instead configures itse;f based on the incoming message
Support for all I/Omodes
It now uses JSON to receive and send data
It supports different read and write modes including average of 5 readings analog, digital pulse output and even specialty modes… one is coded to flip flop the direction of current for minimizing corrosion on buried probes
Node:
The communication is much more robust.
I’m using a transmit Queue to send requests
Supports multiple devices
Supports each pun being polled at a different frequency
Supports retries (30 second, 1.5 minutes then 2.5 minutes.
Manages transmit failures gracefully
Adds “UNIT” to the database for supporting multiple arduinos in the mix
Polling as frequent as 10 minutes and as slow as 30 minutes.
A rolling PAcket ID to avoid mis-identifying a failed packet .
Found a BIG bug that was not using the proper time in replicating the data to the web
Added the capability for each pin to have a unique function to run on the data. Currently used for scaling the returned value
Support for C and F sensors using the above.
Web
I added support for the 6 new sensors
The hard part?
Getting the Queue functioning right
So the code scans over each pin of each device and determines if it’s time to request the read or output. If it is, the details of the pin (pin number, type, Xbee address and other information are added to a transmit queue. A second process is looking at the Queue every 3 seconds to determine if any transmission needs to be performed. If so, it sends the JSON packet to the indicated device. If there is a transmission failure, the particular request’s next transmission request is postponed 30 seconds or one minute. If there is no failure, a request packet comes back in a few milliseconds. The returned packet is matched with a transmission request. The returned packet is added to the local database and the transmission request is removed from the queue. If after 4 tries and 2.5 minutes, if a given request is not received back, the packet is removed from the queue in order to not accumulate in the queue.