Update examples to use logical order for methods

[mfalkvidd]

https://forum.mysensors.org/post/75527 suggests that the order of the methods in the MySensors examples follow the order in which they are called (before->setup->presentation->loop?). This will not affect execution, but could make it easier for users to understand what is happening when.

• Figure out correct call order
• check the examples (both git repos) and re-arrange methods so they follow the logical order

[rejoe2]

Sugesstion has two parts:

1. Just change the appearance order in the sketch text as already described, (+ add preHwInit() if reasonable: Never used that and do not see any real advantages)

2. Also change functionality of example sketches to make use of the logical order of the execution where helpful for learner's understanding.
   Unfortunally, I don't have easy examples (nor is my code in all sketches completely following this suggestion), already mentioned was to use getControllerConfig() in the setup routine in the Dallas-temp-sketch and ask there for initial value for counter sketches

Some more complex examples and description from my personal experience (I don't claim any copyright on the code for myself).

• before():
  -- Usefull for any kind of initialisation that should be done independend to any MySensors communication
  -- could be used to get device counts when using 1wire devices
  -- Needed in case one wants to initialise additional SPI devices using the same SPI interface as the transceiver (did this eg. in https://github.com/rejoe2/Junkers_TW2/blob/master/Junkers_TW2/Junkers_TW2.ino to initialise 2 digital resistors; basical functionality ist tested, but I then decided to try other ways to solve the underlaying problem)

• setup(): Everything that requires connection to the controller, but could or should only be executed once: ask for controller config, send some one-time info to the controller or request initialisation values like counter values also.

Further examples: https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency/blob/master/DallasTemperatureSensor_Stored_ID/DallasTemperatureSensor_Stored_ID.ino
https://github.com/rejoe2/MySensors_Small/blob/master/MyS097/MyS097/MyS097.ino

[rejoe2]

After reviewing the most recent versions of the counter sketches: There already the initialisation of values is implemented (other than in the DallasTemp-Sketch (Arduino-Examples) or DHT (where the request for metric is done within presentation()). Sorry for mentioning these, I should have had reviewed prior to writing...

[mfalkvidd]

I have now checked the code and the functions are called in the following order:
preHwInit()
MCO:BGN:INIT
MCO:BGN:BFR
before()
MCO:BGN:STP
setup()
MCO:BGN:INIT OK
presentation()

after this I guess loop() is called but I am not skilled enough to follow the execution path.

[tekka007]

@mfalkvidd correct 👍

[rejoe2]

@mfalkvidd Thanks for having a look at the code and linking at the right place for deeper analysis.
@tekka007 I'm a little confused wrt. to setup() and presentation(). As far as I understood, the presentation() is internally called as part of "_callbackTransportReady", that would mean prior to setup().
You may verify this finding by using the following test code:

/**
* The MySensors Arduino library handles the wireless radio link and protocol
* between your home built sensors/actuators and HA controller of choice.
* The sensors forms a self healing radio network with optional repeaters. Each
* repeater and gateway builds a routing tables in EEPROM which keeps track of the
* network topology allowing messages to be routed to nodes.
*
* Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
* Copyright (C) 2013-2015 Sensnology AB
* Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
*
* Documentation: http://www.mysensors.org
* Support Forum: http://forum.mysensors.org
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
*******************************
*
* DESCRIPTION
* The RS485 Gateway prints data received from sensors on the serial link.
* The gateway accepts input on seral which will be sent out on
* the RS485 link.
*
* Wire connections (OPTIONAL):
* - Inclusion button should be connected between digital pin 3 and GND
* - RX/TX/ERR leds need to be connected between +5V (anode) and digital pin 6/5/4 with resistor 270-330R in a series
*
* LEDs (OPTIONAL):
* - RX (green) - blink fast on radio message recieved. In inclusion mode will blink fast only on presentation recieved
* - TX (yellow) - blink fast on radio message transmitted. In inclusion mode will blink slowly
* - ERR (red) - fast blink on error during transmission error or recieve crc error
*
* If your Arduino board has additional serial ports
* you can use to connect the RS485 module.
* Otherwise, the gateway uses AltSoftSerial to handle two serial
* links on one Arduino. Use the following pins for RS485 link
*
*  Board          Transmit  Receive   PWM Unusable
* -----          --------  -------   ------------
* Teensy 3.0 & 3.1  21        20         22
* Teensy 2.0         9        10       (none)
* Teensy++ 2.0      25         4       26, 27
* Arduino Uno        9         8         10
* Arduino Leonardo   5        13       (none)
* Arduino Mega      46        48       44, 45
* Wiring-S           5         6          4
* Sanguino          13        14         12
*
*/

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable RS485 transport layer
#define MY_RS485

// Define this to enables DE-pin management on defined pin
#define MY_RS485_DE_PIN 2

// Set RS485 baud rate to use
#define MY_RS485_BAUD_RATE 9600

// Enable this if RS485 is connected to a hardware serial port
//#define MY_RS485_HWSERIAL Serial1

// Enable serial gateway
#define MY_GATEWAY_SERIAL


// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60
// Digital pin used for inclusion mode button
#define MY_INCLUSION_MODE_BUTTON_PIN  3

// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Flash leds on rx/tx/err
#define MY_DEFAULT_ERR_LED_PIN 4  // Error led pin
#define MY_DEFAULT_RX_LED_PIN  5  // Receive led pin
#define MY_DEFAULT_TX_LED_PIN  6  // the PCB, on board LED

#include <MySensors.h>

void before()
{
  Serial.println("before");
}

void setup()
{
	// Setup locally attached sensors
  Serial.println("setup");
}

void presentation()
{
	// Present locally attached sensors
  Serial.println("presentation");
}

void loop()
{
	// Send locally attached sensor data here
}

[tekka007]

@rejoe2, @mfalkvidd I just realized there is more to add: Generally speaking, it depends on MY_TRANSPORT_WAIT_READY_MS and transport initialization status:

• if MY_TRANSPORT_WAIT_READY_MS = 0: setup() is called after presentation()
• if MY_TRANSPORT_WAIT_READY_MS > 0: it depends if transport init (=radio init, parent check, ID check, GW pinging, registration) succeeds before the timeout - if so, same scenario as above - if it fails, setup() is called before presentation() (==> presentation() is called as soon as the transport SM is ready, most likely during main loop execution)

[rejoe2]

@tekka007 Thx for clarification, this makes it more complicated to explain the "mechanics" to "normal users".
So how to proceed wrt. to possible code changes?

I would still vote for changing the textual appearance, because only a few users are aware of that option and those using this kind of tricks will understand that all other code than presentation() will be executed after timout. Maybe a hint in the respective cpp/h-file (?) would be helpful wrt. to the need of shifting that kind of things in the code in case MY_TRANSPORT_WAIT_READY_MS is set to >0?

But wrt. to this, best place to ask for initialisation values (counters) would be at the end of presentation(), as this is also compatible with MY_TRANSPORT_WAIT_READY_MS>0. Today, this is different in the example sketches -> initialising values here is done in setup().

[mfalkvidd]

Since there is no logical order (due to the flexibility of MySesnors), I'll close this.

If someone has a suggested way forward, feel free to reopen.

[tekka007]

See here for a general flow graph:

https://forum.mysensors.org/topic/10529/nrf24-transport-status-not-initialized/10

[henrikekblad]

I added the flow chart here:
https://www.mysensors.org/download/sensor_api_20#node-boot-sequence