Repository navigation
feat(sensors): reach the MQTT hub through remote access, over WebSockets at /mqtt - #508
Merged
Merged
Conversation
…ets at /mqtt The broker also listens for MQTT over WebSockets (sensors.mqtt_web, off by default; sensors.mqtt_web_port 9883) and the web app relays /mqtt to it, upgrades included, so the Cloudflare tunnel and HTTPS reach the hub. There every client signs in with a hub login (never anonymous) and failed logins are throttled per visitor, read from X-Forwarded-For as trusted proxies report it. Docs say why SMB, NFS and syslog stay on the local network. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CXpr1EWCfUD5tb1SmSwfDa
…-ppx7di # Conflicts: # threat-model.yaml
…-ppx7di # Conflicts: # threat-model.yaml
…-ppx7di # Conflicts: # threat-model.yaml
…-ppx7di # Conflicts: # README.md # threat-model.md # threat-model.yaml
…-ppx7di # Conflicts: # CHANGELOG.md # threat-model.yaml
…-ppx7di # Conflicts: # CHANGELOG.md # threat-model.yaml
20 of 23 tasks
adeelahmad
added a commit
that referenced
this pull request
Oct 17, 2026
…525) threat-model.yaml kept a sha256 of the whole prose, so any two pull requests that changed threat-model.md both rewrote that one line and the second to merge conflicted (#400, #508). The YAML's prose_version now names the prose in the same commit, and the validator's new --base check (run by CI against the merge commit's parent) fails a change to the prose that changes neither companion, which is what the hash enforced, without a line every change edits. Adds tests, including two branches that change the prose in different places merging cleanly and still validating. Fixes #507 Claude-Session: https://claude.ai/code/session_01Bwc5go44W4hjHKu329MepB Co-authored-by: Adeel Ahmad <noreply@anthropic.com>
…-ppx7di # Conflicts: # docs/requirements.md # threat-model.yaml
The merge of main took main's whole threat-model.yaml, dropping the /mqtt entry point, the sensors.mqtt_web flag and P-SENSORS' conditions. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CXpr1EWCfUD5tb1SmSwfDa
This was referenced Oct 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Before: Remote access (the Cloudflare tunnel) and HTTPS reached only the web app, so the sensor hub's MQTT broker on port 1883 was out of reach for a phone or a sensor away from home.
After: with MQTT at the web app's address too on in Settings › Sensors (off by default), devices anywhere publish and subscribe at
wss://<your address>/mqtt, the same broker as port 1883. Every client there signs in with a hub login (anonymous clients are refused even where 1883 allows them), and too many wrong passwords from one address are throttled like sign-in. Remote access now says what it reaches and why SMB, NFS and syslog stay on the local network.How: the hub's broker also takes MQTT over WebSockets on port 9883 (
sensors.mqtt_web_port), through thewebsocketslibrary Lens already ships (the Slack connector uses it too), andlens-relay.js, which already relays/s3and/dav(#402), passes/mqttupgrades to it with the visitor's address, so throttles see the real client. The compose files point the web app athttp://worker:9883.Motivation and Context
The owner asked whether remote access reaches S3, WebDAV, MCP and other protocols, and to add what it doesn't. S3 and WebDAV landed in #402; MCP already worked over HTTP. This adds MQTT, the remaining protocol that can travel over HTTP.
Types of changes
!in the title)Checklist:
make hookschecks it on commit).docs/accordingly.## UnreleasedinCHANGELOG.md.Done questions (AGENTS.md)
sensors.mqtt_web), and any MQTT client with a WebSocket transport connects.LENS_MQTT_WS_URL; turning it on is one switch.wss://address next to the MQTT port.sensors.mqtt_webandsensors.mqtt_web_portin Settings › Sensors, with defaults (off, 9883).make openapi).websocketslibrary already installed, and thelens-relay.jsrelay from feat(shares): reach S3 and WebDAV through remote access, at /s3 and /dav #402.Local CI (
ci/local-ci.sh): Next.js, pre-commit and PR title pass; the backend run caught a timing race in the new WebSocket test (a client count read before a closed client's goodbye arrived), now waited for and passing five runs in a row.Generated by Claude Code