@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 :joy: :joy: :joy:

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