Hello all, may be I did not get the point of this thread, but a very similar code to measure the AVR CPU voltage is already part of the MySensors library: MyHwAVR.cpp#L289

I use it in some of my PIR sensors and it works fine. Simply call hwCPUVoltage() to get it.
This is from my code:

void sendBatteryLevel()
{
  // This calls the internal voltage measurement
  uint16_t voltage = hwCPUVoltage(); 

  // Li AAA Cell Voltage range: discharged - full 2.6V - 3.0V
  uint16_t batteryPcnt = map(voltage, 2600, 3000, 0, 100);
  batteryPcnt = constrain(batteryPcnt, 0, 100);

  // This MySensors function sends the "internal battery info" to the gateway
  sendBatteryLevel(batteryPcnt);
}

BR Immo

Hi all, @Necromant has created an interesting PR #1477 in the MySensors repo with request for comments. It is about packet transport reliability for nRF24L01+ modules and how to improve it.

I have a similar setup as in PR with gateway, repeater and about 20 sensor nodes. To make it not too easy, there are two ping-pong nodes, which constantly send each other telegrams of maximum length with life sign signal value.

I know since longer time that the main reason for lost telegrams in my setup is the collision of two nodes, each trying to send a telegram to the other. Then both repeat the telegram 15 times but both nodes have no success with it. The other node would have to be in receive mode, but instead to listen it tries to send it's own telegram multiple times - a classic deadlock.

In worst case other nodes then also try to transmit and sometimes (every few days) this causes a traffic jam on the airwaves with a longer failure of the gateway. The error light then flashes constantly and nothing works anymore.

I see two different RF24 problems which may be resolvable by the PR:

1. Occasional traffic jam on the airwaves
2. Packets lost if two nodes try to send almost simultaneously to each other

So, your comments are requested - Thank you

@skywatch Thank you for clarifying. And nice that you like my implementation

I also find it very good and helpful for beginners to show the internal battery measurement method on the "Battery Power" page from MySensors. When I started with MySensors I followed the instructions for measuring via analog pin and 2 resistors. The more simple internal measurement I discovered way much later.

BTW there are some more built in functions, e.g. for the current CPU frequency and the current free heap size. With the MYSController you can query these values from the individual nodes:

You need only to add the #define for this functionality in your Node sketch:

// Enable support for I_DEBUG messages.
#define MY_SPECIAL_DEBUG

Hi @Necromant, welcome to the forum!
BTW From your profile image is it this one?

This is a SN7440 clone from Soviet times, right?

But back to topic and your issue 1:
A delay before resending is required for sure. A wait() is not a good idea because it introduces recursion of unknown deep, depending from the users receive() implementation.

But a short delay() is possible. While delay() the RF24 is in receive mode and can actually receive the other nodes packet which has collided before.

But exponential backoff is also not a good idea, because this can become a long delay of a second or more which blocks all time the main loop. But a short random delay of some 10th ms (like mentioned by @skywatch) worked for me in my setup.

But instead of speculating, we should try out the ideas on a test setup in a comprehensible way. But we should do that outside the official MySensors repo.

I will prepare a branch with the necessary core changes in my MySensors clone repo and also create test projects. I will start with a gateway and a sensor node.

Then we can check your topic 3 with sending 4 or more packets in a row from gateway (I will use a ESP8266) to a slow 12MHz Nano clone.

Hi @Necromant, thank you for your comments regarding the RPD feature of the nRF24+.

I have done some experiments with it. The result is a new tool TrafficDetectorRF24, which is available in my MySensors.Tools repository. The tool scans a single channel and outputs the current status via a debug pin. This can be used to connect a LED or better an input of a logic analyser.

At first I tried to use the RPD feature based on the MySensors example PassiveNode.
Unfortunately, that didn't work at all for me. I then adapted the code from Rolf Henkel Poor Man's Wireless 2.4GHz Scanner for my purposes.

The detector works quite accurately (resolution approx. 140us) so that you can usually detect the transmitted telegram and the ACK response of the receiver individually:

I hope you have more success in your attempts with the RPD feature.

@PZDPRO
Hi, have you checked in HA the file /config/mysensors/mysensors.json?
Can you provide the content here?

I have been using HA with MySensors for some time and it works for me, but sometimes HA behaves strangely for me too.
Maybe we can fix your problem here and maybe someone with more HA experience can join the discussion.

So far your second Arduino sketch should work with HA.
BR Immo

@mfalkvidd Yes, you are right. Acknowledge only checks the first hop. I mean the requestEcho parameter in the send function, see: API doc send().

bool send(MyMessage &msg, const bool requestEcho = false)

Hi @mfalkvidd, thank you for your prompt response to check with the core team. cla-assistant looks perfect.

Hope the switch will not be to complicate for your side.

Hi @Steve-Parsons, I had also some trouble with reading light level after sleep. My solution is to read the sensor twice. Also you should use in setup() the one-time-mode:

lightMeter.begin(BH1750::ONE_TIME_HIGH_RES_MODE)

This is an excerpt of my battery powered garden sensor sketch.
It runs on an Arduino Pro Mini clone:

#include <BH1750.h>

BH1750 lightMeter(0x23);

void setup()
{
  // begin returns a boolean that can be used to detect setup problems.
  if (lightMeter.begin(BH1750::ONE_TIME_HIGH_RES_MODE)) {
	Serial.println(F(("BH1750 Advanced begin"));
  } else {
	Serial.println(F(("Error initialising BH1750"));
  }
}

void getLightLevel()
{
  lightMeter.readLightLevel();
  wait(20); // First measurement after sleep is wrong, take the seconde reading
  float lux = lightMeter.readLightLevel();
  if (lux >= 0.0) {
	// Round lux to 0.1
        // May be this rounding can be improved
	lux = floor(lux * 5 + 0.5) / 5;
	send(lightMsg.set(lux, 1));

	Serial.print(F("BH1750 - Light = "));
	Serial.print(lux);
	Serial.println(F(" lx"));

  } else {
	Serial.println(F("=> BH1750 Error!"));
  }
}

void loop()
{
  static uint32_t lastMillis = 0 - measurementPeriod;
  if (millis() - lastMillis >= measurementPeriod)
  {
	getLightLevel();
	lastMillis = millis();
  }

  unsigned long sleeptime = 60000ul; // 60 sec
  Serial.println(F("Sensors node - Go to sleep"));
  bool smart = true;
  sleep(sleeptime, smart);
  Serial.println(F("Sensors node - Waking up"));
}

HTH Immo

@HisDudeness Hi, MySensors will not help you with your use case to control a RC Car.
But may be this link helps you further:
rf-433mhz-transmitter-receiver-module-with-arduino

@Nigel31 Hi again, yes looking at your code these wait() calls inside a while loop may be the reason for the recursion. You could check this when you add debug messages before and after your waits. If then are in the log the recursion messages between your own wait begin/end messages you have the "smoking gun". In this case you should refactor your code to use state machines instead of the wait() functions. In general the loop() function with all sub function calls should always be as short as possible.

@Nigel31 These messages are warnings that you are recursively calling the wait() function.
I think this warning is only issued since version 2.3.2.
In older versions there is certainly the same problem, but you do not receive a warning.

Under certain circumstances, this recursion can also occur during normal operation of the MyS lib. I think it is specifically in connection with the signing functionality. There was already a thread about this problem and the lib issue
https://github.com/mysensors/MySensors/issues/1458.

These "internal" warnings are unpleasant, but not a cause for concern.

It is also possible that you are causing the recursion through your application program.
This case is the real purpose of this warning.
You should check whether you call the wait() function within your receive() function.

tobof created this issue in mysensors/MySensors

open Recursive call of process() and wait() when using signing #1458

@workshopninja Yes, this is basically what I did with an Arduino MKR1000 WIFI some years ago. There are some #defines for the EEPROM in the code. But for me it worked out of the box with a 24LC32P.

See also in the MyS lib code:
hal/architecture/SAMD/MyHwSAMD.h#L47

But in the end I switched to the ESP8266 because it also has WiFi and is much cheaper. The support for external libraries is also much better than with the SAMD.

@mfalkvidd Yes, you are right. Acknowledge only checks the first hop. I mean the requestEcho parameter in the send function, see: API doc send().

bool send(MyMessage &msg, const bool requestEcho = false)

@HisDudeness Your module does not have the coil because the Chinese manufacturer decided to make production costs for the cheap module even cheaper. Technically, these coils serve to suppress harmonics of the transmitter. Without the coil, your module also transmits on a frequency other than the one printed on it.
Here in Germany, for example, it is strictly forbidden to transmit outside the ISM frequency band 433 MHz without a licence. This is also controlled and, if necessary, prosecuted.

@Nigel31 From my understanding you could send periodically a message with auto acknowledge request to the gateway and check in your node for this response. Then you know that the gateway is up and responsible.

@workshopninja said in Seeeduino Xiao:
Hi all,
MySensors is basically able to work with samd21 MCU chips, like used in the Xiao and Arduino Zero because the SensBender gateway also has such a MCU, see:
https://www.mysensors.org/hardware/sensebender-gateway

But this gateway has an additional serial EEPROM chip AT24CS32-STUM - 32Kb (4096x8) Serial EEPROM with Unique Serial Number, SOT-23-5.
This is required to get MySensors lib running.

For your Xiao you have to connect such a serial EEPROM externally, you can use any one with 32k and DIL enclosure which makes it more breadboard friendly e.g.:
https://www.reichelt.de/eeprom-32-kb-4-k-x-8-2-5--5-5-v-dip-8-24lc32a-i-p-p40077.html?&trstct=pol_2&nbc=1

HTH

@HisDudeness Hi, MySensors will not help you with your use case to control a RC Car.
But may be this link helps you further:
rf-433mhz-transmitter-receiver-module-with-arduino

@BearWithBeard Big thank you for the link to MyNetDebug. I was not aware of this debug feature. Looks cool, I will give it a try.

@halipte Yes, you are right. The AM312 is different from the AS312 which I use.
see: AM312 Datasheet and AS312 Datasheet
But both are looking similar. No additional parts are required. For the HC-SR501 PIR there are a lot of additional parts on the module PCB. So at the end I prefer the AS312 to keep my PIR sensor device small and simple.