Troubleshooting & FAQ

FAQ

Does any factory data leave the site? No. Every service runs on an internal network with no route to the internet. The only two outbound paths anywhere in the system — an opt-in signed update check and an opt-in, time-boxed support tunnel — are off by default and never carry telemetry. See Security model.

Does the language model see live sensor data or control anything? No. Counts, states, alarms and defect verdicts all come from the deterministic detectors and the vision worker, never from the local model. The model is used only for onboarding assistance and for explaining results in Ask. See Local inference & models.

Can ReduceWaste write to my PLCs? No, not in this release. Every OT adapter is read-only: Modbus write function codes are rejected in code, and OPC UA sessions are opened read-only. See Security model and OT network safety.

Am I locked into a specific sensor vendor? No. Every recipe specifies a generic sensor spec (signal kind, unit, range); the listed example_parts are illustrative, not a requirement. See Sensors & recipes.

What does a sensor actually cost? Each recipe states a cost range, based on the example parts listed on that recipe — not a quote. Price the specific part you intend to buy for a firm number. ReduceWaste itself has not published pricing, a beta factory list, or a launch date; treat any such figure outside an official release note as unconfirmed.

What hardware do I need? It depends on site size — see Hardware sizing. A laptop or small box is enough to try the demo plant; a full single-site deployment targets one GB10-class unified-memory box, with larger or multi-line sites adding boxes by role.

Can I run this with no Kubernetes or cloud account at all? Yes — Docker Compose on a single on-site box (or a few) is the supported path today; see Install with Docker Compose and Air-gapped install.

docker compose ... --wait never reports healthy

Check the specific container’s health check and logs:

docker compose ps
docker logs <container-name>

A common cause for rw-historian is a stale data volume from an older schema — see the next item.

Port already allocated (historian / another dev port)

The dev-only host ports (for example the historian’s forwarder) default to standard ports such as 5432. If that port is already used on your machine, set the matching environment variable before bringing the service up, for example:

RW_HISTORIAN_PORT=55433 docker compose --profile dev up -d --wait rw-historian-dev-port

Then point rw at the same port in $RW_DSN.

rw db migrate fails with a changed-migration error

A migration file’s checksum changed after it was already applied. Never edit an applied migration — add a new one instead, and re-run rw db migrate.

No signals showing up after rw site load

Confirm the edge reader actually has a config pointed at the right devices (RW_EDGE_CONFIG, mounted from ${RW_EDGE_DIR}/edge.yaml), and that its signal paths match the signal ids in the site file you loaded — rw-ingest validates every sample against the registry and drops anything that does not match a known (site, signal) pair.

The app container is healthy but the page does not load

The app binds to 127.0.0.1 by default (RW_APP_BIND). If you are connecting from another machine, you will not reach it on that address — either tunnel in, or explicitly set RW_APP_BIND to an address you intend to expose, understanding that this changes who can reach the operator UI.

A recipe fails rw recipes lint

Run the linter directly for the specific error:

uv run rw recipes lint recipes/

It validates every recipe’s YAML against its schema; the error message names the file and field that failed.

Still stuck

Open an issue on the project’s GitHub repository with the exact command you ran and its full output — see the social link in the site footer.