5.2 KiB
Current functional test mode — 2026-10-07
The user requested unrestricted functional testing. This supersedes the earlier diagnosis and restrictions described below.
- The live remote broker's ACL plugin was removed over SSH and the broker restarted. An original configuration backup is on the server. Password authentication remains; any authenticated account can publish/subscribe to any topic.
- The Docker observer was rebuilt and restarted with
topics.observe_all=true. It subscribes torobot-market/test/v1/#, displays raw payloads and performs no JSON-schema, device identity or timestamp validation. - Independent socket-client checks passed for MQTT 3.1.1 and MQTT 5, over plaintext 1884 and TLS 8884. Each used the esp32-lab-001 account for BOTH publication and subscription on sim-001/telemetry, sending the user's exact JSON with a literal
{{$isoTimestamp}}. The broker delivered it and the browser snapshot recordedmessage_received. Arbitrary device/category topic plus plain text also passed in all four combinations. - Go tests passed with the race detector. These checks exercise the deployed broker and viewer without using the simulator; the Postman application itself still needs a successful connection.
Live broker logs also show repeated clients attempting TLS against the plaintext listener (host port 1884 mapped to container 1883), resulting in protocol errors before MQTT authentication. A client doing this cannot publish anything, regardless of payload or topic permissions. In Postman create a new MQTT request and use mqtt://109.122.252.129:1884 for plaintext, or mqtts://109.122.252.129:8884 for TLS with the supplied CA. SSL certificate verification settings control certificate checks, not the choice between plaintext and TLS.
Earlier diagnosis (superseded)
Findings and corrections
The deployed observer was connected to the remote broker but subscribed only to sim-001. The supplied physical-device kit publishes under esp32-lab-001, so those packets never reached the observer. Compose now configures both identities using exact ACL-authorized topics: telemetry, status, commands and acks. Message device identity is derived from the topic before contract validation and display.
Incoming payloads previously had to match the simulator JSON contract before their contents could be displayed. Arbitrary Postman/device payloads produced a generic validation event with omitted contents. The Docker test observer now explicitly enables bounded raw diagnostics. Failed contracts show their received contents and a validation reason, while successful compatibility evidence still requires a valid contract. Default non-Docker configuration keeps raw diagnostics disabled.
Device accounts can publish their own telemetry/status/acks and read commands. A Postman subscriber must use the test-backend account to receive telemetry. Publishing credentials and topic identity must match. No broker ACL change was needed.
Verification
The observer Docker image was rebuilt and the observer container recreated. The simulator remains stopped. Go tests passed with the race detector. Existing opt-in Go remote tests were skipped in that run; the following independent live check was run separately.
A standalone Python socket client, independent of the Go simulator and Paho transport, used the ESP32 kit credentials to publish QoS 1 non-retained telemetry. A separate test-backend client subscribed to the same exact topic. Each check verified successful CONNECT, SUBACK, PUBACK, exact payload delivery to the independent subscriber, and matching events in /api/snapshot.
| Transport | Protocol | Valid telemetry | Plain-text diagnostic |
|---|---|---|---|
| TCP 1884 | MQTT 3.1.1 | PASS | PASS |
| TCP 1884 | MQTT 5 | PASS | PASS |
| TLS 8884 with trusted CA | MQTT 3.1.1 | PASS | PASS |
| TLS 8884 with trusted CA | MQTT 5 | PASS | PASS |
Valid payloads appeared as message_received for esp32-lab-001. Plain-text payloads appeared as validation_failed, with the exact bounded payload visible. This proves the deployed broker/client/viewer path; it does not claim that physical ESP32 firmware or the Postman UI was exercised.
Quick physical-device or Postman test
Connect to mqtt://109.122.252.129:1884, using the ESP32 kit username/password and a distinct client ID. Publish hello from esp32 to robot-market/test/v1/esp32-lab-001/telemetry, QoS 1, retain false. It should appear in the browser at http://127.0.0.1:8080 as a contract error with its text. Then publish the kit JSON to get a valid contract event.
To receive that publication in Postman, use the local test-backend credential handoff and subscribe to robot-market/test/v1/esp32-lab-001/telemetry. A device-account telemetry subscription is not authorized. To receive commands as a device, subscribe to robot-market/test/v1/esp32-lab-001/commands.
Refresh the browser after rebuilding and clear topic/device filters. Subscriptions cover only the configured devices and four categories, not arbitrary broker topics. Payloads are limited to 16 KiB, previews to 4 KiB. The observer cannot determine a publisher's negotiated protocol from a normal forwarded payload; hardware MQTT 5 proof still requires broker session evidence or native-property command replies.