We’re opening our product to distributors, which is leading to a lot of photons needing to be programmed. I’m using the publish and subscribe functions to send and receive data between the two, but this is becoming extremely time consuming (changing two lines of code per photon x2 photons x multiple products). Does anyone have any ideas to streamline this process and keep from crossing signals?
Sooh, a bit more detail on what you are after would be helpful…
The event names don’t have to be hard coded.
You can use the device IDs, device names or even dynamic event names that you set via a Particle.function() and store in EEPROM.
Loads of ways, but so little info in your request.
1 Like
My product sends wiegand data through the cloud, when you swipe a card it publishes an event name carrying the data where the other end picks up that event name, and the data, and feeds it to the controller. I’m looking for a simpler way to carry the data through the cloud to the other device.
That’s not quite the info we needed to answer your actual question.
You already have the solution for the inter-device communication, but now you asked how to pair devices and for that we need to know how do you want them paired.
How will you organise the the two devices as part of the one project?
Will the users need to have the devices claimed to their own Particle account?
Will you have these organised as product group devices?
How do you intend to set the devices up?
Or should the users do that themselves?
If user-setup how do you intend to have the user do that?
…
Have you considered any of the suggestions in my post?
If the two devices are sold in pairs, you could create a Particle.function() that accepts its partners device ID as an argument.
int updateParticlePartner(String command) {
Particle.unsubscribe();
char deviceID[64];
strcpy(deviceID, command.c_str());
EEPROM.put(someAddress, deviceID);
Particle.subscribe(deviceID, myHandler, MY_DEVICES);
}
and in your setup, retrieve your partner device from EEPROM before you call subscribe…
Kind of thing.
1 Like
I’m not sure whether the Particle.subscribe() will actually be applied when put there
and int updateParticlePartner() should return an int.
1 Like
Ah ok, I think we got confused. I was wondering if there was a way to take the place of the publish and subscribe functions to make sending the data more efficient when getting everything programmed to send out. The devices would all be on my account.
What do you mean by that?
Where have you got it now and where do you want it moved to?
If you want to replace the communication entirely with your own logic.
An experienced developer certainly could do that.
But in doing so one would immediately lose the default encryption and have to explicitly incorporate that security layer (which isn't a simple task) and then need to lay out the communication substitute as TCP or UDP communication.
IMO, that might well be a bit too big a chunk to swallow for you.
2 Likes
you see
Yup, and my comment was meant to reduce the kind-of-thinginess 
1 Like
You’re absolutely right, implementing something like that is beyond my knowledge right now. I was curious if there was a way to completely replace the publish and subscribe functions (only because of the amount of time involved in changing each devices code) while maintaining the basic functionality it provides. This may not be possible, but I thought I would ask more experienced people than myself.
Is it possible to hardcode the publish and subscribe the same on every device and have them ignore every one except it’s mate id or something similar?
The suggestions you had got further up by @BulldogLowell and myself would already have provided the solution to your riddle.
I’ll have more time to read through everything when I get home from work. I’ve been trying to glance through and at least respond when I can in between job sites. As usual, thanks for the help @ScruffR and @BulldogLowell
I’ve been going over @BulldogLowell s code, I am wondering what you meant by
I’m not sure whether the Particle.subscribe() will actually be applied when put there
Since I have the two linked in the code, would I not use Particle.subscribe?
So, if it doesn't properly subscribe, just save the partner device ID to EEPROM and restart the Photon.
2 Likes
I read over the docs about writing to EEProm, this is going to be my first time writing to it, but it looks like your code pretty much covers everything aside from the “myHandler” function.
In:
Particle.subscribe(deviceID, myHandler, MY_DEVICES);
the deviceID would be the partner ID correct?
As previously stated, there are many ways to address this need. What I’d offer for consideration would be to set up a database (MySQL for example) and have records for each device indicating its partner’s DeviceID. In addition, you could have the customer’s name or some form of ID so you could easily search for the devices associated with each customer. As each Photon powers up, in its setup() function, it would first do a particle.subscribe() to an event (more in just a sec). It would then make a particle.publish() call to an API you’d write in something like PHP which would do a SQL search for the record associated with that device’s ID and return (create the aforementioned event) the partner ID that’s in the record. You could also send along any other parameters that may be desirable to have being somewhat dynamic (ex period for publishing data to each other).
Yes, this is more complicated and requires more work, but it does provide quite a bit of flexibility and allows you to easily change partner ID’s should a device need swapped in the field. You don’t have to have either device powered up in order to make partner changes – or any other parameter changes you set up.
And yes, it does require having a host service for the API and you do have to develop the code on the host for the API and any other table maintenance you desire.
I use this strategy for many Particle devices in the field and it works very gracefully.
4 Likes
we are using this and it works extremely well this way!
1 Like
I like the idea of automatically searching for its partner ID, but this is similar to what we’re doing now, without the external database, and it’s just too time consuming. Also, we’re only selling in pairs so non paired replacements arent an issue.