As part of my work for brewpi, I created a framework for the Arduino/Spark that is basically a object container that you dynamically configure at runtime ithings you want it to manage. Ok, that sounds pretty abstract - so, what does it do?
For example, you can set up various types of sensors (temp, humidity, pressure etc.), actuators (e.g. digital pin, OneWire 2413 etc…) and various local control loops (e.g. keep this temp sensor in range by activating these head/cool actuators.) The key thing is that this setup happens at runtime - you don’t have to write code to make this happen.
The key motivation is flexibility - rather than having to write code and upload a sketch to instantiate the sensors you want and configure the pins etc…, then log data at a set interval etc., all of this is managed at runtime using the same standard sketch. Since the device is configured at runtime, we could have a webapp that allows you to click “add temp sensor” - you then plug in a new temp sensor to the bus and it then added to the managed devices.
Some other highlights of this framework:
small - the core framework is around 12K of flash on an arduino, and can be made smaller with removal of optional features (e.g. system profiles, multiple control loops.)
supports regular logging of data - the value of each object can be logged at regular intervals.
all configuration data is persisted, so once configured, the system continues behaving that way until you change it, even after power off.
easy to add new types of objects - there is a simple API your object needs to implement to fit in with the system.
supports multiple control loops, with each loop executing with the specified period (e.g. every second)
supports system profiles: the same device can be put to use in different ways by storing each configuration as a profile. The profiles to run can selected and changed at runtime.
My goal is to put an end to the need to write code when wanting to configure a spark/arduino for monitoring and control tasks - so that non-programmers don’t have to get involved compiling and uploading firmware. With this framework uploaded to the spark, users could then forget about coding and focus on connecting and configuring the devices they want to control. For example, when paired with Temboo, there would be no need to upload the sketch - the Temboo webapp could configure the spark directly, and changes would not need to interrupt monitoring, as would be the case with flashing new firmware for each change.
I hope I explained this well enough. How does this sound? Let me know if this sounds interesting to you
Sounds interesting. Do you have a link for that? I found this Unified Sensor Driver.
The framework is less about the types of objects you manage (since that’s really the domain of the application). It’s more about the management and organization of the objects, and allowing them to be created and configured at runtime.
That unified sensor driver would be a good candidate to bundle with the “standard” application since it covers a lot of the typical sensors required.
I’ve also written python code that talks the low-level protocol of the framework and exposes a higher-level (python) api. Ultimately it will expose these objects as a high-level web service for RESTful integration, notification of state changes etc… and integration with other services (IFTTT etc.)
@mdma, that’s exactly the one! I completely agree with your assessment and I really like what you are creating, especially the runtime configuration approach. Stop taunting and please let me know when you will release the code
my hope is that this flexible framework can flourish on it’s own, so I will make the framework independent from the current brewpi application. In the code, the framework is well isolated from the application, so this is mainly about moving files around in github.
porting to the spark: the code already runs both on the arduino and cross-compiled to the desktop, so this will be straightforward.
bundle various libraries to build the the “standard” application - this would include libraries for all the common devices that people want to interface with the spark. Suggestions welcome!
To me, this is an exciting idea, one that I envisage would make using the spark in the internet of things even easier.
I’ll sketch out the current plans and thoughts - if you see a place where you’d like to help please chime in!
I’ve been looking at component-js with a view to using that to build a UI. The framework is inherently component based, so building a SPA with a component-based UI seems to be a natural fit.
I’ve also not thought much about how we can make the back-end service also pluggable and configurable via the UI. E.g. different data loggers. I’d planned to log data to influxdb, a timeseries database, but really there is wide scope for all kinds of plugability and integration with third-party services.
Here’s an outline of the general plan from here on out:
I take vacation for a month!
I code up the first end-to-end feature. This will be controller recognition - plug in a controller (e.g. turn on a spark loaded with the firmware, or plug an arduino into the serial port), and it’s displayed in the UI. Having it end-to-end means that all major pieces are in place - the firmware, the cloud service, the UI, unit and integration tests, build system etc.
Once the end-to-end feature is done, it will serve as a template for building additional features, so then I can open up the project for contribution!
I hope that’s clear, if you have any thing to add just drop it in here!
Hi there. Photon newbie here. Has this been integrated into the Photon firmware by any chance? I’m looking to collect sensor data from a variety of sensors and simply upload it via REST to an event collector. It would be super to just have a generic way of doing that with minimal per sensor configuration. Thanks.
When will you be sharing?
