Skip to content
This repository has been archived by the owner on May 17, 2021. It is now read-only.

Update the HUE binding to work with non continuous device numbers on the... #2514

Merged
merged 1 commit into from May 3, 2015

Conversation

mstolt
Copy link
Contributor

@mstolt mstolt commented Apr 27, 2015

... bridge (and speed up the initial loading)

Due the new option to delete bulb on the Hue bridge the old assumption
of continuous device numbers is no longer true. The for loop in
HueBinding.java crashed with a NPE if it hits a deleted bulb.

The second fix in the update is a speed up of updates/initial reads by
removing multiple call to the settings on the bridge. The code now
fetches the settings once per refresh from the bridge and hands the
settings over the the bulb construction.

This fixes the
issue #2504 and
issue #2505

…the bridge (speed up the initial loading)

Due the new option to delete bulb on the Hue bridge the old assumption
of continuous device numbers is no longer true. The for loop in
HueBinding.java crashed with a NPE if it hits a deleted bulb.

The second fix in the update is a speed up of updates/initial reads by
removing multiple call to the settings on the bridge. The code now
fetches the settings once per refresh from the bridge and hands the
settings over the the bulb construction.
@buildhive
Copy link

openhab » openhab #2857 SUCCESS
This pull request looks good
(what's this?)

@@ -223,6 +223,10 @@ protected int count() {
return dataMap.size();
}

protected Set<String> getKeys(){
return dataMap.keySet();
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are there any other Key types then Integer? If not i would suggest to transform the Strings into Integer once (probably here?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually the Philips API is not clear about a type for the ID (but in the Java SDK they do use String as ID type for the lights). Since the usage of the ID in the rest API is always in a string context (and the integer ID is alway converted into string), my next suggestion for a refactoring would have been a complete usage of String for the ID type.
In the ESH the lights ID is also a String.

@teichsta teichsta added this to the 1.7.0 milestone May 2, 2015
@teichsta
Copy link
Member

teichsta commented May 2, 2015

Hi @mstolt, thanks for this contribution! Please find my review comment inline. Also it would be great if you could have a look at the ESH version of the Hue Binding. It was rewritten from scratch but probably that piece of code has been copied? Could be worth having a look there. Best, Thomas E.-E.

@mstolt
Copy link
Contributor Author

mstolt commented May 2, 2015

Hi Thomas, I only looked at the ESH code. It seems to be fine. The light IDs are Strings and the init loop/update loop in the method "run" of HueBridgeHandler (line 91) works with an iterator over the lights key set.

teichsta added a commit that referenced this pull request May 3, 2015
[Hue] Update the HUE binding to work with non continuous device numbers
@teichsta teichsta merged commit 8361c68 into openhab:master May 3, 2015
@teichsta
Copy link
Member

teichsta commented May 3, 2015

thanks, @mstolt!

@mstolt
Copy link
Contributor Author

mstolt commented May 3, 2015

I have to thank you (and the other contributors) for this project.

Btw. do you close the associated issues #2504 and
issue #2505 ? I already commented them as "to be closed".

And do you think the suggested refactoring (bulb id from int to String) as in ESH is ok? If yes, I will prepare another pull request with it.

CU
Matthias

@teichsta
Copy link
Member

teichsta commented May 3, 2015

since you are the creator of both issues you can close them yourself. Thanks, Thomas E.-E.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants