mstenta / atmospi

Atmospheric monitoring app for logging and graphing temperatures and humidities over time using a Raspberry Pi and DS18B20, DHT11, DHT22, and AM2302 sensor(s).
31 stars 9 forks source link

Presentation enhancements #23

Open ultima-originem opened 9 years ago

ultima-originem commented 9 years ago

I've worked with the very useful Atmospi for almost a month now and over the last few weeks have tweaked the code in several places the make the presentation a better fit for my needs. Some of these tweaks may be of general interest whereas others may be just a personal preference.

The following screenshot from my current version lists a number of these items in arbitrary order [i.e. no priority implied]. The text is mostly in Dutch but that shouldn't pose a problem for reading the annotations.

screenshot

The use case is the monitoring and tweaking of a radiant floor heating system.

  1. Summary location and format: with currently 9 sensors, the summary needs to be as compact as possible. I made the following changes:
    • moved the summary to the right to allow right-justified values
    • reduced the font size
    • removed the capture time as this is already shown in the title
    • limited the number of decimal places to 1
    • Ideally the sort order should be the same as the [forced] index sort order and in case there are more than e.g. 4 sensors, a more compact, table format could be used. This would use up less vertical space.
  2. Chart title: I simplified the chart title to save more space and added the capture time
  3. Range selector: I added 1h, 2h, 3h and 6h to the range selector
  4. Export: the file index.html was modified to automatically show the export button with support for various formats by adding Highcharts "exporting.js" module. Unfortunately the standard export orientation is "portrait" which is unsuitable for my purpose. I have not been able to change this.
  5. Plot band: a plot band was added to show a temperature range.
  6. Y axis: the y-axis title was removed because every grid line already shows the fact that the data is a temperature; in my case in degrees Celsius.
  7. Line color: with 9 sensors it's a bit of a challenge to obtain a legible chart. I have set each sensor's color and opacity individually for improved legibility and semantics [red = hot].
  8. The use of areaspline: areasplines are used for a few sensors for the same reasons as in item 7.
  9. Legend: the legend is sorted by a user defined order, again for improved legibility and semantics.

Hopefully this annotated example will inspire some enhancements.

mstenta commented 9 years ago

Thanks this is great! I have a few thoughts... I will organize my ideas and comment here later...

mstenta commented 9 years ago

Responses:

  1. My original intention for styling it as I did was to make it readable on my phone. I use Atmospi to monitor temperatures on my property (different places inside and outside), and I rely on it being mobile-friendly. That said, there are certainly things that can be improved... the graph actually doesn't work great on mobile (a little too finicky with touches).
  2. The tricky thing with the "capture time" is that sometimes the sensors stop working... and sometimes some stop working but others keep working... that's why I put the capture time next to each in the summary - to more easily debug when a sensor needed a kick.
  3. I like this, can you put together a patch?
  4. I haven't tried this... maybe another good candidate for a patch?
  5. This might be a nice feature to have... define bands in settings.py (or in a new database table as it expands). Currently I have a band that represents freezing temperature (below 32 F / 0 C). We could move that into the same standardized system and allow more to be added easily.
  6. Atmospi can also be used for Humidity sensors... so we need to keep the Y-Axis titles to differentiate Temperature and Humidity. Or maybe it makes sense to split them into separate graphs... especially when we add the "relay/switch" sensor support like you requested in #24
  7. I like this, let's continue discussion in #20
  8. Similarly, let's discuss in #20
  9. We started discussing this in #20 but maybe it needs it's own issue...
ultima-originem commented 9 years ago

My comments:

  1. I'm using a 24" display and find that even on an iPad there's too much information to display. I think there should be a completely separate mobile interface.
  2. Agree. Perhaps a separate warning when one or more sensors are out of sync?
  3. I'm not sure how a patch should be presented but this is how I solved it:

       rangeSelector: {
           enabled: true,
           buttons: [{
               type: 'hour',
               count: 1,
               text: '1h'
           }, {
               type: 'hour',
               count: 2,
               text: '2h'
           }, {
               type: 'hour',
               count: 3,
               text: '3h'
           }, {
               type: 'hour',
               count: 6,
               text: '6h'
           }, {
               type: 'day',
               count: 1,
               text: '1d'
           }, {
               type: 'week',
               count: 1,
               text: '1w'
           }, {
               type: 'month',
               count: 1,
               text: '1m'
           }, {
               type: 'month',
               count: 6,
               text: '6m'
           }, {
               type: 'year',
               count: 1,
               text: '1y'
           }, {
               type: 'all',
               text: 'all'
  4. Here's the applicable index.html. Please note that I don't have a solution for landscape printing although I understand from researching this topic that it should be possible.

<<< NEED SOME HELP HERE AS COPYING HTML GETS RENDERED INSTEAD OF LISTED>>>

  1. Agree; that's exactly why I used it.
  2. Agreed. I also ran into the need to have multiple charts to reduce complexity [too many lines]. This needs additional thought on how to specify this functionality. Multiple synchronized charts are probably required in complex situations.
  3. OK
  4. OK
  5. OK