Apparently this day is my lucky day

@scalz , you did me think with your comment about the samd21 board not triggering the irq.

So I looked up where the pin layouts of all these 'arduino compatible' boards are defined.
My used board is a RobotDyn Samd21 M0 board and they claim compatible with a Arduino M0 and I did use the Arduino SAMD boards (32-bits ARM Cortex-M0+) by Arduino version 1.8.3.
The code you find at: https://github.com/arduino/ArduinoCore-samd
With some help of the google doctor, I did find that the pin layouts are defined in the Variants.cpp file in
https://github.com/arduino/ArduinoCore-samd/blob/master/variants/arduino_mzero/variant.cpp
(I'm using the Arduino M0 entry when selecting my board)
In this file

/*
 *
 * + Pin number +  ZERO Board pin  |  PIN   | Label/Name      | Comments (* is for default peripheral in use)
 * +------------+------------------+--------+-----------------+------------------------------
 * |            | Digital Low      |        |                 |
 * +------------+------------------+--------+-----------------+------------------------------
 * | 0          | 0 -> RX          |  PA11  |                 | EIC/EXTINT[11] ADC/AIN[19] PTC/X[3] *SERCOM0/PAD[3] SERCOM2/PAD[3] TCC1/WO[1] TCC0/WO[3]
 * | 1          | 1 <- TX          |  PA10  |                 | EIC/EXTINT[10] ADC/AIN[18] PTC/X[2] *SERCOM0/PAD[2] TCC1/WO[0] TCC0/WO[2]
 * | 2          | ~2               |  PA08  |                 | EIC/NMI ADC/AIN[16] PTC/X[0] SERCOM0/PAD[0] SERCOM2/PAD[0] *TCC0/WO[0] TCC1/WO[2]
 * | 3          | ~3               |  PA09  |                 | EIC/EXTINT[9] ADC/AIN[17] PTC/X[1] SERCOM0/PAD[1] SERCOM2/PAD[1] *TCC0/WO[1] TCC1/WO[3]
 * | 4          | ~4               |  PA14  |                 | EIC/EXTINT[14] SERCOM2/PAD[2] SERCOM4/PAD[2] TC3/WO[0] *TCC0/WO[4]
 * | 5          | ~5               |  PA15  |                 | EIC/EXTINT[15] SERCOM2/PAD[3] SERCOM4/PAD[3] TC3/WO[1] *TCC0/WO[5]
 * | 6          | ~6               |  PA20  |                 | EIC/EXTINT[4] PTC/X[8] SERCOM5/PAD[2] SERCOM3/PAD[2] TC7/WO[0] *TCC0/WO[6]
 * | 7          | ~7               |  PA21  |                 | EIC/EXTINT[5] PTC/X[9] SERCOM5/PAD[3] SERCOM3/PAD[3] TC7/WO[1] *TCC0/WO[7]
 * +------------+------------------+--------+-----------------+------------------------------
 * |            | Digital High     |        |                 |
 * +------------+------------------+--------+-----------------+------------------------------
 * | 8          | ~8               |  PA06  |                 | EIC/EXTINT[6] PTC/Y[4] ADC/AIN[6] AC/AIN[2] SERCOM0/PAD[2] *TCC1/WO[0]
 * | 9          | ~9               |  PA07  |                 | EIC/EXTINT[7] PTC/Y[5] DC/AIN[7] AC/AIN[3] SERCOM0/PAD[3] *TCC1/WO[1]
 * | 10         | ~10              |  PA18  |                 | EIC/EXTINT[2] PTC/X[6] SERCOM1/PAD[2] SERCOM3/PAD[2] *TC3/WO[0] TCC0/WO[2]
 * | 11         | ~11              |  PA16  |                 | EIC/EXTINT[0] PTC/X[4] SERCOM1/PAD[0] SERCOM3/PAD[0] *TCC2/WO[0] TCC0/WO[6]
 * | 12         | ~12              |  PA19  |                 | EIC/EXTINT[3] PTC/X[7] SERCOM1/PAD[3] SERCOM3/PAD[3] *TC3/WO[1] TCC0/WO[3]
 * | 13         | ~13              |  PA17  | LED             | EIC/EXTINT[1] PTC/X[5] SERCOM1/PAD[1] SERCOM3/PAD[1] *TCC2/WO[1] TCC0/WO[7]
 * | 14         | GND              |        |                 |
 * | 15         | AREF             |  PA03  |                 | *DAC/VREFP PTC/Y[1]
 * | 16         | SDA              |  PA22  |                 | EIC/EXTINT[6] PTC/X[10] *SERCOM3/PAD[0] SERCOM5/PAD[0] TC4/WO[0] TCC0/WO[4]
 * | 17         | SCL              |  PA23  |                 | EIC/EXTINT[7] PTC/X[11] *SERCOM3/PAD[1] SERCOM5/PAD[1] TC4/WO[1] TCC0/WO[5]

This is the defined pin mapping for a Arduino mZero. (I was using D2 as IRQ for the RFM69)

* | 2          | ~2               |  PA08  |

But on the pin layout of the RobotDyn board I saw:

* | 2          | ~2               |  PA14  |

On the RobotDyn the pin PA08 is mapped on the D4 arduino pin and not the D2 pin!
With the pins D2/D4, RobotDyn is following here the Arduino Zero layout and NOT the Arduino mZero layout!

So, I verified the other mappings and found that following pins are different mapped on the Arduino mZero:

 * | 2          | ~2               |  PA08  | 
 
 * | 4          | ~4               |  PA14  | 

On the RobotDyn Samd21M0

 * | 2          | ~2               |  PA14  | 

 * | 4          | ~4               |  PA08  | 

So I changed the IRQ (DIO0) from the RF69 to the port D8 (PA06) and bingo it started to work (did choose randomly D8)

I saw also a difference in the SPI mapping
mZero

 * | 18         | 1                |  PA12  | MISO 

RobotDyn samd21 m0

 * |  not defined on their pin layout doc       | 1                |  PB12  | MISO 

But it is working, so maybe an error on RobotDyn's documentation?

So if I resume the thing:
The RobotDyn SAMD21 M0 board is claimed compatible with the Arduino M0 (mZero). In the IDE you must also select the Arduino M0. (selecting Arduino/Genuino Zero xxx will not work)
But the RobotDyn used layout is compatible with the Arduino Zero, so pin D2 and D4 are reversed, making the code of the board Arduino M0 not working if you choose to use these pins in your design.

So now we can continue to build our gateway, my originally goal.
Edit : my MQTT gateway with the RobotDyn Samd21 M0 board, a W5500 ethernet module and a radio RFM69HW is up and running

Thanks for all comments that guided me to the solution

This post is a try to order my thoughts about the mysensors implementation possibilities for signing and encryption.

I thought that it could be of some help for other people, who are new, like me, to mysensors and want to start using it.
This is written with in mind the current version 2.3.1 of the mysensors libary and 2 Arduinos Uno's R3 as hardware. Be aware that this can change in the future as the library will continue to evolve!

Please, if you find any mistakes, don't hesitate to point them out to me so I can correct this post.

First some (condensed) theory found in the docs and on this forum.

Two different things:

• Signing messages : this makes that the receiver is sure that the received message is really from the transmitter. The message can't be changed by somebody during the transmission of the message. This is done by the MySensors message protocol.
  More detailed explication can be found on: https://www.mysensors.org/apidocs/group__MySigninggrpPub.html#MySigninggrpencryption

• Encryption of the messages: is done on the level of the used radio itself. For RFM69HW for example, it is done by the hardware itself of the radio. It is independent from the MySensors message protocol implementation.

A. Signing of the messages

Three possibilities: 2 based on software and one based on extra external hardware. The latest I can't test because I have no Atmel ATSHA204 chips lying around...

• First option, software backed by using only a password : weaker security, but simple to activate.

  MY_SIGNING_SIMPLE_PASSWORD: this keyword enables security only on the level signing
  If the provided password is shorter than the size of the HMAC key, it will be null-padded to accommodate the key size in question. A 32 character password is the maximum length. Any password longer than that will be truncated.

• Second option, sofware backed

  MY_SIGNING_SOFT: this keyword enables security only on the level signing

  If MY_SIGNING_SIMPLE_PASSWD is used a personalisation must not be done.
  If not used, a personalization must be done, the values are stored in EEPROM.(see: https://www.mysensors.org/apidocs-beta/group__MySigninggrpPub.html#personalization). See also further on.

• Third option, hardware backed via the Atmel ATSHA204 chip

  MY_SIGNING_ATSHA204: this keyword enables security only on the level signing

  If MY_SIGNING_SIMPLE_PASSWD is used a personalisation must not be done.
  If not used, a personalization must be done, the values are written to the Atmel ATSHA204 ship. It is irreversible!! (see https://www.mysensors.org/apidocs-beta/group__MySigninggrpPub.html#personalization)

B. Encryption of the radio transport level

Only possible for the supported radios (RF24, RFM69, NRF5, RFM95 at current library version 2.3.1)(https://www.mysensors.org/apidocs-beta/group__EncryptionSettingGrpPub.html)
The RFM69 radio does support hardware encryption of the communication using AES (Advanced Encryption Standard).

• MY_ENCRYPTION_SIMPLE_PASSWORD: this keyword enables encryption on all radio communications of the radio types that supports it and uses provided password as key.
  If the provided password is shorter than the size of the AES key, it will be null-padded to accommodate the key size in question. A 16 character password is the maximum length. Any password longer than that will be truncated.
  example : #define MY_ENCRYPTION_SIMPLE_PASSWD "MyInsecurePassword"

If you are already using the first option of signing messages (MY_SIGNING_SIMPLE_PASSWORD), you can replace it by following keyword:

• MY_SECURITY_SIMPLE_PASSWORD: this keyword enables security on the level signing and encryption (only usable on Arduino. On the Raspberry PI use the other two simple options)

My practical tests

• a sensor based on an Arduino Uno with the sketch UltraSonic_sensor from the website adapted for the RFM69HW radio
• a gateway based on an Arduino, a W5100 ethernet shield for the Uno and a radio RFM69HW (see https://forum.mysensors.org/topic/10358/solved-mqtt-gateway-based-on-arduino-uno-uno-compatible-w5100-ethernet-shield-rfm69hw-radio)

1. Added in the two sketches: only encryption

#define MY_ENCRYPTION_SIMPLE_PASSWORD "my16characterpassword"

Result : it works

1. Added in the two sketches: encryption and simple signing

#define MY_ENCRYPTION_SIMPLE_PASSWORD "my16characterpassword"
#define MY_SIGNING_SIMPLE_PASSWORD "my32characterpassword"

Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work!

1. Added in the two sketches: encryption and simple signing

#define MY_ENCRYPTION_SIMPLE_PASSWORD "my16characterpassword"
#define MY_SIGNING_SIMPLE_PASSWORD "my16characterpassword"

Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work!

1. Added in the two sketches: the shortcut define for the Arduino platform

#define MY_SECURITY_SIMPLE_PASSWORD "my16characterpassword"

Result : it works

1. Added in the two sketches: the shortcut define for the Arduino platform

#define MY_SECURITY_SIMPLE_PASSWORD "my32characterpassword"

Result : it works

Is this shortcut define specially done for the Arduino platform to avoid the low memory condition?

1. Added in the two sketches : encryption and soft signing with simple password personalization

//enable radio communication encryption
#define MY_ENCRYPTION_SIMPLE_PASSWD "my16characterpassword"
#define MY_SIGNING_SIMPLE_PASSWD "my32characterpassword"
#define MY_SIGNING_SOFT
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_SOFT_RANDOMSEED_PIN A0

Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work. The signing is failing.

1. Added in the two sketches : encryption and soft signing with personalization
   First we will personalize each arduino (the sensor and the gateway)

• open the SecurityPersonalizer.ino file via the Arduino IDE menu File, Examples, Mysensors, SecurityPersonalizer
• uncomment the define GENERATE_KEYS_SOFT
• upload the sketch to your Arduino
• open the serial monitor
• here you will find your generated keys HMAC and AES keys
• copy the entries under the 'Key copy section' into the SecurityPersonalizer.ino file
• comment again the define GENERATE_KEYS_SOFT

The following 3 steps must be done on each node where you want to use soft signing

• uncomment the define PERSONALIZE_SOFT
• upload the sketch again to your Arduino
• in the serial monitor output you will find now that the keys are written to the EEPROM (see EEPROM section)

The following 5 steps must also be done on each node where you want to use whitelisting

• if you want to use whitelisting and your device does not provide a unique device ID, you have to generate a unique serial and store it in EEPROM (my arduino uno does not provide a unique device ID, so I must run the sketch)

• comment the define PERSONALIZE_SOFT

• uncomment the define PERSONALIZE_SOFT_RANDOM_SERIAL

• upload the sketch to your Arduino

• in the serial monitor output you will find now a generated serial unique device ID. This unique serial ID must be copied somewhere on a safe place. You must later on copy this key in the whitelisting define of your gateway and nodes sketches.

• Take now your sketches and add the following defines

//enable radio communication encryption
#define MY_ENCRYPTION_SIMPLE_PASSWD "my16characterpassword"
//enable soft signing
#define MY_SIGNING_SOFT
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_SOFT_RANDOMSEED_PIN A0
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = 0,.serial = {0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88,0x99}},{.nodeId = 1,.serial = {0x99,0x88,0x77,0x66,0x55,0x44,0x33,0x22,0x11}}}

The MQTT gateway has always nodeid = 0 and my sensor has nodeid = 1 (the sensors must have a fixed set nodeid because in MQTT mode, the controller (like HomeAssistant) can't assign node ids).
The serials given above are fake numbers, use the ones from your sketch!

Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work!

So I think that in my case, with an Arduino Uno as MQTT gateway, only the simple signing and encryption is possible.
Maybe the hardware backed signing, but I can't test this at this moment. (see my other question : https://forum.mysensors.org/topic/10370/is-there-still-a-breakout-board-for-the-atmel-atsha204a-chip)

Nobody has never build a gateway based on an Arduino Uno, a W5100 shield and a RFM69HW?

So I will answer my own questions
I did take my chance and choose to build first a gateway version using the hardware SPI bus (no soft spi) and I was lucky, it worked directly! So no need to try the soft-spi version.

Because I did already build previously a sensor (https://www.mysensors.org/build/distance), I had all hardware already ready to be used.

So what is the used hardware?

• one standard Arduino Uno R3 (guine or chinese clone, DON'T BUY WAVGAT arduino uno types, they require specific hardware drivers in the Arduino IDE and this manufacturer doesn't update his own old drivers!!)(https://www.aliexpress.com/item/1pcs-Smart-Electronics-high-quality-UNO-R3-MEGA328P-CH340G-Compatible-NO-USB-CABLE-for-arduino/32830661533.html)
• one RFM69HW, version 868MHz (check what you can use at your country!)(https://www.aliexpress.com/item/Free-Shipping-RFM69HW-868Mhz-Transceiver-Module-High-Integrated-HopeRF-Wireless-868S2-Module-SPI-1-8-3/32810316806.html)
• one helical antenna (https://www.aliexpress.com/item/10PCS-868MHz-Helical-Antenna-2-15dBi-13mm-Stable-for-Remote-Contorl/32668155368.html)
• one W5100 shield pin compatible with an Arduino Uno (https://www.aliexpress.com/item/Free-Shipping-UNO-Shield-Ethernet-Shield-W5100-R3-UNO-Mega-2560-1280-328-UNR-R3-only/32502588687.html)
• one proto shield to build the RFM69HW radio on top of the W5100 shield (https://www.aliexpress.com/item/Standard-Proto-Screw-Shield-Board-For-Arduino-Compatible-Improved-version-support-A6-A7-Diy-Kit-Electronic/32832054800.html)
• one logic channel convertor between Arduino 5V and RFM69HW radio 3.3V (https://www.aliexpress.com/item/3-3V-5V-TXS0108E-8-Channel-Logic-Level-Bi-directional-Converter-Module-TXB0108-Mutual-Convert-Module/32916020205.html)

The hardware is wired following next schematic:

Connecting the RFM69HW hardware was somewhat tricky. The used pin headers on the RFM69HW are not following the standard spaced 2.54mm pin headers like on the Arduino print. I did not have a converter plate, so I soldered some hard wire into the RFM69HW pins and bend them into the pin holes from the protoboard. See photo.

So what about the software:

• Arduino IDE version 1.8.9
• MySensors library 2.3.1

I did take as base the sketch found on the website https://www.mysensors.org/build/mqtt_gateway or https://github.com/mysensors/MySensors/blob/master/examples/GatewayW5100MQTTClient/GatewayW5100MQTTClient.ino

Important is to configure the specific RFM69 defines
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RFM69_868MHZ // Set your frequency here
#define MY_IS_RFM69HW // Omit if your RFM is not "H"
#define MY_RFM69_NEW_DRIVER

When the W5100 Arduino shield is connected we have to move SS (slave select) pin for the RFM69 radio because the shield is using the default D10
#define MY_RFM69_CS_PIN 6

/*
 * 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-2019 Sensnology AB
 * Full contributor list: https://github.com/mysensors/MySensors/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.
 *
 *******************************
 *
 * REVISION HISTORY
 * Version 1.0 - Henrik Ekblad
 * Version 1.1 - Eric Van Bocxlaer
 *
 * DESCRIPTION
 * The W5100 MQTT gateway sends radio network (or locally attached sensors) data to your MQTT broker.
 * The node also listens to MY_MQTT_TOPIC_PREFIX and sends out those messages to the radio network
 *
 * LED purposes:
 * - To use the feature, uncomment WITH_LEDS_BLINKING in MyConfig.h
 * - RX (green) - blink fast on radio message received. In inclusion mode will blink fast only on presentation received
 * - TX (yellow) - blink fast on radio message transmitted. In inclusion mode will blink slowly
 * - ERR (red) - fast blink on error during transmission error or receive crc error
 *
 * See http://www.mysensors.org/build/esp8266_gateway for wiring instructions.
 * nRF24L01+  ESP8266
 * VCC        VCC
 * CE         GPIO4
 * CSN/CS     GPIO15
 * SCK        GPIO14
 * MISO       GPIO12
 * MOSI       GPIO13
 *
 * Not all ESP8266 modules have all pins available on their external interface.
 * This code has been tested on an ESP-12 module.
 * The ESP8266 requires a certain pin configuration to download code, and another one to run code:
 * - Connect REST (reset) via 10K pullup resistor to VCC, and via switch to GND ('reset switch')
 * - Connect GPIO15 via 10K pulldown resistor to GND
 * - Connect CH_PD via 10K resistor to VCC
 * - Connect GPIO2 via 10K resistor to VCC
 * - Connect GPIO0 via 10K resistor to VCC, and via switch to GND ('bootload switch')
 *
  * Inclusion mode button:
 * - Connect GPIO5 via switch to GND ('inclusion switch')
 *
 * Hardware SHA204 signing is currently not supported!
 *
 * Make sure to fill in your ssid and WiFi password below for ssid & pass.
 * 
 * ***************************************************************************************************************
 * Connection with RFM69HW and EthernetShieldW5100 through the SPI bus (Serial Peripheral Interface)
 * On this bus we can have only one master (= the Arduino Uno) and different slaves (= the W5100 and the RFM69HW).
 * The master can only talk to one slave each time!
 * 
 * RFM69HW    Uno R3    EthernetShieldW5100(autowired)
 * VCC 3.3V   VCC 3.3V  
 *            VCC 5.0V  VCC 5.0V
 * DIO0       D2/INT0
 * NSS        D6
 * SCK        D13/SCK   SCK (D13)
 * MISO       D12/MISO  MISO (D12)
 * MOSI       D11/MOSI  MOSI (D11)
 *            D4        SS (sd-card)
 *            D10/SS    SS (W5100)(Default in ethernet library: do not wire different with a no shield version!)
 *            
 * 
 * NSS/SS : Slave Select for SPI bus (the master selects with which slave he want to talk)
 * SCK : serial clock signal delivered by the master
 * MISO : Master Input Slave Output (arduino receives data from the slave)
 * MOSI : Master Output Slave Input (arduino sends data to the slave)
 */


// Enable debug prints to serial monitor
//#define MY_DEBUG
// Enable specific RFM69 debug prints to serial monitor
//#define MY_DEBUG_VERBOSE_RFM69

// Enables and select radio type (if attached)
//#define MY_RADIO_RF24
//#define MY_RADIO_RFM95
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RFM69_868MHZ // Set your frequency here
#define MY_IS_RFM69HW // Omit if your RFM is not "H"
#define MY_RFM69_NEW_DRIVER

#define MY_GATEWAY_MQTT_CLIENT

// Set this node's subscribe and publish topic prefix
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway1-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway1-in"

// Set MQTT client id
#define MY_MQTT_CLIENT_ID "mysensors-1"

// Enable gateway ethernet module type : not needed here because MY_GATEWAY_MQTT_CLIENT defines already the use of W5100
//#define MY_GATEWAY_W5100
#define SD_SS_PIN (4)  // chip-select for SD card (normally unused, pull high!, see code!) 

// W5100 Ethernet module SPI enable (this setting is optional if using a shield/module that manages SPI_EN signal)
//#define MY_W5100_SPI_EN 4

// Enable Soft SPI for NRF radio (note different radio wiring is required)
// The W5100 ethernet module seems to have a hard time co-operate with
// radio on the same spi bus.
// Situation on 2019-05-04: with the new RFM69HW driver this is not true anymore for a radio RFM69!
//#if !defined(MY_W5100_SPI_EN) && !defined(ARDUINO_ARCH_SAMD)
//#define MY_SOFTSPI
//#define MY_SOFT_SPI_SCK_PIN 14
//#define MY_SOFT_SPI_MISO_PIN 16
//#define MY_SOFT_SPI_MOSI_PIN 15
//#endif

// When W5100 shield is connected we have to move SS (slave select) pin for the RFM69 radio because the shield
// is using the default D10
#define MY_RFM69_CS_PIN 6

// When W5100 is connected we have to move CE/CSN pins for NRF radio
//#ifndef MY_RF24_CE_PIN
//#define MY_RF24_CE_PIN 5
//#endif
//#ifndef MY_RF24_CS_PIN
//#define MY_RF24_CS_PIN 6
//#endif

// Enable these if your MQTT broker requires username/password
//#define MY_MQTT_USER "username"
//#define MY_MQTT_PASSWORD "password"

// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
//#define MY_IP_ADDRESS 192,168,178,87

// If using static ip you can define Gateway and Subnet address as well
//#define MY_IP_GATEWAY_ADDRESS 192,168,178,1
//#define MY_IP_SUBNET_ADDRESS 255,255,255,0

// MQTT broker ip address or url. Define one or the other.
//#define MY_CONTROLLER_URL_ADDRESS "m20.cloudmqtt.com"
#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 68

// The MQTT broker port to to open
// With simple arduino uno's we can't use encrypted communication!
#define MY_PORT 1883

/*
// 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
// Uncomment to override default HW configurations
//#define MY_DEFAULT_ERR_LED_PIN 16  // Error led pin
//#define MY_DEFAULT_RX_LED_PIN  16  // Receive led pin
//#define MY_DEFAULT_TX_LED_PIN  16  // the PCB, on board LED
*/

#include <Ethernet.h>
#include <MySensors.h>

void before() {
    pinMode(SD_SS_PIN, OUTPUT);
    digitalWrite(SD_SS_PIN, HIGH); 
}

void setup()
{
    // Setup locally attached sensors
}

void presentation()
{
    // Present locally attached sensors here
}

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

I hope that this will be helpful for some people trying to build something equivalent

Free Shipping RFM69HW 868Mhz Transceiver Module High Integrated HopeRF Wireless 868S2 Module SPI 1.8-3.6V DC 0-800M Distance

$1.98

diymore 10PCS/Lot D215T-B-868MHz Helical Antenna 2.15dBi 13mm Stable for Remote Control

$0.71

UNO Shield Ethernet Shield W5100 R3 UNO Mega 2560 1280 328 UNR R3 only W5100 Development board FOR WAVGAT

$5.29

Standard Proto Screw Shield Board For Arduino Compatible Improved version support A6 A7 Diy Kit Electronic PCB Board Module

$0.74

3.3V 5V TXS0108E 8 Channel Logic Level Bi-directional Converter Module TXB0108 Mutual Convert Module TXS0108

$0.52

Hi Folks,

I'm new to MySensors, so before beginning building things, I read the docs, search the forum, etc., to be able to form me an idea how to start.

First taking the docs: https://www.mysensors.org/build/ethernet_gateway and https://www.mysensors.org/build/mqtt_gateway

The MQTT gateway is based on the ethernet gateway, so we are starting there.
The recommandation is to use a W5100 Ethernet module. This module has problems sharing SPI with the radio, so it is proposed to use soft-spi for the radio.
The W5100 ethernet shield module is hardware wired:

The radio should then be wired for soft-spi following the docs.
Because there is no example for a RFM69HW, I imagine that we must follow the same schematic as for the NRF24L01 radio.

The given sketch is based on the use of a NRF24L01 radio, so when searching for the correct settings for RFM69HW in the forum, I stumbled on plenty of topics of people trying to build the same thing.
Some topics are already several years old, speaking about changing core ethernet libraries for the W5100 to disable the interrupts, others are building on forks of MySensors, forks of RFM69 library, etc.
I saw also a remark in a topic that for using soft-spi, we should use the new RFM69 driver in the MySensors lib.
In one of the topics with an own fork, was mentioned that, because the transactions in SPI where now supported in the RFM69 library, we can now wire also the RFM69HW radio to the same ports on the Arduino as the ethernet module.

So, when reading all these topics, I did loose my view on the things :
With the current version of the MySensors library (2.3.1)

• must we use soft-spi like mentioned in the docs or hardware spi like found in topics on the forum?
• https://forum.mysensors.org/topic/5109/solved-rfm69-based-nodes-unable-to-report-lib-version/45 : Are these forks now included into the main branch of MySensors?

Did search the forum, but didn't really find an answer of it is now implemented by default in the MySensors library...

Found : https://forum.mysensors.org/topic/8863/esp8266-mqtt-gateway-ssl-connection
But it is already 2 years old and it is a proposal to modify the code in the MySensors library.
@monte : do you know what the status is? There is not really an answer on your topic.

Apparently this day is my lucky day

@scalz , you did me think with your comment about the samd21 board not triggering the irq.

So I looked up where the pin layouts of all these 'arduino compatible' boards are defined.
My used board is a RobotDyn Samd21 M0 board and they claim compatible with a Arduino M0 and I did use the Arduino SAMD boards (32-bits ARM Cortex-M0+) by Arduino version 1.8.3.
The code you find at: https://github.com/arduino/ArduinoCore-samd
With some help of the google doctor, I did find that the pin layouts are defined in the Variants.cpp file in
https://github.com/arduino/ArduinoCore-samd/blob/master/variants/arduino_mzero/variant.cpp
(I'm using the Arduino M0 entry when selecting my board)
In this file

/*
 *
 * + Pin number +  ZERO Board pin  |  PIN   | Label/Name      | Comments (* is for default peripheral in use)
 * +------------+------------------+--------+-----------------+------------------------------
 * |            | Digital Low      |        |                 |
 * +------------+------------------+--------+-----------------+------------------------------
 * | 0          | 0 -> RX          |  PA11  |                 | EIC/EXTINT[11] ADC/AIN[19] PTC/X[3] *SERCOM0/PAD[3] SERCOM2/PAD[3] TCC1/WO[1] TCC0/WO[3]
 * | 1          | 1 <- TX          |  PA10  |                 | EIC/EXTINT[10] ADC/AIN[18] PTC/X[2] *SERCOM0/PAD[2] TCC1/WO[0] TCC0/WO[2]
 * | 2          | ~2               |  PA08  |                 | EIC/NMI ADC/AIN[16] PTC/X[0] SERCOM0/PAD[0] SERCOM2/PAD[0] *TCC0/WO[0] TCC1/WO[2]
 * | 3          | ~3               |  PA09  |                 | EIC/EXTINT[9] ADC/AIN[17] PTC/X[1] SERCOM0/PAD[1] SERCOM2/PAD[1] *TCC0/WO[1] TCC1/WO[3]
 * | 4          | ~4               |  PA14  |                 | EIC/EXTINT[14] SERCOM2/PAD[2] SERCOM4/PAD[2] TC3/WO[0] *TCC0/WO[4]
 * | 5          | ~5               |  PA15  |                 | EIC/EXTINT[15] SERCOM2/PAD[3] SERCOM4/PAD[3] TC3/WO[1] *TCC0/WO[5]
 * | 6          | ~6               |  PA20  |                 | EIC/EXTINT[4] PTC/X[8] SERCOM5/PAD[2] SERCOM3/PAD[2] TC7/WO[0] *TCC0/WO[6]
 * | 7          | ~7               |  PA21  |                 | EIC/EXTINT[5] PTC/X[9] SERCOM5/PAD[3] SERCOM3/PAD[3] TC7/WO[1] *TCC0/WO[7]
 * +------------+------------------+--------+-----------------+------------------------------
 * |            | Digital High     |        |                 |
 * +------------+------------------+--------+-----------------+------------------------------
 * | 8          | ~8               |  PA06  |                 | EIC/EXTINT[6] PTC/Y[4] ADC/AIN[6] AC/AIN[2] SERCOM0/PAD[2] *TCC1/WO[0]
 * | 9          | ~9               |  PA07  |                 | EIC/EXTINT[7] PTC/Y[5] DC/AIN[7] AC/AIN[3] SERCOM0/PAD[3] *TCC1/WO[1]
 * | 10         | ~10              |  PA18  |                 | EIC/EXTINT[2] PTC/X[6] SERCOM1/PAD[2] SERCOM3/PAD[2] *TC3/WO[0] TCC0/WO[2]
 * | 11         | ~11              |  PA16  |                 | EIC/EXTINT[0] PTC/X[4] SERCOM1/PAD[0] SERCOM3/PAD[0] *TCC2/WO[0] TCC0/WO[6]
 * | 12         | ~12              |  PA19  |                 | EIC/EXTINT[3] PTC/X[7] SERCOM1/PAD[3] SERCOM3/PAD[3] *TC3/WO[1] TCC0/WO[3]
 * | 13         | ~13              |  PA17  | LED             | EIC/EXTINT[1] PTC/X[5] SERCOM1/PAD[1] SERCOM3/PAD[1] *TCC2/WO[1] TCC0/WO[7]
 * | 14         | GND              |        |                 |
 * | 15         | AREF             |  PA03  |                 | *DAC/VREFP PTC/Y[1]
 * | 16         | SDA              |  PA22  |                 | EIC/EXTINT[6] PTC/X[10] *SERCOM3/PAD[0] SERCOM5/PAD[0] TC4/WO[0] TCC0/WO[4]
 * | 17         | SCL              |  PA23  |                 | EIC/EXTINT[7] PTC/X[11] *SERCOM3/PAD[1] SERCOM5/PAD[1] TC4/WO[1] TCC0/WO[5]

This is the defined pin mapping for a Arduino mZero. (I was using D2 as IRQ for the RFM69)

* | 2          | ~2               |  PA08  |

But on the pin layout of the RobotDyn board I saw:

* | 2          | ~2               |  PA14  |

On the RobotDyn the pin PA08 is mapped on the D4 arduino pin and not the D2 pin!
With the pins D2/D4, RobotDyn is following here the Arduino Zero layout and NOT the Arduino mZero layout!

So, I verified the other mappings and found that following pins are different mapped on the Arduino mZero:

 * | 2          | ~2               |  PA08  | 
 
 * | 4          | ~4               |  PA14  | 

On the RobotDyn Samd21M0

 * | 2          | ~2               |  PA14  | 

 * | 4          | ~4               |  PA08  | 

So I changed the IRQ (DIO0) from the RF69 to the port D8 (PA06) and bingo it started to work (did choose randomly D8)

I saw also a difference in the SPI mapping
mZero

 * | 18         | 1                |  PA12  | MISO 

RobotDyn samd21 m0

 * |  not defined on their pin layout doc       | 1                |  PB12  | MISO 

But it is working, so maybe an error on RobotDyn's documentation?

So if I resume the thing:
The RobotDyn SAMD21 M0 board is claimed compatible with the Arduino M0 (mZero). In the IDE you must also select the Arduino M0. (selecting Arduino/Genuino Zero xxx will not work)
But the RobotDyn used layout is compatible with the Arduino Zero, so pin D2 and D4 are reversed, making the code of the board Arduino M0 not working if you choose to use these pins in your design.

So now we can continue to build our gateway, my originally goal.
Edit : my MQTT gateway with the RobotDyn Samd21 M0 board, a W5500 ethernet module and a radio RFM69HW is up and running

Thanks for all comments that guided me to the solution

@Les, I'm still learning also

In your first post you mentioned the wemos - rfm69hw hardware connections:
GND GND
3.3V VCC
D1 DIO0
D5 SCK
D6 MISO
D7 MOSI
D8 NSS

In previous posts, you mentioned in your sketch:
#define MY_RFM69_IRQ_PIN D1
#define MY_RFM69_IRQ_NUM MY_RFM69_IRQ_PIN
#define MY_RFM69_CS_PIN D8

But in the latest debug output, I see:

12946 RFM69:INIT:PIN,CS=15,IQP=5,IQN=5

Your CS/NSS pin is now on D15 and the IRQ pin on D5?
@mfalkvidd: or must I interpret these numbers different?
(I don't want to hijack this thread, but I've the same problem with my SAMD21 M0 board, see my thread in the same section )

@tbowmo
An old thread already : https://forum.mysensors.org/topic/5555/arduino-zero-supported/6
It should be possible to use the zero with mysensors library. And as @scalz mentions, the upcoming Sensebender GW is based on basically the same mcu, as used in the zero.
However you can't use the the gw files for the zero, as I use a couple of tricks, and use multiple spi ports, which isn't available on the zero, if I remember correctly.
Is this still true? What you mean by use multiple spi ports?
On the robotdyn samd21 M0 board there is only one SPI port, via the header.

That is something I have still problems with: what are the pinnumber to use if not an Arduino UNO?
#define MY_RFM69_IRQ_PIN
Define this to override the default RFM69 IRQ pin assignment.
#define MY_RFM69_IRQ_NUM digitalPinToInterrupt(MY_RFM69_IRQ_PIN)
Should I define here 14 (from the pin PA14)?

EDIT: I tested it quickly by putting the define MY_RFM69_IRQ_NUM equal to 14, but no change in the result, same behaviour.

My hardware connections:
Samd31 M0 board --> RFM69HW
PA14/D2 --> DIO0
PA21/D7 --> NSS
MOSI/PB10(ISP header) --> MOSI
MISO/PB12(ISP header) --> MISO
SCK/PB11(ISP header) --> SCK

As test sketch I'm using the example pingpongsensor example adapted for the RF69 radio.
The IRQ pin is not defined, because I thought that mysensors lib takes pin D2 as the default.
Out of range is normally not the case, they are at 10 cm of each other...

/*
 * 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-2018 Sensnology AB
 * Full contributor list: https://github.com/mysensors/MySensors/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.
 *
 *******************************
 *
 *  This is a simple sketch used to demonstrate and test node-to-node MySensors communication.
 *  To use this sketch, assemble MySensors nodes - they need nothing more than a radio
 *  1.  Flash each node with the same sketch, open the console and type either 0 or 1 to the respective nodes to set their ID
 *  2.  You only need to set the node id once, and restart the nodes
 *  3.  To being a ping-pong test, simply type T in the console for one of the nodes.
 *
 *  2015-05-25 Bruce Lacey v1.0
 */

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

// Enable and select radio type attached
#define MY_RADIO_RFM69
#define MY_RFM69_FREQUENCY RFM69_868MHZ // Set your frequency here
#define MY_IS_RFM69HW // Omit if your RFM is not "H"
#define MY_RFM69_NEW_DRIVER
#define MY_RFM69_CS_PIN 7

#define MY_SECURITY_SIMPLE_PASSWORD "mysecretpassword"

#define MY_NODE_ID 10

// https://forum.mysensors.org/topic/10548/sensbender-gateway-gives-a-lot-of-hu
// temporary fix, can be deleted when Arduino SAMD board definitions will be corrected.
#undef PRId8
#undef PRIi8
#undef PRIo8
#undef PRIu8
#undef PRIx8
#undef PRIX8
#undef PRIdLEAST8
#undef PRIiLEAST8
#undef PRIoLEAST8
#undef PRIuLEAST8
#undef PRIxLEAST8
#undef PRIXLEAST8
#undef PRIdFAST8
#undef PRIiFAST8
#undef PRIoFAST8
#undef PRIuFAST8
#undef PRIxFAST8
#undef PRIXFAST8
#define PRId8    "d"
#define PRIi8   "i"
#define PRIo8   "o"
#define PRIu8   "u"
#define PRIx8   "x"
#define PRIX8   "X"
#define PRIdLEAST8  "d"
#define PRIiLEAST8  "i"
#define PRIoLEAST8  "o"
#define PRIuLEAST8  "u"
#define PRIxLEAST8  "x"
#define PRIXLEAST8  "X"
#define PRIdFAST8 "d"
#define PRIiFAST8 "i"
#define PRIoFAST8 "o"
#define PRIuFAST8 "u"
#define PRIxFAST8 "x"
#define PRIXFAST8 "X"

#include <MySensors.h>
#include "MYSLog.h"

#define VSN "v1.0"

// Define two generic nodes with a single child
#define YING 200
#define YANG 201
#define CHILD 1

MyMessage mPing(CHILD, V_VAR1);   //Ping message
MyMessage mPong(CHILD, V_VAR2);   //Pong message

void setup()
{
}

void presentation()
{
	present(CHILD, S_CUSTOM);  //

	sendSketchInfo( nodeTypeAsCharRepresentation( getNodeId() ), VSN );
	LOG(F("\n%sReady.\n"), nodeTypeAsCharRepresentation(getNodeId()));
}

void loop()
{

	// Interactive command and control
	// Entering a number from 0 or 1 will write the node 200 (YING) or 201 (YANG) to EEPROM
	// Entering T on either node will initiate a ping-pong test.
	if (Serial.available()) {
		byte inChar = Serial.read();
		uint8_t node = getNodeId();

		// Manual Test Mode
		if (inChar == 'T' || inChar == 't') {
			LOG(F("T received - starting test...\n"));
			MyMessage msg = mPong;
			msg.sender = (node == YING ? YANG : YING);
			sendPingOrPongResponse( msg );
		} else if (inChar == '0' or inChar == '1') {
			byte nodeID = 200 + (inChar - '0');
			setNodeId(nodeID);
		} else {
			LOG("Invalid input\n");
		}
	}
}

void receive(const MyMessage &message)
{

	LOG(F("Received %s from %s\n"), msgTypeAsCharRepresentation((mysensors_data_t)message.type),
	    nodeTypeAsCharRepresentation(message.sender));

	delay(250);
	sendPingOrPongResponse( message );
}

void sendPingOrPongResponse( MyMessage msg )
{

	MyMessage response = (msg.type == V_VAR1 ? mPong : mPing);

	LOG(F("Sending %s to %s\n"), msgTypeAsCharRepresentation( (mysensors_data_t)response.type ),
	    nodeTypeAsCharRepresentation(msg.sender));

	// Set payload to current time in millis to ensure each message is unique
	response.set( (uint32_t)millis() );
	response.setDestination(msg.sender);
	send(response);
}

void setNodeId(byte nodeID)
{
	LOG(F("Setting node id to: %i.\n***Please restart the node for changes to take effect.\n"), nodeID);
	hwWriteConfig(EEPROM_NODE_ID_ADDRESS, (byte)nodeID);
}

const char * msgTypeAsCharRepresentation( mysensors_data_t mType )
{
	return mType == V_VAR1 ? "Ping" : "Pong";
}

const char * nodeTypeAsCharRepresentation( uint8_t node )
{
	return node == YING ? "Ying Node" : "Yang Node";
}

You could try the new RFM69 driver?

Add to your simple sketch
#define MY_RFM69_NEW_DRIVER

Add also some extra debug info
#define MY_DEBUG
#define MY_DEBUG_VERBOSE_RFM69
#define MY_DEBUG_VERBOSE_RFM69_REGISTERS

Maybe it will reveal something...

I activated these debug options:
#define MY_DEBUG
#define MY_DEBUG_VERBOSE_RFM69
#define MY_DEBUG_VERBOSE_RFM69_REGISTERS

316261 TSM:FAIL:RE-INIT
316271 TSM:INIT
316281 RFM69:INIT
316291 RFM69:INIT:PIN,CS=7,IQP=2,IQN=2
316302 RFM69:PTX:LEVEL=5 dBm
316312 RFM69:DUMP:Registers Address | HEX value 
316323 RFM69:DUMP:REG=0x01 Value=0x04
316333 RFM69:DUMP:REG=0x02 Value=0x00
316343 RFM69:DUMP:REG=0x03 Value=0x02
316353 RFM69:DUMP:REG=0x04 Value=0x40
316363 RFM69:DUMP:REG=0x05 Value=0x03
316374 RFM69:DUMP:REG=0x06 Value=0x33
316384 RFM69:DUMP:REG=0x07 Value=0xd9
316394 RFM69:DUMP:REG=0x08 Value=0x00
316404 RFM69:DUMP:REG=0x09 Value=0x00
316415 RFM69:DUMP:REG=0x0a Value=0x41
316425 RFM69:DUMP:REG=0x0b Value=0x00
316435 RFM69:DUMP:REG=0x0c Value=0x02
316445 RFM69:DUMP:REG=0x0d Value=0x92
316455 RFM69:DUMP:REG=0x0e Value=0xf5
316466 RFM69:DUMP:REG=0x0f Value=0x20
316476 RFM69:DUMP:REG=0x10 Value=0x24
316486 RFM69:DUMP:REG=0x11 Value=0x57
316496 RFM69:DUMP:REG=0x12 Value=0x09
316507 RFM69:DUMP:REG=0x13 Value=0x1a
316517 RFM69:DUMP:REG=0x14 Value=0x40
316527 RFM69:DUMP:REG=0x15 Value=0xb0
316537 RFM69:DUMP:REG=0x16 Value=0x7b
316547 RFM69:DUMP:REG=0x17 Value=0x9b
316558 RFM69:DUMP:REG=0x18 Value=0x88
316568 RFM69:DUMP:REG=0x19 Value=0xe2
316578 RFM69:DUMP:REG=0x1a Value=0xe2
316588 RFM69:DUMP:REG=0x1b Value=0x40
316599 RFM69:DUMP:REG=0x1c Value=0x80
316609 RFM69:DUMP:REG=0x1d Value=0x06
316619 RFM69:DUMP:REG=0x1e Value=0x10
316629 RFM69:DUMP:REG=0x1f Value=0x00
316640 RFM69:DUMP:REG=0x20 Value=0x00
316650 RFM69:DUMP:REG=0x21 Value=0x00
316660 RFM69:DUMP:REG=0x22 Value=0x00
316670 RFM69:DUMP:REG=0x23 Value=0x02
316680 RFM69:DUMP:REG=0x24 Value=0xff
316691 RFM69:DUMP:REG=0x25 Value=0x00
316701 RFM69:DUMP:REG=0x26 Value=0x07
316711 RFM69:DUMP:REG=0x27 Value=0x80
316721 RFM69:DUMP:REG=0x28 Value=0x00
316732 RFM69:DUMP:REG=0x29 Value=0xe4
316742 RFM69:DUMP:REG=0x2a Value=0x00
316752 RFM69:DUMP:REG=0x2b Value=0x00
316762 RFM69:DUMP:REG=0x2c Value=0x00
316772 RFM69:DUMP:REG=0x2d Value=0x03
316783 RFM69:DUMP:REG=0x2e Value=0x88
316793 RFM69:DUMP:REG=0x2f Value=0x2d
316803 RFM69:DUMP:REG=0x30 Value=0x64
316813 RFM69:DUMP:REG=0x31 Value=0x00
316823 RFM69:DUMP:REG=0x32 Value=0x00
316834 RFM69:DUMP:REG=0x33 Value=0x00
316844 RFM69:DUMP:REG=0x34 Value=0x00
316854 RFM69:DUMP:REG=0x35 Value=0x00
316864 RFM69:DUMP:REG=0x36 Value=0x00
316875 RFM69:DUMP:REG=0x37 Value=0xd4
316885 RFM69:DUMP:REG=0x38 Value=0x40
316895 RFM69:DUMP:REG=0x39 Value=0xff
316905 RFM69:DUMP:REG=0x3a Value=0xff
316916 RFM69:DUMP:REG=0x3b Value=0x00
316926 RFM69:DUMP:REG=0x3c Value=0x05
316936 RFM69:DUMP:REG=0x3d Value=0x10
316946 RFM69:DUMP:REG=0x3e Value=0x00
316957 RFM69:DUMP:REG=0x3f Value=0x00
316967 RFM69:DUMP:REG=0x40 Value=0x00
316977 RFM69:DUMP:REG=0x41 Value=0x00
316987 RFM69:DUMP:REG=0x42 Value=0x00
316998 RFM69:DUMP:REG=0x43 Value=0x00
317008 RFM69:DUMP:REG=0x44 Value=0x00
317018 RFM69:DUMP:REG=0x45 Value=0x00
317028 RFM69:DUMP:REG=0x46 Value=0x00
317038 RFM69:DUMP:REG=0x47 Value=0x00
317049 RFM69:DUMP:REG=0x48 Value=0x00
317059 RFM69:DUMP:REG=0x49 Value=0x00
317069 RFM69:DUMP:REG=0x4a Value=0x00
317079 RFM69:DUMP:REG=0x4b Value=0x00
317090 RFM69:DUMP:REG=0x4c Value=0x00
317100 RFM69:DUMP:REG=0x4d Value=0x00
317110 RFM69:DUMP:REG=0x4e Value=0x01
317120 RFM69:DUMP:REG=0x4f Value=0x00
317130 TSM:INIT:TSP OK
317141 TSM:INIT:STATID=10
317151 TSF:SID:OK,ID=10
317161 TSM:FPAR
317172 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0
317183 RFM69:CSMA:RSSI=-102
319193 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
321204 !TSM:FPAR:NO REPLY
321214 TSM:FPAR
321224 RFM69:SWR:SEND,TO=255,SEQ=1,RETRY=0
321235 RFM69:CSMA:RSSI=-98
323246 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
325257 !TSM:FPAR:NO REPLY
325267 TSM:FPAR
325277 RFM69:SWR:SEND,TO=255,SEQ=2,RETRY=0
325288 RFM69:CSMA:RSSI=-97
327299 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
329310 !TSM:FPAR:NO REPLY
329320 TSM:FPAR
329330 RFM69:SWR:SEND,TO=255,SEQ=3,RETRY=0
329341 RFM69:CSMA:RSSI=-98
331352 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
333363 !TSM:FPAR:FAIL
333373 TSM:FAIL:CNT=7
333383 TSM:FAIL:DIS
333393 TSF:TDI:TSL
333403 RFM69:RSL

I see now values in the registers, but now how to continue?

Meanwhile:
I had said that originally I did take the M0 board (by the way it is a RobotDyn SAMD21 M0 board) to build a more powerfull gateway, but because of the radio problems I was doing now tests with the M0 board as normal sensor and my working Arduino UNO as MQTT gateway to be able to see the interactions.
So today I desoldered the W5500 ethernet module from the M0 board to be sure that it was not causing a side effect.
No change in results, my M0 board sensor does send a parent request, I see in the gateway the reception and a send of the parent response, but the sensor doesn't receive anything.
Or is the sensor not waiting enough after the answer?

Already running a sensor and a MQTT gateway successfully based on Arduino Uno's.

Running a MQTT gateway on Arduino Uno works, but is too light if you want to add encryption for example.
Because I had already an Arduino Zero clone board laying around, I used this one to build a second gateway with a RFM69HW and a W5500 ethernet board.
The radio and the ethernet board are using the same SPI header pins (no soft SPI).
W5500 is using the default D10 CS pin and the radio is using D7 as CS pin and default D2 as IRQ.

The gateway is successfully communicating with the MQTT broker on TCP-IP. It receives an IP and can connect to the broker, so the W5500 ethernet module is correctly working.
The radio was doing something, but it was not a correct behaviour as gateway.

To debug, I decided to download the mocksensor sketch to it and to test it as a normal sensor togeter with the working Arduino Uno based gateway.

The log of the Arduino Based gateway:

4504614 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
4504620 TSF:MSG:BC
4504622 TSF:MSG:FPAR REQ,ID=10
4504625 TSF:PNG:SEND,TO=0
4504627 TSF:CKU:OK
4504629 TSF:MSG:GWL OK
4508907 !TSF:MSG:SEND,0-0-10-10,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
4512615 TSF:MSG:READ,10-10-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
4512620 TSF:MSG:BC
4512622 TSF:MSG:FPAR REQ,ID=10
4512625 TSF:CKU:OK,FCTRL
4512627 TSF:MSG:GWL OK

The log of the M0 board:

26196 TSM:INIT
26207 TSM:INIT:TSP OK
26217 TSM:INIT:STATID=10
26228 TSF:SID:OK,ID=10
26238 TSM:FPAR
28249 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
30260 !TSM:FPAR:NO REPLY
30270 TSM:FPAR
32281 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
34292 !TSM:FPAR:NO REPLY
34302 TSM:FPAR
36313 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
38324 !TSM:FPAR:NO REPLY
38334 TSM:FPAR
40345 TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
42356 !TSM:FPAR:FAIL
42366 TSM:FAIL:CNT=2
42376 TSM:FAIL:DIS
42386 TSF:TDI:TSL

So, the sensor is sending a parent request.
We see that the gateway is receiving the request and sends a parent response.
But the sensor never receives it...

I replaced already the radio module by another one, but same result.

Anyone an idea what could be the reason?

I searched the forum on maximum distances, but didn't find much information about it.
I know that distances can be influenced by concrete walls, steel, …, but what are the average distances you are getting with this radio RFM69HW?

This post is a try to order my thoughts about the mysensors implementation possibilities for signing and encryption.

I thought that it could be of some help for other people, who are new, like me, to mysensors and want to start using it.
This is written with in mind the current version 2.3.1 of the mysensors libary and 2 Arduinos Uno's R3 as hardware. Be aware that this can change in the future as the library will continue to evolve!

Please, if you find any mistakes, don't hesitate to point them out to me so I can correct this post.

First some (condensed) theory found in the docs and on this forum.

Two different things:

• Signing messages : this makes that the receiver is sure that the received message is really from the transmitter. The message can't be changed by somebody during the transmission of the message. This is done by the MySensors message protocol.
  More detailed explication can be found on: https://www.mysensors.org/apidocs/group__MySigninggrpPub.html#MySigninggrpencryption

• Encryption of the messages: is done on the level of the used radio itself. For RFM69HW for example, it is done by the hardware itself of the radio. It is independent from the MySensors message protocol implementation.

A. Signing of the messages

Three possibilities: 2 based on software and one based on extra external hardware. The latest I can't test because I have no Atmel ATSHA204 chips lying around...

• First option, software backed by using only a password : weaker security, but simple to activate.

  MY_SIGNING_SIMPLE_PASSWORD: this keyword enables security only on the level signing
  If the provided password is shorter than the size of the HMAC key, it will be null-padded to accommodate the key size in question. A 32 character password is the maximum length. Any password longer than that will be truncated.

• Second option, sofware backed

  MY_SIGNING_SOFT: this keyword enables security only on the level signing

  If MY_SIGNING_SIMPLE_PASSWD is used a personalisation must not be done.
  If not used, a personalization must be done, the values are stored in EEPROM.(see: https://www.mysensors.org/apidocs-beta/group__MySigninggrpPub.html#personalization). See also further on.

• Third option, hardware backed via the Atmel ATSHA204 chip

  MY_SIGNING_ATSHA204: this keyword enables security only on the level signing

  If MY_SIGNING_SIMPLE_PASSWD is used a personalisation must not be done.
  If not used, a personalization must be done, the values are written to the Atmel ATSHA204 ship. It is irreversible!! (see https://www.mysensors.org/apidocs-beta/group__MySigninggrpPub.html#personalization)

B. Encryption of the radio transport level

Only possible for the supported radios (RF24, RFM69, NRF5, RFM95 at current library version 2.3.1)(https://www.mysensors.org/apidocs-beta/group__EncryptionSettingGrpPub.html)
The RFM69 radio does support hardware encryption of the communication using AES (Advanced Encryption Standard).

• MY_ENCRYPTION_SIMPLE_PASSWORD: this keyword enables encryption on all radio communications of the radio types that supports it and uses provided password as key.
  If the provided password is shorter than the size of the AES key, it will be null-padded to accommodate the key size in question. A 16 character password is the maximum length. Any password longer than that will be truncated.
  example : #define MY_ENCRYPTION_SIMPLE_PASSWD "MyInsecurePassword"

If you are already using the first option of signing messages (MY_SIGNING_SIMPLE_PASSWORD), you can replace it by following keyword:

• MY_SECURITY_SIMPLE_PASSWORD: this keyword enables security on the level signing and encryption (only usable on Arduino. On the Raspberry PI use the other two simple options)

My practical tests

• a sensor based on an Arduino Uno with the sketch UltraSonic_sensor from the website adapted for the RFM69HW radio
• a gateway based on an Arduino, a W5100 ethernet shield for the Uno and a radio RFM69HW (see https://forum.mysensors.org/topic/10358/solved-mqtt-gateway-based-on-arduino-uno-uno-compatible-w5100-ethernet-shield-rfm69hw-radio)

1. Added in the two sketches: only encryption

#define MY_ENCRYPTION_SIMPLE_PASSWORD "my16characterpassword"

Result : it works

1. Added in the two sketches: encryption and simple signing

#define MY_ENCRYPTION_SIMPLE_PASSWORD "my16characterpassword"
#define MY_SIGNING_SIMPLE_PASSWORD "my32characterpassword"

Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work!

1. Added in the two sketches: encryption and simple signing

#define MY_ENCRYPTION_SIMPLE_PASSWORD "my16characterpassword"
#define MY_SIGNING_SIMPLE_PASSWORD "my16characterpassword"

Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work!

1. Added in the two sketches: the shortcut define for the Arduino platform

#define MY_SECURITY_SIMPLE_PASSWORD "my16characterpassword"

Result : it works

1. Added in the two sketches: the shortcut define for the Arduino platform

#define MY_SECURITY_SIMPLE_PASSWORD "my32characterpassword"

Result : it works

Is this shortcut define specially done for the Arduino platform to avoid the low memory condition?

1. Added in the two sketches : encryption and soft signing with simple password personalization

//enable radio communication encryption
#define MY_ENCRYPTION_SIMPLE_PASSWD "my16characterpassword"
#define MY_SIGNING_SIMPLE_PASSWD "my32characterpassword"
#define MY_SIGNING_SOFT
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_SOFT_RANDOMSEED_PIN A0

Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work. The signing is failing.

1. Added in the two sketches : encryption and soft signing with personalization
   First we will personalize each arduino (the sensor and the gateway)

• open the SecurityPersonalizer.ino file via the Arduino IDE menu File, Examples, Mysensors, SecurityPersonalizer
• uncomment the define GENERATE_KEYS_SOFT
• upload the sketch to your Arduino
• open the serial monitor
• here you will find your generated keys HMAC and AES keys
• copy the entries under the 'Key copy section' into the SecurityPersonalizer.ino file
• comment again the define GENERATE_KEYS_SOFT

The following 3 steps must be done on each node where you want to use soft signing

• uncomment the define PERSONALIZE_SOFT
• upload the sketch again to your Arduino
• in the serial monitor output you will find now that the keys are written to the EEPROM (see EEPROM section)

The following 5 steps must also be done on each node where you want to use whitelisting

• if you want to use whitelisting and your device does not provide a unique device ID, you have to generate a unique serial and store it in EEPROM (my arduino uno does not provide a unique device ID, so I must run the sketch)

• comment the define PERSONALIZE_SOFT

• uncomment the define PERSONALIZE_SOFT_RANDOM_SERIAL

• upload the sketch to your Arduino

• in the serial monitor output you will find now a generated serial unique device ID. This unique serial ID must be copied somewhere on a safe place. You must later on copy this key in the whitelisting define of your gateway and nodes sketches.

• Take now your sketches and add the following defines

//enable radio communication encryption
#define MY_ENCRYPTION_SIMPLE_PASSWD "my16characterpassword"
//enable soft signing
#define MY_SIGNING_SOFT
#define MY_SIGNING_REQUEST_SIGNATURES
#define MY_SIGNING_SOFT_RANDOMSEED_PIN A0
#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = 0,.serial = {0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88,0x99}},{.nodeId = 1,.serial = {0x99,0x88,0x77,0x66,0x55,0x44,0x33,0x22,0x11}}}

The MQTT gateway has always nodeid = 0 and my sensor has nodeid = 1 (the sensors must have a fixed set nodeid because in MQTT mode, the controller (like HomeAssistant) can't assign node ids).
The serials given above are fake numbers, use the ones from your sketch!

Result : warning when downloading the code into the gateway: "Low memory available, stability problems may occur."
It doesn't work!

So I think that in my case, with an Arduino Uno as MQTT gateway, only the simple signing and encryption is possible.
Maybe the hardware backed signing, but I can't test this at this moment. (see my other question : https://forum.mysensors.org/topic/10370/is-there-still-a-breakout-board-for-the-atmel-atsha204a-chip)