get_parameter answers out of the GenieACS database and may be stale; refresh_parameter goes to the CPE for a current value. Between them sits connection_request, which wakes the device instead of waiting on its inform schedule — the difference between an answer this minute and an answer whenever the device next calls home. Queue control is narrow: delete_task returns a 503 while the device is in an active CWMP session, and retry_task exists because a faulted task otherwise stays faulted.
A control surface over a GenieACS TR-069 ACS, 12 tools across the CPE inventory, its parameters, and the automation rules applied to it.
- Parameter reads at two speeds — get_parameter serves the ACS's cached value without touching the device, refresh_parameter asks the CPE for a current one.
- Configuration writes through set_parameter, which takes parameter paths and values as JSON tuples.
- Device actions: reboot_device, connection_request to wake a CPE ahead of its periodic inform, and download_firmware to push a file already uploaded to GenieACS.
- Fleet search — search_devices takes MongoDB-style filters over any stored TR-069 parameter, and tag_device maintains the tags those filters match on.
- Automation rules: manage_preset for the precondition-and-configuration documents, manage_provision for the JavaScript that runs during an inform session.
- Task queue control with delete_task for something queued in error and retry_task for a task that faulted.
A GenieACS server with the devices already in its inventory, and any firmware or configuration file uploaded to GenieACS before download_firmware can push it. The project is GPL-3.0.
One command — npx genieacs-mcp