Best posts made by Yveaux

UPDATE: The official build guide for the ESP8266 gateway can now be found here.
The description in this post is for reference only!

---

Please find an early release of ESP8266 gateway support in my MySensors 1.5 branch:
https://github.com/Yveaux/Arduino

It has not been tested heavily, but seems to run stable at least with one sensor.
Great feature of this setup is you can run a WiFi gateway with just an ESP8266 and nRF24L01+ radio, no further Arduino (ATMega328) is required!

I'm releasing this now, hoping you can start experimenting with it and help development to get to a stable, official release asap.

Setting things up:

• Install Arduino IDE 1.6.5
• Add support for ESP8266 to Arduino, see https://github.com/esp8266/Arduino (Installing with Boards Manager)
• Get the code form my fork https://github.com/Yveaux/Arduino/archive/master.zip and extract the zip
• Edit libraries/MySensors/MyConfig.h when you use e.g. a different datarate, channel or base radio ID.
• Point your Arduino configuration to the extracted dir (File -> Preferences -> Sketchbook location)
• Restart the Arduino IDE

Compiling the gateway:

• Open the WiFi gateway in the Arduino IDE (File -> Sketchbook -> Libraries -> MySensors -> Esp8266Gateway
• Save it, to allow editing
• Enter your SSID and WiFi password in the 'ssid' and 'pass' variables
• Select the ESP8266 board you're targeting in Tools -> Board. I use an ESP12 module, which is a 'Generic ESP8266 Module' board target
• Verify your sketch. It should compile without errors.

Connecting the radio:

• Make sure to use an ESP8266 module which breaks out pins GPIO 4, 12, 13, 14, 15 (e.g. ESP12 module)
• Connect the radio as described in the header of the gateway code.
• Connect the other signals as described in the header of the gateway code.
• I mounted two switches (for reset & bootload) which your ESP8266 may already be equipped with (e.g. the NodeMCU boards have them most of the time)
• I use an FTDI USB->Serial converter to connect the ESP8266 to my PC, which outputs levels at 3.3V. This is very important as the ESP8266 cannot officially handle 5V signals, and cheap USB->Serial converters often output at 5V levels. When in doubt, please check before connecting!
• Power both the ESP8266 and the nRF24L01+ from a separate 3.3V power supply. The 3.3V supply from many USB->Serial converters is often too weak.
• Decouple the power supply with a large capacitor (e.g. 1000uF) and 100nF, to buffer the input and suppress any noise.

Downloading your sketch:

• Start wit a low upload speed (e.g. 9600baud). It will take ages to download, but I sometimes have issues downloading at high speeds.

• Press reset + bootload buttons.

• Keep bootload pressed while releasing reset

• After a few seconds release bootload.

• The ESP8266 is now in bootload mode, and ready to download your code.

• Choose Upload in the Arduino IDE

• After some time (a lot of dots) upload should finish and your code starts. The serial monitor (115200 baud) shows the progress:

    ESP8266 MySensors Gateway
    Connecting to SSID
    ...........Connected!
    IP: 192.168.1.119
    0;0;3;0;9;gateway started, id=0, parent=0, distance=0
    0;0;3;0;9;read: 123-123-0 s=1,c=1,t=24,pt=5,l=4,sg=0:2810347
    123;1;1;0;24;2810347
  

• This text will be preceded by some garbage from the bootloader (it outputs at a lower baudrate)

• The IP address of the WiFI gateway will currently be obtained from a DHCP server.

Now connect a telnet session (e.g. putty) to the IP address mentioned in the serial output (192.168.1.119 in this case), port 5003 and send some serial commands!

The MySensors core team is proud to announce our participation in the Eindhoven Maker Faire 2017!

The event will take place September 2-3 2017, in Eindhoven, The Netherlands and we will be hosting a full size booth.

We plan to have a static setup, showing MySensors enabled hardware (from Sensebenders to breadboard) and a live scale model of a MySensorized house.
Any wild ideas or help are very welcome.

We hope to meet you all in person and have a fun time!

Update: We devoted a full page on the Faire!

Battery powered MySensors Washing machine & dryer monitor, using LDR's to monitor LEDs on front of the appliances.
Each time a LED toggles, the node wakes from interrupt and sends a message. Easy peasy!
When a device is ready, I'll get a message on my mobile phone

Still need to stuff it in an enclosure...

I bumped into this handy Windows tool which shows a notification when USB Serial ports are connected or disconnected:

https://github.com/avishorp/PopCom

"PopCom is a COM port plug-in/plug-out notifier. Whenever a USB device that emulates a COM port is connected to the computer, a pop-up will be displayed, describing the device that has been plugged in and the COM number assigned to it. This pop-up helps determinig the COM number assigned to each device, a number that is required for communicating with it."

As we are plugging serial devices all the time it can be of use to you too!

Enjoy!

Hey guys!

Just a quick update on the Eindhoven Maker Faire !
Yesterday we had the first day. @hek, @tbowmo, @scalz, @sincze , @marceltrapman and myself were present at our booth:

We had a huge amount of visitors! Many were already familiar with MySensors and we convinced the others to at least have a look a out site
The kids loved the automated dollhouse we have on display!

Today we continue with the second day, so you still have one more change to meet us IRL!

Eindhoven Maker Faire
11:00 - 18:00
Klokgebouw 50
5617 AB Eindhoven
The Netherlands

See you there!

@mfalkvidd How about a capacitve touch dimmer (rotary, on/off or linear, whatever you like) ?
Most electricity wall mount systems (e.g. Busch Jaeger, Gira) have 'blind covers' which you can easily fit a capacitive touch pcb behind:

Use a chip like MPR121 to readout the capacitive touch PCB and translate it into roraty movements, clicks, whatevers...

@gohan I'll probably do a writeup of the house anywhere soon. Please give me some time to process and recover from the Faire

A temperature controlled PWM fan controller for my DPS5005 power supply!

The original 2-wire fan that came with the power supply casing made an incredible amount of noise.
Using PWM to reduce its velocity made it even more noisy

So, I made a fresh start and ordered a quality fan (almost as expensive as the whole casing...)

Using nothing more than a 5V pro mini, piezo speaker, DS18B20 temperature sensor and a resistor I made a full fledged fan controller

It takes the current temp from the DS18B20 (which will be mounted on the heatsink) and ramps up the fan linearly in the 30..60 C range. Below 30 C, the fan is off.
If RPM readback indicates a stalled fan, or DS18B20 returns wrong values the buzzer will force me to invest what's wrong

Attached the HMC5883L to my water meter using some putty (just stuck it on the edge near the metal magnet on the big red arrow):

I let the water run for a while and spilled around 20 litres (0.02m3). You can see the magnet has moved from the 5-digit to the 7-digit:

Next is the chart of the HMC5883L's X/Y/Z readings (Range 8_1GA, average over 8 samples, 1 sample (horizontal pixel) per second):

You can clearly see the sensor readings starting to change when the valve opens and stop changing when it's close again!
I didn't want to spill 100 litres just for a quick test, but I expect the curves to be sinusodial, and certainly periodic with the turning of the magnet.
The position of the sensor isn't critical at all (in contrast to all other water meter sensors I've seen), you could even stick it on the closed lid of the water meter!
Every position will generate a different swing of the X/Y/Z signals, so some clever software is required to translate this into (partial)rotations of the magnet.

BTW I used this library and modified HMC5883L_simple.ino to output the data for the Arduino plotter.

This information is outdated. An error in the ATMega328P datasheet has been confirmed. See https://forum.mysensors.org/topic/6572/sleep-with-interrupt-only-works-with-level-low

@AWI Ok, last reply :simple_smile:

I'll have to dwell a little to explain how the AVR works and what its limitations are regarding sleeping, and how the MySensors library handles it.

For AVR architecture, the MySensors library uses the 'Power-Down mode' when sleeping.
I'll focus on ATMega328P here, for which the datasheet states the possible wake-up sources:

So in our case that's INT and WDT (TWI Address match is for i2c slave implementations).
When a timeout parameter is passed to a sleep() function of the MySensors library the watchdog (WDT) will be used to wake after the specified timeout. If timeout is set to 0 (and wake-up from interrupts is specified) the watchdog will be completely disabled to save some more power.
When an interrupt source is passed to a sleep() function of the library it will configure INT0 and/or INT1 to wake up the ATMega328.
Note point 3, as only level interrupts (more precise LOW in case of ATMega328, thanks @AWI for reminding me) can be used as a wake-up source.
Many posts here use RISING/FALLING/CHANGE as wake-up source for ATMega328 which is not supported by the ATMega328P and thus not supported by the MySensors library. Although people claim it is working for them you are on your own when using the chip out of spec and can expect strange behavior!

The datasheet continues in detail on the power-down mode:

The MySensors library disables brown-out to save some power. Serial interface address match and pin change interrupt are not used by the library.
Pay special attention to the note: Waking the AVR from a INT0/INT1 interrupt will require the LOW level to remain for the startup-time, or the interrupt will not trigger. This means that only when the level is held long enough the library will be able to detect it woke from the external interrupt. If the level is not held at least the startup-time, it will assume it woke because of the total sleep time expired, and return MY_WAKE_UP_BY_TIMER (value -1).

This start-up time depends on the clock frequency and fuse bits, which for e.g. an 8MHz Arduino Pro Mini comes down to 2ms.

So just remember: In the MySensors library, only use LOW level interrupts to wake an ATMega328 from sleep and assure the interrupt level remains constant for at least the start-up time!

@AWI Your third example is out-of spec (CHANGE interrupt) and behavior is therefore undefined. If it seems to work, you're lucky...

This information is outdated. An error in the ATMega328P datasheet has been confirmed. See https://forum.mysensors.org/topic/6572/sleep-with-interrupt-only-works-with-level-low

Ok, brace yourself!

I finally had the time to write on my blog about the wireless network sniffer I've been working on lately.
For the impatient see:

• http://yveaux.blogspot.nl/2014/07/nrf24l01-sniffer-part-1.html
• http://yveaux.blogspot.nl/2014/07/nrf24l01-sniffer-part-2.html
• http://yveaux.blogspot.nl/2014/07/nrf24l01-sniffer-part-3.html

This wireless sniffer allows you to capture traffic on air between multiple nodes of your MySensors network and is able to even capture packets with invalid CRC Values. The amount of CRC errors gives a fair indication of link quality, which is not provided by the nRF24.

The sniffer in action:
nRF24L01+ Wireless network sniffer & Wireshark – 00:46
— Emmission

Actual capturing is performed by an nRF24L01+ module connected to an Arduino (we all known how to do that ). No other hardware is required.

A small piece of software (currently only for Windows, sorry @hek) reads the packet data from the sniffer and forwards it to Wireshark, a network protocol analyzer.
Wireshark then allows you to inspect the packages from high-level down to the individual bits, filter by content, and analyze statistics.
Details are all in the blog posts. Last post in this series, which is yet to be written, will dive into using Wireshark and getting useful information from it.
I didn't want to keep this tool to myself until finally finished and documented, so there can (will?) still be some bugs left...

Please discuss any issues/ideas/suggestions in here or in my blog.

Happy sniffin' to all of you!

Today I posted a full write up of the dollhouse. Find it here: https://www.mysensors.org/build/dollhouse

@Matt I like the chainsaw/oscilloscope combo

@alowhum By the way, I finished an extension for the nRF24Doctor about a week ago to display the nRF24 received power spectrum:

Between channels 0 and 125 you see a little 'chart' which has a clear peak around the center. The little dot above the chart is an indicator which shows the selected channel (61), frequency (2.461GHz) and Wifi channel (11) at the bottom row.

The peak in the chart is caused by my Wifi at channel 11

@NeverDie Simple said: Buffer messages at nodes until they receive an acknowledge that the message was delivered succesfully. Retry sending the message after some time if the acknowledge does not arrive.
The principle is simple, but the devil is in the details

I ran into this article that uses MySensors and the nrf-doctor to correct issues with Pcb antennas on nRF24 modules.
I didn't try it, but seems to deserve a mention at this forum!

@sundberg84 the indication system in MySensors allows a user's sketch to receive events each time the MySensors stack does something 'meaningful' or detects an error condition.
The core/MyIndication.h file contains an enum indication_t that defines all events that will be generated by the stack; e.g. INDICATION_TX indicates a message is about to be sent over the air to a node and INDICATION_ERR_TRANSPORT_FAILURE indicates a problem with the transport layer (radio defect).

The stack itself implements a setIndication() handler for these events (I removed the #ifdefs for readability):

void setIndication( const indication_t ind )
{
    if ((INDICATION_TX == ind) || (INDICATION_GW_TX == ind)) {
        ledsBlinkTx(1);
    } else
    if ((INDICATION_RX == ind) || (INDICATION_GW_RX == ind)) {
        ledsBlinkRx(1);
    } else
    if (ind > INDICATION_ERR_START) {
        // Number of blinks indicates which error occurred.
        ledsBlinkErr(ind-INDICATION_ERR_START);
    }
}

As you can see it blinks the Tx led one time when an INDICATION_TX or INDICATION_GW_TX event is received, it blinks the Rx led one time when an INDICATION_RX or INDICATION_GW_RX event is received, and it blinks the error led a number of times, depending on the actual error event code.

The error events are defined in a separate range of the indication_t enum, starting from INDICATION_ERR_START which is defined as 100.
As you see in the code above, in case of errors the INDICATION_ERR_START value will be substracted from the actual event value.
The first actual error in indication_t is defined as INDICATION_ERR_HW_INIT (its value is 101), and will therefore cause the error led to blink 1 time.
The next error in indication_t is defined as INDICATION_ERR_TX(its value is 102), and will therefore cause the error led to blink 2 times, etc.

The fun thing is, you can define your own handler which receives exactly the same events as this piece of LED blink code from the stack does!

To enable it, define MY_INDICATION_HANDLER before the MySensors-include in your sketch:

#define MY_INDICATION_HANDLER
#include <MySensors.h>

Now, anywhere in your sketch add the following function:

void indication( const indication_t ind )
{
    // .. act on events you're interested in ..
    // Not a very useful example, but I hope you get the point
    if (INDICATION_TX == ind) {
        // turn my garden lights on
        digitalWrite(GARDEN_LIGHTS_PIN, HIGH);
    }
    if (INDICATION_RX == ind)
        // turn my garden lights off
        digitalWrite(GARDEN_LIGHTS_PIN, LOW);
    }
}

Make sure to not stay long in this function, as it will block the MySensors stack from running! Do the bare minimum of what you need to do and exit. Don't use delay() and the like, and don't call any MySensors functions from it!

The gateway from @Japio uses the indication() function. (Note that he doesn't define MY_INDICATION_HANDLER as it was written for an older version of the library).

My dollhouse sketches also use the indication() handler, but I wrapped it into a library as the implementation is shared for all sketches.

This dollhouse library also uses my Arduino LedPattern library what was the other thing suitable for your application.
Instead of having to code all kinds of different LED blinking patterns, you can simply define them as (repeating) sequences in your code and call an update function at regular intervals. The library automagically blinks and/or fades the LEDs in the defined pattern without having to worry about a thing.

Definition of a basic sequence to fade a LED looks like:

// A repeating sequence of fading the LED to on
// in 50 cycles, then fading back to off in 100 cycles.
const uint8_t myPattern[] = {
    LedPattern::CMD_SET, OFF,
    LedPattern::CMD_REPEAT, LedPattern::repeatForever, 
        LedPattern::CMD_FADETO,  50, LED_ON,
        LedPattern::CMD_FADETO, 100, LED_OFF,
    LedPattern::CMD_ENDREPEAT
};

To start the fading pattern, just call

pattern.start(myPattern);

And in your loop() you call update regularly:

void loop()
{
  // Update pattern state. LED gets updated and the pattern gets parsed.
  pattern.update();
  
  // Wait 1 time (10ms) cycle before updating again.
  delay(10);
}

Another option is to call update() from e.g. a timer interrupt.
The library supports regular LEDs (or garden lights ), RGB LEDs, NeoPixels and FastLED library. See the readme and examples that come with it.

Now, if you look again at the dollhouse sketch library, you see I defined a number of different blinking patterns for different states of the stack:

const uint8_t ledPatternJoin[] = {
  LedPattern::CMD_REPEAT, LedPattern::repeatForever,
  LedPattern::CMD_SET, LED_ON,
  LedPattern::CMD_WAIT, 10,
  LedPattern::CMD_SET, LED_OFF,
  LedPattern::CMD_WAIT, 50,
  LedPattern::CMD_ENDREPEAT
};

// ...

const uint8_t ledPatternTxRx[] = {
  LedPattern::CMD_SET, LED_ON,
  LedPattern::CMD_WAIT, 1,
  LedPattern::CMD_SET, LED_OFF,
  LedPattern::CMD_FINISHED
};

These patterns are started from the indication() handler I explained above (simplified):

void indication( const indication_t ind )
{
  if (     INDICATION_TX == ind)
       || (INDICATION_GW_TX == ind)
       || (INDICATION_RX == ind)
       || (INDICATION_GW_RX == ind) )
    {
       ledPattern.start(ledPatternTxRx);
    }
  } else if (INDICATION_FIND_PARENT == ind)
  {
    ledPattern.start(ledPatternJoin);
  } // ... else ... 
}

So any TX/RX event from the stack will play the ledPatternTxRx sequence, and when the node starts searching for a parent the ledPatternJoin sequence is played!
You might want to block starting new patterns once a pattern is playing to prevent getting a blinking mess when events come in rapidly. The ledPattern.finished() function tells you if a pattern is currently playing or not.

Note that these sketches use MsTimer2 to time the LedPattern update() calls.

Combining these two techniques in your gardenlights will certainly drive your neighbours crazy

Hey there!

In the past days I succeeded in taking over an indoor wireless weather display and feed it the data from a bunch of weather sensors.

An 868Mhz transmitter is fed with sensor data obtained through a MySensors network, which will then be shown on the display.
A description of the project can be found at my blog: http://yveaux.blogspot.nl/2015/08/hacking-wireless-weather-display.html

Enjoy!

By popular demand (@hek ), my main workplace:

Semi-organized chaos :metal: and some interesting new projects in the making!

@jpaulin Fix is now in development (also tested on ESP8266) and sleeping issue is also solved.
Node will now finish its LED pattern before going to sleep.

@burningstone the biss0001 chip on the pir is rated for 3..5V operation. If you use it outside its allowed range you can expect undefined behavior, e.g. false triggers.

These sensors are very sensitive to power supply. Even with a good supply within spec behavior is sometimes strange, to say the least...

Hi there!

Inspired by the Blog entry at http://provideyourown.com/2012/secret-arduino-voltmeter-measure-battery-voltage/ I decided to write a simple Arduino library to measure VCC level without any external components!
This library can be used to measure the VCC level from e.g. battery powered sensors that do not use a voltage regulator but are powered directly from the batteries and send the battery level to the gateway.

The trick is to use the AVR's internal 1.1V reference to measure AVcc. This does not require an external voltage divider.

The Vcc component can report the VCC level either in volts, or in percentage. Reporting in percentage is a nice way to report the battery level in MySensors!
For example:

#include <Vcc.h>
const float VccExpected   = 3.0;
const float VccCorrection = 2.860/2.92;  // Measured Vcc by multimeter divided by reported Vcc
Vcc vcc(VccCorrection);

static int oldBatteryPcnt = 0;
void loop()
{
	int batteryPcnt = (int)vcc.Read_Perc(VccExpected);
	if (oldBatteryPcnt != batteryPcnt)
	{
		gw.sendBatteryLevel(batteryPcnt);
		oldBatteryPcnt = batteryPcnt;
	}
}

Deviations can easily be corrected for by running one of the example sketches and at the same time measure VCC with a multimeter.
The correction factor should be entered as (VCC multimeter/VCC reported) in the constructor of the Vcc component (the VccCorrection parameter in the example above).
See the example sketches and code for more info.

The library can be found at: https://github.com/Yveaux/arduino_vcc
Or download as ZIP: https://github.com/Yveaux/arduino_vcc/archive/master.zip

Have fun!

@dynamite Nice work!
I'm currently working on the following Molgan hack:

It is a small PCB (the red board) that overlays the original Molgan PCB.
The original PIR & electronics stay in place.
LEDs will remain functional (if you want) or can be partially removed to improve battery life, or completely to turn it into a motion-sensor only.
It uses an SMD nRF24 module, has a mounting spot for SHA204A, FTDI and ISP connectors.

The layout is currently at the board house.
I'll report back when I get the PCBs and build one!

@hek I'm afraid @scalz is hard to beat on that too

@AWI There goes my pleed:

Source: http://gammon.com.au/interrupts

Back to the drawing board then...

@iancu Here you see part of a schematic which I created to control a latching relay:

It uses a IR4427S Mosfet driver to drive the relay coils and allows me to drive the coil in both directions.
The relay is a RTD34005.

Basically the code comes down to:

#define RELAY_ON              (true)
#define RELAY_OFF             (false)
#define RELAY_STARTUP_STATE   RELAY_OFF
#define RELAY_INA_PIN         (A0)
#define RELAY_INB_PIN         (A1)
#define RELAY_SET_TIME_MS     (30)

// ....


static void switchRelay( const bool on )
{
    Serial.print(F("Relay ")); Serial.println( on ? F("ON") : F("OFF"));
    digitalWrite(RELAY_INA_PIN, on ? LOW : HIGH);
    digitalWrite(RELAY_INB_PIN, on ? HIGH : LOW);
    delay(RELAY_SET_TIME_MS);
    digitalWrite(RELAY_INA_PIN, LOW);
    digitalWrite(RELAY_INB_PIN, LOW);
}

// ...

void setup()
{
  // Setup relay and force to defined state
  digitalWrite(RELAY_INA_PIN, LOW);
  digitalWrite(RELAY_INB_PIN, LOW);
  pinMode(RELAY_INA_PIN, OUTPUT);
  pinMode(RELAY_INB_PIN, OUTPUT);

  // Immediately switch relay off
  switchRelay( false );
}

Then anywhere from your code you just call switchRelay( true ) to switch it on or switchRelay( false ) to switch off again.

I think your issue is mainly that you need 2 inputs to be able to control the direction of the current through the coil of the relay, otherwise you won't be able to open and close it.

About a year ago I posted this issue on the forum.

I never found out the cause of the problem, but kept running into known-good radios consistently failing every now and then. Judging from the forum posts, I'm not alone...

Yesterday I was repeatedly hardware-resetting a sensor node and suddenly it stopped sending. It only reported fails on its serial interface. I did not move the sensor or the gateway inbetween.

This means that sometimes after a reset of the Arduino, probably depending on the state of the nRF, the radio will not be initialized correctly. I searched the net for issues resetting the nRF and only really found this discussion, which could be the same issue I experienced.

Anyway, opened the nRF's datasheet, and had a look at figure 4: Radio control state diagram. As the nRF cannot be reset from software, I was looking for a way to at least consistently bring the nRF back into a defined state during startup.
Normally, after a reset of the Arduino, CE will be set 0 (in RF24::begin()) and state Standby-I should be entered, or we stay at Standby-II.
This way we will not always start from the same state. Furthermore we may only hope that all those fake nRF chips lying around will follow the statemachine from a genuine nRF to the letter (I encountered this issue using a known fake nRF, btw).

There is however a way to always bring the nRF back the same starting state. There is a state transition from every state to 'Power Down', by simply setting the PWR_UP flag to 0 (in the CONFIG register). PWR_UP will be set to 1 again, when calling powerUp() at the end of initialization.

I compared the MySensors nRF driver to the current TMRh20 version (on which MySensors' driver is based) and found it always brings back the radio to state 'Power Down' before starting initialization (this line). The MySensors driver lacks this line of code....

I added the same line to the MySensors driver, and retried the tests, but (ofcourse ) wasn't able to reproduce the issue again...

So, could it be that in some rare sittuations we do not initialize the nRF24 correctly?
If so, this might be a very simple fix for those issues, but we need to be able to reproduce it to make sure it fixes the issue.
Did any of you guys experience somthing similar, or even know how to reproduce it?

@sergio_uno this forum focuses on open-source development.
Your project looks great, but unless you disclose the design files this post is just an advertisement, which goes against forum rules.

We deploy a special site, openhardware.io, where users can share their designs with others. If you disclose your design files you will still be able to sell units through e.g. ebay.

We will remove this post in 24 hours, unless you share your design files with the community.

A set of Node-Red nodes to decode OpenTherm messages produced by thermostats and Central Heating systems: https://github.com/Yveaux/node-red-contrib-opentherm
It can e.g. replace the OpenTherm Monitor software from otgw by InfluxDB/Grafana

Not a MySensors project, but nice anyway

@AWI Took me a day of debugging, datasheet reading and searching the internet, but It looks like I fixed the sleep with external interrupts issues in the MySensors library!
Main issue was this one: https://github.com/mysensors/MySensors/issues/811
If an interrupt was pending (if it had been registered before actually sleeping the AVR) it would immediately wake the AVR again, just 2ms after sleeping it. It didn't matter if this interrupt was registered just before calling sleep or 1 hour ago...
Furthermore https://github.com/mysensors/MySensors/issues/812 and https://github.com/mysensors/MySensors/issues/809 were also fixed, but have minor impact.

I tested it on a ProMini with ATMega328P @ 8MHz, powered directly by 2xAA battery -- a 'standard' sleeping sensor processor setup.
I verified sleeping modes LOW, CHANGE, RISING & FALLING to work Ok. This confirms your findings and Nick Gammon's.

Sidenote: Mode HIGH is mapped onto CHANGE in Arduino ATMega328P port (duh!). The library can therefore not distinguish between the two and will use CHANGE in both situations.

The bugs are solved in development branch, so please give it a try!

@gohan said in Awesome tutorial on MQTT Node Red:

As I said before I never used influxdb and grafana, but it is in my to do list so I am just asking some questions as I "grew up" working most of the times on SQL server

I understand. I also grew up with relational databases and did my first iot steps with them too. Then I found influxdb and never want to go back!

Just sharing my enthusiasm and hoping to spare you time by making the switch now

@vladimir please don't crosspost. Everybody is able to see the latest messages, so there is no need to point to your post from multiple threads.

@skywatch I usually use an exponential moving average (https://en.wikipedia.org/wiki/Moving_average) as it doesn't require keeping a sliding window of the past x values.
The idea is simple: new values are averaged over previous values with low weight.

Eg

avg = (avg*(weight-1) + new) / weight

weight is just a factor (as would the size of your window be). Large weight causes slow response to changes. If working with integer types pick a power of 2 for the weight, so the compiler optimizes the division to a simple bitshift operation instead of a real division.

A MySensor'ed temperature controller for my utility cabinet, which runs too hot due to all the electronics in there (cable modem, router, switch, etc.)
In its current version it is able to control a 12V 120mm PWM fan, and reads the temperature from 3 DS18B20 temp sensors (inlet, 'ambient' and router).
Later I might add a temperature controller to keep the ambient temperature stable at a a few degrees above inlet, by controlling the fan's dutycycle.

As all sensors in my utility cabinet are powered from 5V USB, I used a step-up converter to generate the 12V required by the fan.

After soldering everything together I wasn't happy with the orientation of the JST headers for the temp sensors, so a small PCB was added to mount them under 90 degrees:

All data and control is routed to Node-red, stored in InfluxDB and graphed in Grafana:

You can see the temperature of the router ('USG') go down with increasing fan rotational speed (lower chart, 'rpm.mean').
Temperature decrease is not as big as I hoped for, so I might need to install a fan with a bigger airflow.

@burningstone Here's a schematic representation of what I mean:

The red wire w.r.t. ground (black wire) will supply max. 4.5V (3xAA), the yellow one w.r.t ground will supply max. 3V.
The load of the Arduino and nRF24 are small, so all batteries will more or less drain equally fast.

It can easily be implemented by soldering an extra wire (the yellow one) to a 3xAA battery holder:

Try it, and verify the output voltages with a DMM!

@avamander sorry, but I don't know. I glue everything together using node-red, and you can probably squeeze it in to extract the data for influxdb before passing it on to your favorite controller too.

@LinuxIoT why do you call your board 'LinuxIot' when you don't seem to target Linux as OS?
Or am I missing something?

@TheoL said:

It's not about the tools, it's what you do with it

That doesn't only hold for woodworking!

@Mister_ik try to design your sensor to be directly powered by batteries, without step up/down conversion. The converters in general introduce a lot of noise, which the pir is very sensitive to.
I power my pir sensors from 3xAA battery (remove the regulator from the pir module) and a 3.3v pro mini from 2xAA (same battery pack, just branch power after 2 batteries instead of whole pack)
Works flawlessly with many years of battery lifetime.

@bjacobse TME has a large selection. They ship to all European countries (I think)...

@hek said:

fritzing

first time right!

IMHO the topic of interrupt handling and the required buffering of messages should be extended to automatic resending of messages when they are not acknowledged by the gateway. Currently the sender has to actively check if an acknowledge is received or not.
Buffering of messages and automatic resending when a message gets lost would make the whole MySensors library much more robust and would cause the library to get very close to guaranteed delivery.
This topic has been on my wishlist for a long time, but adding buffering of messages and making the whole library interrupt-safe is not simple to accomplish.
Furthermore the ecosystem of a target platform (e.g. ESP8266) can still suppress interrupt handling -- we won't have control over it.

@Bene Hi and welcome to the forum!
Some time ago I wrote a library which exactly implements the method described on the site you mentioned.
There's a topic devoted to this Vcc library, which you can find here.
The drawbacks of this method are:

• you cannot use it when a regulator is used to power the AVR; it needs to be directly powered from the battery
• it isn't very accurate, but can be calibrated to increase accuracy.

@waspie Seems like you're rounding to full degrees in the line

temperature = data.celsiusHundredths/100;

In the si7021 library the si7021_env type is defined as:

typedef struct si7021_env {
    int celsiusHundredths;
    int fahrenheitHundredths;
    unsigned int humidityBasisPoints;
} si7021_env;

so temperature is an integer in 1/100th increments.

Try converting this integer to float before dividing, like:

temperature = float(data.celsiusHundredths)/100.0;

@neverdie said in nRF5 Bluetooth action!:

@toyman I guess I made an error then. Thanks for pointing that out.

I actually think you were correct in your design, @NeverDie

A while ago part of the e73-2g4m04s schematic was posted on this forum:

Clearly the inductors to use the DC/DC converter are not connected to DCC. There is however a capacitor C17 from DEC4 to GND.

The Nordic reference schematic shows the missing L2 and L3, but capacitor C10 is actually present in the e73-2g4m04s (the mentioned C17, albeit only 100nF instead of 1.0uF in the reference):

Therefore I think your breakout is correct, as only the inductors between DCC and DEC4 need to be added to match the reference schematic

@rozpruwacz said in irq pin for nrf24l01:

What MY_RX_MESSAGE_BUFFER_FEATURE actually do?

The nrf24 radios can only buffer 3 incoming messages at most, if more come in they will be lost.
For repeaters and gateway (basically non-sleeping sensors) this feature enables immediate retrieval of incoming messages and buffering in internal ram. For crowded networks, or sensors which send a lot of data at once, this feature reduces packet loss.
Drawbacks are the increased use of ram (amount of messages buffered can be configured) and the nrf irq has to be connected.

@abrasha small detail, but what you've made is a 'watchdog' between sensor and controller. The time requests are handled by the controller, so if the gateway responds, but the controller is down you will still get no time response.

i just need something like an "ack" or any value that will show me that the GW responds, and if not - execute hw_reboot() to power-cycle the node and force it to reconnect to the GW.

I wonder if a lost connection between gateway and sensor will be re-established by rebooting the sensor.
Some failure modes:

• Non-responsive sensor (sensor 'hangs'): it will not be able to communicate at all, or reboot itself -> the hardware watchdog will provide a better solution
• Non-responsive radio: the radio might recover by initialising it again (executed when the sensor restarts). If radio 'hangs' you'll probably need to powercycle it to become responsive again.
• Non-responsive gateway: bad luck, as reboot of the sensor will not recover the gateway.
• Non-responsive controller: bad luck, as reboot of the sensor will not recover the controller.

Am I forgetting something?

@adamant you need a controller to hand out dynamic id's. The gateway will only pass these id requests on to a controller.

@alowhum well, the schematic is more or less the bare minimum. Even with current measurement the number of components and total cost is very low ($10 ballpark).
This project is a continuous development and I'm designing a pcb for it at the moment (all through - hole, so easy to replicate).
The output of the display could also be sent over serial, but the whole idea is you can walk around with the doctor and improve your results as you go.

@grumpazoid said in 2.3.1 TO 2.3.2 MyConfig.h got changed:

.the channel number has been reset to default in MyConfig.h

What do you mean by has been reset? If you manually made changes to MyConfig.h they will always get lost on an upgrade of the library because the files in the library are overwritten by the new ones!
If you need to change the channel you should do so in your sketch, not in the library.

@NeverDie I agree with @mfalkvidd.
Dirty pcbs produces decent quality boards and allows panalization without extra costs.
I usually combine some designs in a single 10x10 panel, and fill the remaining space with small adapter boards. Cost per pcb will be very low that way.

I found the root cause: https://github.com/mysensors/MySensors/issues/1458#issuecomment-739139339
It is part of the signing code, so expected to occur on all nodes/gateways that request nonces for signing.
Currently discussing if it is a real issue or not.

@hek said:

mysenors.org

Great work, señor !

Hey there!
After reading this topic, I recently ordered an ATMega328pb, the successor of the ATMega328p.
We all know the ATMega328p which is used on e.g. Arduino UNO & Pro-Mini boards.
An extensive overview of all differences can be read here.
In short, the new ATMega328pb has a lot of new features, it's footprint is nearly identical to the ATMega328p and it is binary compatible with its predecessor.
This means you can download a regular ATMega328p binary to it and it will just run!

As the proof is in the pudding, a single TQFP PB was ordered and it arrived safely at my desk.
I took a 5V/16MHz Pro-Mini from China, and removed the ATMega328p using hot-air:

As said, the footprint is nearly identical, except for power pins 3 & 6, which are used as IO pins on the PB. I don't feel happy feeding 5V into a pin configured as output, so I decided to simply remove pads 3 & 6 from the PCB (inside the red cicle).
I soldered the new PB in place (not cleaned yet, and a bit misaligned

Took out the JTAGICE3 ISP programmer, and it was recognized with the PB device signature 0x1E9516!

Now there are two ways to go:

1. Program a 'regular' ATMega328p Arduino bootloader (e.g. optiboot) and use the device from the Arduino IDE as a regular ATMega328P (UNO/Pro Mini/...)
2. Program a specific ATMega328pb Arduino bootloader (e.g. modified optiboot) and use the device from the Arduino IDE as ATMega328PB (no Arduino boards yet -- but I think I just created one)

Thanks to the guys at Watterott the optiboot bootloader for both configurations can be downloaded from here.
They also created a board package for the PB version.
Update Apparently Elektor also did their own board support and peripheral implementation (of course not compatible with Watterott...). More info can be found here.

Following steps describe how to get things going (for now, May 27, 2016 as stuff probably develops rapidly), with Arduino IDE 1.6.9, on Windows:

Use as 'regular' ATMega328p

• Program the ATMega328p optiboot bootloader ('optiboot_m328p.hex') using ISP.
• Set fuses to: Extended 0xF5, High 0xDA, Low 0xFF (for 16Mhz external crystal/resonator!)
• Now the chip can be programmed from the Arduino IDE as if it were a regular ATMega328p based board!

Use as ATMega328pb

• Program the ATMega328pb optiboot bootloader ('optiboot_m328pb.hex') using ISP.
• Set fuses to: Extended 0xF5, High 0xDA, Low 0xFF (for 16Mhz external crystal/resonator!)
• Install the Watterott board location into the IDE (Preferences -> Additional board manager URLs. Add https://github.com/watterott/ATmega328PB-Testing/raw/master/package_m328pb_index.json)
• Install Board support for ATmega328PB Boards (currently at revision 1.0.1)
• Restart the IDE
• Select e.g. the blink sketch, select Board 'Atmel ATmega328PB Crystal Clock', 16MHz
• and upload the sketch!

Support for all the extra peripherals in the PB is still ongoing. I expect it to get really up to speed the moment Arduino releases a PB based board. Watterott is already selling PB boards, as is Elektor, and probably others.

Have fun!

@sundberg84 poor guy... +1 for persistence though

@xlibor said:

ANDed

Better ORed, or all your sensors have to trigger at the same time to wake up the Arduino

For the rest @xlibor is right: OR-ing PIR triggers into a single wake-up signal can be as simple as using a diode per PIR and a resistor:

Ref: https://learn.sparkfun.com/tutorials/diodes/diode-applications

@d00616 said in Where to get legit nRF24L01+ modules?:

they have an rectangle over the N and responding line an original NRF24L01. Maybe this helps to identify originals.

Here we go again... Nordic is a fabless company. Therefore the laser marking on their genuine models can be different with each batch. There is no known way to tell if a module is genuine or not from the outside of the module.

@NeverDie @scalz To get the nRF5 series adopted by MySensors and its users I think we should start with a single board. We have to make sure it is easy to obtain/replicate (by using a ready available module, or using a hardware partner where people can just order the board) and supply the required getting started docs.
I really appreciate all the work done on the nRF5 support, but now we have to take the leap from prototype to 'production' to get it adopted by the community.

I started with a quick overview of the dollhouse node.
Design files and explanation can be found at OH: https://www.openhardware.io/view/475/Dollhouse-wireless-node

@gohan I ran into this HopeRF antenna paper. Addresses a lot of different antenna types.

@mljbr4 You can change it on the fly by calling

RF24_setChannel( c );

But, that's probably not going to work in your situation.... If you change it in before() it will be overwritten by the MySensors stack, if you do it in setup() you're already too late...

What you could try is define a variable holding the channel, and make sure this gets set to the right value before MySensors starts, e.g.:

uint8_t channel = 76;  // default
#define MY_RF24_CHANNEL (channel)
#include <MySensors.h>

void before()
{
  channel = 90;  // debug channel
}

@skywatch As I understand it the remark points to the deprecation of MY_RADIO_NRF24 in favor of MY_RADIO_RF24.

The define MY_RADIO_NRF24 is automatically 'converted' to MY_RADIO_RF24 by 2.3.1, but it will no longer be supported in 3.0.0.
So, to prepare for 3.0.0. you should use MY_RADIO_RF24.

@grubstake said in why no one uses latching relays ?:

This seems useful for any sort of battery powered node that is to trigger opening or closing a circuit

Be aware that the relay on the board is non latching. Keeping it in actuated state requires continuous power to the relay coil, which will quickly drain batteries.

@mfalkvidd from my own experience with ebyte modules I would say they are superior compared to the no-name ones.
The nrf signature (power, inverted ack bit, rf spectrum) compares to genuine nordic modules so the ebyte claim that they use original nordic modules looks to be valid.
Furthermore the red modules referred to by @alowhum are very small, have good build quality and a low power resonator which makes them a perfect fit for battery powered applications.

The mySensors community would profit from a supplier offering good radios at a decent price. IMHO Ebyte currently is the best (only?) supplier matching these criteria, so I would vote to only mention their modules in the build section.

Hopefully this will help (new) users to start using high quality modules and prevent a lot of frustration caused by poor quality hardware.

@yveaux said in CDEBYTE's new NRF24 modules are great! (and cheap):

I see a few solutions to this ploblem (lowering the nRF24 VCC or changing the resistors on the voltage dividers) which I'll give a try and report back.

Lowering the nRF24 VCC is not feasible as it will also impact the signals going to the ATMega below minimum levels.

I replaced 4 10k SMD resistors R5, R6, R7 & R8 by 4k7 types:

@รอเร-อ This patch makes both regular and amplified nRF24 modules work correctly! The IO levels to the nRF are raised to 3.3V at 5V Arduino supply.

Btw. I ordered 2 of these IO shields (red version, by 'Robotale' according to silkscreen) and the quality is horrible...
It's nearly impossible to push the Nano in the socket, it was full of (near) solder shorts, the silscreen is barely readable and one of the boards contained a short to GND on the RX line, making it impossible to program (geen circle):

@sundberg84 looks like you can ditch the temperarure sensor and just use the battery voltage to measure the temperature

Added a basic sketch to the repo. Enjoy!

@Mrlynx said:

After that am I going to release it as open hardware.

I think it would be a good idea to release the design files right now, as it allows people to get a detailed insight in your design and what they'll receive when ordering.
Furthermore every body can help improve the design, but you'll keep in charge of course.
The whole idea about MySensors (both software and hardware) is to be open so everybody will benefit in the long run.

@sundberg84 see api & download on the main page. Section 'sleeping' under 1.5 api
@hek there's a small error in the api describing the sleep-method. The prototype says it returns a bool, but the description talks about an int.

@marceltrapman you don't have to calibrate it to use it. Only the 1v1 reference is created using a bandgap diode which can have slight deviations for each AVR you buy ( approx. In the 1.0..1.2 volts range) If you don't calibrate it, the reading can be 10% off.
If you need accuracy, just calibrate it!

@bjacobse According to this guy it contains a TI CC2500 transciever and MSP430G2221 microcontroller.
This guy claims it suffers from WiFi interference.

@LastSamurai

• What are the SJ1 and 2 parts on the pcb?Just some measurement points where I can cut the trace?

The solder jumpers are to support ATmega328PB. You need to open them when mounting an PB version.

• Why did you put in the pullup for the CS line on the NRF? Never saw that one before

Habit With multiple SPI devices on a bus it's good practise to have a pullup on all of the CS lines. Here it isn't really required though.

• The wire to the batterie spring is need to be able to use only 2 batteries for the addon pcb, right?

Yes, the addon runs on 2xAAA, the PIR on 3xAAA
By powering the addon with 2xAAA it can be powered directly without an extra voltage regulator.

• But you use 3 batteries and both connection points to the main pcb still?

The original connection points are still required to power the bottom PIR PCB. Both PCB's share a common ground.

• Any particular reason why you did not make your pcb bigger so that it reaches the + from the main pcb too?

This size I could fit more sub-PCB's in a panelized design for the board house. And, as said, the addon PCB doesn't require the + on the main PCB.

Today this nice MP3 player board with microSD card reader arrived in the mail:

I bought it from my good friend Ali and planned on creating a MySensor'ed doorbell node.
It conforms to the default Arduino Uno pin layout, as you can see.
Size doesn't really matter so I figured to stick it on a Uno to have the whole thing up and running in no time.

Some of the pins of the VS1053 appeared to be soldered together on my board, so I started surfing the net, looking for some schematics of the board... None found (of course...)
It seems very similar to Sparkfun's MP3 player shield, except for one missing item: a level shifter.
This got me thinking... OK, maybe the VS1053 and SD card IO's are 5V tolerant... No, that's not the case.
Maybe they used some voltage dividers to go from the 5V UNO signals to the 3V3 signals required by the VS1053 and SD card. Took the multimeter. No, directly connected.

So this board directly routes 5V signals to 3V3 tolerant chips...
Who the hell designs, and then dares to sell an Arduino UNO shield that's incompatible to an Arduino UNO???

The net shows some supposedly succesful attempts of using this board, directly connected to an Arduino Uno.
Were these guys just lucky they didn't fry the whole board? Or am I missing something?

I didn't dare connecting it to an UNO yet. I think I'll start with a 3V3 Pro Mini first Update At least it works flawless at 3V3 with Sparkfun's library

What do you think? Or maybe you encountered such fiascos yourself?

@ahmedadelhosni said:

I guess it won't differ.

@whitedrag0n These radios are different. See http://forum.mysensors.org/topic/1887/what-s-the-difference-between-nrf24l01-and-nrf24l01
They can probably be put to work by using correct settings. See http://forum.mysensors.org/topic/2838/mysensors-1-5-and-nrf24l01-without

@Anticimex Ok, updated the thread subject once more

@Damme Only the chair and Weller iron seem to be identical to your opening picture at the top of this thread
Everything else seems to have changed (including location of your desk)
Good to see you're back man!

@Zeph I'm running all my RPi's with readonly filesystem, and tmpfs.
It all depends on your situation whether you need to persistently store a lot of data or can do with a ramdisk.
Added benefit of running from ram is that you can pull the power at any time without the risk of corrupting the filesystem.

@msebbe on my dd-wrt setup the router will only show active clients that it handed out an IP address to using dhcp.
Static IP addresses (configured at the client) won't show up in that list.
You could try if it is in the list of active TCP connections, or configure a static IP address in the router for your client (mapping it's Mac address to an IP address), instead of on the client.

@Zeph Yeah, on my harddrive in Dutch...
I can give you a very short description on how I did it for Arduino Pro Mini, 3v3 @ 8MHz, though.

• Download https://code.google.com/p/optiboot/downloads/detail?name=optiboot-v5.0a.zip

• Extract to c:\Arduino_1.5.5\hardware\arduino\avr\ (rename existing optiboot dir, when required)

• Edit bootloaders\optiboot\Makefile to change baudrate (line 562)

    atmega328_pro8:
    	$(MAKE) $(CHIP) AVR_FREQ=8000000L LED_START_FLASHES=3 BAUD_RATE=76800
  

• Start cmd shell in c:\Arduino_1.5.5\hardware\arduino\avr\bootloaders\optiboot

• make clean

• make atmega328_pro8

• flash optiboot_atmega328_pro_8MHz.hex using your favourite ISP

• Fuses: Low = 0xFF, High = 0xDE, Extended = 0xFE

• Close any active Arduino windows.

• Edit c:\Arduino_1.5.5\hardware\arduino\avr\boards.txt

• Add (based on Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328):

    ## Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328 - Optiboot 76k8
    ## --------------------------------------------------
    pro.menu.cpu.8MHzatmega328ob=ATmega328 (3.3V, 8 MHz, Optiboot 76k8)
  
    pro.menu.cpu.8MHzatmega328ob.upload.maximum_size=30720
    pro.menu.cpu.8MHzatmega328ob.upload.maximum_data_size=2048
    pro.menu.cpu.8MHzatmega328ob.upload.speed=76800
  
    pro.menu.cpu.8MHzatmega328ob.bootloader.low_fuses=0xFF
    pro.menu.cpu.8MHzatmega328ob.bootloader.high_fuses=0xDA
    pro.menu.cpu.8MHzatmega328ob.bootloader.extended_fuses=0x05
    pro.menu.cpu.8MHzatmega328ob.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
  
    pro.menu.cpu.8MHzatmega328ob.build.mcu=atmega328p
    pro.menu.cpu.8MHzatmega328ob.build.f_cpu=8000000L
  

• Start Arduino IDE

• Select Board -> Arduino Pro or Pro Mini

• Select Processor -> ATmega328 (3.3V, 8 MHz, Optiboot 76k8)

• File->Upload

That's it

I received a single ATMega328PB from Farnell; very well packed:

And another 2 ATMega328P's were shipped within the same order.
Guess what? They came in their own tray

@LastSamurai said:

As I will be soldering some too soon: how did you do it? Any tips?

Very fine soldering tip, much flux!

@cimba007 the mysensors library already supports requesting a software ack from the target node. A message can be flagged (command_ack_payload) so the target will send the same message back as confirmation it did arrive at the target. A node requesting a software ack should therefore parse incoming messages scanning for the ack response.
You seem to have a software background, so I guess you can figure out the rest by looking at the code.
Good luck!

I couldn't stand it and wired up the motion sensor I have (HC-SR501) and tested with the MotionSensor example code (MySensors 1.4b).
Sensor supply is 5V, sensor output is connected to pin 2 or Arduino. Pin 2 is configured to be an input pin and generate an interrupt when any change on the pin state is detected. You don't need to attach a resistor as the sensor outputs either a low state or high state (3V3 according to my data). You *could *connect a small resistor (e.g. 100ohms) between sensor output and Arduino pin to limit the current.
I only changed the SLEEP_TIME to 30000 and DIGITAL_INPUT_SENSOR to 2. Downloaded the sketch to Uno and ran it.
Works as expected! Sensor sleeps and is woken by any change in interrupt pin (this is a contradiction with the ATmega datasheet which states it should only act on low level!).
So a value of 1 is sent when the sensor detects motion, 0 when motion 'goes away'.

Hopefully this answers your question

@Jan-Gatzke I have this one:

It's able to hold all kinds of PCB sizes and can rotate easily.

Tip for soldering through-hole components from the back without them falling out:
Place all components on the top of the PCB and put a sponge or scotch-brite on top of them. Fix to the PCB with some rubber bands and swap the PCB to solder!

@Nca78 maybe hi-link, like Nordic, will try to prosecute to get the fakes off the market, or maybe they're not even aware these exist.
What do you have to loose by contacting them?

@Maurice-Krijtenberg or mount them upside down, so the pins will stick out above the arduino. This way you don't have to clip them and you can even still connect jumper wires to them.

@Fabien said:

sensebender node is with default sketch so 2 messages (temp and hum)

And a send of battery level every 60 runs of loop() (according to https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/examples/SensebenderMicro/SensebenderMicro.ino)

Anyway, that's 3 messages in total every 30 seconds. The nRF has a 3-message receive buffer, so when used correctly those 3 messages should just stay in that buffer waiting for the MySensors stack to retrieve them.

Could you retry by changing the following line in your gateway code:

gw.process();

into

gw.process();
gw.process();
gw.process();

This will try to read 3 messages (the whole message buffer) at each run of the gateway loop().

@hek I had a look at the MySensors code and have some doubts about following line: https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/MySensor.cpp#L556
Shouldn't the receive function be called repeatedly until no message is available anymore ? Now it will only read & process one message maximum on each gateway.process() call, while there could be up to 3 messages waiting in the fifo and new messages can come in while processing others.

Furthermore I'm not sure of the code around https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/utility/RF24.cpp#L878
This listeningStarted flag seems to be used to force a delay of 800us after start listening, but the flag is not set when listening starts. In e.g. Thomas' nrf24 github repo (https://github.com/thozza/MySensors-Raspberry/blob/master/librf24-bcm/RF24.cpp#L527) the flag is set when listening starts and TMRh20 doesn't implement this delay (https://github.com/TMRh20/RF24/blob/master/RF24.cpp#L1067)
Seems like we have some halve-merged code, but I wasn't able to track its origin (it was committed by you on 16 Sep 2014)

@NeverDie It looks to be what can be expected after googlin' a bit; e.g. https://openawg.github.io/2016/04/19/first-test-chamber-constructed.html
Opening the freezer's door will further disturb things (did it stay closed in both charts?)
Were both measurements aquired using the exact same si7021 sensor?

@mfalkvidd maybe an old pc power supply?

@Reza Hmmm.... What happens if you touch it with your toe?

@A-R No need to get all grumpy! I'm just trying to understand what you want to achieve, and help you out.
You are posting to a MySensors forum, so I assumed you are using MySensors software in your project.
Answer to your question: No.

@nca78 I did fiddle with the frequency, but the fan was just total crap, so I decided to replace it anyhow.

@karlheinz2000 @parachutesj @gohan It appeared to be pointless to compare markings of nRF24L01+ IC's to determine if they are genuine or not.
Nordic is fabless and uses different fabs to produce their IC's. Each fab will have a different way of marking the chips.

I had a discussion with a Nordic representative in the past and even he could only say for sure if an IC was genuine or not by putting the part in X-Ray.
He had 3 different modules analyzed which I mailed to Nordic (China versions); all 3 appeared to be fakes...

The blob ones however are fake for sure.

@Reza are you?
You're not the first asking these questions here.
Why won't you try searching first? https://www.google.com/search?q=touch+finger+site%3Amysensors.org

@Mark-Swift Don't know if you already ditched the ESP gateway completely, but you could give my latest experiment a try: https://github.com/Yveaux/Arduino/tree/development
It adds a reception queue to the gateway which will immediately retrieve a message from the radio when it comes in. This process should even continue when the ESP is blocked on some TCP transfer.
Only thing you have to do is connect the IRQ line from the nRF radio to the ESP (e.g. to pin 1), and define the IRQ pin at the top of your gateway sketch:

#define MY_RF24_IRQ_PIN  (1)

I tested this on a UNO, and can easily sleep the gateway for 1 second or more when messages come in at 0.1sec interval -- none gets lost. The buffer is set to 20 by default, but you can increase it when the amount of RAM allows it:

#define MY_RF24_MESSAGE_BUFFER_SIZE  (50)

I don't have a NodeMCU setup ready so I cannot test it on ESP myself...

@neverdie said in Awesome tutorial on MQTT Node Red:

1. dumping everything into a mysql database, so everything gets logged forever (storage is cheap).

Skip the relational databases and pick a time series database like influxdb to store your data.
You'll thank me in the end!

@rozpruwacz We were talking relay modules (like this one) which normally only take supply and a single control signal.
Having to control the latching of the relay using an H-Bridge I find 'a bit harder' compared to just toggling an IO, regarding both software and hardware.

For reference, this is the schematic I use to control a latching relay:

It uses a MAX2226/4427/4428 or compatible MOSFET driver to drive the relay.

And a function to switch it:

#define RELAY_INA_PIN         (A0)
#define RELAY_INB_PIN         (A1)
#define RELAY_SET_TIME_MS     (30)

static void switchRelay( const bool on )
{
    digitalWrite(RELAY_INA_PIN, on ? LOW : HIGH);
    digitalWrite(RELAY_INB_PIN, on ? HIGH : LOW);
    delay(RELAY_SET_TIME_MS);
    digitalWrite(RELAY_INA_PIN, LOW);
    digitalWrite(RELAY_INB_PIN, LOW);
}

@burningstone tape a wire directly on the battery, or solder to the battery or the holder.
Look what you have lying around and be creative!
That's what MySensors is about!

@hozze make sure you don't define MY_LEDS_BLINKING_FEATURE or MY_INCLUSION_MODE_FEATURE, as their pin mappings might interfere with your application.

@gohan You probably want to graph your data. Especially when combining different datasets, sampled asynchronous at non equidistant intervals you will have a lot of trouble plotting it when it is stored in a standard relational database like MySQL.
Time series databases are perfectly fit for sensor data from different sources, like your MySensors network.
Tools like Grafana and Influxdb make the perfect combination for this!