Do you store your sensor data? PART ONE.

[homeautomaton]

Polls on github are incredibly lame. There's only one vote allowed per account, and if I go to change anything, or add another option, all previous "votes" get reset and you'd have to vote again. Not at all good for questions that might need to allow multiple answers and if we need to expand the list of answers. Also, it takes two steps to vote. After you click a choice, you must also click VOTE.

So, I'll judge the interest in the topic of whether and how people are capturing sensor data with a simple yes/no question, and we can add comments about the actual methods. If there's a good number of responses over the next few weeks, I'll collect them into an actual poll, with sensible combinations of the choices.

Examples: text log file, JSON file, CSV file, influxdb, mqtt-to-home-assistant, mqtt-to-nodered.

[homeautomaton]

My setup uses MQTT, NodeRED and Home Assistant. Ultimately data is stored in SQLite by Home Assistant.

[rct]

I keep rolled gzipped raw log files from rtl_433 to be able to go back to almost the source when needed.

Over the years, I've used RRDtool, Home Assistant, InfluxDB to store sensor data.

[hdtodd]

I use logrotate to zip files weekly and retain them for a year, but I only have about 4 months of data so far.

I have a separate Arduino/Pi weatherstation that logs data in a sqlite3 database, and it has collected data for about 6 years.

[pswiatki]

I also keep gzip-ped logs.
Question is: how do I deal with id changes after battery replacement? Is it at all possible to identify the sensor without physically checking its reading (my sensors have tiny LCDs). Let me know if this does not belong here (and I will open a separate thread).

[hdtodd]

Piotr,
One way would be to run a terminal window with a mosquitto client subscribed to your rtl_433 MQTT broker and watch as you insert the fresh battery into your remote sensor, when the re-started remote announces itself. I have a bash script that I keep to make it easy: mosquitto_sub -h pi-1 -t "rtl_433/pi-1/event

Another would be to run my rtl_watch program and look for the added new line at the bottom of the table as you insert the fresh battery into the remote sensor.

[pswiatki]

Thank you, David. It is just a shame those cheap sensors (I got mine in as a set with the "weather station" - now I have two of such stations and the reading on both stations are completely f***ed - there are a total of six remote sensors). I am quite frustrated with this situation, I have to say. One single sensor is #91 (inFactory) and comes from yet another station, while the rest are #19 (Nexus). One of those, strangely, kept its id. Even more strangely, it was the one closest (maybe 2 meters away) to the RTL receiver. Probably a coincidence, though.

[hdtodd]

Piotr,
I'd be curious if the sensor kept its id after the next battery change. If it's an 8-bit field, there's a 1 in 256 chance that it'll have the same id when it restarts. If it happens twice, I'd guess that it has some sort of local memory for retaining configuration information.

I didn't understand the problem with your sensors. Do they just all give different readings? Or no readings at all? Or are the in-home monitoring displays broken?

If the problem is with the in-home monitoring system, you can still use the sensors and monitor their readings with my DNT program (https://github.com/hdtodd/DNT). I've deployed an old sensor, for which the in-home display broke, to report temperatures on the porch -- as well as from my new outdoor remote sensor and the temperatures from my neighbors' thermometers. :-)

[pswiatki]

OK, let me quickly explain: evidently, since the id cannot be relied upon, it seems the designers opted for the channel number as a differentiating item. The base station can display four pairs of TH readings - three from the remote sensors and its internal TH.
So, when I got another station of the same type - I immediately started seeing weirdness on the display (the channel switch has only three positions and there are six remote TH sensors now, so, each channel is used twice). Up until last week, I thought the design of the station was flawed as it only looked for the channel field in the message from the remote TH sensor, but now I know the id cannot be used as a unique identifier as it does not survive the battery exchange. So, my current situation is: stations are completely useless (I don't know which readings they show), rtl433 on the other hand at least shows me all the fields and I can somehow identify an individual sensor, but only as long as it remains powered. When I swap batteries, I must update the id-to-pysical-sensor map again.
But yes - it is very nice to be able, with a careful antenna construction to make sure it resonates where it should, to easily pick up all the sensors around the house + some of the neighbours' sensors, too. Also, quite often my setup picks up TPMS from the cars running in the street (~25 meters from the antenna - which is by the window, but indoors).

[hdtodd]

Piotr,

Thanks for clarifying.

My experience is limited to Acurite TH devices, so this might not be helpful. When I replace the battery in my Acurite remotes, I have to re-sync with the base station (which in my case only accepts one remote). It doesn't use channel numbers, but the remote generates a new, random id upon power-up, and that's when I do the syncing.

But I also have DNT running on a touchscreen Raspberry Pi, and I have a table of id numbers and corresponding location (including model/channel/id identifiers for neighbors' remotes) that I have to update whenever one of the batteries gets changed (mine or my neighbors'). It's a nuisance, but it's pretty quick to do by subscribing to the rtl_433 MQTT feed and watching for new id's.

Is the problem that the remotes don't use id at all, or that you don't know which remotes have which id's? It's a nuisance to have to re-identify remotes when you change batteries, but that might be only every 6-12 months. And if you monitor the rtl_433 MQTT broker when you install new batteries in one, you can quickly get its id from that stream.

Not ideal, but if your remotes do have id's, that approach might allow you to use them all. I'm re-using an old remote, from an old Acurite base-station that died, with DNT. You can have lots of extra remotes, even if you don't have base-stations to pair with them, if you use something like rtl_433 and DNT to monitor them.

[riegelbrau]

I send the rtl_433 data via mqtt to openHAB and there some of the data is persisted actually in a MariaDB.