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.

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?

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

That works, and is a lot shorter!

Thanks

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.

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.

@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){}
}

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,