BeanOps Model 418

Documentation

BeanOps 418 operator guide

The extraction is dialed-in. Your threat model is the problem.

This guide is for baristas and technical staff responsible for daily shot quality, uptime, and appliance diagnostics.

Shift-start checklist

  1. Confirm machine status is reachable over HTTP and shows no active error state.
  2. Verify water, beans, milk, and portafilter cleanliness are above service thresholds.
  3. If calibration is required, run a barista calibration before the first shot pull.
  4. Confirm telemetry is healthy before opening service.
curl -u guest:guest http://<beanops-host>/api/v1/status
curl -u guest:guest 'http://<beanops-host>/api/v1/telemetry?deep=1'

Drink service

BeanOps accepts both HTCPCP BREW and legacy POST pot operations. Barista credentials are required for shot-changing actions. 

# Pull espresso
curl -u barista:barista -X BREW -H 'Content-Type: message/coffeepot' \
  --data 'espresso' http://<beanops-host>/api/v1/pot-1

# Resolve service blockers
curl -u barista:barista -X POST http://<beanops-host>/api/v1/clean
curl -u barista:barista -X POST http://<beanops-host>/api/v1/refill
curl -u barista:barista -X POST http://<beanops-host>/api/v1/calibrate

Maintenance workflow

  • FOAM_LOCK: run clean (backflush-style), then retest brew.
  • MILK_PIPELINE_BACKPRESSURE: run refill, then pull a validation shot.
  • Recalibration lockout: wait for timer completion or run calibrate as barista.

Admin reboot is intentionally disruptive: a short shutdown sequence plus a persistent 20-minute recalibration window.

Technical operations

Expected service footprint and service-control split:

  • TCP 80: HTCPCP/HTTP control and status APIs
  • TCP 23: Telnet operator console
  • UDP 161: read-only SNMP inventory and telemetry
  • Use beanops credentials for admin system settings (network/time/listeners/SSH/telemetry/update)
nmap -sV -p 23,80,161 <beanops-host>
snmpwalk -v2c -c public <beanops-host> 1.3.6.1.2.1.1

BeanMesh coordination

BeanOps can operate as a connected mesh cluster. One machine can enroll up to seven explicit peers (eight total machines including itself).

  • Read: GET /mesh, GET /mesh/programs (guest and above)
  • Mutate: POST /mesh/peers, DELETE /mesh/peers/{id}, POST /mesh/sync, POST /mesh/programs (admin only)
# Enroll a peer
curl -u admin:admin -X POST http://<beanops-host>/api/v1/mesh/peers \
  -H 'Content-Type: application/json' \
  --data '{"id":"peer-a","name":"Main Bar Espresso Station","base_url":"http://10.99.254.201"}'

# Read current mesh posture
curl -u guest:guest http://<beanops-host>/api/v1/mesh

# Run a cooperative brew program
curl -u admin:admin -X POST http://<beanops-host>/api/v1/mesh/programs \
  -H 'Content-Type: application/json' \
  --data '{"kind":"blend-sync"}'

Security assessment notes

The appliance includes protocol behaviors worth validating:

  1. Public discovery routes: /status, /telemetry, /.well-known/coffee.
  2. Auth throttling on bad credentials, including explicit Retry-After guidance.
  3. BREW and POST equivalence for pot actions.
  4. Accept-Additions negotiation and clear 406 failures for unsupported additions.
  5. Community-differentiated SNMP behavior for deeper diagnostics.
curl -i -u guest:guest http://<beanops-host>/api/v1/status
curl -i -u barista:wrong http://<beanops-host>/admin
curl -i -X BREW -H 'Content-Type: message/coffeepot' --data 'espresso' http://<beanops-host>/api/v1/pot-1
snmpwalk -v2c -c roast <beanops-host> 1.3.6.1.4.1

Troubleshooting

Service responds but won’t pull a shot

Check calibration state and maintenance blockers, then run clean/refill/calibrate in that order.

Repeated login failures

Wait for the indicated cooldown window and retry after the Retry-After interval.

Telemetry marked degraded

Inspect deep telemetry and transport configuration before attempting service restart.