I just pushed out another update. There was a bug in the hub discovery code introduced when I merged my code to the repository. Sorry about that. I also updated the main app so that you do not have to unlink and relink the hub. If the hub is linked, selecting the hub will initiate a metadata refresh that will re-discover and once discovered, it will refresh all metadata to ensure the hub has all the latest v1 and v2 data to support the new v2 logic from the last update.
So now, if you change the IP address of your Hue hub, as long as it resides on the same LAN, simply selecting the hub in the app will find the hub at its new IP address, update the app with the new IP address, and then initiate a full sync with the hub.
Sorry guys. One more update. I think this version is better designed, and solves the most recent issue discovered. Hub re-linking and auto-discovery has been re-worked some more.
Okay, sorry if anyone needed to add or update their hub in that past few days. I finally broke out my developer hub (a C-7, so a good platform), and updated it. I installed just the AHB code, and repetitively installed the driver from scratch until I could consistently install, link and configure the hub. I then unlinked and relinked numerous times, and finally I went through the process of refreshing metadata (link relinking, without the linking step) until I could feel comfortable that this version should now work for everyone. In my experimentation, I discovered that I needed to update to a newer version of Hubitat software or I would see weird errors when connecting to the hub, so please make sure you are up to date.
Aside from fixing the hub linking that I broke, I added additional code so that the hub device, when newly created, does not throw exceptions before the metadata refresh process has completed. This change eliminates all erroneous errors in my logs that I was seeing during the hub linking process. I also update the logic for pausing the hub device activity to disable the refresh scheduler, and watchdog timers until the hub is fully operational again.
If you are updating from a much older version, after the update, be sure to launch the AHB app, and click on the hub device in the menu to force-refresh the hub's metadata. This is a required step to prepare the app for the new V2 API related behaviors.
@armand Do you see any problem adding capability "Sensor" to the Advanced Hue Light Sensor type? I use Sharptools and it doesn't pick them up unless this is included. I tried it manually on the device and it doesn't seem to impact anything else?
Done. I never needed this, because the capabilities I added are already sensor types, and it works in sharp tools for me, but it doesn’t hurt to add it.
I rolled it back you can restore functionality until I can loo closer at the issue. For some reason, I seem to remember there was something about sensor capability and that I removed it, but I could be remembering wrong. I’m not around a computer, I a doing all this on my phone today, so it’s safest to just roll back until I’m in front of a computer.
okay, it's back with motion, temp, and illuminance sensors support capability 'Sensor'. The problem with the last attempt is that while I am able to edit on a phone, sometimes I should not, because one of the three files had the capability defined as 'sensor' instead of 'Sensor'. this prevents the driver from compiling, that is the source of your issue.
The problem is with the 2nd replaceAll. Don't quite understand what this is for but things seem to be normal, at lease no more error, after removing this line of code. My host was already in the format of X.X.X.X:443.
I know your app is for genuine Hue bridges and Hue apparently uses SSL (port 443) for communication.
I use Tasmota (with Hue emulation) which does not use SSL
HE changed something in recent OS platform updates which caused it to no longer work with Tasmota. Posted about it in another thread. HE version finds the bridge only if I specify Tasmota bridge IP and then it won't discover devices (bulbs).
I tried your app and it discovers the Tasmota bridge but errors out due to Tasmota not supporting SSL or port443.
Question could you make a non SSL version or tell me what to change in you app to see if it will work with Tasmota using non-ssl?
What this regex line does is a two step string replaement. If the host address end in :80, then the :80 is replaced with :443. I oher words, it will transform a host address to http url to a host address for https url.
The 2nd part uses a look behind expression. Essentially, it then takes the host address (modified by first replaeAll or unmodified) and if it does not contain a host address, then it appends :443 (https protocol) address.
ultimately, if the host address reported by the SSDP auto-discovery process has a port defined, then I leave it alone, unless that port is port 80. But, if the host address returned has no port (default is 80 in this case) then I assign port 443 to make it https, because I use https for all calls, since the v2 API requires HTTPs.
This logic will change, but for now I use SSDP because hubitat support for mDNS is very young, and I have not yet taken the time to learn how to use it.
In the meantime, I think I found the flaw in the regex, and am fixing it to make the 2nd match optional, which should fix the error.
Let me see what I can do. The problem her is that my code relies on the hue v2 API. Does the Tasmota with hue emulation support the v2 protocol? If not, i won’t work on my integration. I guess it may be possible to keep a V1 version of my code, but it would have very poor support as Hue is going to end of life the V1 protocol and I never planned to support to bases of code.
Why are you using hue emulation with Tasmota? Doesn’t HE support Tasmota already?
I don't believe Tasmota supports v2, I was not able to find and info related to it. That may not really be the problem though as HE inbuilt, yours and CoCo Hue all made calls to the bridge using https even if I forced V1 of the api in the app. Tasmota's web interface only supports http, hence the problem.
HE does not support Tasmota directly, there are the tasmota sync drivers for plugs and switches.
I am specifically using a Sonoff Zigbee Bridge Pro flashed with Tasmota with Hue emulation enabled for my Zigbee bulbs only. I keep the bulbs on their own network as the ones I have would act as repeaters and from what I've gathered bulbs make poor repeaters.
Anyways don't worry about my request as I was able to get the CoCoHue bridge app/driver working by changing the calls from https to http, and then selecting V1 api.
There are a thousand ways to solve a programming problem. I went with regex because any competent programmer should know regex. This reduces the translation into a one-liner that should be easy to understand.
It’s a simple way to make sure the colon only appears in the appropriate pattern.
I can’t tell you the benefits of my integration over the built-in integration. I created this because the built in integration did not work with hue scenes, or sensors. As I have not tried the built in integration I cannot confirm nor deny any claims about the built in integration. Play at your own risk.
I guess the only reason to use my app is that it supports color and color temp in the V2 API without requiring a refresh. Reading the documentation, it appears as if the built-in app may still be relying on V1 hub refresh to get color and color temp. But this is not confirmed by me, just my interpretation of the docs.
This appears in the documentation:
‘’’
Some Hue features report color data using a color model that is not easily compatible with Hubitat's color model (the CIE xy colorspace as opposed to HSB color used by the hub). In such cases, color temperature data is assumed to be a reflection of the current device state if the device reports such data, which will sometimes be the case even if the device is in color (i.e., RGB) mode. This is most common when using Hue scenes set to color (rather than color temperature) or when changing colors from the Hue app directly.
‘’’
My app fully support the CIE XY colorspace, with custom tunings for each of the three supported bulb types, as per the hue developer documentation. But also, I am not 100% V2 API based yet. I still use the V1 API for sending many commands to the hue hub, but I can accurately translate the event stream XY values to HSV values, and accurately map the color temp within the scale supported by Hubitat.
This will be the last I discuss the built-in integration because my code is not to eliminate the use of the built in integration. It was always just an alternative to the built in app for those that need more than what is provided.
Ah, don't get me wrong. I have been using your app for a long time. It started when the built-in app took forever to get on/off status updates. So I'm very thankful to you for all your effort in maintaining/upgrading the app and making it free for everyone. Cudos!
OK, it looks like the built-in app does most of the things I need now, so I just gave it a run. Here are some basic observations:
For bulbs, it gets on/off, level, and color temp updated almost instantly. Color needs to wait for a refresh.
For groups, it gets on/off and level instantly, but color and color temp updates need a refresh.
I mostly manipulate color temp from Hubitat and don't have automation to control color, so I don't even know how to test the color mapping
Now, curiosity drives me to test the AHB. It turned out that:
For bulbs, the on/off status, level, and color temp updates are a second slower, and color is taking forever to update.
For groups, the on/off status and level updates are a second slower, and color and color temp are taking forever to update.
So I went in to check the refresh interval and realized that I'm getting multiple null point exceptions from AHB (likely from a single source). I'll have to debug a bit and see what's going on here.
java.lang.NullPointerException: Cannot get property 'null' on null object on line 2143 (method findGroups)
java.lang.NullPointerException: Cannot get property 'acca6bf7-f0a7-4329-862b-96587beff024' on null object on line 2143 (method setHueProperty)
java.lang.NullPointerException: Cannot get property 'null' on null object on line 2143 (method componentRefresh)
java.lang.NullPointerException: Cannot get property 'null' on null object on line 2143 (method dispatchRefresh)
So this is the 2nd time I need to debug the app myself. It’s a blessing for open source tools so I can fix things myself. But sometimes, it's also a pain when I'm lazy and/or busy.
As to the use of regex, I agreed with your statement of its ubiquity, but I have also seen enough defects buried in regex by somebody that jump out one day to wake me up in the night. I'm not debating here, It’s just a personal choice. I prefer simplicity.
Thanks again, and I'll update you if I find anything regarding the NPE.
