I've read through several other troubleshooting threads, but those are different problems than I'm experiencing (I think).
I used codebender.cc (that tool is fantastic!) to load and work with my code on both the receiver and remote.
On the remote (garage end):Code: https://codebender.cc/sketch:166758
Serial console: Seems to be working as expected
QuoteGarageMote : 433 Mhz...
UNKNOWN
OPEN
CLOSING
CLOSED
OPENING
r
Relay test...
On the gateway:Code: https://codebender.cc/sketch:166758
QuoteGarageMote : 433 Mhz...
OPEN
CLOSED
r
Relay test...
The problem:
My understanding from looking at the sketches is that the text I see on the gateway moteino is coming from the remote moteino. If true, that tells me that the two nodes are communicating. The OPEN/CLOSED messages above show up when I powerup the gateway mote. At this point the garage side is in an indeterminate state (no magnet). However, when I move the magnet over the transducers, the messages are not showing up on the gateway. Likewise, when I issue the 'r' test, the relay on the garage mote does not click as it does when I test it directly. Finally, it does not appear that the pi is receiving OPEN/CLOSE messages from the garage mote.
Any troubleshooting tips anyone can offer?
Thanks in advance.
Hi spark,
First I would like to say the sketches on CodeBender might be out of date. Unfortunately I cannot do house keeping in multiple places, and while I also think codebender is a great tool, I don't have the resources to keep it updated, hence I keep my latest code in a single "official" place (http://github.com/LowPowerLab/).
There is already a guide that explains how to install and debug garage mote here (http://lowpowerlab.com/garagemote/#programming). So I will refer you to that and also make sure you are running the latest sketches as explained there.
If you're still having trouble please be sure to let me know in this thread.
Hi Felix,
I loaded the Arduino IDE and downloaded your libraries. Communication works as expected now! The pi/gateway is also working.
Question: I notice you have both gateway.ino and garageMote_base.ino. I am intending on adding additional nodes to the system. Should I program the receiver node with gateway.ino rather than garageMote_base.ino?
Suggestion: Can I suggest that you update the https://lowpowerlab.com/programming/ (https://lowpowerlab.com/programming/) information to recommend NOT using codebender.cc and instead using the IDE? I did try uploading the libraries as personal libraries in codebender, but the nodes still would not work as expected. I suspect that one of the #includes was not the right version. I use a MAC and had read that using the Arduino IDE was a pain on a MAC. The problems must have been resolved (or maybe it was the codebender drivers I installed)...using the IDE was no more difficult than using codebender.
In any case, thank you for your help. I read through your nodeJS code and am quite impressed with your design and style!
Good to hear you got it going. Unfortunately the IDE will probably take precedence and be the default before codebender since I get other support complaining that codebender is out of date, and I have to circle back to what I mentioned above about keeping it updated. So yes I should make time to update that.
The latest code and libraries are always kept in the Github repo and linked on the dedicated page (if any) for the respective product guide, in your case http://lowpowerlab.com/GarageMote
To answer your Q: when you use a single node and don't care about all others, there might be a sketch for that node and another received for it, that's all you need. BUT if you need to integrate that node with the rest of the "Moteino Framework" then you will need to use the default gateway sketch (https://github.com/LowPowerLab/RFM69/tree/master/Examples/PiGateway), which is expected to communicate with all other sketches for nodes like garageMote, MotionMote, SwitchMote etc etc. Basically that default sketch passes the RF packets through to the host computer via the serial port (GPIO or USB). Any messages from the host computer to a specific node (format is "[numeric nodeId] message...") will be sent to that node via RF. So this gateway node running this default sketch is just a relay between the wireless nodes and the "Moteino Gateway" (http://lowpowerlab.com/gateway) system.
You will notice there are 2 sketches in the Pi Gateway sketches repo (https://github.com/LowPowerLab/RFM69/tree/master/Examples/PiGateway). The one with LCD will also send any received messages to an attached I2C LCD for immediate display, useful for debugging or seeing the messages coming through.
Thanks for your thoughts about my nodeJS "skills". I learned a lot by doing it, so I'm sure it's full of unintentional closures and subtle javascript bugs that I haven't detected yet, but at least it seems very stable. I will continue to improve it and add features and make the gateway easier to use and more intuitive.
Quote#define RELAY_PULSE_MS 500
Everything works great on my GarageMote, the Open, Close Hall Sensors, the 433MHz transmissions and updates and the Gateway is mostly stable (the socket drops out after many hours of faithful service and the history stops over night) .
Question: I built the GM on my desk tested everything, it worked great. I connected my Fluke test probes to the switch signal "Opener" or "Relay" on the PCB. The tone fired off every time I hit the OPEN - CLOSE button on my phone or the PC. You can here the Relay "CLICK" with the default 250ms delay. I thought the Pulse needed to be longer because the RELAY is not triggering the Garage Door Unit to Open the door. I bumped it up to 500ms. Again you can here the CLICK twice as long now but no door action. I double checked the connections to the head unit. It uses the "PUSH TAB" design so only one solid core wire will fit, so I wrapped the leads from the GM-R4 around each wire three or so times for good contact then shoved it in it's hole. No Joy!
Should I "just" have continuity from the relay or should there be some measurable VDc when the Relay fires?
Whats my next trouble shooting option.
Soooo Close !!!
Lane F
I guess it depends what kind of opener you have. Mine is a simple contact closure (I think most are) and that's what GarageMote works with. I would take a piece of wire and touch the 2 contacts where your wall opener is attached, that is equivalent to you pushing your button on the wall for the door to open/close. And that's what GarageMote does for you, in addition to sensing the door position through the 2 sensors. So try to figure out what it takes for the door to open/close without the garage mote installed.
I'm in the same place. My opener is a Chamberlain Whisper Drive. It uses 24v at the contact closure, and appears to be a modulated signal from the wall switch to operate the door. I haven't had time to experiment or take it apart yet, but that is the next step in the adventure.
Spark,
I got my Chamberlain working today. I'll post what I did and some pic's tomorrow.
Thanks
LaneF
@LaneF that's awesome! Thanks for sharing!
Spark,
Working on the upload now.
Thanks
LaneF
Spark,
The pictures below tell the story.
No matter what "short" I tried with a small single piece of wire, nothing tripped this door to action. I thought about what made the door open. The coded button push in the garage was the only thing. I took it off the wall and shorted the two screws, nothing. I took off the paper back and took out the PCB. In the center was a small Momentum Button (push button). I took it off the wall and tested the four contacts to see which ones shorted then reconnected it to the wall and lightly touched them with my test wire. Bingo!
I soldered two Cat5 Wires to the small PCB, hooked it back up and touched the two brown wires and it worked. I ran a new set of doorbell wire from the motor where the GarageMote was located from the relay points on the board back to the new brown wires. My Pulse delay is on 300ms. Works.
Good Luck
Lane F
Lane,
Nice detective work, why they make these so complicated these days I don't know. Everything is getting so "smart" ..
Thanks for sharing your findings.
Interesting...makes total sense. Thanks for figuring this out!
So @LaneF, I'm reporting back to say that your fix worked for my garage door also. I was fortunate to already have a 4-pair wire running from the wall to the opener.
I do notice something strange with my system. There are some timing bugs to be worked out. When I open/close my garage door, the controller gets confused on the state of the garage door as the magnets pass by on the way to open/close. For example, from CLOSED, I see OPENING, CLOSED, OPENING. Once the door is OPEN, the LED on the controller indicates the right state of OPEN. However, the web software says OPENING (sometimes CLOSED). Hitting refresh on the web site updates the correct status. I think I need to change the timing in the loop to only change the status to OPEN/CLOSED if it remains in that state for a period of time. In addition, for a door, I think I'd feel more comfortable if the gateway polls the status of the door every few minutes to ensure it has the correct status.
spark,
You should not have to do anything or implement polling. I've seen such situations when the belt or chain starts to drift a little bit in one direction and the magnet is not very close to the sensor. That's where the's a few changes of state between a OPEN-CLOSING or CLOSED-OPENING. So every few weeks or maybe 2 months or when I remember I check where the magnets align and adjust them on the velcro to make sure they are centered with the sensors. That's also another reason why with R2 I started shipping longer rectangular magnets which have more linear surface than smaller round magnets, to help the sensor latch the status.
Thanks, Felix. The problem is just timing rather than the position of the magnets. The loop is simply detecting a new change too quickly as the door is moving. In addition, the current sketch is "manually" changing the STATUS upon receiving a command over the radio, rather then allowing the "state engine" to calculate the current status.
I rewrote how this works and consolidated the logic into a function. If the new status is OPEN or CLOSED, I added a delay loop to be sure everything is settled before actually changing the status. This seems to be rock solid and much more stable for my installation. Finally, for peace-of-mind, I added a timer to send the current status to the gateway every so often.
I submitted a pull request to you in case you are interested in incorporating.
Thanks for the contribution, i will review.