Overlock – IoT Exception Tracking
overlock.io
overlock.io
Also, data-reduction is of prime importance for IoT devices, does Overlock have any tricks to play here?
Regarding data use - you're completely right. In previous production IoT projects we've worked on we've had in excess of 10X more debug data than actual useful information coming out, lest we're not able to debug problems! We've got a few tricks up our sleeve, the main one being that this only sends data when there is an exception.
[1]: https://ianskerrett.wordpress.com/2017/04/19/iot-developer-t... (Point 4)
Anything that will be remotely cost-sensitive (as anything produced in large numbers will be) will tend to be microcontroller-based.
Like you say, part of the solution is only sending the data that is needed. I would imagine another part of the solution that you could implement is some sort of shared string-table and hence transmitting only event-codes.
Compression is also certainly on the cards, but really comes in to its own once we have the clients running on resource-constrained devices.
We've got loads of other things we want to do in this space too, but we feel that these two are what's missing from exception tracking at the moment. We believe that IoT needs better tooling to get more reliable and secure.
I was, in part, responsible for creating a cloud logging service. I've never heard the term "lifecycle events" before, but it sounds like something where a device has a life and over time it has events occur, some of which are logged, and some of which are not. Whether or not sending these logs in a controlled way or not would not seem to matter much if the logging was aggregated in a centralized location. The "benefits" of not sending all log data from a device are not presumed to be that important, given bandwidth is cheap and storage even cheaper, increasingly over time for both.
Controlling what information is and is not sent from a device might be interesting (assuming correlation with this and this device, log to here), but you can't depend on the device to have the room for storing that stuff for long, or having much intelligence in sending it on (unless you run something like Particle's devices which have some cloud connected logic built in).
A dedicated edge device for this task might be interesting, but some IoT use cases won't have those edge devices available (at least for some time) on customer premise (home?), so logging to the cloud is presumed to be the only solution here. This reminds me, Microsoft just released some IoT stuff recently that may be related.
The question for how your product compares to existing cloud logging solutions will continue to resurface for y'all. Figuring out a good answer to that may make all the difference in how you go to market!
Some questions: FAQ reads that channel from devices to Overlock employs MQTT(S). I guess that means MQTT-SN, using TLS layer for authentication. Which auth methods do you support? Do you support validation of the client and the server? Can the gateway act as such also for Overlock or do devices need to open the MQTT channel directly?
That should probably be written as secure-MQTT, I'll get that changed. So we are just using vanilla MQTT over TLS.
We're currently using token-based authentication but certainly open to supporting other options. Did you have any suggestions?
I'm not quite sure what you mean about validation? In general, the gateway will already be in communication with the end devices over whatever protocol they're using. So it makes sense to log state etc. from the gateway for those devices. In that sense, the gateway does act as a gateway for overlock.