Control your Supported Govee Lights directly from Streamer.bot without the need for Lumia or IFTTT. If you do not already have an API Key, follow the next step. If you do, skip to this step.
Congratulations, you are now ready to begin controlling your Govee Lights!
How to Use the Actions
It is highly recommended to Duplicate the actions by Right-Clicking and giving them unique names for each of your Govee Devices. This will prevent having to change the Device ID and Model every time that you’d like to make changes.
To change a particular light, go the Action that you’d like to execute and update the %deviceId% and %model% Arguments to their respective value from the text files.
Once updated, ensure you click Save at the top of Streamer.bot and either type the command in your chat, or by Right-Clicking the Trigger and clicking Test Trigger.
Available Controls
Command
Controllable Feature
Description
!govBrightness
Brightness
Adjust the ‘Brightness’ (value must be between 1-100).
!govColor
Color
Select a color from within Streamer.Bot to apply it.
!govColorTemp
Color Temperature
Adjust the ‘Color Temperature’ (value must be between 2000 and 9000).
!govPower
Power On/Off
Turn the selected devices ‘On’ or ‘Off’.
!govDScene
DIY Scene Change
Apply selected DIY Scene to your device.
!govPScene
Preloaded (Dynamic) Scenes
Apply one of the preloaded Dynamic Scenes to your device.
There are some things that need adjustement in your code, I’ll try and see if I adjust it and send it your way or you try adjusting it yourself haha
But generally it’s not recommended to use “using (HttpClient thirdClient = new HttpClient())”, especially when you are making multiple api calls anyway.
This is a note straight from nate who reminded us about it:
If you’re using HttpClient() in C# code, don’t new it up every time you need one, create a private class wide client, or static (this means you’ll need to keep the instance alive), and set your headers/etc as needed, and keep re-using it.
new-ing it up is costly, and it’s likely not being disposing of it correctly. HttpClient() is a finite resource, and can be exhausted, because closures cause a TIME_WAIT in Windows, usually locked for about 240s before Windows frees it for use again
Updated with new import code and download file! Single HttpRequest in the Setup action and the Govee Controls Action still only does a single request, it just calls all the methods separately in their own actions!
I’ve made some adjustments to the Govee Controls action, feel free to take a look at them and check if everything still works fine as I am unable to test the actual code.
The adjustments I made are basically what the same I had mentioned before with only using one HttpClient. Made some other slight adjustments to help with debugging at the very in case someone would try and use the actions without using the Govee-Setup action first. You’ll see a tiny explanation in the Govee Controls Code.
Since you only use the govee setup once the first time you don’t need to keep the instance active which I have set to the Govee Controls action.
Your edits didn’t break anything! Confirmed everything works as advertised on 3 different lights (2 different models as that’s all I have to test with). As long as the HTTP Request does in fact stay alive for the entire instance that SB is open, then I’d say it’s good to go! Updated the Import Code scroll box, as well as the downloadable file.
aight, I guess if you confirmed that everything is working fine and dandy, I’d just suggest to putting the file directly at step 3 of the “Setting it up”, else people will have to go down to the post and download and then come up again.
Then at the very bottom of your post for some reason you have a summary set? The only thing as per the template you need at the bottom is the following: <div data-theme-toc="true"> </div>
After that I’ll let the others know and we’ll see to move it
You forgot to put the downloadable file underneath point 3. in Govee Lighting Control so they can directly download it instead of jumping down at the bottom and having to scroll up again to continue their setup
I think the hyperlink no worky? It’s supposed to be linked to itself but I noticed none of the internal links jump down to where they’re supposed to so maybe it’s another system limitation
Not really a limitation of Discourse per se as the Table of Contents is a plugin for Discourse. Discourse just treats all links put in a post as an external link that opens in the same window I believe. I can look into the plugin and see if it could be suggested or altered in suck a way but as long as all submissions follow the template set forth it shouldn’t be an issue. Browsing standards of the documentation should be as such that when as user browses things from one doc page to the other the are all uniform enough that it’s second nature for them to look in the spot. The table of contents is just a helpful thing that was added to change Discourses post slider to an actual usable thing in documentation.
Like @pwnyy mention the import code should be moved to be in line with the rest of the docs but also should be a .sb file. Trying to purge the import codes from the site and only do files sense it’s cleaner and people can drag n drop them into SB.
Deleted the import string all together. Recommend removing that part from the template if the intent is to have everybody using .sb files vice the import string method!
The import string was never part of the template, only the .sb file itself, you can check the versioning if you don’t believe it . As the post is currently it’s good to go
. As the post is currently it’s good to go