It's been brewing for awhile now. It's time to talk a bit about Manuvr Host Bridge (MHB).

It isn't ready for use yet, but there is a substantial amount complete and worth describing. There are two repositories in play here. The core of everything is MHB (Manuvr Host Bridge). The second is one of many possible front-ends to MHB: ManuvrElectron, which is represented in these screen-shots:

There is the main window or the right-hand side of the screen, as well as a logger window on the left. The logger window is mostly uninteresting and won't be discussed further. The main window is where the action is.

This entire post is about MHB. ManuvrElectron will be discussed independently. But for now I'll just say...

  • A front-end is not required. MHB can be run headless.
  • The front-end is all React ES6.
  • Behavior on linux and OSX is almost exactly the same. Writing GUi desktop applications has never been easier.
  • There are still some gyp/NaN/Low-level problems with bluetooth and serial support. But these are at-present surmountable. We expect the situation to improve as the ecosystem stabilizes and NPM-3/Node-5 settle-in.
  • Styling is not to be taken as indicative of the future. It works beautifully but is not beautiful. :-)

On to MHB...

Self-organization is a key design principle

Self-organization is at the core of Natural systems at every scale. The ability to build systems that self-organize is not a trivial undertaking because it means committing to some rules at the outset that seem arbitrary or meaningless until many independent actors become involved. The assumptions we've made, the rules we've defined, and the limits of our foresight will be a subject of a much more detailed post when that becomes appropriate. But for now, suffice it to say that the ability to support self-organizing systems has been one of the core design themes throughout this entire project.

This software ought to be able to operate equally-well with any Manuvrable at any scale. From wrist-watches to HVAC installations.

Quickly, some nouns...
  • A Manuvrable is (typically) a piece of hardware running a communication stack compatible with Manuvr's protocol.
  • An mSession is the software representation of an active connection with a particular Manuvrable.
  • An mTransport is a means of moving bytes between sessions. This might be a TCP/UDP socket, radio link, or a carrier pigeon.
  • An mEngine is a javascript library written to talk to a given Manuvrable. Any mSession may contain many mEngines.
  • mCore is the root engine from which all other engines derive their connection to the firmware. It is internal machinery to MHB, and the user shouldn't be concerned with it.
  • An mClient is an optional piece of software that makes mSessions accessible to other software. If present, this might be a REST API, a webserver, or a GUI (as shown here).
Next, some component relationships...

At minimum, every mSession is composed of an mTransport and one mEngine (mCore).

mSession's job is to be the cohesive glue that binds engines together in a harmonious way. To that end, it provides the unified "face" representing the IoT device. The session is also responsible for maintaining states and user configuration pertinent to a given Manuvrable. The session co-ordinates the mEngines' efforts to goal-seek the hardware into a desired state.

Without knowledge of who is one the other side of the wire, there is only one mEngine loaded (mCore). It is a special, ever-present engine that is responsible for implementing Manuvr's protocol. At the time of this writing, it is the single-largest piece of the program, and its duties are...

  • Managing connection security.
  • Translating between the high-level API and semantics of the session and the low-level bytes-on-the-wire link to the firmware.
  • During session setup, (optionally) downloading and loading new mEngines for the sake of implementing the nuances of the device. Those engines are then attached to the running session, ready for immediate use.

By the end of session setup, there ought to be a running mSession representing the identity of the particular device at the other side of the wire, as well as the sum-total of its capabilities that have been made accessible to us.

And now to explain the screen shots...

In the screenshot is depicted two sessions connected over a loopback transport. I have manually assigned a debug engine to one of the sessions. It's purpose is only to move a few test messages between sessions. Eventually, it will be expanded to be usable to interact with any firmware in the absence of a javascript library to support it. This will make writing and debugging IoT firmware a breeze.

During the development phase of a project, the communication stack is already implemented, and is transport-invariant.

Prior to release, regression tests can be run host-side for all exposed API in the firmware.

Finally, for actual use, a custom UI or API module can be written for usage of the new device by end-users.

Transports we've coded for:

Loopback has been our primary debugging transport because it lets us connect two sessions on the same system, but is unlikely to be useful for anything other than debugging mEngines. The other supported transports are Websockets, serial ports, and bluetooth.