@mfalkvidd I'm using an AVR board for my serial gateway. I modified hwDebugPrint in MyHwAVR.cpp with an extra #ifndef to look for MY_DEBUGDEVICE or copy MY_SERIALDEVICE to it. Then all occurrences of MY_SERIALDEVICE were changed to MY_DEBUGDEVICE.

I added this to my sketch:

#define MY_DEBUGDEVICE Serial  // Redirect debug to Serial

The result was what I wanted. Controller <-> Gateway configuration went over Serial1 (/dev/ttyS0 on my RPi) and debugging output went to Serial (/dev/ttyACM0 on my RPi). This allows me to easily debug without having to take any special steps with my controller.

void hwDebugPrint(const char *fmt, ... )
{
#ifndef MY_DEBUGDEVICE
#define MY_DEBUGDEVICE MY_SERIALDEVICE
#endif
#ifndef MY_DISABLED_SERIAL
	char fmtBuffer[MY_SERIAL_OUTPUT_SIZE];
#ifdef MY_GATEWAY_SERIAL
	// prepend debug message to be handled correctly by controller (C_INTERNAL, I_LOG_MESSAGE)
	snprintf_P(fmtBuffer, sizeof(fmtBuffer), PSTR("0;255;%" PRIu8 ";0;%" PRIu8 ";%" PRIu32 " "),
	           C_INTERNAL, I_LOG_MESSAGE, hwMillis());
	MY_DEBUGDEVICE.print(fmtBuffer);
#else
	// prepend timestamp
	MY_DEBUGDEVICE.print(hwMillis());
	MY_DEBUGDEVICE.print(F(" "));
#endif
	va_list args;
	va_start (args, fmt );
	vsnprintf_P(fmtBuffer, sizeof(fmtBuffer), fmt, args);
#ifdef MY_GATEWAY_SERIAL
	// Truncate message if this is gateway node
	fmtBuffer[sizeof(fmtBuffer) - 2] = '\n';
	fmtBuffer[sizeof(fmtBuffer) - 1] = '\0';
#endif
	va_end (args);
	MY_DEBUGDEVICE.print(fmtBuffer);
	MY_DEBUGDEVICE.flush();
#else
	(void)fmt;
#endif
}

@mfalkvidd I'm quite willing to open a pull request. This will be my first time. Do you want me to create an issue as well? Also what would this be called? Perhaps something like "Alternate Port Debugging"? It's hard to think of something that's 'googlable'.

What would be useful is a function that gets called (if it exists) between presentation and loop. Home Assistant requires that some sort of initial value be sent so that it can learn that the device exists. Obviously, these initial values have to be sent after presentation to the gateway.

What people end up doing is something like this:

void loop() 
{
  if (!initialValuesSent) 
  {
    //send initial values
    initialValuesSent = true;
  }
  //rest of loop function
} 

That if-statement is executed in each iteration of loop() even though it only matters once. It looks ugly, but more importantly, it consumes unnecessary resources.

@korttoma Two years later.... I just wanted to say that your sketch is elegant and beautiful. Using arrays is an idea I had as well, but I was just starting to write something when I thought about looking to see if someone had already done it. You saved me days of yelling at the monitor trying work it out for myself. You should consider making a topic out of this script.

You might need to take this to the [Home Assistant Forum]
(https://community.home-assistant.io). Something strange is going on at the OS level. Your kernel is recognizing the USB device, but the OS isn't creating the tty. You can try lsusb just to see if it's still there, but beyond that I'm out of advice. The error you are getting from Home Assistant has awkward wording, but it means that it can't find the serial device.

What do you get from ls -l /dev/tty*?

Are you sure that's the right device? It's /dev/ttyUSB0 that is the source of the error in your output. Maybe the device is something like /dev/ttyAMA0 or /dev/ttyACM0?

I'm also having trouble with RFM95's. I'm confused about MY_RFM95_IRQ_PIN and MY_RFM95_IRQ_NUM. Does PIN mean the GPIO pin number or the interrupt pin number? I've noticed that the same physical pin has different numbers depending on their use.

Also, what is the distinction between MY_RFM95_IRQ_PIN andMY_RFM95_IRQ_NUM?

The sketch works using a direct, wired connection (RS485).

T received - starting test...
Sending Ping to Ying Node
2226167 TSF:MSG:SEND,201-201-1-200,s=1,c=1,t=24,pt=5,l=4,sg=0,ft=0,st=OK:2226165

But it does not work with my RFM95's, but that is a completely different topic.

I'm having a problem similar to what is described in "NRF24 Radio does not link if MY_DEBUG_VERBOSE_RF24 is not defined. #941" https://github.com/mysensors/MySensors/issues/941. My local branch is up to date with the beta development branch (v2.2.0-beta).

That issue that I referenced seems to deal with data arriving too quickly from the gateway. I am operating without a gateway doing some testing with PingPong, so I'm not sure the problem is the same. (See below for how I'm shutting off attempts to communicate with a Gateway in case it is relevant).

I'm getting the same error RF24:RBR:REG=23,VAL=17 repeating endlessly, but only on 328P 3.3v 8MHz boards (knock offs from Robotdyn). I've tried two identical boards with the same results. However, the identical sketch runs fine on my 32u4 (Adafruit Feather). The problem, therefore, seems to be hardware specific. I have swapped radios back and forth and the trouble remains on the 328 even when using the radio that works on the 32u4.

I have an identical 328p and NRF24 (from the same shipment) up and running under 2.1.1. Something seems to have crept in with the changes in the new beta. What can I do to help debug?

Assuming that "REG=23" refers to decimal register 23, then looking up the register as hex 17 in the specification, I find this:

If I'm reading the chart right (assuming I'm even in the right place) then it looks like the NRF24 is reporting RX_EMPTY and TX_EMPTY.

The radios are all NRF24L01+ from Makerfire.

Shutting off Gateway communication:

#define MY_TRANSPORT_WAIT_READY_MS 3000
#define   MY_TRANSPORT_UPLINK_CHECK_DISABLED  //Don't check for uplink
#define   MY_NODE_ID 199  //Fallback NodeId
#define   MY_PARENT_NODE_ID  1
#define   MY_PARENT_NODE_IS_STATIC

Based on what @gohan posted, I searched for 'without gateway' and found several useful posts. Sometimes all it takes is knowing how to ask the question.