If you think about the upcoming gateway and Ruuvi Network cloud service, which features you value most and what would be the preferred values? Please think this from the normal consumer use case perspective (businesses have usually a bit different needs).
What is you main use case for the remote monitoring (possible to see current sensors values, alert features, data history)?
Sensor update interval to the cloud (how often data is stored and possible to retrieve to RuuviStation app)?
Should there be web interface for checking long history data and what features web ui should have?
Cloud history length (how long history should be stored)?
Alert method (push / email / SMS) and how fast alerts should be from the event?
Most of the uses cases I consider are available on the RuuviStation app on an individual RuuviTag basis for short term observations and alerts.
However, it is unreasonable to expect any user to have their mobile online all the time. Using the gateway and having ruuviStation pull that data helps significantly but for more that just a few Ruuvitags the small form factor of the mobile is not sufficient.
The excellent RuuviDiscovery server and client system by Balda at GitHub - balda/ruuvitag-discovery: Web interface to Discover RuuviTag Environmental Sensors and save measures to MQTT, InfluxDB, Graphite and Home Assistant provides a view of the entire fleet of RuuviTags (small or large). One of the exceptional things about that system is it’s ability to be tailored by the user. Whenever I disagree with a member of my staff regarding what should be limited, presented or how etc, I have always found that providing an option provides the best solution. Unfortunately the setup is awkward for an end user and it has no historical data or charting.
A web browser interface is always the easiest for the end user as it mitigates the need to install a myriad of prerequsits they do not have or are not available on their platform. From a central site perspective using a web server also allows using log files and cookies to determine the audience, frequency of interaction (including lack of use) and additional marketing opt unities. Incorrect authorization issues as well as network problems (for example partial downloads) can be apparent. The ability to replace the web components for all or even for some users is more easily implemented and controlled by a web application. Updates can be implemented without the user needing to choose to install them now or delay until whenever.
Different users have different needs even varying among various RuuviTags with regard to updating the repository. It is best to leave it up the the user to specify the best interval for each tag. Some of mine need to be updated every few minutes to provide alerts or trends but others only need to report several times per hour. Then there is the worst case where the equipment being monitor is idle most of the time , even hours. The start time may require minute resolution to coordinate with other events. Once it becomes active a finer grain observation period is needed to collect data about its activity and determine when it once again becomes inactive. Consider door monitoring, Air-conditioning and refrigeration or heating monitoring.
No package can hope to provide every use case. One of the most important features is the ability to retrieve data so it can be saved at the users discretion and processed however they need to.
Main use cases in priority order 1. Trigger alarm to my phone 2. See history for learning about measured environment.
Senson update need to be set by user, one by one or in a mass.
Web UI is only solution. It should have one page for configuration, one for dashboard.
History should be one month, and if longer needed user pays for it or storing locally
Alert method should push type and preferably free web message like Telegram
