Best posts made by virtualmkr

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.

@Adam-Slowik, @JeeLet
Ok, I will give CAN-Bus a try. This is my test setup:

I will use the demo sketches from Adam's fork. Let you know how it works for me.

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

@NielBierman Thank you for pointing out that the latest TinyGSM library also supports more modern GSM chips.

I don't have a GSM module myself and no experience with it. But it would be good if you could put an issue in the MySensors GitHub repository.

It would be even better if you could post your solution with the updated TinyGSM library as a pull request to the repository development branch.

Many thanks - 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,
short question: do you have applied the external pull-up resistors for the two I2C bus lines? Some modules have them built-in but others not. E.g. the Lolin Wemos shield has them already connected to power with two 4.7k resistors. See schematic for it: sch_bh1750_v1.0.0.pdf

If not, you should try this.
May be your first module is not defect, but only the resistors are missing?

@CrankyCoder My comments to your sketch:

• be aware that the millis() counter also stops while your node sleeps,
• when the node sleeps then it will not receive messages, may be someone can help out how to handle this (basically I think the node should request the child node state from MQTT after wake up),
• be aware that presentation() can be called from controller at any time, not only at node startup, so I would move the non presentation code to setup().

But for your main problem that the node doesn't wake up after some time I have no idea so far. Hopefully the log helps here.

Hi all,
I'd like to add, there is no need to call wdt_reset() explicitly in loop().
This already takes place before each loop() call in the MySensors library code behind function doYield():
see: MySensorsCore.cpp#L619

And hwWatchdogReset() is an HW abstraction of wdt_reset() for AVR architecture:
/hal/architecture/AVR/MyHwAVR.h#L71

My call stack from main() to doYield() is:

>	MySensorsProject2.exe!doYield() Line 650	C++
 	MySensorsProject2.exe!_processInternal() Line 74	C++
 	MySensorsProject2.exe!_process() Line 91	C++
 	MySensorsProject2.exe!main(int argc, char * * argv) Line 343	C++

@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.

@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

@rozpruwacz
Hi,

1. You can take a look into file history for all people which have maintained the file MyTransportRS485.cpp:
   https://github.com/mysensors/MySensors/commits/development/hal/transport/RS485/MyTransportRS485.cpp
2. In addition, you will find in the header of this file the contact info of the original author:
   • Copyright (c) 2013, Majenko Technologies and S.J.Hoeksma
   • Copyright (c) 2015, LeoDesigner
   • https://github.com/leodesigner/mysensors-serial-transport
   • All rights reserved.
3. There is a recent and still open pull request to improve the RS485 transport layer:
   https://github.com/mysensors/MySensors/pull/1451
   May be you contact this developer too.

@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

@Michiel-van-der-Wulp There was a discussion early this year 2021 on this issue,
see: Contribution Issue with CLA and clahub.com

But unfortunately there is no feedback for a solution from the core team for now.

@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.