AtmoHue - BETA - Philips Hue support for AtmoLight & AtmoWin (2 Viewers)

[Rick164]

Ok - not a big difference - so what would be needed is impossible to acomplish - a calculation of teh content before it is send ... I'm sure Lightning loves task like crwaling a videstream parallel and beforehand it being send. No - honestly - I have no idea how teh player is implemented in MP but - as with Atmolight - it seesm to have a small delay - can this be managed? In the delay can be increased postprocessing could become a visible preprocessing.

Think Lighting is always up for a challenge

What I'm wondering - what is the difference between Transition Time and Send Delay? Am I correct that if I set the send delay to 0 (I tried it ) and play around with the transition time only around 150ms it starts tobrig small flash - but - more interesting - if i select a scene with fast changing colors i can see that when the sequence ends the data is processed from teh fast szene - meaning - if teh send delay is smaller than teh transition time it will at one point floof the bridge or where is the dtata hold? And - if it is like I think - what sense does irt make to separate the transition time and the send delay?

The Send Delay is to throttle the maximum number of commands we send to the bridge per x ms, because if were to send them with the actual frame rate of like 50fps for instance the bridge might not be able to handle it.
It also depends on the content and how well the bridge responds as that seems fluctuate for unknown reasons, could be Z-wave protocol delay / wireless interference / or just maxing out Bridge resources.
The Transition Time is something we send along a color command and is handled internally by the Bridge, basically it queues up color commands and phases them in but if we were to push it too many commands it will not always know what to do (starts flickering or get flooded).

Adopted the Win Hue 2 color calculation code which is based on HueApi examples and testing it out now, it does more corrections but does reset any custom calibrations that may have been set as it handles it differently.
Also looking into reducing the command size, so would only include the color and nothing else to see if that helps speed things up.

For fun started looking into Arduino + Z-Wave as an Hue alternative, it does seem possible and potentially a bit cheaper as well:

http://code.mios.com/trac/mios_arduino-sensor/wiki

Basically you have an Arduino connected to Ethernet and you forward it commands just like now but since it's completely open-source and the hardware can upgraded it should have some very nice response times in theory at least
Definitely not as easy as plugging in an Hue but still looks pretty good and you can also control other appliances with it.
But gonna look into some simpler alternatives to Hue and support those in AtmoHue as well, if anyone knows any good ones that can also be controlled over Wi-Fi just let me know

/edit: found these:

http://www.limitlessled.com/

Fairly new but seems to not have the epilepsy restrictions and is open-source, too bad they only make bulbs

 

[TheBatfink]

Must be the bulbs then, I dont see smooth transitions either, it just changes. Maybe I will give up on Hue bulbs with live TV, my main reason for using is to be able to set scenes and change brightness using keyboard shortcuts as I can map these to my Harmony remote

 

[Rick164]

Experimental version attached in this post, it increases the response times slightly however you lose the ability to change settings (temperature/delay etc..) once it has send its first command during AtmoHue runtime at the moment.
So if you need to make any changes best to restart AtmoHue, used these settings for testing:

- Hue Send Delay 250 ms (can try lower values)
- Transition time 250ms (can try lower values)
- In AtmoLight configuration you can try setting the Hue minimal color difference to 0, this speeds it up a tiny bit.

Really pushing the limits of what the Hue Bridge can handle at the moment but will see if this keeps it stable enough

Changelog

AtmoHue 0.0.68 - experimental version

- Keeps command alive during runtime
- Reduced command size to Hue Bridge, only includes color after first color command and drops the rest.

 

[pur_berger]

Ok - with 0068 - Transition Time 0, Send Delay 15ms, color difference 25

It's quite where it shoudl be

Edit: wrong Video

 

[Lightning303]

I have no idea how teh player is implemented in MP but - as with Atmolight - it seesm to have a small delay - can this be managed? In the delay can be increased postprocessing could become a visible preprocessing.

The delay is actually negative. AtmoLight gets called as soon as a frame is rendered. It then resizes it (to typically 64x48 or 64x64) and converts it into a byte array. This byte array then gets send to all enabled target handlers (e.g. AtmoWin and Hue). In the AtmoWin handler for example it gets send directly to AtmoWin. In Hue the array gets analyzed for the average color and then this color gets send to AtmoHue. This all takes no longer that 1-2ms. And as you saw with AtmoWin, you actually need to add delay, because otherwise your leds change color before your tv screen does.
So any delay you see in the hue lights is comming from Hue itself. There are limitations in Hue that do not allow for fast color changes. It seems Phillips is afraid of an epileptic person to get an attack from their product.

Think Lighting is always up for a challenge

Sure, lets build our own videoplayer

 

[pur_berger]

So under the line - WE NEED SLOW TV's

 

[Rick164]

Ok - with 0068 - Transition Time 0, Send Delay 15ms, color difference 25

It's quite where it shoudl be

Edit: wrong Video

Now we only need to wait till Lightning finishes the video player
Gonna merge the changes and add live settings back in, should have an stable version out somewhere tomorrow

Also did some testing with the WinHue 2 color correction code and wasn't pleased with the results, colors seemed a bit washed out so put off integrating that for now (maybe once they release 3.0).
Think the colors are already more or less what they should look like at least for the bloom / iris / strips, too bad the Hue Colored Bulbs are so freaking expensive (60 euro a piece seriously...) as I would have gotten one for testing otherwise.

 

[pur_berger]

Ok - not a big difference - so what would be needed is impossible to acomplish - a calculation of teh content before it is send ... I'm sure Lightning loves task like crwaling a videstream parallel and beforehand it being send. No - honestly - I have no idea how teh player is implemented in MP but - as with Atmolight - it seesm to have a small delay - can this be managed? In the delay can be increased postprocessing could become a visible preprocessing.

Think Lighting is always up for a challenge

What I'm wondering - what is the difference between Transition Time and Send Delay? Am I correct that if I set the send delay to 0 (I tried it ) and play around with the transition time only around 150ms it starts tobrig small flash - but - more interesting - if i select a scene with fast changing colors i can see that when the sequence ends the data is processed from teh fast szene - meaning - if teh send delay is smaller than teh transition time it will at one point floof the bridge or where is the dtata hold? And - if it is like I think - what sense does irt make to separate the transition time and the send delay?

The Send Delay is to throttle the maximum number of commands we send to the bridge per x ms, because if were to send them with the actual frame rate of like 50fps for instance the bridge might not be able to handle it.
It also depends on the content and how well the bridge responds as that seems fluctuate for unknown reasons, could be Z-wave protocol delay / wireless interference / or just maxing out Bridge resources.
The Transition Time is something we send along a color command and is handled internally by the Bridge, basically it queues up color commands and phases them in but if we were to push it too many commands it will not always know what to do (starts flickering or get flooded).

Adopted the Win Hue 2 color calculation code which is based on HueApi examples and testing it out now, it does more corrections but does reset any custom calibrations that may have been set as it handles it differently.
Also looking into reducing the command size, so would only include the color and nothing else to see if that helps speed things up.

For fun started looking into Arduino + Z-Wave as an Hue alternative, it does seem possible and potentially a bit cheaper as well:

What about this request from the old thread?

Hey Rick,

thanks for this Plugin...i had a thought to develop something like that by myself but not for the Philips Hue system but for Stripinvaders.
I only wrote a test program in java and its working fine but i have no time currently to push the developement further and write a MP plugin.
Stripinvaders is controlled by OSC over network. The OSC commands are really simple and there are some OSC Librarys available for c#.
Would it be possible to implement support for Stripinvaders in your plugin or could you publish your code? Maybe i can add the Stripinvaders support by myself.

Thanks in advance!

 

[killer8]

I was in the DIY shop today and found a Philips Hue Tap and bought it, quite nice Works without batteries based on kinetic energy from pushing the buttons.

Later I was trying a bit with the original philips android app. It has an option to only turn the lights on after sunset, it would be quite cool if this can be added to atmoLight as extension on the times when it should be off. I think this information can be easily taken from some weather api or maybe worldweather mediaportal plugin or something.

@Rick164 since I see in your profile you're also a dutchie Praxis has Philips Hue and takes coupons from all DIY shops, this will give you a nice discount I've done the same for my Hue tap

 

[Rick164]

Think that can be added more easily now due to the AtmoHue API but unsure if the end result will be the same as their sample video.
Would be able to use this as a basis:

https://bitbucket.org/pvarcholik/bespoke.osc

Then make it so that it sends the commands to AtmoHue, should be doable so added it to the to-do list

@Rick164 since I see in your profile you're also a dutchie Praxis has Philips Hue and takes coupons from all DIY shops, this will give you a nice discount I've done the same for my Hue tap

Thanks!
Will take a look as I want to get an Iris for another room