This is "older" tech so the installed base is (was?) large.
In the past I found out if you use "level" in the format string it will output signal strength type data that you can analyze. It is not rocket surgery to store a DB row consisting of timestamp, id, and signal strength of all RX'd packets, then make a dashboard of how many unique IDs you hear over a ten minute period or whatever.
My hope was to detect 70 cm ham radio band openings (tropo ducts and the like) Wow did that never work. It was a good idea and fun but did not work at all. I repurposed the hardware into something else and moved on. Its possible that with different antennas or longer term project or something, who knows. The software, as in the article's link, worked fine however.
If you'd like to try another frustrating IoT experiment, try monitoring all the tire pressure monitor systems that drive by your house using roughly the same hardware and similar software. IIRC I ran out of patience with that one. Sounded like fun after I saw a YT video on the topic... The good news is each tire on the road (by 2023 anyway) has a unique 32 bit ID, IIRC anyway, the bad news is the range was scarcely better than "a car length" away. If you've ever driven your car over the machine with the hoses the DOT puts out to count cars along a road for planning purposes, I thought I could replicate that kind of data by sniffing and analyzing TPMS data, but the range is WAY too low for the low repetition rate of the transmissions. I guess you could just gather data wirelessly for years at a time, but ... Maybe you could make parking meters really smart by listening for the tires parked at the meter, or track super expensive private parking, or an electric charger could pre-load the new user by sniffing the new user's tire transmitters. Or my garage door could automatically open if and only if my car is at the door. However the transmission rate is too low for most door opener level of patience.
I bought an SDR dongle for recording temperature and humidity from a couple of small battery powered transmitters.
I found that the location of my main desktop was perfect for reading the sauna temperature/humidity every minute, but I couldn't simultaneously record values from my balcony. Perhaps my concrete walls were too thick, or the transmitter.
However I soon noticed that those tyre-pressure sensors also spit out the temperature. So the end result was that my receiver could get the temperature of my sauna - which I use to send an SMS with "sauna is ready" - and the outside air.
I'm on the second floor, and there's a car-park 20m away from the side of the house. On average I get readings over most parts of the day, as the various cars come and go.
Try what DOT does. They track toll transponders and vehicle Bluetooth radios for "traffic pattern". I seen both implemented in and around Washington DC and Delaware.
Dumb question, but do you have ID of your house on the chip? You could at least have a high and low threshold for your house and compare it to other houses.
The opening of this article is confusing. It contrasts relatively expensive Zigbee and Z-Wave devices with cheap sensors emitting radio signals in the unlicensed ISM bands. But Zigbee and Z-Wave both operate in ISM bands, so the distinction isn't a difference.
It's more like the difference between building and hosting a static website with Squarespace vs. AWS. One of them is more expensive with more bells and whistles, but both accomplish similar goals by communicating with the browser in similar ways.
yup, I guess what the author meant is the 433 MHz vs 868 MHz / 915 MHz and 2.4GHz ISM bands.
In my experience, expensive stuff tends to run in the 2.4 GHz band, while inexpensive stuff runs in the 433 MHz band. I know that 868 MHz is not in the ISM bands, but in Europe, it's really close.
Rtl_433 is a great program. I have it running on an RPi with an RTL-SDR logging the temperature readings from the sensors for a couple of AcuRite thermometers I have, plus whatever random sensors I pick up from my neighbors, plus a tipping rain gauge I have.
It makes it really easy for DIY projects like the aforementioned raid gauge. To illustrate this I'll give some details about my rain gauge project.
This is the rain gauge I'm using [1]. It's got a reed switch that gets momentarily closed by a magnet on the tipping part whenever it tips. I hooked that up to an GPIO on a cheap microcontroller (an ATTiny 85 [2]) which counts the tips. Also connected to the microcontroller is a 434 MHz transmitter [3]. This is all powered by 3 NiMH rechargeable batteries in series.
That transmitter is remarkably simple. It just contains an oscillator at ~434 MHz that can be turned on and off by the microcontroller.
My send message function takes a byte string and sends it by turning the transmitter one for 1.5 ms, then off for 1.5 ms, and then for each bit off the message sending it as follows: for a 1 it turns on the transmitter for 0.4 ms then off for 0.6 ms, and for a 0 it turns on the transmitter for 0.6 ms then off for 0.4 ms. There is no gap between bits.
The data sent is the string "TZS\4Count:" and then a two byte count.
Here's a config file for rtl_433 that tells it how to recognize those messages and display the count:
decoder {
name = TZS Rain Gauge,
modulation = OOK_PWM,
short = 416,
long = 612,
reset = 1452,
gap = 0,
tolerance = 0,
sync = 1484,
bits = 96,
match = {24}0x545a53,
get = Tips:@80:{16},
}
I really should have included some kind of checksum, but for now I'm relying on the fact that the count should never go down (except when I change batteries) and should not go up too fast. With those constraints I should be able to look at a series of messages from the rain gauge and figure out which ones were corrupted by interference.
I got information on how fast the count might go up here (I'm in Washington) from the Washington State Department of Transportation's Hydraulics Manual [4]. It gives a formula for calculating at various places what would be an N year amount of rain over an M minute interval. E.g., how much rain over 5 minutes would be a once in a 100 year kind of event? (This is of interest to the DoT for things like calculating drainage requirements for roads).
Here's the Arduino code for the transmitting to show how straightforward it is:
#include <avr/interrupt.h>
#include <Adafruit_SleepyDog.h>
/* RST |1 8| Vcc
SERIAL 3 |2 7| 2 LED (SCK)
RADIO 4 |3 6| 1 TIP (MISO)
GND |4 5| 0 (MOSI)
*/
#define TIP 1 // physical 6, PCINT1
#define RADIO_TX 4 // physical 3
#define SERIAL_TX 3 // physical 2
#define LED 2 // physical 7
volatile unsigned long int_count = 0;
unsigned long last_interrupt_time = 0;
void setup() {
pinMode(TIP, INPUT_PULLUP);
pinMode(LED, OUTPUT);
pinMode(RADIO_TX, OUTPUT);
pinMode(SERIAL_TX, INPUT_PULLUP);
cli();
GIMSK |= 0b00100000; /* enabled pin change interrupt */
PCMSK |= 0b00000010; /* PCINT0 */
sei();
}
ISR(PCINT0_vect) {
++int_count;
}
void loop() {
int led = 1;
unsigned long tip_count = 0;
unsigned long tip_int_count = 0;
unsigned long old_int_count = 0;
int silence_time = 0;
while (1) {
int slept = Watchdog.sleep(1000);
int changed = 0;
if (int_count != old_int_count) {
old_int_count = int_count;
} else {
if (old_int_count != tip_int_count) {
++tip_count;
++changed;
tip_int_count = old_int_count;
}
}
digitalWrite(LED, 0);
led = 1 - led;
if (changed || ++silence_time >= 30) {
report(RADIO_TX, tip_count);
silence_time = 0;
}
}
}
(The code mentions an LED, but that was just used during prototyping. I did not include the LED on the deployed rain gauge).
Battery life was 285 days on the first set of batteries, and 219 on the second set. I haven't yet went over my records to see if it was more rainy during the second set's deployment.
In the past I found out if you use "level" in the format string it will output signal strength type data that you can analyze. It is not rocket surgery to store a DB row consisting of timestamp, id, and signal strength of all RX'd packets, then make a dashboard of how many unique IDs you hear over a ten minute period or whatever.
My hope was to detect 70 cm ham radio band openings (tropo ducts and the like) Wow did that never work. It was a good idea and fun but did not work at all. I repurposed the hardware into something else and moved on. Its possible that with different antennas or longer term project or something, who knows. The software, as in the article's link, worked fine however.
If you'd like to try another frustrating IoT experiment, try monitoring all the tire pressure monitor systems that drive by your house using roughly the same hardware and similar software. IIRC I ran out of patience with that one. Sounded like fun after I saw a YT video on the topic... The good news is each tire on the road (by 2023 anyway) has a unique 32 bit ID, IIRC anyway, the bad news is the range was scarcely better than "a car length" away. If you've ever driven your car over the machine with the hoses the DOT puts out to count cars along a road for planning purposes, I thought I could replicate that kind of data by sniffing and analyzing TPMS data, but the range is WAY too low for the low repetition rate of the transmissions. I guess you could just gather data wirelessly for years at a time, but ... Maybe you could make parking meters really smart by listening for the tires parked at the meter, or track super expensive private parking, or an electric charger could pre-load the new user by sniffing the new user's tire transmitters. Or my garage door could automatically open if and only if my car is at the door. However the transmission rate is too low for most door opener level of patience.