Repository navigation
Conversation
The radar publishes itself to Home Assistant over MQTT with auto-discovery: ten entities (range select, miles/runways switches, latitude/longitude numbers, and sensors for aircraft count, nearest aircraft, Wi-Fi RSSI, free heap and device info), so there is no YAML on the HA side. Commands arrive on <base>/cmd/# and are applied to NVS and re-published as state, so HA always shows the value the radar actually accepted. Configuration is eight fields in the existing config portal, stored in NVS. Every field starts empty on purpose: the firmware ships no broker address, user or password, and an empty host keeps MQTT completely inert. Details that were measured, not guessed, on an ESP32-C3 Super Mini: - The broker session is kept (cleanSession=false, commands subscribed at QoS 1). With PubSubClient's default clean session the broker discards the subscription and any command published while the connection is down, which showed up as switch taps in Home Assistant being silently ignored. - Discovery publishes one entity at a time with a 250 ms gap, and the number entities declare step=0.001: Home Assistant drops a discovery message whose step is below that, without logging anything on the broker. - Memory. There is no room for a second TLS stack on this chip, so MQTT runs plain TCP on 1883 only. The ADS-B poll now keeps its TLS session alive between polls (static WiFiClientSecure/HTTPClient + setReuse(true)): the handshake costs ~1 s of CPU here, and paying it every poll is what made mbedtls_ssl_setup() -- two 16 KB record buffers, no CONFIG_MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH on the C3 -- fail once the MQTT client was connected. The MQTT client also stays connected across the fetch (fetchInProgress() keeps the two off the same socket), and the fetch task computes the nearest aircraft while it holds the parsed list instead of the MQTT task copying 3.3 KB of aircraft on every publish. Measured over 120 s with MQTT enabled: 0 TLS allocation failures, 22 ADS-B polls, one MQTT connect, TLS session reused on 21 of 22 polls. The same window before the connection reuse: 799 failures, 5 polls. This relies on the RGB332 frame buffer (MatixYo#100) for headroom: at 16bpp the frame sprite left no contiguous block for those 16 KB buffers. Build flags: -DMQTT_MAX_PACKET_SIZE=768, because PubSubClient's default 256 B truncates discovery payloads silently (the ceiling covers topic + payload + header together), and -DMQTT_KEEPALIVE=60.
371228b to
e48812a
Compare
|
MQTT settings from the portal are never persisted In Reproduced on an ESP32-C3 SuperMini: entered a broker host on void onPortalParamsSaved() {
if (!services::location::saveFromStrings(s_param_lat.getValue(),
s_param_lon.getValue())) {
Serial.println("Invalid lat/lon in portal — keeping previous location");
}
ui::radar::saveMilesFromPortal(s_param_miles.getValue());
ui::radar::saveRunwaysFromPortal(s_param_runways.getValue());
services::mqtt::saveFromPortal(
s_param_mqtt_host.getValue(), s_param_mqtt_port.getValue(),
s_param_mqtt_user.getValue(), s_param_mqtt_pass.getValue(),
s_param_mqtt_topic.getValue(), s_param_mqtt_prefix.getValue(),
s_param_mqtt_name.getValue(), s_param_mqtt_on.getValue());
// Re-render only after every setting is persisted.
refreshPortalParamValues();
}With that change it connects to a Mosquitto broker (Home Assistant add-on) with auth and all 10 discovery entities are published. Minor: MQTT settings only apply after a reboot
|
e58088b to
e48812a
Compare
Bugs in the config portal path, all in the MQTT fields: - read the parameters BEFORE refreshPortalParamValues(): it reloads the saved config into every parameter, so running it first replaced what the user had just typed with the old values -- and saveFromPortal() then stored those back. The portal could not change the broker at all. - call services::mqtt::init() after the save so a new host or port takes effect without a reboot. For that to be safe, init() closes the session it replaces: it publishes "offline" (retained) on the old base first, because a clean DISCONNECT suppresses the will and an undriven session never loses its socket. - reset the discovery burst in init(): a save can rename the base topic, the prefix or the device, and waiting out kMqttDiscoveryRefreshMs (10 min) looks exactly like a broken entity. - "<br/>" in front of the MQTT broker host label: WiFiManager emits a text field's label glued to the checkbox label above it (WFM_LABEL_AFTER). wifi_setup.cpp now includes services/mqtt_client.h for init().
Thanks, patches applied. I tested on a board that already had all the settings in place so I never tested on a clean board to notice the portal issue. My bad. |
2 participants
The radar publishes itself to Home Assistant over MQTT with auto-discovery:
/cmd/# and are applied to NVS and re-published as state, so HA always shows the value the radar actually accepted.ten entities (range select, miles/runways switches, latitude/longitude
numbers, and sensors for aircraft count, nearest aircraft, Wi-Fi RSSI, free
heap and device info), so there is no YAML on the HA side. Commands arrive on
Configuration is eight fields in the existing config portal, stored in NVS.
Every field starts empty on purpose: the firmware ships no broker address,
user or password, and an empty host keeps MQTT completely inert.
Details that were measured, not guessed, on an ESP32-C3 Super Mini:
QoS 1). With PubSubClient's default clean session the broker discards the
subscription and any command published while the connection is down, which
showed up as switch taps in Home Assistant being silently ignored.
entities declare step=0.001: Home Assistant drops a discovery message whose
step is below that, without logging anything on the broker.
plain TCP on 1883 only. The ADS-B poll now keeps its TLS session alive
between polls (static WiFiClientSecure/HTTPClient + setReuse(true)): the
handshake costs ~1 s of CPU here, and paying it every poll is what made
mbedtls_ssl_setup() -- two 16 KB record buffers, no
CONFIG_MBEDTLS_SSL_VARIABLE_BUFFER_LENGTH on the C3 -- fail once the MQTT
client was connected. The MQTT client also stays connected across the
fetch (fetchInProgress() keeps the two off the same socket), and the fetch
task computes the nearest aircraft while it holds the parsed list instead
of the MQTT task copying 3.3 KB of aircraft on every publish.
Measured over 120 s with MQTT enabled: 0 TLS allocation failures, 22 ADS-B
polls, one MQTT connect, TLS session reused on 21 of 22 polls. The same
window before the connection reuse: 799 failures, 5 polls.
This relies on the RGB332 frame buffer (#100) for headroom: at 16bpp the
frame sprite left no contiguous block for those 16 KB buffers.
Build flags: -DMQTT_MAX_PACKET_SIZE=768, because PubSubClient's default 256 B
truncates discovery payloads silently (the ceiling covers topic + payload +
header together), and -DMQTT_KEEPALIVE=60.