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.