V_ARMED Global for node or for each sensor?

[skywatch]

Hi,

I am wondering if I have a node with several security sensors (contact, pir, RF) - can I just have one V_ARMED to act for all the sensors on the node or do I have to present V_ARMED individually for each sensor?

I can't find a clear definition/example to follow.

Here is how I think it works.......But I could be (probably am) wrong!

// Enable debug prints to serial monitor
//#define MY_DEBUG 

// Enable and select radio type attached
#define MY_RADIO_RF24
#define MY_RF24_PA_LEVEL   RF24_PA_HIGH
#define MY_RF24_CHANNEL (97)
#define MY_NODE_ID 81
#define MY_PARENT_NODE_ID 0
#define MY_PARENT_NODE_IS_STATIC

#if F_CPU == 8000000L
#define MY_BAUD_RATE 38400
#endif

#include <MySensors.h>
#include <Bounce2.h>

#define CHILD_ID_PIR 2
#define CHILD_ID_DOOR 3
#define PIR_PIN  2
#define BUTTON_PIN  3 
#define CHILD_ID_ARMED 4
#define CHILD_ID_PIR_ALARM 5
#define CHILD_ID_DOOR_ALARM 6

Bounce debouncer = Bounce(); 
Bounce debouncerPIR = Bounce();
 
unsigned long previousMillis = 0;
const unsigned long SLEEP_TIME = 296000;
int oldValue=-1;
int oldValuePIR = -1;
bool AlarmArmed = false;

//MyMessage msg(CHILD_ID,V_TRIPPED);
MyMessage msgAlarmArmed(CHILD_ID_ARMED,V_ARMED);
MyMessage msgPIR(CHILD_ID_PIR,V_TRIPPED);
MyMessage msgDOOR(CHILD_ID_DOOR, V_TRIPPED);
MyMessage msgDOORALARM(CHILD_ID_DOOR_ALARM,V_TRIPPED);
MyMessage msgPIRALARM(CHILD_ID_PIR_ALARM,V_TRIPPED);

void setup()  
{  
  pinMode(BUTTON_PIN,INPUT_PULLUP);
  pinMode(PIR_PIN,INPUT_PULLUP);
  debouncer.attach(BUTTON_PIN);
  debouncer.interval(5);
  debouncerPIR.attach(PIR_PIN);
  debouncerPIR.interval(5);
}

void presentation() {
  sendSketchInfo("Patio_Door", "3.0");
  wait(250);
  present(CHILD_ID_DOOR, S_DOOR, "PatioDoor", true);  
  wait(250);
  present(CHILD_ID_DOOR_ALARM, S_DOOR, "PatioDoor", true);  
  wait(250);
  present(CHILD_ID_PIR, S_MOTION, "LoungePIR", true);  
  wait(250);
  present(CHILD_ID_PIR_ALARM, S_MOTION, "LoungePIR", true);  
  wait(250);
  present(CHILD_ID_ARMED, S_MOTION, "Alarm Armed", true);  
}

void loop() 
{ 
  debouncer.update();
  debouncerPIR.update();
  int value = debouncer.read();
  int valuePIR = debouncerPIR.read();

  if (AlarmArmed == true && value != oldValue){
    send(msgDOORALARM.set(value==HIGH ? 1 : 0));
    //sound main and local alarm 
    } 

  if (AlarmArmed == true && valuePIR != oldValuePIR){
    send(msgPIRALARM.set(valuePIR==LOW ? 1 : 0));
    //sound main and local alarm 
    }
    
   if (AlarmArmed == false && value != oldValue){
    send(msgDOOR.set(value==HIGH ? 1 : 0));
    //play local warning
    } 
    
    if (AlarmArmed == false && valuePIR != oldValuePIR){
    send(msgPIR.set(valuePIR==LOW ? 1 : 0));
    //play local warning
  
  //Send status every 5 mins as a hearbeat/confidence check.
  if (millis() - previousMillis >= SLEEP_TIME) {
     send(msgDOOR.set(value==HIGH ? 1 : 0));
     send(msgPIR.set(valuePIR==LOW ? 1 : 0));
     previousMillis = millis();
  }
  // Can't sleep with debouncer!
 }
}

void receive(const MyMessage &message) {

if (message.type==V_ARMED) {
           AlarmArmed = message.getBool();
           // Do something wise with the global bArmed boolean
  }
}

Each sensor has 2 messages associated with it. 1. Alarm message if alarm is armed, and a notification message if the alarm is not armed. It compiles but I want to check If I understand this correctly....

[alowhum]

Going by the documentation I'd say it's on a per-child basis. But in the end I guess it's also a matter of how the controller implements it?

[skywatch]

@alowhum Thank you for the info - I asked about this on mycontroller before posting here. Apparently it is "V_ARMED will act like as a binary switch."

So that still leaves me a little unsure as to how to proceed with this one.

Whilst some nodes might benefit from a 'per sensor' setting, others would be better to have a 'per node' setting.

My assumption from what I found was that it was just a bool variable that was sent to the node or sensor depending on how the node handles the incoming message?

Can you post a link to the documentation you mention?

[alowhum]

@skywatch Click on the API link at the top of this page

It really all depends on how it's implemented in your controller / your logic. Since it's, as you say, just a binary switch.

[skywatch]

@alowhum Thanks - In the api all I can see is a list of data types associated with V_ARMED, but no explaination of how it works. So for now I will assume it is as I said above and build the node this weekend and test it out (I like to get the SW compiling before comitting to HW)......So really I'll be treating it in the same way as say a switch.

[alowhum]

As you can tell from the documentation, Node children can have multiple.. data bits attached to them.

S_MOTION 	1 	Motion sensors 	V_TRIPPED, V_ARMED

For example, this code would be ok:

// Both these messages 'share' the same child ID:
MyMessage pressureMsg(BARO_CHILD_ID, V_PRESSURE); 
MyMessage forecastMsg(BARO_CHILD_ID, V_FORECAST);

// Here one child is presented, but it will 'host' both message types.
void presentation() {
  sendSketchInfo(F("Temperature and more"), F("1.3")); wait(RADIO_DELAY);
  present(BARO_CHILD_ID, S_BARO, F("Barometer")); wait(RADIO_DELAY);
}


// In the loop:
send(pressureMsg.set((pressure),1)); // a number with one decimal
send(forecastMsg.set(F("Stable"))); // string

So in this example, the controller will receive two types of messages on the one child ID. It will know to keep them separated because the V_Type is also sent along.

The same thing happens with the motion and door sensor. One child hosts two messages.

Still, as I said, in the end it's all about which controller you use and how it deals with it. For example, in the WebThings Gateway the two messages are basically separated out into being two children, so your original way of just creating a new child for an armed message is totally fine. Some other controllers might have some special way of displaying this specific type of child. Perhaps with a toggle and a small red dot to indicate being armed or not. In those cases them sharing the same child ID can be a hint to the controller that it should keep those two together in the interface.

It really all depends on how your controller deals with it. Which one are you using?

[skywatch]

@alowhum Thank you so much for that - I had a 'light bulb' moment reading it!

I know I am going to be in trouble for not doing housework, but this is more important

[alowhum]

@skywatch My pleasure