First and foremost, the SoftHub allows you to build a lot of typical IoT edge infrastructure without doing any programming. It does this by incorporating an extremely flexible object based rule engine that lets you configure your edge applications in minimal time and with minimal effort. Additionally, the SoftHub includes an ever-growing suite of sensor decodes so sensors are simply picked from a dropdown menu. Once selected, all the values the sensor allows writes to, reads from, or notifications from are exposed and can be referenced by the user when building their configuration ruleset. Lastly, the OmnIoT SoftHub Platform was built with portability in mind. It can run on most Linux platforms including very low power hardware such as the Raspberry Pi Zero/W. All of these factors translate to a very low risk, low cost solution able to be deployed at in a fraction of the time other solutions typically require

The main SoftHub application runs as a Linux daemon. On startup, the daemon reads the user created configuration file. The configuration file consists of three subsections: the general system settings, the ruleset object definitions, and the rules themselves which describes the user’s application. A separate application, the "SoftHub Configuration Utility", is used to create the configuration file. Once created, the user simply copies the file to a SoftHub data directory on the target SoftHub device and restarts the SoftHub daemon.

The OmnIoT SoftHub Platform currently consists of the following subcomponents, (1) The SoftHub Linux daemon, (2) The SoftHub Configuration Utility, (3) The Remote Packet Capture Utility and, (4) The LogFile Decode Utility. The Remote Packet Capture Utility allows you to set up your own servers, either locally or in the cloud, to receive the data the SoftHub generates. Data is sent via a TLS encrypted connection in either binary, JSON, or XML format. The Remote Packet Capture Utility will the receive and decode the data before passing it to the user for further processing. Similarly, when using the SoftHub's logging capabilities, the LogFile Decode Utility allows the user to subsequently decode any raw data that has been retrieved from a SoftHub device's local storage. As with the Remote Packet Capture Utility, data can be decoded into either binary, JSON, or XML format.

The core SoftHub component was built specifically with portability in mind. It was developed on fairly vanilla Linux and with a very few exceptions uses only standard Linux libraries. Currently, we publicly provide download packages for Raspberry Pi 3, 4, and Zero devices, however we are actively seeking additional hardware companies interested in partnering with us. We hope to have additional platforms available in the near future.

One of our primary goals while building the SoftHub was to ensure that new sensors (and even new sensor technologies) could be incorporated into the platform with minimal effort. Adding a new sensor is generally a day or two's work once we have access to the sensor’s packet format information. If you have a sensor you'd like to see the SoftHub support, please get in touch with us. Once support for a new sensor is added into the platform it is there from that release forward, accessible to any new user application.

Yes. The SoftHub has an extremely flexible MQTT interface designed specifically to be compatible with any of the dozens of cloud based solutions which provide a standard MQTT broker interface. In addition to giving you full access to all of the standard MQTT connection parameters, the SoftHub also allows you to modify the outgoing packet data being published on the fly. This is very important as most of these services will have very disparate and exacting data formats they will accept. The SoftHub's "JSON Filter/Format" facility allows you to take the standard JSON packets the SoftHub produces and reformat them into whatever specific format your target MQTT broker may require.

Yes. You can concurrently publish data to (and receive control data from) as many MQTT brokers as your application requires.

Yes. In addition to publishing data to external MQTT brokers, the SoftHub also provides an interface to send data to any IP address over a TLS encrypted socket connection. The Packet Capture Utility component of the SoftHub Platform allows you to set up your own LAN or WAN based servers to capture and further process your sensor data. Packets are sent in raw binary format and can be fully decoded into JSON or XML format on the Packet Capture server if desired. This solution is ideal for systems where no access beyond the internal LAN is allowed or desired due to security concerns.

Yes. You can configure the SoftHub to subscribe to control topics from any MQTT broker, console, or mobile app. These messages in turn can be mapped to your own defined "user events". SoftHub User Events in turn can trigger the evaluation of one of more rules in the configuration ruleset. Thus, from a cloud based MQTT broker you can perform any action the SoftHub is capable of, including actuating external devices via GPIO's, initiating Linux system commands or scripts, or even controlling and connected sensors themselves. The possibilities are really endless when it comes to remote control of your SoftHub devices.

Yes. Data can be logged to any filesystem accessible to the SoftHub host device. This could include the host device's internal storage as well as any externally connected storage devices. With an external storage device, many months of data can easily be archived. It should also be noted that data can be logged in either raw binary, JSON, or XML formats. Note that a utility, the LogFile Decode Utility, is provided to post process and decode any binary data. When logging data to the SoftHub’s internal storage, the binary format may be preferable in order to take up as little space as possible.

Users can choose between raw binary, JSON, or XML formats when publishing, sending, or logging data. To minimize network traffic or save disk space users may choose to send or log their data in binary format. Note that utilities are provided to subsequently decode the received or logged raw binary data into JSON or XML formats.

Yes. Custom data packets can be created in binary, JSON, or XML format. There are two types of custom packets that can be created. The first are aggregate “Report” packets where you choose the values you want to include. Included values can consist of any combination of current sensor data, cached sensor data, averaged sensor data, or current GPIO values. You can also use empty custom packets to signal a specific event has occurred. These packets can be mapped by their custom packet ID to whatever event you wish to report. Note also that when publishing to an MQTT broker the user can employ the SoftHub's “JSON Filter/Format” capability to create virtually any output packet desired.

Using an empty custom packet allows the user to subsequently map the custom packet ID to any event desirable.

Sometimes, due to security or other considerations, you may wish to not have your SoftHub device connected to the internet. Virtually all of the SoftHub's functionality can be partitioned off to a local LAN. Furthermore, if desired you can disable the SoftHub device's ethernet hardware completely. Examples might include using the SoftHub as a logger, using the SoftHub to directly actuate an external device based on some sensor threshold values, or using the SoftHub to trigger some system attached device (e.g. start a camera recording or an audio file playing as an alarm). Attaching a GPIO input to a button you can even have the SoftHub enable or disable the host device's ethernet hardware manually as needed.

By default, the SoftHub will connect to any sensor the user has selected and will start notifications for any notification capable sensor value that the user has enabled. If the connection is lost the SoftHub will continually try to reconnect. However, by disabling the “AutoStart Sensors” system setting, users can take complete control of their BLE sensors. In this mode users manually connect and disconnect sensors, and can directly read, write, or enable/disable notifications to/from any sensor value they’ve enabled. Using the manual mode essentially provides the user with the same degree of control they would have when writing their own custom application.

Yes. The SoftHub allows you full control of the hub device's GPIO output pins. You can read and/or write any pin you wish to configure. This can be used to actuate or control any nearby attached device(s). See the video titled "External Device Control" on our YouTube channel, "OmnIoTVideos", for a complete example showing a device being controlled via sensor value thresholding.

Yes. You can attach button controllers or monitor any GPIO pin you wish to attach an input device to. In turn, any monitored GPIO input transition can be used to asynchronously trigger the evaluation on one or more rules in the user’s configuration ruleset.

When user defined thresholds are exceeded, the SoftHub can be configured to perform a multitude of alerting functions. You can have the SoftHub device send email or SMS messages directly to one or more recipients. You can have the device actuate an external device such as a warning siren or strobe light. You can configure the SoftHub to send special "event detected" messages to remote MQTT brokers or OmnIoT Packet Capture servers. You can also configure the SoftHub to run any system command or script (e.g. play a recorded message over a connected set of speakers). In short, you can perform any number of functions that the SoftHub can carry out based on your own complex event detection or threshold logic.

When building your applications it is critical to be able to define complex "state" logic to detect exception events. The SoftHub incorporates a number of state objects you can use to evaluate whether these exception events occur. You can check sensor values (or averaged sensor values) against thresholds. You can check the value of input GPIO's. You can check time of day, day of week, month of year, etc.. You can check counter values, flag values, as well as sensor connection states. All of these state objects can be used and combined to build your own specific event detection Boolean logic statements.

Timers are used in the SoftHub to signal events which in turn may trigger the evaluation of one or more rules in the configuration ruleset. The SoftHub provides the user with a variety of different timer types. One-Shot timers will run exactly once and then queue their expiry event. Continuous timers will run to completion, queue an expiry event, and immediately restart themselves. Additionally, both One-Shot and Continuous timers can be configured as either relative timers or "time of day" timers. Relative timers are defined to expire relative to when they are started, e.g. "five seconds from now". Time of day timers are defined to expire at a certain time of day, e.g. "tomorrow at 5PM".

Yes. One of the more powerful features of the SoftHub is the ability to queue system commands and/or scripts to be run. These commands can be queued to run either concurrently or sequentially. You can use these commands to manipulate any attached or component hub device hardware (e.g. play a sound, start recording audio/video, enable/disable ethernet hardware, etc.), to transfer data to or from the device (e.g. send a logfile to a cloud server), to do system housekeeping (e.g. clear cache files when running out of disk space), or any number of functions. One added benefit of this functionality is the ability to switch between multiple SoftHub configuration files on the fly. To switch to a different configuration simply copy the desired configuration file to the SoftHub's "RuleEngine.xml" file and have the SoftHub daemon restarted. With the power to run system commands or script files you have the full power of the host operating system at your fingertips.

Security is a constant worry in the IoT space. The SoftHub itself only requires access to the outside world if you configure MQTT connections or connections to an OmnIoT Remote Packet Capture server. These are the only outside connections the SoftHub will initiate and they will only be initiated if you have configured them in your ruleset. Both the MQTT and Packet Capture Server connections provide you with the ability to enforce full TLS encryption as well as security certificate processing. For the most secure environments the SoftHub hardware can be fully locked down by connecting a button to the device and either (1) configuring the button to enable or disable ethernet hardware, or (2) configuring the button to act as a power off button allowing the user to then remove any attached storage, etc..

Currently you will need a Raspberry Pi 3, 4, or Zero/W running the latest version or Raspbian Lite to run the core SoftHub component. You will also need access to a Windows 10 computer to run the SoftHub Configuration Utility. To run one or more instances of the optional Remote Packet Capture service you will also need a Windows computer. Lastly you should have one or more supported senors or beacons listed on our Sensor Support page.

Yes. The OmnIoT SoftHub Platform is free for any and all non-commercial use. If you wish to re-sell the SoftHub, or sell a product that incorporates the SoftHub, please contact us in advance through our website.