Open mwohlert opened 4 years ago
@mwohlert interesting idea! Basically as long as these are completely optional features, and the current implementation works as-is, I'd be very happy with it. That being said, I don't think it would be something that I would get time to work on personally but I'd be more than happy to provide any pointers that may be required.
Fwiw the blinking module already supports customisable patterns via https://github.com/balena-io/blinking/blob/59ca68f6e3445429fd72e3acd0482ea7850081ac/index.coffee#L33-L37
fullPattern =
blinks: pattern.blinks ? 1
onDuration: pattern.onDuration ? 200
offDuration: pattern.offDuration ? 200
pause: pattern.pause ? 0
so it should be straightforward enough to just pass the args through to that
@Page- Thanks. I've been already using that in one container, but due to app updates I wanted to have that functionality in the supervisor since it is always running and does not face interruption at any point.
@CameronDiver I'll start developing on this. I'll keep this completely optional. Just wanted to check if this would be ok with you guys, so I don't waste my time.
I'll orient the json body on the blinking library.
@mwohlert yeah that's what I meant - it's the library the supervisor uses already so it should be possible to map the endpoint body 1-1
Since we are using balena with multiple containers, which need to signal the status via the LEDs, we thought it might be helpful to implement a generalised endpoint(s) in the supervisor that allows these containers to schedule blink patterns with priority.
My question to you guys is basically: Would you be interested in this?
My current Idea:
Extend the /v1/blink to also accept a optional json body which features:
{ "status": { "on": 100, "off": 100}, "power": {"on":100, "off":100}, "timeout" : 5000, "priority": 1 }
The Post request to /v1/blink would also return a uuid of this pattern entry to allow stopping it before the timeout is reached via a DELETE of /v1/blink.