arduino icon indicating copy to clipboard operation
arduino copied to clipboard

Standard Firmata through websockets

Open d-a-v opened this issue 5 years ago • 6 comments

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 https://github.com/bromagosa/Snap4Arduino/issues/297 ~~This PR relies on #455~~ (edited)

d-a-v avatar Jun 01 '20 21:06 d-a-v

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.

soundanalogous avatar Nov 24 '20 00:11 soundanalogous

@soundanalogous This PR is updated

d-a-v avatar Nov 26 '20 15:11 d-a-v

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.

soundanalogous avatar Nov 27 '20 19:11 soundanalogous

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

d-a-v avatar Nov 28 '20 22:11 d-a-v

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

soundanalogous avatar Nov 28 '20 23:11 soundanalogous

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.

d-a-v avatar Nov 29 '20 00:11 d-a-v