@electrik Going through the documentation of the Orangepi, I found out that the config should be

--my-rfm69-irq-pin=71 --my-rfm69-cs-pin=233

but still no dice. I also get an error:

Mar 28 14:11:14 DEBUG MCO:BGN:INIT GW,CP=RPNGL---,FQ=NA,REL=0,VER=2.4.0-alpha
Mar 28 14:11:14 DEBUG TSF:LRT:OK
Mar 28 14:11:14 DEBUG TSM:INIT
Mar 28 14:11:14 DEBUG TSF:WUR:MS=0
Mar 28 14:11:14 DEBUG TSM:INIT:TSP OK
Mar 28 14:11:14 DEBUG TSM:INIT:GW MODE
Mar 28 14:11:14 ERROR Interrupt handler error: Bad file descriptor
Mar 28 14:11:14 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Mar 28 14:11:14 DEBUG MCO:REG:NOT NEEDED
Mar 28 14:11:14 DEBUG Listening for connections on ▒]o:5003
Mar 28 14:11:14 DEBUG MCO:BGN:STP
Mar 28 14:11:14 DEBUG MCO:BGN:INIT OK,TSP=1
Mar 28 14:11:14 DEBUG TSM:READY:NWD REQ
Mar 28 14:11:16 DEBUG ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:

The IRQ pin is connected alright, the RFM69 module works perfectly on a RaspberryPi or an OrangePi Zero.
It just refuses to receive when used on the OrangePi Zero 2 Something with pin assignements or SPI...
It is a a new SOC, so maybe I should wait for someone with more expertise than me to work it out...

Did anyone manage to make it work on an Orangepi Zero 2?
It compiles (after some tweaks) on armbian, it starts OK, trasport seems OK, it can transmit, but not receive.
Out of the box, it comes with

ls -l /dev/spidev*
/dev/spidev0.0
/dev/spidev1.1

My config:

./configure --spi-spidev-device=/dev/spidev1.1 --my-transport=rfm69 --my-rfm69-irq-pin=2 --my-rfm69-cs-pin=13 --my-rfm69-frequency=915 --my-is-rfm69hw --my-gateway=ethernet --my-port=5003

The output is

Mar 23 18:17:18 INFO  Starting gateway...
Mar 23 18:17:18 INFO  Protocol version - 2.3.2
Mar 23 18:17:18 DEBUG MCO:BGN:INIT GW,CP=RPNGL---,FQ=NA,REL=255,VER=2.3.2
Mar 23 18:17:18 DEBUG TSF:LRT:OK
Mar 23 18:17:18 DEBUG TSM:INIT
Mar 23 18:17:18 DEBUG TSF:WUR:MS=0
Mar 23 18:17:18 DEBUG TSM:INIT:TSP OK
Mar 23 18:17:18 DEBUG TSM:INIT:GW MODE
Mar 23 18:17:18 DEBUG TSM:READY:ID=0,PAR=0,DIS=0
Mar 23 18:17:18 DEBUG MCO:REG:NOT NEEDED
Mar 23 18:17:18 DEBUG Listening for connections on P▒E:5003
Mar 23 18:17:18 DEBUG MCO:BGN:STP
Mar 23 18:17:18 DEBUG MCO:BGN:INIT OK,TSP=1
Mar 23 18:17:18 DEBUG TSM:READY:NWD REQ
Mar 23 18:17:21 DEBUG ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:

I tried also with the development branch (fewer tweaks) but with the same results.
Any help would be appreciated

It's a known bug (or feature) of the Rspberry Gateway + RFM69. RSSI values are wrong, so you cannot use ATC
What I do, is i use

#define MY_RFM69_ATC_MODE_DISABLED
#define MY_RFM69_TX_POWER_DBM 0

and set the TX_POWER_DBM to the lowest value I can, by trial & error...

Have you guys considered using a US-100 ultrasonic sensor instead?
It can be used in the usual "ping" method, or in serial mode, in which case you can also get a reading from the built-in temperature sensor, and the distance measurement is automatically temperature compensated.
And it also works reliably at 3V.
I was using it for a year without problems in an diesel tank, and made the mistake to replace it with a TOF sensor. Now I'm back to the old reliable US-100.

It's even simpler than that. Just add a line as the one below:

#define MY_SIGNING_SIMPLE_PASSWD "mypassword"

@gohan I meant multiple gateways on the same raspberry.
Right now, I have an NRF24L01 gateway, Domoticz, pi-hole, and a VPN server running, with 2 more gateways connected, one local and one remote RFM69 on ESP8266.
It would be nice if I could combine the two local gateways, the RFM and the NRF on the same Raspberry's GPIO...

@gohan Nice. I was thinking to do that same at some time, but I wasn't sure if the Raspberry could handle the load, since I also run domoticz on it, along with pi-hole.
How many devices do you have on each gateway?

@rolo6442u From what the node itself reports from transportGetSignalReport(SR_TX_POWER_PERCENT). It starts from say 50%, and after a coule of transmissions it goes up to 100%, when the nodes are 1m apart. When using a stand alone ESP8266 gateway, it drops to 0%.
I'll have the nodes ready in a couple of hours, after I come home from work...

@rolo6442u I built an Raspberry gateway using an RFM69 radio, to replace one built around a NodeMCU.
All nodes are transmit only, and using the latest stable API.
I noticed that all sensors were using max TX power after the first couple of transmissions, although they were respecting the ATC setting before, and were using minimum power most of the time.
Now I am concerned about battery life, so I switched back to the NodeMCU gateway, waiting for a fix.
I'll put together a temporary net, with a RPi0 gateway and a single node later, to show some real data, if you need any more information.

Has the issue with RFM automatic transmission control been addressed?

Any news from the developers on this issue?

@electrik I didn't modify the whole network, just two nodes as a receiver and transmitter. I'm waiting for the SDR-RTL first...

@electrik They work fine if I just change the frequency definition from RFM69_868MHZ to RFM69_915MHZ, but I don't know if the frequency actually changes. Currently I'm waiting for an RTL-SDR dongle to arrive, so I can make some tests to be sure...

Anyone here with experience on using RFM69HW radios marked or 868MHz tune via software to operate on 915MHz?
I ordered several of them to replace some long-distance NRF24L01 sensors that I had problems with, and it seems they interfere with my wireless alarm system, which constantly complains about possible interference and starts blaring at odd times...
I know they work, but I don't know if it is advisable to operate at a different frequency, either for transmitter life expentacy, or spurious harmonics and what not.
Thanks in advance.

@mfalkvidd sorry, I was talking about the US-100 distance sensor. Jumped the gun here.

@dbemowsk I have one sensor (oil tank level) running on an Arduino pro mini, with LEDs & regulator removed on 2 AA batteries for 2 months now.
I use pins 3 & 4 of for power and ground, and the hardware serial to communicate with the sensors. I take a reading every hour. No significant voltage drop so far, the battery level has only dropped by 3%.
I do get occasional spikes though, so when I get to it, I'll modify the sketch to take 3 readings and send the median.

@user2684 Actually, you are right. Thank you.
But shouldn't the compiler throw an error?

Now to the hard part: How to send the actual command from Domoticz, for example to change the sleep duration...

I just started using NodeManager, mainly for the ability to send settings to the node.
I started with a plain analog (Voltage) sensor, and it works just fine. But I cannot make a DS18B20 sensor to send any temperature data. It registers on the gateway, and that's it.
I have enabled the DS18B20 module in the config.h.
This is the code in the sketch:

  /*
   * Register below your sensors
  */
  nodeManager.setSleepSeconds(10);
  nodeManager.setReportIntervalSeconds(10);
  int temp = nodeManager.registerSensor(SENSOR_DS18B20);
   /*
   * Register above your sensors
  */

Am I missing something?

@mfalkvidd Haven't tried that.
I'll give it a chance just in case.

OK, problem solved.
First of all, I stopped using SoftSerial, and I am now using the regular serial port.
I can't debug the node any more, but it is working.
And the drain dropped to 1.9 mA.
This is the US100 idle current, so that was also a problem.
So I chose to power the sensor from pins 3 & 4, as VCC and GND, since just using pin 3 and GND kept the drain to 1.9mA
I turn pin 3 to output high and pin4 to output low, wait 5 seconds to let the sensor stabilize, since it gave erratic readings with anything less, take the measurement, and turn pins 3 & 4 to inputs, so there is no drain.
Seems to work so far, after a whole day of taking readings every minute, I am down by 10mV. I intend to take readings every 2 hours in normal operation, so I figure the batteries will last for about a year.
I am writing this from my phone, so I cannot post the source if anyone is interested, but let me know...