Posts made by Carywin

Check out the RadioHead library, it implements a mesh network on RFM69

If you’re using sensors over wifi you don’t need MySensors, you can just use PubSubClient. MySensors is primarily for mesh network sensors not using wifi.

You don’t need MySensors for this, PubSubClient will do what you need.

What you need is an MQTT broker and the PubSubClient library. MySensors is not useful to you.

I got this working here: https://forum.mysensors.org/topic/6249/mqtt-ethernet-gateway-using-leonardo-32u4-w5100-rfm69h-hard-spi

I have used VL53L0X laser time-of-flight sensors for things like this. They work great, are inexpensive, and reliable. They're available for a few dollars from the usual Chinese suppliers.

I accidentally used a 915 MHz part at 433 MHz and even that worked, albeit at substantially reduced range.

Hi Folks,
This is more of a troubleshooting report than a request for help. I thought I'd report my findings here in hopes of saving someone else the headaches I've had recently.

What it boils down to is: the default clocks used on the common 3V3 and 5V Arduino boards cause small errors in actual baud rate on the hardware USART serial ports, and at certain rates the error difference between the two variants is opposite and results in no communications being possible between them.

Some background:
I have a small but growing RS485 MySensors network incorporated into my OpenHAB-based home automation system. It started out with just a MQTT gateway and a single node, being a weather station mounted up on the roof about 5 metres away. RS485 was chosen because getting RF signals through the metal roof was problematic, and I was sick of climbing up there to change batteries. Both the gateway and the WXS were built with 3V3 8MHz 32u4 based Arduinos, because then I could use the hardware USART port for RS485 comms while still having the USB port for debugging. Cat-6 cable was used, with one pair for the RS485 comms and a pair each for +12V and GND. The baud rate was set at 115200 bps and this setup worked flawlessly for about a year.
So pleased was I with the reliability, that I decided all sensor nodes on my upper storey that had easy access for a cable would be wired nodes on the RS485 network going forward.
The second node to be deployed on the network was a light/heat/fan controller for the bathroom. This node used a 5V 16MHz 32u4 Arduino. When built and tested on the bench, this node worked perfectly; but when deployed into the roof space and connected to mains power it flatly refused to work, spitting FPAR:NOREPLY errors forever. I spent a lot of time trying to troubleshoot the comms issues by investigating ground loops or other noise, termination, or power supply issues. I pulled the AC/DC supply off it and used the central +12V one. I changed the baud rates around and got some intermittent success. At one point I even fried both the Arduino and my laptop when some stray high-power-switching surges tried to find their way to ground through the USB cable. Nothing seemed to work in the roof, everything worked fine on the bench.

After much longer scratching my head than I feel comfortable admitting I examined the differences between the MQTT gateway and my test setup, investigated how the oscillator clock is divided down to determine the baud rate, and stumbled upon the answer:

at fosc = 8 MHz (3V3 parts), 115.2kbps, Error = -3.5%
at fosc = 16 MHz (5V parts), 115.2kbps, Error = 2.1%
Total error: 5.6%, somewhat outside the tolerable window of ~5% for baud rate error.

In the end the solution was as simple as lowering the baud rate on the 5V 16MHz part by ~4% to 110600 bps. The new node then instantly connected and has been reliable ever since.

This is great, thanks!
One suggestion: add a switch mode regulator that can handle 12 or 24 volt DC input. This will allow small sensor devices to hang off a typical bus network having extra pairs for the central power supply.

You don’t need MySensors for a direct connection to MQTT. Just use pubsubclient.

Good luck! I tried sticking with NRF long past when would be sensible, and still ended up changing to RFM69 (433 MHz in my case).
Inner-city areas are just too crowded on 2.4G now, but paradoxically 433 MHz is becoming freeer thanks to the slow death of landlines and DECT phones.

I got it to work using Leonardo, but the same process would work for Uno I think:
https://forum.mysensors.org/topic/6249/mqtt-ethernet-gateway-using-leonardo-32u4-w5100-rfm69h-hard-spi

@neverdie This is correct, but this testing is all handled by the EnableInterrupt library

@dbemowsk The Pro Mini does have pin change interrupts on every pin

@gohan Sorry I don't have a way to measure current that small, but given that it's already run for months on the original batteries, I'm going to assume it's a "normal" Atmega sleep state

You can use pin change interrupts with MySensors sleep loops with an easy hack. Here's the code I use for 4 button battery powered nodes that also report temperature and humidity using DHT a sensor. I run them from 2 AA and so far they've been running for more than 6 months without showing signs of discharge. This could be easily modified for 6 or 8 buttons.

// MySensors EnviroButtons
// Temperature and Humidity Sensor with 4 Push Buttons
// Battery Powered Node
// Don't forget to change buttons and VCC_CAL for each node

// Cary Wintle - July 2017

// MySensors configuration
// -----------------------
#define SN "EnviroButtons"  // Software name
#define SV "0.4"            // Version number
//#define MY_DEBUG
#define MY_NODE_ID 6
#define MY_RADIO_RFM69
#define MY_RFM69_NETWORKID 137
#define MY_RFM69_ENABLE_ENCRYPTION
#define MY_RFM69_NEW_DRIVER
#define MY_RFM69_FREQUENCY RFM69_433MHZ
#define MY_IS_RFM69HW
#include <MySensors.h>

#include <SPI.h>
#include <DHT.h>

#define EI_NOTEXTERNAL // External interrupts managed by built-in routines
#include <EnableInterrupt.h> // Pin-change interrupts

// Set this to the pin you connected the DHT's data pin to
#define DHT_DATA_PIN 8

// Buttons
#define BUTTON1_PIN A1 // 5: A1 - 6: A1
#define BUTTON2_PIN A2 // 5: A3 - 6: A2
#define BUTTON3_PIN A3 // 5: A2 - 6: A3
#define BUTTON4_PIN A0 // 5: A0 - 6: A0

// Set this offset if the sensor has a permanent small offset to the real temperatures
#define SENSOR_TEMP_OFFSET 0

// Sleep time between sensor updates (in milliseconds)
// Must be >1000ms for DHT22 and >2000ms for DHT11
static const uint64_t UPDATE_INTERVAL = 120000;
#define BAT_UPDATE_INTERVAL 720 // 24 hrs - Interval between battery updates (multiples of UPDATE_INTERVAL)
// VCC Calibration Values
// Node 5: 1128953L
// Node 6: 1125300L
#define VCC_CAL 1125300L

// Force sending an update of the temperature after n sensor reads, so a controller showing the
// timestamp of the last update doesn't show something like 3 hours in the unlikely case, that
// the value didn't change since;
// i.e. the sensor would force sending an update every UPDATE_INTERVAL*FORCE_UPDATE_N_READS [ms]
static const uint8_t FORCE_UPDATE_N_READS = 30; // After an hour

float lastTemp;
float lastHum;
uint8_t nNoUpdatesTemp;
uint8_t nNoUpdatesHum;
int cycleCount = BAT_UPDATE_INTERVAL; // Send battery update immediately
volatile byte B1Int = 0, B2Int = 0, B3Int = 0, B4Int = 0; // Interrupt button flags
uint32_t now;

MyMessage msgHum(0, V_HUM);
MyMessage msgTemp(0, V_TEMP);
MyMessage msgButtons(0, V_SCENE_ON);
MyMessage msgBattV(0, V_VOLTAGE);
DHT dht;

void presentation()  
{ 
  // Send the sketch version information to the gateway
  sendSketchInfo(SN,SV);
  // Present the sensor
  present(0, S_CUSTOM, "Temp/Humid/Buttons");
}

void setup()
{
  // Setup pins the DHT sensor is on
  digitalWrite(6, LOW);
  pinMode(6, OUTPUT);
  digitalWrite(7, LOW);
  pinMode(7, OUTPUT);
  digitalWrite(9, HIGH);
  pinMode(9, OUTPUT);

  sleep(2000);

  dht.setup(DHT_DATA_PIN); // Setup the DHT sensor

  pinMode(BUTTON1_PIN,INPUT_PULLUP);
  pinMode(BUTTON2_PIN,INPUT_PULLUP);
  pinMode(BUTTON3_PIN,INPUT_PULLUP);
  pinMode(BUTTON4_PIN,INPUT_PULLUP);
  enableInterrupt(BUTTON1_PIN,Button1,FALLING);
  enableInterrupt(BUTTON2_PIN,Button2,FALLING);
  enableInterrupt(BUTTON3_PIN,Button3,FALLING);
  enableInterrupt(BUTTON4_PIN,Button4,FALLING);
}

void Button1() {
  B1Int++;
  _wokeUpByInterrupt = 0xFE; // Dirty hack to get out of MySensors sleep loop
}

void Button2() {
  B2Int++;
  _wokeUpByInterrupt = 0xFE; // Dirty hack to get out of MySensors sleep loop
}

void Button3() {
  B3Int++;
  _wokeUpByInterrupt = 0xFE; // Dirty hack to get out of MySensors sleep loop
}

void Button4() {
  B4Int++;
  _wokeUpByInterrupt = 0xFE; // Dirty hack to get out of MySensors sleep loop
}


void loop() {
  _wokeUpByInterrupt = INVALID_INTERRUPT_NUM;
  // Power up the DHT sensor
  digitalWrite(9, HIGH);

  // Process buttons
  if(B1Int > 0) {
    send(msgButtons.set(1));
    B1Int = 0;
  } else if(B2Int > 0) {
    send(msgButtons.set(2));
    B2Int = 0;
  } else if(B3Int > 0) {
    send(msgButtons.set(3));
    B3Int = 0;
  } else if(B4Int > 0) {
    send(msgButtons.set(4));
    B4Int = 0;
  }

  // Wait for the DHT sensor to init
  sleep(2000);
  
  // Force reading sensor, so it works also after sleep()
  dht.readSensor(true);
  
  // Get temperature from DHT library
  float temperature = dht.getTemperature();
  if (isnan(temperature)) {
    Serial.println("Failed reading temperature from DHT!");
  } else if (temperature != lastTemp || nNoUpdatesTemp == FORCE_UPDATE_N_READS) {
    // Only send temperature if it changed since the last measurement or if we didn't send an update for n times
    lastTemp = temperature;
    // Reset no updates counter
    nNoUpdatesTemp = 0;
    temperature += SENSOR_TEMP_OFFSET;
    send(msgTemp.set(temperature, 1));

    #ifdef MY_DEBUG
    Serial.print("T: ");
    Serial.println(temperature);
    #endif
  } else {
    // Increase no update counter if the temperature stayed the same
    nNoUpdatesTemp++;
  }

  // Get humidity from DHT library
  byte humidity = (byte)dht.getHumidity();
  if (humidity != lastHum || nNoUpdatesHum == FORCE_UPDATE_N_READS) {
    // Only send humidity if it changed since the last measurement or if we didn't send an update for n times
    lastHum = humidity;
    // Reset no updates counter
    nNoUpdatesHum = 0;
    send(msgHum.set(humidity, 1));
    
    #ifdef MY_DEBUG
    Serial.print("H: ");
    Serial.println(humidity);
    #endif
  } else {
    // Increase no update counter if the humidity stayed the same
    nNoUpdatesHum++;
  }

  if (cycleCount >= BAT_UPDATE_INTERVAL) {
    cycleCount = 0;
    int BatV = readVCC();
    #ifdef MY_DEBUG
    Serial.print("BatVR: ");
    Serial.println(BatV);
    #endif
    float BatVolts = BatV / 1000.0;
    #ifdef MY_DEBUG
    Serial.print("BatV: ");
    Serial.println(BatVolts);
    #endif
    send(msgBattV.set(BatVolts, 2));
    float BatPercent = (BatVolts - 2.8) / 0.6 * 100;
    if(BatPercent > 100) BatPercent = 100;
    #ifdef MY_DEBUG
    Serial.print("Bat%: ");
    Serial.println(BatPercent);
    #endif
    sendBatteryLevel((int)BatPercent);
  }
  cycleCount++;

  // Power down the DHT sensor
  digitalWrite(9, LOW);
  
  // Sleep for a while to save energy
  sleep(UPDATE_INTERVAL); 
}

int readVCC() {
  // Read 1.1V reference against AVcc
  // set the reference to Vcc and the measurement to the internal 1.1V reference
    ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);

  wait(2); // Wait for Vref to settle
  ADCSRA |= _BV(ADSC); // Start conversion
  while (bit_is_set(ADCSRA,ADSC)); // measuring

  uint8_t low  = ADCL; // must read ADCL first - it then locks ADCH  
  uint8_t high = ADCH; // unlocks both

  int result = (high<<8) | low;

  #ifdef MY_DEBUG
  Serial.print("R: ");
  Serial.println(result);
  #endif

  result = VCC_CAL / result; // Calculate Vcc (in mV); 1125300 = 1.1*1023*1000
  return result; // Vcc in millivolts
}

@neverdie The bulk of MySensors nodes run on Atmega328P, with 2k of SRAM they're already quite resource-constrained in some of these sensors.

Power = Current squared x Resistance, so for your example of 5 A and 0.035 Ron the power dissipated is 0.875 W. It's still not a lot but it's substantially more than was stated.

Okay I played around with this tonight and had some struggles. I couldn't get serial uploading working on any of the Gert Sanders bootloaders, so I had to use Arduino as ISP and Upload via Programmer.
However since I have encryption enabled, I need the AES key in EEPROM before my nodes will work.
So I had to enable the fuse that prevents EEPROM being erased when programming.

I experimented with using the 1 MHz oscillator option, but the sketch didn't run properly. It was sending 5-8 copies of every message at a very slow rate.

So now I'm trying the 8 MHz internal oscillator with BOD at 1.8 V to see if that works at a lower voltage than the crystal.

If anyone knows if MySensors works at 1 MHz, or what might cause it to send multiple copies of the same message, speak up please!

Thanks!
I should have mentioned that I already set the BOD to 1.8V, but that doesn't help when the XTAL oscillator stops working at 2.6.
I'll try one of those other bootloaders and see what flies.

Does anybody know of a neat way to get this board to operate below 2.7V?

From some reading it seems like the Atmega328 chip doesn't like running a crystal oscillator below 2.7V, but should be happy running from internal clock source. It seems like this might cause problems with libraries or serial comms though. Does anyone have experience with this or can point me towards a bootloader that might work?

So far I've had a couple of these sensors fail after 2 months or so with battery volts around 2.65V. I was hoping for at least 12 months from a CR2450, but some of these sensors are sending >150 messages a day so I'd understand if it was shorter than that. Still, 2 months is not enough I think, and I hope I can tweak something to get it to work down to at least 2.0V, which might squeeze some more time out of it.

I would suggest comment out the TX power setting and let the ATC control it. If it still doesn't work, try:

#define MY_RFM69_ATC_MODE_DISABLED
#define MY_RFM69_TX_POWER_DBM 20

Edit:
Maybe also try

#define MY_DEBUG_VERBOSE_RFM69

and see if that tells you anything more.

Right, I'm sure that node is fine, I mainly just zoomed in and looked at this one:

I use this same small piggyback board for many nodes and it works great with those 21mm coil antennas.

However, I just noticed the #define for TX power. I think the H and HW versions have a minimum of 13dB or something. Have you tried without?

@mbj Yes I see what you're trying to achieve.
I would keep a 16 or 32 bit counter in the rain sensor, and increment it on each bucket tip and send the new value when it changes. Then in the controller take care of tallys and midnight resets, but with some extra logic to handle when the counter value rolls over (that will take a very long time :D) or the sensor restarts. This would also mean you don't miss any pulses when the controller is down because the sensor is still counting, but a sensor restart won't reset your daily tally.
Another idea would be to have a reset command sent by the controller around midnight. There would need to be some logic where the controller waited until the sensor was awake again before sending it commands, but that seems simple enough.
Or just put a RTC on there XD

Having said all that I will look forward to reading your code and seeing the timing solution!

Interesting design, but I'm wondering why you don't just send a message every time the bucket tips, and then do all the tallying and midnight rollover stuff on the controller?

I'm not very familiar with that hardware, but from a cursory glance it looks like you don't have the interrupt pin connected? Unlike the NRF modules, the RFM69s are interrupt-driven and need DIO0 connected to pin 2

Thanks for the responses. I guess I'll try a simple RFM repeater up there instead, and wait to see if bridging becomes available.

Some background:
I have a MySensors network based on Arduino & RFM69 433MHz radios, with an Ethernet MQTT Gateway. I have 12 nodes on it currently. It's working well.

In progress:
I'm going to add another gateway, this time a Serial <-> RS485 gateway for locally wired sensors. The first sensors on this new wired net will be in a weather station mounted on a pole up on my roof. It's going wired because it's simple (my controller is already in the attic) and I'm sick of getting up on the roof to change WXS batteries.

What's desired:
I want to put another node out at my front gate which will sense things like mail in the mailbox, and read pulses from my water meter. At present signals from my RFM gateway will not reach there, however if I put a repeater up on the roof I reckon they would.

Question:
Is there a way to have a repeater built in to the weather station node up on the roof, which will talk back to the controller via RS485. In essence it'd be a media converter, translating to and from RFM radio and wired RS485. Does the MyS library support a node having two transports, and routing messages correctly between them?

@peterrr
My take:
Put a RFM69-Ethernet MQTT MyS gateway somewhere central like the greenhouse, with a nice 10+db whip up high, and plug the Ethernet into a WiFi AP. Put RFM69s on the other arduino nodes with MyS. Your OpenHAB controller can go anywhere that has a network or WiFi connection, and talk to the sensor net via MQTT. Monitoring and control via the OpenHAB app on a smartphone will work anywhere there's WiFi. Automation is via the Xtend-based rules language which has plenty of examples to work from.

@peterrr Yes absolutely. I have it mixing up RFM69 wireless sensors and actuators with MySensors, MQTT sensors on WiFi ESP8266 via PubSubClient and Sonoff-Tasmota, Zigbee lights via Belkin Wemo, and locally-attached sensors on RPi GPIO and RS485 links. It smashes them all together in a very flexible and adaptable way.

I have had great success with OpenHAB. If you're not afraid of learning a scripting language, it can be very powerful and flexible.

I would use the pin change interrupts. If you search you can find a neat hack for making PCINT work to wake up the micro from MySensors sleep loop. That gives you many interrupts to use.

Okay, so here's some firmware I wrote for these multi-sensors: https://github.com/carywin/MySensors/tree/master/MyS_MultiSensor_revB

Note that I'm currently using MySensors 2.2-beta from the development branch, to solve the some other problems I was having in my RFM69-based gateway. This sketch should still work fine with the released version of MySensors but I haven't tested it.I'm still testing and refining things here and there, but it should be a working base for people to build from. Of course you will need to change the MySensors #defines to match your network and radio settings.

You'll probably notice that all of the sensors report under the same Child ID as a "Custom Sensor". This is because I'm using OpenHAB via an MQTT broker, so I don't really care if a certain sensor type matches with its provided variable types. If you're using a different controller, you may have to re-jig the Child ID/Variable types to match the known-working sensors on your controller.

PIR Sensor:
The PIR sensor is interrupt driven and will send a message when it receives more than 5 pulses in less than 5 seconds. After triggering, the interrupt is disabled for 60 seconds. If it receives fewer than 5 pulses then approx. 5 seconds after the last pulse it will reset the pulse counter. For the first 30 seconds after power-on, the PIR interrupts are disabled to allow the signal conditioning circuit time to settle. All of these values are configurable in the sketch. Note that I'm using GreyGnome's EnableInterrupt library, which you'll need to get from their Github.

Lux Sensor:
The lux level sensor will send a new reading to the controller when the lux reading moves outside a window threshold from the current reading, which is configurable in the sketch. It also takes a new reading after a certain period with no changes in lux, which is also configurable in the sketch.
Note that you'll need the specific version of the OPT3001 library from the above link copied into your libraries folder. I modified the library to spit out raw values and allow the setting of thresholds, so the lux sensor can do most of the heavy lifting with regards to monitoring light levels and flagging an interrupt when it changes. Note that when the lux readings are very low, such as around sunrise and sunset, the threshold values are fixed to prevent excessive lux sensor messages.

Door Sensor:
The D3 pin input is set to trigger an interrupt on state change, which will send its new state to the controller on each change. It's pulled high by an on-board resistor so the input pullup is disabled to save energy.

Temp & Humidity Sensor:
Temperature and humidity are read at regular intervals (default 10 min), and new values only sent if the they have changed by 0.1 degC or 1% RH. If a certain number of intervals pass with no change (default 3 hours) they will send new values anyway. This way the controller can expire their readings after 3 hours and ignore stale values, and you can get an indication that maybe your sensor has failed. The interval times are configurable in the sketch. I'm using the Adafruit SI7021 library which you can get from their Github.

Battery:
Once a day by default the sensor will report battery voltage as a sensor, and remaining capacity as a percentage using the in-built reporting function. The full and empty thresholds as well as reporting interval are configurable in the sketch. Note that the method used to measure battery voltage has a large margin for error, but that this can mostly be calibrated out. For this reason you'll see a VCC calibration value that you should set by measuring each sensor's battery voltage with a multimeter, and comparing with its reported battery volts.

WDT:
I'm using the WDT during the time when the code isn't asleep, with a timeout of 2 seconds. This should be more than enough to send all of the sensor messages needed each cycle, but I haven't extensively tested that. I included it because in revision A I was suffering some kind of unknown lock up that would keep the MC awake and drain the coin cell battery in just a few hours. Of course the WDT is used by the library for timing the sleep intervals, so it gets re-enabled each wake up.

Because timing how long an Arduino has been asleep is difficult without a RTC, the sleep time may vary somewhat depending on how many interrupts the sensor receives. Each time the MC is woken from sleep by an interrupt, it reduces the amount of time it will sleep next time by 25%. In addition to this, if more than 25 interrupts occur before a new round of sensor readings are taken, then the interval will be declared over and the sensors read again. These are crude methods for timing but so far it seem to be reliable in that the sensor neither sleeps forever nor spams excessively when receiving realistic rates of interrupt.

I welcome any input people have on this project and ways that this might be improved.

A coarser but library-compatible way of doing it is to keep a variable with your desired sleep time in it. Each time you wake up from sleep you test if the wake up was caused by interrupt or by the sleep time completing. If it was an interrupt, halve the value of your sleep time variable and call sleep again with the new value. If it was by sleep time expiring, reset your sleep time variable to your desired interval.

Here's a snippet from a recent sketch where I faced this issue:

if(sleep(1, CHANGE, (uint32_t)cycleTimer) == MY_WAKE_UP_BY_TIMER) { // Put the CPU to sleep, wake on interrupts
      #ifdef MY_DEBUG
        Serial.println("- Wake From Full Sleep Cycle -");
      #endif
      cycleComplete = true; // Flag that a full sleep cycle was completed
    } else {
      cycleTimer /= 2; // If we get woken from normal sleep by interrupt, halve the remaining cycle time
    }

Up in my main loop I use "cycleComplete" to flag that the sleep interval is over and it's time to send some messages, and in that routine "cycleTimer" gets reset to the full interval.

@gieemek Glad to hear it's working. I don't think SoftSPI needs to be atomic in its transactions the same way hardSPI does, so you're probably not missing anything important.

@gieemek Oh right, well I'm using hardware SPI so that would explain it. Good luck!

@gieemek Yes my gateway and sensors are very reliable now, using 2.2-beta from the dev branch and the new RFM69 driver.

Are you just trying to use the new driver by itself? Or have you updated the whole MySensors library to 2.2? I upgraded the whole library, I'm not sure how much success you'd have just updating the driver itself.

There are a few definitions changed in the library, anywhere that the old defs had MY_RF69 you have to change it to MY_RFM69 - Note the added M.

Here's the radio block from my gateway sketch:

#define MY_RADIO_RFM69
#define MY_RFM69_NETWORKID 137
#define MY_RFM69_ENABLE_ENCRYPTION
#define MY_RFM69_NEW_DRIVER
#define MY_IS_RFM69HW
#define MY_RFM69_FREQUENCY RFM69_433MHZ
#define MY_RFM69_IRQ_PIN 2
//#define MY_RFM69_IRQ_NUM  1
#define MY_RF69_SPI_CS 6
#define MY_RFM69_ATC_MODE_DISABLED
#define MY_RFM69_TX_POWER_DBM 20

IRQ_NUM seems deprecated now, but it works without it.

I disabled ATC_MODE just on my gateway when I was troubleshooting a different issue, but I don't care much about power consumption there so I didn't bother to enable it again.

Thanks, I will look at doing some stress testing I think. I'm starting to see the occasional missed message already and I'm only averaging 1 message per 3 seconds.

Does anyone know how the RFM modules handle collision/retransmission?

Has anyone done some testing to see what the maximum overall message rate the library/hardware can support? Or what happens when that rate is exceeded?

Failing that, does anyone have an idea of a ballpark figure or rule of thumb to keep the system stable?

How does MySensors deal with messages clashing? Is there a way to guarantee certain messages will get through? Or assign a higher priority to some? Or is it up to the sketch author to send messages with the acknowledge flag set and then manually process ack receipts/retry on fails?

For reference my system is based on Arduino/RFM69-433/MQTT.

I've been slowly poking at these boards and I'm getting somewhere with the firmware, I should have something ready to put out there soon.

In the meantime though I designed a quick snap-together enclosure that I'm sending off for "Dirty" 3D printing:

This is my first time using Fusion 360 and designing something for 3D printing, hopefully it goes okay.

I wanted it to snap together in two halves around the board and be as low-profile as possible, hence why the base plate only covers half of the PCB and is mounted by one screw only. I designed it around using a CR2450 battery. I might also see if I can find a small lens or light pipe to put over the lux sensor so it gets a better read on the light level in the room.

Here's my first 5 multi-sensors assembled and they've passed simple hardware tests. Although I think I have 2 that have PIRs that won't settle down. Thanks for the design scalz!

Now to write some firmware for them... Any hints?

So far so good. I'm feeling tentatively like this problem may be solved in 2.2-beta, and my sensor network is starting to gain my trust again.

@scalz Thanks yeah I have upgraded all the nodes and they're all talking again on the new driver

I have upgraded the whole network to 2.2.0-beta using the new RFM69 driver. I started by upgrading just the gateway but it wasn't backwards compatible with the sensors. Maybe the new radio driver changes something.
Will wait and see if it fails again.

@gohan Thanks, I didn't realise 2.2 had been released yet

Edit: My bad, 2.2 hasn't been released it's the dev branch

Hi People,

I have built a MySensors network based on RFM69H modules, with an Ethernet MQTT Gateway built on Leonardo which I detailed here: https://forum.mysensors.org/topic/6249/mqtt-ethernet-gateway-using-leonardo-32u4-w5100-rfm69h-hard-spi
My three sensor nodes are mains-powered, a mix of Atmega328 and 32u4 doing temperature, environment, energy and HVAC control.
I'm building on Windows 7, Arduino 1.8.1, MySensors 2.1.1

It works really great most of the time, but I have an issue which has cropped up randomly and is starting to bug me a lot. Occasionally it seems like the gateway will just stop sending or receiving radio messages. None of the sensor reports get in nor do control signals get out. To resolve this I have to power cycle the gateway, and since I'm often away for long periods my system is completely paralysed until then. Sometimes it will work for a week or more without issue, and sometimes it will occur several times a day. I haven't been able to correlate the occurrences with anything that happens on the sensor network or the OpenHAB bus. Once I reset the gateway all of my other nodes re-join the network and start working again, so for now I have assumed they're all working properly and the fault lies within the gateway.

I started logging the debug output from the gateway, and the issue has occurred twice since then. Both times it seems to be related to the radio receiving a garbage packet of some kind. After then it seems like the gateway code cannot talk to the radio module correctly, but doesn't seem to do anything about that eg. reset the radio. It seems to pass sanity checks okay and assume everything is good.

Here's two examples of the garbage packets being received:

0;255;3;0;9;TSF:MSG:READ,11-47-153,s=240,c=4,t=205,pt=6,l=22,sg=0:A4709004C242000524F00D0381C00057D048B18C0808
0;255;3;0;9;!TSF:MSG:LEN,59!=29
0;255;3;0;9;TSM:READY:NWD REQ
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
0;255;3;0;9;TSF:SAN:OK

0;255;3;0;9;TSF:MSG:READ,144-0-0,s=160,c=5,t=0,pt=5,l=0,sg=1:117440612
0;255;3;0;9;!TSF:MSG:LEN,61!=32
0;255;3;0;9;TSF:SAN:OK
0;255;3;0;9;TSM:READY:NWD REQ
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
0;255;3;0;9;TSF:SAN:OK

The NWD - MSG SEND - SAN OK cycle repeats continuously thereafter, sometimes punctuated by attempts from the controller to send commands which never get out as such:

0;255;3;0;9;Message arrived on topic: sensors-in/2/4/1/0/2
0;255;3;0;9;!TSF:MSG:SEND,0-0-2-2,s=4,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:0
0;255;3;0;9;TSM:READY:NWD REQ
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
0;255;3;0;9;TSF:SAN:OK

It looks like the network discovery routine is succeeding, but I never see any activity on the gateway LEDs after the fault occurs so I assume it's returning a successful result without actually interrogating the network at all (maybe that's by design? I haven't gone digging to see).

The garbage packets could possibly be related to the Oregon Scientific weather station I have on my roof. I believe it communicates using PAM 433MHz and I wouldn't be surprised if it isn't friendly about sharing the spectrum and just talked over the MyS packets. This would fit with the randomness of the failure, since it requires a OS weather sensor to clash with a MyS sensor message. I would've thought (hoped) that the gateway would be able to ignore and recover from such an event though.

Any thoughts?

@scalz I ordered some boards and components which are on the way, but I can't find the source code anywhere?

Where might I find the source code?

TXS0104E

Yep, still running well. I have a few more sensors hanging off it now but I wouldn't say it's a stressful application, maybe 1-3 messages per 10 seconds.

The NRF modules may be 5V tolerant, but I'm using the RFM69 radio at 433MHz and they're definitely not.

I managed to get an RFM69 MQTT Gateway going: https://forum.mysensors.org/topic/6249/mqtt-ethernet-gateway-using-leonardo-32u4-w5100-rfm69h-hard-spi

Hi Folks,

I'm brand new at this MySensors thing, and I have struggled a lot trying to get a gateway going. I think I have mostly succeeded now though, so I thought I'd share how I got here and hopefully save others some trouble.

I'm using Arduino Leonardo which is the Uno-like board that has the ATMega32u4 processor. It has a couple of differences from the '328 varieties that will trip you up if you're not careful (at least, they certainly tripped me up). The hardware SPI pins are on the ICSP header, and the interrupt pin for the radio triggers a different INT vector, for example.

It's also a 5V chip, so I had to use a level converter for the radio module. I was lucky that my choice of prototyping shield for the Uno had a spot for SOIC-14 and so I populated it with TXS0104E and connected the radio through that. I connected the interrupt output from the radio module (DIO0) directly to the Atmel though.

I had to use some tinned wire to extend the pins on the ICSP header so they would connect through the W5100 shield and into the prototyping shield that I mounted the radio on. I connected the RFM69 chip-select to pin 6 of the Arduino, and used 3, 5, 7 for the LEDs.

I fumbled around for a long time before I realised that MySensors doesn't support the RFM69 module using SoftSPI. I think this should be made more clear on the Ethernet Gateway page. I ended up learning a lot about SPI and the W5100 Ethernet Shield, and came to the conclusion that the recent work on making SPI transactions atomic seems to have made sharing the SPI port possible. So I swapped out the RFM69 driver in the MySensors library with this one which includes the new SPI transaction features.

My sketch is posted below and it's mostly the stock MQTT client gateway with the config set appropriately. The only other change was the RFM driver swap I mentioned above.

*******************************
 *
 * REVISION HISTORY
 * Version 1.0 - Henrik Ekblad
 *
 * DESCRIPTION
 * The W5100 MQTT gateway sends radio network (or locally attached sensors) data to your MQTT broker.
 * The node also listens to MY_MQTT_TOPIC_PREFIX and sends out those messages to the radio network
 *
 * LED purposes:
 * - To use the feature, uncomment WITH_LEDS_BLINKING in MyConfig.h
 * - RX (green) - blink fast on radio message recieved. In inclusion mode will blink fast only on presentation recieved
 * - TX (yellow) - blink fast on radio message transmitted. In inclusion mode will blink slowly
 * - ERR (red) - fast blink on error during transmission error or recieve crc error
 *
 *
 */


// Enable debug prints to serial monitor
#define MY_DEBUG

// Enables and select radio type (if attached)
#define MY_RADIO_RFM69
#define MY_IS_RFM69HW
#define MY_RFM69_FREQUENCY RF69_433MHZ
#define MY_RF69_IRQ_PIN 2
#define MY_RF69_IRQ_NUM  1
#define MY_RF69_SPI_CS 6

#define MY_GATEWAY_MQTT_CLIENT

// Set this node's subscribe and publish topic prefix
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "sensors-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "sensors-in"

// Set MQTT client id
#define MY_MQTT_CLIENT_ID "sensors"

// Enable these if your MQTT broker requires usenrame/password
//#define MY_MQTT_USER "username"
//#define MY_MQTT_PASSWORD "password"

// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
#define MY_IP_ADDRESS 192,168,1,30

// If using static ip you need to define Gateway and Subnet address as well
#define MY_IP_GATEWAY_ADDRESS 192,168,1,254
#define MY_IP_SUBNET_ADDRESS 255,255,255,0

// MQTT broker ip address
#define MY_CONTROLLER_IP_ADDRESS 192,168,1,10

// The MQTT broker port to to open
#define MY_PORT 1883

/*
// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
//#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60
// Digital pin used for inclusion mode button
//#define MY_INCLUSION_MODE_BUTTON_PIN  3
*/

// Set LED blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Flash leds on rx/tx/err
#define MY_DEFAULT_ERR_LED_PIN 3 //3
#define MY_DEFAULT_RX_LED_PIN  5 //5
#define MY_DEFAULT_TX_LED_PIN  7 //7


#include <Ethernet.h>
#include <MySensors.h>

void setup()
{
}

void presentation()
{
	// Present locally attached sensors here
}


void loop()
{
	// Send locally attached sensors data here
}