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 🙂