@sundberg84 , sorry, I meant I did not burn the bootloader and was not aware of that.

Did you mean "reset capacitator", not resistor?

And on that note, am I right that reset to iscp should go to DTS contact?

thanks for help.

@sundberg84 said in 💬 In Wall AC/DC Pcb (with Relay) for MySensors (SMD):

header?

No, I did not. I used to work with arduinos, so this is the first time I bought and try mega328p. could you advise where to find a resource with step-by-step instructions on that?

hi, I get constantly messages Arduino: 1.8.5 (Linux), Board: "Arduino Pro or Pro Mini, ATmega328P (5V, 16 MHz)"
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xde
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x4c
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x9d
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xaa

is this hardware problem? I select Arduino Pro Mini board setting with AVRISP mkII programmer. are these ok?

@annujbhatia , did you manage to connect it right? I have the same challenge as I have 9 zones.

https://www.arduino.cc/en/Tutorial/ShiftOut should be the guidance I suppose

@mfalkvidd ,

I guess I am talking about software ACK's (though not sure).

But, as @itbeyond advised, I downgraded to 2.2.0, recompiled and problems dissapeared. Log is clean, NACK's no more.

@yveaux said in nrf24 : transmission of data works fine, but constant NACK's produced:

e

I kind of do not quite understand why it can be that transmission is reliable in my case within 25-30 metres distance (node and GW communicate reliably), but NACK's appear when distance is over 5-6 metres?

@mfalkvidd ,

I have no repeaters. I tried to experiment to answer your questions. I went to the ~15 meters distance where GW shows peristent NACK's.

I understand the normal scenario is, that node send a message, GW receives the message, GW send ACK to node, node receives ACK from gateway. it should be the end of transaction?

GATEWAY LOG ENTRIES:

0;255;3;0;9;477668 TSF:MSG:READ,250-250-0,s=0,c=1,t=48,pt=3,l=2,sg=0:225
0;255;3;0;9;477674 TSF:MSG:ACK REQ
0;255;3;0;9;477713 !TSF:MSG:SEND,0-0-250-250,s=0,c=1,t=48,pt=3,l=2,sg=0,ft=0,st=NACK:225
250;0;1;0;48;225
0;255;3;0;9;478752 TSF:MSG:READ,250-250-0,s=0,c=1,t=48,pt=3,l=2,sg=0:226
0;255;3;0;9;478758 TSF:MSG:ACK REQ
0;255;3;0;9;478797 !TSF:MSG:SEND,0-0-250-250,s=0,c=1,t=48,pt=3,l=2,sg=0,ft=0,st=NACK:226
250;0;1;0;48;226
Channel:76 PaLevel:MAX DataRate:250KBPS
0;255;3;0;9;480967 TSF:MSG:READ,250-250-0,s=0,c=1,t=48,pt=3,l=2,sg=0:228
0;255;3;0;9;480973 TSF:MSG:ACK REQ
0;255;3;0;9;481013 !TSF:MSG:SEND,0-0-250-250,s=0,c=1,t=48,pt=3,l=2,sg=0,ft=0,st=NACK:228
250;0;1;0;48;228

This is what a node shows for the same transmissions:

LOG FROM NODE
124526 TSF:MSG:SEND,250-250-0-0,s=0,c=1,t=48,pt=3,l=2,sg=0,ft=0,st=OK:225
124533 TSF:MSG:READ,0-0-250,s=0,c=1,t=48,pt=3,l=2,sg=0:225
124538 TSF:MSG:ACK
125067 TSF:MSG:SEND,250-250-0-0,s=0,c=1,t=48,pt=3,l=2,sg=0,ft=0,st=OK:226
125074 TSF:MSG:READ,0-0-250,s=0,c=1,t=48,pt=3,l=2,sg=0:226
125079 TSF:MSG:ACK
125625 !TSF:MSG:SEND,250-250-0-0,s=0,c=1,t=48,pt=3,l=2,sg=0,ft=0,st=NACK:227
126171 TSF:MSG:SEND,250-250-0-0,s=0,c=1,t=48,pt=3,l=2,sg=0,ft=1,st=OK:228
126179 TSF:MSG:READ,0-0-250,s=0,c=1,t=48,pt=3,l=2,sg=0:228
126184 TSF:MSG:ACK

message "226" - a node sent message, GW received it, GW sent ACK and node received ACK. Why GW entry shows NACK? What I am missing?

When we look at node entry "227", a node sent a message, GW did not receive it (there is no entry in GW log), so node did not receive the ACK from GW. this all makes sense.

Hi all,

I use arduinoUno as serial gateway, nrf24 for radios.

I find this strange, that overall reliable data transmission distance is probably ~30 meters, through the walls. so mysensors reliably send data to GW and actuators receive commands.

But I can not use ACK required feature, as in the logs I see systematically NACK's. for troubleshooting I used nrf24doctor sketches ( https://forum.mysensors.org/topic/9178/nrf24doctor )

So what I find is:

When I am at ~7m range, I nrf24doctor node shows no faults and gateway produces all nice log entries like this:

250;0;1;0;48;17
0;255;3;0;9;227401 TSF:MSG:READ,250-250-0,s=0,c=1,t=48,pt=3,l=2,sg=0:18
0;255;3;0;9;227408 TSF:MSG:ACK REQ
0;255;3;0;9;227418 TSF:MSG:SEND,0-0-250-250,s=0,c=1,t=48,pt=3,l=2,sg=0,ft=0,st=OK:18

But when distance increases by one-two meters, mesages are received, but the log on the GW consistently shows NACK's:
250;0;1;0;48;322
0;255;3;0;9;558810 TSF:MSG:READ,250-250-0,s=0,c=1,t=48,pt=3,l=2,sg=0:323
0;255;3;0;9;558817 TSF:MSG:ACK REQ
0;255;3;0;9;558856 !TSF:MSG:SEND,0-0-250-250,s=0,c=1,t=48,pt=3,l=2,sg=0,ft=0,st=NACK:323

The same pattern stays when we increase distance further, - messages are received (within ~25-30 meters distance I find 1-2% of faults, but 99% messages go through).

So do I understand this right, that my node manages to deliver to gateway the message with payload, but fails to deliver the ACK? What could be explanation behind?

@Technovation , thanks for diagnostics tool. Could you help to interpret the results what I get?

When I am at ~7m range, I nrf24doctor node shows no faults and gateway produces all nice log:

250;0;1;0;48;17
0;255;3;0;9;227401 TSF:MSG:READ,250-250-0,s=0,c=1,t=48,pt=3,l=2,sg=0:18
0;255;3;0;9;227408 TSF:MSG:ACK REQ
0;255;3;0;9;227418 TSF:MSG:SEND,0-0-250-250,s=0,c=1,t=48,pt=3,l=2,sg=0,ft=0,st=OK:18

When distance increases, nrf24doctor node shows 1-2 percent of faults, but the log on the gateway consistently shows NACK's:

250;0;1;0;48;322
0;255;3;0;9;558810 TSF:MSG:READ,250-250-0,s=0,c=1,t=48,pt=3,l=2,sg=0:323
0;255;3;0;9;558817 TSF:MSG:ACK REQ
0;255;3;0;9;558856 !TSF:MSG:SEND,0-0-250-250,s=0,c=1,t=48,pt=3,l=2,sg=0,ft=0,st=NACK:323

So do I read it right way, that my node manages to deliver to gateway the message with payload, but fails to deliver the ACK?

How that works? How do I understand results like this?

thanks,

Where to find a sketch with temperature read?

I see in logs, that the whole process of signing and communicating to the node takes a bit more than one second. I do not know how to make a stress test properly, so I hoped that somebody else did it :) my question is if gateway will handle load by putting messages in some pipeline, or I should try to make sure that messages are fired with some spaces.

Are there performance limitations to be considered for mysensors and SensebenderGW specifically. Will the gateway handle the load of signed communications if rules will be firing messages to different sensors like 1-2-5-10 per second?

@Anticimex yes, when I delete #include atsha driver line, it compiles well. thanks.

When I try to compile SensebenderGW sketch with signing features, I receive a bunch of errors. What am I missing?

Arduino: 1.8.5 (Windows Store 1.8.10.0) (Windows 10), Board: "Sensebender Gateway"

In file included from C:\Users\rzylius\AppData\Local\Temp\arduino_modified_sketch_737033\SensebenderGatewaySerial.ino:88:0:

C:\Users\rzylius\Documents\Arduino\libraries\MySensors/drivers/ATSHA204/ATSHA204.cpp:6:16: error: redefinition of 'uint8_t device_pin'

static uint8_t device_pin;

            ^

In file included from C:\Users\rzylius\Documents\Arduino\libraries\MySensors/MySensors.h:131:0,

             from C:\Users\rzylius\AppData\Local\Temp\arduino_modified_sketch_737033\SensebenderGatewaySerial.ino:86:

C:\Users\rzylius\Documents\Arduino\libraries\MySensors/drivers/ATSHA204/ATSHA204.cpp:6:16: error: 'uint8_t device_pin' previously declared here

static uint8_t device_pin;

            ^

In file included from C:\Users\rzylius\AppData\Local\Temp\arduino_modified_sketch_737033\SensebenderGatewaySerial.ino:88:0:

C:\Users\rzylius\Documents\Arduino\libraries\MySensors/drivers/ATSHA204/ATSHA204.cpp: In function 'void swi_set_signal_pin(uint8_t)':

C:\Users\rzylius\Documents\Arduino\libraries\MySensors/drivers/ATSHA204/ATSHA204.cpp:24:13: error: redefinition of 'void swi_set_signal_pin(uint8_t)'

static void swi_set_signal_pin(uint8_t is_high)

         ^

In file included from C:\Users\rzylius\Documents\Arduino\libraries\MySensors/MySensors.h:131:0,

             from C:\Users\rzylius\AppData\Local\Temp\arduino_modified_sketch_737033\SensebenderGatewaySerial.ino:86:

C:\Users\rzylius\Documents\Arduino\libraries\MySensors/drivers/ATSHA204/ATSHA204.cpp:24:13: error: 'void swi_set_signal_pin(uint8_t)' previously defined here

static void swi_set_signal_pin(uint8_t is_high)

         ^

and the same type of errors reoccurs multiple times.

@mfalkvidd , yes, I see. As I wrote in the first post I was using https://github.com/mysensors/MySensors/tree/development/examples/SecurityPersonalizer code.

I checked with the Personizer code in the Library examples - it does compile, thanks.

What I find a bit confusing - in the sketch in exampla library you have to make two keys - USER_SOFT_KEY and USER_KEY (when you do not use hw hashing, and when you do).

I have mixed configurations. Should those keys be the same in my network for mixed configuration to work?

thanks for help and sorry for confusion

@mfalkvidd I tested now on my windows machine with fresh install of arduino185. Mysenors library 2.1.1 , mysensors SAMD boards.

the same outcome

Arduino: 1.8.5 (Windows Store 1.8.10.0) (Windows 10), Board: "Sensebender Gateway"

Build options changed, rebuilding all
C:\Users\rzylius\Documents\Arduino\SecurityPersonalizer\SecurityPersonalizer.ino: In function 'void write_eeprom_checksum()':

SecurityPersonalizer:697: error: 'EEPROM_PERSONALIZATION_CHECKSUM_ADDRESS' was not declared in this scope

  hwWriteConfigBlock((void*)&hash[0], (void*)EEPROM_PERSONALIZATION_CHECKSUM_ADDRESS, 1);

                                             ^

C:\Users\rzylius\Documents\Arduino\SecurityPersonalizer\SecurityPersonalizer.ino: In function 'void probe_and_print_peripherals()':

SecurityPersonalizer:1327: error: 'unique_id_t' was not declared in this scope

  unique_id_t uniqueID;

  ^

SecurityPersonalizer:1327: error: expected ';' before 'uniqueID'

  unique_id_t uniqueID;

              ^

SecurityPersonalizer:1352: error: 'uniqueID' was not declared in this scope

  if (hwUniqueID(&uniqueID)) {

                  ^

SecurityPersonalizer:1352: error: 'hwUniqueID' was not declared in this scope

  if (hwUniqueID(&uniqueID)) {

                          ^

exit status 1
'EEPROM_PERSONALIZATION_CHECKSUM_ADDRESS' was not declared in this scope

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

hi,

I am having trouble to compile security personalizer sketch for Sensebender GW
https://github.com/mysensors/MySensors/tree/development/examples/SecurityPersonalizer

I receive error log. any advise?

regards, rimantas

Arduino: 1.8.5 (Linux), Board: "Sensebender Gateway"

/root/Arduino/SecurityPersonalizer_v11/SecurityPersonalizer_v11.ino: In function 'void write_eeprom_checksum()':
SecurityPersonalizer_v11:697: error: 'EEPROM_PERSONALIZATION_CHECKSUM_ADDRESS' was not declared in this scope
  hwWriteConfigBlock((void*)&hash[0], (void*)EEPROM_PERSONALIZATION_CHECKSUM_ADDRESS, 1);
                                             ^
/root/Arduino/SecurityPersonalizer_v11/SecurityPersonalizer_v11.ino: In function 'void probe_and_print_peripherals()':
SecurityPersonalizer_v11:1327: error: 'unique_id_t' was not declared in this scope
  unique_id_t uniqueID;
  ^
SecurityPersonalizer_v11:1327: error: expected ';' before 'uniqueID'
  unique_id_t uniqueID;
              ^
SecurityPersonalizer_v11:1352: error: 'uniqueID' was not declared in this scope
  if (hwUniqueID(&uniqueID)) {
                  ^
SecurityPersonalizer_v11:1352: error: 'hwUniqueID' was not declared in this scope
  if (hwUniqueID(&uniqueID)) {
                          ^
exit status 1
'EEPROM_PERSONALIZATION_CHECKSUM_ADDRESS' was not declared in this scope

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

The problem dissapeared when I changed 4.7uf capacitator to 47uf. works great!

Hi,

it is very cool project. I assembled one but when I test it this is what I get:

16:18:39.980 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:READ,101-101-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
16:18:39.981 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:BC
16:18:39.982 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:FPAR REQ,ID=101
16:18:39.985 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:PNG:SEND,TO=0
16:18:39.988 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:CKU:OK
16:18:39.993 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:GWL OK
16:18:40.963 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;Will not sign message for destination 101 as it does not require it
16:18:41.004 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;!TSF:MSG:SEND,0-0-101-101,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
16:18:41.010 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:READ,12-12-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
16:18:41.013 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:PINGED,ID=12,HP=1
16:18:41.018 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;Skipping security for command 3 type 25
16:18:41.029 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:SEND,0-0-12-12,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:1
16:18:44.038 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:READ,101-101-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
16:18:44.039 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:BC
16:18:44.040 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:FPAR REQ,ID=101
16:18:44.041 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:CKU:OK,FCTRL
16:18:44.044 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:GWL OK
16:18:44.974 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;Will not sign message for destination 101 as it does not require it
16:18:45.016 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;!TSF:MSG:SEND,0-0-101-101,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0

I guess it shows that radio has unreliable power. Please advise how should I debug?

regards

I have the same situation - mysensors relay node can not find parent. I cleared eeprom and entered manually MY_NODE_ID, but it seems that gateway and node communicate, but fail to make final arrengement.

Gateway log:
22:54:33.173 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;Will not sign message for destination 102 as it does not require it
22:54:33.216 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;!TSF:MSG:SEND,0-0-102-102,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
22:54:34.691 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:READ,102-102-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
22:54:34.692 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:BC
22:54:34.694 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:FPAR REQ,ID=102
22:54:34.697 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:CKU:OK,FCTRL
22:54:34.701 [DEBUG] [orsAbstractConnection$MySensorsReader] - Message from gateway received: 0;255;3;0;9;TSF:MSG:GWL OK

MySensors node log:
91296 TSM:INIT
791303 TSM:INIT:TSP OK
791305 TSM:INIT:STATID=102
791308 TSF:SID:OK,ID=102
791310 TSM:FPAR
791347 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
793354 !TSM:FPAR:NO REPLY
793356 TSM:FPAR
793393 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
795400 !TSM:FPAR:NO REPLY
795402 TSM:FPAR
795439 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
797446 !TSM:FPAR:NO REPLY
797448 TSM:FPAR
797485 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
799492 !TSM:FPAR:FAIL
799494 TSM:FAIL:CNT=7
799496 TSM:FAIL:PDT
859499 TSM:FAIL:RE-INIT
859501 TSM:INIT
859508 TSM:INIT:TSP OK
859510 TSM:INIT:STATID=102
859513 TSF:SID:OK,ID=102
859515 TSM:FPAR
859552 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
861559 !TSM:FPAR:NO REPLY
861561 TSM:FPAR
861598 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
863605 !TSM:FPAR:NO REPLY
863607 TSM:FPAR
863644 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
865651 !TSM:FPAR:NO REPLY
865653 TSM:FPAR
865690 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
867697 !TSM:FPAR:FAIL
867699 TSM:FAIL:CNT=7
867701 TSM:FAIL:PDT

any ideas what I have to check?

regards,

rimantas