Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: more updated

...

Code Block
http://localhost:8080/sky/event/cj0dea39q0001khpqy4su0ru3ME9i5bo26xFPEUp9yBHUbq/subscr/wrangler/subscription?
wellKnown_Tx=cj0dea81g0003khpqy7j9knqzGTrQY4dzrkr7n39Lezp9mf&
Rx_role=controller&
Tx_role=thing&
name=thing1&
channel_type=subscription

Your URL will be different because the ECI to which the event is sent (in the example, cj0dea39q0001khpqy4su0ru3ME9i5bo26xFPEUp9yBHUbq) needs to be replaced by the main ECI of your Mischief Pico, and the wellKnown_Tx parameter needs to indicate the ECI of your Thing1 Pico.

A new channel is created in each of the two picos involved, whose name and channel_type are indicated as such. We indicate the role that the picos involved in the subscription will each play (my_role and subscriber_role).

When you visit this URL, the wrangler/subscription event will be sent to the Mischief Pico and the subscription will be created. The ruleset in each child pico will approve the subscription request. This will result in each of the two picos involved having a subscription. Each of them will also have a new channel, especially created for use with the subscription. Here is the new channel created for the Thing1 pico:

...

Code Block
http://localhost:8080/sky/cloud/cj0dea39q0001khpqy4su0ru3ME9i5bo26xFPEUp9yBHUbq/io.picolabs.subscription/established

we would see that it participates in two subscriptions:

Code Block
[
  {
    "Rx_role": "controller",
    "Tx_role": "thing",
    "wellKnown_TxRx": "GTrQY4dzrkr7n39Lezp9mfY3dpMrT12b5EzNKmdFsUKR",
    "RxTx": "5aEtRXKB2uM6WXWbPtgySsUHD1ku5PraSmRFq6zk9dwo"
  },
  {
    "Rx_role": "controller",
    "Tx_role": "thing",
    "wellKnown_TxRx": "GTrQY4dzrkr7n39Lezp9mf7mkCJX1v3394umHtLuT2Gh",
    "RxTx": "SLebvDm7d9MTQzBNqPn8nRLGdgeySNYRdwtnP9y9yJ1n"
  }
]


Similarly, the Thing1 Pico participates in just one subscription. Doing the same sky/cloud query to its ECI will show something like this:

Code Block
[
  {
    "Rx_role":"thing",
    "Tx_role":"controller",
    "Tx":"SLebvDm7d9MTQzBNqPn8nRY3dpMrT12b5EzNKmdFsUKR",
    "Rx":"Qn2oh1pe6aXbkyLVcr9L9bUHD1ku5PraSmRFq6zk9dwo"
  }
]

Accepting Subscriptions

Note
titleEngine compatibility

The portion of this lesson which follows refers to an older version of the io.picolabs.subcription ruleset


There is one step remaining in the subscription process. Just because one pico offers a subscription to another pico doesn't mean that target 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).

...