Something's cooking in the MySensors labs...

[bwn]

Yes, you're right.
For two separate gateways that's a valid statement, but I need to know how it (will) work for this multigateway feature when I'll connect rs485 and nrf to one physical GW.

[Anticimex]

@bwn I do not think it will if the gateway makes the two transports share the network. As things like encryption is global to each network.
Signing might work if you do it only for specific node id:s and the node id:s are distributed over both networks.

[alowhum]

Wait, wait.. what is that USB stick with the dual antennas? Is that a dedicated MySensors gateway device?

// Ah, it's project Janus. AWESOME!

[lood29]

I'm trying to use the MY_RFM95_RFM69_COMPATIBILITY options but it does not pass the RFM95_sanityCheck.

Code compile without warning, and gateway is working fine with simple RFM95 driver.
Using esp8266 and arduino 1.8.13.

Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;67 TSF:LRT:OK
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 3;0;9;69 TSM:INIT
0;255;3;0;9;71
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;69 TSM:INIT
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) :  TSF:WUR:MS=0
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;71 TSF:WUR:MS=0
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;74 RFM95:INIT:PIN,CS
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : =15,IQP=4,IQN=4
0;255;3;0;9;78 R
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;74 RFM95:INIT:PIN,CS=15,IQP=4,IQN=4
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : FM95:INIT:RFM69
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;78 RFM95:INIT:RFM69
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;86 RFM95:SRM:MODE=4
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;86 RFM95:SRM:MODE=4
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;220 RFM95:INIT:FREQ=868000000
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;220 RFM95:INIT:FREQ=868000000
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;254 RFM95:PTX:LEVEL=20
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;254 RFM95:PTX:LEVEL=20
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;273 !RFM95:INIT:SANC
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : HK FAIL
0;255;3;0;9;276 !TSM:INIT
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;273 !RFM95:INIT:SANCHK FAIL
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : :TSP FAIL
0;255;3;0;9;279 TSM:FAI
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;276 !TSM:INIT:TSP FAIL
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : L:CNT=1
0;255;3;0;9;282 TSM:FAIL:
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;279 TSM:FAIL:CNT=1
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : DIS
0;255;3;0;9;285 TSF:TDI:TSL
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;282 TSM:FAIL:DIS
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;285 TSF:TDI:TSL
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;287 RFM95:RSL
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;287 RFM95:RSL
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;295 RFM95:SRM:MODE=3
Tue Aug 17 2020 10:48:50 GMT+0100 (CET) : 0;255;3;0;9;295 RFM95:SRM:MODE=3
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10299 TSM:FAIL:RE-IN
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : IT
0;255;3;0;9;10302 TSM:INIT
0;
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10299 TSM:FAIL:RE-INIT
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10302 TSM:INIT
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 255;3;0;9;10304 RFM95:INIT:PIN,C
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : S=15,IQP=4,IQN=4
0;255;3;0;9;103
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10304 RFM95:INIT:PIN,CS=15,IQP=4,IQN=4
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 09 RFM95:INIT:RFM69
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10309 RFM95:INIT:RFM69
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10317 RFM95:SRM:MODE=4
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10317 RFM95:SRM:MODE=4
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10451 RFM95:INIT:FREQ=868000000
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10451 RFM95:INIT:FREQ=868000000
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10485 RFM95:PTX:LEVEL=20
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10485 RFM95:PTX:LEVEL=20
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10504 !RFM95:INIT:SA
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : NCHK FAIL
0;255;3;0;9;10507 !TSM
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10504 !RFM95:INIT:SANCHK FAIL
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : :INIT:TSP FAIL
0;255;3;0;9;10511
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10507 !TSM:INIT:TSP FAIL
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) :  TSM:FAIL:CNT=2
0;255;3;0;9;10514
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10511 TSM:FAIL:CNT=2
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) :  TSM:FAIL:DIS
0;255;3;0;9;10516 T
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10514 TSM:FAIL:DIS
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : SF:TDI:TSL
0;255;3;0;9;10519 RFM95:RSL
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10516 TSF:TDI:TSL
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10519 RFM95:RSL
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10527 RFM95:SRM:MODE=3
Tue Aug 17 2020 10:49:00 GMT+0100 (CET) : 0;255;3;0;9;10527 RFM95:SRM:MODE=3

[lood29]

Well, i don't know if it is a timing issue or a hardware issue, but increasing the RFM95_POWERUP_DELAY_MS from 10 to 100ms solved the issue.
Now testing range improvement over rfm69h, will report back.
@tekka , Great work !

[nagelc]

Thanks @tekka
This is awesome and came along at the perfect time. I have 4 networks because of experimenting over the years and have been meaning to clean up the rats-nest of wires that is my current set of serial gateways. Enter Multi-Transport.
I made a gateway with NRF24 and RFM95 (915Mhz) running off an STM32F411 black pill. Worked right off the bat.
Now I just need to duplicate for RFM69 and RFM95(433Mhz).

[Yveaux]

@nagelc sends like you socketed your rfm69. Could you post a closeup picture of it?

[nagelc]

@Yveaux
Another experiment, using 2mm machined pins and sockets. Since the RFM69HCW and the RFM95's share the same pinout, I could switch radios easily for testing.

[Giovanni Chiva]

Hi guys! I'm trying to enable RS485 and RF24 transports but I'm getting the following error :

/libraries/MySensors/2.3.2/MySensors.h:290:2: error: #error Only one forward link driver can be activated

I saw the MY_RFM69_NEW_DRIVER example and tried to apply the same logic :

#define MY_RS485_NEW_DRIVER

This made the error go away but the RS485 transport layer is not initialized.
I've tried enabling only the RS485 layer and it works.

Any idea on how to enable multitransport with RF24 and RS485 ?

[BearWithBeard]

@Giovanni-Chiva You need the development branch (2.4.0-alpha) for multitransport. 2.3.2, which you are using, doesn't support that. Download here: https://github.com/mysensors/MySensors/tree/development

[Giovanni Chiva]

@BearWithBeard thanks for the reply!
Unfortunately I'm getting the same error message :

/libraries/MySensors-development/MySensors.h:295:2: error: #error Only one forward link driver can be activated

Am I missing something?

Here is my gateway code :

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable RS485 transport layer
#define MY_RS485

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

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

#define MY_RF24_CS_PIN 10     // Used by the MySensors library.
#define MY_RF24_CE_PIN 7    // Used by the MySensors library.

#define MY_RADIO_RF24	// Define radio module
#define MY_RF24
#define MY_RF24_PA_LEVEL RF24_PA_MAX // Set radio power to max
#define MY_RF24_DATARATE RF24_1MBPS // Limit transmission to 1MBS

// Enable serial gateway
#define MY_GATEWAY_SERIAL

#include <MySensors.h>

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

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

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

[Giovanni Chiva]

@BearWithBeard
Apparently the main development branch does not include multitransport support. I've eventually found @tekka 's branch and was able to download it from here https://github.com/mysensors/MySensors/tree/09434a4b9fb668fbaa2d47803b5541f2d7b05d29

The error message is gone now, however only RF24 transport layer is working. If I comment the RF24 transport, then RS485 starts working.

[BearWithBeard]

@Giovanni-Chiva I was certain they merged the multitransport feature into the 2.4 dev branch early on. I was wrong about that. I'm sorry. At least you were able to find the right branch from there on.

Not sure though why you are having issues combining NRF24 and RS485. Unfortunately, I don't own any RS485 modules to make my own tests. Maybe try using a different pin for RS485 DE?

Has this combination been tested by anyone else before?

[Giovanni Chiva]

@BearWithBeard No need to say sorry! You did point me to the right direction, I was clueless :)

I've tried a different RS485 DE pin, but still no luck.

#define MY_RS485_DE_PIN 4

I've seen people mentioning RS485 transport here in the comments but I'm not sure if anyone actually did test this combination (RF24 & RS485).

[Nick Willis]

I've been using this PR on my gateway for several months now and it's working great. I'm using a Sensebender gateway with both RFM and NRF radios with sensor nodes on both networks. I can swap radio types on a node, change the radio config in the sketch (keeping the node ID) and it flawlessly changes and continues to work in Home Assistant.
Only thing that is behaving oddly are RFM radio nodes. When they first boot they can pair to the gateway no problem but then suffer NACKs constantly for 3 or 4 mins after which it works no problem for weeks and months... I can see the NACKed messages arriving at the gateway but the node doesn't recieve the ACK from the gateway.
I also note that all other RFM nodes start NACKing at the same time (I have a NACK monitor sensor on all my nodes) which again clears up once the new node has been on a few minutes. It's the same whenever any RFM node is rebooted.
I'm not using this PR version on my nodes - only the gateway - as some things would not compile.
Hope this feedback is of use!

[pikim]

@BearWithBeard
Are you still running the multi version on an ATmega328P? What's your long term experience with it?

[BearWithBeard]

@pikim No, I am not. My original plan was to deploy more and more RFM-based nodes as they seemed superior over NRF24 in general, but I realized that my NRF24 network was rock solid and reliable, so there was no need for the added complexity and cost to support and integrate another transport. Plans are made to change them. ;)

That being said, I used the multiRF gateway for months without issues. The gateway operated as stable as the single transport 2.3.2 gateway. No issues at all, except with the automatic TX power adjustment (ATC) of the RFM transceivers, due to what I believe might be a timing issue within the library. I described the issue in this thread. Basically, the RFM nodes were not able to reduce their transmit power, unnecessarily blasting the environment and wasting battery power. Introducing small delays in various places was all it needed to work around this issue successfully, seemingly without adverse side effects.

This issue has not been properly remedied since the introduction of the multiRF gateway though. For all I know, it is still tekka's personal fork of the MySensors 2.4 branch and has not been updated, so any new fixes and features for version 2.4 since March 2020 will not be available to this fork, unless you manually implement them.

So I guess it is up to you if you prefer to use the multiRF gateway without all the mainline 2.4 changes, or the up-to-date 2.4 branch without the multiRF feature. It should not make much of a difference currently, according the the commits since the multiRF fork, unless you want to use PJON transport or deploy NRF5-based nodes.

I really wish that the development on MySensors revives, as it is feeling kinda stale at the moment. It would be a shame if this project got silently abandoned. I would be glad to help out wherever I can.