First batch of devices arrived. Looks fine. I hope I will manage to install it in garden to the end of the week.

"Your code your rules" but I'm little surprised with your standpoint.

@anticimex OK maybe I will try but I think it could be a good idea to extend you "migration guide".

OK I will try it today. Yesterday I've done such procedure (without success) but now I've realised that I've used OLD (2.1) personalisation script (saved on disk) but loaded GW code compiled with 2.2 library. Probably that's an issue.

So I should first "personalise" ESP8266 device with "standard personalising sketch" and than upload my GW code with #define MY_SIGNING_SOFT. Right?

So it means that (If I want use signing) I'm stuck with mysensors version 2.1?
I'm not able compile new code (using 2.2) and upload it over OTA because I will loose signing right (without changeing EEPROM content)?
I think there should be a way to migrate sketch (which is using soft signing) from 2.1 to 2.2 with OTA. Secure sending of keys actually is NOT a problem because (as I understood) new in 2.2 is "only checksum" of EEPROM.
So if I have "2.1 mysensors library" personalized devices, it's possible to write a program which gets existing data from EEPROM calculate checksum and write it to EEPROM (maybe also migrating other structures if there were other changes). Such sketch can be in safe way transferred via OTA because it doesn't contain any secret information. Then I can upload new (using 2.2 library) version of my sketch and I will have working "2.2" devices without touching it (only OTA). What do you think about it?

Actually now I've realised (luckily) that in these "hard to get devices" I'm using hardware signing so it should be not a problem (?) :-)

Is signing for ESP8266 gateway supported? I know that hardware signing is NOT supported but how about software? If so should be personalization in usual way (using sketch from examples) like "arduino nano" nodes?

I've a lot devices with very hard physical access to them. I'm using OTA to change firmware so please describe how to implement "new 2.2 checksum feature" into existing sketch using OTA.

@mfalkvidd said in Return value of bool send(MyMessage &msg, const bool ack = false);:

@bilbolodz just to check: are you sure there are no repeaters or other gateways within range?

I've to check more thoroughly but rather not.

@pjr Thank you. I'm already using software ack (and message resending after timeout) for get reliable radio transport. According hardware ack:

Hardware ack is what I get when using send(msg, true) and some other functions like present, sendSketchInfo and sendBatteryLevel

    Hardware ack is hop-to-hop acknowledgment
    Sending is a blocking function which returns true if an ack was received and false if ~70ms passed without receiving an hardware ack.
    Sending ack is handled automatically by the library(/radio)
    Receiving an ack is handled automatically by the library
    Re-send needs to be handled manually in each sketch (a while-loop with a counter counting up to maxRetries and using wait() between each resend seems to be the most common solution)

sounds nice but above statement seems to be not true in my case: after complete node registration in GW send function returns always true even GW is powered off.... I've studied source and looks that "in the lowest level of code" send function outcome comes from: drivers/RF24/RF24.cpp function:

LOCAL bool RF24_sendMessage(const uint8_t recipient, const void* buf, const uint8_t len)
{
	uint8_t RF24_status;
	RF24_stopListening();
	RF24_openWritingPipe( recipient );
	RF24_DEBUG(PSTR("RF24:SND:TO=%d,LEN=%d\n"),recipient,len); // send message
	// flush TX FIFO
	RF24_flushTX();
	// this command is affected in clones (e.g. Si24R1):  flipped NoACK bit when using W_TX_PAYLOAD_NO_ACK / W_TX_PAYLOAD
	// AutoACK is disabled on the broadcasting pipe - NO_ACK prevents resending
	RF24_spiMultiByteTransfer(recipient == BROADCAST_ADDRESS ? RF24_WRITE_TX_PAYLOAD_NO_ACK :
	                          RF24_WRITE_TX_PAYLOAD, (uint8_t*)buf, len, false );
	// go, TX starts after ~10us
	RF24_ce(HIGH);
	// timeout counter to detect HW issues
	uint16_t timeout = 0xFFFF;
	do {
		RF24_status = RF24_getStatus();
	} while  (!(RF24_status & ( _BV(RF24_MAX_RT) | _BV(RF24_TX_DS) )) && timeout--);
	// timeout value after successful TX on 16Mhz AVR ~ 65500, i.e. msg is transmitted after ~36 loop cycles
	RF24_ce(LOW);
	// reset interrupts
	RF24_setStatus(_BV(RF24_TX_DS) | _BV(RF24_MAX_RT) );
	// Max retries exceeded
	if(RF24_status & _BV(RF24_MAX_RT)) {
		// flush packet
		RF24_DEBUG(PSTR("!RF24:SND:MAX_RT\n"));	// max retries, no ACK
		RF24_flushTX();
	}
	RF24_startListening();
	// true if message sent
	return (RF24_status & _BV(RF24_TX_DS));
}

so it's from RF24 status register. I've to check how it's working on other RF24 modules. I've read that there are some comparability problems with non original Chinese clones of NRF24L01 chipset.

According MySensorsCore.h function bool send(MyMessage &msg, const bool ack = false) should return " true if message reached the first stop on its way to destination"

/**
* Sends a message to gateway or one of the other nodes in the radio network
*
* @param msg Message to send
* @param ack Set this to true if you want destination node to send ack back to this node. Default is not to request any ack.
* @return true Returns true if message reached the first stop on its way to destination.
*/
bool send(MyMessage &msg, const bool ack = false);

In my case (using ACK options) it always return true regardless state of gateway (I've physically disconnected GW from USB after sensor startup/registration phase..... I'm using 2.1.1 version and RF24 transport What could be wrong?

I know it's very good rule.

OK I will probably fix my parents.

@gohan Static parent id would solve my problem BUT what if one repeaters (Murphy's law: most important) fail? 1/3 of my node network gone..... If I can blacklist some nodes (very distant from sensor) I can enable repeater feature on more nodes and have more redundant network. Similar with "static with backup": I can put more repeaters talking with more PA power and be 100% sure that node will talk to controller via one of "preferred parent".
Of course it's just my idea but maybe it's worth to think about it?

Now I've limited number of repeaters (4 in each corner of the house) and my problems with connectivity are less frequent but yes: from time to time my nodes are jumping to other repeater and in some cases there is a problem with RF link.

@gohan said in Semi static parent modification:

Did you have issues with repeaters since you are asking how to increase reliability?

Sorry but I don't quite understand you.....

It WAS tested but "in the middle of night" I've chosen WRONG firmware..... :-(

I think it's a good idea to implement OTA "pre flash" validation. There should a possibility to define some HARDWARE_ID into sketch, modify OTA message to tell node "these new sketch is for XYZ HARDWARE_ID" and add some predefined function (as validate_OTA()) to block flashing if code is NOT for these hardware.
Accidentally I've flashed node mounted in a field and very well water protected with a wrong HEX. Dissembling module in "the middle of field", cleaning contacts from protecting grease, flashing it and protecting again was VERY painful......

Some background information:

I've bunch (over 30) nodes (NRF24) in my garden, there are working as lamp switches. I'm also using message signing. Because of RF range and required good signal quality (signing demands real stable RF network) I'm using repeaters.
In my code I'm using:

int8_t myParrentNodeId;
int8_t myRF24PALelel;

#define MY_PARENT_NODE_ID myParrentNodeId
#define MY_RF24_PA_LEVEL myRF24PALelel

trick to change preferred parent for nodes without needs of having different sketch image for each node and reflashing.

Unfortunately sometimes (because of unknown reason) node changes parent node to some distant repeater node and communication with these node (over "new parent") is very poor. It's also very hard to recover node from such state (reboot command needs signing, signing needs good radio connection, radio link is poor because node is using very distant repeater).

I've some ideas which could be implemented to remedy such situations:

1. Possibility to BLACKLIST some repeaters - it should be a array(?) in RAM/EEPROM which contain IDs of forbidden parents

2. Possibility to declare " MY_PARENT_NODE_IS_STATIC" but with fixed (in RAM or EEPROM) backup parrent ID. It will allow to limit possible parent to two good (in range) nodes but not break connectivity in case of primary parent failure

3. Better RF link quality verification to be 100% sure that whole path to controller is performing well.

4. It could be also a good idea to make possible enable/disable working node "as parent" without recompilation (easier tunning of large Mysensors network).

Sorry you are right. If you need to check "complete path" fetching time from controller is probably good way to do it.