PowerShell to the Philips Hue API

If you have been to HPE Discover London 2015, Aruba Atmosphere 2016, CeBIT 2016 or you are going to Citrix Synergy 2016 you will have an opportunity to experience the Collaborate Cube(d).

https://twitter.com/hpecollaborate

I have been working with the Cube (making it do its song and dance) and related technologies for nearly two years.

This is an IoT thing.  But what we are driving and the place we are operating is not what most folks thing of as IoT.
This is about taking context (a person, a physical place, the capabilities of a space, and what is relevant at this moment in time) and tying them all together into a set of context specific actions (capabilities, events, controls - call it what you will).

The actions are relevant to this time and place.

One of the actions in the Cube is setting lights around the glass enclosure to red (the room is busy) or green (the room is available).

This sounds pretty simple on the surface.  You hook up a Philips Hue then you link it in, then you send some commands.  Actually, it is rather simple.  Except one part that is not entirely obvious to most folks (that aren't makers nor developers), and that is getting that first connection in the first place.

In helping to set the Cube up at three venues now, the Hue connection still seems to be one of the more complex things.  Especially when you Hue is brand new (which of course it is at each show :-S  ).

So, I have a little PowerShell script that will give you what you need to:

1. create a valid user in your local Hue bridge
2. get the information you need to connect to that

Of course I am using Octoblu to control the Hue.  Why wouldn't I?  There are some decent instructions for getting things set up. (see Step 4, then instead of 3 come back here, then 5).
But they send you off to an API document to sort out the one critical getting started piece, getting connected.  And then Philips hides their API guide behind a registration gate.  Double whammy.  Too much effort.  Walk away.

Here is my script, with comments, to get you started.
And after you get hooked up, there is most likely enough guidance in this script for you to simply play with the Philips Hue API.  ;-)

You can copy, save, and run this script and it should do everything you need.

# Associate your Hue Bridge with Octoblu.
# These are the setup things you need to do.

# find the Hue on your local network - this assumes you have only one
$hueIp = Invoke-RestMethod -URI https://www.meethue.com/api/nupnp
$ip = $hueIp[0].internalipaddress

$gatebluName = Read-Host -Prompt "Enter the name of your Gateblu"

Do {
    if ( !$hueUser ) {
        Write-Host -ForegroundColor Black -BackgroundColor White "Press the button on the top of the Hue bridge."
    }
    elseif ( $hueUser.error.description ) {
        Write-Host -ForegroundColor Black -BackgroundColor White $hueUser[0].error.description
    }
   
    Read-Host -Prompt "Enter to continue"

    #Hue create account
    $body = @{ "devicetype" = "gateblu#$gatebluName" }
    $json_body = $body | ConvertTo-Json
    $hueUser = (Invoke-RestMethod -URI http://$ip/api -ContentType "application/json" -body $json_body -Method Post -ErrorAction SilentlyContinue)[0]

} until ( $hueUser.success )

$apiUsername = $hueUser.success.username

Write-Host "Open the Philis Hue Thing in Octoblu interface"
Write-Host "Select the Gateblu instance to connect to"
Write-Host "Enter: $ip as the ipAddress"
Write-Host "Enter: $apiUsername as the apiUsername"

# Return the full state
$hueState = Invoke-RestMethod -URI http://$ip/api/$apiUsername -ContentType "application/json" -Method Get -ErrorAction SilentlyContinue

"Configured Lights:"
$hueState.lights | Format-List

"Configured Groups:"
$hueState.groups

# Full configuration
# $hueState.config

How can my Checkpoints be consuming more storage than the root virtual disk?

I explain this in the forums every so often.

Folks Create a VM, then a few Checkpoints.  And before they know it they are in that horrific Paused-Critical state with their VMs.

All because they are running out of storage.

In the end, it comes down to many folks not really understanding how this happened in the first place.

It really goes back to the fact that Checkpoints use differencing disks.  And each differencing disk has the potential of consuming as much disk space as its parent.

First of all; the warnings:
Be sure to only delete checkpoints through the Hyper-V Manager.
Do not attempt to manually delete AVHD files on the local file system.

Also, dynamic disks do not matter.  Whether your VM began with a dynamic disk or a fixed disk makes no difference. 
A dynamic disk just gives the illusion of consuming less space as the full potential of the disk is not realized.
But all differencing disks are dynamic, regardless if the parent was fixed or dynamic.

The root concept here is:
Each Checkpoint disk has the potential of consuming the maximum amount of disk space that its parent did.

For example:  Say you make a VM with the default of a 127Gb dynamic virtual disk (you have the potential of consuming 127Gb of storage). 

You install an OS and only 14Gb of physical storage is used. 
You then take a Checkpoint.  Now, you have the root 14Gb, and the potential to consume another 127Gb of additional storage.
 
Time passes and this Checkpoint consumes 50Gb of storage.  14 + 50 = 64Gb consumed.
You now take another Checkpoint.  And all kinds of stuff happens in that VM OS. 
You install Visual Studio create a database application, who knows. 
And with all that the current state is now consuming 80Gb of Storage.

You have only increased the disk use by 30Gb. 
But, with the Checkpoint tree in place you have now consumed 14 + 50 + 80 = 144Gb. 
Beyond the 127Gb limit of the virtual disk. 

Because of the potential of each Checkpoint being able to consume 127Gb (of VM disk change) all by itself.

Side by side with this is folks that use Checkpoints or differencing disks with the false idea that they will save storage.  Over time, they save nothing and add complexity.
Unless you are doing test and are constantly tossing away VM disks and creating new ones, using differencing disks with the argument of reducing storage use is a very false assumption.