Learning Objectives
After completing this lesson, you will be able to do the following:
- Understand pico-to-pico relationships and subscriptions
- Use the developer tools to manage pico subscriptions
- Link two or more picos with a subscription programmatically and have them interact.
Prerequisites
You should have already completed the following lessons:
(Classic) Quickstart lesson. (Be able to register and install rulesets)
Events & Queries lesson. (Be able to create channels and understand how events are raised on channels)
Pico-Based Systems lesson. (Be able to manage the pico lifecycle using Devtools and programmatically)
- Read Wrangler Subscriptions description.
Subscriptions
Subscriptions play an important role in building systems of picos. In the lesson on Pico-based Systems, you created child picos. If the parent-child relationship was the only one that existed, we could create hierarchies of picos, but not peer-to-peer systems of picos. Subscriptions allow us to establish relationships between any two picos.
A subscription represents a relationship between two picos. It has a name and two channels, one from each pico participating in the subscription to the other. Each side in the subscription can be given a role to further identify the purpose of the subscription.
Subscriptions Using Devtools
To begin, let's use Devtools to create a subscription between the Thermostat and TempSensor picos we created in the Pico-based System lesson.
First, we navigate to the Thermostat pico and click on the "Subscription" button. The click the "New Subsciption" button and you'll see a screen like this:
...
Clicking "Unsubscribe" either here or in the TempSensor pico would delete the subscriptiion from both.
Managing Subscriptions Programmatically
Wrangler provides functions, actions, and rules for managing subscriptions from within your KRL code.
To begin, I created a new ruleset called child_subscriptions, registered it, and installed it in the TempSensor and Thermostat picos I created earlier.
Listing Subscriptions
First, let's write a function to show us our subscriptions. The Wrangler function subscriptions() does that and we could call it directly since Wrangler is installed in the pico, but let's wrap it in our own function and remove the status message. Usually, you'd be doing further processing on the subscription list. Here's our function to just return the subscriptions in the Closet namespace:
...
Remember that for this to work, we have to have used the wrangler module, aliasing it to wrangler, set sharing on, and provided the module.
Introducing the Thermostat to the TempSensor
Let's build a rule that allows a pico to introduce itself to another pico. Since it's in our Closet collection, we'll default some of the normal attributes required in a subscription. And since this is a self-introduction, we can raise the wrangler:subscription event on the internal event bus:
...
Wrangler does much of the heavy lifting in managing subscriptions. The introduce_myself rule simply stated that a subscription was needed and Wrangler not only created the pending outbound subscription for the TempSensor, but also sent an event to the subscription provider, Thermostat, so that a pending inbound subscription could be created there. Then, when we approved the subscription in Thermostat, Wrangler again, made the job easy. Wrangler made the pending inbound subscription into a subscription, created a channel for the subscriber (TempSensor) to use, sent an event to the subscriber with the new channel, and changed the subscription in TempSensor from outbound.
Deleting a Subscription
We delete a subscription between two picos in a similar manner. The following rule shows how to use Wrangler to do that:
...