Support for Philips Hue System (1 Viewer)

[Zoidberg77]

That's odd, could be connectivity issue but does it always work correctly if you control it via the Philips remote/app?

Yes, no problems with the remote. And WinHue (not WinHue 2, which seems to be not working under Win 8.1) is working fine from the same PC here. So the Bridge is accessible from this computer.

 

[Rick164]

New version below which has more debug options, please enable the debug log option and post the "debug.log" from the app folder here afterwards.
Also added the option to auto-connect when using manual bridge detection i.e. the "Locate Hue bridge" button.

Download AtmoHue 0.013
http://1drv.ms/1w81kPI

 

[Zoidberg77]

Log attached.

What I did:

• started app
• tried to change color -> Net Error
• ticked Win 8.1 and Auto Connect
• Locate Hue Bridge -> no success with SSDP (Worked in the version before)
• tried color change -> no effect
• unticked Win 8.1
• Locate Bridge -> Bridge found
• tried color change -> no effect

 

[zekaja]

I had a nice experience today... Tried winhue in conjunction with atmowin..
Everything seemed fine with live update... The color changed a little slow, and never dimmed I black scenes of the movie...

Tell me how I best can help test development of this project?

 

[Rick164]

Log attached.

What I did:

• started app
• tried to change color -> Net Error
• ticked Win 8.1 and Auto Connect
• Locate Hue Bridge -> no success with SSDP (Worked in the version before)
• tried color change -> no effect
• unticked Win 8.1
• Locate Bridge -> Bridge found
• tried color change -> no effect

Thanks, think I've found the problem and will publish a new version tomorrow.
Only thing that is unclear is why SSDP stopped working, are you sure it isn't being blocked by some firewall application?
Also could try it with "run as admin" (right click menu on .exe) to make sure it's not some weird UAC problem.

I had a nice experience today... Tried winhue in conjunction with atmowin..
Everything seemed fine with live update... The color changed a little slow, and never dimmed I black scenes of the movie...

Tell me how I best can help test development of this project?

Good to hear it's working better now , a few things that I'll would like to test so that we can get some good default settings in the app:

- Does brightness work when you change levels?
Value 100 should be 100% but unclear in the documentation so would like to make sure.

- Does saturation lower the color intensity as expected and what would be a normal value for it?

- Can you try AtmoHue with an Transition time value of 4250 and see if that makes the color change near instant.

- Can you enable debug logging and and render an completely black screen while Atmowin monitoring is enabled?
Afterwards you can post the usual "debug.log" so I can check what values are being send in and out.
This way I can check what Atmowin is reporting as the summary zone color, if that value is too high we need some more options for that as I don't see an easy way to parse brightness levels from Atmowin to AtmoHue at the moment.

Checked out WinHue 2/3 and that one looks pretty advanced already, too large of an code base to use it for Atmowin integration alone though but could use their API instead of the one we're using now which would probably be better.
First lets see if we can get the current solution working and if not I'll switch over to that one.

 

[Zoidberg77]

Only thing that is unclear is why SSDP stopped working, are you sure it isn't being blocked by some firewall application?
Also could try it with "run as admin" (right click menu on .exe) to make sure it's not some weird UAC problem.

Really strange. This was working with version .012 but isn't any more now. No difference if firewall is deactivated and/or run as admin.

 

[pur_berger]

somtimes (after Wakeup when hue was still running diuring shutdown) I see these

 

[pur_berger]

Ok - some new things:

- when I start atmowin over atmolight (no effect until Video) it seems there is nothing created for teh hue
- when I start atmowin manually before I start atmowin something is sent

Also there seems to be an error with calculating the colours - most of the times it is black which doesnt fit

21 - 28 - 10 it's black; seen.

seems as blue and green are much less intensive than red

 

[pur_berger]

FF0000 - 17-0-0 (110000) - red as expected
00FF00 - 8-33-0 (082100) - very light green
0000FF - 0-0-17 (000011) - very light blue

Found this on the net:
http://stackoverflow.com/questions/...e-for-the-phillips-hue-bulb/21535834#21535834

and this
http://stackoverflow.com/questions/16052933/convert-philips-hue-xy-values-to-hex/16187919#16187919
https://github.com/PhilipsHue/PhilipsHueSDK-iOS-OSX/tree/master/ApplicationDesignNotes
http://stackoverflow.com/questions/22564187/rgb-to-philips-hue-hsb/22649803#22649803
No idea if this was already taken into Count?


I also still don't get why teh Response is so slow - according to philips
http://www.developers.meethue.com/faq-page
1 command per second for Groups should be fine

So - could this be the issue?

//Turn the light on and set a Hex color for the command
207 command.TurnOn().SetColor(color);


but in the FAQ it says

Why is the bridge response so slow?
Don’t always send ‘ON’ Once you have sent the ‘ON’ attribute to a light, it will stay on. Do not repeatedly send the ‘ON’ command as this will slow the responsiveness of the bridge.

 

[Rick164]

Will do some more testing this weekend and add new debug functions, might need to send the off command before sending a new color but unclear why it would react slow as it resets it if you send a new color command and based on the transition which makes it fade in/out.
Already fixed SSDP bridge detector so that will be back as well

Atmowin black seems off either by specific gamma/color settings within Atmowin or because its detection is off internally (coding error), you can test it out when using the device "dummy" within Atmowin and when you tweak the gamma/brightness settings within Atmowin it should lower the color in realtime.

The error out of standby is because it lost its connection, better connection handling is on the to-do list but the error itself is no problem as it reconnects when sending a new color

Will publish the new version on Sunday as I would like to fine tune and make it a bit more stable first