The Internet of Things (IoT) has been growing at an incredible pace as of late.
Some IoT application frameworks expose a model-based view of endpoints, such as
on-off switches dimmable switches temperature controls door and window sensors metering cameras
Other IoT application frameworks provide direct device access, by creating real and virtual device pairs that communicate over the network. In those cases, writing to the virtual /dev node on a client affects the real /dev node on the server. Examples are
GPIO (/dev/gpiochipN) I2C (/dev/i2cN) SPI (/dev/spiN) UART (/dev/ttySN)
Interoperability (e.g. ZigBee to Thread) has been a large focus of many vendors due to the surge in popularity of voice-recognition in smart devices and the markets that they are driving. Corporate heavyweights are in full force in those economies. OpenHAB, on the other hand, has become relatively mature as a technology and vendor agnostic open-source front-end for interacting with multiple different IoT frameworks.
The Linux Foundation has made excellent progress bringing together the business community around the Zephyr RTOS, although there are also plenty of other open-source RTOS solutions available. The linux-wpan developers have brought 6LowPan to the community, which works over 802.15.4 and Bluetooth, and that has paved the way for Thread, LoRa, and others. However, some closed or quasi-closed standards must rely on bridging techniques mainly due to license incompatibility. For that reason, it is helpful for the kernel community to preemptively start working on application layer frameworks and bridges, both community-driven and business-driven.
For completely open-source implementations, experimental results have shown results with Greybus, with a significant amount of code already in staging. The immediate benefits to the community in that case are clear. There are a variety of key subjects below the application layer that come into play for Greybus and other frameworks that are actively under development, such as
are devices abstracted through an API or is a virtual /dev node provided?
unique ID / management of possibly many virtual /dev nodes and connection info
standards are nice (e.g. 802.15.4) and help to streamline in-tree support
non-standard tech best to keep out of tree?
userspace utilities beyond command-line (e.g. NetworkManager, NetLink extensions)
re-use machinery for e.g. 802.11 / 802.15.4 ?
generic approach for other MAC layers ?
in userspace via e.g. SSL, /dev/crypto
generally different protocol for each IoT framework / application layer
Linux solutions should re-use components e.g. SWUpdate
If you are interested in participating in this microconference and have topics to propose, please use the CfP process. More topics will be added based on CfP for this microconference.
This Microconference will be a meeting ground for industry and hobbyist contributors alike and promises to shed some light on the what is yet to come. There might even be a sneak peak at some new OSHW IoT developer kits.
The hope is that some of the more experienced maintainers in linux-wpan, LoRa and OpenHAB can provide feedback and suggestions for those who are actively developing open-source IoT frameworks, protocols, and hardware.
Discoball is a new point to point protocol for controlling and responding to events on remote embedded buses.
The protocol makes extensive use of existing userspace driver APIs for serial, I2C, SPI, GPIO and more. Furthermore, the protocol allows for a high level of configurability via the existing pinctrl, pinmux, and pinconf APIs.
As demonstrated with a custom DeviceTree file and the...