Communication problems between MQTT Gateway (OrangePi) and Node (Arduino Nano)

[gammlerstyle]

Hello everyone,

As I am stuck at this topic for several weeks now, you are my last hope to get a running MySensors network. Otherwise I think I will give up on this. Because this is my second attempt to build such a network, I invested several weeks and only became frustration.

I do have the following setup:

• MQTT Gateway with NRF 24L01+ module based on an OrangePi PC2 with Mosquitto and HomeAssistant running as MQTT Broker and Controller (if the communictaion between GW and Node would work )

• Arduino Nano with NRF 24L01+ module as node

The Logging of the Gateway looks like the following:

May 01 19:46:22 INFO  Starting gateway...
May 01 19:46:22 INFO  Protocol version - 2.3.1
May 01 19:46:22 DEBUG MCO:BGN:INIT GW,CP=RNNGL-Q-,REL=255,VER=2.3.1
May 01 19:46:22 DEBUG TSF:LRT:OK
May 01 19:46:22 DEBUG TSM:INIT
May 01 19:46:22 DEBUG TSF:WUR:MS=0
May 01 19:46:22 DEBUG TSM:INIT:TSP OK
May 01 19:46:22 DEBUG TSM:INIT:GW MODE
May 01 19:46:22 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
May 01 19:46:22 DEBUG MCO:REG:NOT NEEDED
May 01 19:46:22 DEBUG MCO:BGN:STP
May 01 19:46:22 DEBUG MCO:BGN:INIT OK,TSP=1
May 01 19:46:22 DEBUG GWT:RMQ:MQTT RECONNECT
May 01 19:46:22 DEBUG connected to 192.168.178.99
May 01 19:46:22 DEBUG GWT:RMQ:MQTT CONNECTED
May 01 19:46:22 DEBUG GWT:TPS:TOPIC=mysensors-out/0/255/0/0/18,MSG SENT
May 01 19:46:22 DEBUG TSM:READY:NWD REQ
May 01 19:46:22 DEBUG TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
May 01 19:46:22 DEBUG GWT:IMQ:TOPIC=mysensors-in/2/255/3/0/6, MSG RECEIVED
May 01 19:46:22 DEBUG !TSF:MSG:SEND,0-0-2-2,s=255,c=3,t=6,pt=0,l=1,sg=0,ft=0,st=NACK:M

The Logging of the Node is:

 __  __       ____
|  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
|_|  |_|\__, |____/ \___|_| |_|___/\___/|_|  |___/
        |___/                      2.3.1

16 MCO:BGN:INIT NODE,CP=RNNNA-Q-,REL=255,VER=2.3.1
26 TSM:INIT
27 TSF:WUR:MS=0
28 RF24:INIT
30 RF24:INIT:PIN,CE=9,CS=10
32 RF24:SBY
33 RF24:WBR:REG=0,VAL=62
40 RF24:WBR:REG=3,VAL=3
43 RF24:WBR:REG=4,VAL=95
45 RF24:WBR:REG=5,VAL=0
47 RF24:WBR:REG=6,VAL=3
49 RF24:WBR:REG=29,VAL=4
52 RF24:RBR:REG=29,VAL=4
54 RF24:RBR:REG=6,VAL=3
56 RF24:RBR:REG=5,VAL=0
58 RF24:WBR:REG=2,VAL=2
60 RF24:WBR:REG=1,VAL=0
62 RF24:WBR:REG=28,VAL=3
65 RF24:FRX
66 RF24:FTX
67 RF24:WBR:REG=7,VAL=112
69 TSM:INIT:TSP OK
71 TSM:INIT:STATID=2
73 RF24:WBR:REG=2,VAL=3
75 RF24:WBR:REG=1,VAL=1
77 RF24:STL
78 RF24:WBR:REG=0,VAL=63
80 RF24:WBR:REG=10,VAL=2
82 TSF:SID:OK,ID=2
84 TSM:FPAR
86 TSM:FPAR:STATP=0
88 TSM:ID
89 TSM:ID:OK
90 TSM:UPL
92 RF24:SPL
94 RF24:WBR:REG=0,VAL=62
96 RF24:OWP:RCPT=0
98 RF24:WBR:REG=10,VAL=0
100 RF24:WBR:REG=16,VAL=0
102 RF24:TXM:TO=0,LEN=8
104 RF24:FTX
134 RF24:WBR:REG=7,VAL=48
136 !RF24:TXM:MAX_RT
138 RF24:FTX
140 RF24:STL
141 RF24:WBR:REG=0,VAL=63
143 RF24:WBR:REG=10,VAL=2
145 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=NACK:1
2153 TSM:UPL
2155 RF24:SPL
2157 RF24:WBR:REG=0,VAL=62
2159 RF24:OWP:RCPT=0
2161 RF24:WBR:REG=10,VAL=0
2164 RF24:WBR:REG=16,VAL=0
2166 RF24:TXM:TO=0,LEN=8
2168 RF24:FTX
2198 RF24:WBR:REG=7,VAL=48
2201 !RF24:TXM:MAX_RT
2203 RF24:FTX
2204 RF24:STL
2205 RF24:WBR:REG=0,VAL=63
2208 RF24:WBR:REG=10,VAL=2
2210 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=1,st=NACK:1

The Part between TSM:UPL and !TSF:MSG:SEND... is repeated again and again.
Due to the Log-Parser there is no communication between the gateway and the node.

What I didn't find out until now is the meaning of !RF24:TXM:MAX_RT.

As I followed the Debug/FAQ, I already checked the wiring more than 5 times (everything ok), experimented with different NRF24 modules (Used clones that worked 2 years ago and even new genuine modules from Nordic Semiconductor, with and without PLA+LNA [shielded]).
I also experimented with different sizes of capacitors 10uF in parallel with 100nF, up to 10uF.
Furthermore I tried different power supplys. I ended up by using a 5V power supply that could handle 2Amps and one AMS1117 for the node. The OrangePi is connected via an 2.5Amps power supply. The power for the nrf module is coming directly from the pi (AMS1117 onboard).
An exchange of the Arduino nano clone also brought no success.

On software side I already tried different RF24 channels(0,77,83,125), transmission rates (250kbps, 1mbps), PA_Levels (from MAX to MIN) and I disabled signing which I planed to use.

The strange thing is, that I once had a connnection between the node and the gateway (for a few seconds) because the Gateway stored the node with the id 2 in the routing-table.
At this point I think I have to tell, that I am using fixed IDs.

Maybe the best is to show you my last configuartion:

• Configuration of the Gateway:

./configure
--spi-driver=SPIDEV 
--my-gateway=mqtt
--my-mqtt-user=mqtt_user 
--my-mqtt-password=*secret*
--my-controller-ip-address=192.168.178.99 
--my-port=1883
 --my-mqtt-client-id=MySensors-SmartHome1 
-my-mqtt-publish-topic-prefix=mysensors-out 
--my-mqtt-subscribe-topic-prefix=mysensors-in
--my-transport=rf24
--my-rf24-ce-pin=21
--my-rf24-cs-pin=13
--my-rf24-irq-pin=2
--spi-spidev-device=/dev/spidev1.0 
--my-rf24-channel=0
--my-rf24-pa-level=RF24_PA_LOW
 --extra-cxxflags="-DMY_RF24_DATARATE=\(RF24_1MBPS\) -DMY_RF24_BASE_RADIO_ID=\(0x00,0xFC,0xE1,0xA8,0xA8\)"

• Configuration Node: (shortened, only disabled features left out because of length issues)

 /**
 * @file MyConfig.h
 */
#ifndef MyConfig_h
#define MyConfig_h
#include <stdint.h>

/**
 * @defgroup SerialDebugGrpPub Serial and debugging
 * @ingroup MyConfigGrp
 * @brief These options control serial and debugging features and functionalities in the library.
 * @{
 */

/**
 * @def MY_DEBUG
 * @brief Define MY_DEBUG to show debug prints.
 *
 * This option will add a lot to the size of the final sketch but is helpful to see what is actually
 * is happening during development.
 *
 * @note Values in parenthesis indicate default values which will be used if you have not defined
 * the flag in your sketch.
 */
#define MY_DEBUG

/**
 * @def MY_BAUD_RATE
 * @brief Serial output baud rate (debug prints and serial gateway speed).
 *
 * The baud rate configured here must match the baud rate at the "other" end.
 *
 * @warning Depending on your target device and clock speed, certain baud rates might not work well.
 */
#ifndef MY_BAUD_RATE
#define MY_BAUD_RATE (115200ul)
#endif

/**
 * @def MY_SERIAL_OUTPUT_SIZE
 * @brief Maximum characters for serial output.
 *
 * If you are running extremely low on memory, reducing this size might just save your day.
 */
#ifndef MY_SERIAL_OUTPUT_SIZE
#define MY_SERIAL_OUTPUT_SIZE (120u)
#endif
/** @}*/ // End of SerialDebugGrpPub group
/**
 * @defgroup RadioSettingGrpPub Radio selection
 * @ingroup MyConfigGrp
 * @brief These options control what radio type to use and various radio specific customisations.
 * @{
 */

/**
 * @defgroup RF24SettingGrpPub RF24
 * @ingroup RadioSettingGrpPub
 * @brief These options are specific to the RF24 family of wireless transport modules.
 *
 * The following chips are supported by this driver:
 * | Vendor                   | Chip
 * |--------------------------|----------
 * | Nordic Semiconductor     | nRF24L01
 * |                          | nRF24L01+
 * @{
 */

// legacy - remove for 3.0.0
/**
* @def MY_RADIO_NRF24
* @brief Define this to use a RF24-based radio transport for sensor network communication.
* @deprecated This flag is deprecated and replaced by @ref MY_RADIO_RF24
*/
#ifdef MY_RADIO_NRF24
#warning MY_RADIO_NRF24 is deprecated, use MY_RADIO_RF24 instead.
#undef MY_RADIO_NRF24
#define MY_RADIO_RF24
#endif

/**
 * @def MY_RADIO_RF24
 * @brief Define this to use a RF24-based radio transport for sensor network communication.
 */
 #define MY_RADIO_RF24

/**
 * @def MY_RF24_ENABLE_ENCRYPTION
 * @brief Define this to enable software based %AES encryption.
 *
 * All nodes and gateway must have this enabled, and all must be personalized with the same %AES
 * key.
 * @see @ref personalization
 *
 * @warning This driver always sets the initialization vector to 0 so encryption is weak.
 */
//#define MY_RF24_ENABLE_ENCRYPTION

/**
 * @def MY_DEBUG_VERBOSE_RF24
 * @brief Define this for verbose debug prints related to the RF24 driver.
 */
#define MY_DEBUG_VERBOSE_RF24

/**
 * @def MY_RF24_SPI_SPEED
 * @brief Define this if you need to run the SPI clock at a different frequency than the default.
 *
 * Default nRF24L01+ SPI speed, 2MHz should be safe for nRF24L01+ clones.
 */
#ifndef MY_RF24_SPI_SPEED
#define MY_RF24_SPI_SPEED (2*1000000ul)
#endif

/**
 * @def MY_RF24_CE_PIN
 * @brief Define this to change the chip enable pin from the default.
 */
#define MY_RF24_CE_PIN (9)//Pin D9
#ifndef MY_RF24_CE_PIN
#define MY_RF24_CE_PIN (DEFAULT_RF24_CE_PIN)
#endif

/**
 * @def MY_RF24_CS_PIN
 * @brief Define this to change the chip select pin from the default.
 */
#define MY_RF24_CS_PIN (10)//Pin D10
#ifndef MY_RF24_CS_PIN
#define MY_RF24_CS_PIN (DEFAULT_RF24_CS_PIN)
#endif

/**
 * @def MY_RF24_IRQ_PIN
 * @brief Define this to use the IRQ pin of the RF24 module (optional).
 */
#define MY_RF24_IRQ_PIN ((2)) //Pin D2  //CAN NOT BE USED WITH SOFT SPI!!

/**
 * @def MY_RF24_POWER_PIN
 * @brief Define this to use the RF24 power pin (optional).
 */
//#define MY_RF24_POWER_PIN (3)

/**
 * @def MY_RX_MESSAGE_BUFFER_FEATURE
 * @brief This enables the receiving buffer feature.
 *
 * This feature is currently not supported for anything but RF24.
 * Require @ref MY_RF24_IRQ_PIN to be set.
 */
#define MY_RX_MESSAGE_BUFFER_FEATURE

/**
 * @def MY_RX_MESSAGE_BUFFER_SIZE
 * @brief Define this to change the incoming message buffer size from the default.
 *
 * Require @ref MY_RX_MESSAGE_BUFFER_FEATURE to be set.
 */
#ifdef MY_RX_MESSAGE_BUFFER_FEATURE
#ifndef MY_RX_MESSAGE_BUFFER_SIZE
#define MY_RX_MESSAGE_BUFFER_SIZE (20)
#endif
#endif

/**
 * @def MY_RF24_PA_LEVEL
 * @brief Default RF24 PA level. Override in sketch if needed.
 *
 * - RF24_PA_MIN = -18dBm
 * - RF24_PA_LOW = -12dBm
 * - RF24_PA_HIGH = -6dBm
 * - RF24_PA_MAX = 0dBm
 */
#ifndef MY_RF24_PA_LEVEL
#define MY_RF24_PA_LEVEL (RF24_PA_LOW)
#endif

/**
 * @def MY_RF24_CHANNEL
 * @brief RF channel for the sensor net, 0-125.
 *
 * Frequencies: 2400 Mhz - 2525 Mhz
 *
 * Channels: 126
 * @see https://www.nordicsemi.com/eng/nordic/download_resource/8765/2/42877161/2726
 *
 * - 0 => 2400 Mhz (RF24 channel 1)
 * - 1 => 2401 Mhz (RF24 channel 2)
 * - 76 => 2476 Mhz (RF24 channel 77)
 * - 83 => 2483 Mhz (RF24 channel 84)
 * - 124 => 2524 Mhz (RF24 channel 125)
 * - 125 => 2525 Mhz (RF24 channel 126)
 *
 * In some countries there might be limitations, in Germany for example only the range
 * 2400,0 - 2483,5 Mhz is allowed.
 * @see http://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/2013_10_WLAN_2,4GHz_pdf.pdf
 */
#ifndef MY_RF24_CHANNEL
#define MY_RF24_CHANNEL (0)
#endif

/**
 * @def MY_RF24_DATARATE
 * @brief RF24 data rate.
 *
 * - RF24_250KBPS for 250kbs
 * - RF24_1MBPS for 1Mbps
 * - RF24_2MBPS for 2Mbps.
 *
 * @note nRF24L01, BK2401, BK2421, BK2491 and XN297 does not support RF24_250KBPS
 * @note BK2401 does not support RF24_2MBPS
 */
#ifndef MY_RF24_DATARATE
#define MY_RF24_DATARATE (RF24_1MBPS)
#endif

/**
 * @def MY_RF24_BASE_RADIO_ID
 * @brief RF24 radio network identifier.
 *
 * This acts as base value for sensor nodeId addresses. Change this (or channel) if you have more
 * than one sensor network.
 */
#ifndef MY_RF24_BASE_RADIO_ID
#define MY_RF24_BASE_RADIO_ID 0x00,0xFC,0xE1,0xA8,0xA8
#endif

/**
 * @def MY_RF24_ADDR_WIDTH
 * @brief RF24 base address width.
 */
#ifndef MY_RF24_ADDR_WIDTH
#define MY_RF24_ADDR_WIDTH (5)
#endif
/** @}*/ // End of RF24SettingGrpPub group

/** @}*/ // End of RadioSettingGrpPub group

/**
 * @defgroup RoutingNodeSettingGrpPub Routing and node
 * @ingroup MyConfigGrp
 * @brief These options control message routing and node configurations.
 * @{
 */
/**
 * @def MY_DISABLE_RAM_ROUTING_TABLE_FEATURE
 * @ingroup memorysavings
 * @brief If defined, routing table will not be kept in RAM.
 * @see MY_RAM_ROUTING_TABLE_FEATURE
 */
/**
 * @def MY_RAM_ROUTING_TABLE_FEATURE
 * @brief If enabled, the routing table is kept in RAM (if memory allows) and saved in regular
 *        intervals.
 * @note Enabled by default on most platforms, but on AVR only for atmega1280, atmega1284 and
 *       atmega2560.
 * @see MY_DISABLE_RAM_ROUTING_TABLE_FEATURE
 */
#ifndef MY_DISABLE_RAM_ROUTING_TABLE_FEATURE
#define MY_RAM_ROUTING_TABLE_FEATURE
#endif

/**
 * @def MY_ROUTING_TABLE_SAVE_INTERVAL_MS
 * @brief Interval to dump content of routing table to EEPROM
 */
#ifndef MY_ROUTING_TABLE_SAVE_INTERVAL_MS
#define MY_ROUTING_TABLE_SAVE_INTERVAL_MS (30*60*1000ul)
#endif

/**
 * @def MY_REPEATER_FEATURE
 * @brief Enables repeater functionality (relays messages from other nodes)
 * @note Repeaters need to be constantly kept awake to be useful. They are therefore not suitable
 *       for battery powered operation.
 */
//#define MY_REPEATER_FEATURE

/**
 * @def MY_PASSIVE_NODE
 * @brief If enabled, the node operates fully autonomously, i.e. messages are sent without ACKing.
 *
 * @note All transport-related checks and safety-mechanisms are disabled.
 * @note Requires that @ref MY_NODE_ID is set, @ref MY_PARENT_NODE_ID and
 *       @ref MY_PARENT_NODE_IS_STATIC are optional.
 * @note Singing, registration, and OTA FW update are disabled.
 */
//#define MY_PASSIVE_NODE

/**
 * @def MY_NODE_ID
 * @brief Node id defaults to AUTO (tries to fetch id from controller).
 */
#define MY_NODE_ID (2)
#ifndef MY_NODE_ID
#define MY_NODE_ID (AUTO)
#endif

/**
 * @def MY_PARENT_NODE_ID
 * @brief Node parent defaults to AUTO (tries to find a parent automatically).
 */
#define MY_PARENT_NODE_ID (0)
#ifndef MY_PARENT_NODE_ID
#define MY_PARENT_NODE_ID (AUTO)
#endif

/**
 * @def MY_PARENT_NODE_IS_STATIC
 * @brief Define MY_PARENT_NODE_IS_STATIC to disable fall back if parent node fails
 */
#define MY_PARENT_NODE_IS_STATIC

/**
 * @def MY_TRANSPORT_SANITY_CHECK
 * @brief If defined, will cause node to check transport in regular intervals to detect HW issues
 *        and re-initialize in case of failure.
 * @note This feature is enabled for all repeater nodes (incl. GW)
 */
#define MY_TRANSPORT_SANITY_CHECK

/**
 * @def MY_TRANSPORT_SANITY_CHECK_INTERVAL_MS
 * @brief Interval (in ms) for transport sanity checks
 */
#ifndef MY_TRANSPORT_SANITY_CHECK_INTERVAL_MS
#define MY_TRANSPORT_SANITY_CHECK_INTERVAL_MS (15*60*1000ul)
#endif
/**
 * @def MY_TRANSPORT_DISCOVERY_INTERVAL_MS
 * @brief This is a gateway-only feature: Interval (in ms) to issue network discovery checks
 */
//#ifndef MY_TRANSPORT_DISCOVERY_INTERVAL_MS
//#define MY_TRANSPORT_DISCOVERY_INTERVAL_MS (20*60*1000ul)
//#endif

/**
 *@def MY_TRANSPORT_UPLINK_CHECK_DISABLED
 *@brief If defined, disables uplink check to GW during transport initialisation
 */

/**
 *@def MY_TRANSPORT_MAX_TX_FAILURES
 *@brief Define to override max. consecutive TX failures until SNP is initiated
 */
//#define MY_TRANSPORT_MAX_TX_FAILURES (10u)

/**
 * @def MY_TRANSPORT_WAIT_READY_MS
 * @brief Timeout in ms until transport is ready during startup, set to 0 for no timeout
 */
#ifndef MY_TRANSPORT_WAIT_READY_MS
#define MY_TRANSPORT_WAIT_READY_MS (0)
#endif

/**
* @def MY_SIGNAL_REPORT_ENABLED
* @brief Enables signal report functionality.
* @note This feature adds ~1kB code to the sketch.
*/
//#define MY_SIGNAL_REPORT_ENABLED

/** @}*/ // End of RoutingNodeSettingGrpPub group

/**
 * @defgroup RegistrationSettingGrpPub Node registration
 * @ingroup MyConfigGrp
 * @brief These options control node registration configurations.
 * @{
 */
/**
 * @def MY_REGISTRATION_FEATURE
 * @brief If enabled, node has to register to GW/controller before being allowed to send sensor
 *        data.
 * @note Enabled by default.
 */
#define MY_REGISTRATION_FEATURE

/**
 * @def MY_REGISTRATION_RETRIES
 * @brief Number of registration retries if no reply received from GW/controller.
 */

#ifndef MY_REGISTRATION_RETRIES
#define MY_REGISTRATION_RETRIES (3u)
#endif

/**
* @def MY_REGISTRATION_DEFAULT
* @brief Node registration default - this applies if no registration response is received from
 *       controller.
*/
#define MY_REGISTRATION_DEFAULT (true)

/**
 * @def MY_REGISTRATION_CONTROLLER
 * @brief If defined, node registration request has to be handled by controller
 */
//#define MY_REGISTRATION_CONTROLLER
/** @}*/ // End of RegistrationSettingGrpPub group

/**
 * @defgroup CoreSettingGrpPub Core
 * @ingroup MyConfigGrp
 * @brief These options control the library core configurations.
 * @{
 */
/**
 * @def MY_CORE_ONLY
 * @brief Define this if you want to use core functions without loading the framework.
 */
//#define MY_CORE_ONLY

/**
 * @def MY_CORE_COMPATIBILITY_CHECK
 * @brief If defined, library compatibility is checked during node registration.
 *        Incompatible libraries are unable to send sensor data.
 */
#define MY_CORE_COMPATIBILITY_CHECK
/** @}*/ // End of CoreSettingGrpPub group

/**
 * @defgroup SleepSettingGrpPub Sleep
 * @ingroup MyConfigGrp
 * @brief These options control sleep configurations.
 * @{
 */
/**
 * @def MY_SLEEP_TRANSPORT_RECONNECT_TIMEOUT_MS
 * @brief Timeout (in ms) to re-establish link if node is send to sleep and transport is not ready.
 */
#ifndef MY_SLEEP_TRANSPORT_RECONNECT_TIMEOUT_MS
#define MY_SLEEP_TRANSPORT_RECONNECT_TIMEOUT_MS (10*1000ul)
#endif

/**
 * @def MY_SMART_SLEEP_WAIT_DURATION_MS
 * @brief The wait period (in ms) before going to sleep when using smartSleep-functions.
 *
 * This period has to be long enough for controller to be able to send out
 * potential buffered messages.
 */
#ifndef MY_SMART_SLEEP_WAIT_DURATION_MS
#define MY_SMART_SLEEP_WAIT_DURATION_MS (500ul)
#endif
/** @}*/ // End of SleepSettingGrpPub group

/**
 * @defgroup OTASettingGrpPub Over The Air firmware
 * @ingroup MyConfigGrp
 * @brief These options control OTA firmware configurations.
 * @{
 */

/**
 * @def MY_OTA_FIRMWARE_FEATURE
 * @brief Define this in sketch to allow safe over-the-air firmware updates.
 *
 * This feature requires external flash and the DualOptiBoot boot-loader.
 * @note You can still have OTA FW updates without external flash but it
 *       requires the MYSBootloader and you must not define this flag.
 */
//#define MY_OTA_FIRMWARE_FEATURE

/**
 * @def MY_OTA_FLASH_SS
 * @brief Slave select pin for external flash used for OTA.
 */
#ifndef MY_OTA_FLASH_SS
#define MY_OTA_FLASH_SS (8)
#endif

/**
 * @def MY_OTA_FLASH_JDECID
 * @brief Flash JDECID used for OTA. Use (0x00) if unknown.
 */
#ifndef MY_OTA_FLASH_JDECID
#define MY_OTA_FLASH_JDECID (0x1F65)
#endif

/**
 * @def MY_DISABLE_REMOTE_RESET
 * @brief Disables over-the-air reset of node
 */
//#define MY_DISABLE_REMOTE_RESET
/** @}*/ // End of OTASettingGrpPub group

/**
 * @defgroup SecuritySettingGrpPub Security
 * @ingroup MyConfigGrp
 * @brief These options control security related configurations.
/**
 * @def MY_SECURITY_SIMPLE_PASSWD
 * @brief Enables SW backed signing functionality and encryption functionality in library and uses
 *        provided password as key.
 *
 * Example: @code #define MY_SECURITY_SIMPLE_PASSWD "MyInsecurePassword" @endcode
 *
 * For details on the effects, see the references.
 * @see MY_SIGNING_SIMPLE_PASSWD, MY_ENCRYPTION_SIMPLE_PASSWD
 */
//#define MY_SECURITY_SIMPLE_PASSWD "MyInsecurePassword"
#if defined(MY_SECURITY_SIMPLE_PASSWD)
#define MY_SIGNING_SIMPLE_PASSWD MY_SECURITY_SIMPLE_PASSWD
#define MY_ENCRYPTION_SIMPLE_PASSWD MY_SECURITY_SIMPLE_PASSWD
#endif

/**
 * @defgroup SigningSettingGrpPub Signing
 * @ingroup SecuritySettingGrpPub
 * @brief These options control signing related configurations.
 *
 * @see MySigninggrpPub
 * @{
 */
/**
* @def MY_DEBUG_VERBOSE_SIGNING
* @brief Define this for verbose debug prints related to signing.
*/
//#define MY_DEBUG_VERBOSE_SIGNING

/**
 * @def MY_SIGNING_SIMPLE_PASSWD
 * @brief Enables SW backed signing functionality in library and uses provided password as key.
 *
 * This flag is automatically set if @ref MY_SECURITY_SIMPLE_PASSWD is used.
 *
 * This flag will enable signing and signature requests. It has to be identical on ALL nodes in the
 * network.
 *
 * Whitelisting is supported and serial will be the first 8 characters of the password, the ninth
 * character will be the node ID (to make each node have a unique serial).
 *
 * As with the regular signing modes, whitelisting is only activated if a whitelist is specified in
 * the sketch.
 *
 * No @ref personalization is required for this mode.
 *
 * It is allowed to set @ref MY_SIGNING_WEAK_SECURITY for deployment purposes in this mode as it is
 * with the regular software and ATSHA204A based modes.
 *
 * 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.
 *
 * Example: @code #define MY_SIGNING_SIMPLE_PASSWD "MyInsecurePassword" @endcode
 *
 * @see MY_SECURITY_SIMPLE_PASSWD
 *
 */
//#define MY_SIGNING_SIMPLE_PASSWD "*secret*"
#if defined(MY_SIGNING_SIMPLE_PASSWD)
#define MY_SIGNING_SOFT
#define MY_SIGNING_REQUEST_SIGNATURES
#endif

/**
 * @def MY_SIGNING_ATSHA204
 * @brief Enables HW backed signing functionality in library.
 */
//#define MY_SIGNING_ATSHA204

/**
 * @def MY_SIGNING_SOFT
 * @brief Enables SW backed signing functionality in library.
 */
//#define MY_SIGNING_SOFT

/**
 * @def MY_SIGNING_REQUEST_SIGNATURES
 * @brief Enable this to inform gateway to sign all messages sent to this node.
 *
 * If used for a gateway, gateway will by default require signatures from ALL nodes. This behavior
 * can be disabled by weakening security.
 * @see MY_SIGNING_WEAK_SECURITY
 */
//#define MY_SIGNING_REQUEST_SIGNATURES

/**
 * @def MY_SIGNING_WEAK_SECURITY
 * @brief Enable this to permit downgrade of security preferences and relaxed gateway signing
 *        requirements.
 */
//#define MY_SIGNING_WEAK_SECURITY

/**
 * @def MY_VERIFICATION_TIMEOUT_MS
 * @brief Define a suitable timeout for a signature verification session
 *
 * Consider the turnaround from a nonce being generated to a signed message being received
 * which might vary, especially in networks with many hops.
 *
 * Shorter time gives less time for an attacker to figure a way to hijack the nonce and attempt to
 * brute force attack the node. Longer time permits more network hops and node or GW processing
 * time. 5s ought to be enough for anyone.
 */
#ifndef MY_VERIFICATION_TIMEOUT_MS
#define MY_VERIFICATION_TIMEOUT_MS (5*1000ul)
#endif

/**
 * @def MY_SIGNING_NODE_WHITELISTING
 * @brief Define to turn on whitelisting
 */
//#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0x09,0x08,0x07,0x06,0x05,0x04,0x03,0x02,0x01}}}

/**
 * @def MY_SIGNING_ATSHA204_PIN
 * @brief Atsha204a default pin setting. Set it to match the pin the device is attached to.
 */
//#ifndef MY_SIGNING_ATSHA204_PIN
//#define MY_SIGNING_ATSHA204_PIN (17)
//#endif

/**
 * @def MY_SIGNING_SOFT_RANDOMSEED_PIN
 * @brief Pin used for random seed generation in soft signing
 * @note Do not connect anything to this when soft signing is enabled, or the seed will be
 *       predictable.
 */
#ifndef MY_SIGNING_SOFT_RANDOMSEED_PIN
#define MY_SIGNING_SOFT_RANDOMSEED_PIN (A7)
#endif

/**
 * @def MY_LOCK_DEVICE
 * @brief Enable read back protection
 *
 * Enable read back protection feature. Currently only supported by NRF51+NRF52.
 * Use this flag to protect signing and encryption keys stored in the MCU.
 *
 * Set this flag, when you use softsigning in MySensors. Don't set this
 * in SecurityPersonalizer.
 *
 * @warning YOU CAN BRICK YOUR DEVICE!!!
 *          Don't set this flag without having an boot loader, OTA firmware update and
 *          an Gateway connection. To reset an device, you can try >>
 *          openocd -f interface/cmsis-dap.cfg -f target/nrf52.cfg -c "program dap apreg 1 0x04 0x01"
 */
//#define MY_LOCK_DEVICE

/**
 * @def MY_SIGNING_FEATURE
 * @ingroup internals
 * @brief Helper flag to indicate that some signing feature is enabled, set automatically
 */
#if defined(MY_SIGNING_ATSHA204) || defined(MY_SIGNING_SOFT)
#define MY_SIGNING_FEATURE
#endif
/** @}*/ // End of SigningSettingGrpPub group

/**
 * @defgroup EncryptionSettingGrpPub Encryption
 * @ingroup SecuritySettingGrpPub
 * @brief These options control encryption related configurations.
 *
 * Note that encryption is toggled on a per-radio basis.
 * @see MY_RF24_ENABLE_ENCRYPTION, MY_RFM69_ENABLE_ENCRYPTION, MY_NRF5_ESB_ENABLE_ENCRYPTION, MY_RFM95_ENABLE_ENCRYPTION
 * @{
 */

/**
 * @def MY_ENCRYPTION_SIMPLE_PASSWD
 * @brief Enables encryption on all radio transports that supports it and uses provided password as key.
 *
 * This flag is automatically set if @ref MY_SECURITY_SIMPLE_PASSWD is used.
 *
 * This flag will enable encryption. It has to be identical on ALL nodes in the network.
 *
 * No @ref personalization is required for this mode.
 *
 * 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: @code #define MY_ENCRYPTION_SIMPLE_PASSWD "MyInsecurePassword" @endcode
 *
 * @see MY_SECURITY_SIMPLE_PASSWD
 */
//#define MY_ENCRYPTION_SIMPLE_PASSWD "MyInsecurePassword"
#if defined(MY_ENCRYPTION_SIMPLE_PASSWD)
#ifndef MY_RF24_ENABLE_ENCRYPTION
#define MY_RF24_ENABLE_ENCRYPTION
#endif
#ifndef MY_RFM69_ENABLE_ENCRYPTION
#define MY_RFM69_ENABLE_ENCRYPTION
#endif
#ifndef MY_NRF5_ESB_ENABLE_ENCRYPTION
#define MY_NRF5_ESB_ENABLE_ENCRYPTION
#endif
#ifndef MY_RFM95_ENABLE_ENCRYPTION
#define MY_RFM95_ENABLE_ENCRYPTION
#endif
#endif

/**
 * @def MY_ENCRYPTION_FEATURE
 * @ingroup internals
 * @brief Helper flag to indicate that some encryption feature is enabled, set automatically
 * @see MY_RF24_ENABLE_ENCRYPTION, MY_RFM69_ENABLE_ENCRYPTION, MY_NRF5_ESB_ENABLE_ENCRYPTION, MY_RFM95_ENABLE_ENCRYPTION
 */
#if defined(MY_RF24_ENABLE_ENCRYPTION) || defined(MY_RFM69_ENABLE_ENCRYPTION) || defined(MY_NRF5_ESB_ENABLE_ENCRYPTION) || defined(MY_RFM95_ENABLE_ENCRYPTION)
#define MY_ENCRYPTION_FEATURE
#endif
/** @}*/ // End of EncryptionSettingGrpPub group

/**
 * @defgroup MyLockgrppub Node locking
 * @ingroup MyConfig
 * @brief These options control node lock related configurations.
 *
 * This feature locks a node that suspect itself for being under some form of attack.
 *
 * This is achieved by having a counter stored in EEPROM which decrements when suspicious activity
 * is detected.
 *
 * If the counter reaches 0, the node will not work anymore and will transmit a @ref I_LOCKED
 * message to the gateway/controller with 30 minute intervals. Payload is a string with a reason for
 * the locking.
 *
 * The string is abbreviated to accommodate a signature. The following abbreviations exist at the
 * moment:
 * - LDB (Locked During Boot)
 * - TMNR (Too Many Nonce Requests)
 * - TMFV (Too Many Failed Verifications)
 *
 * Typically, the counter only decrements when suspicious activity happens in a row.
 * It is reset if legit traffic is present.
 *
 * Examples of malicious activity are:
 * - Repeatedly incorrectly checksummed OTA firmware
 * - Repeated requests for signing nonces without properly signed messages arriving
 * - Repeatedly failed signature verifications
 *
 * If counter reaches zero, node locks down and EEPROM has to be erased/reset to reactivate node.
 * Node can also be unlocked by grounding a pin.
 * @see MY_NODE_UNLOCK_PIN
 *
 * The size of the counter can be adjusted using @ref MY_NODE_LOCK_COUNTER_MAX.
 * @{
 */
/**
 * @def MY_NODE_LOCK_FEATURE
 * @brief Enable this to activate intrusion prevention mechanisms on the node.
 */
//#define MY_NODE_LOCK_FEATURE

/**
 * @def MY_NODE_UNLOCK_PIN
 * @brief By grounding this pin during reset of a locked node, the node will unlock.
 *
 * If using a secure bootloader, grounding the pin is the only option to reactivate the node.
 * If using stock Android bootloader or a DualOptiBoot it is also possible to download a sketch
 * using serial protocol to erase EEPROM to unlock the node.
 */
#ifndef MY_NODE_UNLOCK_PIN
#define MY_NODE_UNLOCK_PIN (14)
#endif

/**
 * @def MY_NODE_LOCK_COUNTER_MAX
 * @brief Maximum accepted occurrences of suspected malicious activity in a node.
 *
 * Counter decrements on reoccurring incidents but resets if legitimate behaviour is identified.
 */
#ifndef MY_NODE_LOCK_COUNTER_MAX
#define MY_NODE_LOCK_COUNTER_MAX (5)
#endif
/** @}*/ // Node lock group
/** @}*/ // End of SecuritySettingGrpPub group

/**
 * @defgroup PlatformSettingGrpPub Platform specifics
 * @ingroup MyConfigGrp
 * @brief These options control platform specific configurations.
 * @{
 */
/**
 * @defgroup ESP8266SettingGrpPub ESP8266
 * @ingroup PlatformSettingGrpPub
 * @brief These options control ESP8266 specific configurations.
 * @{
 */
/**
 * @def MY_ESP8266_SERIAL_MODE
 * @brief ESP8266 serial modes
 *
 * - SERIAL_FULL: Default mode.
 * - SERIAL_TX_ONLY: allows to use RX (GPIO3) as a general purpose input/output.
 * - SERIAL_RX_ONLY: allows to use TX (GPIO1) as a general purpose input/output.
 */
#ifndef MY_ESP8266_SERIAL_MODE
#define MY_ESP8266_SERIAL_MODE SERIAL_FULL
#endif
/** @}*/ // End of ESP8266SettingGrpPub group

/**
* @defgroup ESP32SettingGrpPub ESP32
* @ingroup PlatformSettingGrpPub
* @brief These options control ESP32 specific configurations.
* @{
*/

As the logging from my gateway was similar to the one from this topic I also tried the fix explained here:
@flyingdomotic said in [Solved] Nodes having trouble reconnecting to gateway:

@grumpazoid: I had recently the same issue with a 2560 node and a Nano gateway. I fixed it putting a delayMicroseconds(1500) at (very) top of RF24stopListening function.

LOCAL void RF24_stopListening(void)
{
	// The following delay will allow this node to send an ACK to the last received message
	//	Value should be at least equal to ACR (1500 ms for 250 Kb/s transmission with 15 retries
	delayMicroseconds(1500);			//// *** FF_CHANGE *** //// 
	RF24_DEBUG(PSTR("RF24:SPL\n"));	// stop listening
	RF24_ce(LOW);
	// timing
	delayMicroseconds(130);
	RF24_setRFConfiguration(RF24_CONFIGURATION | _BV(RF24_PWR_UP) );
	// timing
	delayMicroseconds(100);
}

Don't know if your trouble is the same as mine, but hope this helps!

The final conclusion of this topic, to shield the nrf24l01 modules was also tested by me as I used this modules:
https://de.aliexpress.com/item/E01-ML01DP5-Ebyte-2-4GHz-20dBm-2100m-nRF24L01-SPI-Wireless-transceiver-module/32638720689.html

I hope I have not forgotten any information right now.
I would really appreciate if someone would help me to get this fixed.

P.S.: I already tried the development branch on the OrangePi side with no success.
P.P.S.: Maybe I have the same issue as in this topic? -> https://forum.mysensors.org/topic/10339/node-not-working-with-existing-gateway

[bgunnarb]

@gammlerstyle said in Communication problems between MQTT Gateway (OrangePi) and Node (Arduino Nano):

--my-port=1883
--my-mqtt-client-id=MySensors-SmartHome1
-my-mqtt-publish-topic-prefix=mysensors-out
--my-mqtt-subscribe-topic-prefix=mysensors-in

Just an observation: There is one dash missing in the ./configure command line on the publish-topic-prefix.
Also, all these configs should be on one line, no CR/LF between but maybe that is only the code block markers acting up. Maybe you have done so.

I did implement this mqtt GW recently on an old RPi and I included --my-rf24-irq-pin=2 in the config but in reality I never connected that pin to the RPi. This caused some interesting problems I think.

[gammlerstyle]

@bgunnarb thank you for the hint.
Unfortunately I deleted the dash when I formatted the configuration to be read more easy.
I should have written this somewhere .
At my OrangePi I am writing the complete config in the same line without linefeed or something like that.

I tried both configurations (including the hardware wiring ) with and without interrupt pin on both sides, Gateway and Node. There was no big difference in the logging. The only difference was in the RF24: Messages which showed the constant polling for new messages.

[gammlerstyle]

Hi,
It seems like I got one step further...
I realized, that I had used pin 0 and 1 of the Arduino Nano (Tx1/Rx0 pins) as outputs.
As I found in the MyConfig.h, that I can use them as outputs, but do not have the possibility to debug at the same time, I deleted the parts of the sketch where I used these outputs as they where only for status LEDs.

Now I have the following debug output on the side of the node:

 __  __       ____
|  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
|_|  |_|\__, |____/ \___|_| |_|___/\___/|_|  |___/
        |___/                      2.3.1

16 MCO:BGN:INIT REPEATER,CP=RNNRA-Q-,REL=255,VER=2.3.1
26 TSM:INIT
27 TSF:WUR:MS=100
34 TSM:INIT:TSP OK
36 TSM:INIT:STATID=2
38 TSF:SID:OK,ID=2
39 TSM:FPAR
40 TSM:FPAR:STATP=0
43 TSM:ID
44 TSM:ID:OK
45 TSM:UPL
81 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=NACK:1
129 MCO:BGN:STP
Setup started
mySetup started
2089 TSM:UPL
3850 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=1,st=NACK:1
5858 TSM:UPL
7618 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=2,st=NACK:1
9626 TSM:UPL
9627 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=3,st=OK:1
11634 !TSM:UPL:FAIL
11635 TSM:FPAR
11637 TSM:FPAR:STATP=0
11639 TSM:ID
11640 TSM:ID:OK
11642 TSM:UPL
11644 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
13652 TSM:UPL
13654 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
15662 TSM:UPL

The Ping Messages and the Messages, that say, that the Uplink check failed are continous displayed.

My next question is: Due to the parser it says, that the status of the Ping message is OK. Doesn't this mean, that the message was received from the Gateway?

Then why does the next debug message say, that the ping was not OK?

Is my conlusion right, that this means, that the connection between the Node and the Gateway is established (between the two NRF24L01+ Modules) but the Gateway itself (OrangePi) does not answer to the ping?

The Logging output of the Gateway is as follows:

May 04 16:42:41 INFO  Starting gateway...
May 04 16:42:41 INFO  Protocol version - 2.3.1
May 04 16:42:41 DEBUG MCO:BGN:INIT GW,CP=RNNGL---,REL=255,VER=2.3.1
May 04 16:42:41 DEBUG TSF:LRT:OK
May 04 16:42:41 DEBUG TSM:INIT
May 04 16:42:41 DEBUG TSF:WUR:MS=0
May 04 16:42:41 DEBUG TSM:INIT:TSP OK
May 04 16:42:41 DEBUG TSM:INIT:GW MODE
May 04 16:42:41 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
May 04 16:42:41 DEBUG MCO:REG:NOT NEEDED
May 04 16:42:41 DEBUG MCO:BGN:STP
May 04 16:42:41 DEBUG MCO:BGN:INIT OK,TSP=1
May 04 16:42:41 DEBUG GWT:RMQ:MQTT RECONNECT
May 04 16:42:41 DEBUG connected to 192.168.178.99
May 04 16:42:41 DEBUG GWT:RMQ:MQTT CONNECTED
May 04 16:42:41 DEBUG GWT:TPS:TOPIC=mysensors-out/0/255/0/0/18,MSG SENT
May 04 16:42:41 DEBUG TSM:READY:NWD REQ
May 04 16:42:41 DEBUG TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
May 04 16:42:41 DEBUG GWT:IMQ:TOPIC=mysensors-in/2/255/3/0/6, MSG RECEIVED
May 04 16:42:41 DEBUG !TSF:MSG:SEND,0-0-2-2,s=255,c=3,t=6,pt=0,l=1,sg=0,ft=0,st=NACK:M

I tested the Gateway with and without Interrupt mode for incoming messages, but there is no difference in the logging.
Is there somewhere a file where I can look up the complete configuration of the gateway on OrangePi?
I already looked in the MyConfig.h but it does not seem to be the file where the config is done for an linux Gateway.

[gammlerstyle]

Hello everyone,

As there was no response to my last update, I tried to figure out what is wrong by myself.
Today I built another MQTT Gateway using an Arduino Mega2560. The interesting thing is, that the communication between the node and the Arduino-Gateway works. There I am receiving the messages of the node and the Arduino-Gatway is answering them.

To me this means, that I have to search for the problem at the OrangePi-Gateway. I disconnected the Arduino-Gateway and started digging into the source of the OrangePi-Gateway again.
While I was searching why there is no communication, I had a short success as the gateway received 2 pings of the node. After that there was no communication. The bad thing about this is, that I have no idea why the gateway received these two pings. The other thing is, that the response to the received ping messages were not send successfully.

I thougth that maybe there is a power issue on the OrangePi-Gateway. When I am measuring the voltage with my multimeter (Fluke 179) directly at the radio, I do have a stable woltage of 3.28V.
I think this is ok, isn't it?
Unfortunately I don't have an oszilloscope to see if there are some peaks/ripples.

Is there anyone out there who has an working MQTT-Gateway that is running on an OrangePi PC2 or similar, who would be able to share his config with me?

[gammlerstyle]

Hello again,

I think I finally found the problem on my OrangePi-Gateway.
When I compared the logfiles of my Arduino-MQTT-Gateway and the OrangePi-MQTT-Gateway I discovered the following:

The initialisation of the REG0 of the RF24 module is different.
See the following Logs:

Arduino-MQTT-Gateway (working):

MCO:BGN:INIT GW,CP=RNNGA---,REL=255,VER=2.3.1
		  
TSM:INIT
TSF:WUR:MS=100
RF24:INIT
RF24:INIT:PIN,CE=8,CS=9
RF24:SBY
RF24:WBR:REG=0,VAL=14
RF24:WBR:REG=3,VAL=3
RF24:WBR:REG=4,VAL=95
RF24:WBR:REG=5,VAL=79
RF24:WBR:REG=6,VAL=37
RF24:WBR:REG=29,VAL=4
RF24:RBR:REG=29,VAL=4
RF24:RBR:REG=6,VAL=37
RF24:RBR:REG=5,VAL=79
RF24:WBR:REG=2,VAL=2
RF24:WBR:REG=1,VAL=0
RF24:WBR:REG=28,VAL=3
RF24:FRX
RF24:FTX
RF24:WBR:REG=7,VAL=112
TSM:INIT:TSP OK
TSM:INIT:GW MODE
RF24:WBR:REG=2,VAL=3
RF24:WBR:REG=1,VAL=1
RF24:STL
RF24:WBR:REG=0,VAL=15
RF24:WBR:REG=10,VAL=0
TSM:READY:ID=0,PAR=0,DIS=0
MCO:REG:NOT NEEDED
RF24:RBR:REG=23,VAL=17
GWT:TPC:IP=192.168.178.100
MCO:BGN:STP
RF24:RBR:REG=6,VAL=37
RF24:RBR:REG=5,VAL=79
MCO:BGN:INIT OK,TSP=1

OrangePi-MQTT-Gateway (not working):

MCO:BGN:INIT GW,CP=RNNGL-Q-,REL=255,VER=2.3.1
TSF:LRT:OK
TSM:INIT
TSF:WUR:MS=0
RF24:INIT
RF24:INIT:PIN,CE=21,CS=13
RF24:SBY
RF24:WBR:REG=0,VAL=62
RF24:WBR:REG=3,VAL=3
RF24:WBR:REG=4,VAL=95
RF24:WBR:REG=5,VAL=79
RF24:WBR:REG=6,VAL=37
RF24:WBR:REG=29,VAL=4
RF24:RBR:REG=29,VAL=4
RF24:RBR:REG=6,VAL=37
RF24:RBR:REG=5,VAL=79
RF24:WBR:REG=2,VAL=2
RF24:WBR:REG=1,VAL=0
RF24:WBR:REG=28,VAL=3
RF24:FRX
RF24:FTX
RF24:WBR:REG=7,VAL=112
TSM:INIT:TSP OK
TSM:INIT:GW MODE
RF24:WBR:REG=2,VAL=3
RF24:WBR:REG=1,VAL=1
RF24:STL
RF24:WBR:REG=0,VAL=63
RF24:WBR:REG=10,VAL=0
TSM:READY:ID=0,PAR=0,DIS=0
MCO:REG:NOT NEEDED		  
MCO:BGN:STP
RF24:RBR:REG=6,VAL=37
RF24:RBR:REG=5,VAL=79
MCO:BGN:INIT OK,TSP=1

After a look in the Datasheet of the NRf24L01+ module I realized, that this config means, that on the orangepi the interrupt-feature is deactivated at the radio -> writing an "1" to bit 5 and 6 of register 0.

As I have configured the OrangePi-Gateway with interrupt, there is something wrong/missing?!
Do I have to activate the interrupt feature with an additional config to --my-rf24-irq-pin=2?

My config:

./configure --spi-driver=SPIDEV --my-gateway=mqtt --my-mqtt-user=*user* --my-mqtt-password=*password* --my-controller-ip-address=192.168.178.99 --my-port=1883 --my-mqtt-client-id=MySensors-SmartHome1 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-transport=rf24 --my-rf24-ce-pin=21 --my-rf24-cs-pin=13 --my-rf24-irq-pin=2 --my-signing=password --spi-spidev-device=/dev/spidev1.0 --my-rf24-channel=79 --my-rf24-pa-level=RF24_PA_HIGH --extra-cxxflags="-DMY_RF24_DATARATE=\(RF24_250KBPS\) -DMY_RF24_BASE_RADIO_ID=\(0x00,0xFC,0xE1,0xA8,0xA8\) -DMY_DEBUG_VERBOSE_RF24" --my-debug=enable 

[gammlerstyle]

Hi,

for everyone who reads all of this, forget about the last few posts.
I don't know why it works even when the Interrups are masked out on the radio, but it works now.

The error I had occured because of the config of the OrangePi-Gateway.
I removed:

--extra-cxxflags="-DMY_RF24_DATARATE=\(RF24_250KBPS\) -DMY_RF24_BASE_RADIO_ID=\(0x00,0xFC,0xE1,0xA8,0xA8\) -DMY_DEBUG_VERBOSE_RF24"

and wrote:

--extra-cxxflags="-DMY_RF24_DATARATE=\(RF24_250KBPS\) -DMY_DEBUG_VERBOSE_RF24"

Now I think I have an working OrangePi-Gateway without signing but with interrupt enabled.
If there are new problems I will come back here.
The next step for me is to activate signing again and bring the node into homeassistant.