Standard Firmata through websockets

[d-a-v]

Websockets allow a WiFi-enabled Firmata device to be natively controlled by a web browser.

An example is provided:

• esp8266 arduino sketch (using two external libraries, see in comments)
• a poor javascript proof of concept allowing to blink the arduino builtin led without further setup
  (sorry not to be an html5 expert)

This PR is used for bromagosa/Snap4Arduino#297
This PR relies on #455 (edited)

[soundanalogous]

Can you update this PR to exclude all the changes that involve: #include <utility/ExampleStandardFirmataCommon.h>. I'd prefer it only includes the changes relevant to adding websocket support.

[d-a-v]

@soundanalogous This PR is updated

[soundanalogous]

Had some time to think more about this proposal. I definitely like the idea of websocket support for Firmata and have pondered it several times over the past few years. I even created a Firmata client library that relied on websockets (via a serial to websocket server).

Historically we have not included architecture specific example with Firmata. I think this proposal is off to a good start, but what I would like to see is support (or at least a plan) for additional boards such as some of the newer Arduino WiFi boards (such as the Nano 33 IoT and MKR WiFi 1010) which should have enough RAM and high enough clock speeds to perform well with a websocket implementation.

[d-a-v]

but what I would like to see is support (or at least a plan) for additional boards such as some of the newer Arduino WiFi boards

Do you think of a particular PAL¹ for websockets, or should we make a new one with specific names ?
From what I understand of what is necessary in this websockets use case, it is not more than what's in the event function:

• connected event
• disconnected event
• receive event (binary? text? both? data, len)

and a write function (binary? text? both? data, len)

Underlying protocol consideration (ping, ...) would be left to the PAL implementer.

¹ Protocol Abstraction Layer

[soundanalogous]

Yeah, something like we used for BLEStream as an abstraction layer that works with different BLE libraries.

[d-a-v]

That's a stream without events.
This is partly done thanks to the pipedstreams used in this PR's example.
I will isolate and hide details and offer a Stream as websocket API.
I like the idea very much, it looks like a previous attempt I made for websockets in posix world.