Success. As my daughter was controlling the lights from her phone - i was assuming they were connected to the wifi But they were in fact not. She had them connected BT. A little bit of difficulty re pairing to my wifi. Had to remove that set of lights from her app - do a hard reset on the lights, then it accepted the pair request to the wifi, Im able to switch on / off, change colors and intensity right from HE. !
I feel some what more confident now to send a new set to the tenant and get them connected.
The other night, my Govee lightstrip was acting wonky (going dim and bright for no reason and I couldn't get it to stay off).
Looking at the HE logs, nothing was apparently hammering the lightstrip, but it somehow had 1,700+ pending commands.
I disabled the lightstrip on the hub and left it for some time. It eventually seemed to catch up. Once the pending commands weren't pending, if started working.
Any idea what might have freaked it out, how to prevent that, etc ? Is there an ready easy to flush the pending commands?
The only thing that has the potential to be the culprit is the fade updown routines. Are your devices controlled locally with LAN API. That would be if you turned on Local LAN Control and specified the IP address.
Unless it is a Matter device the device doesn't natively support fade in any way. With LAN API it is enables in the driver and essentially loops multiple brightness changes to go up or down to the requested level. Unfortunately the device and hub can only do that at a certain rate so when you try to do it to fast commands can be queued up in the hub.
If some how you submitted multiple fade commands it could potentiall create a condition were there is a backlog of commands. If the commands were queued up and not allowed to clear then it could just compund and get worse.
It should be obvious if you look at the live logging that this is the case.
I'm not seeing fades in the few places I have automations for that lightstrip. Something 'unusual" must have happened.
It would be nice if there was a way to "flush" all the pending commands immediately... And, a way to know things are messed up (notification, etc.)--if I wasn't home, this could go on for days.
Yea.. it would be nice if there was a way to ensure there were no pending commands, but unfortunately once the command is submitted it is in the OS of the Hub commands to process. There isn't anything else I can do.
If you have any logs for the time this was going on you can send them me in a DM and i will try to review and see if i can find what triggered it and put in safe guards. The only thing that comes to mind as potential causes are the fade operations I mentioned. Outside of that i don't even see how this could happen unless something else is terribly wrong outside of the driver.
So that said, can you answer these questions
What was the device Model Number?
Is the device setup for LAN API Control?
What activity was going on around the time this happened.
Also if it happens again check the event log to see if what is causing the commands to occur.
Can you check the data section of the driver and see what is show there for thr Captype. You would be looking for something with sensor at the end.
Unfortunately my H7142 doesn't show it, but i have a very early hardware revision of that device. So my initial thought is no. It is possible a newer revision could supports it though.
I havent seen any hardware dimming added in new firmware for the garden lights. This was mentioned a while ago govee would possibly add it. Do u know where this stands? Thanks
Yea I have never gotten a timeline for implementation from them, just some positive feedback it is being considered. Like allot of companies they don't seem to give timelines out.
Recently got the H6167 tv backlights. It installed with the lights driver 3. It works but it doesnt. Color, color temp, brightness work. but cant seem to get scenes to load. Shows music mode, but it doesnt work either. Tried chnging to another light driver and that didnt work. Any suggestions? Thanks
For lights you really shouldn't change the driver that the integration app assigned to the device. When the integration performed the device create it looks at the devices capabilities that it supports and selects the right driver based on that. By changing the driver all you would likely do is change the commands available to submit on the device page.
I would suggest putting the driver back to what it was when the device was installed. Then turn on debug logging and attempt the commands again. Save the logging created and send it to me. I will review the logging and let you know what it means.
It would also help to know if the driver is setup for LAN API or is using the cloud.
Hey Mavrick, anything new with nitelight w/ noise machine? I am seeing a driver with white-noise for an aroma diffuser. Does that mean they've released white-noise control?
Unfortunately no. The Aroma Diffuser is a unique device that actually leans heavily on the old API. That is becuase of what you are asking about in that it was one of the few devices that had fantastic controls for white noise and lights on appliance in the older API. I have yet to see any device with the new API to have good white noise controls.
