Posts made by Yveaux

@frapell did you replace the power supply of the gateway?

@Dave-Myers iirc nodes are supposed to perform the conversion themselves. I know at least the gateway does not take care of this.

@Newzwaver said in Ethernet Gateway Using PCBWAY board Fifisoft57:

!TSM:INIT:TSP FAIL

This indicates there's a communication issue with the radio module. Start your debugging there.

@Njwyborn sorry, I don't know. If the stack is called recursively, something is seriously wrong and behavior is undefined I guess.

@Njwyborn judging from the logs, i would suspect that you're at least suffering from this issue https://github.com/mysensors/MySensors/issues/1458, which unfortunately is still open.

@Serj-Sam there is a pull request included in that pr. Once this is merged it will be available in development, later in the next release.
If you just downgraded the core, that is persistent until you upgrade the core to 3.x again.

@Serj-Sam you could very well have run into the incompatibility of mysensors with the latest esp arduino core 3.x (see eg https://github.com/mysensors/MySensors/issues/1496)
Easiest solution is to downgrade the esp arduino core to 2.x

@benhub some sellers indeed have EU warehouses, which are now the preferred ordering locations for EU citizens. I also don't know how to easily find them on eg aliexpress. I kind of run into them by accident...
Additional benefit is shorter shipping times, but products stocked are limited in general.

@anderBAKE said in WeMos D1 Mini Gateway + Relay:

#define RELAY_PIN 1

That should be

#define RELAY_PIN D1

When something doesn't work it's best to strip a sketch to the bare minimum and get that to work first, eg setup the pin, then switch the relay on and off from the main loop(), without including mysensors or anything else.

@anderBAKE are you sure the code to actually toggle the relay gets executed? You could add some debug statements or toggle the led instead.
Btw. I would prefer

if (message.getBool() == true)

Or even

if (message.getBool())

@Serj-Sam logs are available through serial port. You mention esp8266 and esp32; which one is it?

@ben999 said in Raspberry as a node (bis):

Does it stay local within the LAN (and gets directly to my gateway) or does it have to travel through internet up to openhab and down again to my gateway (remember, my bell has to ring) ?

You run an MQTT broker ('server') somewhere in your local network (or even on your pi) that takes care of distributing the data.
Not saying you need MQTT, only that it works marvellous for me.

So last question just to be sure : it is not common practice to use RPi as a node ? And there is no "sketch" ready made that can be tweaked ?

Not to my knowledge, but as all platforms supported by mysensors can be turned into nodes, this should also work for a pi.

@ben999 said in Raspberry as a node (bis):

Raspberry will be connected to LAN to transfer picture to NAS, probaly via wifi (or wired if i decide to go down the PoE road...)

Ah! Thought you were slightly paranoid

But i also want the RPi to be connected to openHab in order to send notification of "front gate button pushed" via MySensors so i can get the doorbell to ring AND a broadcast message from openHab.

I personally would go the MQTT way for this and bypass MySensors completely. Probably there are many more ways supported by OpenHab to trigger something on a remote node or receive some data from it using a (wireless) ethernet connection.

@ben999 said in Raspberry as a node (bis):

Not posting doesn't that mean i've lost interest

It's been a while indeed. Welcome back

can a Raspberry Pi be hooked to a NRF module and behave like a node

I would think so, but to send an image to your NAS the connection is way too slow.
Just use WiFi/ethernet to connect your pi to your LAN, and use that to transport images.

@Zwer2k my expectations seem correct. I created a bug report that also includes a rudimentary workaround.

https://github.com/mysensors/MySensors/issues/1496#issue-968399284

@Zwer2k mysensors replaces the arduino statup code, so you don't have to call setup and processing functions from your code.
Likely something changed in the esp arduino 3.x implementation that causes the mysensors code to no longer work.
If i can find some time I'll have a look.

@Zwer2k please don't crosspost!

@pw44 said in nRF24Doctor:

Is this undestanding correct?

Yes it is

@Njwyborn said in Is there a "standard" way to terminate a sleep time, after waking by an interrupt?:

Please note that I am still on V 2.2.0

You should have started there. I fixed some nasty race conditions in the sleep code, that iirc, were not included until 2.3.0.
Why don't you upgrade? These versions are on - air compatible anyway.

@Njwyborn said in Is there a "standard" way to terminate a sleep time, after waking by an interrupt?:

so if I just define the pin as INPUT_PULLUP, and not attach a interrupt, when I call sleep, passing the interrupt handler, it WILL call the handler?

You shall not pass the interrupt handler, but the interrupt number instead. Each pin that supports interrupts can trigger a certain interrupt. The interrupt number for a pin is returned when calling digitalPinToInterrupt(). You can read more on the topic here.
During the execution of the sleep() function, a new interrupt handler will be installed that is used to handle the wake-from-interrupt. It is detached again, before returning from sleep().

About the most minimalist implementation is the following, which compiles without errors:

#include <Arduino.h>

#define MY_RADIO_RF24
#include <MySensors.h>

#define MY_PIN         (3)
#define CHILD_ID       (0)
#define SLEEP_TIME_MS  (60000)
#define SKETCH_NAME    F("Test")
#define SKETCH_VERSION F("1.0")

void presentation()
{
    sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);
    present(CHILD_ID, S_RAIN, F("Rain"));
}

void setup()
{
    pinMode(CHILD_ID, INPUT_PULLUP);
}

void loop()
{
    auto result = sleep(digitalPinToInterrupt(MY_PIN), RISING, SLEEP_TIME_MS);
    Serial.println(result);
}

How is it possible to utilise an interrupt on a otherwise sleeping node, WHEN it is awake?

I did not relealize before that you wanted to install your own interrupt handler for the same pin when the node is awake.
To achieve this, you can just attach your own handler after returning from sleep(), something like:

// .. same code as above ..
void RainINT(void)
{
  // .. handle the interrupt ..
}

void loop()
{
    auto result = sleep(digitalPinToInterrupt(MY_PIN), RISING, SLEEP_TIME_MS);
    attachInterrupt(digitalPinToInterrupt(MY_PIN), RainINT, FALLING);
    Serial.println(result);
}

Just be aware that the call to sleep() will overwrite your installed interrupt handler, so you need to reinstall it after returning from sleep().

separately, what is wrong with my watchdog implementation?

MySensors on AVR uses the watchdog to wake a sleeping node after a certain amount of time.
To achieve this, it reprograms the watchdog just as it does with the interrupt handler.
In most cases you will be just fine if you reprogram the watchdog settings when returning from sleep(), just as when reattaching the interrupt handler.

However, as MySensors hides you from a lot of nastiness by taking over hardware specifics, you must understand its limitations.
That's why I do not suggest most users to follow your solution but instead, don't use the watchdog or try to share interrupts.

@Njwyborn Good to see you how have a somewhat working solution.
Just configuring the pin for input, and passing the corresponding interrupt (not the pin) to the sleep() fuction as in my example does work.
I have many sleeping sensors that wake from either timer or interrupt and they all work correctly.

Others, please don't use this as an example, as the manual watchdog and interrupt handling will likely interfere with the MySensors AVR implementation.

I can only help when the exact compiler error is known (not "the compiler complained (unsurprisingly I thought), as it is expecting a uint8_t"), and if you provide a minimal sketch that exhibits the compiler error.

The hardware could also be a cause of errors; bouncing switches and sleeping nodes don't play together nicely, unless signals are debounced.

@Njwyborn yes, the sleep() function which takes an interrupt will install an interrupt handler, enable interrupts for wakeup and then goes to sleep for the specified time, unless it wakes early from an interrupt.
Its use and some example code is documented here: https://www.mysensors.org/download/sensor_api_20#sleeping

If you're into low-level coding you can find the heart of the underlying library implementation for AVR here https://github.com/mysensors/MySensors/blob/b9d9cc339659f724aa94d4108fc5289a720d1bcd/hal/architecture/AVR/MyHwAVR.cpp#L175
It takes care of some tricky corner-cases involving interrupts and sleeping the CPU.

Note that you should call sleep() as

sleep(digitalPinToInterrupt(RainPin), FALLING, MYsleepTime);

so pass it an interrupt instead of the pin number

@Njwyborn post your full sketch please. You should not attach your own interrupt handler and let mysensors handle it instead.

@cvdenzen said in Millis and sleep:

Accuracy can be as good as one or two millis per sleep I guess

No it cannot. Look up the watchdog specs on the atmega datasheet.
When the atmega is sent to sleep for 8 seconds and is woken by an interrupt it does not know how long it actually slept. Could be 1ms, could be nearly 8 seconds.
This is also documented in the interface : https://github.com/mysensors/MySensors/blob/b9d9cc339659f724aa94d4108fc5289a720d1bcd/core/MySensorsCore.h#L393

If it is not woken by an interrupt, timing will be more precise, but possibly still a lot less accurate than the regular atmega timer as the watchdog uses an rc oscillator.

@cvdenzen I'm not saying it's impossible, I'm warning you that the result will be very inaccurate.
Everytime your node sleeps, it's millis counter would rely on the watchdog and each time an error will be introduced. Worst case this will be 8 seconds per sleep call, which adds up rapidly.
But, if that's acceptable to your use case, please go ahead!

@cvdenzen the atmegas will no longer increase their millis counter on sleep. The sleep time, or approximate time elapsed during sleep, is using the watchdog timer and can therefore be off as much as 8 seconds!
It depends on your application if this is acceptable or not.
If not, you have to revert to a different timing method (eg external timer) or use a different cpu.

@omarrxa sure, now you're using identical radios

@omarrxa mkr1010 supports wifi and Bluetooth, the nrf24l01 uses a proprietary protocol, which is incompatible unfortunately.
Simply said, they cannot talk together.

@alec44 is the wire conductive?

@Max-Kurilov said in Wake-up by interrupt doesn't work:

for how long is it safe to send node to a sleep mode while keeping data packets from losing.

You should not sleep a node that must be responsive to incoming messages.

@Max-Kurilov said in Wake-up by interrupt doesn't work:

What do you mean by saying "off"? It seems that there is a voltage when a node sleeps. So that the radio should be powered in my case.

I tried to keep it simple as I don't know your background, but by 'off' i mean powered, but in sleep mode. Receiver is switched off. This is the case for nrf24, but might slightly differ per radio.

It is a limitation of the radio, not of the mysensors library. Either sleep the node for minimum power usage, or keep it awake at higher power requirements.

If the radio can't change its IRQ pin state while powered on what is the purpose of this pin? Maybe this is a rhetorical question.

In case of nrf24 the irq can be used for buffering incoming messages on nodes with high load. Mainly used for gateways.
Furthermore, for future hardware compatibility it is suggested to connect the irq line. If you're short of pins, you can decide differently.

For other radios the irq line might be mandatory.

@Max-Kurilov said in Wake-up by interrupt doesn't work:

my device wakes up if I connect an interrupt pin with the ground. But it doesn't wake up when a gateway transmits data to binary switch.

True, in MySensors the radio will be 'off' when a node sleeps, so nothing will be received. Your node will only wake up by an interrupt (eg the interrupt pin in your setup) or after a certain amount of time has elapsed.

@NeverDie the difference between min/max is not much different here, approx. 11V over 24h, in Europe:

Although relatively it's only half of yours...

@hyla these meters produce a lot of serial data (at least for P1 protocol) which might be too much for mysensors if you just want to stream that data.
I'm using tasmota instead (wifi) and extract the data in node - red.

@NickL in not familiar with domoticz, but the log from the gateway shows no sensor presentations.
That could be the reason nothing shows up.
What happens if you restart a node? Does it communicate with the gateway?

@NickL ok, clear. I took the liberty to move this to the Domoticz sectio.

@NickL and your issue is.....?

@NeverDie and if it warns you, what do you do? Check all electrical wiring in your house?

@itjobhunter where's mysensors in all of this?

@jkandasa said in serial, Ethernet to MQTT:

They do not want to use WiFi.

Of course, but MySensors MQTT gateway runs just as fine when connected over cabled ethernet, as when connected over wifi

@jkandasa nice, but MySensors comes default with an MQTT gateway. Could you explain why you created this, what the advantages are?

@Njwyborn said in Sensebender. Still same problems with NEW board and radio:

big job to upgrade

Or stick with the old driver

@Njwyborn said in Sensebender. Still same problems with NEW board and radio:

The NEW rfm69 driver, is it wirelessly compatible with the OLD driver? i.e. can old talk to new?

No, the on - air payload is different. All nodes in a network must use the same rfm driver.

@zebmina did you attach an antenna to both the transmitter and the receiver?
Also, your radios are very close together, so the receiver might saturate (but that would be the next hurdle, first you need to receive something)

@bonamin thanks for reporting back!

@bonamin start with a few meters between the nodes and free sight (no walls). Quick test and could make a difference.

@bonamin the failure to send a message, as seen from the logs, is probably the reason that often the relay does not respond.
This unfortunately is also the hardest to solve, as it can have many causes.
E.g. The power supply to your nrf24 radios may be noisy. Try a different supply and add capacitors.
The radios may be of bad quality. Exchange the radios.
The radios might be too close or too far apart, or obstacles inbetween severely reduce range.
Etc.

@รอเร-อ you probably want to filter spikes in the sensor readings to prevent reacting on outliers.
I understand your sensor is located outside. Here is an example over 2 days from my pm sensor also located outside:

I would try a long, slow filter window to establish a baseline value, and a short, fast filter window to react on changes relatively quickly. Then when the slow filtered value differs more than x from the fast filtered value you need to stop the intake of fresh air.
Search for "exponential moving average" to implement such filters.

Btw. I only read a pm value once a minute or so. If filtering using a few values the response will be in the order of a few minutes at best.

@Callahan i own a few wemos d1 minis that also just fail to be recognized during download. Do you have another esp that you can check out, just to rule out the board itself?

@4994james or just use internal vcc measurement as described on the same page. That saves you the voltage divider.
I wrote a convenient library to measure vcc internally : https://github.com/Yveaux/Arduino_Vcc

@LiamW said in Best 3d printers:

found this article about top printers in 2021

Seems like a rather biased comparison if brands like prusa and creality are not even considered...

@nagelc or monitor gas flow. That would also detect gas flow when your stove isn't burning, which is an even bigger danger than leaving the fire on.

@electrik mysensors uses its own protocol, so won't be able to 'talk' to your device. You might be able to use a mysensors node as a bridge, but you would have to develop the code by yourself.
As you indicate, existing solutions like rflink are likely a lot easier to get running.

@4994james great to hear you solved it, and thanks for reporting back!

@4994james as you own the tools to monitor the i2c traffic, what is going on with the htu on the bus during initialization?

@Diazovitch69 mysensorsssssss.h?

@4994james How do you connect the board? Do you have the I2C pull-up resistors mounted?

@maddhin you need to pass a Wire instance in the call to begin(). Search the net for an example.

Edit: never mind; answered too quickly It doesn't return a bool indeed so you cannot use it in a while loop.

@Gilles-BILLARD I would like to think along to help, but lost you many posts back...
All was ok, so what did you change (and why) and what is the real issue right now?
And as @skywatch indicates, post the full log, sketch and everything. Don't try to filter information yourself, you might miss something.

@DenisJ yes, it does not depend on the radio, but on the arduino platform

@DenisJ MySensors implements sleep() for AVR using the watchdog. As you know, the watchdog can only sleep for at most 8 seconds, so long sleeps are divided into smaller watchdog sleeps by MySensors. Sleeping for eg 30 seconds is divided into 3x8 seconds, 1x 4 seconds and 1x2 seconds. This is all done by the library, in the single call to sleep() without you needing to worry about it

@Gilles-BILLARD what pro minis are you using? The 3v3 version only goes to 57600 baud, so 115200 is likely too much

@evb said in Please give me an advice for a simple sensor node:

But the node will continue to work till 1.8V in a safe operating area.

Yeah sure, but alkaline batteries are nearly depleted when they get to 1V, so barely worth the hassle.

@DenisJ I would advise to just build the standard node as described. The 1MHz frequency will hardly increase battery life, if any, but possibly introduces new issues (eg new bootloader).
Your node will be sleeping over 99% of the time, so focus on sleeping current when trying to improve battery life.
Once you feel more familiar with mysensors and Arduino you could try out new improvements, but you can always return to your initial, known good sleeping node.

@DenisJ a step up converter is never 100% efficient, so although you can drain your batteries further, it depends whether you can run your sensor longer with, than without converter.
Furthermore, boosters often introduce noise to the radio supply which can lead to range issues.
As this is your first build, I would simply use 2 fresh aa or aaa batteries to power your node directly.
I have several pro minis with bme280 and nrf24 radio that run for years on 2 aa batteries. Just follow the build instructions for the battery powered node.

@DenisJ nice!
Btw. @tbowmo created a nice set of node-red nodes to de- and encode MySensors messages. Maybe they can be of good use to you.

@DenisJ that should be possible, although mysensors does not implement it.

What you could do is use the MQTT MySensors gateway as-is, and use a service on top, running somewhere else, that subscribes to the mysensors MQTT topics, 'decodes' them and republishes the data under different, understandable topics to the MQTT broker.

This way you are not deviating from the MySensors gateway implementation (e.g. when updates are released) and you do not have to modify & reflash your gateway each time a node is added.

I personally use node-red for the decoding, but any other 'programming' tool with MQTT access should work.

@Gilles-BILLARD from the photos it seems you didn't connect a radio. If that is the case, the loop will not be entered and your arduino won't sleep!

@NeverDie If you only want to monitor and are worried about relays you could always open the shelly/sonoff/... and permanently shortcut/bypass the relay. And while you're at it, also disconnect the relay coil contacts (or remove the relay completely) to reduce heating of the unit and reduce power consumption.

@NeverDie IW100 uses the CS7598, according to https://templates.blakadder.com/sonoff_IW100.html
You'll be alright!

@NeverDie have a look at https://templates.blakadder.com/ which lists all devices (including power monitors) supported by tasmota. Tasmota exposes all measured data for a device through mqtt, where you can hook into.
I'm using a number of https://templates.blakadder.com/blitzwolf_SHP6-15A.html that way.

Tuya devices can often be flashed with https://tasmota.github.io/docs/Tuya-Convert/ without opening them.

@Bartosz-Nowak there is a long thread on this forum on the nrf52840. You could have a look there how to get things working

@Bartosz-Nowak said in Arduino nano 33 BLE sense:

wondering if the nano 33 sense is officially supported

No, it is not, and welcome to the forum @Bartosz-Nowak !

@BearWithBeard said in Measuring battery voltage, which way is best?:

This doesn't address backwards compatibility issues though

Nor forward compatibility, as "#pragma once" is much more common these days than using an include guard

@barrydou you seem right about the component types. If you doubt on their connection or use, just use a multimeter to trace signals

@Geelbuik it is a known issue, see https://github.com/mysensors/MySensors/issues/1458

@halo6 are you using fixed node ids, or using the controller to hand them out?

@canique I don't have much experience with rfm, but i definitely would prefer a solution that doesn't require a timer on the cpu side (so option a). Especially on the popular atmega 328 timers are scarce.
Could you prepare a pull request with your suggestions, so people can try it out?

@canique interesting info, but what is the actual point you're trying to make?
You say all rfm libraries are broken by design; do you have a suggestion to fix them?
You added timeouts; if you show people where, it becomes reproducible and people may benefit or even be able to improve on it.

@emre299 the booster likely adds noise to the power line, and it is a known fact that the nrf24 is very sensitive to this.
Either filter the noise, or better, get a decent booster.

@cabat what are you trying to achieve? Setting that LNA_HCURR to 1? It appears indeed to be 1 by default in MySensors

I ran into this article that uses MySensors and the nrf-doctor to correct issues with Pcb antennas on nRF24 modules.
I didn't try it, but seems to deserve a mention at this forum!

@barrydou are you sure your arduino is sleeping, and stays asleep? It could just as well go to sleep and wake again, go to sleep, wake etc.
To be sure you could add some prints around the sleep statement.

@skywatch do you have a link?

@hek so, when's the barbeque?

@boanjo very nice project & description!
How's are the petg prints doing outside? I wonder if they hold after prolonged uv exposure.

@bjornhallberg if you have a cheap sdr lying around you could use that to verify transmission frequencies and signal levels to some extent.
This can rule out bad modules easily.

@Diazovitch69 said in WatermeterPluseSensor How to parameter ?:

It cannot be lower if the measured volume is lower.

You say 15 liters in reality, gets reported as 20 in domoticz. Hence the factor should be lowered as stated in my post.
If the reporting is non linear, due to whatever reason, you will never get it right with a linear conversion factor...

@Diazovitch69 said in WatermeterPluseSensor How to parameter ?:

I have filled a 15 liter bucket and domoticz tells me 20 liters with a pulse factor set to 300 000.

Ok, then the factor should be 15*300 000/20=225 000

@evb how's the range of your node? Being enclosed in aluminum will definitely reduce range.

@Diazovitch69 could you give 11000 a try? (11 pulses per liter, 1000 liter per m3)
A simple test setup by connecting eg a bottle holding 1 liter to the sensor can help to confirm this number.

@joaoabs no, sorry. I didn't investigate any deeper.

@Olaf-Jacobs I cleaned your sketch a little, and changed the DS18B20 code to more or less reflect the way I read these sensors in some of my nodes:

#include <Arduino.h>

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable serial gateway
#define MY_GATEWAY_SERIAL

#include <MySensors.h>
#include <OneWire.h>
#include <DallasTemperature.h>

#define COMPARE_TEMP 1 // Send temperature only if changed? 1 = Yes 0 = No

#define ONE_WIRE_BUS 2 // Pin where dallase sensor is connected 
#define MAX_ATTACHED_DS18B20 16

OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature. 
float lastTemperature[MAX_ATTACHED_DS18B20];
int numSensors = 0;

// Initialize temperature message
MyMessage msg(0,V_TEMP);
int16_t conversion_wait_time_ms;

void presentation()
{
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo(F("Temp Sensor"), F("1"));

  // Startup up the OneWire library
  sensors.begin();

  // Fetch the number of attached temperature sensors  
  numSensors = min(sensors.getDeviceCount(), MAX_ATTACHED_DS18B20);

  // requestTemperatures() will not block current thread
  sensors.setWaitForConversion(false);
  sensors.setCheckForConversion(false);
  conversion_wait_time_ms = sensors.millisToWaitForConversion( sensors.getResolution() );

  // Present all sensors to controller
  for (int i=0; i<numSensors; i++) {   
     present(i, S_TEMP);
  }
}

void setup()  
{ 
}

void loop()  
{     
  // Fetch temperatures from Dallas sensors
  sensors.requestTemperatures();

  // sleep until conversion completed
  wait(conversion_wait_time_ms);

  // Read temperatures and send them to controller 
  for (int i=0; i<numSensors; i++) {

    // Fetch and round temperature to one decimal
    float temperature = static_cast<float>(static_cast<int>((getControllerConfig().isMetric?sensors.getTempCByIndex(i):sensors.getTempFByIndex(i)) * 10.)) / 10.;

    // Only send data if temperature has changed and no error
#if COMPARE_TEMP == 1
    if (lastTemperature[i] != temperature)
#endif
    {
      if ((temperature > -127.) and (temperature < 85.))
      {
        // Send in the new temperature
        send(msg.setSensor(i).set(temperature,1));
      }
      // Save new temperatures for next compare
      lastTemperature[i]=temperature;
    }
  }
}

Main changes:

• Removed the RS485 transport and any stuff you don't use/need (inclusion mode, leds, unused variables)
• Removed before, as all initialization can be done in presentation()
• Added setCheckForConversion() as my sketches do so too
• Store the conversion time in a variable as it won't change at runtime. This silences the bus communication during conversion.
• Removed the check for maximum sensors from the loops (I missed the check for numSensors in my first comment) and also calculate it only once, as these will also not change at runtime.
• Cleaned the COMPARE_TEMP a bit and added a range check on min/max temperatures -- checking for exact floating point values is tricky, so better just check if they are in range

Disclaimer: It compiles, but I didn't check it for correct functioning.

All in all I didn't see any obvious reasons for a freeze in your sketch.
If it runs ok for a while and then freezes, there could be other issues like power supply or faulty sensors.
Capture the gateway output over time to see what happened just before the freeze.

In any case you should always protect against missing or wrong updates!

@Olaf-Jacobs you seem to configure the gateway for rs485 transport, but I understand you don't have nodes at all, only the gateway. It's this correct?
You also loop over all possible sensors in the main loop, not the actual mount detected. Not sure if that's OK...

@fifo exactly which modules did you get? Did you check the pinout?

@mfalkvidd probably, but the search range (channel, baudrate) will be large.
I would start by just sniffing the spi communication to the nrf24 using a logic analyzer, to get the comms parameters and the data. Then configure another nrf24 to receive this data and work from there.

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

I found the root cause: https://github.com/mysensors/MySensors/issues/1458#issuecomment-739139339
It is part of the signing code, so expected to occur on all nodes/gateways that request nonces for signing.
Currently discussing if it is a real issue or not.

@joaoabs said in Anyone using Slimnode (RFM69) with MySensors 2.3.2?:

40 !SGN:PER:TAMPERED

I'm no signing expert, but that doesn't look good...
Ping @Anticimex?