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: