Everything works fine with using the CustomAttributes to execute the available commands. I was able to SetColorTemp and SetLevel. Hope it helps someone else who might be working on RM rules down the line with lights.
This is with the RGGWW Night light for kids right H6059. Maybe i will go ahead and order that so i can test this out completely myself.
If that is right you definitely want to use the Set Color Temp options instead of setcolor. Set color temp will use those extra WW led's in the device for better white colors.
This is strange. I use toggle on and off in button controller with my H6052 Aura lamp every day. We turn it on when the house goes to sleep and then it gets turned off with another button press every morning. My TV lights both come on and off via cloud with RM rules as well. The rule monitors TV's power state and then turns on/off the H6199 kit based on it. I will do some more testing once I get home because several parts of this don't line up.
Works fine with my button controller too. Sets colors and all. I have a NanoMote that sets random colors for my son.
I'm thinking of just returning this and grabbing the newer night light (H6057) with IC , white noise, and rechargeable battery to move around the room. I can then skip the alexa routine, as-long as it's controllable from the APi and the white-noise is accessible. It's barely a $15 price difference from what I paid for the original model.
What the API will support won't be any different. I am not even sure if it will enable the Local LAN api as it doesn't show up on the supported list currently. I think at one point they did say it would come with 5.4.0 but it doesn't appear to be there now. I am sure it is a nicer lamp, but don't know if it will allow you to eliminate Alexa.
I did just check the list for local LAN API access and the H6059 is on it. Have you tried using it with the Local LAN API instead of the cloud api.
Yeah, didn't trigger at all. I enabled it both places. Initialized it. Refreshed and nada. It was late into the evening so I didn't tinker enough with it. I quickly switched it back before bedtime. Forgot to go back and mess around with it since then...
I just re-enable it in both places again and tested a quick setcolortemp.
So i just did some testing with the set color command. I can certainly confirm strange results when submitting the setcolor command with similar numbers to what you showed above.
Everything appeared successful, but it looked turned off. I even checked the Govee Home app and it showed the lamp was on so what gives. Well I tried it again and set it to the (value)brightness parm option to 50 and low and behold it lit up. I turned it off and then tried it again at 50 and it lit up again. That disproved one of my theories. The command is working but the question is why is it so darn dim that it looks off when the brightness value is set to 1. I think there are a few things at play here. First thing to understand is we are doing conversions between HSB % scale and RGB. HSB includes a value for brightness variable, but RGB doesn't. Though we call it brightness I don't think it actually translates the way you are thinking in regard to dim level. So, when a conversion is done that level means practically no color is visible and not a dimness level. Think of it like taking a color that is near perfect black and making it 100% dim level. If it is nearly black even at 100% it would be pretty much black.
I tested the setColorTemp value and that seems to work fine from what I can tell and worked every time.
My suggestion is to use the setcolortemp as you have started anytime you want a white light. If you want a color light first set it to the color and then adjust the dim level independently.
Local Lan cotrol doesn't have a message back to show it was successful unfortunately. By chance is your lamp on the edge of your wifi. My lamp is turning on and off and changing states very reliably. The only strange thing I found is above, but my lamp was reacting to what was asked of it. You may want to try turning bluetooth off on your phone and then try to take actions from your phone to it. Maybe there is some wifi reception issues to the device.
To enable the Local Lan API there are only 3 things you need to do.
- Enable Local Lan APi on the deive in the Govee Home app.
- Enable it in the driver on Hubitat and click on save.
- Make sure the IP on the driver in Hubitat is corret and click save again.
You should really only be doing a refresh and initialize for very specific circumstances.
Only Initialize if you change the Polling setup. This is all it will change.
Refresh just tells the device to do status lookup with the Govee Cloud API for the device current status. You would only want to do this if for some reason you need the status updated quickly after a state change you do from the Govee Home app, or maybe if you are testing and want to ensure you have the latest status of the device. Otherwise it shouldn't be needed.
Local Lan uses UDP protocol to talk to the device instead of TCP. With UDP it doesn't have the same error correction or validation checks to ensure the packet gets to the destination. Simply put you wouldn't be able to see if the command didn't get to the device with UDP. I am really curious if you are having some kind of wifi issue talking to that device.
It's actually directly above the router and like 20 feet from the mesh tower. But connected to the main router.
It's going back anyway, the features felt underwhelming compared to the upgraded model. Going to mess around with it this weekend. I wish I could trigger the WhiteNoise from hubitat. Maybe with a virtual switch to a alexa routine.
You can't trigger the white noise on it, but you can change a setting so the whitenoise effects start when it is turned on or when a certain scene is activated.
It is also cloud API only and that is only when power save mode is off or it is on the base
1 Like
I tweaked how the driver handles change with the SetColor command. Simply put it will set the level of the lighting device to 100% but will pass the requested RGB Color based on the HSL light value submitted. It should act more like what is expected I think. Let me know if anyone finds any issues with this.
This update should now be available in HPM.
1 Like
Got the new night light yesterday. It blows the mini out the water. IC and the preset scenes are impressive. Hubitat does have the same controls for it like the original model. Luckily Alexa can tap into the other features such as white noise and scenes.
Virtual switch works as expected to trigger those features. I'm still using your integration to control turning on and off with correct temps/brightness for bedtime routine. If the Alexa routine starts to give me issues, at least I know the light will dim down correctly with your integration and only need to worry about setting the white noise with the buttons on the actual device.
1 Like
thanks @mavrrick58 these app and drivers work perfectly and so easy
1 Like
What is the minimum brightness on Govee? I have seen a lot of other bulbs that go 15% as the minimum and trying to ramp up for a dimly lit room is out of the question as it will blast your eyes while it ramps up.
They come back on at the last level you set them to. They can get pretty dim, but for them it is just 1%. They don't do any fade over time. What specific device are you thinking about.
I'm getting rate limited w/ two H6057 speakers. I'm not doing anything that would seem to be particularly verbose with them. However, the logs look noisier than expected:
I have rules configured to toggle these off/on based on wall switch taps. So, nothing that would be sending commands with any amount of frequency that would run afoul of the rate limit I wouldn't think. Any ideas?
What do you have polling set to? If you ope.n up the device it will show you what your API Usage is like. What numbers are shown there.
default, 300 sec
Is it still happening?
