Anthony Aufdenkampe

@ldecicco, last autumn I started working on a somewhat similar task using the same radio module, but for posting to Azure EventHub.

As @srgdamiano mentioned, the key is to add HTTPS capabilities using the <span class=”lang:default decode:true crayon-inline “>TinyGsmClientSecure client(modem)</span> . Doing that worked for me and I was able to…[Read more]

<p class=”user-nicename”>@jamesbailey, I just noticed this post and have a quick answer to your  first problem regarding the EnviroDIY/TippingBucketRainCounter library.</p>
In April 2021, I issued the v0.2.0: Add Anemometer Counting and Bug Fix release, which not only fixed a byte-order bug in the original release, but also expanded event c…[Read more]

@ayalavinay, Monitor My Watershed has two APIs:

• An HTTP POST API designed for devices to submit data to MonitorMW, as documented here: https://github.com/ODM2/ODM2DataSharingPortal/blob/main/doc/example_rest_requests.md
• A Water One Flow (WOF) / WaterML API for scripts or apps to get data out of the MonitorMW database, as documented here:…

[Read more]

I’ll second Neil, and say that Keller sensor are very high quality and work really well with Mayfly RS485 integrations. I’ve helped deploy many AccuLevel sensors.

There’s a small chance that Keller 36XiW-CTD uses the same Modbus map as the Acculevel, but I think it is unlikely. You’ll need to get the Modbus documentation from Keller for that. I…[Read more]

The first explanation that pops to mind is that the DIY Modbus wing has power bleed from the digital pins when the power is turned off.

Modbus stop bits are high, which leaves the AltSoftSerial transmit pin (5 or 6) at 3.3V when the sensor power shuts down. This then bleeds through RS485 converter (when it is powered off) over to the switched…[Read more]

@neilh, we’re glad to have you doing the intensive testing, reporting what you find, and having patience with us over the years before we could dive in to this issues, and over these recent weeks and future months as we work out all the tech debt and also adjust to a growing data system (we have 400 million records!).

@neilh, we’ve been tracking your many issues in the last few days, including #542, and have been working on solutions. I just responded in detail here: https://github.com/ODM2/ODM2DataSharingPortal/issues/542#issuecomment-999785715

The short story is that we’re working hard to improve error handling (i.e. making it more accurate, rather than j…[Read more]

@lemon, we won’t be releasing that code until February, so I would encourage users to clear their cache before then. That said, you don’t have to clear the cache for all websites, but just do it for MonitorMyWatershed. That’s not that painful. Clearing it for all websites is somewhat painful, so would be clear in how you make the recommendation.

@neilh, do a hard reset of your browser cache our URL to get TSV working on Chrome. That is definitely the issue there. We’ll be adding “cache-busting” code in our next update.

We started the proxy forwarding about 45 minutes ago, so all data should now be rerouted from our old servers to the new servers on AWS.

Let us know how things look!

@mbarney and others,

After doing some research, we decided that shutting down our old servers for 30 minutes would not likely force the DNS on devices to refresh.

Our plan is to set up proxy forwarding on our LimnoTech server to instantly forward all data to the AWS servers. We plan to do that today, and will also set up a forwarding log to…[Read more]

@mbarny, that is very helpful to know that you have had success with power-cycling the stations. We’re seeing a few other sites switch over on their own in the last 24 hours.

@mbarney, wouldn’t that have been great if the Hologram pause worked! Thanks for trying it out!

Have you seen any of your sites start reporting again in the last 24 hours? The couple that I’ve been tracking have not, which is disappointing. I definitely recognize how painful it would be to manually power cycle these stations.

We’ll likely try to…[Read more]

Fortunately, we deployed to AWS region US-east-2 (Ohio) and it was the US-east-1 (Virgina) data center that went down, so our release yesterday was not affected by the AWS outage!

Unfortunately, we’ve seen two issues with caching mess up our otherwise smooth release:

1. Domain Name Service (DNS) caches are causing some devices to send data to our…

[Read more]

Hi All,

This is all related to a temporary data routing issue when we switched from LimnoTech servers to Amazon Web Services (AWS) servers yesterday with our MonitorMW v0.12 release. The data are not lost but rather still getting routed to our old servers because the Domain Name System (DNS) update that points our URLs to our new IP addresses is…[Read more]

@mbarney, @neilh20, thanks for pinging us.

As @heather mentioned, we released MonitorMW v0.12 yesterday at that time, which has some major under-the-hood improvements to substantially improve reliability, including now being hosted by AWS (zone: us-east-2; Ohio). For details read  our v0.12.0: Update to Python 3.8 & Django 2.2; Migrate to AWS…[Read more]

We think we’ve got it resolved (thanks @ptomasula!).

The main MMW site is back up and data looks to be flowing to the database server again.

We’re rebuilding the tsa_catalog now, so there might be some short term glitches with interactions to TSA capabilities and sparkline plots.

Unfortunately, some data was lost last night, before were able to…[Read more]