Sensor presentation failure



  • 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.


  • Mod

    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.



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


  • Contest Winner

    @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.


  • Contest Winner

    @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.



  • @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.


  • Contest Winner

    @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.


  • Mod

    @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.


Log in to reply
 

Looks like your connection to MySensors Forum was lost, please wait while we try to reconnect.