Posts made by virtualmkr

@chabo_mq Could this possibly be an IR light barrier?

@monte Thank you for sharing, just ordered the bits.

@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

Uploaded with Crome and copied from clipboard.

In logic analyser it looks like this:

Upper 4 channels are from node, lower ones are from gateway.

Close up from gateway send (4 packets):

@Adam-Slowik, @JeeLet Ok, with the both sketches it works with some limitations.
Nice work so far - thank you for contributing!

I have done some modifications in the CAN transport files.
@Adam-Slowik I would like to create a PR in your forked repo. Then we can discuss the code changes in GitHub. Would that be Ok for you - do you have time for this?

One limitation I found so far are long MyMessages. They can be up to 32 byte - which results in up to 4 CAN-Bus sub telegrams. When I send 32 byte message I observed the sub telegrams do not always arrive in send order in MyTransportCAN.cpp like this:

19916 CAN:RCV:CANH=2202010368,ID=3,TOTAL=4,CURR=0,TO=3,FROM=0
19921 CAN:RCV:LN=8,DTA0=0,DTA1=0,DTA2=3,DTA3=202,DTA4=9,DTA5=2,DTA6=0,DTA7=49
19929 CAN:RCV:SLOT=0,PART=1
19932 CAN:RCV:CANH=2202075904,ID=3,TOTAL=4,CURR=1,TO=3,FROM=0
19937 CAN:RCV:LN=8,DTA0=50,DTA1=51,DTA2=52,DTA3=53,DTA4=54,DTA5=55,DTA6=56,DTA7=57
19945 CAN:RCV:SLOT=0,PART=2
19947 CAN:RCV:CANH=2202206976,ID=3,TOTAL=4,CURR=3,TO=3,FROM=0
19953 CAN:RCV:LN=8,DTA0=56,DTA1=57,DTA2=48,DTA3=49,DTA4=50,DTA5=51,DTA6=52,DTA7=53
19960 !CAN:RCV:proper slot not found
19964 CAN:RCV:CANH=2202141440,ID=3,TOTAL=4,CURR=2,TO=3,FROM=0
19970 CAN:RCV:LN=8,DTA0=48,DTA1=49,DTA2=50,DTA3=51,DTA4=52,DTA5=53,DTA6=54,DTA7=55
19978 CAN:RCV:SLOT=0,PART=3

Sub telegram 3 arrives before 2.
I'm afraid the function _findCanPacketSlot() needs an update to handle this.
@Adam-Slowik Do you see a chance for you to update the logic next time?

Other limitation I see is the limited CAN telegram buffer of 3 packets in the MCP2515 module. I'm afraid for reliable operation with MySensors a change from polling to interrupt mode is required.
But this can be done later, after the fix for the PacketSlot logic.

@JeeLet

what do you want me to test ????

bool transportSanityCheck(void)
{
	return (CAN0.getError()==CAN_OK)
}

The "radio guy" opinion would be great.
((I'll look for possible help ). )

I'm not a "radio guy", but I think this code change looks fine. When sanity check fails then MySensors core calls transportInit() which would try to re-initialise the MCP2515 module.

In my setup with only 2 CAN modules I'm afraid this will always return CAN_OK. So no idea how to check this. May be unplug the both CAN wires?

@ueb
For me the connections according your photos are correct for ESP32.

• SDA - 21
• SCL - 22

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

@virtualmkr CE is required to switch between send and receive mode of the radio.

@CrankyCoder Yes, may be. But also may be the CE connection from Arduino to the radio is broken.

@CrankyCoder Yes, your node tries to find his parent but gets no response. And additional the sleep and wake up happens at the same time. Interesting state, your node is in.

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

@CrankyCoder Can you provide your node sketch and also activate MY_DEBUG to get a log to provide here? This would be helpful for sure.

@ltigges
Hi, I can confirm your issue. Thank you for reporting!
Best will be to open a new issue in in the GitHub repo at MySensors/issues.
It would be great if you could do that- thank you.
BR Immo

@jaraics MySensors supports multiple communication physics between the MySensors Gateway and the node Arduinos. Best supported are the wireless ones, but you can also use wires with RS485 (two wire) or the new added PJON driver which only needs one wire (plus ground).
One other option is to use only one Arduino with many IO pins like the Arduino Mega as a gateway arduino-mega-2560-rev3. This board has 54 IO pins. There are also cheap China clones available.

One issue for this way: I have never tried to use the Arduino Mega by myself.
Maybe someone else can give feedback to tell if a Mega will work as a gateway?

@skywatch

@mrmuszynski
Hi, there are some setters for message payload types but none for type String, see: Message manipulation.

You need to convert the resulting String into const char* like this:

send(msg.set(("string " + String(expectedScratchpadValues)).c_str()));

But in general I would try to avoid usage of the String data type, especially for the use case in your code example. You could use e.g.:

  char str[80];
  sprintf(str, "string %d", expectedScratchpadValues);
  send(msg.set(str));

For Arduino String read more e.g. here: The Evils of Arduino Strings

HTH

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

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

@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 Also you should activate the logging for the MySensors integration.
See: https://www.home-assistant.io/integrations/mysensors#debug-logging

The log will hopefully provide further insights..

@PZDPRO
Additional I use the MYSController tool, very helpful for debug:
MYSBootloader 1.3 pre-release & MYSController 1.0.0beta

With this you can check if the problem is on HA side or with your gateway.

@PZDPRO It may be you use the automatic config file name. For me I have a second MySensors integration with the configuration file located directly in the config folder:

When your MyS gateway is reachable via ping then HA should be able to connect.
How is your HA hosted? Do you use the HA Raspi image?

@PZDPRO
I use the File editor from Add-on Store:

Then I can see the MySensors nodes configuration:

@halipte
Hi, have you tried these ones? HC-SR501 PIR
For me they work faster than the AS312.

For the AS312 I use this one:
Wemos PIR shield

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

@maddhin I use Wemos D1 Mini as a gateway and it works perfect. May be there is an issue with your modules? Did you tried the ESP8266 example sketch WiFiScan?

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.

Hi @skywatch, from my view this would be possible, but it needs some modifications to the MySensors library.

One needs to add a field for the RF24 channel to the EEPROM fields, see:
core/MyEepromAddresses.h#L34

This field value should then be used when initialising the transport layer for the RF24 channel.

For the initialisation to take place, the simplest way would be to call hwReboot(). This can also be done remotely via an I_REBOOT message.

But that is a lot of modification. The mysbootloader that I love to use for my AVR nodes would also need an update, as it also relies on the EEPROM address layout.

Hi @necromant, thanks for your HA setup and investigations. Yes, when a message is sent to an actuator, it needs to respond with the new status for HA. If you control multiple actuators quickly one after the other it creates perfect traffic jam in the MySensors network.

Now we just have to find an algorithm how to best resolve these collisions.
Your HA project is then a perfect real-world test for the algorithm.

This is how Setting-02 looks like with my good old Saleae LA when both nodes send at the same moment:

You can see, both nodes send the message 16 times because ARD is 15 by default.
And both without success.

@Necromant You are right, an ESP8266 with WiFi may behave differently than an STM32. Unfortunately I don't have a working STM32 as gateway.

Meanwhile I created two additional test settings with gateway and two nodes, where the used gateway type is not important. The test settings are available in my repo MySensors.IssueProjects.

• Setting-02 creates a race condition of two nodes sending a message to the gateway at the same time.
• Setting-03 creates a conflict when both nodes send a message to each other at the same moment. For that one node is in repeater mode and the other node is associated to the repeater.

The approach of synchronizing the two nodes via GPIOs and a wire to send at the same moment works very well and reproducibly in Setting-02. The only problem was when all the sent messages in a row fail, that then the internal self-healing mechanism of MySensor's transport logic reinitializes the radio. To avoid this, I added logic that sends a successful message after 4 failed messages. With this the MySensors self-healing mechanism is then satisfied.

Setting-03 does not work properly yet, because the N2N logic causes every message from node to the repeater to be sent twice.

I will create an issue about this in the MySensors repo.

@Necromant said in [RFC] Improve package delivery for RF24 modules:

Another idea I thought of, would be listening if any carrier is present. (nRF24L01+ has that feature) and sending any packets only once there's no carrier + adding a random delay. This would hopefully avoid collisions, even with other things, like WiFi.

Yes, this sounds interesting. Do you think of the RPD register value (Received Power Detector) from RF24?
But it will only work with the RF24 transport drivers (like @skywatch remarked above).

Meanwhile I'm ready with the first setup to produce a reproduceable packet lost with your idea of sending multiple messages immediately one after other. The test project repo with gateway and one node is:
MySensors.IssueProjects

The MySensors core changes are in my project fork branch:
topic/mkr/issueTransportHalRetry

Unfortunately the #1477/Setting-01 solution don't produces any lost packet with ESP8266/160MHz as gateway and Nano/12MHz as node. So I would say that a fast gateway, sending multiple messages to same node in a sequence without wait() in between, is not the reason for lost packages. I have checked with up to 256 packets in a row. All perfectly transferred without any one lost.

My next try is to use two nodes which send messages at the same time to gateway. I think of somehow synchronize the nodes by a wire between GPIOs. I will let you know.

But maybe someone has a better idea for a setup which produces a packet lost for sure?

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.

@NeverDie No thanks
To write a complete architecture HAL for MySensors is a lot of work. Search e.g. in the MyHwSAMD .cpp code for "TODO: Not supported!". And this HAL already exists since years!

There are other construction sites in MySensors that are more worth the development effort.

@skywatch There is also the next "Yet another Arduino with fancy hardware but poor library support" planned: Arduino Nano RP2040 Connect

Hi @NeverDie, I also like the Atmega4809. I have an Nano Every here to play with. It has 6KB RAM and 48KB flash memory. That's all nice. But software compatibility is the problem.

Looks like it needs a new HAL architecture implememtation for MySensors. When I try to build a simple MyS project with Arduino IDE I get:

~\Documents\Arduino\libraries\MySensors/MySensors.h:89:2: error: #error Hardware abstraction not defined (unsupported platform)
 #error Hardware abstraction not defined (unsupported platform)
  ^~~~~
exit status 1
Error compiling for board Arduino Nano Every.

Very sad

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

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?

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

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++

@karlheinz2000 sounds great that you found the bug. It's always difficult to tell if it is a HW or SW bug on MCUs. From your first description it seems like a SW one to me.

@skywatch Thank you for the minicore tip. I was not aware of this project.
Implementation of constrain() in minicore differs from constrain() implementation in the original Arduino core.
So maybe it is a minicore issue. Or may be your batteryPcnt type is float?
Neverless one should prevent battery percentage below 0% or above 100% because it makes no much sense.

"cHz" is actually strange but it means 0.1 x MHz, so for my ESP8266 I get 1600 x 0.1 MHz = 160 MHz:

This way the frequency value fits well into uint16_t type.

@karlheinz2000 Unfortunately there are no debug messages in the RS485 driver code available. I mean something similar to MY_DEBUG_VERBOSE_RF24 for the RF24 transport.

When you don't get any input at the STM32 side I would start by adding some "Serial.println(x)" into the function _serialProcess() in ~\MySensors\hal\transport\RS485\MyTransportRS485.cpp
to check if there is something coming in at least.

HTH

@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

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

Hello MySensors community!

Many thanks for this brilliant project and all the contributors to it.

I use it now for about two Years whith joy and good success and also made some modifications to the library for myself.
So now I would like to contribute some of them.

I followed the Contribution Guideline but stuck with the CLA registration website
https://www.clahub.com/agreements/mysensors/MySensors.

Looks like the site is down at least since yesterday.
Found on the web that also others have trouble with this clahub web site.

How I can proceed now? Is there an other way for the CLA?

Thank you