The developement on hyperborg was a bit “silent” during the last weeks. One of the reason was that there were less time available for developing, but the more major issue was he SSL communication with the webassembly (webbrowser) node. For some reason it stalled in connecting state, while it should level up to connected state.

There were multiple issues to resolve the issues and different setups were tested (library versions and so). These took a a lot of time, since rebuilding these libraries requires multiple hours in each run.

Finally, the issue was found, so codebase is about to be cleaned and updated, then we can face implementing the core features: buttons and scripting language.

(Also, python would be supported ….)

Although the automatic WASM build from the GIT repository is working, there are some minor differences between the compilers used for WASM building (EMSDK) and the initial developement (Visual Studio 2019) resulting in some temporary compilation issues still needing manual fixes. These are going to be fixed.

Meanwhile a new screeshot from the actual “ping-pong” version in the latest FireFox Nightly.

As we get closer to the POC state, soon better instruction would be available how to launch your HyperBorg nodes.

As the base implementation of the the node’s internal is taking shape, it is time to talk about what de different modules do.

Before that, it should be mentioned, that using the EPI approach, all of these modules are lazy connected to the others, thus they could be easily replaced with other implementations.

CoreServer is the module responsible for the communication with other nodes. It gets the connection information (or if node is the master, the used port) from the Beacon module. Then it handles and hides all socket related communication from all the other modules.

Currently the CoreServer builds up a one master-multiple slave scenario (this is one of the easiest to implement), but since it is shadowed from all the other modules, it could be modified for any other topology: virtual token ring, or others.

When a data package arrives into the Coreserver, it is handled to the UniCore.

UniCore is the “main processor” for the node: it checks the parametric of the data block to be sure that everything is right, could tag ACL on it then – if node is a master – processed according the internal rules. If the output has anything related to the local slots (plugins, GUI elements), then the package is passed to the Slotter.

The Slooter is the actual interfacing module between the node and the loaded plugins and preset elements (whether they are GUI or not). All the elements are connected to a slot (hence the name “Slotter”) and they are communicating over that one. For example, if you add a new I2C board to a node, it connects to a slot. Also, adding a GUI push button to the HUD is connected to a slot.

Then a minimal rule is needed to connect the state of that GUI button to the I2C relay panel.

Firefox currently has SharedArrayBuffer off by default, because of the Spectre attacks. You can manually turn it on, though, by going to about:config and switching on javascript.options.shared_memory.

You need to do this change manually in your web browser in order to run the live demo at https://hyperborg.com/demo

We assume, that this issue (enabling thread by default would be resolved later on)

We, the Borgs believe, that it should be always easy to join the community. We also like technical abbreviations, like EPI and EPM. They stand for “Easy-Peasy Installation” and “Easy-Peasy Management”. Most of the HyperBorg features are based on these two policies meaning that it should be working out-of-box and should be as bullet-proof as possible.

Of course, there is a certain balance between the two edges. You cannot create a one-button controlled nuclear powerplant, so for certain areas, you need to understand the logic under the hood. But for most Borg users, it has to simply work.

So, basically EPI and EPM helps you to have a working system in couple of minutes.

Added a minimal sample for chart display. It is in the hub at this moment, but would be transferred into its own class. GlowGlass GUI would implement and follow tile handlings (move, span, etc). But currently we are working on the background communication and SQL access.

Screenshot of the current state:

The GlowGlass GUI got a bit facelift. In the last days, the main project was to bring the git repositories and build servers online, so the GUI was just a handwritten draft.

Now added everything in the layouts, minimialized parts that requires manual repainting. Added HUDLabel class so the date and welcome texts could be displayed without geometry issues.

Want to take a look?

We started. Somewhere in the distant corner of the Intenet. But we are gaining experience, skills and source codes day by day. We are small yet, but we are bringing new ideas and solutions in the home automatization scene.

Get on board, resistance is futile … we are HyperBorg, afterall …