Without looking at the code I’d guess that you just need to let it run for the week and accumulate the additional data.
I had noticed it after 4 days so I made sure I had left it a week before reporting.
I know it has been running for over a week as I can get the 'hourly' stats to show a weeks worth of data.
Once you set the value to 2000, it should start collecting more data in the 5m file by not removing older records until it reaches the new limit.
I'll take a look at this, maybe something is broken. Thanks for reporting!
Released version 1.4.1 with the following small fix:
Fixed
- Fix "Max records with 5 min accuracy" settings - @bobbles
Pretty sure this is fixed as the 5m file is now increasing in size. The oldest day/time is remaining the same at present as it hasn't reached the 7 day cut off yet.
Thanks again.
Released version 1.5.0 with the following changes:
Added
- Add support for null (-) values in CSV files
- Mark some attributes values as null when the device also has a "switch" attribute with value "off" (see reasoning below)
- Add attributes support: Alarm/alarm, CarbonMonoxideDetector/carbonMonoxide, Chime/status, AudioVolume/volume, SwitchLevel/level, UltravioletIndex/ultravioletIndex
Certain mains-powered devices, such as light bulbs or air purifiers, can be turned off. While these devices are off, the values of other attributes remain unchanged, which can lead to invalid data being recorded. To prevent this, the following attributes will be recorded as null when the device has a switch attribute set to off:
Standard attributes:
- airQualityIndex (0-500)
- amperage (A)
- carbonDioxide (ppm)
- humidity (%)
- illuminance (lx)
- level (%)
- pH (pH)
- power (W)
- rate (LPM)
- temperature (°C or °F)
- ultravioletIndex
Custom attributes:
- cloudiness (%)
- pm10 (μg/m3)
- pm25 (μg/m3)
- vocIndex
- windDirection (°)
- windGust (km/h or mph)
- windSpeed (km/h or mph)
Note: Currently, to start monitoring any of the newly added attributes on already configured devices, you must first remove the device. Unfortunately, this will result in the loss of all previously collected data stored in CSV files. Sorry for the hassle!
@jpcurcio I chose option #3 for the level attribute. The aggregated values (1h, 1d, and 1w) will now reflect the average brightness (%) of the light, but only while it was turned on.
Have fun!
This is fantastic!!! A few comments/notes:
- When picking the "max" values for storing in 5m, 1w, 1d, etc... it's hard to know what is too much, or what happens if we screw up and pick something too large. Is it possible to show some kind of real data about "with the devices you have, you have THIS MUCH room left as configured" or something?
- I don't totally follow if I can include a dashboard in the standard hubitat dashboard or not - or how I would get to it from my phone, is that URL stable and always available inside the network basically for each dash?
- I have a tempest weatherstation, and some of the fields I would want included aren't (namely, dewpoint temperature as the main one). Anything I did wrong there? I also recognized that some other dewpoint virtual points (calculated) that I created are showing up as temperature, so maybe each device can only have one "temperature" standard attribute I'm guessing by design. In that case, would I need to somehow send the Tempest dewpoint to a virtual device that can then be added here? (not that I know how to do that, lol!).
- The Min/Max saving in the reduced data points (1h, 1d, 1w) is a huge benefit - so it can save AVG, MIN, and MAX for each point. I +1 that!
- In the future, are you envisioning any way to somehow save past data off of the hub or something? For example, I would denote a simple folder on my windows network share and would love to have full resolution data still live there in perpetuity (5m). Some simple solution like that would ensure we don't lose anything for offline use later, but everything we need is still local for example.
Thanks!!!
I'm betting that a very popular graph type -- although I'll be dogged if I can think how one would go about representing such a concept -- is "Uptime" in the sense of how online services like healthchecks.io do it (e.g. regular pings from subscribing IoT devices, sites, servers, etc.).
Of course, a bunch of us use those "external" providers to monitor our hubs online/offline behavior (powerline, connectivity) remotely, but for everything else, an app like Watchtower (using Local and/or Cloud endpoints) perhaps could accomplish much the same function?
Talking timestamps and actual (reported) "Up" or (inferred based on time lapsed) "Down" states -- sometimes a third state, but hey, configurably more? -- as datapoints; e.g.:
Kudos on such a gorgeous piece of code and documentation!
I am monitoring the temperature in the kitchen freezer and am seeing the following log entries. Can I turn them off?
Graphing seems to be working ok it just the warnings in the logs.
Thanks
Storing the data files should not be problem, since we have 1GB of space in File Manager, and the max size needed for a device is fixed to around 70KB (with the default settings).
The problem might come from processing these data files. Every 5 minutes, for every configured device, the app loads the contents of the wt_${device_id}_5m.csv
file into RAM as as string, then splits the string by the newline character (to identify lines), adds a new line at the end, removes the first line, and finally stored the data back to the file. To be honest, I have no idea if the hub considers this as a light or heavy task. Folks can play with the settings and report if the app puts a strain on their hubs.
The default "max" values are chosen somewhat random: I thought what would be good enough for my usage and went with that I am willing to change the defaults, if more people find them not good enough.
As a side node, I don't find the 1-week averages particularly useful, so I am thinking to remove them altogether.
The Watchtower dashboard URLs are stable, if you don't rename the dashboards. You can bookmark them on your phone and it will work if the phone is on the local Wi-Fi/LAN.
I was able to make the dashboards also work through the Hubitat cloud, so it is technically possible; but all data files, although small is size, must go through the Hubitat servers and the staff might not like it, so I did not enable this feature.
You can include Watchtower dashboards as iframes in the standard Hubitat dashboard using a virtual Tile iFrame Device. See this great comment here for more details:
We already touched this topic in a post above; I cannot add all custom attributes for all custom drivers since there is no standardization in place. Weather drivers use dew_point, dewpoint, dewPoint, etc. I can add "dewPoint", since it follows the same naming convention as some other attributes I already added, but I think this will not help you very much. Sorry.
You can either edit the app source code (top of the file) and apply your patch on every app update; or you can create a Virtual Temperature Device and sync it's "temperature" attribute with the "dewpoint" attribute from your driver (using an automation rule).
This is still in the "feature request" state, so not implemented yet. It's on my to do list, though.
You can fetch the data from the hub (http://${hub_ip})/local/wt_${device_id}_5m.csv
) from your external storage system. If you schedule this fetch process to run once every 3 days, you can just append the newly fetched data to the old data and create a really big csv file on the external storage that will contain all data points.
If you want to monitor external IPs/URLs using the hub as the monitoring device (e.g. to monitor Wi-FI/LAN devices) and chart their "uptime", I believe it's pretty straightforward to create a custom driver that pings the configured target every 5 minutes and updates the value of an attribute accordingly (I would use the "networkStatus" attribute of the Telnet capability for this).
Once you have this in place, it's really easy to add this device to Watchtower and visualize its uptime status (hourly, daily, weekly uptime %).
Sorry about that. There was a bug in the app that calculated negative values for % attributes and I added that warn line for debugging purposes. I will remove it in the next release; thanks for reporting!
Excellent point and IMO this is why they pay you the big bucks; I completely overlooked several existing community apps that do Ping in one form or another, so thanks for the reminder!
Released version 2.0.0 with the following changes:
Added
- Add support for aggregated min/max values
Changed
- Remove bar chart rendering when fewer datapoints are available
- Null values in CSV files are now saved as empty strings instead of using dashes (
-
)
Handling of Min/Max Values
For certain attributes, such as temperature and humidity, storing only the 1-hour, 1-day, or 1-week averages may not provide a complete picture. Therefore, the application also automatically records the minimum and maximum values for these intervals in the CSV files.
These min/max values can be visualized in a chart using the Device tile. When adding this type of tile, if a supported device attribute is selected, the “Chart attribute min/max” option becomes available:
Once the chart is rendered, the min/max values are displayed:
In the example above (1-hour time resolution):
- The top tile displays the min/max values for both temperature and humidity.
- The middle tile displays the min/max values only for temperature.
- The bottom tile displays temperature and humidity without the min/max values.
Note: Min/max values are charted only when the 1-hour, 1-day, or 1-week time resolutions are selected. So you need to let the application collect more datapoints (including the min/max values) in the following days if you want to see min/max in the charts.
You also need to delete and re-add the Device tiles and select the new “Chart attribute min/max” option, since this is not enabled by default.
Have fun!
@dandanache,
Just wondering if I need to be concerned about the errors below:
Unfortunately this looks serious, no data is being aggregated for those 4 devices.
Please download the 5 minute csv files from Settings -> File Manager and see if you can spot something wrong with the data, especially the last records. Files that you need to look into are: wt_4221_5m.csv
, wt_3923_5m.csv
, wt_3957_5m.csv
, and wt_4224_5m.csv
.
Please let me know what you find, it's very possible you found a bug.
I've checked the dehumidifier (wt_4224_5m), and I can see that only 1 timestamp was recorded in the csv file today when the dehumidifier was on, although there are 4 readings on the graph?
Strangely, zero power readings seems to be blank instead of zero.
timestamp energy power
1727621100 | 0 | |
---|---|---|
1727621400 | 0 | |
1727621700 | 0 | |
1727622000 | 0 | 159.75 |
1727622300 | 0 | 167 |
1727622600 | 0 | 171.5 |
1727622900 | 0.04 | 165.33 |
1727623200 | 0 | |
1727623500 | 0 | |
1727623800 | 0 | |
1727624100 | 0 |
Is there a "switch" attribute on this device? If this is the case, then blanks are recorded when switch is "off". But this is normal behavior, should not be a problem.
I'll investigate further when I get a bit of time. Can you please also provide (here or PM) the contents of the other 3 files?
@dandanache,
Thanks for the quick fix, I can confirm that I did not receive the error at XX:00 after updating to v2.0.1
Released patch version 2.0.1 with the following small fix:
Fixed
- Fix
IndexOutOfBoundsException
when the last value on a record line is null (empty string) - @iEnam
A big thank you to @iEnam for providing the data files to spot the problem.
TIL that, in Java, "0,,1,".split(",")
returns an array with only 3 elements ["0", "", "1"]
instead of 4, as I expected.
Have fun!