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.
Showing posts with label platforms. Show all posts
Showing posts with label platforms. Show all posts
Monday, November 28, 2016
Saturday, July 9, 2016
Evolving Interaction API and Scala in Smartspaces
It has been quite some time since I wrote anything in this blog. I started my own company in February, so have been pretty busy, without a lot of time for writing in this blog. I have about 4 posts in draft about building a sensor network in LUA on an ESP8266, my configurations of Raspberry Pis as sensor platforms, etc. Some day I will post those.
The evolution of Smart Spaces continues apace. Recently I started writing a new Interaction API that makes it simpler to model a physical space with sensors in it. Though Smart Spaces supported sensors in spaces, it was very low level in the Interactive Spaces days and I have been trying to up the abstraction game.
If you want to see some of what I mean in the file
https://github.com/smartspaces-io/smartspaces-sandbox/blob/development/models/smartspaces-interaction/src/main/scala/io/smartspaces/sandbox/interaction/test/testdescription.yaml
Eventually this model will be built in a GUI, but for now I just needed something simple, so created a quick YAML format.
Look for the section labeled sensors. This contains a listing of sensors and a description of them. Eventually this will include reference to a detailed list of what the sensor senses, but for now, there is just an ID, a name, and a description.
The section physicalLocations contains similar information about physical locations in the model. This model will eventually evolve into being able to describe the connectivity of the space, which rooms are connected to which other rooms.
The section sensorAssociations then links sensors to a physical location via the sensor and physical location IDs. The API has the concept of a Sensed Entity Model that will contain all the sensor values currently known to be valid for that Sensed Entity. An example of a Sensed Entity is one of the physical locations discussed above, but really, they could be anything that is being sensed, such as a person. One of these models is built for every item that can have a sensed state in the API.
One of the interesting parts of the Physical Location Sensed Entity Model is that it can model the occupants that are currently in the room. To do that, it is necessary to be able to model people. The descriptions of people known in the model are found in the persons section of the YAML file.
One of the ways that I am considering knowing where someone is in the space is caught up in the Marker concept. A marker is something that marks something else's location in the space. Often a marker will be something transmitting a signal, such as a BLE node or perhaps an RFID tag that is being carried around by a person. You can see this by looking at the markers section and the markerAssociations section. The sample file contains a BLE marker, identified as such with the format of the Marker ID, though there should probably be a type field in here specifying that it is a BLE device. This marker is then associated with a person. Marker detectors in the space, such as the sensor with ID /home/livingroom/proximity can then detect these markers and update the occupants of the room.
Yes, I know RSSI is not a great way of knowing someone is in a room, but it was a simple technology that allowed me to quickly get something working.
This API is very knew and rapidly evolving as I build a prototype system that lets me model what I want to model. My house is getting more and more sensors in it and I am using that to help drive the modeling possible with the API, rather than building the API in my mind, hoping that it is actually useful for the tasks I want to achieve.
You can browse through the current state of the code here:
https://github.com/smartspaces-io/smartspaces-sandbox/tree/development/models/smartspaces-interaction/src/main/scala/io/smartspaces/sandbox/interaction
Finally, you will notice the Interaction API is written in Scala. As I build more of the new modeling framework, I decided I needed a richer language for doing it in. So now Smart Spaces is compiled as a Scala project, though the bulk of the system code is still Java. No way I want to immediately rewrite all that code in Scala. New stuff, sure, you can see some simple Scala in the workbench and there will be more in the future. I have also done some of the examples in Scala as it is now possible to compile Activity and Library projects in Scala. Be aware, I am new to Scala, so I am sure I am not writing idiomatic Scala. Yet, anyway.
The evolution of Smart Spaces continues apace. Recently I started writing a new Interaction API that makes it simpler to model a physical space with sensors in it. Though Smart Spaces supported sensors in spaces, it was very low level in the Interactive Spaces days and I have been trying to up the abstraction game.
If you want to see some of what I mean in the file
https://github.com/smartspaces-io/smartspaces-sandbox/blob/development/models/smartspaces-interaction/src/main/scala/io/smartspaces/sandbox/interaction/test/testdescription.yaml
Eventually this model will be built in a GUI, but for now I just needed something simple, so created a quick YAML format.
Look for the section labeled sensors. This contains a listing of sensors and a description of them. Eventually this will include reference to a detailed list of what the sensor senses, but for now, there is just an ID, a name, and a description.
The section physicalLocations contains similar information about physical locations in the model. This model will eventually evolve into being able to describe the connectivity of the space, which rooms are connected to which other rooms.
The section sensorAssociations then links sensors to a physical location via the sensor and physical location IDs. The API has the concept of a Sensed Entity Model that will contain all the sensor values currently known to be valid for that Sensed Entity. An example of a Sensed Entity is one of the physical locations discussed above, but really, they could be anything that is being sensed, such as a person. One of these models is built for every item that can have a sensed state in the API.
One of the interesting parts of the Physical Location Sensed Entity Model is that it can model the occupants that are currently in the room. To do that, it is necessary to be able to model people. The descriptions of people known in the model are found in the persons section of the YAML file.
One of the ways that I am considering knowing where someone is in the space is caught up in the Marker concept. A marker is something that marks something else's location in the space. Often a marker will be something transmitting a signal, such as a BLE node or perhaps an RFID tag that is being carried around by a person. You can see this by looking at the markers section and the markerAssociations section. The sample file contains a BLE marker, identified as such with the format of the Marker ID, though there should probably be a type field in here specifying that it is a BLE device. This marker is then associated with a person. Marker detectors in the space, such as the sensor with ID /home/livingroom/proximity can then detect these markers and update the occupants of the room.
Yes, I know RSSI is not a great way of knowing someone is in a room, but it was a simple technology that allowed me to quickly get something working.
This API is very knew and rapidly evolving as I build a prototype system that lets me model what I want to model. My house is getting more and more sensors in it and I am using that to help drive the modeling possible with the API, rather than building the API in my mind, hoping that it is actually useful for the tasks I want to achieve.
You can browse through the current state of the code here:
https://github.com/smartspaces-io/smartspaces-sandbox/tree/development/models/smartspaces-interaction/src/main/scala/io/smartspaces/sandbox/interaction
Finally, you will notice the Interaction API is written in Scala. As I build more of the new modeling framework, I decided I needed a richer language for doing it in. So now Smart Spaces is compiled as a Scala project, though the bulk of the system code is still Java. No way I want to immediately rewrite all that code in Scala. New stuff, sure, you can see some simple Scala in the workbench and there will be more in the future. I have also done some of the examples in Scala as it is now possible to compile Activity and Library projects in Scala. Be aware, I am new to Scala, so I am sure I am not writing idiomatic Scala. Yet, anyway.
Wednesday, February 3, 2016
Announcing the Smart Spaces Project
The fork of the Interactive Spaces project is complete and I spent a very long time removing every use of the word "interactive" and replacing it with the word "smart".
Smart Spaces is now available at https://github.com/smartspaces-io/smartspaces.
Smart Spaces will not be just concerned about interactivity in a physical space, but also smarts. It is time to get interesting learning algorithms and rules based systems into the package. I also want to increase the abstraction level for talking about events happening in a physical space, both in detecting them and also affecting them. I'm not entirely sure what this will all mean, but it will be fun figuring it out.
The initial effort was merely changing the root package name from interactivespaces to io.smartspaces. I imagine I will be removing instances of interactive for some time.The next major project will be removing all deprecated APIs from the Interactive Spaces days and adding the ability to use MQTT for activity to activity communication, routes in Smart Spaces parlance.
Despite the low initial version number, 0.1.0, this is feature complete to Interactive Spaces 1.8.2 (1.8.1 runs in production in the Google Experience Centers) and is ready for deployment. I just numbered low as I want 1.0.0 to have some of the things that were wanted in Interactive Spaces for some time, such as ROS out of master/space controller communications.
The discussion board is found at https://groups.google.com/forum/#!forum/smartspaces.
Join us on this adventure.
Subscribe to:
Posts (Atom)