Posts made by linus72982

I had SimpliSafe for a while and the batteries last a long time (3 1/2 years, no battery change for me in any sensor) -- but the base station, even after a reset, still seems to know when a door sensor is open or closed. I had thought about using the IRQ pin on the radio to wake up the node when a status request was sent, but most people here were saying this is terrible for battery life. How the heck is SimpliSafe keeping batteries lasting for almost 4 years (and maybe longer) but still retain the functionality of detecting what state a sensor is in?

Is it maybe that they have the sensors wake up and report every minute or something? I thought about doing that, 1 second of every 60 seconds powered up shouldn't have too much battery impact, should it?

@hek

Thanks -- one other quick question: am I right in assuming a child sensors will only ever send "set" message types and will only be routed "req" types?

For example, I'll never see a message like this:

3; 3; 3; 0; 9; etc

right? Nodes would send that sort of message, but never a child:

3; 255; 3; 0; 9; etc

yes? I'm assuming this because most nodes just report a setting or get set to something, they don't have any intelligence beyond that, that all exists on the child's node.

Nevermind, I figured it out (sort of). I deleted the serial port from device manager and then checked for hardware updates which reinstalled it. It then worked just fine for one iteration, but the serial monitor showed BinarySwitchSleepSensor output instead of gateway output. And then stopped working. I deleted it again, reinstalled the port, and immediately uploaded the gateway sketch back to it. Now it works great. My guess is that the binary sketch somehow messed up the serial comm when on the Nano? Not sure, but that fixed it. I must have forgotten to switch the port # when I was reuploading the binary sketch to my node and accidentely uploaded it to the gateway port.

Everything worked last night. Then I came home on lunch today and when I tried to open the serial monitor to my gateway, I get nothing in the screen and this error:

Error while setting serial port parameters: 155,200 n 8 1

I tried reseating the usb cable on both ends, reset the gateway, restarted the computer, and reuploading the sketch, and even uninstalled arduino and reinstalled -- none of that did anything. I have the board set correctly to "Nano" and the com port correct (verified by removing, checking, and reattaching). The 155,200 is obviously the baud, and I've always used that for the gateway. I tried a few other bauds (9600, etc) and still nothing.

I haven't tried a few other things like trying it on another computer yet because I ran out of time and am now back at work.

I literally didn't even touch the gateway, it just started doing this, does anyone know what this error is?

Nevermind, I think I figured it out. In the Library API it says:

On Nano/Pro Mini: 0=Pin2, 1=Pin3

Which means that minus 2 would turn pin 2 to 0 and pin3 to 1 -- I feel like an idiot. What's that dash do? Lol. It's a minus and it uses the pin number to get the proper interrupt #.

Leaving this here in case anyone in the future has this issue.

I only have one sensor attached to my node, so I changed the BinarySwitchSleepSensor example to only recognize one. I changed PRIMARY_BUTTON_PIN to BUTTON_PIN, changed PRIMARY_CHILD_ID to CHILD_ID, erased SECONDARY_BUTTON_PIN and SECONDARY_CHILD_ID, and then deleted the portions referring to the secondaries. But I'm stumped on the last line in the sketch:

sleep(PRIMARY_BUTTON_PIN-2, CHANGE, SECONDARY_BUTTON_PIN-2, CHANGE, 0);

Presumably, I can just delete ", SECONDARY_BUTTON_PIN-2, CHANGE" and switch the PRIMARY_BUTTON_PIN-2 to BUTTON_PIN-2 and it will work, but I'm wondering what the "-2" at the end of BUTTON_PIN is. Does the -2 do something on the function end that I'm not seeing. I want to make sure that isn't a number I need to fiddle with (I'm guessing not as both PRIMARY and SECONDARY are -2). Thanks.

Oh, and the Library API doesn't mention what that -2 does, I already checked.

Edit -- wait a minute, is that a minus?

@Koresh
Where on this knock-off version do I disconnect the regulator? The pic they give for that in the Build section is also for a different layout. I already bricked one pro mini because I cut both sides of the LED on accident (but don't worry, on my second attempt on a new pro mini, I got just the one lead and it worked) so I don't want to brick another

The serial gateway will restart sometimes, such as when you open a serial connection. The problem I'm having is that there doesn't seem to be any information propagated from the gateway when it starts up referring to nodes connected. I'm writing a controller and would like to determine which sensors are on after the gateway restarts. Is there a way to do this without pinging every possible sensor? If the node itself restarts, I see the info just fine, it reports a registration, etc, but not when the gateway restarts. Thanks ahead of time.

@tekka
That's good info, thank you. Quick question if you have a minute, what is the difference between CHKUPL and SANCHK? Based on the docs, they both seem to accomplish the same goal.

The picture in the Battery-Powering section of the site shows a different layout for the pro mini than I have. Mine looks like this:

Can anyone show me where to cut the power LED at? The LED is just to the left of the Atmel in the middle. Also, what kind of tool are you using for such a small task?

I'm trying to write a controller and am trying to account for fringe cases. Say the power turns off and then comes back on and both the gateway and sensor start simultaneously -- will the gateway always report its full startup before it receives node messages? I would assume the gateway won't respond to the find parent until after it's fully initialized, but I just want to make sure. This will help me determine when I need to create certain objects in the controller.

@tekka
Thanks for the explanation of the messages, that helped me quite a bit. I figured out that my gateway radio wasn't working very well so I bought an Addicore version that the reviews said was a bit more reliable. It came in today and works like a champ (and it has labeled pins which is helpful).

I eagerly await the documentation of the messages. I am writing a controller in Python and with my limited C knowledge (weird, I know, as Python is a C-based language, but it's just different enough to drive me nuts), I'm going cross-eyed trying to reverse-engineer the messages from the code. Your documentation will help immensely. Just the bit you told me up there has allowed me to write most of it. Thanks, again.

Also, after running for a bit, I get this from the gateway:

0;255;3;0;9;TSP:MSG:READ 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSP:MSG:BC
0;255;3;0;9;TSP:MSG:FPAR REQ (sender=3)
0;255;3;0;9;TSP:CHKUPL:OK
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;!TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=fail:0
0;255;3;0;9;!TSP:SANCHK:FAIL
0;255;3;0;9;!TSM:FAILURE
0;255;3;0;9;TSM:PDT
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSM:RADIO:OK
0;255;3;0;9;TSM:GW MODE
0;255;3;0;9;TSM:READY
0;255;3;0;9;TSP:MSG:READ 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSP:MSG:BC
0;255;3;0;9;TSP:MSG:FPAR REQ (sender=3)
0;255;3;0;9;TSP:CHKUPL:OK
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;!TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=fail:0
0;255;3;0;9;!TSP:SANCHK:FAIL
0;255;3;0;9;!TSM:FAILURE
0;255;3;0;9;TSM:PDT
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSM:RADIO:OK
0;255;3;0;9;TSM:GW MODE
0;255;3;0;9;TSM:READY
0;255;3;0;9;TSP:MSG:READ 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSP:MSG:BC
0;255;3;0;9;TSP:MSG:FPAR REQ (sender=3)
0;255;3;0;9;TSP:CHKUPL:OK
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=ok:0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;TSP:MSG:PINGED (ID=3, hops=1)
0;255;3;0;9;TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=ok:1
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
0;255;3;0;9;!TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=fail:0100
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=0,t=17,pt=0,l=5,sg=0:2.0.0
3;255;0;0;17;2.0.0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0
3;255;3;0;6;0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=11,pt=0,l=13,sg=0:Binary Sensor
3;255;3;0;11;Binary Sensor
0;255;3;0;9;!TSP:SANCHK:FAIL
0;255;3;0;9;!TSM:FAILURE
0;255;3;0;9;TSM:PDT
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSM:RADIO:OK
0;255;3;0;9;TSM:GW MODE
0;255;3;0;9;TSM:READY
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK

and this from the pro mini:

TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-3 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=3)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 0-0-3 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
TSP:MSG:SEND 3-3-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=11,pt=0,l=13,sg=0,ft=0,st=fail:Binary Sensor
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=1,st=fail:1.0
!TSP:MSG:SEND 3-3-0-0 s=3,c=0,t=0,pt=0,l=0,sg=0,ft=2,st=fail:
!TSP:MSG:SEND 3-3-0-0 s=4,c=0,t=0,pt=0,l=0,sg=0,ft=3,st=fail:
Request registration...
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=4,st=fail:2
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=5,st=fail:2
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
Init complete, id=3, parent=255, distance=255, registration=1
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR

the !TSP:SEND:TNR messages at the end happen each time I open or close the sensor.

I keep having a few problems that I can't figure out. I think they are related, but I'm not entirely sure. I have the Nano Compatible as my serial gateway connected to the NRF24L01+PA+LNA Antenna version radio with a 4.7uf cap (ground connected to the white strip side) using the 2.0 GatewaySerial example (unchanged). I have it shielded the radio with the "ugly fix", the tin foil attached to ground. I checked the pins for continuity, nothing is touching the ground. On the sensor side, I have a pro mini 3.3v connected via the ftdi adapter to another usb port. The radio is the NRF24L01+ 2.4GHz Wireless Transceiver with a 47uf cap (yes, 47 for this and 4.7 for the other, I found references to use both in different places, of course, if my electronics classes serve me, it doesn't matter if I go bigger, it should still work, right?) Connected is a magnetic open/close sensor. This guy is running the 2.0 BinarySwitchSleepSensor (unchanged).

What I've tried: Replacing the pro mini with another, replacing the pro mini's radio (twice), replacing all cables (dupont cables), replacing caps, moving the node further away from the gateway (to the adjacent room).

I don't have a controller, so I've hard-coded (I think) the node ID and parent id with #define MY_NODE_ID 1 and #define MY_PARENT_NODE_ID 0 for the gateway, then the same with node # 3 and parent #1 for the node. The goal is to write my own controller but I need to get these working first.

So, when I start the two monitors up within a few seconds of each other (gateway first), here's the output of the gateway:

0;255;3;0;9;Starting gateway (RNNGA-, 2.0.0)
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSM:RADIO:OK
0;255;3;0;9;TSM:GW MODE
0;255;3;0;9;TSM:READY
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.0.0
0;255;3;0;9;No registration required
0;255;3;0;9;Init complete, id=0, parent=0, distance=0, registration=1
0;255;3;0;9;TSP:MSG:READ 3-3-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSP:MSG:BC
0;255;3;0;9;TSP:MSG:FPAR REQ (sender=3)
0;255;3;0;9;TSP:CHKUPL:OK
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;!TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=fail:0
0;255;3;0;9;!TSP:SANCHK:FAIL
0;255;3;0;9;!TSM:FAILURE
0;255;3;0;9;TSM:PDT
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSM:RADIO:OK
0;255;3;0;9;TSM:GW MODE
0;255;3;0;9;TSM:READY

Here was the output of the pro mini over the same time:

Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT

To my untrained eye, it looks like the gateway sees the node as it says FPAR req'd sender=3, but then it looks like the fpar fails? I don't even know what FPAR is and I can't find anything on the site that allows me to decode these messages, only the 0;255;3;0;9 which is logging.

Can anyone see what I'm doing incorrectly?

A quick related question:

If I add the router antenna, I shouldn't get any increased range or anything unless I up the power, in which case I'll have to tweak the radio component to handle it, correct? So, now I'm wondering if this is even worth it other than for looks and how nicely it fits into the case. Also, if I wanted to use both of the router antennas, would I have to boost the power even further or just split it?

I took apart an old Linsys WRT45G 1.1 router I had laying around and decided to use that to enclose my gateway. It's big, but I like it for nostalgia purposes. The antennae on the back are much larger and connect to a much larger connector -- I'd like to use them because they fit in the holes that are already there. They are both 2.4GHz -- is there anything I should be aware of before I switch my little sma antenna out for this larger?

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

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.

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.

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:

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.

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?

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.

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?

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.

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;
  }
} 

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?

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?

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

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.

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.

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?

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

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.

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?