Sensor presentation failure

[Sergio Rius]

I'm just now working with the MS v2.0. Using a NodeMCU wifi gateway and Domoticz, I've done a testing sketch for controlling a discrete number of switches.
In my presentation function, I noticed that if I register all the sensors in series, through a loop, the gateway would reply fail for some of the sensors.
As I noticed that those where almost always odd iterations, I simply put an sleep after every iteration and that makes it work.

An example:

void presentation() 
{
	sendSketchInfo("myTestSketch", "1.0");
	for (int i = 0; i < 10; i++) {
		present(i, S_LIGHT, "mySensor");
		sleep(500); //Commenting this line brings back the problem.
	}
}

Is that the normal behaviour or is it a Bug?

Regards,
Sergio.

[mfalkvidd]

Waiting or sleeping between presentation is a common workaround. The problem can be power related but since waiting usually solves the problem and presentation only happens at startup I don't think anyone has spent the time required to dig deeper.

[Sergio Rius]

I understand.
Also it can be a power issue. By that you're referring to a gateway or a sensors power issue?

[TheoL]

@mfalkvidd It's not always a power issue. If you have node with a lot of children it's always good to add a small wait between each presentation. At least in 1.5. I wrote a blocking method specially for that purpose.

void blockingPresentChild( uint8_t childSensorId, uint8_t sensorType, const char *description, bool ack ) {
  gw.present( childSensorId, sensorType, description, ack );  // present to controller
  gw.wait( 50 );
  switch ( sensorType ) {
    case S_BINARY:
      gw.request( childSensorId, V_LIGHT );
      break;
  }
  gw.wait( 50 );
}

In this case is also requests the current state for V_LIGHT sensors. I call it like this in the setup() method.

  gw.begin( incomingMessage, NODEID, false );      // initialize MySensors with static Node id
  gw.sendSketchInfo( "Generic node GNDC", "1.0"); // Present a generic door chime node.
  gw.wait( 50 );
  blockingPresentChild( FIRST_PIRSENSOR_CHILD_ID, S_MOTION, FIRST_PIRSENSOR_DESCRIPTION, true );
  blockingPresentChild( FIRST_DOORSENSOR_CHILD_ID, S_DOOR, FIRST_DOORSENSOR_DESCRIPTION, true );
  blockingPresentChild( SECOND_DOORSENSOR_CHILD_ID, S_DOOR, SECOND_DOORSENSOR_DESCRIPTION, true );
  blockingPresentChild( THIRD_DOORSENSOR_CHILD_ID, S_DOOR, THIRD_DOORSENSOR_DESCRIPTION, true );
  blockingPresentChild( DOORBELL_SWITCH_CHILD_ID, S_DOOR, DOORBELL_SWITCH_DESCRIPTION, true );
  blockingPresentChild( PLAY_CHIME_CHILD_ID, S_LIGHT, PLAY_CHIME_DESCRIPTION, true );
  blockingPresentChild( DOORBELL_MUTED_CHILD_ID, S_BINARY, DOORBELL_DESCRIPTION, true );
}

Don't know if this is still necessary in MySensors 2.0. But I used to get a lot of fails in the communication just adding a small delay works like a charm for me.

[TheoL]

@Sergio-Rius The 500 might be too much. Also I suggest to use a wait instead of sleep. When you put your node to sleep, the radio is also sleeping so you might missing some communication the gateway sends to your node.

[Sergio Rius]

@TheoL
Thanks! I'm just a novice arduino programmer. I was more thinking on the legacy language sleep. I'll try that wait(50)

Very interesting function that blockingPresentChild. I was to load the states in a separate/dedicated function. I find yours more efficient.

[TheoL]

@Sergio-Rius Thank you! It's part of a library I'm working on, which just handles all the binary switch logic for you. Learning how to program is hard enough, so I'm trying to make it easier for new MySensors users. I'll be pushing it to my github in a couple of days. When I'm done testing.

[Yveaux]

@Sergio-Rius a Nrf24 radio can only buffer 3 incoming messages. If you send more messages at a very fast rate you might overflow the buffer at the gateway and start to loose messages. It all depends on the rate at which your node sends messages (that's why the delay improves things) and the speed at which the gateway processes incoming messages.
I have some code under test which increases the buffer at the gateway side, by retrieving new messages as soon as they come in, which might help.
Until then, just use a delay.

[Danielo Rodríguez]

@yveaux thanks for that piece of information!!
This was driving me crazy. I know this is an old thread, but this is still a problem today.
I think this should be added to the documentation and probably add one example with this setup properly working.

[Jonnyd]

Its still a problem in V2.xx and occurs when you have more than one sensor. Not battery related - all my sensors are mains powered. One of my nodes has 5 sensors - 2 others only have two. One is a sensebender - the other two are nano's. All exhibited this behaviour. Using mysensors 2.3.2 and a wifi gateway. wait( 50 ) between presentations fixes the problem every time.

[TheoL]

@Yveaux I also add the delay to not ddos the gateway. When I did the MySensors workshop, 20 people started to connect to the gateway almost at the same time. And they got Funky messages. Since then I do a delay. But it would probably be better to add a random time to the delay. Something like 20ms + random( 0 - 30 ) ms. That way you don't get the ddos effect. Sonoff had the same problems with their solution a couple of years ago, when the servers went down. All Sonoff devices tried to reconnect almost the at the same time. Which caused a ddos xd