Wake up automation - #81
Conversation
…avoid "No provider" error due to TLS library misconfiguration
…m was shadowing the generic /{resource} with e.g. /scenes, which makes the GET handler.
…e request channel to Backend::run_forever()
…pedLight by reference
This has been underway for too long, but now it's finally here. This commit reworks how Bifrost works internally, and better separates the backend from frontend code. Before, the route handlers (`src/route/...`) would receive Hue V1 and Hue V2 data, and convert each incoming request into a corresponding Z2m request, which was then broadcast to the backends. Not only did this put z2m code inside the hue route handlers, it also struggled to represent the finer details of status updates. In this new model, the route handlers send Hue V2 update messages to a central backend bus, that all backends subscribe to. Backends (currently always z2m), are then in charge of converting Hue V2 updates into meaningful actions for their domain, without involving the hue-based core. This is a much cleaner design, and makes it hypothetically possible to extend Bifrost with new types of backends in the future.
…2m-specific code there
It previously started fade in when the fade in when the light should've been at full brightness
When the wake up schedule first begins it shouldn't be cancelled by doing changes
The previous method was buggy and brittle
This should prevent to light from using the previous configuration when starting up
|
As I mentioned on discord, this is amazing work! Really great to see the first major, outside contribution to Bifrost. I love it ❤️ 😃 I'll get back to you as soon as I've had some time to look at this properly. We're on a great path here! |
748c4a4 to
54b5d01
Compare
|
@duvholt I've recently implemented (the basic parts of) a Service Manager type. It's in the When you have some time, maybe you can attempt the tricky process of getting this rebased all the way on top of that? 😅 That would make it much closer to the (upcoming) modern infrastructure in master (when it is merged at some point). As soon as I'm done with this major excursion into implementing Entertainment Mode, we can take a look at getting this ship-shape :) |
|
Nice, I've been sick for the past week, but starting to get better now so I'll probably take a look at rebasing the PR this weekend 😄 |
|
Sorry to hear that :( No rush! Take your time to get better. I also just wanted to let you know that I didn't forget about this PR :) |
54b5d01 to
c26982c
Compare
|
@duvholt did you close this? It says here that I closed this, but I didn't!? Did I press the wrong button, or did github give up trying to figure out where this goes? I'm confused.. In any case, I hope you'll reopen it :) |
|
Huh, weird. I guess it happened because the base branch was deleted? I thought github just changed to the default base branch (master) in that case 🤷 Looks like I have to create a new PR, so I'll do that after I hopefully have time to look at using the sunrise effect later today 🌅 |
|
I thought so too! I don't know what happened 😕 Just wanted to let you know I still very much want your contribution 😅 |
2 participants
Note: I set base branch to "the-big-backend-refactor"
I've implemented more or less everything related to wake up automation in this PR:
The only known thing that is missing is support for using the sunrise effect which AFAIK is implemented directly in the Philips Hue bulbs. Shouldn't be hard to implement if general support for effects is done.
I also noticed that the bulb keeps the previous color for a split second when turning on and starting the routine, but I think this is a bug in z2m. I'll probably look more into this later as it's not that bad.
I introduced a scheduler service that listens for changes and creates a list of jobs to execute. Since these are just futures dropping and recreating them ensures that only the last known automation is used.
From studying the official Hue bridge it seems like wake up automations that have started are not cancelled, so I implemented that as a future that spawns another future 😄
I didn't try to do much future proofing for new implementations, but I don't think I've done anything that is in the way of introducing new ones either.
In general I'm not super happy about the naming of things in the scheduler.rs file, but I figured it's easier to discuss names with a complete implementation than doing it beforehand. I'm also very open to changing the scheduler abstraction.
In general I think it makes sense to have: