Listening to and acting on device state change in Octoblu

Part 1: Use configuration events in Octoblu
Part 2: Creating custom devices in Octoblu
Part 3: Setting the state of an Octoblu device from a flow

Now we are on to Part 4 - Responding to state changes

If you are catching up, check out the previous posts.

In this post I am going to listen to state changes of an Octoblu device within a flow and then respond to that somehow.

I have my starter flow from last this that looks like this:

Now, I want to create a second flow, where I am going to simply wait for my key 'rooms' and then process that data.  In this flow I am listening to state changes to myDevice.

To begin with your new flow should look like this:

Turn on 'Use Configuration Events' but you don't need to turn on 'Use Incoming Messages' like you did in the first flow.  In this flow we are only listening, not sending messages to or modifying the properties of (like the previous flow).

Open a second browser window, open your previous flow and click the trigger.
Notice that in the debug of this flow, you get the same debug output.  Because you are listening for changes to the device (in both flows).

Now, add some operator after your device in the new flow, set it and modify your JSON in the first flow to send something you can begin to act on.  Use {{msg.rooms}} to reference my example value, but make your own, set multiples, have fun with it.

Quite honestly, it is that simple.
And what you have built is this special Thing, where you can now save JSON formatted data, and then catch when it changes in some other flow.

one to one, many to one, one to many.....
And this data is all yours, formatted by you.

Next up, some of the screwy ways I have dealt with JSON data.

Setting the state of an Octoblu device from a flow

Building on what I began:

Part 1: Use configuration events in Octoblu
Part 2: Creating custom devices in Octoblu

In this post I am going to set and unset properties and their values on an Octoblu Thing, from a flow.

I am going to use the custom Thing that I created in my previous post, but you can use any Thing that has the option "Use Configuration Events".

Part 3 - Setting properties dynamically from a flow

In the previous post I created a custom Thing. And named it: MyDevice

Now I create a new flow, and I add that Thing to the Flow.

I select the Node (a reference to that thing in this flow) and turn on Use Configuration Events.  Notice the little gear.  This means that the behavior of this node in this flow is now different.

The next advanced thing that I am going to do is to add Trigger and JSON template nodes to define the message that is being sent and I am going to turn on Use Incoming Message on my custom node.

Let me back up here and explain a little..
Use Incoming Message takes whatever message is sent to the node.  If you don't turn this on, your device must have fields that you can set and then you can reference the values of keys using mustache notation or hard code values.

And then I am going to attach a debug node after my Thing.

And this makes a complete message circuit from start to end.

Be careful to pay attention to what you are doing - DO NOT create loops; they are very, very bad.  You will get your account suspended.

Now, to craft some JSON.

This is a very simple JSON body that we put in the template:
{
 "$set": {
  "rooms": "foo"
 }
}
Set the value for the key rooms to foo.

Start the flow, click the Trigger, and look for the Key 'rooms' in the message output.
In fact, explore that message output a bit.  Notice, these are all the settings / properties / state values of your device.

Now, change the JSON.  Change the key name, or change the value and see what happens.

If you want to remove the key and its values, we unset.
{
 "$unset": {
  "rooms": ""
 }
}
The $set and $unset are actually MongoDB commands.  And you can use others, such as $addToSet, $push, etc.  As long as you format your JSON properly.

Now, I have discovered that there are some key names that must be special to Octoblu and if you try to use them, nothing happens.  I am going to mention that in case you run into doing everything right, but nothing changes.
Is there a list of these special keys?  Not that I know of.  I was simply observing behavior...

Next up:  responding to state changes

Creating custom devices in Octoblu

Part 1: Use configuration events in Octoblu

This is something that I have been playing with for a very long time.
I directly use the Octoblu API to create my own devices.

I have copied existing devices, and I have created entirely new devices.
In this post I am going to create an entirely new device so that I can take advantage of the state (properties) feature to persist and evaluate data.

Why am I doing this instead of just reusing an existing Device?  Primarily because this makes a much easier to digest configuration change message on the listen side later on.  As there is a bare minimum number of properties.

Part 2 - Create a custom Octoblu device

Up front - I am a hard core Windows user (I do use Linux as well, but I have never used MAC) so my code example is in PowerShell.

Why would I create a custom device?
Well, my 'Thing' is an abstraction and not a physical device.

In practice, I have created 'rooms' in which I save data (aka set properties) from multiple sources or flows.  And I listen to specific data (property) changes of this device and then act on that data.

To do this there are a few things involved;

• your security uuid and token
• defining the security of the device
• defining any custom properties of the device (if you want)
• defining the base properties
• performing the POST
• looking at what you get back

Much of what is in the PowerShell below is all about building the object as a PowerShell object before it is converted to a JSON object.  Making sure that the data format is correct (arrays in the proper places, lists in the proper places, etc.)

# Octoblu User account (check your user properties)
$meAuthHeader = @{
    meshblu_auth_uuid = ''  
    meshblu_auth_token = ''
}


### build the JSON



# define the device permissions
$user = @()
$user += @{ uuid = $meAuthHeader.meshblu_auth_uuid }

$anyone = @()
$anyone += @{ uuid = '*' }

$empty = @()

$configureWhitelist = @{
    as = $empty;
    received = $empty;
    sent = $empty;
    update = $user
}

$message = @{
    as = $empty;
    received = $empty;
    sent = $anyone
}

$discover = @{
    as = $empty;
    view = $user
}

$broadcast = @{
    as = $empty;
    received = $anyone;
    sent = $anyone
}

$whitelists = @{
    configure = $configureWhitelist;
    message = $message;
    discover = $discover;
    broadcast = $broadcast
}

# define the schema of the device (behaviors and properties)

$properties = @{
    rooms = @{
        title = "sensors";
        type = "array";
        readonly = $true;
        items = @{
            type = "string"
        }
    }
}

$configure = @{
    Default = @{
        type = "object";
        properties = $properties;
        'x-form-schema' = @{
            angular = "configure.Default.angular"
        }
    }
}

$options = @{
    title = "Options";
    type = "object";
    properties = $properties
}

$configure = @{
    Default = @{
        title = "My Entity";
        type = "object";
        properties = @{
            options = $options
        };
        'x-form-schema' = @{
            angular = "configure.Default.angular"
        }
    }
}

$fields = @()
$fields += @{ key = "options.rooms" }

$form = @{
    configure = @{
        Default = @{
        angular = $fields
        }
    }
}

# wrap the above in the proper keys

$schemas = @{
    configure = $configure;
    form = $form;
    version = "2.0.0"
}

$meshblu = @{
    version = "2.0.0";
    whitelists = $whitelists;
}

# basic 'properties' (aka key:values) of the Device

$body = @{
    online = $true;
    owner = $meAuthHeader.meshblu_auth_uuid;
    type = "device:myDeviceType";
    name = "myDeviceName";
    city = "Redmond";
    meshblu = $meshblu;
    schemas = $schemas
}

# convert the PowerShell object to a JSON object

$json_body = $body | ConvertTo-Json -Depth 99

### create the device

$device = Invoke-RestMethod -URI http://meshblu-http.octoblu.com/devices -ContentType "application/json" -body $json_body -Method Post

$device | ConvertTo-Json -Depth 99

Now record the uuid and token of your device.  This is the ONLY time you get this token back, and you would need to generate a new one to know it again.

Also, you can set other properties such as a 'logo'.  For the logo the value must be an HTTPS URL reference to an SVG.

Next up:  Setting properties from a flow to this device.

Use Configuration Events in Octoblu

It has been a really long time since I have written a post and I need to get back into practice.   So I thought I would share a few things that I have been doing with Octoblu for a few months now.

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.

The Division and delta 20010186

There is no doubt that if you search on The Division for the Mike or Delta error messages you will uncover a sordid history of unhappy users that began with the beta and continues.

My son recently invested in this game only to pop it into the Xbox to be greeted by the "delta 20010186" error.

tl:dr

1. enable uPNP
2. If you have a router behind your modem, put your modem in bridge mode
3. Rerun the Xbox multiplayer network test (see the link below) - UBISoft requires this to test as 'open'

The long winded explanation:

If you search on this you will find all kinds of guessed at solutions.  From punching port forwarding rules in your firewall to putting your Xbox wide open for attack in a DMZ (seriously, these are the suggestions from UBISoft for Xbox connectivity)

Considering the number of folks that run into this issue, I really don't think UBIsoft understands it.

After thinking about this and spending hours troubleshooting, my conclusion is this: UBISoft blocks the game working if there is any reduction in the multi-player experience at all.

If you read the Xbox network descriptions, there should be grades in the experience where only certain features of the game don't function if the connectivity status is reduced from the full set.  And I can only speculate that UBISoft chose to not follow this guideline (could be by choose or ignorance - the result is the same).

There is a mysterious black box type issue on the Xbox side that puts the pieces together.
It is rooted in the output of the Xbox multiplayer network test and the resulting "NAT type".
This is not a setting that any human can impact, nor any resetting, cryptic combinations of movement through the settings menus or anything else can reliably impact.

From what I can tell, there are a couple issues going on here.

1. There is an expectation that uPNP is enabled on your router.

The multiplayer mode requires communication back to your Xbox. 
This is why there are port forwarding rules being suggested, and DMZ placement.  If uPNP is not available or not working, this this would solve that issue.

Adding to this is claims that I uncovered that stated that Xbox historically had issues with properly making the uPNP router when it is set to 'InstantOn' power mode.
Again, uPNP not working for a different reason.

Wrap all of these together and you have a combination of things that all impact connectivity back and the Xbox test for multiplayer connectivity puts you in the Moderate or Severe NAT bucket.

2. Beware the double NAT

No matter the setting on your router, if you have put yourself into a double NAT configuration, you will never be tested as 'open' by Xbox.

What is this double NAT?  It is when you hop through two IP address changes on your end of the network.
Frequently a double NAT happens in the IT world to isolate front end web servers or to further protect the corporate network by using two firewalls instead of one.

For the home network, the first NAT would be between your ISP (Comcast, ATT, etc.) and you - your cable modem (or FIOS modem, 'the modem').  The ISP network IP address range is converted once.
If you go straight from your modem to a switch, you are probably good.

The second NAT happens when you put a router behind your cable modem.  Thus you end up traversing another IP address change.  Thus a second IP change.  The key here is that the public side of this second NAT is private behind the first firewall of the modem.

This looks like this:  - modem - - router -
The problem is that any modifications you make to your router get trapped in this container .
Not even port forwarding or DMZ will work properly here unless your cable modem supports uPNP or does not offer a firewall at all ( most give a firewall and default you into this first NAT ).

The things here, simply put your model into 'bridge' mode.
What this does is turn off this first NAT, and your router gets the public side IP from your ISP instead of your cable modem getting it.
The impact here is that for most of us, this means only ONE device can plug into the modem.  As you only get one IP of the ISP network.

If you cannot put your modem into bridge mode, put attach your Xbox directly to the modem (using a switch to go around your router).
I am always assuming that there is still some network protection here, at least a basic firewall.  As just about anything can be hacked these days.



I always want folks to understand how things work, how things function and to tie as much as what I uncover together in a cohesive way.  That is what I have attempted to do here.

I hope it helps some folks, or solves the problem for others.
It is very frustrating to bring a new game home ($80 - $100) only to have it not work (fail to load) at all.  From the number of passed customers on the web, I am not alone.