-
Notifications
You must be signed in to change notification settings - Fork 1
FAQ
Short answer, the only other way to continually monitor playback session status would be to poll the server at regular interval which would be more resource intensive and would require a more complex state machine to keep track.
The tl;dr answer (for the techies) comes down to likening it to a GPIO input pin on a microcontroller. There are essentially two ways for software to read a change in the input level on the pin. The first would be to set up a routine that continuously polls the pin to see what level it reads at. Such a routine would require continuous CPU cycles as it polls the input. If the input does not change very often, that would be a lot of wasted computer cycles. Also, there would need to be a balance between an acceptable amount of polling versus the reaction time of reading the input. If the intervals are spaced too far out there would be a delay between when the pin changed and when the change was received by the software. If the intervals are too short then that will increase the compute cycles and potentially slow down other resources. This is probably not as big of an issue on a high-end Intel core processor, but can have an effect on smaller microcontrollers.
The second way to read a change in an input pin would be to use an interrupt along with an interrupt service routine. The software would sit idle waiting for in interrupt to happen (which would be when the state of the input changes) and use up less compute cycles while eliminating wasted ones.
A real-world analogy would be either to periodically check if you have mail in your mailbox, or set up a buzzer next to it and have the mailman press it when your mail has arrived. You aren't wasting energy and time continually checking it.
For Lumunarr, webhooks would be analogous to interrupts. The backend web server is waiting for webhooks to come in and then it parses the data and takes the proper actions to the lighting system. Since Lumunarr is meant to be run 24/7, the choice was made not to have a continuous polling of the Plex server.
The obvious drawback is that a Plex Pass is required to use webhooks and thus to use Lumunarr. If there is enough demand, perhaps a polling option can be created with adjustable polling intervals to balance delay vs. compute cycles and network traffic.
This idea was debated for a while during the creation of the application. In the end it was decided that the primary application for Lumunarr is to create a full theater experience and that the most common use case will be to control a full set of lights (or scenes) in the entertainment area.
Single-light options would require additional settings for brightness, color, etc. where a scene can be created, even for a single light, and have all of those settings stored within the scene. Ease of use was the deciding factor.
If you wish to control individual lights, you can simply create a scene with just one light and use that scene in your Client profiles.
See Webhooks to Nowhere in the webhook section of the user guide.
The short answer is, officially no.
While Philips Hue does have a Cloud API that allows users to access their bridges over the internet, the problem with Hue's OAuth (secure authorization) flow is that it requires a public-facing redirect URL after a secure token is requested. This is a singular URL that must be set up once by the developer. Since Lumunarr is a self-contained web application, there is no universal intermediary server to redirect token requests back to.
Plex gets around this by sending a temporary token which is used for authentication on their servers. Signify (Philips' parent company) has no such setup available.
I'm sure you can use something like a VPN or a service like TailScale to work around this, but these methods are not officially supported by the Lumunarr development team.
Can Lumunarr be set up to use specific Plex libraries as opposed to library types like Movie or TV Show?
Yes! This functionality was added in v1.5.4.