Crates.io | autodeck |
lib.rs | autodeck |
version | 0.4.0 |
source | src |
created_at | 2019-12-24 07:39:32.43189 |
updated_at | 2019-12-24 11:27:39.393581 |
description | Elgato StreamDeck based Automation Software |
homepage | |
repository | https://github.com/ryankurte/autodeck |
max_upload_size | |
id | 191994 |
size | 106,843 |
A simple automation daemon for linux, designed to interact with Elgato Stream Deck devices. See example.toml for a set of example automations, and the docs for further information on automation options.
WIP, basic functionality working, tested only with a stream deck mini, pull requests welcome.
Precompiled binaries are available on the releases page (including a .deb that will install configuration files and a systemd unit). The utility can also be installed from source using cargo install autodeck
, but you'll need to manage the configuration files etc. by yourself.
For the debian package, automations are specified in /etc/autodeck/autodeck.toml
with configuration in /etc/autodeck/autodeck.env
.
You can register the service at startup with sudo systemctl enable autodeck
, and check the logs with sudo journalctl -u autodeck --follow
.
An automation file consists of a list of [[automata]]
, each corresponding to a single button on a stream deck.
These automata
have a state
field describing their intitial state, as well as an on_init
executor.
Each automata
contains a set of named states
(for example, [automata.states.error]
), these may contain on_press
and on_poll
executors, called when the button is pressed or under periodic polling, as well as a display
object that defines what will be displayed on the button in a given state.
Executors
contain instructions about commands that should be executed and how these effect the state of an automata. These contain a func
argument that is the command to be executed, an args
list of arguments to be passed to the command (note that args cannot be included in the func
string directly), a pair of on_success
and on_failure
fields mapping to the next states.
In general success is determined by the return code of the command (0 = success, non-0 = error), however, in some instances a command will always return 0 however may not have executed the desired action. In these cases you may use the success_filter
and failure_filter
fields that to check for matching data from standard out, and the on_failure
next state field mapping.