Objective

Previous labs have focused on a single pico and how to use rulesets to change its behavior. This lab goes beyond that to systems of picos. You will be building a pico that creates, updates, and deletes other picos. This ability is one of the primary features of an actor-model system. 

The objective of this lab is introduce actor-model programming principles using picos.  You will learn:

• Pico life cycle management
• Inter-pico interaction

Reading and Reference

Read the following:

• Pico-Based Systems Lesson

You may find the following resources useful:

• KRL Manual 
• Fuse with Two Owners
• Using Picos for BYU's Priority Registration
• Accessing a Function Shared by Another Pico

Prerequisites

You should have completed:

•  Lab 4: Single Page Applications

Implementation Notes

• Read the Pico-Based Systems lesson carefully and completely. Ask questions if you don't understand what's happening. Creating child picos is an asynchronous process with lots of room for errors. 
• 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. 
• Even though another event may be the primary result of a rule firing, you can use directives to see what's happening for debugging purposes. 
• You can use this emitter ruleset to simulate Wovyn devices in the picos. 

Do This

In previous labs, you've created a pico that manages a single temperature sensor. In this lesson, you'll build a sensor management pico and program it to create sensor picos as needed. When the sensor management pico creates a sensor pico, it will programmatically install the necessary rulesets for a sensor pico that you've used or built in previous lessons. 

Do the following:

1. Create a new pico that represents a collection of sensors. This pico may be a child of the root pico or you can start over with a fresh installation of the pico engine. It doesn't matter. When I say represent, I don't mean that actual devices will connect to it. Each device will still connect to a specific pico representing that device. The sensor management pico, manages multiple sensor picos. 
2. Create, register, and install a ruleset called manage_sensors in the sensor collection pico.
3. Write a rule in the manage_sensors ruleset that responds to a sensor:new_sensor event by 
1. programmatically creating a new pico to represent the sensor
2. installing the temperature_store, wovyn_base, sensor_profile, and io.picolabs.wovyn.emitter rulesets in the new sensor. 
3. storing the value of an event attribute giving the sensor's name and the new sensors pico's ECI in an entity variable called sensors that maps its name to the ECI
4. Programmatically send a sensor:profile_updated event to the child after it's created to set its name, notification SMS number, and default threshold. The name should be an attribute of the sensor:new_sensor event and the threshold should be a default value defined in the manage_sensors ruleset. You'll need to avoid race conditions so that you're not trying to update the profile before the system has finished creating the child and installing the desired rulesets.
5. Modify the rule for creating a new sensors to not allow duplicate names.
6. Write a function in the manage_sensors ruleset called sensors that returns the child pico information (which should be in the entity variable you created above).
7. Write a rule that responds to a sensor:unneeded_sensor event by 
   1. programmatically deleting the appropriate sensor pico (identified by an event attribute)
   2. removes the mapping in the entity variable for this sensor
8. Write a script or test harness to test your set up. Ensure your test harness tests the rules and functions you defined by:
   1. creating multiple sensors and deleting at least one sensor. You only have one Wovyn device, so you'll only have one sensor pico that is actually connected to a device, the others will have the emitter simulator ruleset. Note: you'll have to reprogram the Wovyn sensor to send events to the new pico instead of the one you created manually and pause the emitter ruleset in that pico so it's not also firing. 
   2. tests the sensors by ensuring they respond correctly to new temperature events. 
   3. tests the sensor profile to ensure it's getting set reliably.
9. Write a function in the manage_sensors ruleset that calls the temperatures function in each of the sensors it knows about. The result should be a JSON object combining the results returned by each sensor. Be sure that the function continues to work even when sensors are added or deleted. 

Deliverables

Turn in the following:

1. URLs for your rulesets
2. A diagram showing the relationships between the picos.
3. Short screencast (< 3 min with sound) showing the basic functionality and also you running your test harness.
4. Answers to the following questions:

Questions

1. How did your rule that creates the sensor pico install rules in the new child pico? 
2. How did you ensure that your sensor picos were created before sending them the event telling them their profile was updated? 
3. How did you create a test harness for your pico system?
4. In this set up, the picos representing sensors don't need to talk to each other and the sensor management pico is the parent, so it has channels to each child. How could you provide channels between sensor picos if sensor-to-sensor interaction were necessary?