Thanks for the suggestion, this is so far I have come as well. That is, I will use a regular moteino connected to a raspberry pi that I connect to the network in the barn. If I give it a separate network ID it should not be in conflict with what I use inside my house, and I believe that domoticz should have no issues with to different mysensors gateways connected. Lucky I installed broadband in my barn just last week :-)

@DavidZH i have thought the same, but that software is an very simple script. Still, you might be right.

Hi,

I upgraded my gateway to the release version 2.0 using a moteino with a rfm69 radio attached. After one or two days the gateway stops responding. It is connected by a 20 cm USB cable directly to my computer. On the computer side I am running the latest version of domoticz which pings the Gateway every 10 seconds or so. since I have issues with connecting to many serial devices I am running it through a serial-socket Gateway script (python) that forwards all data from the socket to the serial port and vice versa. A usual sequence looks like this:

Received socket: 0;0;3;0;18;PING
Received serial: 0;255;3;0;22;23458138
Received serial: 0;255;3;0;9;TSP:SANCHK:OK

When things stop workingit continues sending pings to the Gateway, but no response is received, nor any other messages. It is usually resolved by reconnecting to the serial port, but sometimes I need to physically unplug the device to reset it. Have anyone else experienced such stability issues?

One on my sensors is mounted quite far away with spotty radio coverage. This means that the sensor will not always boot correctly since it is not able to reach the Gateway (apparently the sensor hangs on initialisation while trying to initiate a connection with the Gateway). A radio connection is not critical for me since I have a local interface on the sensor to actuate it and display readings. However, this feature prevents the sensor from operating locally. Is there a way to instruct the library to give up if the initial radio communication fails and work in some kind of "off-line" mode?

I have a generic multi meter, but I was not able to measure the current with this. I'm not sure why, I put it between the battery and the final connection terminal of the battery compartment.

I am not getting frequent reports, so if you are right that means that sleep is working as you suggest. I believe the weather shield is not drawing much power, it is simply a collection of a temperature and humidity sensor, a barometric pressure sensor, and a battery voltage reading circuit which is switched off when not used. More information about this shield is here: http://lowpowerlab.com/blog/2015/01/30/weathershield-is-here/.

Hi guys,

I have a battery-powered moteino with the RFM96 radio and a WeatherShield attached for environment measurements (and for hardware simplicity). I am powering everything from 3 1.5 V AA cells in series.

The node sleeps for 900000 seconds after reading the various sensor measurements from the board (temperature, humidity, pressure, and battery level). I set the node up last night and it lasted for around seven hours before the battery ran out. Apparently it appears not to be sleeping as it should. What am I doing wrong? Sketch is included below.

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_RFM69
#define MY_IS_RFM69HW
#define MY_RFM69_FREQUENCY   RF69_868MHZ

#include <SPI.h>
#include <MySensors.h>

#include <DHT.h>
#include <SFE_BMP180.h>    //get it here: https://github.com/LowPowerLab/SFE_BMP180
#include <SI7021.h>        //get it here: https://github.com/LowPowerLab/SI7021
#include <Wire.h>

#define REPORT_INTERVAL 900000
#define ALTITUDE 220


#define CHILD_TEMPERATURE 1
#define CHILD_HUMIDITY 2
#define CHILD_PRESSURE 3
#define CHILD_POWER 4

SI7021 sensor;
SFE_BMP180 pressure;
int BATTERY_SENSE_PIN  = A7;  // select the input pin for the battery sense point
char *weather[] = {"stable", "sunny", "cloudy", "unstable", "thunderstorm", "unknown"};
int minutes;
float pressureSamples[180];
int minuteCount = 0;
bool firstRound = true;
float pressureAvg[7];
float dP_dt;

MyMessage temperatureMessage(CHILD_TEMPERATURE, V_TEMP);
MyMessage humidityMessage(CHILD_HUMIDITY, V_HUM);
MyMessage pressureMessage(CHILD_PRESSURE, V_PRESSURE);
MyMessage forecastMsg(CHILD_PRESSURE, V_FORECAST);
MyMessage powerMessage(CHILD_POWER, V_VOLTAGE);

bool changed = false;
float lastPressure = -1;
float lastTemperature = -1;
float lastHumidity = -1;
int lastForecast = -1;
float lastBattery = -1;
void setup()
{
  // use the 1.1 V internal reference
#if defined(__AVR_ATmega2560__)
  analogReference(INTERNAL1V1);
#else
  analogReference(INTERNAL);
#endif
  sensor.begin();
  if (pressure.begin())
    Serial.println("BMP180 init success");
  else
  {
    // Oops, something went wrong, this is usually a connection problem,
    // see the comments at the top of this sketch for the proper connections.

    Serial.println("BMP180 init fail\n\n");
    //while(1); // Pause forever.
  }
}

void presentation()  {
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("Outdoors environment", "2.0");

  // Register all sensors to gateway (they will be created as child devices)
  present(CHILD_TEMPERATURE, S_TEMP);
  delay(250);
  present(CHILD_HUMIDITY, S_HUM);
  delay(250);
  present(CHILD_PRESSURE, S_BARO);
  delay(250);
  present(CHILD_POWER, S_POWER);

}

void loop()
{
  changed = false;
  float temperature = sensor.getCelsiusHundredths() / 100;
  int humidity = sensor.getHumidityPercent();
  if (lastTemperature != temperature) {
    changed = true;
    lastTemperature = temperature;
  }
  if (lastHumidity != humidity) {
    changed = true;
    lastHumidity = humidity;
  }

  pinMode(A3, OUTPUT);
  digitalWrite(A3, LOW);
  lastBattery = analogRead(A7) / 10;
  pinMode(A3, INPUT);
#ifdef MY_DEBUG
  float batteryV  = lastBattery * 0.003363075 * 10;
  Serial.print("Battery Voltage: ");
  Serial.print(batteryV);
  Serial.println(" V");

  Serial.print("Battery percent: ");
  Serial.print(lastBattery);
  Serial.println(" %");
#endif

  char status;
  double T, P, p0, a;
  status = pressure.startTemperature();
  if (status != 0)
  {
    // Wait for the measurement to complete:
    delay(status);

    // Retrieve the completed temperature measurement:
    // Note that the measurement is stored in the variable T.
    // Function returns 1 if successful, 0 if failure.

    status = pressure.getTemperature(T);
    if (status != 0) {

      status = pressure.startPressure(3);
      if (status != 0)
      {
        delay(status);
        status = pressure.getPressure(P, T);
        if (status != 0)
        {
          p0 = pressure.sealevel(P, ALTITUDE); // we're at 1655 meters (Boulder, CO)
          int forecast = 5;//sample(p0);
          if (lastPressure != p0) {
            changed = true;
            lastPressure = p0;
            Serial.print("relative (sea-level) pressure: ");
            Serial.print(p0, 2);
            Serial.print(" mb, ");
          }
          if (lastForecast != forecast) {
            changed = true;
            lastForecast = forecast;
          }
        }
        else Serial.println("error retrieving pressure measurement\n");
      }
      else Serial.println("error starting pressure measurement\n");
    }
    else Serial.println("error retrieving temperature measurement\n");
  }
  else Serial.println("error starting temperature measurement\n");

  if (changed) {
    send(temperatureMessage.set(lastTemperature, 1));
    send(pressureMessage.set(lastPressure, 1));
    send(humidityMessage.set(lastHumidity, 1));
    sendBatteryLevel( lastBattery);
    if (lastForecast > -1)
      send(forecastMsg.set(weather[lastForecast]));
  }
  sleep(REPORT_INTERVAL);
}

Hello again.

As a temporary fix I found a simple TCP/serial Gateway Python snippet that handles the connection to the serial mysensors device and provides a TCP interface to openhab. Switching the binding of aggression from serial to socket and having it connected to this software gateway removes the core dump issue. This confirms my suspicions that the issues are with the serial port library.

It works okay as a workaround until someone figure something out :-)

If anyone else is having issues with the serial connection, this is the by then snippet I found and used:

https://github.com/pyserial/pyserial/blob/master/examples/tcp_serial_redirect.py

After a full computer crash (overheated CPU, CPU fan stopped working) I'm trying to set everything up on a new computer. Using the latest openhab2 beta 3 I'm having issues with using this binding. Specifically, whenever I add my standard thing configuration I get a buffer overflow in openhab which results in a core dump.

I have downloaded latest binding from the link at github, but that did not affect it. In addition to this binding I am using the zwave binding and rfxcom binding. All three connect to devices through serial ports, although I I'm not sure if they do it in the same way.

You may recall that I have had trouble using these three bindings together earlier, but for some reason things worked out and it has worked quite reliably since then.

I'm not sure which information from the system crash is useful, but if there is anything I can send you to help you figure out what happens, let me know. Also, I realise that this problem might not be related directly with mysensors, but maybe with the serial library used (I saw a reference to NVJavaSeria in the stack trace after the crash.

@mfalkvidd The cable had some kind of repeater on it, and my rfxtrx433 has worked perfectly all the time, even with the MS gateway connected, so I thought the MS gateway should work also ☺️

@lafleur I have also updated my local RFM69 library to the latest version with some additional changes to solve issues with acknowledgements not being received. If you're interested, you can see my conclusion here: https://forum.mysensors.org/topic/3663/testing-development-branch-with-rf69hw-is-not-working-as-it-should/12

I also link to a separate thread over at the low-power forum where things are discussed in more detail. If we are planning to upgrade the RFM library I propose that we include the fix I found. The only problem is that this fix is mostly a temporary solution, so perhaps it is better to wait until the issue is fixed in the library itself.

I do not know what happened to the other guy, but for my problems everything was related to the radio not receiving packets correctly when waking from sleep as I described in the thread. After resolving that issue, and switching to a frequency (from 868 to 869) outside of the allowed band because of radio noise my network became quite stable.

I did not post any more to the thread since I had already described my solution that worked :-). I think the problem I'm seeing now is not related to the same thing. My current theory is maybe that my USB cable was too long (15 m) so that the device did not receive enough power. I have moved closer to the computer to see if stability improves.

After finally getting my sensible indication to work quite reliably, I'm experiencing problems with my serial gate on the dev branch as of some weeks ago. It works fine for several days, but at some point it stops responding. Restarting the serial connection is not sufficient, I have to physically unplug it to get it to respond again. I'm not sure if this is a problem with the board or software related? Has anyone else experienced similar issues? I'm using a moteino USB board with the RFM69HW radio.

It seems like my sensors are quite stable, they have not crashed for several weeks of operation.

@andreacioni Sure, getting automatically configured alerts both for silent sensors and low battery for free would be great ☺️.

@andreacioni This can be easily done with a periodic rule that checks the latest update of the value assuming you have some persistence like rrd configured.

A simple thing you can do in RFM69Transport is to increase the retry count for the messages that are sent. The default value is 2 (implicit), to increase this by changing the following:

return _radio.sendWithRetry(to,data,len);

to

return _radio.sendWithRetry(to,data,len, 5);

To have it retry five times.

My guess is that this will greatly increase the operation time of your network.

@BenCranston For testing the noise I simply print the result from readRSSI() inside the radio library inside the canSend function to the serial connection. The reason for doing it like this is that the radio is very picky about which mode it has to be in for reporting the rssi value. I used the node example from the RFM69 as the basis for this test. At the beginning of RFM69.cpp there are three lines that initialise the radio with the correct frequency. This can be changed to shift the frequency up or down a few megahertz.

I'v never had a chance/need to look into the routing functionality (although I actually have a PhD in network routing), so I cannot comment much on this. From your description the basic problem is that the gateway for some reason fails to respond, or that the response from the gateway is not captured by the node. The resulting routing flood seems like the natural consequence of this. This is why i pointed to the latest developments in my testing since you're better off solving the thing that triggers the rerouting rather than fixing any rerouting problems yourself :-)

@BenCranston I'm glad the fix the proposed helped out, but too bad it was not good enough. It might be worth catching up on the latest few developments in the thread. Basically it turns out that changing all references to standby to sleep in the setMode function is a bit overkill. Maybe this is also causing some of your trouble. The current version of the fix consists of putting the radio to sleep in receiveBegin, like this:

void RFM69::receiveBegin() {
    DATALEN = 0;
    SENDERID = 0;
    TARGETID = 0;
    PAYLOADLEN = 0;
    ACK_REQUESTED = 0;
    ACK_RECEIVED = 0;
    RSSI = 0;
    setMode(RF69_MODE_SLEEP);
    if (readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_PAYLOADREADY)
       writeReg(REG_PACKETCONFIG2, (readReg(REG_PACKETCONFIG2) & 0xFB) |  RF_PACKET2_RXRESTART); // avoid RX deadlocks
    writeReg(REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_01); // set DIO0 to  "PAYLOADREADY" in receive mode
    setMode(RF69_MODE_RX);
}

In my case it also turned out that the RF environment around 868 MHz was a bit noisy. This messed with the CSMA function which always caused the node to wait a second before transmitting the message since the channel was never quiet enough. This limit is controlled by CSMA_LIMIT which I set to -40 instead of -90. Actually, what I ended up doing was to switch the frequency down 1 MHz, to 867, which was a much quieter band. The trouble with the high noise floor was that the gateway had trouble hearing the nodes that were far enough away to have a received RSSI less than -60 when the noise floor was -55. It could be worth continuously printing the RSSI of the channel at the gateway without anyone transmitting to see what your background noise is.

Now that things seem to be working on all levels, I have a very small request. Could someone please update the "baro" thing definition to include "V_PRESSURE" as well as "V_FORECAST"? My arduino is not big enough to calculate the forecast without running out of memory, so I can only send the actual barometric pressure.

Edit: Perhaps it is better to replace forecast with pressure for baro and create a new channel for the forecast?

What would also have been great, but this is a longer shot, would be to have some standardised way of getting received signal strength for the (at least directly connected) sensors. At least the RFM69 has an easy way of reporting RSSI, so just need a standard way of reporting this to the binding. Currently I'm reporting it as a generic debug message like this: 0;255;3;0;9;Received RSSI: -32

The reason I want to keep track of this is to keep an eye on the RF environments around my sensors. Things may change for many reasons (appliances, foliage, et cetera) and this will allow me to pre-emptively correct any problems in the future :-)

I just tried disconnecting and reconnecting the board and restarting OH2 again, and this time it seems to have initialised correctly :-). I'm not sure why it didn't work the first two times, though.