sidoh / esp8266_milight_hub

Replacement for a Milight/LimitlessLED hub hosted on an ESP8266
MIT License
944 stars 219 forks source link

Replay mode (send regularly last known state to all bulbs) #68

Open g-rom-info opened 7 years ago

g-rom-info commented 7 years ago

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

sidoh commented 7 years ago

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:

  1. MQTT messages with retain=true. This would make it so the ESP re-runs the last command sent to each topic every time it boots.
  2. HomeAssistant's LimitlessLED integration resets bulbs to last known state each time it starts up.

Do you feel like either of those would do what you're wanting?

g-rom-info commented 7 years ago

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. I don't know HomeAssistant, I will test it next days.

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. The main goal is to switch off all bulbs after a power outage. I think this can be simplified easily. It is not necessary to Switch On lights or reset colors, brightness, ... For each UDP Gateway, can you implement a simple function that sends "off" regularly on each group that are not "explicitely" switched on before ? (configurable timer). As a consequence, all lamps will be switched off on bridge startup, and if the bridge is backuped by a battery or an UPS, known "non-on" bulbs will be switched off :-)

On the other hand, if it is not possible, I will try to implement a script on Domoticz..

sidoh commented 7 years ago

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.

g-rom-info commented 7 years ago

Yes I understand that it is not an easy implementation. In my way, I think I can implement a refresh script in domoticz.

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.

sidoh commented 7 years ago

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. :)

WoodsterDK commented 7 years ago

It could be a user enabled option. Some systems handle the state, but if not then the controller can handle it.

WoodsterDK commented 7 years ago

Just started to use the hub with Home Assistants "light mqtt json".... really cool, and simple implementation. The replay state option could be nice - if it gets implemented, then what about transmitting the state to get feedback to HA?

sidoh commented 7 years ago

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).