Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: clarify and show structure of ent:timings

...

You will probably also find it useful informative to install the pre-registered logging ruleset, and enable logging in the "Logging" tab.

The finally step in preparing your pico for use as the "back end" of the single page application is to create a channel for each timekeeper. Do this in the "Channels" tab.

...

and similarly for other timekeepers. Having a separate ECI for each timekeeper allows you to revoke access to the SPA for one timekeeper while allowing others to continue using it.

The Pico Ruleset

The ruleset shares (line 3) the function entries (defined in lines 6-8), which simply returns the values of an entity variable named ent:entries which will be maintained as a KRL map.

...

Rule timing_finished (lines 31-40) selects when the event with domain timing and type finished occurs, provided it has an attribute number matching the regular expression in line 32. If it does, the rule is selected with ordinal_string set to the number. In the rule prelude, a normalized key is built from the ordinal value. If there is already a timing with that key, the rule fires, performing no action, and in its fired postlude sets (to the current time) an attribute time_in on the map for that timing.

In the "Rulesets" tab for the pico, you can check the box beside the timing_tracker ruleset to see its entity variable. The value might look something like this (lightly edited for readability):

Code Block
ent:timings=
{"N1": {"ordinal":1,"number":"n1","name":"Nick Angell","time_out":"2017-04-26T22:35:48.446Z","time_in":"2017-04-26T22:39:47.998Z"},
 "N2": {"ordinal":2,"number":"n2","name":"Connor Grimm","time_out":"2017-04-26T22:36:12.665Z"}
}