RelayWithButtonActuator problem after toggling with pushbutton



  • Hi,

    I'm struggling with the example RelayWithButtonActuator.ino sketch.
    After uploading the sketch to my Arduino Nano, I get the following scenario :
    At first, when I toggle the relay from Openhab via MQTT, then all seems to work fine, but after I toggle the relay with the local_button pin3, then I get the problem that the state always remains 1 for subsequent toggles (either from openhab, either from local button).
    The serial monitor shows this (see below) : you can, at the last lines, see that indeed status remains 1.
    I'm guessing it has to do with the gw.saveState.
    Any hints ?
    Or is this hardware related ?
    I've loaded to different arduino's & radio's with the same result ...
    Thanks for any help.

    Incoming change for sensor:28, New status: 0
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8,sg=0:1D004113
    Incoming change for sensor:28, New status: 1
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8,sg=0:0D004113
    Incoming change for sensor:28, New status: 0
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8,sg=0:1D004113
    Incoming change for sensor:28, New status: 1
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8,sg=0:0D004113
    Incoming change for sensor:28, New status: 0
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8,sg=0:1D004113
    Incoming change for sensor:28, New status: 1
    send: 28-28-0-0 s=28,c=1,t=2,pt=2,l=2,sg=0,st=ok:0
    read: 0-0-28 s=28,c=1,t=2,pt=2,l=2,sg=0:0
    This is an ack from gateway
    Incoming change for sensor:28, New status: 0
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8,sg=0:07204113
    Incoming change for sensor:28, New status: 1
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8,sg=0:17204113
    Incoming change for sensor:28, New status: 1
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8,sg=0:07204113
    Incoming change for sensor:28, New status: 1
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8,sg=0:17204113
    Incoming change for sensor:28, New status: 1
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8,sg=0:07204113
    Incoming change for sensor:28, New status: 1



  • Ok,

    I've investigated further and now I suspect my MQTT Client gateway which is 1.4 based. While the relay sketch is 1.5 based ... could this be the problem ?
    What I did was strip-out the RelayWithButtonActuator sketch to the bare mimimum, keeping it as (see below)

    I can verify that OpenHAB sends correct MQTT messages to the Mosquito broker. (Via MQTT lens)
    I assume that the MQTT Client picks them up correctly via ethernet.
    But when the communication arrives at the sensor node, it oftenreads out state=1 when it should be 0.

    I'm reluctant to upgrade my MQTT Client to 1.5 because it has so far worked very well with about 8 sensornodes connected.

    Thanks for any advise.
    DirkB

    #include <MySensor.h>  
    #include <SPI.h>
    #define CHILD_ID 28   // Id of the sensor child
    #define RELAY_PIN  4  // Arduino Digital I/O pin number for relay 
    #define RELAY_ON 1
    #define RELAY_OFF 0
    
    int node_id = 28;
    boolean state = false;
    MySensor gw;
    MyMessage msg(CHILD_ID,V_STATUS);
    
    void setup()  
    { 
      gw.begin(incomingMessage, node_id, false);
    
      // Send the sketch version information to the gateway and Controller
      gw.sendSketchInfo("RELAY", "node28");
    
        // Register all sensors to gw (they will be created as child devices)
      gw.present(CHILD_ID, S_BINARY);
    
        // Make sure relays are off when starting up
      digitalWrite(RELAY_PIN, RELAY_OFF);
      // Then set relay pins in output mode
      pinMode(RELAY_PIN, OUTPUT);   
          
      // Set relay to last known state (using eeprom storage) 
      // state = gw.loadState(CHILD_ID);
      Serial.print(", Loaded  status from gw: ");
      Serial.println(state);
      digitalWrite(RELAY_PIN, state?RELAY_ON:RELAY_OFF);
    }
    
    
    void loop()     
    {     
      // Process incoming messages (like config from server)
      gw.process();
    }
    
    
    void incomingMessage(const MyMessage &message) {
      // We only expect one type of message from controller. But we better check anyway.
      if (message.isAck()) {
         Serial.println("This is an ack from gateway");
      }
    
      if (message.type == V_STATUS) {
         // Change relay 
         state = message.getBool();
         digitalWrite(RELAY_PIN, state?RELAY_ON:RELAY_OFF);
         // Store state in eeprom
         // gw.saveState(CHILD_ID, state);
        
         // Write some debug info
         Serial.print("Incoming change for sensor:");
         Serial.print(message.sensor);
         Serial.print(", New status: ");
         Serial.println(message.getBool());
       } 
    }
    


  • Meanwhile, I re-compiled the skech with 1.4 Library. So the sensor-sketch and MQTT CLIENT GATEWAY now have compiled with the same library.
    Still same problem.
    I'm getting desperate here.
    I've build many sensors and know how to decouple radio etc. so I don't believe hardware is the problem.
    Thank you for any hint.


  • Contest Winner

    Hi @DirkB19,

    I don't know anything about MQTT. But I've noticed a couple of things. Don't think it'll solve your problem though. I'll put my comment's in your code

    setup()

    void setup()  
    { 
      gw.begin(incomingMessage, node_id, false);
    
      // Send the sketch version information to the gateway and Controller
      gw.sendSketchInfo("RELAY", "node28");
    
        // Register all sensors to gw (they will be created as child devices)
      gw.present(CHILD_ID, S_BINARY);        // No expert on this, but I use S_LIGHT
    
        // Make sure relays are off when starting up
      digitalWrite(RELAY_PIN, RELAY_OFF);          // Theo: put the pinMode declaration above the first write!
      // Then set relay pins in output mode
      pinMode(RELAY_PIN, OUTPUT);   
          
      // Set relay to last known state (using eeprom storage) 
      // state = gw.loadState(CHILD_ID);
      Serial.print(", Loaded  status from gw: ");
      Serial.println(state);
      digitalWrite(RELAY_PIN, state?RELAY_ON:RELAY_OFF); 
    }
    

    To dig into it more, I'd like to see the results in the Serial monitor.



  • Hi TheoL,

    Thanks for your reply.
    I tried it as you suggested but still the same problem.

    I've posted serial monitor from the sensor in my first post.
    Is it the serial output from the mqtt-client-gateway you want to see ?
    In the first post you see in the beginning a few lines like :+1:
    "Incoming change for sensor 28, New status :1"
    The first few lines like this is when it works, status toggles from 1 to 0 and back when receiving the according MQTT message.
    But then you notice that status remains 1 even if 0 was sent from MQTT.

    Anyway thanks for replying.
    Grts,
    DirkB


  • Contest Winner

    @DirkB19 To me it looks like MQTT keeps sending 1 to your node.

     // Write some debug info
         Serial.print("Incoming change for sensor:");
         Serial.print(message.sensor);
         Serial.print(", New status: ");
         Serial.println(message.getBool()); <---- this value remains '1' acording to your debug info
    

    You Sketch keep printing ",New status: 1" which means it receives 1 is the new value from MQTT??? Maybe the problem is within MQTT?



  • @TheoL, thanks again for looking at my problem.

    You could be right about the mqtt-client-gateway being the problem.
    I'm waiting for a new Arduino UNO to arrive to test the mqtt gateway based on 1.5 lib.

    Meanwhile if assembled another Arduino Nano + nRF24L01 node and uploaded the sketch to it.

    Below is a dump of the serial monitor.
    From the serial monitor dump, could somebody please explain to me the meaning of "l=8:03606113 " ?
    Because when this comes up it is where things go wrong ...

    send: 28-28-255-255 s=255,c=3,t=7,pt=0,l=0,st=fail:
    read: 0-0-28 s=255,c=3,t=8,pt=1,l=1:0
    new parent=0, d=1
    sensor started, id 28
    send: 28-28-0-0 s=255,c=0,t=17,pt=0,l=5,st=ok:1.4.2
    send: 28-28-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
    read: 0-0-28 s=255,c=3,t=6,pt=0,l=1:M
    send: 28-28-0-0 s=255,c=3,t=11,pt=0,l=5,st=ok:RELAY
    send: 28-28-0-0 s=255,c=3,t=12,pt=0,l=6,st=ok:node28
    send: 28-28-0-0 s=28,c=0,t=3,pt=0,l=0,st=ok:
     Loaded  status from gw: 1
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8:0D096113
    Incoming change for sensor:28, New status: 0
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8:1D096113
    Incoming change for sensor:28, New status: 1
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8:0D096113
    Incoming change for sensor:28, New status: 0
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8:1D096113
    Incoming change for sensor:28, New status: 1
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8:03606113   <==== what is the meaning of this ?
    Incoming change for sensor:28, New status: 1  <==== the result is that New status = 1 when it should be 0 !!
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8:1D006113
    Incoming change for sensor:28, New status: 1
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8:0D006113
    Incoming change for sensor:28, New status: 0
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8:1D006113
    Incoming change for sensor:28, New status: 1
    read: 0-0-28 s=28,c=1,t=2,pt=0,l=8:0D006113
    Incoming change for sensor:28, New status: 0
    
    

    Thanks,
    DirkB



  • Hi, I still haven't found the cause of the problem.
    But I have found a workaround :)

    The problem is captured in the serial output of my previous post.
    As you can see the payload ? of the incomming message is for some reason messed up.
    I still suspect the mqtt-cllient-gateway to be responsible for this, but i can not prove this.

    So the workaround is to filter out only the good info from the messedup payload. The good info seems to be found in the first bytes of the payload, while the last part acts up randomly.
    I filtered using substring as follows :+1:

    String hexstring = message.getString();
    String String3 = hexstring.substring(0,1); // Filter out unwanted additional characters = workaround bug
    

Log in to reply
 

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