Check the "Lan Scene File" preference and make sure it has the file name I provided you. Also check the Dev Type under the device data section on the Device info tab. Chek that it shows "Net_Lights"
Apologies - I looked at that preference when I enabled local LAN scene control, and just totally forgot to update it. Too excited, moving too fast. As soon as I updated the file name the scenes were updated in the driver.
Device has the right dev type.
Tried to set one scene (Bubbles - 101). Nothing happens on net lights, errors below:
Also getting new errors from my RM rule that applies DIY scenes...thinking that the problem relates to changing the LAN setting in the driver?
Well the UDP errors in your second screen shot are interesting. I just got a idea to improve that parse method. Either way what that means is the command was sent to the device and we got a response back. Generally that indicates a problem so not sure what that means at this time. Going to dig into testing this more with one of my home devices. It may still be related to the ptURL command that was found recently.
Your third screen shoot looks odd but I guess that is because most of it is from RM. Do you have your DIY's extracted locally, or did we just setup to use the cloud? When you flip that switch Govee Scenes and DIY's will use methods to pull from local files. If the DIY's are not extracted to a local file that likely explains that error.
Yes, this, I believe.
Figured that was it. Since my device uses that new "ptURL" we were unable to extract so I was using cloud. Thanks for the info, and happy new year!
Um. If you haven't already set it back the way it was. After some testing i am finding issues with that new process. As of right now i am not convinced it is working fully. I couldn't get it to work right with my Govee Glide Hexa Pro which is what i use for pretty much all of my testing. So for now that change is on hold
Hey, thanks for the update.
I just reverted the LAN preference setting that I changed, and the scenes are back to their original five-digit numbers. Should things "just work" as they did before now, or do I need to revert any driver code changes?
You shouldn't have to do anything. If you want you can delete that new scene file as i don't think the scenes are valid from the script.
I ended up with a RM rule to adjust the lights to the desired level when they get activated.. It's a bit of a sludge, but it works.
Maybe I'll try to change the RL to pick the color using HSL, other than just picking the direct color (Red). See if that will work..
Thanks for the RGB/HSL hint. I can probably get that to work without the RM "cludge"!
I'm spending my early Saturday night playing around with home automation. I know, I know...
Anyway I tried setting my Table Lamp v1 (H6052) to music mode but it didn't do anything. I checked the logs and found this (and this is definitely NOT an emergency!)
Looks like our friends on the "Home Assistant" platform has some issues with Govee in their latest update. What I love about Hubitat we rarely see breaking changes:
Tried adding a "Star Light Projector", but the child device is not being created.
I found the following error in the log:
2025-01-05 07:20:56.872 AM error
org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_Mavrrick_Govee_v2_Device_Manager_769.addDeviceHelper() is applicable for argument types: (java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.util.ArrayList, java.util.ArrayList) values: [Govee v2 White Light Driver, 35:39:C1:9A:35:50:93:C3, Star Light Projector, ...] (method addDeviceHelper)
Found the error. It looks like this has been broken for a while. It will be fixed in next release.
That stinks. That is a shame. After scanning the github issue linked, it looks like it had a problem that was bound to happen eventually.
Found the issue. It will be fixed in the next release Though I am a little concerned it is showing it is trying to use the "Govee V2 White Light Driver" driver. That driver is fairly limited in functionality. After I publish the next update, you should probably send me the commands listed in the device info so I can confirm you have all of the functions expected. It is possible that device has some functions I haven't had to identify in the past and so is defaulting to that device driver.
There has been more discussion around the new process to extract the scenes. We have apparently found what appears to be keys that identify occasions it works and doesn't work. As part of testing, I have integrated the known current process that is partially working into the Govee Integration v2 app. It will be tagged as experimental and I will tweak it as we find keys to make different devices work. Right now it looks like it works with any linear device. Linear devices are LED strip type devices, and string pod type lights. Devices like "Y Lights", "Hexa Panels", "Square gaming panel", "Cylinder lamps", ect just don't seem to work. There is research going on using the scene list files we have to try to figure out what is different and what needs to changed to get it to work.
I have also tweaked some other things to help the integration use these new files. The downside is this will change scene numbers.
This said I want to be clear this doesn't break or removed anything from the current setup if you don't actively try to use this new method to get your scenes.
If you need anything from a "cylinder lamp" owner, I'm happy to help.
Just to be sure, would this include Net Lights - not sure if they are classified as a linear or string pod device.
Thanks for all the updates and all the work on this!!
I wouldn't consider the Net Light to be a linear device. It has to use some logic to know the net layout.
I do not think this will have any impact on devices that use the new ptURL command. Now if that net device had some scenes that use ptReal those could work with this method if the unique items with that device are identified.
One problem with this new method is that unlike the older method we already have this doesn't know anything about if the command to be used is ptReal or ptUrl.
To know for sure what is needed we would need to get some extracts using our old method and then compare with the script.
Simply put the new method has a few items in the strings that are still not clear on how to convert. It isn't hard to identify some of them, and with some analysis i can kind of figure out some others. I am adding logic now to hopefully get the Cylinder Lamp, and the Table lamp 2 to work with what i already have. The older Lyra Lamp and Basic lamps have already been reported to work. and i tested it with my lyra lamps already.
@oldcomputerwiz and @AEBogdan I just released some code that should have fixes for your issues.
The code also includes a few other updates.
- A change was made to code related to activating scenes and scene management to allow a slightly different scene file structure. This should make them make a bit mroe sense to use.
- Renamed the scene extraction button in the Lan API Scene management Menu. It has been renamed to "Extract Scene from Tap to Run".
- There is a new option to perform a extraction from the Govee API. It has been labled as Experimental. This new option will take you to a new screen that you will enter the 5 charecter model number and click on next. Once next is clicked a new file will be created on the hub with the extracted scenes for that model number. This new method is not 100% and many advanced devices that are not linear will l not get valid scenes from this method. It should work with devices that have linear pixes like LED strips or devices that have light pods along a wire. I have also worked on the routines to allow Cylinder Lamps, Table Lamps, and the Hexa Glide panels to work. I will continue to tweak this as i get time.
Thanks for the fast response!
The child device did not get created. We made it past the first error only to hit a new one.
2025-01-06 06:29:45.250 AM error
groovy.lang.MissingMethodException: No signature of method: user_driver_Mavrrick_Govee_v2_Device_Manager_769.addLightDeviceHelper() is applicable for argument types: (java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.util.ArrayList, java.util.ArrayList) values: [Govee v2 White Light Driver, 35:39:C1:9A:35:50:93:C3, Star Light Projector, ...]
You are correct. It is definitely not a simple white light. If it is helpful below are some of the app parameters (though I'm sure the extracted list will be more useful once a device is created).
The app controls include Scenes, Music, Share Space, DIY, AI, Timer, etc..
It has two main controllable aspects:
STARS:
- Brightness
- Blink
- Orbit
AURORA
- Flow Rate
- Brightness
- Change Mode
- Change Speed
With some additional global values:
WAVES
- Color Settings
FLOWS
- Color Settings
My initial goal is to simply control the ON/OFF state, but I'd be happy to assist with further testing if you would like to fully implement it.
@AEBogdan I have posted two code updates today. The first one earlier should address the issue you are having. Please go ahead and update and try this add again. The issue is related to how basic of a device it is presenting. Simply put some stuff is missing and the method just didn't like then when the request was made to create the device. I believe that should be resolved now.
The second set of code were enhancements to the Govee API Extraction process. I have now tested all of the devices I have that could work with it. They all should be fairly functional now. I have also managed to do some cleanup now as well. This should be very maintainable now as the code is standard even for unique devices. we just need to update a simple map as new unique device id's are validated and added.
One negative to this new method is that it doesn't seem to actually capture all of the scenes available. It gets the initial first list a device gets. Some devices have multiple scenes with the same name like Lighting-A, Lightning B. these secondary scenes do not seem to be returned by the API.
That did the trick!
A "Star Light Projector" device was created. It defaulted to "Govee v2 White Light Driver" device, but I changed it to "Galaxy Projector". The ON/OFF switch is working. I'll test it out further when I have time.
Thanks!
Please go open up the device. Click on the "Device Info tab and then post me the Cap Types, and Command listed there.
You really shouldn't need to change the driver. All that could do is introduce commands you really don't have access to. The info requested above will tell me 1. most importantly what does the device really support through the cloud. 2. Then I can review if that device has any new functions the current driver doesn't support and if i need to find a better way to identify that device.