AtmoHue - BETA - Philips Hue support for AtmoLight & AtmoWin (1 Viewer)

[Rick164]

Its like 3 lines of code .
I can add it if you want me to .

Would be awesome

I just did the testing colour rotation.. it is set at the default value of 100ms in the textbox. I'm noticing the colour changes almost exactly every one second (roughly monitored with a wrist watch).

Is that expected outcome or is that slower than you would expect? (using your new version btw).

EDIT: A query.. in the atmolight plugin there is a note that says 'Use the context menu to switch effects'. What context menu is that? Is there control within a skin?

I'm also seeing some strange behaviour. I have just one light set for live tv. I start media from tvseries and winhue is doing its thing.. but eventually the light stops doing anything. I press stop on the media and the light goes out. I start the media again and resume from the previous position and it takes like 40 seconds for the light to turn back on again?

Maybe it would help to record a video off my phone or something?

Think it might have something to do with the bulbs, haven't seen this with blooms so far.
In AtmoHue there are several additional settings that affect delays:

- Hue send delay (Remote API box) which throttles delays from external commands (like AtmoLight)
- Transition time which tells the Bridge to smoothly transition between colors.

The default settings should be ok but you could try lowering them slowly and see if that helps

EDIT: A query.. in the atmolight plugin there is a note that says 'Use the context menu to switch effects'. What context menu is that? Is there control within a skin?

Correct, if you map a button for the context menu via the AtmoLight configuration window then it will allow you to change effects and more when Mediaportal is running.

 

[pur_berger]

So - This is how it looks like with me . At the top is the stripe and the lower left the Iris.

 

[Rick164]

Looks very nice!
Response times look pretty decent already as well, once @Lightning303 adds the Hue exception for delays I'm hoping that will improve it even further

 

[pur_berger]

Yes. Not much but enough to be recognised ... Anyway i'm already very happy with the result.

 

[Lightning303]

Looks very nice!
Response times look pretty decent already as well, once @Lightning303 adds the Hue exception for delays I'm hoping that will improve it even further

I pushed the changes.

Please all keep in mind, this will only improve the timing if you have set a delay in AtmoLight for other targets (e.g. AtmoWin), like @pur_berger has.
So if you are only using Hue, or did not enable the delay feature, nothing will change.

 

[Rick164]

Thanks , compiled / tested and works fine so added a new MPEI release to the first post

Changelog

15-11-2014 - AtmoLight BETA updated

AtmoLight 1.13.110.0 - BETA version

- Hue is now excluded from the "LED delay" setting ( @Lightning303 ).
Only for those who have that option enabled and/or run Hue plus additional handlers(AtmoWin etc..) you might notice an increase in response times.

 

[killer8]

I think something is wrong with debug options. I'm using .67 but the log field is flooded with all kinds of messages(atmolight, standby etc) I thought this should only happen when log/debug was enabled.

 

[Rick164]

Did change it a bit so that it shows more info for troubleshooting at least until we get to a point where we have all the mayor features in and its stable , doesn't get written to the debug.log file when debug log is disabled however so it will not fill up the disk.

 

[killer8]

Ah oke clear Thought it was a bug or something since it didn't work like that before.

 

[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.

I also have the feeling that the delay (at least I have between teh stream an atmolight) is coming from the framrate switching?

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?