Managing channels

A previous post, Pico channels, defines and describes channels, and prescribes some best practices for managing them. 

This post tells a story of bad consequences when that advice was ignored^*, and also describes a more resilient way to set up the channels for one particular application.

Consider a pico that records temperature readings from remote sensors. The sensors need a channel to post their readings periodically. A web application allowing the history of those readings to be explored also needs a channel to the pico.

The situation

The author controls a pico hosted by a pico engine which also runs picos for dozens of other people. Besides the primary use of that pico (the reason for which it is hosted at all), the author has installed a ruleset for recording temperature readings. In this way, the pico is being treated as a personal cloud^**.

There are four Wovyn temperature sensors which have been configured to send their "heartbeat" message every ten minutes. The messages are all sent to the author's pico, over a channel. The channel was set up when the com.vcpnews.wovyn-sensors ruleset was first installed into the pico. The message each sensor sent was to a URL that looked like this:

http://IP:3000/sky/event/ECI/hb/com_vcpnews_wovyn_sensors/heartbeat

Where IP is the address of the EC2 instance on which the pico engine runs. The author arranged for port 3000 to be opened for incoming traffic from his home WiFi router, used by the sensors to post their messages. Each message payload, the actual heartbeat message, is a JSON structure, including the sensor's identifier and the current temperature (among many other things).

The ECI was cl6gkrzzt04mpjbpb7hfx3ufp^***. In choosing this ECI, the author ignored an important prescription from that Pico channels post. Nevertheless, everything worked fine for months.

The problem

The prescription which was ignored was "Create a channel for each usage and user." Instead the sensors were given the ECI of the channel that was used by the web application. 

Early Sunday morning, the author made a simple improvement to the web application. Careful consideration of the handling of the entity variable maintaining the record of temperatures showed that it would not be lost when the ruleset was installed again. 

However, not noticed was that when installed, the new ruleset would create a new channel and remove the old one. That action implemented the prescription to "delete any old channels from previous installations." So far so good.

But starting then, the sensor readings were no longer accepted into the pico because they were coming in on the old channel. And that channel had been effectively revoked.

The solution

Once the outage was noticed^**** ten hours later, the solution was to manually create a channel just for use by the sensors. The web application side of things could then manage channels as it did without impacting communications from the sensors.

The first channel is the new one created by the ruleset as it was installed. And its identifier, clb…4fuw  could have been used to update the URL configured into each of the four sensors. But the lesson was learned!

Configuring a sensor is a time-consuming operation that must be done with a laptop in close proximity to each sensor, and two of them are out in the cold. So, wishing to never have to do it again, the author manually created the second channel above, and used its identifier, clb…193x, in the URL configured in the sensors.

Now, when the next early morning brainstorm comes for an improvement to the web application, that can be made, and the improved ruleset installed, all without revoking the channel used by the sensors. It was manually created, and can be manually deleted when the author decides to retire the sensor devices.

Moral of the story

Follow best practices when using channels with your picos.

Addendum

At the end of the day, everything was back in working order. The graph:

showing the gap. The sensor inside the shed, once given the new ECI worked a few times, but then stopped, so it was moved a bit closer to the WiFi router.

The next day, a simple change was made to the web application part of the ruleset, and it was installed into the pico without disrupting the sensors, even though there is again a new channel and the old one was revoked.

Notes

^* by the author, of both the prescriptions and of this blog, who should have known better! The result was an outage that lasted 10 hours before it was noticed, and took half an hour to get things going again.

^** the term "personal cloud" was in use ten years ago, by a company based around the first version of a pico engine to be created. The term "pico" has supplanted "personal cloud" now, but there is much to be gained from a study of precursors. For instance, you might enjoy the story of "Forgetting to Water the Christmas Tree? How Personal Clouds Saved Christmas". A reader of this blog will immediately see how a pico could be used to address this problem.

An alert reader of the Christmas Tree story will notice that a critical step in the solution of that problem is hidden away in the simple words that they "spent five minutes setting up his personal cloud...", in which the active link is broken, because that provider of picos is no longer in business. Once you find a provider of pico hosting, it would indeed be a simple matter to set that up.  The author has planned a post to be entitled, "How to make money hosting picos," which will hopefully motivate people to do just that. Until that happens, you can just set up your own pico engine (which, be warned, will take a few more than five minutes).

^*** Why is this identifier published to the world while care will be taken to elide portions of the others? The others are active. Because this one was revoked, it can no longer, ever again, be used. Thus, nothing is risked by exposing it.

^**** which brings up the point that perhaps there should be monitoring in place, so that if no readings have come in during some period of time the pico's owner could be notified by text or email.