-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replay mode (send regularly last known state to all bulbs) #68
Comments
Hmm... I like the concept, but I think I'm sort of tempted to leave this up to a higher-level controller (like HomeAssistant). I kind of like the idea of this project being a dumb stateless controller. I'm worried it'd get over-complicated if we start incorporating state. A few ways I can imagine solving this out of band from the firmware:
Do you feel like either of those would do what you're wanting? |
I use Domoticz and this platform is not able to refresh regularly the state of devices natively. Although I think I can develop a python script in order to refresh automatically devices not operated since a several minutes. About MQTT, I never tried this protocol :-) If I understand correctly, with MQTT the broker knows all last states forwarded by the Milight Bridge, consequently you can implement a start script that downloads all last known state and reapply ? That's interesting but in my case my IT infrastructure, including Rpi and Milight Bridge, is backuped by an UPS :-) I have suggested to you a repeat function, I understand that it is too difficult to manage because you need to implement some "memory" functions. On the other hand, if it is not possible, I will try to implement a script on Domoticz.. |
Nah, I get where you're coming from. I like the idea, just a little worried it's going to get complicated. It's totally doable, just a question of whether it's worth the complexity. If we did this, I think I'd want to implement this at the client level rather than binding it to a particular interface (UDP, HTTP, etc.). Imagining it'd work exactly as you described -- optionally have MiLightClient keep track of last sent state for every device ID it sees (probably up to some pre-defined limit), and have some background process refresh that state on some regular interval. |
Yes I understand that it is not an easy implementation. However Domoticz, like other solutions, is less reliable than a dedicated controller (sometimes I need to reload the service), that's why I think there is better to implement it on the dedicated controller :) I like the idea to use MilightClient class instead off interfaces, I will try to test a custom implementation next weeks if you want. |
The idea is certainly growing on me. As long as it's optional behavior, I think it's fine. I'll probably take a stab at it, but might be a bit before I can get to it. :) |
It could be a user enabled option. Some systems handle the state, but if not then the controller can handle it. |
Just started to use the hub with Home Assistants "light mqtt json".... really cool, and simple implementation. |
Nice. Glad you found it easy. Yeah - I like the idea of publishing state updates via MQTT. Would be nice if it happened regardless of what triggers a state update (including replay). |
Hi Chris,
I suggest to you an enhancement:
Milight bulbs are not able to stay off after a power outage and light on when power is recovered.
Is it possible to add a mode that resend regularly the last know state of the bulb ?
The period may be adjusted by a parameter on the webui (in minuts)
Consequently, after a power outage, the bridge will switch off necessary light according to the last known state.
Moreover, we can also add a feature that switch off all lightsfor all UDP bridges at startup.
What do you think about this ?
Regards,
Jerome
The text was updated successfully, but these errors were encountered: