Part 1 - Use Configuration Events
First of all some background, if you are a user of Octoblu I am sure that you noticed a change a few months back to some of the Things. A new option appeared: "Use Configuration Events"
This is the exposure of device state for Octoblu Things. In the software world 'state' is a highly overloaded term.
As we look at the term state in relation to IoT devices there is a common pattern among most all the platforms - it really refers to a property or an abstract term to describe some setting change that might have a bunch of steps involved within it.
- desired state - this refers to IoT devices that can accept a setting and then do something to apply that setting. The state we want this thing to be in. You see this in many places from Desired State Configuration in Windows to the device twin model of Azure IoT Hub.
- reported state - many folks consider this the true state. The current condition that the system knows it is in.
In Octoblu - state is a property of a Thing or device. For physical Things it works like this;
- you set the state (define some key: value using JSON and apply that - it can be a known or unknown property).
- the Connector that is running on the Thing then gets a notification that its state has been changed.
- If the Connector knows how to interpret the setting it applies it.
- The Connector then reports back.
The new Hue light connector is a good example of a state based Octoblu Thing.
You must turn on "Use Configuration Events" to change any setting (light on and color for example).
And then - if you attach a debug node to the right side of it, you can see the output of all of its properties. More on this later as I expand on how I am using the device state capability in some of my work.
No comments:
Post a Comment