46 lines
5.2 KiB
Markdown
46 lines
5.2 KiB
Markdown
# 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 to `robot-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 recorded `message_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.
|