Best posts made by canyouhearmenow

I needed a simple tool for keeping track of all the MySensors nodes which I had built and deployed around the house over the years:

• what is the battery level of each sensor node?
• what was the last time I changed the battery on that sensor node, i.e. how many months has it been running with the current battery?
• see at a glance if a sensor has crashed, i.e. has not sent any messages for, say, more than a day
• is a sensor node sending strange messages?

This is implemented as a Python script running on a server, with a web-based interface for browsing and filtering messages.

Source code and documentation in Github

Here are a few screenshots:

This sensor node is attached to the gas meter in my home. It uses a 2,4 GHz RF link to a MySensors-to-MQTT gateway to report natural gas consumption data to my home automation controller. The gas meter is of the type that creates magnetic pulses when the meter dial moves, so the connection is contact-less, and works without access to the inside of the “official” meter from the utility company.

Initially, MyGasMeter only reports incremental data:

• frequently, it reports the incremental pulse count since the last report.
• once per hour, it reports flow [liters/hour] calculated from pulse count.

Once it has received a base count value from the controller (see below), it also starts reporting absolute data:

• frequently, it reports the absolute pulse count, i.e. base value + pulses since power on.
• once per hour, it reports total gas volume [liters] consumed, i.e. (base value + pulses since power on) * liters/pulse.

With this two-stage approach, the node will always report correct absolute pulse count, even if the gateway misses a message now and then. Also, you can replace the battery on the node and then re-initialize it for the correct absolute pulse count, without relying on EEPROM memory.

In my home automation setup, this is integrated with openHAB, but it should also be usable with other controllers, because all communication is done via MQTT.

The node must be battery-powered (read: low supply current, sleep as much as possible), but it can’t use the MySensors sleep() function, because it needs a fairly accurate time base so it can report flow in liters per hour.

It uses the (not so accurate) internal RC oscillator of the AVR to clock the CPU, but a (much more accurate) external 32768 Hz crystal to clock Timer2, which generates interrupts every 10ms, so it can debounce the reed switch, and do all other housekeeping as needed.

In between interrupts, it sleeps in SLEEP_MODE_PWR_SAVE mode, which stops most of the processor’s peripherals, except for Timer2. During sleep, Timer0 as used by the Arduino framework is stopped, so we can’t rely on the Arduino millis() function for timing. Instead, we use a milliseconds counter incremented by the Timer2 ISR for timing purposes (has an hour passed? should we report pulse count or flow or climate?).

Source code and schematics are available in Github. For a more detailed technical description , please visit my blog.

MySensors is a very nice framework for building very low power sensor nodes ... in a hobbyist environment, I like it, I have sensors around the house that have been running for 2+ years on a coin cell battery.

I am wondering if one of the reasons why no commercial player is offering MySensors-based gadgets might be the choice of license: MySensors is published under GPL, which commercial players may perhaps not be comfortable with. Other popular and successful open source projects, such as Arduino itself, are published under less restrictive licenses such as LGPL.

Good idea to measure battery voltage after an RF transmission, not before ... never thought of that.

I have built window sensors that last more than 36 months on one CR2032. I usually set the brownout threshold to 1.8V, not 2.7V, and then replace the battery when the voltage drops below ~2.2V.

You have to be careful not to power any sensors while the node is asleep, that also applies to the lowly reed switch windows sensor! If you just connect it to an input pin and use the internal pull-up of the ATmega processor, then you have a current flowing all the time, when the window is closed and therefore the reed switch inside the sensor is closed. That current is higher than the sleep mode power consumption of the whole processor!

I can see why internal clock vs 8 MHz crystal doesn't make a difference -- most of the time, the processor will be asleep with all clocks stopped, and a stopped 8 MHz crystal oscillator consumes as much power as a stopped internal RC oscillator ...

You can find more details about what to watch out for, and some measurements with different configurations, here.

@evb Still haven't had a chance to look at your PR, sorry.
Yes, the database tends to grow I have about 80MB after a year of use. Just added a function to delete all messages older than, say, a year.

I needed a couple of motions sensors to automate lighting in hallways and other rooms. Since the lights should only turn on when it is dark, the system also needs to know the ambient light level in the location where the motion was detected -- so I added a simple brightness sensor to each node.

This is based on an Arduino Pro Mini clone, it is low power (runs for >18 months one a pair of AA batteries) and low cost (cost of materials <EUR 10 ).

Source code and schematics are available in Github, and a more detailed description here.

I chose the smaller HC-SR505 PIR sensor rather than the larger HC-SR501 sensor used in the MySensors motion sensor example. The PIR sensor appears to be sensitive to power supply fluctuations. In the first prototype, it would often re-trigger immediately after its output returned to low (inactive), presumably because sending a message via the NRF24L01+ module would draw current from the battery, and cause a drop in supply voltage. Therefore, the software ignores transitions of the PIR sensor output for a few seconds after going to sleep.