Philips Hue Hub Config for Polisy

[Hoosier Daddy]

Is there any developer out there willing to update the Hue Hub NS? There seems to be a few of us here in PG3 world are not able to access nodes any more since PG2 went away.

I'd be willing to support the effort financially. I'm guessing it might sell a few licenses on PG3 to offset costs.

Edited July 9, 2022 by Hoosier Daddy

[MrBill]

On 7/9/2022 at 11:03 AM, Hoosier Daddy said:

Is there any developer out there willing to update the Hue Hub NS? There seems to be a few of us here in PG3 world are not able to access nodes any more since PG2 went away.

I'd be willing to support the effort financially. I'm guessing it might sell a few licenses on PG3 to offset costs.

Is there a problem with the PG3 version of the node server? It does exist in the production store. Or were you wanting it altered? 

Also PG2 has been deprecated, but is still working.  Deprecated means it won't receive additional enhancements, but as yet it hasn't been removed from the system.

[Hoosier Daddy]

The Hue NS doesn't update the Hue hub ip if it changes for whatever reason. It probably doesn't have anything to do with PG3 vs PG2, but I don't know how to evaluate that. The problem surfaced for me when all of my LAN ip's changed for an unrelated reason around the time I was moving from 994i/PG2 to Polisy/PG3.

However, @Geddy and @bpwwer have found a way to force the NS to look for the hub at it's new ip:

This solution worked for me.

Edited July 18, 2022 by Hoosier Daddy

[Dub]

11 hours ago, Hoosier Daddy said:

The Hue NS doesn't update the Hue hub ip if it changes for whatever reason. It probably doesn't have anything to do with PG3 vs PG2, but I don't know how to evaluate that. The problem surfaced for me when all of my LAN ip's changed for an unrelated reason around the time I was moving from 994i/PG2 to Polisy/PG3.

Something to help with those types of issue is to use DHCP reservations.  I have been doing it on all my devices that connect to each other. I had just gotten started testing Hue so your post caught my eye and reminded me to set up the reservation for it as well.  ?

[Geddy]

21 hours ago, WHaas said:

Something to help with those types of issue is to use DHCP reservations

While that works as long as you keep your current setup. It's sometimes unavoidable when you change brands of routers. Unless you always make a mental note to change your DHCP back to what you had previously. I don't usually worry about setting DHCP reservations, but it seems to be becoming more expected that people do for situations like this. 

What's interesting is that another automation process found the Hue Bridge without issue. So somehow the node server is putting the IP it found the bridge at into its configuration for when it gets loaded again and ALWAYS looks at that location. 

Thankfully it can be changed with the custom configuration setting, but that requires a different way of indicating the IP address.

[Dub]

5 hours ago, Geddy said:

While that works as long as you keep your current setup. It's sometimes unavoidable when you change brands of routers. Unless you always make a mental note to change your DHCP back to what you had previously. I don't usually worry about setting DHCP reservations, but it seems to be becoming more expected that people do for situations like this. 

Totally agree.  I have been switching different routers over the years, but recently went back to DD-WRT.  After Insteon Hubs went red, I wanted a good router that I KNEW I could block the outbound access out to the Internet for certain devices.  I decided to make the router part of my design and not an afterthought of my home automation needs.  I'm documenting the reservations outside of the router and saving backups. Ironically after reading this and going to set my DHCP reservation, I fat fingered and keyed one digit higher in the last octet.  ?...I was able to easily identify the error in the logs in the NS and changed my DHCP reservation.  I'm testing Home Assistant as well and have had some mixed results when IP's changed....some integrations did good others not so much.  What I don't want is to loose the DHCP lease during day to day use and loose connectivity.  In the past I set static IP addresses, but that can be a pain when there are network changes and trying to get everything back online.  This thread has been good for me as it pushed me to dig into my Hue lights and get the Network Resources set up along with the NS.  Thanks to everyone for their past work documenting and commenting to help me get over those humps.

[Dub]

On 7/16/2022 at 5:16 AM, Hoosier Daddy said:

The Hue NS doesn't update the Hue hub ip if it changes for whatever reason. It probably doesn't have anything to do with PG3 vs PG2, but I don't know how to evaluate that.

I keep doing some digging, to learn more and noticed on the Github repo for the PG2 and PG3 of this node server exking/xking(not tagging him as reply is not needed)has noted the following.

Notes

Poly assumes that Bridge IP address never change, so it is recommended that you create an IP address reservation for the Hue Bridge on your router.

IMHO this is an accepted risk of using the NS.

 

[Hoosier Daddy]

6 hours ago, WHaas said:

Poly assumes that Bridge IP address never change, so it is recommended that you create an IP address reservation for the Hue Bridge on your router.

Just do it after it grabs an initial IP address; reserve that address. If you don't, then you need to use the 'bridges' key and the ["x.x.x.x"] parameter format.

[Dub]

On 7/16/2022 at 5:16 AM, Hoosier Daddy said:

The Hue NS doesn't update the Hue hub ip if it changes for whatever reason. It probably doesn't have anything to do with PG3 vs PG2, but I don't know how to evaluate that. The problem surfaced for me when all of my LAN ip's changed for an unrelated reason around the time I was moving from 994i/PG2 to Polisy/PG3.

 

19 minutes ago, Hoosier Daddy said:

Just do it after it grabs an initial IP address; reserve that address. If you don't, then you need to use the 'bridges' key and the ["x.x.x.x"] parameter format.

 

Totally agree thats how I did mine the second time!

On 7/9/2022 at 11:03 AM, Hoosier Daddy said:

Is there any developer out there willing to update the Hue Hub NS? There seems to be a few of us here in PG3 world are not able to access nodes any more since PG2 went away.

I'd be willing to support the effort financially. I'm guessing it might sell a few licenses on PG3 to offset costs.

@Hoosier Daddy my digging for a better understanding was based more off your question about wondering if a developer would update the app.  I am definitely in favor of supporting the developers on node servers when the MS adds value to our daily lives/automations.  This NS seems to be the type that adds value to me, but it is a free NS which I appreciate, but the development time comes at some cost whatever that is. The cost would be different to each developer and some might just feel rewarded for helping out.  

@Hoosier DaddySince the developer has acknowledged in his notes that is a known behavior, what else would you like to see out of the node server?

Also, will this Node Server be maintained over time?  Does UDI ever pick these up and maintain in house?

I'm mainly curious before I begin to depend on this NS too much as I don't have much invested Hue at the time, but I'm in more of a test mode.  

My biggest challenge is the mapping of the scenes to the generic names, but I noticed in the Node server logs that my custom named Hue app scenes are in the logs, just not in the Admin Console for ISY.  Overall I think its a very functional Node Server and the ability to set custom colors and temperature is a much welcomed option without the simple color palette.  I also saw some other discussions where folks use the Network Resources to trigger the Hue scenes.  My understanding was they were using NR for this because when they updated their scenes on the Hue app the scenes in the ISY needed to resync in some way and it was easier to just edit the scene in Hue for spouses and other family and calling the unique scene name in the NR was reliable.(Maybe this is resolved now???)   I was able to edit an existing scene's brightness level in the Hue app, and when I triggered the generic scene name in the Admin Console, I saw the new values when I triggered this scene with no syncing of the ISY and the Hue box.  The one thing I would like to better understand is the expected behavior of the generic scene names and is this something that could be populated in the Admin Console(since I saw my scene names in the logs.)

[bpwwer]

1 hour ago, WHaas said:

Also, will this Node Server be maintained over time?  Does UDI ever pick these up and maintain in house?

I'm mainly curious before I begin to depend on this NS too much as I don't have much invested Hue at the time, but I'm in more of a test mode.  

I can't speak for the original developer of this node server, but the answer to does UDI ever pick up unmaintained node servers is sometimes.  Other individual developers can also pick up and maintain a node server.

The pool of node server developers is not real large and in many cases, the developer has created a node server because they need the node server.  Without having the equipment, it can be difficult for another developer to take over the maintenance of a node server.

[Dub]

2 minutes ago, bpwwer said:

I can't speak for the original developer of this node server, but the answer to does UDI ever pick up unmaintained node servers is sometimes. 

Thank you that is good news.

2 minutes ago, bpwwer said:

The pool of node server developers is not real large and in many cases, the developer has created a node server because they need the node server.  Without having the equipment, it can be difficult for another developer to take over the maintenance of a node server.

I completely understand this and thought this might be the case.  I'm optimistic on this one because of the large Hue user base and the Official Developer program with Philips, but Philips Hue can be cost prohibitive.

@bpwwerI just noticed the title line in your signature and knew I had seen your name in the Node Server store.  It made me go look to see how many! WOW!  Thank you for all your contributions!

[Bumbershoot]

I suspect that the node server will need to be updated to incorporate version 2 of the API whenever it's finished.  I think that there are also numerous devices in the API that the current node server doesn't support.

The Hue API - referred to as CLIP API ('Connected Lighting Interface Protocol') - will move to version 2, which is a breaking change over version 1. Version 2 is still a RESTful JSON HTTP API, but the structure has been redefined to make some improvements and allow for new use-cases. Both APIs will exist in parallel to give developers time to upgrade, however any new features (such as dynamic scenes) will only be available on V2, and in the long term the V1 API will eventually be removed. The V2 API is currently in early access and not yet feature complete, but it is already available on production bridges and in use by Signify developed applications. For features that are available on both versions, we recommend to start using V2. Just make sure to check that the bridge version is at least 1948086000.

[Hoosier Daddy]

6 hours ago, WHaas said:

@Hoosier DaddySince the developer has acknowledged in his notes that is a known behavior, what else would you like to see out of the node server?

I don’t have any suggestions. The current NS is great as far as I’m concerned. The configuration notes in PG3 are misleading (the ip key seems useless) and they are insufficient for this user who doesn’t know how to wade into the dev environment and search the developer’s notes.

I don’t mean to sound critical. The NS is free, after all, which is why I suggested throwing some money at it when I couldn’t figure out how to resolve the ip problem. 

[Dub]

41 minutes ago, Hoosier Daddy said:

I don’t have any suggestions. The current NS is great as far as I’m concerned. The configuration notes in PG3 are misleading (the ip key seems useless) and they are insufficient for this user who doesn’t know how to wade into the dev environment and search the developer’s notes.

I have trouble with the developers notes too, but thats my gap of not understanding.  I was mainly curious if there was anything else you saw the NS needed on features.  I just started testing it and this thread and the comments got my attention. 

 

43 minutes ago, Hoosier Daddy said:

I don’t mean to sound critical. The NS is free, after all, which is why I suggested throwing some money at it when I couldn’t figure out how to resolve the ip problem. 

I didn't take is as critical myself, and agree with supporting the developers that provide solutions that provide value for us. 

[Dub]

One point of clarification about the developers notes from my point of view....I think it is great to have direct access to so many people and developers that make themselves directly available here in the forums to help.  I have gotten a lot of value from many posters and it encourages me to answer questions that I might can help with.

[Hoosier Daddy]

15 hours ago, Bumbershoot said:

I suspect that the node server will need to be updated to incorporate version 2 of the API whenever it's finished.  I think that there are also numerous devices in the API that the current node server doesn't support.

I am hopeful that UDI's approach to incentivizing NS development results in a paid NS version. I have some Hue strip lights on order now and plan to use much more in the future. I didn't stop to think about the fact that the current NS may not recognize these lights. oops.

@Bumbershoot, do you have any indications that the current version is being revised by anyone?

[Bumbershoot]

2 hours ago, Hoosier Daddy said:

@Bumbershoot, do you have any indications that the current version is being revised by anyone?

No, I haven't heard of any progress.  I hope to see someone take it on, as I'd support it financially as well.  In reading through some the developer docs, it certainly appears that the API is licensed in a developer friendly fashion, and the documentation appears to be very professionally done.  

[Michel Kohanim]

Please let me know the improvements you need. I will talk to the genius behind it's development.

With kind regards,

Michel

[Bumbershoot]

3 hours ago, Michel Kohanim said:

Please let me know the improvements you need. I will talk to the genius behind it's development.

With kind regards,

Michel

For starters, I'd love to see the motion sensor exposed (motion | temperature).  Adding these would allow me to get rid of a couple of Insteon MS II's. 

EDIT: I'm not expecting the performance of a Hue motion sensor to match the speed of a linked Insteon sensor - that's not how I'm using them.  I've got them for ambient lighting purposes, but they're attractive and very well built.

Edited July 20, 2022 by Bumbershoot

[Michel Kohanim]

@Bumbershoot, thank you for the feedback. I'll discuss with @xKing.

With kind regards,
Michel

[RJ K]

@Michel Kohanim I'm still struggling to get the hub connected due to the same issue many of the previous posts in this thread are related to. Not sure whats possible but a cleaner way to know what its trying to connect to and a way to remove the default/current configuration?

Thanks!
RJ 

[Geddy]

@RJ K did your Hue Hub change IP addresses recently? That's what sparked most of this thread. Either a router change or not using DHCP reservation with the Hue Hub after you got it online.

If so then you need to add the following for Custom Parameter:

Key = bridges

Value = ["#.#.#.#"]        (MUST have the square bracket AND the quotes)

As soon as I added that (in PG2) it found the hub right away.

If you're still having issues then look at the lot (put it in debug mode) and restart the node server. Allow it some time to start up and then review the log. See if it is giving any idea as to the IP it's looking at for the bridge. When I attempted to add PG3 version (after having the PG2 at the old IP) it still looked for the hub at the old IP address. 

I do not think there is a way to remove the current configuration. Just a custom parameter to overwrite it. I think I attempted to remove the custom parameter and it still looked at the old IP. 

 

[Hoosier Daddy]

19 hours ago, RJ K said:

@Michel Kohanim I'm still struggling to get the hub connected due to the same issue many of the previous posts in this thread are related to. Not sure whats possible but a cleaner way to know what its trying to connect to and a way to remove the default/current configuration?

Thanks!
RJ 

@RJ K, 

If it helps, this is my PG3 configuration:

Also, log in to your "meethue" account and see if the "python_hue" app is listed:

[Hoosier Daddy]

On 7/20/2022 at 10:29 AM, Michel Kohanim said:

Please let me know the improvements you need. I will talk to the genius behind it's development.

With kind regards,

Michel

@Michel Kohanim, regarding Hue NS wish list, I would like to see support for effects. I am putting in some Gradient Light Strips that have some interesting effects available from the Hue app but the only effect available from the console is a color loop.

[RJ K]

@Hoosier Daddy and @Geddy thank you for that! I'm not entirely sure what happened by my IP's were all static but it never connected on the original one after switching to PG3. I changed the address to start from scratch but was following what are seemingly old instructions on the GitHub that say to use a parameter "IP" and no mention of the brackets.

Thanks everyone!