Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update examples to use logical order for methods #927

Closed
mfalkvidd opened this issue Sep 12, 2017 · 10 comments

Comments

@mfalkvidd
Copy link
Contributor

commented Sep 12, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 17, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2017

@mfalkvidd correct 👍

@rejoe2

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2017

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

@fallberg fallberg added the discussion label Nov 18, 2017

@fallberg fallberg added this to To do in 2.4.0 via automation Feb 25, 2018

@mfalkvidd

This comment has been minimized.

Copy link
Contributor Author

commented Aug 29, 2019

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.

@mfalkvidd mfalkvidd closed this Aug 29, 2019

2.4.0 automation moved this from To do to Done Aug 29, 2019

@tekka007

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2019

@henrikekblad

This comment has been minimized.

Copy link
Member

commented Aug 30, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
5 participants
You can’t perform that action at this time.