Ambient Weather Rain Gauge New Feature

 One problem I have had with the Ambient Weather system in the past was the lag time from the start of a rain shower until I actually saw any indication on my system that it was accumulating. The reason for this was that the weather station had to register a count, which got sent to the console about every 16 seconds. The console then would send this info to the Ambientweather.net system online once a minute at the most. Then my system had to get this info from the online account about once a minute before I would see the it was raining on my rain gauge display. The total delay could be as much as two to three minutes.

I found that the console recently had a feature added by which it could send data immediately after getting it from the outside system and send it to a local http client. I worked on getting this to work for me for some time. At first, I tried to get it to send to my Windows computer but was unable to get an app on the computer to collect this data. I then tried to get the data sent to an Arduino set up as an http server and it took a lot of work before I was finally able to get this to work.

This was great but I had a lot of trouble getting the address programmed into the console. Then I had trouble keeping the console connected to my local router. It seems they have trouble with 5ghz systems or mesh routers that provide both 5G and 2.4G signals. When it did work, it would average about 24 seconds to get the rain data, because many of the transfers took 31 seconds instead of 16.

With a little digging, I found a radio receiver that was supposed to work on the 915Mhz band the console worked on and I would be able to intercept the signal straight from the outside device. It took a lot of work, first to get the radio attached to the correct data ports on the ESP32 device I was using. Then I had to get the device to recognize the data packets and reject all of the extra noise the radio was picking up.

Slowly I was able to get the radio working reliably and get a steady flow of data. However, I found that the outside device only sent a count of tips of the rain sensor and that the console was keeping the totals. I had to develop code to read the data and convert it into a rain rate. That signal was more close to the 16 second rate that was supposed to come from the console. I worked this device into my overall system with my wall rain gauge display and my watch rain gauge.

I had used MQTT for a lot of the intra-device communications but with this new device, I switched over to using HTTP for data transfers within my home system, only using MQTT when I traveled with my phone and my watch. Since I'm using a free, serverless service from HiveMQ, I am limited in the number of bytes of data I can move so I have cut that way back.

Now, if a rain storm starts, I get a notification within less than a minute. I also cut back the rate calculations from the standard 10 minute average that AW uses to only 5 minutes. The rain storms we get here in Florida are usually on and off within minutes and taking 10 minutes after the rain has stopped for the rate to drop to zero was too long. I also changed the alarm to only come on when the rate exceeds 0.1 inch per hour. Little drizzles were turning it on and off too much.

Ambient Weather Rain Gauge

About 8 years ago, I bought an Ambient Weather weather station so that I could monitor the weather at my home while I was away. I have had it set up at three different homes in the same area since then and it has worked very well for me. It collects the information and then sends it to the "cloud" once a minute. I can then look on their website and see the current and historical information. I have loved this, especially when we have had some significant weather events, like a glancing blow from a hurricane (direct hits mess with the power and internet access, so data is lost then. 

 Although the device gives me this data on their website, I decided I wanted the current data in a different format on my phone where it would all be on one dashboard. The data can be queried through an API they provide and I have become well versed in writing Java apps for my Android device over many years, so this was easy for me to do. In the past year, I realized the weather event I was most interested was rainfall. The device measures it well and keeps charts and graphs of events over a one month period and less detailed information over a year. I wanted to have up-to-date rain information at a glance in my home, so I created a rain gauge app to work on an Android tablet and placed that on the wall. It alarms when rain starts and ends so I am alerted to the changing weather outside. 

 Since the rainfall totals accumulated only extend to the month, I also wanted to keep yearly and (meteorological) seasonal totals. To do this, I created an app for my Windows laptop that would store the historic data by day, week, month, year and season in a file. It could then distribute this information via messaging (MQTT) to the tablet gauge so all of this info is available at a glance. 

 As I am always looking for a new programming challenge, I decided to see if I could get this information to an even closer, personal device; my watch. I've had several Android smart watches over the years, but I've never tried putting an app of my own on them. Android Studio, which is my programming platform, has Wear OS capabilities. So I created an app and started working on what I wanted it to do. 

 When I started, I discovered that Java is not the programming language that is desired for Wear OS apps, rather Kotlin. I had not programmed in Kotlin before, so I had to do some studying on the differences between Kotlin and Java. As it turns out, Android Studio is very good at helping out with syntax and coding. I was able to import modules I had already composed in Java and convert them to Kotlin. Except for small changes I had to make, this was very simple.

Android Studio was also able to create companion Wear and Mobile apps, something needed to get the watch and phone to communicate with each other. I was then able to create a Rain Gauge App for my watch that displayed all the same info as the wall rain gauge.

As I was doing this, I discovered another aspect of smart watches I had not encountered; complications. Although it sounds daunting by its name, these are areas of the watch face that contain information other than the time. They can have pictures, text, and range data. I realized that I could go one step further with my personalization of the rain data by putting it right on the watch face. Android Studio heled me a lot with this coding as well. Soon I had the data right there to see at a glance. Also, tapping on the complication info brings the entire rain gauge app to the display.

I can get notifications on my phone when it starts or stops raining, notifications if one of the data feeds stops sending in data, and even, something I have had trouble with, a notification when my watch battery is running down. Although the watch is supposed to do this itself, it has only worked sporadically at best.

This has been a real adventure in programming for me and I can't wait until the next feature I decide to add.