HTTP vs. Custom TCP Protocol for Querying Device via Wi-Fi

[TobiasUhmann]

Hi there,

in our current project, we need a way to test our hardware after it has been built and sealed. Tests include toggling LEDs, querying microphones and motion sensors, etc. The sealed device cannot communicate via cable and we cannot remove the test code after the device has been sealed. We will either add the test code in a test partition or as part of the OTA updatable firmware.

As for the test code, it shall start a server that the test client can connect to via Wi-Fi. The test client might be a script that runs a sequence of test commands, e.g. turn LED on, turn LED off, enable microphone, etc., or a UI app where the tester can perform those commands manually.

Now, the question is what protocol to use to communicate between the test client and server. The simplest way might be to start a TCP server that handles TCP commands, i.e. we would implement our TCP test protocol that supports above mentioned commands. Alternatively, we could start an HTTP server and implement our test protocol on top of HTTP. This also seems to be the way the Wi-Fi provisioning and the following "local control" examples work by using protocomm: https://github.com/espressif/esp-idf/tr ... local_ctrl. But I wonder if HTTP is the right choice, since we don't need most of its features like methods, headers, and the microphone and sensor data we request is binary. On the other hand, we have the requirement to encrypt the traffic beyond WPA, which is easy using HTTPS. Also, an HTTP API would be easy to test and debug.

After all, I would like to know whether we should start a TCP or HTTP server or whether there's another protocol that better suits our needs.

Edit: I also thought about using gRPC due to the binary data, but that would add another layer to the stack and I'm not sure about ESP-IDF's HTTP/2 support - there seemed to be an HTTP/2 example in the past that has been removed.


Thanks for your advice!

[ESP_Sprite]

Honestly, that sounds like bikeshedding - way too much architectural investment in an effectively throwaway application. Pick the tech you're most comfortable with for this and be done with it.

[TobiasUhmann]

Thanks for your impression. Unfortunately, we cannot consider the test code as throw-away software. But if there's no obvious solution I'm missing, I will start out with the HTTP approach, due to the simplicity of encrypting the traffic.