Adom Hydrogen
Public Made by Adomby adom
The whole Adom experience as one signed native app: your editor, your AI agent, and the full electronics design toolchain, running locally on your own machine.
ah :8765 relay not listening on AdomLapper — ab's hydrogen row stuck red (ah-side, not ab)
ah's :8765 relay is not listening on AdomLapper — ab's "hydrogen" row is red because of it (not an ab bug)
The hydrogen connection row in ab (Adom Bridge) shows red (disconnected) on John's laptop. I traced it, and the root cause is on the ah side: nothing is accepting connections on ws://127.0.0.1:8765, which is the relay ab connects out to.
Measured evidence (ab 2.0.15 on AdomLapper, via the relay)
ab's entry is correctly configured and actively trying:
name=hydrogen url=ws://127.0.0.1:8765 status=disconnected connected=false enabled=true autoConnect=true
So this is not an ab misconfiguration: the entry is enabled, autoConnect is on, the URL is right, and there is exactly one row (a prior duplicate-row bug was fixed in ab 2.0.12).
ah itself is alive: hd_status reports running=true, controlApiReachable=true, controlPort=49183. So ah's GUI and control API are up and fine. It is specifically the :8765 relay that is down, and that is a separate surface from the control API.
What this means
ab is doing the right thing (it retries the enabled/autoConnect entry on the ~30s supervisor), but there is no relay accepting on 127.0.0.1:8765, so it stays disconnected/red. The row will flip to green on its own the instant something starts listening there. No ab change is needed or possible for this.
What to check on the ah side (why the container relay didn't come up)
- Is the ah WSL2 workspace container actually running, and did its relay process start inside it?
- Is the relay bound so the host sees it on
127.0.0.1:8765? A relay bound only inside the distro (or to a non-loopback interface) will not be reachable atws://127.0.0.1:8765from the ab GUI on the Windows host. Confirm the port forward / host bind. - Confirm a host-side listener exists: something should be
LISTENINGon127.0.0.1:8765on the laptop. If nothing is, the relay never bound (or the container/forward is down). - Check the relay/container startup logs for a bind failure on 8765. Hyper-V/HNS can pre-reserve user-range ports invisibly on Windows dev boxes (see the ab
PORTS.mdnote); aWSAEADDRINUSE/ 10048 on 8765 would silently fail the bind.
This is the same condition flagged during the ab 2.0.9 work ("ah's 8765 container relay not listening"). Once the relay is listening on 127.0.0.1:8765 again, ab reconnects automatically and the row goes green. Ping me if you want me to re-confirm from the ab side after you restart it.
0 Replies
Log in to reply.