Can't receive parent answer
-
Hi,
Trying to integrate a basic node but it seems it isn't "hearing" the GW.
It boots up nicely, starts the signing backend and radio encryption. Then, it tries to find a parent, the gateway answers but it seems it isn't "heard" by the node.The node is 2m away from the gateway, I've tried different RFM69HW modules and different PCBs (slim node PCB).
The node is a slimnode with internal 8MHz clock. Other nodes are working fine with the GW.Any idea what can be wrong?
__ __ ____ | \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___ | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __| | | | | |_| |___| | __/ | | \__ \ _ | | \__ \ |_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/ |___/ 2.3.2 16 MCO:BGN:INIT NODE,CP=RPNNAS-X,FQ=8,REL=255,VER=2.3.2 40 SGN:PER:OK 75 SGN:INI:BND OK 77 TSM:INIT 79 TSF:WUR:MS=0 81 TSM:INIT:TSP OK 83 TSM:INIT:STATID=34 86 TSF:SID:OK,ID=34 88 TSM:FPAR 90 SGN:SGN:NREQ=255 2095 ?TSF:MSG:SEND,34-34-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 4102 !TSM:FPAR:NO REPLY 4104 TSM:FPAR 4106 SGN:SGN:NREQ=255 6109 ?TSF:MSG:SEND,34-34-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 8116 !TSM:FPAR:NO REPLY 8118 TSM:FPAR 8120 SGN:SGN:NREQ=255 10123 ?TSF:MSG:SEND,34-34-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 12130 !TSM:FPAR:NO REPLY 12132 TSM:FPAR 12134 SGN:SGN:NREQ=255 14139 ?TSF:MSG:SEND,34-34-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 16146 !TSM:FPAR:FAIL 16148 TSM:FAIL:CNT=1 16150 TSM:FAIL:DIS 16152 TSF:TDI:TSL 26155 TSM:FAIL:RE-INIT 26157 TSM:INIT 26159 TSM:INIT:TSP OK 26161 TSM:INIT:STATID=34 26165 TSF:SID:OK,ID=34 26167 TSM:FPAR 26169 SGN:SGN:NREQ=255 28174 ?TSF:MSG:SEND,34-34-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 30181 !TSM:FPAR:NO REPLY 30183 TSM:FPAR 30185 SGN:SGN:NREQ=255 32190 ?TSF:MSG:SEND,34-34-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 34197 !TSM:FPAR:NO REPLY 34199 TSM:FPAR 34201 SGN:SGN:NREQ=255 36206 ?TSF:MSG:SEND,34-34-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 38213 !TSM:FPAR:NO REPLY
Dec 06 19:28:25 DEBUG TSF:MSG:READ,34-34-255,s=255,c=3,t=7,pt=0,l=0,sg=0: Dec 06 19:28:25 DEBUG TSF:MSG:BC Dec 06 19:28:25 DEBUG TSF:MSG:FPAR REQ,ID=34 Dec 06 19:28:25 DEBUG TSF:CKU:OK,FCTRL Dec 06 19:28:25 DEBUG TSF:MSG:GWL OK Dec 06 19:28:26 DEBUG SGN:SGN:NREQ=34 Dec 06 19:28:30 DEBUG !TSF:MSG:SEND,0-0-34-34,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0 Dec 06 19:28:33 DEBUG TSF:MSG:READ,34-34-255,s=255,c=3,t=7,pt=0,l=0,sg=0: Dec 06 19:28:33 DEBUG TSF:MSG:BC Dec 06 19:28:33 DEBUG TSF:MSG:FPAR REQ,ID=34 Dec 06 19:28:33 DEBUG TSF:CKU:OK,FCTRL Dec 06 19:28:33 DEBUG TSF:MSG:GWL OK Dec 06 19:28:34 DEBUG SGN:SGN:NREQ=34 Dec 06 19:28:38 DEBUG !TSF:MSG:SEND,0-0-34-34,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
#define MY_DEBUG //!< Enable debug prints to serial monitor // RADIO STUFF #define MY_RADIO_RFM69 //!< RFM69 radio driver #define MY_RFM69_NEW_DRIVER #define MY_RFM69_FREQUENCY RFM69_433MHZ #define MY_IS_RFM69HW #define MY_RFM69_ENABLE_ENCRYPTION //#define MY_DEBUG_VERBOSE_RFM69 // SIGNING STUFF // Select soft/hardware signing method #define MY_SIGNING_SOFT //!< Software signing //#define MY_SIGNING_ATSHA204 //!< Hardware signing using ATSHA204A // Enable node whitelisting //#define MY_SIGNING_NODE_WHITELISTING {{.nodeId = #define MY_SIGNING_REQUEST_SIGNATURES //!< destination node signs all messages sent to this node // SETTINGS FOR MY_SIGNING_SOFT //#define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 //!< Unconnected analog pin for random seed // SETTINGS FOR MY_SIGNING_ATSHA204 #ifndef MY_SIGNING_ATSHA204_PIN #define MY_SIGNING_ATSHA204_PIN 17 //!< A3 - pin where ATSHA204 is attached #endif #define MY_DEBUG_VERBOSE_SIGNING //!< Enable signing related debug prints to serial monitor #define MY_NODE_ID 34 #include <MySensors.h> #define LOCK_1 3 //!< Arduino Digital I/O pin number for first lock (second on pin+1 etc) #define NOF_LOCKS 2 //!< Total number of attached locks #define LOCK_LOCK 1 //!< GPIO value to write to lock attached lock #define LOCK_UNLOCK 0 //!< GPIO value to write to unlock attached lock void setup() { for (int lock=1, pin=LOCK_1; lock<=NOF_LOCKS; lock++, pin++) { // Set lock pins in output mode pinMode(pin, OUTPUT); // Set lock to last known state (using eeprom storage) digitalWrite(pin, loadState(lock)?LOCK_LOCK:LOCK_UNLOCK); } } void presentation() { // Send the sketch version information to the gateway and Controller sendSketchInfo("Secure Lock", "1.0"); // Fetch lock status for (int lock=1, pin=LOCK_1; lock<=NOF_LOCKS; lock++, pin++) { // Register all locks to gw (they will be created as child devices) present(lock, S_LOCK, "SecureActuator", false); } } /** @brief Sketch execution code */ void loop() { } /** * @brief Incoming message handler * * @param message The message to handle. */ void receive(const MyMessage &message) { // We only expect one type of message from controller. But we better check anyway. // And echoed messages are not accepted as control messages if (message.getType()==V_LOCK_STATUS && message.getSensor()<=NOF_LOCKS && !message.isEcho()) { // Change relay state digitalWrite(message.getSensor()-1+LOCK_1, message.getBool()?LOCK_LOCK:LOCK_UNLOCK); // Store state in eeprom saveState(message.getSensor(), message.getBool()); // Write some debug info Serial.print("****\n\nIncoming change for lock:"); Serial.print(message.getSensor()); Serial.print(", New status: "); Serial.println(message.getBool()); Serial.print("\n\n****\n"); } }
-
@joaoabs I might not have been clear in the other thread (https://forum.mysensors.org/topic/11465).
Slim Node does not route RFM69-signal DIO0 (interrupt) to Arduino-pin D2 (INT0) (at least PCB version 1.4).
Have you added a trace for this signal?
-
@frits I think you are right!
I admit initially I didn't thought it could be that because I have a slim node working 100%, but after your comment, I checked it and there is in fact a shunt between INT0 and DIO0 (I must have done it last year or so and didn't remember). The other nodes I've been trying don't have it, so that's likely the case.
Maybe the slim node page could have some reference to this?
I'll solder some shunts and will re-try this evening, but I'm sure that was the problem.
My slim nodes PCB's are red, but were ordered in 2018. Not sure what PCB release they are, though.
Thank you very much!
-
@joaoabs said in Can't receive parent answer:
Maybe the slim node page could have some reference to this?
I totally agree, the IRQ line should be routed, also for nrf24 modules. Could you propose this in the slimnode maker's thread?