I'll try a repair as I've done all the other and more. My frustration also lies in that I'm trying to do this remotely and watch the lights via a camera. That's on me but not helping either.
It looks like when I was messing with it I now cleared all the DIY scenes.
I appreciate the help but I'm just going to find some built on scenes to use in place of the DIY scenes. They really have been so difficult to maintain that they do take the fun out of the lights. I'm sure I can find something I like for these particular holidays
Have a good good evening.
well sounds like it is time to create a decent backup so that all of this can be saved in a flat file and restored easily. I will start on that as my next feature.
1 Like
If you've ever saved off or emailed your diyEffects string value in the past it's a pretty simple matter to get your DIY scenes back into Hubitat. That being said, I can understand that sometimes it's best to just step away for a while when the frustration level gets too high.
Don't do that. It's the process Govee has. It's just not intuitive. If Govee actually wanted us to use the lights outside of their app they would make this easier for all of us. I know the hoops you jumped through just to get DIY to work in the first place.
I did find a Red, white and blue built in effect that will suffice. I used 174. Govee should actually add some additional red, white and blue for the US market. There really wasn't much when I stepped through the effects. I only have a couple more holidays to replace and I think I saw some that will work just fine. Everything else is working great and I'm happy. If I can't find something in the 140 built in effects then there is something wrong. Thanks again!
I haven't saved them and I do know how to retrieve them but it is time to use what works and move on. There are other more important projects for me to fret over. 
2 Likes
See that is kind of it. Govee gave us a supported simpler way with their newest API. The method we have for the DIY's were we extract the scene and store it on in the App was a hacked way to make it work before Govee added it to the new API. The same goes for snapshots too. In many ways they are much easier to manage if you just use the Cloud API. I have wondered a few times about pulling the code that enables LAN API to control scenes so all scene, diy, snapshot calls goes through the cloud. I just know some folks only want to use this stuff if is is 100% local.
The thing is now that is going to start bein filled by devices supporting MATTER. Govee just released another product that supports Matter. It is their new triad flood light device. They seem to be going through every category with a refresh and including MATTER support. So it won't be long until every new device has the possibility of being fully local.
1 Like
I follow this thread but I missed that.
I just turned off local access and my DIY scenes are there. Even the ones I never imported into local. That's cool. I believe I noticed that the built in scene numbers appear to be different than local access numbers but I can pretty easily deal with that.
For me, this integration is fun, not critical like the low level bathroom light needed for those late night trips so cloud isn't that big of deal. I'm fortunate in that I my provider rarely goes down anyway.
I'm going to switch to cloud access and take the easy way to still have access to everything.
I am going to suggest adding directions in the scene extraction section that all of the extraction steps are unnecessary if you use the cloud API. Maybe also describe the differences (like the effect numbers). I believe this would be a better alternative to removing the extraction code. Users will have the choice.
Again thanks for the integration. My frustration was not directed at you. It was a tough day all around as I dropped almost $1000 having to have the vehicle repaired on Memorial Day while on the road. Probably shouldn't have been worrying about my lights last night.
No worries. The suggestion I made about creating a backup process was something that has been on my mind on and off for a while. This just reiterated the potential benifit.
Good suggestion. I am also thinking about adding a switch in the Light drivers so that it can be set there instead of just yanking the code. Because of a few things there are several functions that take different paths based on configuration switches. I can still see good use for the other regular LAN API Controls that are documented. There are a few new commands that are already cloud based even if you turn on LAN Control. I probably need to better document what "Enable LAN Control" does.
This will allow us to use LAN Control to still turn on/off, Set CT, Brightness, and single color.
1 Like
That sounds great. Best of both worlds!
I just bought the govee kettle and I am really surprised it doesn't have a the LAN control option seeing its using WIFI......
Unfortunately the LAN API is only avaliable on light devices.
I wonder why.....
You probably already know this but since we are discussing the differences between cloud and LAN I discovered last night that not only are the effect numbers different, so are the names. At least the one effect I was messing with. This was on the 6172's. I seem to recall you saying that the effects were not the same across all devices and maybe this explains that.
I think it goes back to what the mindset at the time was, and what they were originally trying to replace.
The first instance of the API came out quite some time ago. It was fairly limited by today's standards, but checked all the boxes for what was available at the time. The push for local stuff got bigger over the next couple years and so they finally released local LAN API on many devices, but it officially only duplicated the functions that the Cloud API had. It was only a couple of months before the LAN API's release that the Cloud API 2.0 was released and it could even interact with Appliance devices, and the control was very limited.
It is only now with the newest API which entered early release just before last Christmas. This new API really brings in support for all of the new functions of the new tech. It also made appliances retrievable so we can finally know what they are doing and added a lot of functions for most.
That is kind of it. The way the Scenes work with the LAN API is kind of a hacked way of doing it and isn't official from Govee. First the command is retrieved from Govee's services. Once it is retrieved I format it and store it in the code of the app/driver and then when you load the scenes it looks for a device type to match to the list of preloaded scenes. If you use the Govee app, Govee may have slight differences between scenes for devices of the same type basic type. Like a Neon Rope, may have different scenes from the outdoor strip which may have different scenes from the M1. Because I can't have 150 lists of different devices I create a list for similar device groups and then load the same list for each device of a similar type. So the LAN API treats all LED Strip like devices the same unless we find there is just a absolute incompatibility.
Based on certain selections in the driver setup determines were the scenes are pulled from.
Because the scenes are extracted and then stored they are static once they are retrieved. I don't go out and refresh them regularly. It is allot of work to do it, and frankly just not reasonable. On top of that periodically Govee adds scenes to their devices, or has ancillary scenes that don't show up by default.
The biggest advantage of using the preloaded scenes is the curation of the number to match things of the same category or to match wiz bulbs. Outside of that with the new API using what comes from the cloud is probably a better way to go. Especially since Snapshots and Diy's just work generally.
1 Like
I'm curious, how feasible is it to be able to switch between lan and cloud within a rule? I know it's just a switch in the driver but have no idea how it works on the backend, and really have no drive to try and decipher the code.
As I understand it I would need to do 2 things.
- Update the driver to allow flipping between Lan API stored locally
- Provide a command to be called with a button that would allow it to be done. It isn't impossible. Actually very doable. It just isn't super clean.
Number one will be coming once I get some time to go through and update all the Light device drivers to add that preference option. It shouldn't be to hard to add the code once the switch is in.
We actually do something like this already in the Kettle driver to allow dynamically adjusting the polling time for the device.
Based on previous discussions my thought process was that it would easily (I use that word loosely as I again have no idea what the programming entails) give the user access to everything. For me, I would use local except for those 3 or 4 holidays that I created diy effects for. Have RM flip the switch and then call the effect. I know I could just pull the DIY effect manually but am just thinking out loud.
My main concern with this idea is that the process to flip from one to the other is not exactly easy on the CPU.
Have you noticed how the hub runs hot after a reboot. I think it is largely based on managing the scenes data and loading it. My hub doesn't settle down for about 15-20 min after a reboot.
It doesn't seem bad when you are flipping it one at a time and it refreshes for you when you change the settings or you are just waiting for the hub to calm down after a reboot. Doing it in a regular flow of a process i worry could end up being detrimental. Especially if you change it to run a scene and then change it back. You would need to do that if you go back and forth
Also the process to load the scenes for the cloud likely calls the Govee API to retrieve the data. That can also be problematic and heavy on load.
It is a little bit better with the devices running under the Govee Device manager. The way it works for that is a bit more streamlined then it use to be and would end up only scanning scenes and commands for the specific device in question.
I haven't watched the load on the CPU. I am going to have to play with it and see what it does on my C5.
Everything you said makes sense and I completely forgot about the API calls. It's not something I have had to worry about. I'm assuming that calling the effect makes one API call to get the info and then runs it on the device. My effects run unless there is motion then everything goes white for a bit then will start the effect again.
Again, I was just thinking out loud not knowing how everything runs in the background. I'm happy with how easily the cloud API works and will most likely stay with it. I have a another cloud device that I have been using since 2015 with minimal issues.
