A few random questions (V_tripped vs V_armed)

[alowhum]

I have a few small questions that a forum search and api page browse didn't answer:

What is the advantage of using the Presentation function? Why not just put all those things in the setup function?

Aside from any advantage of using the presentation function, is it possible to present things in the setup function?

Is there a technical difference between using V_tripped and V_armed? Or is it just a different name which helps controllers display them in a certain way?

[mfalkvidd]

If you for example need to initialize a onewire bus and query the number of devices before presenting, presenting in presentation() and initializing in setup() makes for clearer separation. Example: https://www.mysensors.org/build/temp
2.
I have not considered this. Maybe digging through the code can yield an answer. A downside would probably be that the sketch would become less easy to read and harder to understand, troubleshoot and maintain. What would the benefit be?
3.
The technical difference is that V_TRIPPED = 16 and V_ARMED = 15. Controllers decide how they show/use different types.

[mfalkvidd]

Based on the discussion in https://github.com/mysensors/MySensors/issues/927 I think that one big problem with calling present() from inside setup() is that the transport might not be ready to send messages yet. So trying to send messages might mess up all sorts of things.

[alowhum]

@mfalkvidd Thanks for the replies, they cleared things up.

To andwer your question: the benefit of presenting in the setup function would be that the Serial output is usually started in setup. That was I could find out while debugging how many devices have been created.

Another "advantage" would be that more variables are available. For example, I have a function that reads from eeprom how many 433Mhz signals have been stored. For each signal a corresponding button must be presented.

In other words: there are some things I need during the presentation phase that are usually initiated in the setup function.

[mfalkvidd]

@alowhum sorry, I don't understand the first benefit. Serial output is available already in preHwInit(), which is called before setup(). present() is also called after preHwInit(), so Serial is available there as well.

For the second benefit, my impression is that you are doing stuff (reading eeprom) in setup() that could be done in present() instead.

[alowhum]

Indeed. I just moved them into present, and it worked fine.

I didn't so much mean to say that it was technically not possible, more that the convention is to do things like "Serial.begin" in the setup function. So in a way, for beginners like me, it can also create some slight confusion/insecurity about what all those extra Present and Before functions do, and how vital it is to keep things in those functions.

[DavidZH]

Stubborn old me: I've dropped presentation() in my sketches. 🙃

But that is possible because I do not use discovery in my controller (Pimatic). All my MYS devices in Pimatic are coded so when the sensor starts it immediately shows.
Main reason: it saves a lot of battery during startup. I've made a watchdog in Pimatic with rules to keep an eye on the device to see if they stop sending.

[alowhum]

@davidzh So if I understand correctly you've hardcoded the sensors on the controller side? Interesting move. I guess that only works if you don't need to automatically add new sensors.

I have another question:

I'm trying to make the child name in the presentation function generative.

For example, let's say I want to present 30 on/off buttons to the controller. I'm trying to automatically name them "BUTTON_1", "BUTTON_2", etc in a loop.

But I can't get it to work:

  // We loop over all the recognised signals.
  for( byte recognisedID=10; recognisedID < 10 + (amountOfStoredSignals - amountOfStoredReplayableSignals); recognisedID++ ){
    char childName[2]; childName[0] = (char) recognisedID;
    Serial.println(F("Presenting sensor ")); Serial.println(childName);
    present(recognisedID, S_DOOR, childName); wait(RADIO_DELAY);
  }

I've tried a lot of variations..

How can I generate names for the presentation function?

Another question, just to be sure: the children don't need to have consecutive ID's right? And the only child ID that is off limits is 255, in case it also functions as a repeater?

[alowhum]

Arduino doesn't seem to complain about this:

for( byte replayableID=1; replayableID < 100; replayableID++ ){
  present(replayableID, S_BINARY, (const char*)replayableID); wait(RADIO_DELAY);
}

[mljbr4]

@alowhum V_ARMED indicates whether the alarm system is on or off.
V_TRIPPED indicates whether the alarm has been tripped (an intruder has been detected)
Usage: when you are home the security system is not ARMED so if you receive a TRIPPED message from, say, a movement sensor you would not sound the alarm.

[alowhum]

Thanks!

I guess I'm looking for a neutral "binary sensor", as in this case people could connect pretty much anything that uses 433Mhz and has an on and off state.

[alowhum]

Another random question:

In my global definition of variables, what is the difference between:

const byte metadataArraySize = 8;
byte metaData[metadataArraySize];

and

byte metaData[8];

.. When it comes to memory use and storage use? I tested it, and Arduino says there is no difference in memory use OR storage use? Is that true?

Similarly, if I have this in my code inside a function:

else if( message.sensor >= 100 ){

Does that 100 get stored in memory? Or is Arduino smart enough to store that in flash only? If it's stored in memory, does Arduino make it a byte or an int or.. ?

[alowhum]

And another:

When I use "wait()" instead of "delay()", does that guarantee that the sketch stays non-blocking and that the device can still function as a repeater during that waiting time? For example, does the repeater function still work when I do this:

      digitalWrite(RELAY1_PIN, RELAY_ON);            // Unlock the door.
      wait(1000); 
      digitalWrite(RELAY1_PIN, RELAY_OFF);          // Re-lock the door.

[mfalkvidd]

@alowhum yes it does. Documentation: https://www.mysensors.org/download/sensor_api_20#waiting