IoT solutions usually need to be learning solutions

 The value in LoRaWAN solutions comes from allowing people to take actions to address issues with things or control things. In many cases while people know what they want to achieve in a business sense they often can not initially be as precise about: exactly what data they need, at what frequency, with what accuracy, with what fidelity; how that data is best converted into meaningful information that can be used by business or non-technical people, to affect what they actually do. 

So systems need to be set up initially to learn about these things and then continually be refined to achieve an optimal solution. This will often require evolving sensors, devices, fittings, on device logic/AI, device messages, network components, back end systems logic, scoring, thresholds, etc. It is effectively an agile and iterative process but it needs to take place across: hardware, firmware and software.

Too frequently people try too early to fix an aspect of the system and then work around that as a fixed constraint. What is needed initially is a solution that can capture information and allow it to be analysed in a range of ways e.g. using basic instrumentation, analyticals tools and allowing the application of data science to filter, aggregate, compare, correlate, interpolate, extrapolate etc. and compare calculated values (actual and predicted) against observed data.

What is learned will allow one to understand how to calibrate sensors (modes, frequency, thresholds etc.), configure devices, develop interpretations, present information, identify incidents that require people's attention.

This has important implications for the overall process and sequencing of solution design and development.  Usually a highly iterative approach will make sense with cycles of: user experience and improvements in data analytics and devices (and within that iterations focused on improving the data, analytics, device). So the systems will be usually be developed as follows:

• Get an initial system operative 

• common business objects and associations that provide initially an information  harness or context for readings and controls. 

• gather data from real world entities in real world environments

• share access to information with expert users

• Analyse the data, rules, sensor parameters, etc and convert data into meaningful information e.g. accurate, reliable, credible etc. 

• diagnose the cause of inconsistencies between what we know of the real world and what the solution says

• use the diagnosis to recalibrate and reconfigure the solution

• Polish user experience so users can get the value they seek in the way they want it

• Operationalise the system

To achieve this evolution, avoid stranded pilots and minimise wasted effort and cost, it is critical that the platform on which the solution is built is end to end and configurable at all points.

LoRaWAN in a box overview

 Many see opportunities to better look after and control their remote assets. Making this viable requires significantly reducing the costs, complexity, risk, time, etc. and obviating the need for expertise in a raft of technologies across several domains (electronics, firmware, networking, etc.) most people don't have (or want). People also need confidence they can scale without commensurately scaling costs (e.g. because some rapacious Telco has a lock-in) and integrate it into a suite of other applications. 

LXC-in-a-box allows you to get readings from devices and to control devices out of the box. It allows PoCs to move quickly to Pilots and then on to production solutions that integrate into an enterprise's ecosystem. 

It doesn't pretend you can build a highly optimised large scale solution codelessly and it doesn't require you to try and pretend a generic Swiss-army device a) does precisely what you need; or b) will be the lowest cost component for you needs. Rather it allows you to choose any link in the technology value chain and optimise it. You can do that optimisation when it suits you. 

The advantages to the typical user are that LXC is:

• simple — works end to end on day one. You require no knowledge of, or investment in, technologies for: network (including LoRaWAN), electronics, firmware, etc.

• low risk — all the little steps that have to work together to get remote sensors and controllers to actually solve business problems in the field for real users in a production environment are done.

• scalable — it supports thousands of devices, millions of messages.

• cost effective and efficient — extremely low initial cost and excellent cost visibility.

• customisable and optimisable — you can reduce: equipment costs, size, energy demands or add extra capabilities; you can extend the network; you can optimise and simplify the user experience (data interpretation, analytics, alerts)

• learning — automatically continuously learns about coverage, congestion, what is normal, etc.

• proven — production systems use it for: animals, assets, environment,control, etc.

• integratable — you can integrate it with other systems via basic APIs. 

• extendable — you can add new sensors, devices, readings, scoring, logic, etc. 

When you get ‘LXC in a box’ you get OTB an end to end system (device, gateway, web system, phone app) and you can see information about your thing(s): what is measured, what is normal etc. Your thing(s) are organised in groups, associated with users, teams, properties, places, areas, etc. Your device(s) can be configured and controlled and there are a range of automated alerts.

We think it is THE answer to getting from the trough of disillusionment or the valley of despair to the slope of enlightenment and the plateaux of productivity.