In the last days one could have seen some git code changes around HFS. Since we do not have a documentation yet (but in progress! :), here comes a small sneak&peek about HFS.

The HFS is a tree structured database which collects all information about the system. It collects and stores events and values. Also files could be uploaded into it and downloaded from it.

##Why is it needed?

Since HyperBorg is a decentralised system, one of the key component is to keep the statuses and values synchronized all around the system. The base concept here is to provided a central data structure that kept in sync transparently. This approach has some good sides: it is not relevant, who is modifying a given node, it would be propagated all over the system and will have effects. For example, you would like to have a family photo as a background and you want that to be changed in every minute.

You can deploy a HyperBorg instance on a Linux storage server that keeps pushing the family photos into HFS, which triggers a background change on a Windows or WebAssembly client.

##Why it is designed this way?

The HyperBorg system aims multiple operating systems: Linux, WebAssemly, Windows and Android.

These operating systems have different constraints. For example WebAssembly cannot reach out to the local filesytem, thus it can rely only on its network communication (and that is also somehow limited: COEP & co) To minimalize OS related differences, this database is kept in memory and it acts as a quasi-filesystem-virtualization while keeping the possibility for given nodes to attach HFS to real file sytems.

##Snapshots?

One of the good side of the HFS, that it stores all information in an isolated model (QModel). It has two major advantage: it is possible to attach a treeview anytime, so all of its content is visible and modifiable real-time. The second advantage is that the whole “database” could be saved at any given point, thus could be backed up or analyzed in a convinient way.

As you might have noticed, HUDScene is removed from the source codes, although the HUD – as a name – will remain with us. Behind this change there is a technology decision, thus the new GUI interface would be based on QML, rather than Widgets. This opens up a lot of new possibilities that could have been reacheable with HUDScene with more effort.

The main goal with this change is to have a better separation of the look and feel from the actual logic and to provide more fluent experiences.

The new QML interface would be rolled out soon both in github as well as the demo site.

Due to the Qt framework changes, HyperBorg itself is also switching to cmake build system.

In the last couple of month there were intensive testing of how Qt 6 could be adopted.

There were a lot of issue on all sides that needed to be addressed (one of them was the high CPU usage at the WebAssembly platform.

The HyperBorg project now officially switches to Qt 6.2.1 framework.

Since the POC setup has been extended with a SainLogic WS-3500 weather station, it is time to intoduce the GUI elements usuable for weather stations. All, the here presented 12 gauges are instanced from the same Gauge element.

Please keep in mind, that this is still a work-in-progress, so there are still bugs in them to fix.

The second and the fourth row contains the same gauge from the row above, but with a different style setup. Also noteworthy, that when the value in those gauges go to a specific range, the color is changed (check where the needle is at the row above!)

The GUI would be connected to the real-live data in the coming days.

The datapaths inside the node had been revised, so one step closer to the presentable POC.

Currently, on the testbed, there are 3 RPi nodes, one of set to MASTER, the other two are SLAVEs. The forth node, the webassembly node at https://hyperborg.com/demo is not yet updated, so it does not connect to the mesh yet.

Some thoughts about MASTER/SLAVE (This would be updated to Initiator/Target later on): The main concept of HyperBorg is to be decentralized, thus one centralized node that controls all the others does not fit into the future plan. Although, in the pre-POC era it certainly helps debugging communication issues.

As you might know, the mesh maintenance and discovery is done in the lower level (CS and Beacon), so it should not be a big issue to switch from master/slave to virtual token ring or other more balanced, more decentralized approach.

But for now, we are at a master/slaves setup, as follows: – the master loads up the n8i8op modules and the ws3500. This way, the light switching relay board is controlled by the main HyperBorg Node. This node has no graphical output. – the two other slaves are also RPis having TFT display.

Currently, the WS3500 weather station sends all the weather data to the main node, which instantly distributes the information to all the slaves.

The path of the measured variables could be tracked and arriving into the slaves, but they are discarded at the Slotter (the highest) level, since the GUI is not yet capable of using them.

In short: the communication is now established between all three nodes (and maintained if any of the nodes are drop out from the mesh) and all Slotter levels are capable of communicating with each other.

The next step is to create some buttons and weather tiles/widgets for the GUI. When that is achieved, the POC level is complete!

Today at HyperBorg HQ, we have unboxed a brand new SainLogic WS3500 weather station.

This device provides, temperature, humidity, air pressure, wind, wind direction, UV and other sensor data over WunderGround protocol. (This is a simple HTTP GET command)

In order to suppor that device, a new plugin is introduced, named: ws3500.

Today HyperBorg has reached its very minimal POC state. Let’s see what have changed:

#Configuration parsing The configuration is now based on a .json file (config.json) that contains all settings for all layers and plugins. The concept here is that each hardware device should have an additional 2 extra files to insert it to an existing matrix (or create a new one). If that configuration file is saved, the whole matrix could be restored.

#HHC-N8I8OP fixes The device driver for HHC-N8I8OP matured a lot in the last days. Now it is using the global configuration file, but more important, the anti-bouncing parts are enhanced and it now finally reconnects to the relay board if the TCP/IP connection is lost.

#HHC-N8I8OP bypass mode Since the UniCore module is under developement, the relay board cannot use its features. Thus a bypass mode is activated in the device driver. When bypass mode is active, the input side of the relay board is 1:1 mapped to the state of the relay. So if you connect +5v to IN1 for example, relay 1 would be triggered and it would close NO1 to COM.

In this mode, the input from the relay board is sent to device driver at the HyperBorg node, where the anti-bouncing filter is applied on it, then sent back to the relay board. The anti-bouncing filter applies a preset of 200ms fixed delay currently.

#Why is it big deal for HyperBorg? One might think that switching a relayboard from its own input ports is not a big issue. In reality, this is the case. But the real importance is that HyperBorg node is now transparently between the input ports and the relays. Although it just sends to the output what is on the input side, it enables anyone who wants to tinker with HyperBorg to install it in an environment, where phyiscal switches are deployed to control lights or any electricity driven application. And as HyperBorg evolves further, the possiblities would open up!

Bottom line: with today, the node is usable, even if it only means switching up some lights 🙂

As you might now, a new trend is emerging in the IoT area. The CHIP (Connected Home over Internet Protocol) protocol is going to be the de facto communication platform for smart home and other IoT devices.

We have put the support for CHIP into our roadmap.

Stay tuned, vibrant years ahead … and resistance is flutile 🙂

The internode communication requires secured channels. Also, using WebAssembly based node, the COEP/COOP settings should be set correctly on the server side.