In completing #1 and getting more familiar with the data from the API, I can see that null values appear to be relatively frequent. Because I am using structs and strict data types, the compiler really doesn't like it when there are null values. So I do need to sort that out and manage null values.

This is core functionality.

A configuration file is necessary to allow a user to save sensitive MQTT broker details and optionally username and passwords.

This file will also allow us to facilitate allowing a user to specify what data, from the data available in the API, a user wants. A user may want all of the data, a subset or even just one piece.

This was due to the weather source used to develop the initial program. It had null values for wind gusts. However when a location that is providing the full data is available, it is not parsing properly due to the design of the structs. So need to design structs for full data then handle errors when null values are in the hierarchy.

This should tidy up the code in the get_weather() function and possibly allow for better concurrency. This may be too early of a time to work on this sort of optimisation. It is likely better to increase basic functioning and features first.

Currently, all code is in the main.rs file. However it is currently in it's own function so moving should be trivial. This will be an important step to facilitate unit testing later as this cannot be done in the main.rs file.

This is core functionality.

~~To do this, we'll also need a seperate configuration file to set broker details.~~ This is done, in #4

We'll also need to determine topic naming conventions.

Data should probably also be published with one data point to one topic rather than have one MQTT payload with all data in one json message. This will allow for easier later saving of MQTT messages into a database.

This is core functionality.

Saving the desired data into variables will allow for later error handling and prepare the data for publishing via MQTT messages.

This could be individual variables or perhaps it will be best to use a Struct.

This is core functionality.

The program needs to be able to GET the weather data from the BOM API, parse the returned json and have it ready for subsequent processing.

RusQTTbom currently has hard coded bounds for what a valid temperature value looks like. These are as follows:

• min -20
• max 50

In colder areas of Australia (noting the BOM weather only covers Australia), there may be valid colder days than -20. Likewise, some areas may want to increase the lower bound as the temperate never even gets to freezing.

This is a minor extra data validation step ensuring only as correct data as possible is being published.

Initially, the RusQTTbom program has hard coded MQTT topics. A user should be able to decide on the structure and naming of the MQTT topics.

This functionality will likely be provided as options in a configuration file.

This issue is related to the issue to provide user configuration of weather data (#7).

At the moment, users need to grab the geohash from the BOM website. However it would be better, and it is possible, do simply write in your location in the config.toml file that use an API call to grab the geohash. This would be much simpler and more streamlined from a user perspective.

So far, the program only gets the current weather observations. It makes sense to also want weather forecasts for at least the current day. This data is from a different endpoint though same overall API URL. This makes sense to start after the code refactoring is complete as at #10 as this will consist of a larger function as there are many more data points when considering the data is for multiple days.

Initially, there are no user configurable options to decide what weather data is wanted.

A user should be able to select what weather data is collected from the BOM API.

This feature will likely be implemented via a configuration file where options are provided.

This will likely need to tie in with the MQTT topics configuration (#5).