Holy crap, thanks @rickkas7! I didn’t expect you guys to write this for me, for me that’s part of the learning process. But this is awesome, I’ll get it flashed and tested this week.
5 Likes
I was getting an error compiling the “Sender” firmware, double checked everything, and ended up modifying this:
#include "SparkIntervalTimer/SparkIntervalTimer.h"
to this:
#include "SparkIntervalTimer.h"
Just wanted to check before I made a mistake, is there something I’m missing about having both of those in there?
An important thing to know for us is how you are building.
e.g. @rickkas7’s code was built with Particle Build (aka Web IDE), hence the include with lib path, but you seem to be using CLI or Particle Dev which need the include “flat” (without path).
I usually use this to have code easily build for both ways
#define xPARTICLE_BUILD // add or remove the leading x to select
#if defined(PARTICLE_BUILD)
# include "libName/libName.h"
#else
# include "libName.h"
#endif
2 Likes
I always compile using the web IDE, it’s the best way for me to work with multiple computers. Now I’m wondering what could be different, haha.
How did you include those libraries, using the library system or the little ‘+’ icon? That could explain the difference.
I used the “+” icon this time.
Yup, then the respective files get put in the folder alongside the main .ino, but if you import the lib as intended, it’ll end up in its own subfolder, relative to the main .ino.
Hence being exact about your used IDE and how you are doing things is crucial for us to be told, our 
foo is not that strong 
1 Like
I had some issues with my photons, so I wasn’t able to get this tested as soon as I had hoped, I was on it first thing this morning, and flashed the firmware successfully, hooked everything up but there doesn’t seem to be communication between the two photons, or maybe I’m looking at it wrong. The reader seems to publish the event and data fine, I can see it in the console, but nothing from the other side. Also the number its showing on the console doesn’t match up with the number printed on the card I’m using, console shows: 57978266, card number is: 22221.
Here is the console with the publish and data on it:
If you’re using my code, the number in the event won’t correspond to the number printed on the card. It’s the raw Wiegand format, which contains 1 parity bit, the facility code (not printed in a readable way on the card), the card number (printed on the card), and 1 more parity bit. The receiver code has the formula to decode it.
2 Likes
I’m using your code, the only thing I changed was the event name, just so I could have some logic to it from my end, I’ve changed it in both codes. The other photon doesn’t seem to be picking it up or it is picking it up but not pushing it out. I’ve got another controller here, I’m going to swap them out just to eliminate my Doorking board being bad.
Swapped controllers, everything works fine with my wiegand controller, I connected the cardreader directly to the controller, both work fine.
There’s a Serial print in the sender, is that printing? If you don’t have it connected by serial, I’d put a publish with a different event name there so you can see if it triggers.
Can I view that in the console or should I pull up my terminal? I just hooked everything back up, swiped my card to make sure it was publishing ok, and my controller activated, unfortunately I wasn’t paying attention to it to see what was going on, but I can’t duplicate it now.
Ok, scratch that, I found a loose wire, connected but loose, everything seems to work fine. This is an awesome project and I can’t thank you guys enough for the support on this.
2 Likes
I wan to thank all of you guys for the help on this, especially @rickkas7 for the code. I installed the first setup today, on site time was less than an hour and it works perfectly. Thanks again.
1 Like