Device can be "handshaked" on first payload

[oscgonfer]

This issue is to discuss the possibility to "handshake" a device based on a publication of data (actual sensor data) and to not need the hello. This is the step in the onboarding where we "wait for device".

This will help us in two ways:

1. Avoid the hello bottleneck in case something happens in the hello payload
2. Potentially fill up some data already for when the user ends the onboarding process and goes to the kits page

In principle, right after receiving a valid configuration (SSID + PASS + Token) and a successful connection, the kit will immediately send a hello, take a reading and send it.

This will also help us in the initial check of the device itself, which can be done in the onboarding stage. Potentially, we can even think that the hello OR the data payload can trigger the handshake, in case we don't want to risk moving completely away from the hello part.

[pral2a]

TL;DR

Yes, the 'Hello' protocol is no longer needed in our current firmware setup.

Detailed Explanation:

1. Handshake: Initially, 'Hello' confirmed device communication independently of sensor data, in case it was not available: i.e. sensors are warming up.

2. Heartbeat: The 'Hello' served as a device health check when sensors were inactive: i.e. sleep mode for power savings

3. Security: A plan for 'Hello' to aid in periodic key exchanges (i.e. Diffie-Hellman) to increase security: i.e. current token is very weak. Current MQTT over SSL and longer device tokens might be sufficient.

Conclusion: Given these developments, maintaining the 'hello' handshake isn't justified in our current firmware system architecture. We can always come back to it or merge it with ‘hardware_info’.

[oscgonfer]

I confirm that this is now handled in @timcowlishaw #246 PR

We should keep @pral2a things in mind in #286 though. @timcowlishaw could you add a small mention to it?