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

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.. :smile:
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

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

21

11.7k

11.2k

113.0k