...
Repeat the process for the Thing2 pico.
Listing Subscriptions
If we were now to query the Mischief Pico to see its subscriptions, using a URL like
...
| Code Block |
|---|
{
"mischief:thing1": {
"eci": "cj0deky3l0007khpqdmo4037y",
"name": "mischief:thing1",
"type": "subscription",
"attributes": {
"subscription_name": "thing1",
"name_space": "mischief",
"relationship": "thing<->controller",
"my_role": "thing",
"subscriber_role": "controller",
"outbound_eci": "cj0deky300006khpqn7ucdvhj",
"status": "inbound",
"attributes": ""
}
}
} |
Accepting Subscriptions
There is one step remaining in the subscription process. Just because a pico offers a subscription to your pico doesn't mean that your pico is forced to accept it. This is manifest by the "status" of the subscriptions. For the originating pico, the status is "outbound" (short for outbound, pending), and for the other pico, the status is "inbound" (i.e. inbound, pending).
...
It is possible to initiate a subscription with a rule running in a pico which already has in its possession the ECI's of the two picos which need to be related by the subscription. For example, once we have set up the three child picos, Mischief, Thing1, and Thing2, we can install a ruleset into each of them and the owner pico. Simple examples are available in this repository.
The owner pico already has all of the ECI's in its array of children (maintained by the io.picolabs.pico aka Wrangler ruleset), but it doesn't know which is which. So we added this rule to allow it to distinguish between the Mischief pico (which identifies itself by ECI) and the thing picos.
| Code Block |
|---|
rule mischief_who {
select when mischief who
pre {
mischief = event:attr("eci")
things = wrangler:children().map(function(v){v.eci})
.filter(function(v){v != mischief})
}
always {
ent:mischief := mischief;
ent:things := things
}
} |
...
| Code Block |
|---|
rule mischief_subscriptions {
select when mischief subscriptions
pre {
mischief = ent:mischief
thing1 = ent:things[0]
thing2 = ent:things[1]
}
if mischief && thing1 && thing2 then
event:send(
{ "eci": mischief, "eid": "subscription",
"domain": "wrangler", "type": "subscription",
"attrs": { "name": "thing1",
"name_space": "mischief",
"my_role": "controller",
"subscriber_role": "thing",
"channel_type": "subscription",
"subscriber_eci": thing1 } } )
event:send(
{ "eci": mischief, "eid": "subscription",
"domain": "wrangler", "type": "subscription",
"attrs": { "name": "thing2",
"name_space": "mischief",
"my_role": "controller",
"subscriber_role": "thing",
"channel_type": "subscription",
"subscriber_eci": thing2 } } )
} |
The ruleset also sets up a button in the owner pico's Testing tab, "mischief/subscriptions" to send the event that causes this rule to evaluate.
...
As in the case of introductions, the other pico must have a rule selecting on wrangler/inbound_pending_subscription_added which will complete the subscription process by raising the wrangler/pending_subscription_approval event.
Writing rules that use subscriptions
Suppose that we wanted the Mischief pico to respond to a mischief/hat_lifted event and send the same event to all of the thing picos that it controls. Assuming that you have arranged to use Subscriptions as a module in the meta block, as in
...
| Code Block |
|---|
rule mischief_hat_lifted {
select when mischief hat_lifted
foreach Subscriptions:getSubscriptions() setting (subscription)
pre {
subs_attrs = subscription{"attributes"}
}
if subs_attrs{"subscriber_role"} == "thing" then
event:send(
{ "eci": subs_attrs{"outbound_eci"}, "eid": "hat-lifted",
"domain": "mischief", "type": "hat_lifted" }
)
} |
Deleting subscriptions
(to be written)
Endnotes
This page is inspired by (and often copied verbatim from) the original fourth lesson, Lesson: Pico to Pico Subscriptions.
...