Monitoring on Pi Zero W with multiple RuuviTags

That witty2 device looks good, especially with its apparently very low power consumption.
At the moment the 5w solar panel I have cant cut it but thats with the Rpi running 24/7 but without a cellular hat working too- thats still on order.
I think its going to be the power consumption and hence battery/charger setup thats going to be the limiting factor for my setup and use.

This is actually one of the reasons why I chose InfluxDB as my database. As of right now, I have over 70 million unique measurements (ie. a packet from a tag, including all “extra” data such as tag name, mac, calculated values, RSSI…) saved, which means a few billion values (a value is ie. temperature or humidity), which consume less than 7GB of storage space right now.

This is from 8+ tags collected in the past 2+ years with 5-10s transmission intervals. The efficient delta-compression algorithm (among other things) is what makes this kind of space efficiency possible in InfluxDB (and most other time-series databases).

However, on very large scale deployments (hundreds or thousands of tags potentially transmitting even more frequently) even this may be too much, in which case it would be smart to create aggregations of the history data (ie. over a month old data) and drop the single measurements of these “older measurements”, keeping only ie. “hourly averages” or whatever happens to be sufficient for the use-case.

As my setup is this small, I don’t have a need for this and thus I still keep every single measurement as-is. :slight_smile:

Thanks for the contribution @Scrin. Learning new things every day!

On this subject, I see mongodb has some examples on how to setup time-series schemas to store data more efficiently and economically…

I should’ve created a new topic on this instead of hijacking this thread - sorry everyone… :grin:

Sorry scrin I just dont get what I can possibly get from being able to recall thousands of bits of data that seldom changes and when it does I only find out about it after the event.
Seems to me its more a case if doing it because its possible rather than useful.
If it was set up to monitor and only report changes outside preset limits, now that is more useful IMHO.

Has anyone managed to get the Chronograf alert system in Kapacitor working?

Well, in my case it’s more about avoiding the unnecessary effort, I could save maybe a gigabyte per year or so by saving less values, but it’s definitely not worth the time in my case. And like I said, in very large setups the savings may become worth it, in which case it’s relatively easy to set different retention policies and automatic aggregation of historic data.

Also, in my personal opinion, there is no need to over-complicate things by optimizing storing of the values if the used space is not an issue with the current setup, kinda like the saying “if it ain’t broken, don’t fix it” :slight_smile:

OK understood.

I have been working on getting the wittyPi hat running on a Rpi3B with dgermans Collector.Influx.Chronograf image.
It works and the on.off sequence can be chosen just by making a text file.
One thing that odd though.
On installing I got the required files in the correct folder but also others with a symbol and ‘35’ in front.
See below, anyone know what these are, before I rename them? :-/

What you’re seeing is the terminal screen attribute codes not part of the name of the file.
Seems to be a configuration issue with LX Terminal

Not just 35 but 1B 01; 35m
That’s an escape character ( 0x1B) " Set Graphics Rendition" (‘m’) to magenta(35).

PS using x-org (i.e. windows ) takes more memory and makes the system slow to respond. I recommend ssh instead.

See http://real-world-systems.com/docs/ANSIcode.html

OK so do I need to do anything about it?
Thats on the Rpi zero w using terminal, as I find it easier to connect by wire than using ssh on the mac.
That windows thing putty is XXXX. rude words.
Its quite a bit slower to display Chronograf on either the mac or pc than the 3B.
Next thing is try and get the alerts working then its the cellular hat.
Running on a zero W and witty 15m on and 15m off seems to work.
Any time less ‘on’ is a bit of an issue as the delay built into the Influx startup means it takes about 5m from witty switching on until Chronograf updates.

I don;t know why the ls command seems to be outputting a ANSI set graphich rendition string for magenta that lxterminal is not able to process.

Issue echo $LS_COLORS

see also http://linux-sxs.org/housekeeping/lscolors.html

You could try adding
alias
ls='ls --color=never’
to your .profile
No worries. Its not a problem with witty pi, not a problem with raspberry pi

I agree that it seems to take influx a really long time to get ready to accept transactions.

I wonder if there is a nice way to shutdown InfluxDB so that the next start is quicker.
+++++++++
I think that a more limiting factor, regarding duty cycle, will be related to the amount of light aka battery charge, that can be received. I would be surprised if 50-50 is off enough but that depends on latitude, size of solar cell. I think that evaluating the current state of the battery and trying to predict how much time to spend running vs charging is way to compacted and imprecise to be worth the trouble. Especially if frequency of environmental changes of concern as well as alert evaluation and – most of all in your case – time necessary to respond are taken into consideration. Trial and trail and excessive safety margin seems the best way to go.

I hope to get my equipment tomorrow.

Ok I have had little success with Rpi zero but on a 3B the Collector/influx/chronograf image plus wittyPi2 hat, runs fine with two ruuvitags on my wifi.
Times are 20mins on and 40mins off set to start on the hour so you always know when to log on via ssh to do any changes.
Next is to get wvmail and the 3/4g hat running.

Just update this old thread.
Information for RaspberryPi Zero W and the download link is at
http://MyBeacons.info/RuuviCollectorSD.html

1 Like