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

[pavke]

Yeah, that one is fixed in attached build

Confirmed

could try a different app name and key to rule out any issues with it but it shouldn't make any difference .
Also make sure no other Hue apps are running at the same time on the same machine.

Tried with different app name & key, but indeed doesn't make any difference.
Also: I have absolutely no other Hue-related apps running on these machines.

One thing I wonder : have you recently tried hard-resetting your bridge, then tried to pair again with it ?
Imagine it has got to do with the newer firmware, and that your pairing was still sticking from an older version.
Just guessing...

 

[Rick164]

One thing I wonder : have you recently tried hard-resetting your bridge, then tried to pair again with it ?
Imagine it has got to do with the newer firmware, and that your pairing was still sticking from an older version.
Just guessing...

Have a few lamps setup with Domoticz so hard resetting would probably wipe the scenes for it which are pretty specific, @michi216 did mention that AtmoHue showed up in WinHue3 as an registered app on the bridge so it does seems to pair properly at some point.
Want to make sure it's not some weird firewall issue so could you try the following:

- Close AtmoHue
- Open command prompt as administrator
- Execute the following command to turn off the Windows Firewall for all zones:

NetSh Advfirewall set allprofiles state off

- Start AtmoHue and check if it will connect
- Execute the following command in command prompt again to re-enable Windows Firewall:

NetSh Advfirewall set allrprofiles state on

 

[pavke]

Hi Rick. I tried your latest version on the PC from which I had previously my Norton AV cum firewall removed. I was surprised to find it then 'located' the bridge using the Win8 setting, thus via SSDP - even without switching off the Windows firewall manually.
But I'm afraid that's it for the good news. All the rest stays the same : status remains 'Disconnected', no scenes or led data can be retrieved, and none of the tests do anything - even with a switched off firewall.
I guess the net effect of a SSDP discovery is not different from the 'standard method' discovery, namely just the IP of the bridge?

It remains a mistery to me if it is simply the pairing that fails, or the communication in general...
In any case, on the "myhue" site, there is no trace of AtmoHue in the 'Apps' section (only my android app is mentioned) - don't know if it would be in there if all went well ?
Sooo, anything I - or you - can do/try/fix ?

 

[Rick164]

Hi Pavke,

Will do some more digging but this one is hard to track down so far
Does it make any difference with the Windows Firewall steps from the previous post?
Best guess is still that it's something network related as it has worked for others in the past, also might be worth trying a previous AtmoHue version (0.0.87) with a clean config as the Hue library wasn't updated in that one:

https://forum.team-mediaportal.com/attachments/atmohue_v0087-zip.169349/

If all else fails will hard reset the bridge here to rule out any pairing issues but code wise that is pretty straightforward (3 commands that's it) so should work the way it is right now.

 

[pavke]

BREAKTHROUGH !

I searched around for some info on the Hue API, found this web app with which it is easy to test the various API calls and set off to x-ray my bridge. One thing that soon became clear, is that the pairing had worked before, because I could retrieve a good number of paired 'users'. What was clear also, is that their 'names' didn't look anything like the credentials used in AtmoHue - more like "24e04807fe143caeb52b4ccb305635f8" or so.
However, when I plugged one of these keys into AutoHue, things started working perfectly... !
Status was 'Connected', all tests worked, and it even worked with MediaPortal when I did a quick test.

So, the (or at least: my) conclusion is that when you pair with the bridge, you use a format that results in a registration that does not quite look like you expect. That, or you do not retrieve the correct 'user name' to use as HueAppKey after pairing - all of this probably due to the fact that the user-creation API has been slightly changed, at least that's what I think.
Shouldn't be too hard to fix ...

 

[Rick164]

Thanks!
There must have been a change at some point with the Hue library where that got switched around, double checking the documentation now and will fix

 

[Rick164]

Attached new build, added backwards compatibility for users where it was already paired (old format key) so it doesn't break it for them.
If you use "Locate and register bridge" using SSDP it will afterwards fill in a very long key in the HueAppKey textbox which it will use for communication.

Wish the library documentation would have been updated to reflect migration steps for newer pairing options but oh well let's hope this fixes it

// Update

New attachment and now also works with both discover options (SSDP / Broadcast).

 

[pavke]

Glad my diagnosis was correct
Will test asap. Looking forward to my first ambilight evening ;-)
Big thanks for the quick fixes, and for the plugins as a whole !
Grtz - Paul

 

[Rick164]

Still not 100% sure why my old key remained working the Hue bridge though, unless the bridge stored it as some legacy key and accepted it that way.
Because right now it goes like this:

- Initiate pairing (locate and register)
- We send it our own AppName and DeviceName
- It returns a unique user key which is stored locally for communication.

However before it was:

- Initiate pairing (locate and register)
- We send it our own AppName and AppKey
- It accepts that AppKey and now allows communication with it.

 

[pavke]

I have been wondering about that too. I think the answer is that the old user keys still work because only the new user creation api has changed - not the user authentication/retrieval logic. Which seems kinda logical, as otherwise they would have broken all existing setups ...
You also probably can figure out why it kept working with you, by retrieving the details of your user list from the bridge and looking at it, knowing what you now know.

PS Last night everything worked fine with MP & the latest version. So we're good to go