Reply To: Coding to send data from a non-Mayfly logger

@oakleynode something to note is that the MMW/ODM2 packet design with UUIDs make an extra heavy packet. The packet design is not optimally designed for wireless conditions, the thingspeak packets are

@oakleynode something to note is that the MMW/ODM2 packet design with UUIDs make an extra heavy packet. The packet design is not optimally designed for wireless conditions, the thingspeak packets are much lighter. If your site is on the edge of the wireless range,  which varies a lot of with weather conditions, its going to have more trouble with the MMW UUID overheads. A site that I have on the very edge of wireless connectivity is https://monitormywatershed.org/sites/TUCA_GV01/.  I implement a sequence number in all my packets to be able to easily characterize reliability. I have been upgrading the antenna on the site to be able to improve the wireless signal strength.

I’ve found  the server is pretty exacting, and the error responses are wip. In addition due to some undocumented compression routines on the server, if the POST timestamp is too old, and that region of the database its going to insert into is compressed,  it then initiates an uncompres for that region and that can take an undefined  looong, time . Which can the client POSTer to define a times-out.

 

I’m an advocate of reliability for ModularSensors,   – and that also has meant characterizing the server, and in the process of testing my devices I’m finding server issues, one example   https://github.com/ODM2/ODM2DataSharingPortal/issues/685

My reliability enhancements  can do multiples POSTs per connection . Over a celluar connection (with 9600bard to the modem) the first POST has had responses of ~ 2.5sec, and subsequent ones 10seconds. However the server is not set up to take too many serial POSTs.  Discussion https://github.com/ODM2/ODM2DataSharingPortal/issues/673#issuecomment-1692514992

For the ODM example,  seems to me it is missing the “Content-Length: ”

The best documentation is the code.

https://github.com/EnviroDIY/ModularSensors/blob/master/src/publishers/EnviroDIYPublisher.cpp

I got the POST working on a Wio Terminal device (WiFi), but I needed to get wire-shark out to be able to sniff the packet to see exactly what the WioT device driver was outputting.

Here is an example of a trace from the transmitting device that succeeded (with a couple of changes to UUIDs so this won’t work)

POST /api/data-stream/ HTTP/1.1
Host: data.envirodiy.org
TOKEN: d9e65186-6cf6-4803-xxxx-4d9b1142bd48
Content-Length: 508
Content-Type: application/json

{“sampling_feature”:”851d0f00-3d8b-41c7-xxxx-40cb86b9ad2c”,”timestamp”:”2023-10-27T16:04:49-08:00″,”740cc4f8-6bc5-471a-811c-e0977f286f51″:3,”1f239d16-e6e4-4f76-ae98-0b274c75c79e”:48.04,”5ab3af01-bf49-4187-893d-276d7d256cd7″:17.93,”fd4e9448-8f67-4b5b-bd73-630b0659af8b”:17.1875,”586f9006-261b-4c5a-8abe-c93d5ec799fe”:17.8750,”87e166b4-0810-424f-bcd1-bbfaf9bda24d”:17.5625,”f10be729-b2d0-48ba-9c30-912274985b83″:17.7500,”27d7e570-7ef1-4ab5-af94-dfef2eeb19c1″:4.101,”66b0642a-d8c9-4e25-9a8f-39e081c188fc”:6.557}

and in this case over WiFi the response is faster

— Response Code — 201 waited 632 mS Timeout 10000

regards

Less...