How is a plugin like Philps Hue Supported - Support for Color Items?

Plugins & Plugin Development openHAB MiOS Binding
#1

I was hoping to continue to use OpenHab to control the Philps Hue Plugin on the Vera.

On OpenHab, I’d define OpenHab Hue binding to directly communicate using the following:

Color	US_Bed_Bloom	"Color Bloom"	(Lights,US_Living)		{ hue="27" }

Can I bind to the VeraPlugin (insted of via the OpenHab binding?

#2

Two issues at the moment:

a) I don’t specifically “map” the openHAB Color “Item” type to a string-form
This will impede it being mapped to anything in Vera but it’s fixable IF there’s a reasonably-standard way that it’s represented in a single Vera Hue StateVariable, as well as a single Vera Hue Action that takes a HSB (format?) and consumes it

eg. HSB (in CSV form as a State Variable?)

Many more details about a standardized [String] format would be needed, one that wouldn’t be specific to Hue (since, presumably, there will eventually be used for ZWave devices etc)

ie. I would like to avoid implementing Color magic that could only work with Hue.

b) I don’t have any Hue gear.
I can certainly mock it up, but if there is an absolutely-expliclt document that outlines what all the parameters are, and their formats (in graphic detail, range, decimal or whole values, negative’s supported?, etc, etc) then I can try and work out how to map it.

Looking at the attrs it’s exposing currently (Hue, Saturation) it seems to be missing Brightness, so the [combined] HSB values from openHAB aren’t going to map cleanly to anything in the Hue (yet)

If it exposes an “Action” that takes a HSB value (format?) then it might be possible to map FROM openHAB TO Vera, but the other way around would require a similar way to map what’s in Vera into openHAB’s [String?] representation of the Color Item type.

Anyhow, a few problems at the moment and more questions than answers, in part because there are no Vera UPnP standards for representation of Color-oriented stuff.

#3

One other quick thing, for new serviceId’s like “urn:intvelt-com:serviceId:HueColors1”, the mapping will default everything to be “String” and values will flow FROM Vera TO openHAB, but in their String representation.

For data to flow in the other direction, a set of MAP files need to be built that take the openHAB String-form data and MAP it to the appropriate UPnP Action call on a single Device in Vera (the same device that the value came from)

These MAP files can then be manually configured into the “command:” parameter of the respective Item declarations. This happens automatically, and internally, for common ServiceId’s like SwitchPower1, Dimming1, etc, but these internal defaults are missing (currently) and will need to be defined by someone familiar with the Plugin.

These default-mappings look like:

service/urn:micasaverde-com:serviceId:DoorLock1/Status=command:MAP(miosLockCommand.map),in:MAP(miosSwitchIn.map),out:MAP(miosSwitchOut.map) service/urn:upnp-org:serviceId:SwitchPower1/Status=command:ON|OFF,in:MAP(miosSwitchIn.map),out:MAP(miosSwitchOut.map) service/urn:upnp-org:serviceId:Dimming1/LoadLevelStatus=command:MAP(miosDimmerCommand.map)

#4

Thanks so much sir!

#5

A Philips hue binding exists and works well.
Except if the Vera plugin has more features than the hue binding, I don’t see any interest to use the Vera plugin.

#6

Mostly, my reasoning is I have rooms with Z-Wave motion sensors, and Z-Wave and Hue lights.

For an “instant” response when motion is detected, I was planning to leave the Hue on the Vera. However, I suppose I can re-architect the logic (it’s a lotta logic).

#7

Internally, the openHAB Color Item is using HSBType.

This will automatically parse from/to a CSV String like:
,,

eg. 300,100,100

Where:
is Hue 0-359
is Saturation 0-100
is Brightness 0-100

I’m not familiar with the Hue Plugin, but if it can natively provide it’s HSB Value like this, and also provide an Action call (eg. urn:intvelt-com:serviceId:HueColors1/setHSB(String <hsb)), then the tweaks to the openHAB MiOS Binding code would be minimal.

You may want to have a chat with @intveltr…

#8

I see three different patterns in this sample device state (the presets):





<state service=“urn:intvelt-com:serviceId:HueColors1” variable=“Preset1” value=“{“hue”:19474,“sat”:254}” id=“4”/>
<state service=“urn:intvelt-com:serviceId:HueColors1” variable=“Preset3” value=“{“hue”:0,“sat”:255}” id=“5”/>
<state service=“urn:intvelt-com:serviceId:HueColors1” variable=“Preset2” value=“{“xy”:[0.6169,0.3635]}" id=“6”/>
<state service=“urn:intvelt-com:serviceId:HueColors1” variable=“Preset5” value=”{“hue”:5000,“sat”:254}" id=“7”/>
<state service=“urn:intvelt-com:serviceId:HueColors1” variable=“Preset6” value=“{“ct”:343}” id=“8”/>
<state service=“urn:intvelt-com:serviceId:HueColors1” variable=“Preset4” value=“{“hue”:18200,“sat”:254}” id=“9”/>

PS - Do you want a Hue? I’d be happy to PM you a Gift Certificate for your hard work.

#9

Using RGB colors

The hue API provides three options for setting color:

[ul][li]hue and saturation[/li]
[li]xy in the CIE color space[/li]
[li]ct the Mired Color temperature[/li][/ul]

If you would like to use RGB color in your app, you will need to translate to one of these color settings options. Our SDKs provide utility methods to do this or alternatively you can build your own. For more information on this refer to ?Color gets more complicated? in ?Core Concepts?.

Also this seems like a good reference:

I’ll worth on seeing if I can get the answers here.

#10

Not too worried about the internal presets, as it looks like the code just calls the Hub and builds a JSON string to stash away for later use. The format of those isn’t going to be significant.

The Hue code is in Git:
GitHub - intveltr/vera-hue-plugin: Plugin for Vera home automation hubs, adds support for Philips Hue lights

so you could mod it with the new functionality and submit a PR to @intveltr. That’d be the fastest way to get any proposed mods back into the core code (although, there’s still a need to publish that back via apps.mios.com et-al … sigh)

The Plugin changes would likely be minor (add new setter to I_ and S_ files, and add “derived/calculated” HSB Attribute (in CSV format) everywhere a change is made, preset restored (etc))

PS: I’ve made a few tweaks (not published yet) to the Item file Generator to better handle some of your devices. For the Hue, thing like ColorTemperature, Hue, Saturation, and CurrentPreset will now be Numbers instead of String. Many of the Hue “FIXME” strings are now gone also, due to new internal defaults for them.

#11

BTW, thanks for the offer, but at this point I’m looking to reduce my tech footprint 8)

The family next door has 8x Hue BR30’s in their living room, and they look like a lot of fun, but I’d probably go down a sinkhole if I put more tech in the house. I am considering a Fibaro RGBW though, so it’s possible I’ll need the same (setHSB()/setRGB()) support down the line.

If you chat with @intveltr, and get him to add it to the Hue, I’ll add whatever is needed to the MiOS Binding to support it natively.

#12

BTW, I did a mockup of this in my DVE, and with only a few files tweaked it’s possible to have an MiOS String StateVariable “Bound” to a Color Item in openHAB.

The behavior of the [Classic] Sitemap UI for the Colorpicker is a little odd, but manageable. I’m not really sure how often someone would use that UI but, onward…

I have it taking a [HSB] Value from Vera, in the form h,s,b (eg. “120,30,100”) and it displays in the Colorpicker, as well as changing values in the Colorpicker and having them “call” a [fictitious] UPnP Action call:

    urn:micasaverde-com:serviceId:Color1/setHSBTarget(newHSBTarget=??)

I picked a neutral serviceId, in case others wanted to use it, but it’s living in a config file (not code) so it’s easy to have others.

I just need Thomas to merge my other checkin, then I’ll put this into the code so it’s ready for when we need it.

Changes include, adding “[tt]miosHSBCommand.map[/tt]”:

INCREASE=urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget(newLoadlevelTarget=?++) DECREASE=urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget(newLoadlevelTarget=?--) OFF=urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget(newLoadlevelTarget=0) ON=urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget(newLoadlevelTarget=100) _defaultCommand=urn:micasaverde-com:serviceId:Color1/SetHSBTarget(newHSBTarget=??)

Tweaking a few code files, and then building a sitemap entry:

sitemap demo label="Color Menu" { Frame label="Frequently Used" { Colorpicker item=StaircaseLightsModeStateForEnergy label="Color List" } }

and a test item:

Color StaircaseLightsModeStateForEnergy "Staircase Lights Mode State (Energy) [%s]" {mios="unit:house,device:95/service/HVAC_OperatingState1/ModeStateForEnergy,command:MAP(miosHSBCommand.map)"}

PS: Just ignore the weird State Variable I slammed it into, that was something that Vera put against my Dimmer back in UI4…

The odd part is that I’m assuming the “Color” information is another serviceId hanging off an existing [Vera] Light Switch. Looking at the generated Items files though, it looks like the Hue binding is creating 2x devices for each bulb (one “regular” Light switch, and another device for the color information)… this might throw a wrench/spanner in the works.

#13

Just an FYI – I’ve had great success with the OpenHAB Hue binding. It does virtually everything I wanted and as a result, I remove the Hue plugin from my Vera and manage them strictly via OH now.

Just a data point, for those curious

Gerry

#14

This has been added under openHAB PR #2184, and has been merged in this morning.

It will formally be available, as part of the 1.7 Nightly Build on Cloudbees tonight.

It works like the example above.

For those interested in trying it in advance, I’ve manually created an Untested build of the latest stuff on 1.7, which contains all the fixes merged so far (Color, Performance work, etc)

#15

Awesome!

Until I move my motion sensors (on Vera), I need the Vera to be able to switch on lights (Z-Wave or Hue) on motion. I like my sub second performance :wink:

#16

Try it, you might be surprised how quickly it turns it around.

#17

I’m having some trouble moving to OpenHab rules (not having ever programmed in Java before)

I’ve gotten quite use to PLEG shorthand (as shown in the below PLEG code)…the longform code is making it hard to follow the logic of rules.
http://1drv.ms/1FZZp7V

Loving OpenHab for reporting and Graphing :slight_smile:

My next step is some cool UI/SiteMaps…then on to rules.