Conversation
…ole on it. A panel with no known Wi-Fi in reach raises an access point named after itself (patternflow-a1b2, WPA2, password "patternflow" until changed), and the whole console is at http://192.168.4.1/ on it: patterns, knobs, the Wi-Fi page to add the next place's network, updates. Modes on /wifi and /api/hotspot: auto (the default - up fifteen seconds after the last link, down once a network is joined and nobody is on it), always, off. Status carries a hotspot object; the NETWORK screen shows the name while the hotspot is what there is. Core, not a feature: Wi-Fi is the device's. The bench ran six rounds before the phone loaded a page in under a second, and each round is a line in core_hotspot.h's header: - the channel comes from a scan (least loaded of 1/6/11), never a fixed one - channel 1 sat under three -33 dBm networks and the SSID flickered; - every console module waited for WL_CONNECTED before registering, so on the hotspot a phone got an address and port 80 never opened - PatternflowWifi::linkUp() is the condition now, for the core pages and the audio, microphone, clock and MQTT pages, and the hotspot raises the same link edge the station does; - a station interface that is merely present - scanning, retrying, idle - drags the AP's transmit to a crawl (a 13 KB page cut at 5.7 KB after 20 s), so alone the radio runs AP-only and the station comes back for a rare probe with nobody connected, or when credentials arrive; - the 13 dBm transmit cap made a phone beside the panel take 4-9 s per 10 KB page and under a second at full power: the cap is retired, the owner's call, conformance to be handled elsewhere; - answering the phone's internet probe with a 204 put a Samsung into its limited-connectivity state and it dropped the network; a DNS responder on the hotspot answers every name with the panel so the verdict comes in a second, and the probe gets the console's ordinary 404; - the web server waits one second, not five, for a connection that sends nothing - a browser's spare connections were holding the real requests. Verified on the bench board: home network joined at full power with the hotspot down in auto; always brings it up beside the station on its channel and auto drops it; the API's validation; the /wifi section. In the field scenario (no network) with the user's phone: joins first time, console pages 0.5-3 s, DNS answered, no drops over the session. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…t; the host test knows the mode. Three things the first field use found. Booting in `always` mode raised the hotspot at one second and switched the station off under its own first attempt, so a panel with good credentials never joined - the station is dropped only after the fifteen-second grace now, in any mode, and never while a probe is in flight. The console's reconnect did nothing while the radio was AP-only - it brings the station back first. The "someone nearby is scanning" gate on station probes is gone: in a home or a venue somebody always is, and the panel would never have rejoined a network that came back; probes stay off only while a client is on the hotspot. check_network.py compiles core_wifi.h against a mock radio with -Werror: the mock learns getMode()/mode() and the mode constants, and the retry cadence has a fallback define for a build without net_config.h. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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
1 participant
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.
The panel is a network of its own: a hotspot (
patternflow-a1b2, WPA2,patternflow) whenever it has no known Wi-Fi in reach, with the whole console athttp://192.168.4.1/on it. Modesauto(default) /always/offon/wifiand/api/hotspot; ahotspotobject in status; the NETWORK screen shows the name.Core change. Six bench rounds are written into
src/core_hotspot.h's header and the changelog: channel from a scan (never a fixed one),PatternflowWifi::linkUp()instead ofWL_CONNECTEDfor every console service (core pages and the audio/mic/clock/MQTT pages), AP-only radio when alone, DNS answered on the hotspot so the phone's internet check fails within a second instead of twenty, the web server's idle-connection wait 5 s → 1 s, and the 13 dBm transmit cap retired (owner's decision - a phone next to the panel took 4-9 s per page at 13 dBm and under a second at full power).Verified:
build.sh all+ footprint within tolerance for all five compositions; bench board joins the home network at full power with the hotspot down,alwaysbrings it up beside the station, the API validates; in the field scenario with a phone: joins first time, pages 0.5-3 s, no drops.🤖 Generated with Claude Code