Thanks for the detail feedback. I’ll take a look shortly.
I just published a small update that is essentially just a update to the "Govee Device Manager" driver. This update is important if you use LAN API with the integration.
Fix:
Devices setup prior to being enabled with LAN API will now be assigned there IP properly when first detected. Previously they would have shown "N/A" even if enabled for LAN API and detected by the Govee Device Manager.
1 Like
This is 100% a issue with the device IP not being populated in the Device Data on the Hubitat hub. I have gotten some time tonight to dig into this and to finally get a parse method that works. I was able to reliably reproduce this and confirm for sure what the cause is.
Those error messages are actually a error from the UDP client on the Hubitat Hub. Simply put it is complaining about not having a proper destination. This means the related device does not have a valid IP address. Open the related device and click on the initialize button. That will trigger the device to update and retrieve it's IP Address.
I just published a update that will provide a updated Parse method that will make the logged response more understandable.
@mavrrick58 Appreciate you looking into it. I updated the Govee App through HPM, rebooted my Hub. All child devices non functional, I clicked the initialize on one, no change, still not controlling the device.
I understand the thought behind removing the ability to set the IP by the user, but a read only field to see what IP is being assigned would be helpful.
Not sure if it helps, I never got to converting 2 devices before things stopped working, so they aren't child devices and they do work correctly.
Can you open up the "Govee Device Manager" devices and look at the state values. There should be two of them at least. The first state value is "ipxdni" which is a cross reference value to link IP's to the Device DNI. The second is "lanApiDevices" which is basically a value to keep track of what devices have been found on your network. It has a entry for each devices with the Govee DeviceID, and then lists the associated IP, Model number, and Last time the device responded.
Both of those state values are populated by the devices scan process the "Govee Device Manager" does. The frequency of the scan call is controlled by a preference, but I have it set to default at every minute. So ever min the Govee Device manager will call out to the network and ask for all devices to respond with their info. When they do it will process the incoming data and populate those state values.
Once those state values are populated is when the child devices initialize should be able to retrieve their IP address.
The reason I ask for a reboot is because assuming that the devices is detected by the Govee Device Manager and the state values get populated that should be the easiest way to get the IP values into the devices itself.
@DenverTech99 can you please check those state values and confirm they are populated with the expected information. Maybe even spot check to see if your devices that are not working are listed there as well. I need to isolate where the failure is.
Clearly something isn't working as expected and I am trying to chase this down so sorry folks for all those struggling with this latest change. I am continuing to make adjustments to try to smooth this out. I really thought I had this migration process down when I announced the release with all the LAN API Improvements.
@mavrrick58 for visibility
I'm unclear when this issue was introduced but I'm no longer able to change the color/brightness/saturation/etc. of my Govee TV lights from the Hubitat device--works fine from the Govee phone app.
Other controls such as power on/off work from Hubitat. For clarity, at some point, this used to work but I'm not able to say when it broke for me. Neither of these buttons function nor does the RM method:
A couple of debug logs below:
Any input much appreciated!
Thx!
Based on all of the responses you are getting it looks like you are using the Cloud API and are getting good responses from it. That would indicate there may be a Govee Cloud issue.
If the devices supports it you can get around this by enabling the use of LAN API
2 Likes
Thx.
//EDIT: checking if local control is supported with this model.
As I mentioned, the app on my phone works just fine. Hence, if I disable WiFi on my phone then I'm definitely using the cloud API from the phone. I assume that logic is sound?
Here's the latest log just now from an attempt to change the color from the Hubitat device (looks a bit strange to me):
Per the Govee app, the TV lights DO support local control (assuming the mere presence of the setting is a valid indication)--I enabled it in both the app and on the Hubitat device. When trying to explore options within your Hubitat app, I get:
The cloud API is for integrations. Most likely your phone will use either Amazon AWS, or Bluetooth depending on if you are in range. Disabling WiFi on your phone won't change that.
Those UDP message indicate you have LAN API enabled. Can you click on the Initialize button on the device. Those also indicate you may not have the info I just put out. Please open HPM and perform a repair on the integration to load the latest code.
The "Manual Lan Setup" page is really to configure LAN API device that don't support the cloud. You really shouldn't need to use that. My guess is that error is related to a blank value that is being looked at for the list of the LAN API Devices. I will add some logic in to prevent that going forward.
What is the model number for the Living Room TV Lights? Please open the devices and click on the initialize button and then go to the devices info page and look at the devices data section. You should see a listing with a IP like below. If not go into the preferences tab and click on save
2 Likes
I just posted a small update to the Govee Integration app that should prevent the error you saw when going to the "Manual LAN Setup" page.
Now it should just tell you don't have any LAN API devices detected
Understood, thx.
HPM completed the repair without issue. FWIW, I NO LONGER receive the same error when clicking on the 'Manual setup for...' button. However, you've indicated that's moot here so ignoring it either way.
I've initialized the device but I don't see an IP address attribute; is there another driver I should be using?
The error was caused by a state value on the Govee Device Manger being blank or null. Based on the first screen shot the code change worked and gave you the message about not detecting any LAN Control enabled devices. That has some interesting implications.
Considering your first screen shot that actually makes sense those state values are used to populate that value. It should create the value and be "N/A" though. Can you try going into the device preferences, turn on debug logging, and thenclicking on the "Save and Close " button. Once that is done check your past logs for what is generated from that device and send it to me in a DM please i will review it and see what is happening.
The big question now is why are you getting that message saying nothing is detected. Lets check a few things. Go open up the "Govee Device manager" and look at the state variables to the right. Do you see "ipxdni" or "lanApiDevices". I would expect the answer to be no. Then click on the preferences tab and check the "Scan Rate in Minutes for new LAN API Devices" and set it to 1. Flip the switch for debug logging and click on "Save and Close". If you check your logs for the Govee Device Manager you should see some entries that look like the below image. The bottom most lines are the driver initializing the multicast socket. Then it broadcasts a call to the network for any Govee Device listening to respond. Then what you see above that are the responses from some of my devices. Lets check what you get
Can you also confirm that you went into the Govee Home App, clicked on the device, selected the gear in the upper right corder to go into the properties, and then scrolled down and flipped the switch below to turn on LAN Control?
If that is not turned on, the Govee Device manager will never know the device is on the network and ready for the LAN API calls from Hubitat. Simply put it won't respond when the Govee Device manager send out it's broacast message for devices to announce themselves
By chance do you run a separate vlan for IOT devices and your Hub is not on the same network? That would cause a problem. Or did you load the recent Govee Integration from Hubitat? Because of how Multicast UDP traffic works you can't run my Govee Integration and the new Hubitat Govee integration together as they will fight with each other to be the listener. You will need to fully uninstall one or the other.
Thanks so much for the detailed assistance!
Having done nothing since yesterday, it's working perfectly and locally this morning. 
FWIW: I do use an isolated guest/IoT network for my Tesla (because it's unbelievably fussy about WiFi/subnets) but it's the only device on it.
Great work--love it!
The Govee Device Manager device is programmed to update existing chile devices as they are detected for LAN Control.
What likely happened is the device responded to the scan request and then in hubitat it got updated as it should have.
It would be interesting to check the device entry in the "LanAPIDevices" state value on the Govee Device Manager. It records the time the last time the Device scan request was responded to. If it is much older then the interval set for the scan rate it may mean your network is dropping udp packets or the device is missing wifi packets.
Sure, happy to help. Nothing useful here, though:
Let me know if there's anything else useful you'd like.
A reboot of the hub brough the LAN control back!
@mavrrick58 In the Device Manager, the only Device Data field is the API. State Variable shows 6 for child count.
In the Child Device itself, no IP listed for any device.
I installed the update that came through, no change. Then did a repair through HPM, rebooted and even shut down once and waited a few minutes before starting the hub - no change
I still see the errors in the logs including on Initialize comand, including 1 which shows it sees when Govee App shuts off the light through Cloud API, just can't control through the LAN any longer.
Confirmed LAN Control is still enabled via Govee App.
The problem is likely not with the govee decice itself but with the Govee Device manager not getting a return to its device Scan request. You provided loggs for the Govee device and not the Govee Device Manager. Can you show me those logs.
Do you use a seperate vlan for your iot devices and then have hubitat on a seperate vlan?
@mavrrick58 Yes, separate VLANs for my IOT (Govee) and Hubitat. No changes in Network configs since I setup the Govee Integration in December and everything worked at that time.
Each Govee device has a static IP, I can communicate with the devices through my firewall routing rules from the VLAN Hubitat is ln, and back.
Govee Device Manager Logs when I hit Initialize:
