All of my dashboard buttons and Hubitat device page buttons are no longer controlling any scenes or formulas imported through one specific instance of the CoCoHue App. I have other bridges with other CoCoHue apps which are all working fine, the problem is only with this one instance controlling a Hue bridge controlling lights in my kitchen. I can access the Kitchen lights through the Hue App in my iPhone, just not in Hubitat. I tried opening the specific instance of the CoCoHue app and hit "done," also tried restarting my Hubitat. Neither of these worked.
Wondering if anyone has seen this problem before and has a fix?
I haven't seen this, but the first thing I'd do is check the "Logs" for errors or other clues.
In particular, I'm wondering if your Bridge IP address may have changed. Opening the app normally fixes that if it doesn't find it automatically first. If you didn't set it up with a static IP address in CoCoHue to begin with, you can at least see what the app currently thinks it is by looking at the the ipAddress value under "Application State" on the App Status page (gear icon in the top right of the CoCoHue app). I assume you know how to use your router or other tools to find this from the Bridge if the Hue app doesn't provide an easy way to see that anymore...
I think that might be the problem. I noticed that in the Philips Hue App, it's set for DHCP which I understand means that it will chose whatever IP address. Do you think I should enable static IP in the bridge and choose the IP address that the corresponding CoCoHue App is listing for it?
Either way should be fine as long as your CoCoHue setting matches your network setup (e.g., if you manually enter the IP address in CoCoHue instead of using discovery, it should be static or reserved--otherwise you'll have to update it when this happens). That being said, I do agree that a static or reserved address is probably the best and easiest to avoid problems.
Ok, so in the Philips Hue App, I selected static IP for the bridge in question and I put in the IP address listed in the CoCoHue App instance for this bridge. I also went into my Xfinity router, found that very IP address and made sure to reserve it. I then restarted both my Hubitat and the Philips Hue bridge and…. still no response to any of the devices in my Kitchen to Hubitat commands. But again, I can send commands through the Philips Hue app to the kitchen devices, and I can send commands through Hubitat to any of my other bridges.
I’m guessing the nuclear option here would be to uninstall and reinstall this instance of the CoCoHue App, but I’m trying not to do that because I have a lot of scenes and formulas saved which I had to rename in Hubitat according to my convention. So I’m hoping I don’t have to do that…
When I get back home, I’ll get you those logs you asked for to see if that gives us any useful information.
Either set a static or a reservation but not both. Once you've chosen do a re-discover and re-authorize (you will likely have to push the button on top of the hue bridge)
OK, noobie question here - what’s the difference between a static IP and a “reservation?” I thought the choices were between DHCP and static IP. Previously the Hue bridge was using DHCP and I don’t recall if I had reserved the IP the router or not, but I think I did and yet this happened.
So if you set a reservation on your router for the device, the device is issued the same address every time it boots. Setting the device statically means putting a permanent ip directly on the device. It's better to reserve the ip for the device on the router so you're not always looking for it somewhere and can see all your reservations in one place. It's best to do this for all your iot devices that hubitat interacts with including hubitat itself. In some cases setting a reservation and a static ip even though both are the same ip can occasionally cause a problem depending on equipment . So my advice in the end is simply leave everything set to dhcp and set a reservation. If you had a reservation for your hue bridge, then the ip would not have changed.
Hmmm… I need to look at my router and see what the exact verbiage is there since… I’m not really clear on the difference but I want to make sure I’m doing what you are suggesting so that I know what I’m talking about. I’ll try to post some screenshots of the relevant section in my router to show you.
OK, I verified that this bridge has a reserved IP address for 10.0.0.79, and that the Philips Hue App also has this as the IP address, and that this is the same address. I'm sending a command through my dashboard to turn on one of the kitchen scenes and here is what I record in the event log for that CoCoHue App - absolutely nothing:
So it says "error connecting to Hue bridge." Does that tell us anything?
When I clicked on the "warn" button I found something else interesting - it leads me to the App page for this instance of CoCoHue, but it has the OLD NAME (Philips Hue Bridge 4) on the bridge before I renamed it in CoCoHue and in the Philips Hue App to (Kitchen Area). Could that be relevant somehow?
Enable logging for the app and bridges device, and you'll probably see more useful information. HTTP 403 is a timeout, which I could see if it's still trying the old IP. A manual address should eliminate that, but even if you use discovery, it goes by MAC address and not name, so as long as it's the same Bridge, changing the name should have no effect. The app is called whatever call it, which does default to something that includes the (original) bridge name, so also not a concern.
I do this by clicking "enable debug logging" in this particular instance of the CoCoHue App, right? Is there anything else I need to do to do this?
So far after doing that and sending another command, I got only the following in the log: dev:20962022-09-26 08:42:01.080 pmwarnError communiating with Hue Bridge: HTTP 408
Yes, also enable it on the corresponding Bridge in your Devices list. The particular light or group you're using wouldn't hurt, either, though I suspect the problem will appear elsewhere.
Welp, that wasn't helpful for me, but that appears to be because I don't see a way that enabling logging will spit out what I'm really looking for (though you could get it from App Status, which I don't quite see above--I'd need state, not settings).
If you update the CoCoHue app with this code, a slight modification to the latest version (4.1.2) that I assume you're already using, it should put out a trace log with the relevant data:
You can manually copy the real app back over this one when it's all done, or do a re-pair from HPM if you used that and think it's easier.
PS - I do assume you're already using the latest version of all apps and drivers and that if you upgraded to 4.x at some point you've already hit "Done" in that child app, per the 3.x upgrade notes a while back (and if not at some point during all of this!).
I verified using Hubitat Package Manager that there are no pending updates, so I assume I'm using the latest. You mention App Status - here is what that shows in case that's helpful. If not, I guess I will have to update the App with the code you mentioned. I've definitely hit "done" after upgrading or if not at that time, then definitely at times after that.
