Mqtt bridge implementation flex update#3
Open
Elektr0Vodka wants to merge 82 commits into
Open
Conversation
…lse airtime calcs. Left update in the startsendraw as a safety, but should not be used under normal circumstances
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. It is working fine on my end on multiple nodes. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always "self" and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one of the same type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far. - RAK12035 and other current upstream dev branch changes integrated.
Align TX activity LED with LED_BLUE / variant.h after LED definition and power-button pin mapping changes.
This is for Xiao S3 and a normal Wio SX1262 for Xiao shield.
With the '^x.y.z' semantics, the version can upgrade out from under us and change dependencies, so this pins to an exact version.
…lar-tx-led-12 fix(sensecap_solar): correct TX LED after remap & power-button pin changes
…device-model fix: correct device model name for Heltec Wireless Paper
feat: Enable GPS on RAK 1W kit
Introduce DataType Definitions for Meshcore Open
…3-202604 Added Xiao S3 variant
Add MeshCore website to splash screen
Add unit tests for Utils::toHex
…radio_set_tx_power()
Don't play startup tune if buzzer pref disabled
…anup Refactor: removed duplicated target code
The `::init` method in the Adafruit ST7789 library is responsible to initialize the device. This includes performing a reset, which can be found in the Adafruit source for `Adafruit_SPITFT`. Before this change, MeshCore performed its own ST7789 display reset sequence, which consisted of three steps. * Pull reset low * Wait 10ms * Pull reset high Importantly, there was no fixed delay after pulling reset high. The ST7789 driver requires a delay (T<sub>RT</sub>) of 5ms in Sleep In Mode and 120ms in Sleep Out Mode before it will properly receive commands. When `Adafruit_SPITFT` resets the device after MeshCore has already reset it, the mandatory time may not have elapsed, leading to strange behavior. In the author's case, this issue caused the initial `fillScreen` to fail, such that the display showed an uninitialized framebuffer. This removes the MeshCore delay, leaving the responsibility of reset to `Adafruit_SPITFT`, where they have the correct delays in place with extra safety margin. The change was briefly tested by Josiah VanderZee and Ben Zignego on a custom hardware build using an nRF52840 Dongle and an Adafruit 4311 TFT display. The user button seemed to behave strangely, but the display looked correct.
…et-timing Do not perform redundant reset on ST7789 displays
…y-rxdelay Docs: Add explanatory notes for txdelay, direct.txdelay, and rxdelay
Incorrect time_t TypeDef used in RAK12035_SoilMoisture
fix CustomLFS version pinning
Do not reference it unconditionally
…-sensor-refactor fix(sensors): improve sensor initialization and handling to prevent hangs and handle growth
…n-undefined Gate PIN_GPS_EN
…ding un-scoped * FIRMWARE_VER_CODE bumped to 12
…e-none Companion: Set flood scope to None
This slipped through in PR meshcore-dev#2327 and I noticed because the TechoBoard.h for my variant doesn't include the Wire header, so the source file in question does not coincidentally obtain a copy.
…clude Add missing Wire.h include to sensors
…n-repeat-build-flag Add build flag to configure allowed repeat frequency range
Enhance KissModem frame processing and timeout handling
Merge meshcore-dev changes (kiss_modem targets, preamble SF tuning, CI). Resolve conflicts: combine RadioLib preamble/watchdog fields; keep kiss_modem and MQTT envs. Co-authored-by: Cursor <cursoragent@cursor.com>
Updated MyMesh implementations in simple_repeater and simple_room_server to set mqtt_origin to an empty string, allowing the effective origin to follow node_name during publishing. Introduced new functions in MQTTBridge to manage effective origin retrieval and refresh from preferences, ensuring consistent behavior across MQTT operations. This change simplifies the origin management and enhances clarity in the codebase.
Updated the MQTT message structure to add a new field for repeat status, allowing the indication of forwarding status as "on" or "off". This change includes modifications to the MQTTMessageBuilder and related documentation to reflect the new parameter. Additionally, updated CLI command documentation to clarify flooding behavior in different firmware versions.
Implemented a new function to strip surrounding quotes from strings in TxtDataHelpers, enhancing string manipulation capabilities. Updated CommonCLI to handle MQTT origin configuration, allowing for both setting and clearing of the mqtt.origin preference. This change improves the flexibility of MQTT origin management in the CLI.
Added ColoradoMesh as a new built-in preset in the MQTT bridge documentation. Updated relevant sections to reflect this addition, including command examples and notes on topic templates. This enhances the flexibility and options available for MQTT connections.
…idge-implementation-flex
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
20 participants
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.
No description provided.