Support for transitions

[corneyl]

First, thanks for this package, works perfect!

I couln't find any mentions of this before, but would it be possible to support transitions?
mqtt_json in Home Assistant already sends this parameter in the MQTT messages, but I do not know whether this is feasible to implement.
In my opinion this should be implemented in the bridge, and not in Home Assistant, as timing can be done a lot more precise on a ESP (realtime vs OS), and MQTT messages have more overhead opposed to RF messages.

[sidoh]

Just to make sure I'm on the same page: a "transition" just means that you slowly fade from the previous state state to the new state?

I agree that it makes sense for that to be implemented by the controller rather than HASS or whatever else.

That is blocked by esp8266_milight_hub being stateful. It currently has no memory for states -- it just sends commands as it gets them, and doesn't keep track of what state bulbs are in.
Statefulness will add a lot of complexity, and will take a fair amount of effort to implement, but is a blocker for several features that people care about (eg #68).

[corneyl]

Yes, we're on the same page about transitions: configurable fades. 👍

But it doesn't have to be a really stateful solution, as in that the hub knows the state exactly for each node. It can e.g. also be implemented using a queue, or by only saving the state of the transition instead of the state of all nodes.

[sidoh]

Oh, does the transition command include both the original state and the desired state? That wasn't clear to me. If it does, then you're right. Not strictly necessary to keep track of bulb state.

[corneyl]

Ok, sorry, didn't think of that.
I don't see anything mentioned in the docs about sending the original state so I don't think it's included. So then it wouldn't be possible to create transitions without making the whole thing stateful.

[sidoh]

Cool, makes sense. Thanks for confirming!

[corneyl]

It looks like v1.6 will be stateful, does that mean that transitions will be possible in the future? That would be awesome! 👍

[sidoh]

Yes, will enable transitions. Transitions will probably not be in v1.6, but this is probably about half of the hard part. Other hard part is having some kind of pipeline for queued work.

[sidoh]

Should say that this sounds like a fun feature to work on, so it'll probably happen at some point :)

[JohanLeirnes]

As a easy feature to add would be to make the OFF command send brightness to 0 wait for X ms depending on current brightness and then send OFF.

And ON command send ON then Brightness 255 if no other brightness was given.

Easy way to get a smooth on/off atleast.

The only downside to transitions by the "hub" is that we get alot of radiotraffic, say swapping from one color to another. That would take like atleast 100 radio commands to get a smooth transition.

This would be alot easier if the bulb had built in transitions.

[oakbrad]

Transitions work fine with the Gateway Server emulation, yeah? I just switched to mqtt_json lights and noticed the transitions are missing from my scenes. Unless I am mistaken and they were broken before.... would love to have this feature as well.

[JohanLeirnes]

In gateway simulation you are using a python library that has support for transitions.

[sidoh]

@bhaap - that's a good idea. My only hesitation is that most of my bulbs from more recent lines (FUT105, FUT015) already behave this way.

@oakbrad - bhaap said it. The UDP integration in HomeAssistant supports transitions. It's queueing and sending a bunch of UDP packets.

[JohanLeirnes]

Ok. I only have RGBW and a CCT Ledstrip driver. Have not tested the ledstrip driver but my RGBW works as it always remembers its last state so if it was 255 brightness and you want to turn it on to 150 brightness it turns on instantly to 255 brightness and then dims down to 150.

I was not aware that newer bulbs behaved any other way. So you might only want to implement this for the bulbs that behave like I described above.

Or for all bulb. I mean does it matter that you send the brightness commands to your FUT105 and FUT015 bulbs aswell? :)

[sidoh]

Ah I see what you're saying. Nah, newer bulbs do the same thing. The transition is just a lot smoother -- it fades from full brightness to off over a second rather than it being roughly instantaneous.

It probably makes sense to expose this behavior as an option, but I think it's orthogonal to the ask in this ticket. Could you open a new issue?

[JohanLeirnes]

Yes I will.

[corneyl]

@sidoh Can you maybe provide some pointers on where how/where you would implement the queue/pipeline for transitions. I'm not sure yet, but I might have time to work a bit on this in the near future...

[sidoh]

Hey @corneyl, sorry for the late response here. The notification I got for your comment slipped through the cracks.

Honestly the hardest part about this effort is going to be figuring out how to design the pipeline and where the different pieces fit in to the existing stuff.

[matthewcky2k]

any updates on this?

[matthewcky2k]

maybe this code can give a clue, it also runs on an ESP8266 ans supports transitions

https://github.com/stelgenhof/AiLight

[matthewcky2k]

@corneyl @sidoh this has been open for over a year is there a workaround or any progress on this?

[sidoh]

@matthewcky2k:

No, no updates. I'd have updated the issue if I had any.

I hope this is obvious, but this is a project I work on in my spare time. I don't always have the time to work on it, nor do I always have the interest.

I doubt it was your intention, but I want to point out that the tone of your last message in particular is sort of naggy and entitled. This is an open source project. If you're eager to see this feature included, I encourage you to try to add it yourself, and contribute your work back to the project if you so choose.

[matthewcky2k]

You are right that was not my intention, I am already working on adding this feature but i'm more familiar with python than C++ so it may take some time...

[randyarrasmith]

@sidoh Thank you for this great project. Please consider me a +1 for this feature when you have time. :)
Thanks again.

[sidoh]

Will be added in 1.10. There's a feature branch that is code-complete, but I need to add tests and documentation before merging.

[sidoh]

Support is live in 1.10.0-dev.7. I somehow lost the documentation I added to the README. Think I forgot to commit it and nuked my local branch or something. Will get around to re-writing soon.

There are RESTful create/read/list/delete transitions under /transitions and /transitions/:id.

You can also create transitions using the syntax HASS uses -- by including a {"transition":x} key in a command body (either via MQTT or REST), where x is the number of seconds in the transition (the default update interval is 300ms). Here, the bulb will transition from the last known state to the one provided in the command.

[randyarrasmith]

Thank you very much, Sidoh. I look forward to trying this out and hopefully can this week. :)

[badstraw360]

Can’t wait to try transitions! I really want to thank you for putting so much effort in this project.

Is there a way to add a practical example to the readme using home assistant so everyone can start using the new feature?

{
"entity_id": "light.lights",
"transition": "15",
"brightness": "255"
}

[sidoh]

I think it should support using transitions using whatever interfaces HomeAssistant has. It's not its own special thing in that way. You toss a {"transition":15} into your command, and it'll transition from known state to what you've provided.

Makes sense to list (or link to) a simple example, I'll look into that before releasing 1.10.