Systems not recognized from 12th( v0.15.0?)

Thanks for looking into it.

I’m in the UK for my Uncle who had a stroke, and I took off very quickly from California,  and not likely to get back before the end of May after his funeral. I haven’t brought any tools to see what the response are from the server.

It seems very unlikely that 5 systems would all stop transmitting by themselves. My three systems, for power saving, only transmit every two hours, and then they transmit 8 readings with 1second pacing between readings. So they would typically  attempted to transmit  2hours after the  last readings all successfully received. However if the server only responded with a 201 to the first of the  8 and then no response to the other 7- then technically in wall time terms they could be trying 3hrs 45min later.

https://github.com/ODM2/ODM2DataSharingPortal/issues/485

I have seen blocking issues that have come up in the past, and wonder what could cause them

https://github.com/ODM2/ODM2DataSharingPortal/issues/628

I  wonder if there has been further insight.?

It seems a real challenge to phrase how to have real world reliability. It seems to be such a hard concept to discuss and define how to get there. Its a standard Computer Engineering problem, and it typically requires a commitment to make it happen, and a reference model to test the implementation.

Well, I’m back at my desk, with a Mayfly and powered it up, and I’m posting to

Host: monitormywatershed.org

and getting

— Response Code — 301 waited  326 mS Timeout 8000

If I change it to

Host: data.envirodiy.org

— Response Code — 201 waited  577 mS Timeout 8000

From   https://github.com/ODM2/ODM2DataSharingPortal/issues/542

aufdenkampe commented on Dec 20, 2021

so, the main host URL that you should be using on devices is monitormywatershed.org. For a couple of years now, data.enviroDIY.org is just a DNS alias that will get redirected to monitormywatershed.org, even for POST requests from devices.

However it seems I got out on the “bleeding edge”  because somehow
https://github.com/EnviroDIY/ModularSensors/blob/master/src/publishers/EnviroDIYPublisher.cpp#L21

const char* EnviroDIYPublisher::enviroDIYHost       = “data.envirodiy.org”;

Also seems discussed here

https://github.com/ODM2/ODM2DataSharingPortal/issues/316

@aufdenkampe @heather @srgdamiano – just wondering where the source of truth is for this URL. ?
https://github.com/ODM2/ODM2DataSharingPortal/issues/658

Thanks to @ptomasula for fixing https://github.com/ODM2/ODM2DataSharingPortal/issues/658

If I understand it right, the internal redirection for  POST to MonitorMyWatershed.org/api/data-stream/ HTTP/1.1 got broken with the upgrade to v0.15.0, and a http response of 301 was returned, which ModularSensors doesn’t handle. Of course its not a good idea for ModularSensors to handle a redireciton, as its expensive in power.

Given the failure, and that my fork has built in reliability  https://github.com/neilh10/ModularSensors/wiki/1a-Feature-notes I’ve been monitoring the responses from 4 systems and characterizing the server after the upgrade.

I’m afraid the server seems to have degraded after this upgrade, I wonder if anybody else is seeing different results after the upgrade.?

I’ve put my results here https://github.com/ODM2/ODM2DataSharingPortal/issues/661

A previous reference is here https://github.com/ODM2/ODM2DataSharingPortal/issues/552

I’m happy to run this against a staging server if available.

Seems like this might have broken, and I’ve created an issue https://github.com/ODM2/ODM2DataSharingPortal/issues/682