Communication problem (maybe)

[Hausner]

Hi,

I have a UNO R3 as a MQTT GW and some temp sensors (mini pro 5v) and 1 actuator relay sensor (a nano).

The problem is that the comm to the actuator node keeps "partly" dropping out. Yes, I know it sound wierd, but this is what happens.

On relay actuator powerup, everything works as planned. I can see the relay on the GW console. The temp sensors then use the relay actuator sensor as a repeater to report temp. It all works. So far so good.

Now, if I send some commands to the relay actuator (switch on a relay) it works, but no more than 5-10 times, then the GW reports

   <<30 16 00 13 4D 79 4D 51 54 54 2F 32 32 2F 32 2F 56 5F 4C 49 47 48 54 30 
  0;0;3;0;9;send: 0-0-22-22 s=2,c=1,t=2,pt=0,l=1,st=fail:0

The relay node however keeps functioning as a repeater node, even though, it has stopped to respond on actuator "SET" commands.

This is the relay actuator booting seen from the GW

   0;0;3;0;9;read: 22-22-0 s=255,c=0,t=18,pt=0,l=3:1.4
   0;0;3;0;9;read: 22-22-0 s=255,c=3,t=6,pt=1,l=1:0
   0;0;3;0;9;send: 0-0-22-22 s=255,c=3,t=6,pt=0,l=1,st=ok:M
   0;0;3;0;9;read: 22-1-0 s=255,c=3,t=6,pt=1,l=1:0
   0;0;3;0;9;send: 0-0-1-22 s=255,c=3,t=6,pt=0,l=1,st=fail:M
   0;0;3;0;9;read: 22-22-0 s=255,c=3,t=11,pt=0,l=5:Relay
   0;0;3;0;9;read: 22-22-0 s=255,c=3,t=12,pt=0,l=3:1.0
   0;0;3;0;9;read: 22-22-0 s=1,c=0,t=3,pt=0,l=3:1.4
   0;0;3;0;9;read: 22-22-0 s=2,c=0,t=3,pt=0,l=3:1.4
   0;0;3;0;9;read: 22-22-0 s=3,c=0,t=3,pt=0,l=3:1.4
   0;0;3;0;9;read: 22-22-0 s=4,c=0,t=3,pt=0,l=3:1.4
   0;0;3;0;9;read: 22-22-0 s=5,c=0,t=3,pt=0,l=3:1.4

and seen from the node:

 repeater started, id 22
 send: 22-22-0-0 s=255,c=0,t=18,pt=0,l=3,st=ok:1.4
 send: 22-22-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
 read: 0-0-22 s=255,c=3,t=6,pt=0,l=1:M
 send: 22-22-0-0 s=255,c=3,t=11,pt=0,l=5,st=ok:Relay
 send: 22-22-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
 send: 22-22-0-0 s=1,c=0,t=3,pt=0,l=3,st=ok:1.4
 send: 22-22-0-0 s=2,c=0,t=3,pt=0,l=3,st=ok:1.4
 send: 22-22-0-0 s=3,c=0,t=3,pt=0,l=3,st=ok:1.4
 send: 22-22-0-0 s=4,c=0,t=3,pt=0,l=3,st=ok:1.4
 send: 22-22-0-0 s=5,c=0,t=3,pt=0,l=3,st=ok:1.4

The GW and relay node are now only 20cm apart because I thought it could be a bad signal problem, but then again, it works fine in it's original place when it's only repeating temp sensors. As soon as I send the actuator "switch on" commands, the relay actuator part starts to fail.

Any advise would be highly appreciated

[hek]

You must upgrade to 1.4.1

[Hausner]

I only see version 1.4 on the download page.

[hek]

You will get 1.4.1 when downloading.

[Hausner]

Yes, I figured that out, but the problem is still there...

Only 5-10 relay on/off, then it fails.

It actually looks like the GW never sends the new status. I see faild on GW, but nothing on the node?

[niccodemi]

@Hausner I've got same issues with relay nodes. Other sensor nodes work ok.

See this post for my serial output. At first I thought this is because of ethernet gw but now I am having similar issues with serial gw. I can switch relay on/off few times but after that node stops responding.

[hek]

How do you power you relays?

[Hausner]

I first tried with the nano, but (ofcause) that was insuffient.

So now the 8-channel relay is powered externally, via JD-VCC and GND. The nano has a 5v to the 5v on the relay pin which is next to the INx pins. Nothing on the GND.

[niccodemi]

Same here, relay is powered separately.

[Hausner]

@niccodemi said:

Same here, relay is powered separately.

Do you have the arduino and relay on shared GND?

[pgo]

Do you use sleep in some of the nodes? I found with sleep(xxx) the messages get dropped across the mesh... I found that by making multiple sensors in one node - http://forum.mysensors.org/topic/115/implementing-multiple-sensors/59 and it gets worse with going through repeaters. For example the lux sensor could be very active and then the Relay ON/OFF messages get dropped... Interesting I did never see a temp or lux node message got dropped through the mesh.
EDIT I am using MQTT broker gateway and open HAB, but will probably switch to MQTT client gateway<->mosquitto<->openHAB to check whether the message delivery gets more stable.

[Hausner]

@pgo

Yes, I have 3 temp nodes running on battery which uses the sleepmode.

But it doesn't matter if they are runnig or not, the result with the relay node is the same. With the battery nodes offline it does however seem more stable. At least I can get 3-4 times as many relay on/off before it fails.

I'm running the default MQTT GW, DallasTemperature Nodes and Relaynode sketches. OpenHAB as controller.

Something tells me, that I might have to go back to the serial GW on a Raspberry and then use the GPIO pins to control the relay. When that was running, I never had a single problem with messages getting dropped.

[niccodemi]

@Hausner yes, arduino and relay share ground. I use this node solely as relay (not repeater) and still have issues.

[Hausner]

I have now converted the 3 temp sensors to mains power and removed the sleep function, but the problem is still the same

I even let the temp nodes be repeaters! I looks like the GW can't SEND to the nodes, receiving is just fine. I'm getting "spammed" with temp readings atm.

I have already tried with a CAP on the GW radio, but still out of luck

Somehow this tells me, that mysensors is not for me

[Hausner]

UPDATE:

I was getting a bit frustrated with the relay node not working, so as a last resort, i decided to reset all the nodes. Starting with the temp nodes and the relay at the end.

And I'll be damned! The system has now been running 3-4 hours with only a single hickup! (a relay failed on first request)

So this tells me, that if you only have "1-way send" battery nodes in the mesh eg. temp sensors, then the "intelligent" mesh works fine, but as soon as you introduce main powered "recieve" nodes to the setup, it starts to fail (big time!). So pgo, you were right! I have just seen the same as you.

At the temp sensors, I have removed the sleep command. The only problem now is that i'm getting flooded with temp readings! Anyone know of a simple solution to only have reading every 1 min without killing the radio?

[daulagari]

So this tells me, that if you only have "1-way send" battery nodes in the mesh eg. temp sensors, then the "intelligent" mesh works fine, but as soon as you introduce main powered "recieve" nodes to the setup, it starts to fail (big time!).

Good observation but what is the difference between the "1-way send" battery nodes and the main powered "receive" nodes? Is it that the main powered nodes do send more often messages and therefore the network gets flooded?

I am not sure how this is related to "i decided to reset all the nodes. Starting with the temp nodes and the relay at the end."

On:

The only problem now is that i'm getting flooded with temp readings! Anyone know of a simple solution to only have reading every 1 min without killing the radio?

In there sketch there is:

// Fetch and round temperature to one decimal
float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;

// Only send data if temperature has changed and no error
if (lastTemperature[i] != temperature && temperature != -127.00) {

  // Send in the new temperature
  gw.send(msg.setSensor(i).set(temperature,1));
  lastTemperature[i]=temperature;
}

Right?

Is the temperature changing every minute??

[Hausner]

@daulagari

By 1-way node I mean a reporting node. It only reports a temperature, nothing else. So therefore 1 way traffic TO the GW/controller.

A relay node on the other hand has to receive also, else you can't flip on/off the relays.

This is roughly 1 minute worth of controller log:

 2014-11-13 04:49:27 - Helena_temp_LastUpdate state updated to 2014-11-13T04:49:27
 2014-11-13 04:49:28 - Temperature_GF_Helena state updated to 26.7
 2014-11-13 04:49:28 - Helena_temp_LastUpdate state updated to 2014-11-13T04:49:28
 2014-11-13 04:49:29 - Temperature_GF_Helena state updated to 26.6
 2014-11-13 04:49:29 - Helena_temp_LastUpdate state updated to 2014-11-13T04:49:29
 2014-11-13 04:49:30 - Temperature_GF_Helena state updated to 26.7
 2014-11-13 04:49:30 - Helena_temp_LastUpdate state updated to 2014-11-13T04:49:30
 2014-11-13 04:49:39 - Temperature_GF_Helena state updated to 26.6
 2014-11-13 04:49:39 - Helena_temp_LastUpdate state updated to 2014-11-13T04:49:39
 2014-11-13 04:50:07 - Temperature_GF_Living state updated to 24.3
 2014-11-13 04:50:07 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:07
 2014-11-13 04:50:08 - Temperature_GF_Living state updated to 24.2
 2014-11-13 04:50:08 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:08
 2014-11-13 04:50:12 - Temperature_GF_Living state updated to 24.3
 2014-11-13 04:50:12 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:12
 2014-11-13 04:50:14 - Temperature_GF_Living state updated to 24.2
 2014-11-13 04:50:14 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:14
 2014-11-13 04:50:15 - Temperature_GF_Helena state updated to 26.7
 2014-11-13 04:50:15 - Helena_temp_LastUpdate state updated to 2014-11-13T04:50:15
 2014-11-13 04:50:16 - Temperature_GF_Helena state updated to 26.6
 2014-11-13 04:50:16 - Helena_temp_LastUpdate state updated to 2014-11-13T04:50:16
 2014-11-13 04:50:16 - Temperature_GF_Living state updated to 24.3
 2014-11-13 04:50:16 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:16
 2014-11-13 04:50:16 - Temperature_GF_Living state updated to 24.2
 2014-11-13 04:50:16 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:16
 2014-11-13 04:50:18 - Temperature_GF_Living state updated to 24.3
 2014-11-13 04:50:18 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:18
 2014-11-13 04:50:19 - Temperature_GF_Helena state updated to 26.7
 2014-11-13 04:50:19 - Helena_temp_LastUpdate state updated to 2014-11-13T04:50:19
 2014-11-13 04:50:20 - Temperature_GF_Helena state updated to 26.6
 2014-11-13 04:50:20 - Helena_temp_LastUpdate state updated to 2014-11-13T04:50:20
 2014-11-13 04:50:20 - Temperature_GF_Living state updated to 24.2
 2014-11-13 04:50:20 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:20
 2014-11-13 04:50:20 - Temperature_GF_Helena state updated to 26.7
 2014-11-13 04:50:20 - Helena_temp_LastUpdate state updated to 2014-11-13T04:50:20
 2014-11-13 04:50:20 - Temperature_GF_Living state updated to 24.3
 2014-11-13 04:50:20 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:20
 2014-11-13 04:50:22 - Temperature_GF_Helena state updated to 26.6
 2014-11-13 04:50:22 - Helena_temp_LastUpdate state updated to 2014-11-13T04:50:22
 2014-11-13 04:50:23 - Temperature_GF_Living state updated to 24.2
 2014-11-13 04:50:23 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:23
 2014-11-13 04:50:24 - Temperature_GF_Living state updated to 24.3
 2014-11-13 04:50:24 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:24
 2014-11-13 04:50:26 - Temperature_GF_Helena state updated to 26.7
 2014-11-13 04:50:26 - Helena_temp_LastUpdate state updated to 2014-11-13T04:50:26
 2014-11-13 04:50:26 - Temperature_GF_Living state updated to 24.2
 2014-11-13 04:50:26 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:26
 2014-11-13 04:50:27 - Temperature_GF_Living state updated to 24.3
 2014-11-13 04:50:27 - Living_temp_LastUpdate state updated to 2014-11-13T04:50:27
 2014-11-13 04:50:29 - Temperature_GF_Helena state updated to 26.6
 2014-11-13 04:50:29 - Helena_temp_LastUpdate state updated to 2014-11-13T04:50:29

As you can see i'm getting way more than 1 reading a second. I think this is happening because of the rounding up/down of the temperature readings.

[hek]

Please post your sketch code. And to which pins you have connected sensors.

[Hausner]

Temperatur sensor

 // Example sketch showing how to send in OneWire temperature readings
 #include <MySensor.h>  
 #include <SPI.h>
 #include <DallasTemperature.h>
 #include <OneWire.h>
 
 #define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected 
 #define MAX_ATTACHED_DS18B20 16
 unsigned long SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)
 OneWire oneWire(ONE_WIRE_BUS);
 DallasTemperature sensors(&oneWire);
 MySensor gw;
 float lastTemperature[MAX_ATTACHED_DS18B20];
 int numSensors=0;
 boolean receivedConfig = false;
 boolean metric = true; 
 // Initialize temperature message
 MyMessage msg(0,V_TEMP);
 
 //int BATTERY_SENSE_PIN = A0; // select the input pin for the battery sense point
 //int oldBatteryPcnt = 0;
 
 void setup()  
 { 
   // Startup OneWire 
   sensors.begin();
 
   // Startup and initialize MySensors library. Set callback for incoming messages. 
   gw.begin(); 
 
   // Send the sketch version information to the gateway and Controller
   gw.sendSketchInfo("Temperature Sensor", "1.0");
 
   // Fetch the number of attached temperature sensors  
   numSensors = sensors.getDeviceCount();
 
   // Present all sensors to controller
   for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {   
      gw.present(i, S_TEMP);
   }
   
   // use the 1.1 V internal reference
   //analogReference(INTERNAL);
 }
 
 
 void loop()     
 {     
   // Process incoming messages (like config from server)
   gw.process(); 
 
   // Fetch temperatures from Dallas sensors
   sensors.requestTemperatures(); 

   // Read temperatures and send them to controller 
   for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {

   // Fetch and round temperature to one decimal
   float temperature = static_cast<float>(static_cast<int>  ((gw.getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;

// Only send data if temperature has changed and no error
if (lastTemperature[i] != temperature && temperature != -127.00) {

  // Send in the new temperature
  gw.send(msg.setSensor(i).set(temperature,1));
  lastTemperature[i]=temperature;
}
   }

// get the battery Voltage
//int sensorValue = analogRead(BATTERY_SENSE_PIN);
//Serial.println(sensorValue);
// 1M, 470K divider across battery and using internal ADC ref of 1.1V
// Sense point is bypassed with 0.1 uF cap to reduce noise at that point
 // ((1e6+470e3)/470e3)*1.1 = Vmax = 3.44 Volts
 // 3.44/1023 = Volts per bit = 0.003363075
//float batteryV = sensorValue * 0.004106;
//int batteryPcnt = sensorValue / 10;
 //Serial.print("Battery Voltage: ");
   //Serial.print(batteryV);
   //Serial.println(" V");
   //Serial.print("Battery percent: ");
   //Serial.print(batteryPcnt);
   //Serial.println(" %");
   //if (oldBatteryPcnt != batteryPcnt) {
   // Power up radio after sleep
   //gw.sendBatteryLevel(batteryPcnt);
   //oldBatteryPcnt = batteryPcnt;
   //}

   //gw.sleep(SLEEP_TIME);
 }

The temp sensor has been build according to this: http://mysensors.org/build/temp
1 small exception though. I have used 5v->3.3v aparters for the radios, but that shouldn't matter.

[hek]

@Hausner said:

//gw.sleep(SLEEP_TIME);

Why did you comment away this line?

[Hausner]

@hek

Because it looks like that the sleep function is messing with the repeater function. With sleep enabled, almost all messages to the relay actuator node gets lost.

[hek]

Hmm.. shouldn't affect transmissions. When you removed this line you will get several hundreds of temp readings per second. It is a very big chance a few of them differs which means they will send it to gateway.

You could try adding:
gw.powerUp();
delay(10)
Just before gw.send() to add a small some additional delay after radio powers up.

If you want to keep node awake another option is to use millis() keep track of send frequency. See here:
https://github.com/mysensors/Arduino/blob/master/libraries/MySensors/examples/TimeAwareSensor/TimeAwareSensor.ino#L47

[Hausner]

@hek said:

delay(10)

I assume that is milliseconds, but does that mean that the radio will be powered on during that delay, and will the node repeat incoming messages during that?

If so, I think a much bigger delay would be better, like 30000 or even more.

[hek]

This node isn't configured to be a repeater. So no, it won't.

[Hausner]

It isn't??

hmm... now i'm puzzled!

Cause this is 2 temp nodes

0;0;3;0;9;read: 24-23-0 s=0,c=1,t=0,pt=7,l=5:23.8

My relay actuator is 22

[niccodemi]

@Hausner do you have any issues with relay node if you are NOT using it also as repeater?

[hek]

If so, I think a much bigger delay would be better, like 30000 or even more.

Yes, thats is actually a third option like you say. Just add a delay(30000) at the end of loop(). (If this node just acts a as a temp sensor and nothing else).

[pgo]

@Hausner I send the temp changes only if change is > 1 deg C and light changes only > +/- 40 lux, have this in main loop:

void loop()     
{     
  // Process incoming messages (like config from server)
  gw.process(); 

  // Fetch temperatures from Dallas sensors
  sensors.requestTemperatures(); 

  // Read temperatures and send them to controller 
  for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {

    // Fetch and round temperature to one decimal
    float temperature = static_cast<float>(static_cast<int>((gw.getConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;

    // Only send data if temperature has changed more then 1 degC and no error
    if (int(lastTemperature[i]) != int(temperature) && temperature != -127.00) { //added integer

      // Send in the new temperature
      gw.send(msg.setSensor(i).set(temperature,1));
      lastTemperature[i]=temperature;
    }
  }
  // Read lux from TEMT6000
  float lightLevel = analogRead(LIGHT_SENSOR_ANALOG_PIN) * 9.765625;  // 1000/1024
  if (int(lightLevel - lastLightLevel) > 40 || int(lastLightLevel - lightLevel) > 40) {
      gw.send(msg.setSensor(CHILD_ID_LIGHT).set(int(lightLevel),1));
      lastLightLevel = lightLevel;
  }
  //gw.sleep(SLEEP_TIME); //no sleep for relays!!!!
}

Hope this helps, Pego

[daulagari]

As you can see i'm getting way more than 1 reading a second. I think this is happening because of the rounding up/down of the temperature readings.

Yes, clear, if you do not want this you need to change the if to something like:

if (abs(lastTemperature[i] - temperature) >= 0.5 && temperature != -127.00) {

[Hausner]

@daulagari

Thank you. I'm gonna try with this

if (abs(lastTemperature[i] - temperature) >= 0.2 && temperature != -127.00) {