After working on an Ubidots solution for a while it is looking increasingly important we investigate Losant as another potential platform to power of Particle based IoT product, it seems to be evolving far quicker and more importantly has Particle integration baked in. I have some potentially silly questions, sorry!
To try Losant out I have moved one of our production prototype boards to a new “Product” and followed the Particle Integration tutorial, I can get the integration to connect if I leave the product ID blank, but if I try to include it it won’t connect.
Clearly I’m missing a step here what other details do I need to include to connect to a specific product only?
Other questions/details
Because we have been using Ubidots/Webhooks we have been working with Devices that are registered to our account as device ownership is pretty meaningless to Ubidots. This may or may not be the way to go with Losant with its deeper Particle integration.
We have multiple events we would like to subscribe to with this integration, however I’m not exactly a strong JS programmer is there a way to identify which event we are splitting up in the Losant Function block of the workflow?
The device is marked on the Particle Console as a development device …
1 Like
For your first question, I’m going to dig into working with the “product” field and see if I can figure out what is going on. Our integration maps to the Get Event Stream Particle API call, but I don’t have a lot of knowledge on how Particle “product” grouping works, so I’m going to try it out with some particle electrons here in the office and see what I can reproduce.
For your other question - the information that is included in the Particle Trigger has what you need. In the case of a Particle trigger, the data property on the payload is an object with a couple properties of its own, two of which you will care about. data.name is the exact name of the Particle event - so even if you subscribed to a wildcard event string in the Losant Particle integration, you will have the exact name of the event here. data.coreId is the the ID of the device in Particle that sent the event. Using those two pieces of information, and other nodes like the conditional or switch nodes in a workflow, you should be able to take different paths based on the exact source and kind of event that is coming in.
Hope that helps, and I’ll try to get back to you later this week with more information on using the “Product” field
Thanks for that I will give it a go.
Hey @spacetc62, I’m experiencing a similar problem to to @Viscacha. When I enter a product ID, the integration fails. I can think of a few other ways to filter my incoming events, but this seems like the Particle way of filtering devices, which I’d like to stick to if possible!
Let me know if there’s been any progress on this. Thanks for your help! 
1 Like
We finally took at look at the issues with setting the product field. Turns out our automatic defaulting of “mine” for the device field is invalid when combined with the product field, so we will be removing that defaulting in our next release. We are also adding more information to connection errors for Particle integrations, which is helpful because the default Particle auth token for a user account (that you can get on the “settings” tab of the Particle cloud editor) is not valid when working with products - I’ve found you actually have to generate a new access token (using either the api or the cli tool, doesn’t seem to be a way to do it in the web interface).
When we release the change on our side, I will let you know, and you can try to use the product field again.
1 Like
Thanks for that. The Particle “product” feature seems to be in a very fast production cycle, hard to keep up!
We have released the update on our side - so you should be able to give this a try again!
1 Like