Porter 2: The Final Push
TLDR: This will be my final update before we launch Porter 2 in the next couple weeks. There’s still time to get early access with an extended trial period if you sign up today.
So, What is Porter, Again?
Porter accelerates Particle IoT development by providing a suite of common device control and monitoring functions, freeing developers to focus on building their product.
In its first iteration as a stand-alone mobile app, Porter provided an instant, customizable user interface for your hardware to expedite the repetitive testing and monitoring that happens in all projects.
In the upcoming service-based incarnation, Porter offers a desktop interface accessible from any browser, along with access to your recently published events.
A few weeks ago we rolled out our final major feature planned before launch: Actions.
Similar to Particle’s native webhooks, Actions differ by offering more finely-grained selection criteria and responses that fire push notifications, emails, or trigger http requests.
Personally, the push notifications are one of the the most engaging last mile tasks: customized push notifications from published events offer a valuable monitoring capability during IoT product development, but usually don’t feel worth the development effort while the core product is still in flux.
The following is available to Porter 2 Preview members using the latest Porter 2 mobile app.
Let’s walk through a quick example. Suppose you want a push notification when a device’s online/offline status changes.
Create a new Action and tell Porter to watch for events that contain “spark/status” in the name, and then to send a Push Notification with a title “Device [data]” and a body “[device_name] is [data]”.
If the Porter 2 mobile app is on your phone and signed in to the same Porter account, you’re all set; and, you’ll start seeing notifications like this:
Email (Still Not Dead)
Yes, there is also an email action, which works just like the push notification Action.
If you want an event to send a notification that doesn’t depend on the mobile app, eg. someone who is not you, then this is your solution. The same message customization options are available, you just need an email address.
Web Request vs Webhook
You may ask yourself, “Why would Porter replicate webhooks?”
Not an unfair question. A Porter Web Request has some subtle but important differences, and you should consider using one when:
- You require a more complex event selector. While a Particle Cloud Webhook will only match on event name, a Porter Action can match on event name, device name and event data. Also, it can match on partial strings and use numerical operators for event data.
- You want the device name — and, not just the device ID— to be included in the request.
- You want the event JSON to be sent as a request argument.
You should consider a Particle Webhook when:
- You need a Webhook Response. Porter Webhooks will not trigger a handler on your device.
- You need a Product Webhook. While Porter can broadly select by device name, it does not yet support Particle Products.
- You need to send custom JSON. Porter only sends the default event JSON.
- You’re running a high volume of requests. Porter actions are more tightly metered than Particle Webhooks.
We’re now wrapping up the less fun, but still necessary for Porter’s sustainability, parts of Porter 2 development, such as accounts, plans, and billing.
If you haven’t already, now is the best time to sign up for preview access; especially since signing up before launch will add a couple of months to your free trial.
I’m sincerely looking forward to welcoming all of you to the new Porter.