We kickstarted the first work package of our follow-up project LoRaBridge 2 by defining the basic requirements and later selecting the suitable software and hardware components. As we will have a lot of "moving parts" in our setup, this early planning phase is crucial and should be conducted as comprehensively as possible. This way we can minimize the cost of backing up in later project phase, should some of the selected components turn out to be insufficient for our needs.

The main goal of LoRaBridge 2 is to transfer home automation rules from a user to a remotely located home automation gateway. This means we will need: 1) User interface for home automation configuration, 2) wireless interface to carry the data and 3) the actual home automation gateway. 

For the UI, we are looking forward to implement a light weight approach of the popular node-red visual programming of home automations. That is: A user places home automation components on a blank canvas and configures and connects them as she/he likes.  The best bet would be to use web-components, e.g. with Svelte (already successfully utilized in LoRaBridge 1), which automatically guarantees cross-platform support. A strong alternative is the Godot game engine, which allows for implementing visual scripting and supports for HTML5 and multiplatform exports (Windows/Linux/Mac/Android/Ios).

For the LoRaWAN link, taking care of communication of home automation rules and also the device data, we first thought any popular LoRaWAN stack combined with a LoRaWAN modem would do. This turned out not to be the case. In the middle of brainstorming the LB2 system concept, it dawned upon us that we need a time synchronization mechanism for the home automation gateway. Otherwise, some popular automations like timer controlled lights would not work, e.g. after a electricity blackout. Luckily, the LoRaWAN 1.0.3 standard offers a network timesync feature and so we started to look at stacks which offer this functionality. Moreover, to allow for broader LoRaWAN modem selection for the user to choose from, we did end up using the popular LMIC node repository to define the LoRaWAN transmitter.

Finally, the work horse of the project, i.e. the automation gateway, was actually easiest in terms of selecting the suitable software. We ended up picking up the NodeRED, which is a mature frame work for defining automations. 

In the following months we look forward to work on the UI, on the compression algorithms for automations and on the NodeRED.