Posts made by phil2020

Re: Everything nRF52840

Just wanting to find out if anyone @d00616 has the nRF52840 fully working with MySensors? I've been able to only get the radio part working, but the peripherals on the board (e.g. Adafruit Bluefruit Sense) don't seem to be exposed/working. I see adafruit have their own bootloader and way of programming this device, but it requires the upload of the softdevice, so we can't use it with Mysensors? Anyone got any workarounds to get it working?

I created a new section for the nRF52840 in the \AppData\Local\Arduino15\packages\MySensors\hardware\nRF5\0.3.0\boards.txt.

# MyBoardNRF5 nRF52840
# Board definition is expected in
# MyBoard.cpp and MyBoard.h as part
# of the sketch
###################################

MyBoard_nRF52840.name=MyBoardNRF5 nRF52840

MyBoard_nRF52840.upload.tool=sandeepmistry:openocd
MyBoard_nRF52840.upload.target=nrf52
MyBoard_nRF52840.upload.maximum_size=524288

MyBoard_nRF52840.bootloader.tool=sandeepmistry:openocd

MyBoard_nRF52840.build.mcu=cortex-m4
MyBoard_nRF52840.build.f_cpu=64000000
MyBoard_nRF52840.build.board=GENERIC
MyBoard_nRF52840.build.core=sandeepmistry:nRF5
MyBoard_nRF52840.build.variant=MyBoardNRF5
MyBoard_nRF52840.build.variant_system_lib=
# -I{build.path} and -DMYBOARDNRF5 is only required by MyBoardNRF5
MyBoard_nRF52840.build.extra_flags=-DNRF52840_XXAA -DMYBOARDNRF5 -I{build.path}
MyBoard_nRF52840.build.float_flags=-mfloat-abi=hard -mfpu=fpv4-sp-d16
MyBoard_nRF52840.build.ldscript=nrf52840_xxaa.ld

MyBoard_nRF52840.menu.bootcode.none=None
MyBoard_nRF52840.menu.bootcode.none.softdevice=none

MyBoard_nRF52840.menu.lfclk.lfxo=Crystal Oscillator
MyBoard_nRF52840.menu.lfclk.lfxo.build.lfclk_flags=-DUSE_LFXO
MyBoard_nRF52840.menu.lfclk.lfrc=RC Oscillator
MyBoard_nRF52840.menu.lfclk.lfrc.build.lfclk_flags=-DUSE_LFRC
MyBoard_nRF52840.menu.lfclk.lfsynt=Synthesized
MyBoard_nRF52840.menu.lfclk.lfsynt.build.lfclk_flags=-DUSE_LFSYNT

MyBoard_nRF52840.menu.reset.notenable=Don't enable
MyBoard_nRF52840.menu.reset.notenable.build.reset_flags=
MyBoard_nRF52840.menu.reset.enabled=Enable
MyBoard_nRF52840.menu.reset.enabled.build.reset_flags=-DCONFIG_GPIO_AS_PINRESET

When compiling, it didn't like the reference to 250kbps speed, so I had to comment out references. Using current Dev branch...

in \AppData\Local\Arduino15\packages\MySensors\hal\transport\NRF5_ESB\driver\Radio.h

// Radio mode (Data rate)
typedef enum {
	NRF5_1MBPS = RADIO_MODE_MODE_Nrf_1Mbit,
	NRF5_2MBPS = RADIO_MODE_MODE_Nrf_2Mbit,
	//NRF5_250KBPS = RADIO_MODE_MODE_Nrf_250Kbit, // Deprecated!!!
	NRF5_BLE_1MBPS = RADIO_MODE_MODE_Ble_1Mbit,
} nrf5_mode_e;

in \AppData\Local\Arduino15\packages\MySensors\hal\transport\NRF5_ESB\driver\Radio_ESB.cpp

// Calculate time to transmit an byte in µs as bit shift -> 2^X
static inline uint8_t NRF5_ESB_byte_time()
{
	if ((MY_NRF5_ESB_MODE == NRF5_1MBPS) or
	        (MY_NRF5_ESB_MODE == NRF5_BLE_1MBPS)) {
		return (3);
	} else if (MY_NRF5_ESB_MODE == NRF5_2MBPS) {
		return (2);
	} //else if (MY_NRF5_ESB_MODE == NRF5_250KBPS) {
		//return (5);
	//}
}

I'm wondering if the memory definitions in sandeepmistry\hardware\nRF5\0.7.0\cores\nRF5\SDK\components\toolchain\gcc\nrf52840_xxaa.ld are correct/complete, and if they should be linking to nrf52_common.ld or what changes need made there? The memory map https://infocenter.nordicsemi.com/topic/ps_nrf52840/memory.html?cp=4_0_0_3_1 seems more complicated than the nRF52832, and difficult to read across, so I'm not sure if anything needs changed/updated there?

For the pins, I see the standard MyBoard defintiion is for 32 pins on p0, but I see in the adafruit definitions they reference p1 pins, it seems that p0 covers pins 0 to 31 and p1 continues with references 32-63. To support referencing p1 pins, do we then just need to extend the pin definitions to 64 pins in \AppData\Local\Arduino15\packages\MySensors\hardware\nRF5\0.3.0\variants\MyBoardNRF5\compat_pin_mapping.h and add to the list in MyBoardNRF5.cpp and reference in MyBoard NRF5.h alongside the sketch?

Would welcome any other insights or steer if anyone has got it working with MySensors?

@tekka Thanks for the pointer about the reboot. After some experimenting I found that two devices sharing the same ID and receiving the 255 node ID will receive that message simultaneously (since they are both sensitive to the same ID) and would try to send their requests at the same time, interfering with each other on the channel and only one request being received at my controller. However both devices seemed to update with the new NODE_ID value, even though I was using the random token which should only act upon the device that issued that token. To overcome this I added a random delay before the update/storage of the new ID, changing the timings of each device.

So in below code, it is essentially called twice, the first message is sent when a clashing node is detected, sending a NODE_ID value of 255, and each device then reboots at a different time. The devices will then automatically request a new node from the controller and this time they will get issued new unique NODE_ID values from the controller.

// Code snippet from void receive()
delay(random(1000)); // delay up to 1000ms to de-conflict simultaneous updates
hwWriteConfig(EEPROM_NODE_ID_ADDRESS, message.getByte()); // store new NODE_ID
software_Reboot();

// Soft reboot in NRF5
void software_Reboot(){
  wdt_enable(WDTO_15MS);
  while(1){}
}

@tekka I'm wondering if there have been any changes in the ability to update the node ID via I_ID_REQUEST? In the past I am sure I was able to send a message to devices which had the same clashing node IDs and tell them to take on the ID 255. This would then put them into the mode, as if they were new devices, and they would automatically request their new ID. But if I try to do this now, they seem to get the node 255, but they don't emit the automatic messages to request new IDs e.g. successive messages like below

255;110;3;0;3;
255;63;3;0;3;
255;16;3;0;3;
255;225;3;0;3;

I was intending to use the approach of assigning the 255 address to enable me to handle the re-assignment of new node IDs where multiple devices were reporting the same node ID (e.g. more than 1 device on the channel reports that it has the same node ID "1").

I note that erasing the device completely (including EEPROM) does trigger the appropriate automatic requests, but once programmed and I try to set the clashing node IDs to 255, doesn't trigger the same behaviour of automatic ID request.

Is there an issue with how it works in the current library version, or is there another way to do it?

Thanks,

Are there any plans to update the mysensors nRF5 boards definition to now support the nRF52840? I saw that Adafruit have now added support and are offering a feather based on this module https://www.adafruit.com/product/4062. There is also this listing for a module with 1.27 mm spacing on Alibaba https://www.alibaba.com/product-detail/low-energy-mesh-network-UART-module_60816297852.html

That works, and is a lot shorter!

Thanks

I'm expecting this is just a simple declaration/formatting issue, but I can't work out how to compare the individual characters of a received message.

I want to loop through a received message payload of 20 characters. If I find a "*" character then update a status flag.

          bool status= false;
          for (int i=0;i<20;i++){
            char *a = "*";
            char *b = message.getString()[i];
            if (strcmp(a,b) == 0){
              status = true;
            }
          }

I keep getting a compile error relating to "invalid conversion from char to char* [-fpermissive]".

Thanks for the replies. From looking through those links, it appears that instead of just using a fixed #define value, you can instead reference a variable and assign the variable's value programmatically in the before() section. For example you could load in the value required for channel or base radio ID from EEPROM memory.

So you can, in a sense, dynamically change the values through store of updated parameters into EEPROM and effect that change via a software reset process that you can call from your program.

Hi,

It's my understanding that you can change the channel and/or base radio ID via defines at the top of the sketch, but this means you can't change anything dynamically or via the program at run-time?

Could the MySensors system be enhanced to enable selection of channel number and/or base radio ID, for example in before(), so that a switch value could be read and so the radio could be configured to be set at different channel or base radio ID?

This would be a way to enable devices to be set to non-interfering channel or radio ID without a re-program? This sort of approach is used for things like wireless door-bell systems, so if the neighbour has the same setup it doesn't trigger your bell or interfere?

Thanks, Philip

From my testing, it appears that the second field is a way to enable nodes requesting an update to be individually targeted with an ID assignment response. So potentially useful if you have two or more nodes requesting a node assignment at the same time. Note that the node ID you assign (i.e. the payload value for the message) doesn't have to match the random value in the request, but you do have to use it in the response, before the next request comes, otherwise it expires.

e.g. request 255;70;3;0;3; response to send 255;70;3;0;4;22 if want to assign node ID of 22.

Note that you can alternatively use 255 for the second field value and it will accept the node update request, but that may have issues if you have more than one device requesting an ID at the same time.

Hello,

I'm trying to understand the auto assignment of ID better for controller development. Here is an example of my output at the serial port of my serial gateway. The four bottom messages of the output are the I_ID_REQUEST from the node.

0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.2.0
255;110;3;0;3;
255;63;3;0;3;
255;16;3;0;3;
255;225;3;0;3;

Can I ask why the second field of those I_ID_REQUEST messages are always changing? Is that for purposes of helping to uniquely identify requests when multiple nodes may be requesting auto assignment at the same time?

If a controller responds immediately to the I_ID_REQUEST of 255;110;3;0;3; with 255;110;3;0;4;55 for example, will it accept the response, or does it need to be 255;255;3;0;4;55 to work, i.e. the second field always needs to be 255 also?

Thanks,

For those interested in the final steps to assign the node ID...

So now I have the node in auto mode pumping out the requests to the gateway. I have also disabled the debug mode for the serial gateway sketch and see the following info at the serial output on Arduino's Serial Monitor output.

0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.2.0
255;110;3;0;3;
255;63;3;0;3;
255;16;3;0;3;
255;225;3;0;3;

The first two lines are just the gateway telling it's alive and ready to go. The following 4 lines are showing the I_ID_REQUEST messages from the node. you need to respond with the following message 255;255;3;0;4;node_id where node_id can be any value you choose between 0-254 (but obviously should be unique for your population of nodes).

Looking at the I_ID_REQUEST messages, the first field with value 255 is the special node ID which indicates it is unassigned, and why it is important (as discussed above) that you erase EEPROM to 0xFF state using the MySensors supplied ClearEepromConfig sketch.

But it is not mentioned anywhere I could find on the forum or documentation, about the value of the second field, which seems to be changed continually for each I_ID_REQUEST message. From my testing, it appears that the second field is a way to enable nodes requesting an update to be individually targeted with an ID assignment response. So potentially useful if you have two or more nodes requesting a node assignment at the same time. Note that the node ID you assign (i.e. the payload value for the message) doesn't have to match the random value in the request.

e.g. request 255;70;3;0;3; response to send would be 255;70;3;0;4;22 if want to assign node ID of 22.

I can confirm that if you respond quickly (i.e. before the next I_ID_REQUEST is sent out), mirroring that second field value, then you can update the node ID for the requesting device. If you wait until the next I_ID_REQUEST message is broadcast, then it expires and won't accept that previous ID.

Note that you can alternatively use the special value of 255 for the second field in the response, and it will accept the node update request, but that may have issues if you have more than one device requesting an ID at the same time.

Since the I_ID_REQUEST is happening too quick to read the random generated ID and then manually enter that into the Serial Monitor prompt, for testing purposes we can use the approach of using 255 as the second field value and ignore the random ID value.

So at the Arduino Serial Monitor window, first select the drop down at the bottom to add a Newline character at the end of the commands being sent, and then enter the following string in the send command input at the top of the Serial Monitor window, which requests that the new node ID should be 10.

255;255;3;0;4;10

Note that you need to click on the send button when actively receiving the I_ID_REQUEST messages, if you try sending during the long pause between the request pulses, the message will be ignored and nothing will happen.

So now you should have registered the device and start being able to see the registered node's output to the Serial Monitor. My sketch is just a simple toggling output of a binary value. The message meaning, as per the Serial API definitions is: node ID 10, outputting sensor ID 88, sending a set type message, with no acknowledgement required, message type 16 (V_TRIPPED), payload is binary on/off.

10;88;1;0;16;0
10;88;1;0;16;1
10;88;1;0;16;0
10;88;1;0;16;1
10;88;1;0;16;0
10;88;1;0;16;1

Hope that is useful for other's understanding.

@gohan Yes.

OK, my problem in getting the I_ID_REQUEST messages to appear at the serial gateway was due to my use of the Arduino supplied eeprom_clear sketch on my node device. That sketch clears EEPROM values to 0x00.

I needed instead to use the MySensors supplied ClearEepromConfig sketch which sets the EEPROM values to 0xFF (and then copy over the example dust sensor sketch).

Now the default MY_NODE_ID AUTO kicks in and pumps out the I_ID_REQUEST messages and they appear at the gateway's serial port output.

I seem to be falling at the first hurdle here. I am using the example serial gateway code and the example dust sensor code for the sensor, on NRF24 radios. I have the hardware tested and working fine with other code.

So I enable debug output with #define MY_DEBUG lines in the serial gateway and dust sensor code. I haven't defined any NODE_ID value in my dust sensor code, so it should be going to automatic mode where it should request the assignment of an ID. Note that I also erased the EEPROM to wipe out any existing ID, so it should behave just like it's a first time device. But I don't see any presentation/registration messages at the output of the gateway serial port. I only get the below output, and nothing else after that.

0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RNNGA---,VER=2.2.0
0;255;3;0;9;4 TSM:INIT
0;255;3;0;9;6 TSF:WUR:MS=0
0;255;3;0;9;14 TSM:INIT:TSP OK
0;255;3;0;9;17 TSM:INIT:GW MODE
0;255;3;0;9;20 TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;23 MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.2.0
0;255;3;0;9;28 MCO:BGN:STP
0;255;3;0;9;34 MCO:BGN:INIT OK,TSP=1

For my dust sensor I get the below output on the serial port, which looks like it's attempting to present but not getting any response back from the gateway, as expected, since there is no controller at present. But if I can't see any output at the gateway serial output, I can't interact with the gateway with my controller to send back the ID response.

| / |_ / | ___ _ __ ___ ___ _ __ ___
| |/| | | | _ \ / _ \ _ \/ __|/ _ \| _/ __|
| | | | || || | / | | _ \ _ | | _
|| ||_, |/ ___|| ||/_/|| |/
|__/ 2.2.0

16 MCO:BGN:INIT NODE,CP=RNNNA---,VER=2.2.0
26 TSM:INIT
28 TSF:WUR:MS=0
34 TSM:INIT:TSP OK
36 !TSF:SID:FAIL,ID=0
38 TSM:FAIL:CNT=1
40 TSM:FAIL:DIS
43 TSF:TDI:TSL
10047 TSM:FAIL:RE-INIT
10049 TSM:INIT
10055 TSM:INIT:TSP OK
10059 !TSF:SID:FAIL,ID=0
10061 TSM:FAIL:CNT=2
10063 TSM:FAIL:DIS
10065 TSF:TDI:TSL

I suppose I need to enable some other setting somewhere? I saw #define MY_REGISTRATION_CONTROLLER and included that in the serial gateway sketch, but it didn't seem to make any difference.

Can you point me towards what I'm overlooking to get the presentation/registration messages output at the gateway's serial port?

Thanks.

@gohan I really need a custom implementation for my needs, with a separate admin front-end from the ID assignment feature. I’m splitting up the controller functions between a RPi and web app.

Thanks

@neverdie thanks for the reply. This is the first step. Yes I’ll also need to be able to update and remove IDs, I’ll look at that after I have the assign ID function working.

I want to have a lightweight controller that sits on a RPi Zero, so planning on writing something on node.js. Interface for admin would then be via web app.

Hello,

I want to implement a bare minimum controller that assigns IDs to devices, enabling them to join the network.

I'm trying to understand this process better and hoping there are some example snippets of code demonstrating this? I couldn't find anything directly on the forum, but perhaps I wasn't searching for the right terms?

I've looked at the API descriptions and see that a device presents itself first. From my current understanding, if the device is new (and ID is not hard-coded, so assigned under auto scheme) it will have the default ID of 255? Is this therefore what the controller looks out for, and if it should see this 255 ID upon presentation, then it sends out an internal I_ID_RESPONSE type message to overwrite the node ID with an assigned ID of its choosing? Or does the MySensors library take care of this, sending out an I_ID_REQUEST message to request an ID from the controller? The controller will see that request and then responds with the I_ID_RESPONSE message, with the ID in the payload?

Thanks

@mfalkvidd The before() function only seems to allow you to do a one-off things like turn on LEDs before moving on, rather than allowing you to stay in a loop checking for the current status of the network as it starts up. When I tried that it doesn't then progress onto the main loop(). Helped getting the LED on to start with though, so thanks for that.

@mfalkvidd thanks for the reply. On the api docs page you referred me to, I saw another function called transportCheckUplink() which seems to do the necessary check for the uplink to the gateway. I added the below simple while loop to the beginning of the main loop() execution.

while (transportCheckUplink() == false){
  power_led_flash();
}

If the link to gateway is OK, then it quickly confirms and moves onto the rest of my code. If the link to gateway is lost, then it enters the while loop and flashes the LED until the link to gateway is established again. I tested by unplugging my gateway, seeing that it went into flashing mode after a few seconds, then plugged back in, and it returned to operational mode a few seconds later.

The only small problem I have left is that I can't seem to find a way to flash the LED on my node device if the gateway is not initially present, as the MySensors software seems to want to wait until it gets the link to the gateway before running the presentation(), setup() and main loop().

Is there any way to run some code before MySensors loads up, or before the initial link to the gateway is established?

Hi,

I have a basic setup of 2 nodes connected to a gateway (no controller at present). I have added the NODE-IDs, so they can connect to the gateway and send messages OK.

What I would like to do to is have an LED on each of my nodes, which flashes when powered up, but then goes solid when the connection is made to the gateway. So if there is an issue with the gateway, then the LED will flash on the node, so I can know that I've dropped out of range, or if I need to go and reset the gateway.

Is there any way I can check from the node side whether there is a current connection to a gateway device?

Thanks

Hi @Yveaux,

Thanks for the pointer. I installed the http://domoticz.com/ controller and see it all working now. I saw some mention elsewhere on this site about the gateway automatically taking care of assigning nodes etc and storing them in a local table, I assumed without any input from a controller, but I suppose it makes sense to have the controller software involved during that step also.

Thanks.

Hi,

Just got a SenseBender Gateway and separately some Arduino Nanos and nRF24L01's. I've followed the guides to wire things up and have flashed example programs. For the nano, I've flashed the DustSensor from the MySensors examples directory. I don't have any actual dust sensor connected to the analogue input pin, but I assume it will just send some value for the pin, whether it floats high or low. For the gateway I re-flashed the default SenseBenderSerial Gateway code from the examples directory. I have the latest Arduino development environment 1.8.5, and also the MySensor 2.1.1 libraries. Both devices are being powered from USB ports on my PC.

I seem to be getting some sort of comms between the sensor node and the gateway, but the sensor seems to be attempting some repeated connection and then drops out for a few seconds before trying again. I'm hoping it's something simple that the more experienced can spot from the serial comms?

Here is the Sensor node serial comms:

0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
3 TSM:INIT
4 TSF:WUR:MS=0
11 TSM:INIT:TSP OK
12 TSM:FPAR
15 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
646 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
651 TSF:MSG:FPAR OK,ID=0,D=1
2022 TSM:FPAR:OK
2023 TSM:ID
2024 TSM:ID:REQ
2027 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
4034 TSM:ID
4035 TSM:ID:REQ
4037 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
6045 TSM:ID
6046 TSM:ID:REQ
6048 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
8056 TSM:ID
8057 TSM:ID:REQ
8059 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
10068 !TSM:ID:FAIL
10070 TSM:FAIL:CNT=1
10072 TSM:FAIL:PDT
20075 TSM:FAIL:RE-INIT
20077 TSM:INIT
20084 TSM:INIT:TSP OK
20086 TSM:FPAR
20088 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
20299 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
20304 TSF:MSG:FPAR OK,ID=0,D=1
22097 TSM:FPAR:OK
22098 TSM:ID
22100 TSM:ID:REQ
22103 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
24111 TSM:ID
24112 TSM:ID:REQ
24115 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
26122 TSM:ID
26123 TSM:ID:REQ
26126 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
28133 TSM:ID
28134 TSM:ID:REQ
28137 TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
30144 !TSM:ID:FAIL
30145 TSM:FAIL:CNT=2
30147 TSM:FAIL:PDT

Here is the related SenseBender gateway serial:

0;255;3;0;9;MCO:BGN:INIT GW,CP=RNNGS--,VER=2.1.1
0;255;3;0;9;TSF:LRT:OK
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSF:WUR:MS=0
0;255;3;0;9;TSM:INIT:TSP OK
0;255;3;0;9;TSM:INIT:GW MODE
0;255;3;0;9;TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.1.1
0;255;3;0;9;MCO:BGN:STP
0;255;3;0;9;MCO:BGN:INIT OK,TSP=1
0;255;3;0;9;TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;TSF:CKU:OK,FCTRL
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;
0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;
0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;
0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;
0;255;3;0;9;TSF:MSG:READ,255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSF:MSG:BC
0;255;3;0;9;TSF:MSG:FPAR REQ,ID=255
0;255;3;0;9;TSF:PNG:SEND,TO=0
0;255;3;0;9;TSF:CKU:OK
0;255;3;0;9;TSF:MSG:GWL OK
0;255;3;0;9;TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;
0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;
0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;
0;255;3;0;9;TSF:MSG:READ,255-255-0,s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;

I've tried some things like lowering the transmit power and physically separating the devices by a couple of metres, but that didn't seem to change anything.

It seems like it is trying to reference node and child ID 255-255? But looking at the DustSensor source code I would expect it reference a node with child-ID 0 (#define CHILD_ID_DUST 0).

Can anyone spot anything obvious? Happy to provide any further info.

Thanks.