Skip to end of metadata
Go to start of metadata

Learning Objective

After completing this lesson, you will be able to:

  • explain how a pico is a first-class Internet citizen
  • explain channels and use the "My Picos" page to manage them
  • send events and queries to a pico using a browser, the event console, and the "Testing" tab
  • use logs
  • use the klog() operator


  • complete the Pico Engine Quickstart
  • have the hello_world ruleset from the Quickstart registered in the pico engine, and installed in a pico
  • have installed the event console in Google Chrome


Pico as an Internet citizen

A pico (quoting from Rebuilding KRL):

  • is capable of receiving events and queries on Internet channels,
  • interacts with other picos, even if they're hosted on another instance of the evaluator somewhere else on the Internet, and
  • can call and be called from Internet-hosted APIs.

Picos respond to events and queries using two different URL schemes. Events are sent to a pico using the Sky Event API. Queries are made using the Sky Cloud API

The Sky Event API describes the event API pattern for a pico including what components are important and how those components are encoded in an HTTP method (GET or POST). The specific API for a given pico, however, depends on which rules are installed since it is rules that respond to events. Similarly, the Sky Cloud API defines the patterns for queries that a pico understands. Again this is a meta-API since the queries that any given pico responds to depend on the modules installed. Queries are thus implementable with different code than the event processing and, in practice, tend to be much faster.

A pico has multiple URL's that can be used to query its state and send it events.


Here is a sample URL that sends an event to a pico like the one you created in the Pico Engine Quickstart:


Breaking this URL into components:

  • "http://" identifies HTTP as the protocol
  • "localhost:8080" is the domain name and port of the pico engine which hosts the pico
  • "sky/event" identifies this as an event for the pico
  • "citdel5gz00012aaoo5ucc613" is one of the pico's event channel identifiers (ECI) (yours will be different)
  • "1556" is an arbitrary string which serves as an event identifier (EID) and correlation ID. (useful when looking at logs)
  • "echo" identifies the domain of the event
  • "hello" identifies the type of the event


Here is a sample URL that sends a query to a pico:


This URL shares some components with the URL above for an event. The new components are:

  • "sky/cloud" identifies this as a query for the pico
  • the event channel identifier or ECI
  • "hello_world" is the ruleset identifier or RID
  • "hello" is the name of a shared function from that ruleset
  • "obj" is the name of the argument that the function expects
  • "Bob" is the value for that argument

Create a Channel

As you can see in the URL for events and queries, channels are the way in which a pico can be identified by the pico engine.

A pico can have multiple channels. Best practice is to create a channel for each purpose or correspondent. There are several reasons for this:

  • A single-purpose channel can be revoked without affecting other relationships the pico has.
  • Unique channels prevent correlation by third parties (protecting privacy)
  • The main channel, created at the same time as the pico, cannot be replaced except by deleting the pico and creating a replacement pico. 

Each channel has a name and a type.

To create a new channel, visit the "Channels" tab:

Note that the channel identifiers you will see are assigned by your pico engine, and will differ from the ones seen in these screenshots.

Enter "lesson" in the box whose placeholder is "name" and "temporary" in the box whose placeholder is "type" and click the "add channel" button to create a new channel.

Congratulations! You have created your first channel.

Note that you are able to delete channels that you create.

Make a note of the event channel identifier (ECI) assigned to your temporary channel. You will be using this "lesson" channel throughout the rest of this lesson.

Sending events through the channel

Since a pico is a first-class Internet citizen, there are many ways in which you can send it an event. We will look at three such ways here:

  1. Directly using a URL through a client (ex. a browser, or the `curl` command at the command line)
  2. Using the event console or some other console for RESTful APIs
  3. Using the "Testing" tab of the UI

1. Directly using a URL

Construct a URL that identifies your Pico by the channel id that you created in the previous section. Remember to replace the channel identifier in the sample URL with the identifier of your "lesson" channel. Also, you may choose your own event identifier (rather than use "5", as we did for this screenshot).


You can use the URL in any Internet client. For example, you could use it in the `curl` command in a Bash shell.

Here we will use a tab in the browser. Place the URL in the location area of your browser, and press the Enter key.

The result will look something like this:

Congratulations! You just received your first directive from an event you raised.

Directives allow picos to direct endpoints to react a certain way to an event.  Our rule's directive just says hello, but it could be used to do more complex things. Directives allow the program's logic to be placed in the rules, not in the end points.  Placing logic in the rules provides loose coupling with easier scaling and maintenance.

2. Using the event console

The Kynetx event console is a Google Chrome application that you can add to your browser to make it easy to send events. You can find it on GitHub and install it into your browser following the instructions. You can then launch it and enter in the host:port of your pico engine, the channel identifier and the event domain and type. You will need to un-check the box beside "Use HTTPS".

Click the "Raise Event" button to send the event to your pico engine, and the app will scroll to the Results section, where you can see the directives generated by your event.

Notice that the event identifier was chosen by the event console.

3. Using the "Testing" tab

When you develop a ruleset, you may choose to use the "Testing" tab of the "My Picos" page which can provide a simple UI for your event. The "Testing" tab works by querying your ruleset to see if it shares the name __testing and if it does, it parses the structure that __testing points to and builds simple forms to test each of the queries and events which the structure defines.

The value bound to __testing is a structure that describes those portions of our ruleset that we wish to expose in the "Testing" tab. You do not need to expose every aspect of your ruleset, but only those that you wish to appear in the "Testing" tab.

Add this code into the global block of your ruleset:

    __testing = { "queries": [ { "name": "hello", "args": [ "obj" ] },
                               { "name": "__testing" } ],
                  "events": [ { "domain": "echo", "type": "hello" } ]

You have added a new name, __testing (double underscore), which defines two queries and one event, to the "global" block of the ruleset.

This name must also be shared, so you will need to add it to the "shares" entry in the "meta" block of the ruleset. The "shares" keyword is followed by a comma-separated list of names defined in the globals section which we wish to use outside of the ruleset. Any names not mentioned in "shares" are for the private use of the the ruleset and are not exposed outside the ruleset. Edit the "meta" block of your ruleset to look like this:

  meta {
    name "Hello World"
    description <<
A first ruleset for the Quickstart
    author "Phil Windley"
    logging on
    shares hello, __testing

Be sure to validate your source code, using one of the techniques in Developer Tips for Pico Engine to ensure that you have introduced no syntax errors into your ruleset. Once you get the "ok", go ahead and push your changes and re-install the ruleset into your pico. (Review the Pico Engine Quickstart page if necessary)

Refresh your "My Picos" page, and click on the "Testing" tab. Notice under your ruleset identifier that there are three forms, one for each of the queries and the event that you described in your ruleset.

Notice the button "echo/hello", representing this event for your ruleset named "hello_world". Click on this button to send the event.

Notice in the directive returned by the event that the "Testing" tab uses the event identifier "__testing".

Using logs

Look at the console from which you started your pico engine.

You should see entries like this one:

[DEBUG] { rid: 'hello_world',
   { eci: 'citeh9si400022aao04assjxy',
     eid: '5',
     domain: 'echo',
     type: 'hello' } } fired

This console log may be useful in debugging events.

For example, try introducing a typo in the URL for the event, say by spelling "echo" incorrectly as "ecco". In the console log, you will see that the event is received, and the Pico selected (based on its ECI), but you will not see that the event has fired.

Send a query through your channel

Create a URL for your Pico which uses your "lesson" channel identifier. It will look something like


Places where your URL will differ from the one shown above:

  • you may be using a different port (other than "8080")
  • you will be using a different channel identifier (your ECI will not be "citeh9si400022aao04assjxy")
  • you may be using a different value for the expected argument named "obj" (not "Bob")

Enter your URL into the location line of your browser, or use it in a `curl` command in a Bash shell.

You can also enter the value for the argument in the "Testing" tab, in the box whose placeholder is "obj", and click on the link "hello".

Congratulations! You know how to send queries to a pico, either directly using a URL, or through the UI.

More about logs

KRL provides an operator, klog(), which allows us to print information into the logs. It is an operator, rather than a statement, so it is applied to an expression. It prints into the log the message passed to it as an argument, followed by the value of the expression on which it operates. Finally, it returns the value of the expression on which it operates, unchanged. This makes it easy to add to or remove from your KRL code without changing its meaning.

As an example, modify your "hello_world" rule to expect an attribute, named "name" and use it to customize the message returned in the directive.

Modify your rule so that it looks like this:

  rule hello_world {
    select when echo hello
    pre {
      name = event:attr("name").klog("our passed in name: ")
    send_directive("say", {"something":"Hello " + name})

This is the first use in these lessons of a prelude block within a rule. This is where we bind values to names which can then be used within the rule. Here, we obtain the value of the event attribute named "name" and bind that value to a name which is also named "name". We apply the "klog" operator to that value, which simply passes the value along, but as a side-effect logs its argument followed by the value.

Let's also modify the structure bound to __testing, as follows:

    __testing = { "queries": [ { "name": "hello", "args": [ "obj" ] },
                               { "name": "__testing" } ],
                  "events": [ { "domain": "echo", "type": "hello",
                                "attrs": [ "name" ] } ]

After making these changes to your ruleset, be sure to validate it, then push your change, and re-install into your pico.

With these changes, refresh the "Testing" tab and you can now enter a value into the box whose placeholder is "name" before clicking on the "echo/hello" button to send the event.

Examine the terminal or console from which you launched your engine. You will see the expected message from the klog operator, which will look like this (embedded in other logging messages, just before the rule fires):

[DEBUG] { rid: undefined,
   { eci: 'ciu4b6zui0001jfs0nmki6z1y',
     eid: '5',
     domain: 'echo',
     type: 'hello' } } rule selected: hello_world -> hello_world
[KLOG] our passed in name:  Bob
[DEBUG] { rid: 'hello_world',
   { eci: 'citeh9si400022aao04assjxy',
     eid: '5',
     domain: 'echo',
     type: 'hello' } } fired

Using the "Logging" tab

Click on the "Logging" tab for your pico.

Notice that logging is disabled. The ruleset required for logging is pre-registered in your pico engine. Click on the "Rulesets" tab, and notice that it appears in a dropdown list named "Available Rulesets".

Click on the "install ruleset" button to install the "io.picolabs.logging" ruleset in your pico.

Click again on the "Logging" tab.

Logging is now available for this pico, but is turned off. Click the "On" button, and refresh the "My Picos" page.

You should see one episode, for the event that turned logging on. Now go to the testing tab and do a query and an event for your hello_world ruleset. Refresh the page, and you will see logging episodes that match your testing activity. Select a couple of these to see the detailed logging.

Here we see the logging for a query and an event.


You now know how to send events to, and make queries of, a pico. You have also learned some debugging techniques.

Next, learn about persistence, the "P" of pico, by working through Pico State Lesson.


Do the following:

  1. Create a new channel (pick any name and type you like). 
    1. Send an event to your pico using the new channel. 
    2. Do you get the same result? Why or why not? 
  2. Delete the channel.
    1. Resend the event using the deleted channel. 
    2. What happens? Why?
  3. Send the event ecco/hello to your pico. What do you observe? Why? 
  4. Add a new rule that selects on echo/monkey and responds with "Hello Monkey" unless an event attribute named name is given, in which case it will respond with "Hello " followed by the given name. Hint: use the .defaultsTo() operator. Use the .klog() operator to log the value that is used. 
  5. Repeat the previous exercise using the ternary conditional instead of the .defaultsTo() operator. 

  • No labels