Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, a web toolkit designed to help citizens, conservation practitioners, municipal decision-makers, researchers, educators, and students advance knowledge and stewardship of fresh water. New to EnviroDIY? Start here

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

Home Forums Monitor My Watershed Systems not recognized from 12th( v0.15.0?)

Viewing 7 reply threads
  • Author
    Posts
    • #17738
      neilh20
      Participant

        Just wondering if anybody seeing MMW not showing systems

        There is one station working fine, over cellnet https://monitormywatershed.org/sites/TUCA-Na13/

        And three systems not reporting

        https://monitormywatershed.org/sites/TUCA_Sa01/ last update <span class=”last-observation”>April 12, 2023, 5 a.m. (UTC-08:00)</span>

        https://monitormywatershed.org/sites/TUCA_PO03/ last update at <span class=”last-observation”>April 12, 2023, 5:45 a.m. (UTC-08:00)</span>

        https://monitormywatershed.org/sites/nh_LCC45/ last update at <span class=”last-observation”>April 12, 2023, 6:30 a.m. (UTC-08:00)</span>

        I’m away from my office/test systems to be able to do a check with other systems and see the POST response from MMW.

        thanks

      • #17740
        Heather Brooks
        Keymaster

          Thanks for reporting. I’ve verified that your sites are still not updating and notified the Monitor My Watershed development team. I’ll let you know when I hear back.

        • #17741
          Anthony Aufdenkampe
          Participant

            @neilh20, We just looked at the database and the server logs and found the following.
            Only 5 sampling features stopped reporting new data on April 12.

            • TUCA_PO03
            • nh_LCC45
            • TIMU01
            • TUCA_Sa01
            • DEADFALL_ELC-6

            These stations have not attempted to post anything in the last 30 minutes.  We’ll keep looking.

            Our guess is that the issue is originating from these stations, not from a bug on our servers.

            We are indeed confused why they stopped reporting the same morning that we issued the release. That said, many of these stopped reporting a couple of hours BEFORE we switched the production servers, which according to our logging happened from 10:34 to 10:38 ET  ( = 7:34 to 7:38 PT).

          • #17742
            neilh20
            Participant

              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

               

               

            • #17767
              neilh20
              Participant

                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.

              • #17823
                neilh20
                Participant

                  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

                • #17852
                  neilh20
                  Participant

                    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.

                  • #18172
                    neilh20
                    Participant

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

                  Viewing 7 reply threads
                  • You must be logged in to reply to this topic.