The Control page is different to the other pages in that it gives you access to the inner working of SharksHead. Many of the operations you perform in other SharksHead pages can be done, with the right information, on the Control page.
This Control page discussion is not so much about the page itself as it is about SharksHead’s design. You probably only need to access this page if we ask you to look at or change something. So I’ll end this page here, but, if you want to read on, by all means, read on.
The Control page exposes some of the design elements behind SharksHead. I’m not going to detail every possible thing you can do with this page, however, discussing these design elements should help with understanding SharksHead in more detail. Taken along with the status panel discussion it can give you quite a bit knowledge of the inner workings of SharksHead.
In terms of page layout and operation it is pretty typical of most other SharksHead pages, so I won’t go into any details. I’m sure it will be familiar enough for you to find your way around.
Here’s the HQ’s control page from my primary development system:
And here’s another from a Consumer controller:
You’ll notice they are similar in structure but quite different in detail. The same is true for any module. They are the same at a high level but different at the low level.
The HQ is a module similar to other modules, however, it is special because it runs the show and so has some functionality the other modules do not have. This is why there is a set of details that starts with Channel just under the Mo 0 – HQ heading, and the Routing table heading at the bottom.
The Shutdown HQ link on the HQ page shuts down and powers off the HQ. You must do this if you are going to power down the HQ – do not simply remove power from the HQ. The shutdown process takes 30 seconds, after which you may remove the power.
The Reboot SH restarts the SharksHead process that runs on HQ. It does not reboot the HQ. It’s like a reset button on a module. You should have no reason to hit this.
The Routing table link will show you HQ’s routing table at the end of the page. This shows the modules (their Mo number), which module they are accessed via, and the number of packets in and out. The PDR part refers to modules that are in power saving mode, as you might do with the TPH module. PDR stands for Powered Down Radio.
The Download logs link is for debugging. Specifically, if you’re having trouble with your SharksHead installation we may ask you to send us these logs. This link packages the SharksHead diagnostic logs in a tar.gz file and asks you to download them to your computer. Download them then send them to us. There is no personally identifiable information in the logs. They contain mostly packet logs and some details about your modules. Feel free to try it and check the logs out for yourself.
Every module has four common design elements, three of which you can see here: Sensors, Actors and Configs. The fourth, Directors, are not something that is so easily shown on a web site, however, they are at the core of SharksHead smarts.
Each sensor is defined by its type and sub-type. When SharksHead is searching for a sensor it uses the type and sub-type fields, nothing else. Once the sensor is found then it is the sensor’s number that is used in all communication with the module and the database.
A sensor’s type generally defines the unit of its return value. We stick to ISO units, for example, Volt, Ampere, Kelvin and the like.
A sensor’s representation and scale is an internal implementation detail that we take care of when presenting the value to you, however, it does give you an indication of the best precision you can expect from the sensor. For example, the CS 8.0 current sensor above, with a scale of 10^3 and an integer representation, means it returns milliAmps, or Amps to three decimal places. It cannot return a value with more precision, such as microAmps (six decimal places.) And, it needs to be said, the sensor may not even have milliAmps resolution. The scale sets an upper bound to the resolution you can expect. It does not indicate the actual resolution of the sensor.
Each sensor can be enabled or disabled. One reason you may wish to disable a sensor is when that sensor is returning rubbish data which in turn is causing some alert to be constantly or inappropriately triggered.
As for the web page, the value and timestamp, in keeping with many pages, are updated in real-time.
Actors can do things, like open or close relays, turn switches on or off, or show alert details on the traffic light (yes, the traffic light is an actor, SI 0.2 above.)
Actors, like sensors, are defined by their type and sub-type and can be enabled or disabled.
Each actor has a single 8-bit value to indicate its internal state. For a simple switch actor this could be a 0 or 1, or for more complex actors this can be multiple values. Each actor defines this value. There is no SharksHead-wide definition of what an actor state can be.
Communicating with an actor is through an actor command that, as you can see from the images above, consists of a command and up to 8 arguments, each being 8-bits. Like the actor state, each actor command is specific to each individual actor, however, actors of the same type accept the same command and arguments.
And, again, in keeping with the real-time nature of SharksHead, the Status, State and the enable/disable link are updated in real-time.
Configs are where modules store data that will be retained across a power outage. Configs are to a module what a disk is to a computer: long term storage. Like sensors and actors, they are defined by their type and sub-type. And, like sensors, they have a representation and scale, although the scale is not always indicative of the config’s actual use.
A config’s factory default value can be used to reset its value back to its as-shipped value.
The uses of configs can vary dramatically. They may store calibration constants that we generate as part of a module’s setup, thresholds and cutoffs, module state information, and LED colours. Their use hinges entirely on their type and sub-type.
And, no surprise, config values are updated in real-time.
Directors tell actors what to do and when. We have designed SharksHead loosely on the movie-making business. Actors can perform tasks, but they don’t know when or why. Directors are pieces of code, or logic, inside SharksHead that monitor various sensors and, when they detect something that requires an action, they ask an actor to perform a task.
Some directors run on the modules. For example, the Consumer controller has a director that monitors the current, and when the current goes over the threshold, stored in a config, it asks the virtual circuit breaker actor to trip. A similar director runs on the Battery controller module.
Most directors run on the HQ, and they don’t always tell actors what to do. Some of the simpler directors are the barometric pressure monitor (watches for sharp rises or falls) and the AA battery pack monitor (watches for low battery), both of which talk to actors. Getting a bit more complex is the director that maintains the real-time data stream to web browsers, the database director that provides more efficient use of the database (an internal technicality), and the director that helps lessen the effects of an unreliable radio network, none of which talk to actors.
Another director is you, the SharksHead user. Many things you do through the web interface involve communicating directly with an actor, such as when you click on the locate link for a module, turn a CC switch on, or open a BC relay.
And it goes beyond the director analogy, too, for when you hit an Upgrade button, enrol or replace a module, or simply plug a Programmer into a module, you have initiated actions that will ultimately result in a director starting a series of events that will talk to one or many actors to achieve the end result.
So, that’s the Control page. Not much detail about how you can use the page to achieve some end. More of a view of the design of SharksHead. Hope you enjoyed.