Problems with the current approach:
- Redundant weather data - Data plan usage can be greatly reduced.
- Be able to rebuild the local database on the hive computer from the public webserver in case of theft or computer failure.
- Be able to send the hive parameters on the local hive to the public database when they are changed locally, and the opposite:
- Be able to send the hive parameters on the public database to the local hive when they are changed in the public database on the public web server. (This allows changing hive parameters and calibration without going in the remote yard or opening a port for access.)
- Add apiary table. Hives can be moved and tracked between apiaries
- Add comment table and UI for beekeeper notes to explain manipulation changes (adding or removing equipment) that affect weight..
- Add weather station data table (linked to apiary, not hive).
- Don't upload weather station data from the hive to the server, instead let the server fetch it.
- Add transactional methods and capture all hive parameters each time they change.
- Enforce foreign key constraints
- Simplify raw data table and do no data conversion on it during input.
- Separate data collection and analysis/visualization to be able to handle as many hives as possible. Periodically (daily, hourly, 5 minutes?) transfer the raw data to the data warehouse and convert raw data table to other tables (metric, imperial, filtered, delta, daily) for viewing.