As the title says... Chat on...

User avatar
By ukslim
#62308 Hi - I'm new to the board, let me know if I'm failing on any etiquette :)

I've been reading the docs for rtctime, rtcfifo etc. and I assume plenty of people have used them to create devices that push sensor data to a collector. I wondered whether there's an established best pattern.

I've already got it periodically writing one reading to a collector (over HTTP, but that's an implementation detail). Now I'd like it to recover if the collector isn't available.

My guess is (LUA-like pseudocode -- for brevity I've pretended everything is synchronous -- assume the real thing would be callback-oriented):

Code: Select all
-- on boot
wifi init
sntp.sync()
if not rcfifo.read() then
     rtcfifo.prepare()
end

rtcfifo.put(rtctime.get(), readsensor(), 0, "temp")

while rcfifo.peek() do
     if not write_to_collector(rtcfifo.peek()) then
          break
     end
     rtcfifo.pop()
end

rtctime.dsleep(sleepTime)


Is that basically it, or is there something I've missed? Or a neater way (perhaps avoiding using both "peek" and "pop").

Are any of you sharing the code for a working sensor project that uses this?
User avatar
By marcelstoer
#62344 I have less than pseudo code to offer.

Basically the intended flow with the rtcfifo is:

  • On boot, check if rtcfifo.ready() and if it isn't, initialise.
  • Check whether there is space available in the rtcfifo, probably by rtcfifo.peek(max_fifo_idx).
  • If there is space, take a sample and rtcfifo.put() it, then go back to sleep.
  • Otherwise,
    • Connect the WiFi
    • Start streaming or bulk uploading by rtcfifo.peek()ing, and once confirmed as uploaded by the server, rtcfifo.pop()ing those particular entries.
    • Handle upload errors however you want, maybe just by going back to sleep and starting from the top here again. Maybe you want to throw out the oldest entry before doing so. All application dependent.
    • Repeat...
User avatar
By ukslim
#62633 OK, great. Thanks.

So in your intended flow, the idea is to reduce network use by buffering up lots of readings into the FIFO, and dumping a batch to the sink when appropriate.

Eventually I want my sink to be making near-real-time decisions based on the readings, so I want readings to be transmitted immediately if the service is available -- but to be cached in the FIFO if it cannot be reached.

Looking again at mine, it handles the sink being unavailable, but doesn't consider the possibility of NTP or wifi being unavailable. So I'll have to tweak the logic a bit, but it's nice to know the basics are sound.