New status update: IT WORKS!
I have to implement sleep and ATC, then I will upload it to GitHub for testing, if anyone is iterested...

Hello Henrik,

In your scenario, I would not use a RPi. Maybe a ESP32 with BLE is already enough as a controler, if you don't need to log too much data or add an SD card. You could even combine two NRF52 (see below) and use one for BLE and the other for MySensors.
For your sensoirs, you could use a Keywish RF Nano or an NRF52 module like (this one)[https://www.aliexpress.com/item/32974237147.html] which combines a NRF24L01 and an ARM cortex M cpu and have very low sleep current.
Maybe it's best for you to use passive nodes when not using the RPi, so you don't have to care about address management and so on on the gateway.

Regards, Edi

@NeverDie Did you check out the assembly instructions? There they use a fuse with a rather high current in this place
The explanation why it is polarized is because in fact, it used to be a diode in older revisions, check out Step 7 here.

Hi everyone,
After the good comments by @Yveaux and @mfalkvidd in this thread i started over again. After some sleepless nights, a SSD-crash destroying about 12h of coding and tons of soft drinks, I just uploadated my github repository with the SX126x drivers and the ASR650x hal.
What is different to the things I mentioned in the thread above:

• Everything is rebased to the developement branch as suggested by @mfalkvidd
• CubeCell hal byebye, welcome SX126x hal. As inspired by @Yveaux, I abandoned the CubeCell drivers in favor of SX126x drivers which should work on other SX126x based modules as well. Feel free to test. The code should work for the SX1261 as well as the SX1262, but as I only have CubeCell boards, only SX1262 is tested.
• ATM, I really dont feel like writing down all the defines, but everything is documented in MyConfig.hand in ```SX126x.h`` If you got questions. please ask.

During developement, I found another nasty bug in ASR650x Arduino regarding IRQ handling. You should take the latest version from ASR650x github if you encounter strange freezes on a CellCube board.

Have fun, I gotta get some sleep

Oh sorry, my fault. It was a bit late. We have a return true in there, where we exit the loop as soon as we got an ack. You are right!

@NeverDie and for reverse polarity protection, you could just use a FET, a resistor and a Zener (only necessary if reversed voltage is breaking the FET, which is cheaper if you have some amps and has loooots of less power dissipation:

I use this on all my PCBs with removable batterys. Luxury upgrade: a reverse voltage indicator:

Add a Zener parallel to the LED if you have a wide expectet input voltage range.

@Eme said in MySensors Raspberry Pi Gateway + Domotics Controller:

TSF:CKU:OK,FCTRL

Uplink OK, flood control prevents pinging GW in too short intervals

Yes, exactly.

Well, I think we would have to write the HAL functions (which is not too hard as I imagine) as a first step. I hope we could use the RFM95 drivers in a first step, but the Framework compiles with a LoRa and a LoRaWAN app. If we have luck, we have no collisions.
In a further step, I would test if it is worth while to implement a new transport and use the native LoRa-stack.

Well, I think I fork the github-repository and start to play around...

@NeverDie said in CNC PCB milling:

capacitors are to be used for that instead

Wow, thanks. I learned something today!

@Eme did'nt I write English
So, if you look at the source:

bool transportCheckUplink(const bool force)
{
        if (!force && (hwMillis() - _transportSM.lastUplinkCheck) < MY_TRANSPORT_CHKUPL_INTERVAL_MS) {
                TRANSPORT_DEBUG(PSTR("TSF:CKU:OK,FCTRL\n"));    // flood control
                return true;
        }

The transport prevented an uplink check, since the last was done less then MY_TRANSPORT_CHKUPL_INTERVAL_MS milliseconds ago (defaults to 10 seconds)
.

@Eme i usually solder a tantalum directly to the pins on the top side of the board

@Eme said in MySensors Raspberry Pi Gateway + Domotics Controller:

Pi Model A with wifi

Sure? AFAIK A had no WiFi. Or do you use a USB dongle?

@Eme did'nt I write English
So, if you look at the source:

bool transportCheckUplink(const bool force)
{
        if (!force && (hwMillis() - _transportSM.lastUplinkCheck) < MY_TRANSPORT_CHKUPL_INTERVAL_MS) {
                TRANSPORT_DEBUG(PSTR("TSF:CKU:OK,FCTRL\n"));    // flood control
                return true;
        }

The transport prevented an uplink check, since the last was done less then MY_TRANSPORT_CHKUPL_INTERVAL_MS milliseconds ago (defaults to 10 seconds)
.

@Eme said in MySensors Raspberry Pi Gateway + Domotics Controller:

TSF:CKU:OK,FCTRL

Uplink OK, flood control prevents pinging GW in too short intervals

So the sensors do not receive Messages from the gateway, but not from other sensors. Is the nrf24 on the gateway a module with PA? Then maybe test different PA settings, this helped once on a setup here.
BTW: Your picture is not visible: access denied

Hello @Eme,

Sending only works for an unacknowledge msg. Now the question is did the gateway not send the message or did the sensor not receive the message thus not sending an ACK. Yould you ckeck on the sensor side what the debug says?

@Oumuamua said in High battery usage (Pro-Mini / RFM69 / Si7021):

Seems the step-up had a problem. Changed to a new one does not use that much current.

Oh... Sorry. I should read all the new messages befor posting again....

@Oumuamua said in High battery usage (Pro-Mini / RFM69 / Si7021):

the step-up is actually using a crazy 11mA (not uA) when idle. Same current as when not connected with the board.

That is not normal! Do you have a second step up? It seems to be... not normal

Can you post your sketch?

@NeverDie said in CNC PCB milling:

capacitors are to be used for that instead

Wow, thanks. I learned something today!