Can't figure out what I'm doing wrong with test setup

[linus72982]

I'm trying to test everything out before I build a bunch of sensors, but I can't seem to get any output at the serial monitor in the arduino program. Here's my setup (I'm not sure I set everything up correctly, I tried to follow the directions as well as I could):

Nano and NRF24L01+PA+LNA Antenna version - connected exactly how the guy in the youtube getting started video did it. That said, I had a slightly different version of the radio as mine wasn't labeled and didn't have white squares, so I assume they are pinned the same? Also, I included the capacitor between GND and VCC with the white stripe to GND (4.7uF).

Then I connected 5V and GND from the nano's 6 pin interface section to a pro mini at the top connections (TX0, RX1, VCC, GND) to VCC and GND to power it for testing. The pro mini is then connected to a NRF24L01+ 2.4GHz Wireless Transceiver as shown in the "Wiring it up" section. I then connect the door open/close sensor to GND and pin 3 on the pro mini as shown in the binary sensor page.

The nano has the SerialGateway example installed and the pro mini has the BinarySwitchSleepSensor example installed.

So, I plug in the nano via USB to my computer and then pull up the arduino program and go to Serial Monitor for COM3 (where the nano is plugged in) -- I get one output and it always seems to be some unicode character and two digits. And then nothing else. I pull the magnets on the sensor apart, nothing. I'm not sure what I'm doing incorrectly. Can anyone assist?

[AWI]

@linus72982 have you set the right baud rate in the serial monitor? Please post a picture of your setup and sketch

[mfalkvidd]

Welcome @linus72982 Great to have you here!

Are you using a 3.3 or 5V pro mini? It sounds like you are powering the pro mini with 5V on Vcc. If the pro mini is 3.3V it needs to be powered with 5V or higher through the RAW pin, or 3.3V on the Vcc pin.

Which speed are you using for the serial monitor? Try using 115200.

The most common problems and instructions on how to read the serial debug output is available in https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help

Start with getting the gateway to start properly (it will say when it has started on the serial output). When that is done, connect the pro mini to serial and start looking at the output. Post the output here if you need help reading it.

[linus72982]

Okay, the serial monitor baud wasn't set correctly, changing it to 115200 allowed me to see the data -- the gateway is starting up, but still nothing from the sensor. My pro mini is a 3.3V, I have it powered via 5V from the Nano currently to the VCC pin -- it sounds like I need to switch that to the RAW pin. I'll do that after work and if I still can't get anything, I'll post some pics.

[mfalkvidd]

Great progress

Giving the Pro Mini 5V might have killed it, so be aware of that when you troubleshoot. If the power led lights up when you give it 3.3V you have a good start

[linus72982]

I connected to the RAW input instead, the red LED still comes on so hopefully I didn't torch it (if I did, I have 9 others). Anyway, still no output, just Gateway started in the serial monitor. Here are some pics of the setup:

http://imgur.com/a/vQlkK

The first two pics are either side of the gateway radio.

The next one is of the nano.

The next two are the connections to the radio from the pro mini

The last two are both sides of the pro mini

[mfalkvidd]

I don't see a capacitor on the radio for the pro mini.

What does the serial output from the pro mini say?

[linus72982]

Okay, I made a lot of progress with your guys' help. I added a capacitor and checked the output from the pro mini. It said Radio Init Failed or something similar. I checked for that error and it looks like bad power or wiring. I tried rewiring and checking power -- nothing wrong, so I switched out the radio and that seemed to work. Now when I check the serial monitor for the nano, I get this:

0;0;3;0;9;gateway started, id=0, parent=0, distance=0
0;0;3;0;14;Gateway startup complete.

like usual, but now I also get this when I separate the magnets:

0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;
0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;
0;0;3;0;9;read: 255-255-0 s=255,c=3,t=3,pt=0,l=0,sg=0:
255;255;3;0;3;

So, one more problem left -- I only ever can get three outputs from separating and repairing the magnets. Those three above. Thereafter, I get nothing when I separate even if I wait for minutes. I try to separate and repair a few different times, tried waiting in between each, still nothing after the first three. When I restart the serial monitor, I get three more, but no more after that.

Thanks so much for your help so far, I'm getting close -- any ideas about this last glitch? Is that just a problem with the serial monitor or is it a problem with my setup?

[linus72982]

I wrote up a python serial reading script and figured out that I only ever can get one response for separating the magnets before it stops, so it can't be the arduino serial monitor as I just tested it on my own and still it stalls out. Not sure if there's a setting for this somewhere in the sketch or what.

[martinhjelmare]

The message read by the gateway was an internal message of subtype 3, which is a request for node id. The node will send this message if no manual node id is set in the sketch. If using automatic node id, a controller needs to be connected to the gateway, and the controller needs to be able to hand out node ids.

Read about this on the api page on the mysensors web.

[linus72982]

So, the actual message is a subtype 9, trace-log a message and it's sending "read: 255-255-0 s=255,c=3,t=3,pt=0,l=0,sg=0: 255;255;3;0;3;" correct? So, it's trace-logging a node-id request? The thing is, these messages only happen when I separate or re-pair the magnet sensors.

Two questions: Is this a normal message -- I mean, is everything working well? I don't care how node-ids get passed out. I assume the serial gateway example sketch has it handing out node-ids?

If everything is working well -- how do I get my sensor open/closed messages? I don't seem to be getting those. I know the sensor is doing something as the trace-log messages only happen when I trigger the sensor.

I'm not sure where to go from here.

[AWI]

@linus72982 You need a "controller" to issue node id's. If you don't have one you can assign a fixed id. This will allow your sketch to move on and show it's real Tricks.

[linus72982]

I have the nano connected to the gateway radio -- isn't that the controller?

[linus72982]

If I do fixed ID's, where do I do that? I assume I do that in the BinarySwitchSleepSensor sketch, I'm just not sure where. It looks like there is already a PRIMARY_CHILD_ID and SECONDARY_CHILD_ID assigned (3 and 4 respectively). Is that what those are?

[linus72982]

Okay, I tooled around and figured it out. I assigned a manual id in the begin() on the pro mini. But, I still have a problem:

I get the sensor open and closed messages just fine -- for about 30 seconds. After that, I get nothing through the serial port. I restart the serial monitor and I can get 30 seconds more. I opened my Python script and same thing. I get about 10 seconds of messages on that. I'm not sure what's going on here. Does anyone else know?

[mfalkvidd]

@linus72982 said:

I have the nano connected to the gateway radio -- isn't that the controller?

The nano is the gateway.

See https://www.mysensors.org/about/network for a description of the different parts. https://www.mysensors.org/controller/ has a list of supported controllers.

[mfalkvidd]

@linus72982 said:

Okay, I tooled around and figured it out. I assigned a manual id in the begin() on the pro mini. But, I still have a problem:

I get the sensor open and closed messages just fine -- for about 30 seconds. After that, I get nothing through the serial port. I restart the serial monitor and I can get 30 seconds more. I opened my Python script and same thing. I get about 10 seconds of messages on that. I'm not sure what's going on here. Does anyone else know?

Great progress!
My guess would be a power problem or an error in the sketch. Could you post your sketch so we can take a look?

[linus72982]

Ahh, I got a bit tripped up in the terminology. The controller is my computer. I'm going to be using a custom python script to control, I'm using the gateway as a sort of dongle from the radio network to the computer. Either way, I prefer the hard-coded node-ids so handing out IDs is moot now, anyway.

So, to my problem, it can't be power because everything works again when I restart the serial controller. It also works more when I stop and restart my python serial monitor. It's weird, there is no communication from the computer to the gateway when I restart the monitor so I don't think it can be anything in the gateway at all, it has to be from the USB, operating system of the computer (win 10), or the monitors (unlikely because I'm using two different ones). It's almost like there's a timeout on the port or something.

In any case, here's the sketch in case my reasoning above isn't sound and there is something there that is affecting operation (this sketch is, literally, just the example SerialGateway from MySensors but with the added arguments in the begin() line:

/**
 * The MySensors Arduino library handles the wireless radio link and protocol
 * between your home built sensors/actuators and HA controller of choice.
 * The sensors forms a self healing radio network with optional repeaters. Each
 * repeater and gateway builds a routing tables in EEPROM which keeps track of the
 * network topology allowing messages to be routed to nodes.
 *
 * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
 * Copyright (C) 2013-2015 Sensnology AB
 * Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors
 *
 * Documentation: http://www.mysensors.org
 * Support Forum: http://forum.mysensors.org
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 *
 *******************************
 *
 * DESCRIPTION
 *
 * Simple binary switch example 
 * Connect button or door/window reed switch between 
 * digitial I/O pin 3 (BUTTON_PIN below) and GND.
 * http://www.mysensors.org/build/binary
 */


#include <MySensor.h>
#include <SPI.h>
#include <Bounce2.h>

#define CHILD_ID 3
#define BUTTON_PIN  3  // Arduino Digital I/O pin for button/reed switch

MySensor gw;
Bounce debouncer = Bounce(); 
int oldValue=-1;

// Change to V_LIGHT if you use S_LIGHT in presentation below
MyMessage msg(CHILD_ID,V_TRIPPED);

void setup()  
{  
  gw.begin(NULL, CHILD_ID, false);

 // Setup the button
  pinMode(BUTTON_PIN,INPUT);
  // Activate internal pull-up
  digitalWrite(BUTTON_PIN,HIGH);
  
  // After setting up the button, setup debouncer
  debouncer.attach(BUTTON_PIN);
  debouncer.interval(5);
  
  // Register binary input sensor to gw (they will be created as child devices)
  // You can use S_DOOR, S_MOTION or S_LIGHT here depending on your usage. 
  // If S_LIGHT is used, remember to update variable type you send in. See "msg" above.
  gw.present(CHILD_ID, S_DOOR);  
}


//  Check if digital input has changed and send in new value
void loop() 
{
  debouncer.update();
  // Get the update value
  int value = debouncer.read();
 
  if (value != oldValue) {
     // Send in the new value
     gw.send(msg.set(value==HIGH ? 1 : 0));
     oldValue = value;
  }
} 

[linus72982]

I did a little reading and found out my earlier statement that there is no communication between the computer and the gateway when I start the serial monitor is incorrect. Starting a connection resets the board, auto-reset. I know this is happening because there is a green led blink when I click on the serial monitor.

So, now there are more options for what it could be -- I'll check power and some other things and come back. Let me know if there's anything in the sketch that looks like it could be doing it. I don't know C well at all.

[AWI]

@linus72982 what does the serial monitor on your node show when you strart the node now. Any radio failures?
Your sketch looks fine.

[linus72982]

The monitor only shows Gateway Startup Complete or whatever the initial message is. I don't have two of the cables needed so I can't check the pro mini at the same time. If I check the pro mini, then I can't get power to gateway.

I checked power to the pro mini, the pro mini's radio, and the nano's radio -- all good, even after I "time it out".

I noticed one thing, though -- after a reset, I can go for many minutes without triggering the sensor but once I do, I only get one sensor trigger before it stops reporting. If I start triggering the sensor immediately after a reset, I can get about 5 seconds of triggering before it stops reporting. If I do REALLY fast triggering of the sensor on and off I can go indefinitely. Weird?

[linus72982]

Also, keep in mind, I can only start getting data again after a timeout by resetting the nano. Even if I reset it manually with the same serial monitor left open, I can get data back by triggering the sensors -- but again, only for a few seconds. If I reset the pro-mini, I don't get data back, just the nano.

[linus72982]

Just a thought -- does the nano require I respond that I'm receiving the messages? As I'm only monitoring and not sending anything, could it just time out sending it if I don't tell it I'm still listening? Being that I'm not yet using a controller, if it does require some sort of response, could that be the problem?

[AWI]

@linus72982 it sounds a little confusing..
Let's start again.

The nano is your serial gateway node. The pro mini is your sensor node.
The MySensors protocol needs a communication between two nodes to work. So both the nodes must be switched on.
As far as I can see your gateway seems to function. So connect that to a powered usb port (or charger). Then connect the pro mini to a serial monitor (with ftdi) and tell us what it is doing.

[linus72982]

Yes, both nodes were switched on -- what I was saying was that I don't have two of the mini-USB cables, just one that came with the FTDI. So, if I have it plugged into the nano to power everything, I can't see the pro mini's output. If I have it plugged into the pro mini, I can't power the nano unless I move around some cables. I will head to the store in a bit and grab another usb cable in a bit and let you know the output of both.

[linus72982]

Okay, I got another cable and now have the pro-mini's output:

It starts up and does this automatically:

send: 3-3-0-0 s=255,c=3,t=15,pt=2,l=2,sg=0,st=fail:0
send: 3-3-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=fail:1.5.4
send: 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=fail:0
sensor started, id=3, parent=0, distance=1
send: 3-3-0-0 s=3,c=0,t=0,pt=0,l=0,sg=0,st=fail:
send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:0

Then, when I trigger the sensor open:

send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:1
find parent
send: 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:

Then closed:

send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:0

And opened again:

send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:1

After a few opens/closes, I get the find parent again:

find parent
send: 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,st=bc:

[AWI]

@linus72982 as expected, there is no radio contact between the node and gateway. If the node can't find a parent node (gateway) it will keep on searching. Make sure the radio is working by following the flowchart mentioned by @mfalkvidd.

[linus72982]

Will do and I'll get back to you.

Curious though, there does seem to be some comm between the two because I get triggers for about 5 seconds. If it doesn't find a parent, it stops sending? Maybe hardcoding a parent id would work? I'll try a few things.

[linus72982]

@AWI

Okay, I followed the chart and couldn't find anything specific. I switched out the pro mini for a new one, I switched out the radio attached to the pro mini, and I added a hard-coded parent to the pro mini. After I hard-coded the parent, I stopped getting the find parent messages, but the nano still stops reporting the sensor triggers after 5 seconds or so. But, again, I can keep the nano reporting the triggers indefinitely if I trigger if very fast on and off. It almost seems like an acknowledge problem or something. So, here's the output of the nano with me tripping the sensor a few times:

0;0;3;0;9;gateway started, id=0, parent=0, distance=0
0;0;3;0;14;Gateway startup complete.
0;0;3;0;9;read: 3-3-0 s=3,c=1,t=16,pt=2,l=2,sg=0:1
3;3;1;0;16;1
0;0;3;0;9;read: 3-3-0 s=3,c=1,t=16,pt=2,l=2,sg=0:0
3;3;1;0;16;0
0;0;3;0;9;read: 3-3-0 s=3,c=1,t=16,pt=2,l=2,sg=0:1
3;3;1;0;16;1
0;0;3;0;9;read: 3-3-0 s=3,c=1,t=16,pt=2,l=2,sg=0:0
3;3;1;0;16;0
0;0;3;0;9;read: 3-3-0 s=3,c=1,t=16,pt=2,l=2,sg=0:1
3;3;1;0;16;1
0;0;3;0;9;read: 3-3-0 s=3,c=1,t=16,pt=2,l=2,sg=0:0
3;3;1;0;16;0
0;0;3;0;9;read: 3-3-0 s=3,c=1,t=16,pt=2,l=2,sg=0:1
3;3;1;0;16;1

Here's the output of the pro mini to start (no sensor tripping):

send: 3-3-0-0 s=255,c=3,t=15,pt=2,l=2,sg=0,st=fail:0
send: 3-3-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,st=fail:1.5.4
send: 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,st=fail:0
sensor started, id=3, parent=0, distance=1
send: 3-3-0-0 s=3,c=0,t=0,pt=0,l=0,sg=0,st=fail:
send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:0

And then a few sensor trips does this on the pro mini:

send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:1
send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:0
send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:1
send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:0
send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:1
send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:0
send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:1
send: 3-3-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,st=fail:0

I'm not sure how to read the send messages as there doesn't seem to be documentation on the API page for these, just the receive messages. I'm not sure what st=fail means.

For reference, I hard-coded the pro mini ID as 3 and the parent to talk to on the pro mini as 0 with this line:

gw.begin(NULL, CHILD_ID, false, 0);

because the SerialGateway sketch has this line:

gw.begin(incomingMessage, 0, true, 0);

and from what I read, that means that the gateway is set to ID 0, but then the second zero should be setting the parent to 0 also. So it's its own parent? I'm not sure. Either way, I'm not sure where I'm going wrong. I really do appreciate all your help, I just want to get one up and working so I can make some more.

[AWI]

@linus72982 You are getting there..
The st:fail part of the message indicates a failure to send. This is based on a low level acknowledgement between the radio's. In most cases these fails result from power/hardware problems.
You mentioned an amplified radio for the gateway. The specifically are prone to unpredictable behavior. (search for 'the ugly fix' or nrf24l01+pa+lna) or replace it with a standard radio for testing.

[linus72982]

So, it works now. Weird.

I swapped out for a radio without the antenna and replaced the capacitor just in case (the leads were getting wavy). The little antenna worked, but very intermittently, there were many misses. So, I put the radio with the antenna back to try some of the "fixes" for them like the ugly fix and powering externally. Well, I put it back and it works now. I moved the antenna back where it was sitting and still worked. Restarted a few times, still works. Not sure what was going on but I'm guessing it was either a bad capacitor or I had it mis-wired somehow as I completely redid the wiring when I swapped them.

Thanks very much for your time. I know I was annoying as hell, I appreciate you sticking with me

[AWI]

@linus72982 thanks. Now let the fun begin and share your idea's