Objective

The objective of this lab is to learn

• pico-to-pico subscriptions
• how to manage them programatically.

Subscriptions allow you to create networks of peer-to-peer picos and move beyond the hierarchical parent-child relationship. 

Reading and Reference

Read the following:

• Pico to Pico Subscriptions Lesson Links to an external site..
• Fuse with Two Owners Links to an external site.

The following video may be helpful:

Subcsriptions and Picos Links to an external site.

You may find the following resources useful:

• KRL Manual 
• Subscriptions API Links to an external site.
• Wrangler Subscriptions Links to an external site.
• Developer Tips for the Pico Engine 

Prerequisites

You should have completed:

• Lab 5: Pico-Based Systems

Implementation Notes

• In this lab, you'll be modifying rulesets you created for earlier labs. Be sure you're not overwriting or changing work that is still being graded. 
• Subscriptions are useful whenever you need a communication or relationship pattern between actors that doesn't follow the parent-child hierarchy. Most actor-based systems are heterarchical in nature, so this is common. 
• You'll be using the io.picolabs.subscription ruleset that is part of Wrangler for this lab. If you look at the code that makes up this ruleset Links to an external site., you'll see that it's quite complicated. Your job in this lab is to learn how to use subscriptions, not implement them. 
• This lab is less prescriptive than previous labs. You have more freedom to define event and function names. Try to name rules for what they do. Try to name events using nouns that describe the state change that they are signaling. 
• This lab requires that you coordinate with other members of the class. You will be doing all the work and graded individually, but you'll need a group to test the multiple sensor functionality. 
• To connect to other people's engines, you will all have to be on the same subnet or use a tunneling tool like Beame.io Links to an external site. or NGrok to expose your pico engine to others on the Internet. If you're running your pico engine on AWS or some other public hosting cloud, you will get this functionality without having to use a tunneling tool. 

Do This

1. Change the sensor management ruleset you created in the last lesson to ensure it creates a subscription to any child picos that are sensors. Use subscription roles to ensure you can pick out the subscriptions to sensors (and not other subscriptions the pico might have). Test this by creating a subscription to a pico with a different role and ensure you can distinguish it from the others. 
2. Modify the ruleset so that the subscription information is used to find sensor picos instead of the entity variable you used in the last lesson. For example, the function in the sensor management ruleset that queries all the child picos should query any subscription with a temperature sensor role and not others. You will still need an entity variable to keep track of names and any other information you need, but you won't use it to find sensor picos. You can use the subscription Tx channel as a unique identifier if you need to. Wrangler raises a wrangler subscription_added event that might be handy to find the Tx. This would be useful for cancelling a subscription when deleting one of the sensors. However, we do not require you to cancel the subscriptions when deleting sensors for this lab.
3. You can imagine that a sensor pico will already exist and your manager pico will want a subscription to it, even though this manager pico was not the initial parent of that sensor. Add a rule to your sensor management ruleset that introduces a sensor pico to your sensor management pico. Use event attributes to identify which sensor pico to introduce.  Make sure the auto subscription is working. 
4. Test your set up by creating subscriptions to a few sensors from other people in the class and ensuring you can see the temperatures from each managed sensor. Make sure to double check your function names. You may need to modify them so that your picos will be able to query each other correctly.
5. Add a profile ruleset to the sensor management pico that contains the SMS notification number and a means of sending SMS messages to the notification number. 
6. Modify the sensor ruleset that sends threshold violation notifications to raise a threshold violation event to the sensor management pico. Ensure you use subscription information to identify the manager not parent information. 
7. Add a rule to the management pico that listens for threshold violation events. Add a rule that sends an SMS notification whenever the management pico receives such an event. 

Deliverables

Turn in the following:

1. The URLs for your rulesets
2. A diagram showing the relationships between the picos.
3. Short screencast (with sound) showing 
   1. Creating sensor picos.
   2. Using introductions to add sensors to the sensor management pico's collection.
   3. Getting temperature information for sensors from the sensor management pico. 
4. Answers to the following questions:

Questions

1. Why might an auto-approval rule for subscriptions be considered insecure? 
2. Can you put a sensor pico in more than one sensor management pico (i.e. can it have subscriptions to more than one sensor management pico)? 
3. Imagine I have sensor types besides temperature sensors (e.g. pressure, humidity, air quality, etc.). How would you properly manage collections of sensors that include heterogeneous sensor types? 
4. Describe how you'd use the techniques from this lesson to create collections of temperature sensors in particular rooms or areas of a building. For example, I would still have the sensor management pico, but might have collections for each floor in a building.
5. Can a sensor pico belong to more than one collection? After the modifications of this lab, if a sensor belonged to more than one collection and had a threshold violation, what would happen? 
6. When you moved threshold violation notifications from the sensor to the management ruleset, did you add the rules to an existing ruleset or create a new one? Why? 
7. When you moved threshold violation notifications from the sensor to the management ruleset, did you add only one rule or more than one rule to achieve this end? Which rules did you add and why (i.e. justify the architectural decisions did you made)?