New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web of things servers for microcontrollers #14

Open
draggett opened this Issue Jun 7, 2015 · 3 comments

Comments

Projects
None yet
3 participants
@draggett
Copy link
Member

draggett commented Jun 7, 2015

This is to track proposals for implementing open source Web of Things servers for microcontrollers. I would expect these to be separate GitHub projects, but to share a common test framework.

The idea is to create resource constrained servers that can run on microcontrollers for use as IoT devices directly connected to sensors or actuators, or as gateways to IoT technologies such as Bluetooth or ZigBee. It would make sense to start from existing open source servers. Some questions to be addressed include

  • What open source projects to start from?
  • Which programming language to use, e.g. C, C++, Lua or Python?
  • Which scripting languages to support if any, e.g. JavaScript, Lua, Python, etc.?
  • Which protocols to support, e.g. CoAP or MQTT?
  • What security mechanisms it supports?
  • Which binary encodings to support, e.g. CBOR or EXI?
  • Whether it supports remote updates, e.g. for security fixes or capability enhancements?

A resource constrained IoT device may just support a fixed set of "things" without any dependencies on other "things", for example a temperature and humidity sensor such as the DHT11, or a switch that operates a light. This allows for a really stripped down Web of Things server, where the logic of the things it hosts is coded in the same language as the server, e.g. C.

A more powerful device may support a scripting language and allow scripts for things to be uploaded to it subject to appropriate security mechanisms. One possibility would be a server written in C + Lua. Such a device may also play a role in discovery, and allow things with dependencies on other things that are hosted on other devices.

If you are starting such a project please post a response to this issue telling us about your project and including a link to it.

@draggett draggett added the help wanted label Jun 7, 2015

@jbeard4

This comment has been minimized.

Copy link

jbeard4 commented Jun 7, 2015

SCXML is a W3C standard for Statecharts, a visual modeling language for safety-critical embedded systems.

I am working on an SCXML orchestration server for microcontrollers, code-named "MicroSMaaS". This work is based on the State Machines as a Service protocol (SMaaS), and the SCXMLD orchestration server. SMaaS provides an HTTP and REST-based protocol for interacting with state machines over a network, and SCXMLD provides a reference server implementation of SMaaS.

I am building a proof-of-concept SMaaS server for the ESP8266 running the NodeMCU Lua firmware. This work involves porting the SCION SCXML implementation from JavaScript to Lua. I will then attempt to use NodeMCU's built-in HTTP server to create an initial SMaaS server implementation.

For devices with less memory than the ESP8266, it would be possible to develop an SCXML implementation with an efficient representation in hardware. Initially, this would be an SCXML-to-C compiler, and then eventually targeting hardware description languages such as VHDL or Verilog. Some modifications would need to be made to the SCXML specification to support a micro-implementation. Primarily this would involve exchanging JavaScript for an alternate scripting language with low memory requirements.

The SMaaS protocol may also be adapted to use a more lightweight protocol, such as CoAP instead of HTTP.

@jollen

This comment has been minimized.

Copy link
Contributor

jollen commented Jun 8, 2015

When a constrained IoT device may just support a fixed set of "things" without any dependencies on other "things", and consider time-series style sensors (providing data streams) for example temperature and humidity sensor.

There is a use case that have been used in one of my WoT open source projects. This could be summarized in the following architectural pattern.

2015-06-08 12 01 10

  • In this case, constrained devices has a built-in Websocket client, and plays the role of sender client.
  • There must be a Websocket broker (server) which could be deployed as a cloud server instance, or a home IoT gateway.
  • The form of the viewer client could be in Web apps (W3C HTML5), iOS app and etc.

This architecture is trying to give a general purpose framework for very constrained devices to stream series data over WebSocket to user clients. In general, a constrained device doesn't need to contain a built-in WebSocket/HTTP server. The architecture is also a proposal for multiple connections of user clients. Whe a constrained device has a builtin-in WebSocket server and used as a data server, it may not be able to accept and serve too many connections because of it has less memory or other limited hardware resources.

Use Scenario

To send the data over the Internet, IoT devices should use the url below to establish a connection with the server.

ws://[hostname]/object/[name]/send

You must specify an object name and your hostname. For example:

ws://wot.city/object/554785c7173b2e5563000007/send

To receive data from the server, the frontend should use the url below to establish a connection with the server.

ws://[hostname]/object/[name]/viewer

Also, you need to specify the object name and hostname. For example:

ws://wot.city/object/554785c7173b2e5563000007/viewer

In the perspective view of a virtual object, the object has two significant resources, send and viewer. send is to send device data to WebSocket broker server.

I would like to contribute a draft implementation to the separated GitHub projects of this issue.

@draggett

This comment has been minimized.

Copy link
Member

draggett commented Jun 9, 2015

Web Sockets may be impractical on microcontrollers with limited memory. MQTT is a popular pub-sub protocol using TCP for constrained devices and can be used to stream sensor readings to a server in the cloud. CoAP can be likened to HTTP but using UDP, and there is work on a pub-sub mechanism, see:
https://datatracker.ietf.org/doc/draft-koster-core-coap-pubsub/

Another approach is to use a hub server that sits behind the firewall+NAT and relays the sensor stream to the cloud. The hub could, for instance, have drivers for IoT protocols like Bluetooth or ZigBee. We're looking for volunteers to help with writing such drivers for common classes of devices for which there are well defined profiles. The hub could be based on the NodeJS server in this project or the Go (lang) based server we plan to start as another sister project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment