As I near getting a deployment of the prototype of my company's product (http://www.inhabitech.com) in my home, I have been making quite a few changes to Smart Spaces to support the new usages I have. There have been modifications to the core open source system and to some items in the sandbox that I thought I would mention. This isn't an exhaustive list, but contains some of the highlights.
First let's start with something fun. Recently support for GPIO on a Raspberry Pi has been added to Smart Spaces through the Pi4J project. This was added to support reading a PN532 RFID/NFC scanner through SPI, but has also given the ability to directly control GPIO pins. This is leading to much better native hardware support for Smart Spaces. I will soon have example Smart Spaces activities that will use the GPIO pins to demonstrate how this is used.
Zeroconf/mDNS support is now a key part of Smart Spaces, with support for mDNS Service Advertising and Discovery. This is moving Smart Spaces towards being autoconfigurable, though it also still supports manually putting a network together..
Smart Spaces now has a lot of support for the Internet of Things protocol MQTT, all designed as I have built a collection of ESP8266-based sensor boards using MQTT to communicate with Smart Spaces. The Interaction API allows sensors to attach to the Sensor portion of of the API over MQTT (potentially with future CoAP support). The original MQTT client did not support automatic reconnect to an MQTT broker if the connection was lost, this has now been implemented, including automatic resubscription to MQTT topics registered with the client if not using MQTT persistent sessions, helping make the sensor and communication layer much more reliable. The Smart Spaces Master will also soon support an MQTT broker so that an additional one need not be installed in a Smart Spaces installation unless there is a reason to run an external broker. Future plans also include support for SSL-based connections so that a Smart Space can communicate with other spaces through the cloud or monitoring/alerting systems in the cloud.
The Core platform now also supports ReactiveX programming using rxjava. The core platform now contains an EventObservableService that allows components to register named ReactiveX Observable
instances for easy discovery by other components in the system that
want to observe events from those components. This is being used a lot
in the Interaction API that now publishes ReactiveX events for people
entering and exiting a room.This provides a uniform way of locating
event observables in an application.
The core platform no longer uses ROS for Smart Space
master and Space controller control communication. Though ROS support is
still in Smart Spaces, it did not work well in an environment where the
master or space controllers could go up and down. We would often see a
lot of XmlRpc errors in the Experience Centers at Google, and this
change was wanted way back then, but it has only finally happened. There
is now a TCP server running on each Space Controller that a TCP client
will attach to from the Master for control. This will evolve over time
so that the Master can start a reconnect schedule if it loses contact
with a Space Controller. This is evolving towards being able to run a
space without a master constantly running, but rather have automatically
starting Space Controllers as hardware comes up and down in the space.
All of the above changes are now findable on the master branches of the SmartSpaces github repos. If you want to track the evolution of the open source project, do be aware that the smartspaces and smartspaces-sandbox repositories have a development branch.
I am also planning on integrating Smart Spaces with the Eclipse Smart Homes project. This will make it easy to access a lot of hardware without needing to reduplicate that work in many cases.
