Add QMP6988 telemetry sensor type - #921
Open
mokjpn wants to merge 82 commits into
Open
Conversation
This was referenced May 24, 2026
The comment documents ground_speed as m/s, but the firmware transmits it in
km/h. In meshtastic/firmware, GPS::lookForLocation() is the only place the GPS
path sets the field:
// src/gps/GPS.cpp
p.ground_speed = reader.speed.kmph(); // TinyGPS++ .kmph() -> km/h
PositionModule.cpp copies the value through unchanged. So the on-the-wire unit
is km/h, and clients decoding it as m/s over-report speed by 3.6x. This updates
the doc comment to match the implementation.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Randall Hand <randall.hand@gmail.com>
* Rename Seeed Tracker and add sensor * uh, i'll kill that cat * Dear Copilot, stop messing with me
Add LORA_OTA_APP portnum for firmware updates
…essagable-licensed Add is_unmessagable and is_licensed as fields for DeviceProfile exports
Set up a basic coderabbit yaml
Add Heltec RC series boards
Snapshots were named `<tag>-<shortsha>-SNAPSHOT`. A git short SHA carries no chronological signal, and Maven's ComparableVersion tokenizes it as alpha/numeric garbage, so consumers' Renovate could not tell which snapshot was newest — "latest" resolved to latest-lexical, not latest-commit, and often bumped backwards. Switch to `git describe --tags --long`, yielding `<tag>-<N>-g<shortsha>-SNAPSHOT` where N is the commit count since the tag. N is a leading numeric token Maven compares numerically, so newer commits sort above older snapshots and Renovate picks the newest with no custom versioning. `--long` forces the `-<N>-g<sha>` suffix even on a tagged commit, so a bare `-SNAPSHOT` (which would sort below its base and trigger a downgrade) is never produced. The scheme still sorts above the tag's release and below the next release, preserving prior behavior. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
CodeRabbit flagged packages/kmp/README.md still describing the old
`{tag}-{short-sha}-SNAPSHOT` scheme. Update the versioning table, the
rationale paragraph, the Snapshots section, and the example coordinate to
`{tag}-{N}-g{sha}-SNAPSHOT`, and note that the leading numeric commit
count is what makes newer snapshots sort above older ones.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ot-versions ci: make KMP snapshot versions sort by recency
…shots
Follow-up to the git-describe --long change. That put the commit count in
`{tag}-{N}-g{sha}-SNAPSHOT`, but the count shares a hyphen level with the
old `{tag}-{sha}-SNAPSHOT` snapshots still published in the repo. A short
SHA can tokenize to a large integer (e.g. `678281c` -> 678281) that dwarfs
the count (e.g. 88), so in Maven's ComparableVersion the legacy snapshot
still sorts highest and dependency bots keep pointing at it — the new
scheme is masked and never picked.
Move the count after a dot: `{tag}.{N}-g{sha}-SNAPSHOT`. A dot-separated
numeric segment outranks any hyphen-nested token, so the new snapshots sort
above every legacy `-<sha>-SNAPSHOT` regardless of the SHA's leading digits,
while still sorting above the tag's release and below the next release, and
ordering among themselves by count. Verified against maven-artifact 3.9.9
ComparableVersion:
2.7.26-678281c-SNAPSHOT < 2.7.26.88-gd77b460-SNAPSHOT < 2.7.27
Also add workflow_dispatch so the scheme change (which touches only this
workflow, outside the push-path filter) can be published on demand.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…after-dot ci: separate snapshot count with a dot so it outranks legacy SHA snapshots
Develop dangit
Medium range preset comparable to MEDIUM_FAST but with 500kHz bandwidth.
…eset Add MEDIUM_TURBO modem preset
Ukrainian legislation* was harmonised with the EU's, and UA_868 is now obsolete as it is identical to the EU_868. * https://zakon.rada.gov.ua/laws/show/262-2026-%D0%BF
Add HM330X PM sensor
Deprecate EU_868 region code
- Add packages/kmp/gradle/build-cache.settings.gradle (shared remote HTTP build cache), applied from packages/kmp/settings.gradle.kts and configured from the GRADLE_CACHE_URL / GRADLE_CACHE_USERNAME / GRADLE_CACHE_PASSWORD secrets. Push is enabled only when credentials are present, so fork PRs are pull-only and cannot poison the cache. - Pass GRADLE_CACHE_* to the KMP CI, snapshot, and publish workflows. - Cache ~/.konan across those workflows — each compiles all 14 KMP targets (including native) on macOS from a cold Konan today. Part of the Meshtastic KMP library standard alignment (CI caching). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Addresses CodeRabbit review of the shared build-cache script: - Drop allowInsecureProtocol/allowUntrustedServer — the cache server presents a valid public TLS cert, so enforce HTTPS + certificate validation. - Write to the cache only on trusted events (push/merge_group/local) with credentials present, so pull_request runs stay pull-only and cannot poison the cache. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ci(kmp): add remote HTTP build cache and Konan toolchain caching
…-trigger-and-badge docs: fix broken CI badge in README
…-tag ci: auto-publish every package when a release tag is cut
…Lite.rssi storage field MeshPacket.rx_rssi was proto3 singular, so an unset value and a genuine 0 dBm reading were byte-identical on the wire (0 is a legal SX126x return, and SX127x's offset+register formula can even go positive). Mark it optional so absence survives encoding, mirroring the precedent already set by NodeInfo.hops_away. NodeInfoLite had no RSSI field at all, so nothing survived a device reboot for replayed history packets to restore - every replay showed RSSI 0 regardless of the real measurement. Add NodeInfoLite.rssi (tag 20, sint32, next free tag) with the same "0 is not automatically unknown" caveat; presence is tracked via NODEINFO_BITFIELD_HAS_RSSI on the firmware side rather than a second wire-level bool, to avoid a RAM cost per stored node. Companion firmware change: meshtastic/firmware, phantom-node-fix-perhaps branch, .notes/plans/plan-executed-snr-rssi-replay-fidelity.md.
Rssi explicit presence
…haps Add explicit presence for arrival time: MeshPacket.rx_time optional
* Move ADC values to environment telemetry * Rename to adc_voltage to avoid confusion * Mark some ADS fields and SHTs as deprecated * Make a multi-measurement wildcard measurement * Return to unpacked messages, to avoid sending repeated lists with no data * Remove unused wildcard options * Add one-wire bridge config * Update ADC and One-Wire temperature channel numbers * Fix formatting for deprecated one_wire_temperature field * Remove unnecessary newline in telemetry.proto * Don't generate code for this field.
* Add SEN6X fields * Address comments * Remove extra whitespace in admin.proto
This emits a warning if not removed
Trim unused DrawnShape.vertices
* Add AS3935 lightning sensor telemetry fields Adds lightning_strike_count_1h and lightning_distance_km to EnvironmentMetrics (reset on a rolling ~1h window, matching the rainfall_1h precedent), and an AS3935 entry to TelemetrySensorType, to support meshtastic/firmware#10774. Assisted-by: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Andrew Yong <me@ndoo.sg> * Remove extra newline in telemetry.proto * Add AS3935 tuning capacitance configuration AdminMessage.sensor_config gains AS3935_config with set_tuning_cap_pf, alongside the existing per-sensor configuration messages. AS3935Config holds the trim for saving to flash. The AS3935 does not retain the tuning capacitor across power loss, so firmware stores the value and re-applies it on every boot. --------- Signed-off-by: Andrew Yong <me@ndoo.sg> Co-authored-by: Thomas Göttgens <tgoettgens@gmail.com>
Add new firmware editions for Dragon Con and CCC events
Add SEEED_WIO_TRACKER_L1_PRO_1W
docs(Position): correct ground_speed unit to km/h (matches firmware)
Add the Meshnology W12 to the HardwareModel enum.
…y-w12 Add MESHNOLOGY_W12 hardware model
Add the Seeed Studio MeshPager X2 to the HardwareModel enum.
Add MESHPAGER_X2 hardware model
MeshBeaconConfig.broadcast_send_as_node let a client set a node ID that outgoing beacons would be sent AS, rewriting the packet's `from` field so beacons appeared to originate from another node. Firmware never applied it. The assignment in MeshBeaconModule::sendBeacon() is commented out pending review, so `from` is always the local node number and the field is a settable, persisted no-op: a client can write it, read it back, and see no effect on air. The mechanism was also unsound as designed. Rewriting `from` forges no signature; it only makes isFromUs() false, so Router::perhapsEncode() skips XEdDSA signing and receivers get an unsigned packet attributed to another node. The field never reached a tagged release and has no consumers outside the firmware repo, so it is removed rather than kept. Tag 3 and the field name are reserved to prevent reuse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MeshBeaconConfig had two ways to name a beacon destination. broadcast_on_channel / broadcast_on_region / broadcast_on_preset described a single destination with the channel spelled out inline, and broadcast_targets described up to four, each naming its channel by channel-table index. The firmware silently used one or the other depending on whether broadcast_targets was empty. The comments claimed the two were equal and differed only in representation. They were not: an inline ChannelSettings carries name and PSK, so it could transmit on a channel absent from the node's channel table, which channel_index cannot express. That capability is dropped deliberately - there is no use case for beaconing on a channel the node does not have, and provisioning the channel is not a workaround but the intended way to do it. Removes tags 8, 9 and 10 and reserves them. Empty broadcast_targets now means one beacon on the node's running preset and region over the primary channel, which is what the scalar path produced when it was left unset. Also corrects two statements about broadcast_targets that did not match the firmware: copies are sent per distinct destination, not per entry, because entries resolving to the same effective preset/region/channel are deduplicated. MeshBeaconConfig shrinks 324 -> 246 bytes, ModuleConfig 328 -> 250, against a hard 512-byte FromRadio ceiling. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…-as-node Remove unused beacon broadcast_send_as_node field
…-broadcast-targets Consolidate beacon TX destinations onto broadcast_targets
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
14 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.
What does this PR do?
Adds a new
QMP6988value toTelemetrySensorTypeon the protobufsdevelopbaseline used by current meshtastic/firmware.This is needed for firmware support of the QMP6988 environmental sensor. The corresponding firmware work uses this enum value to identify QMP6988 explicitly in telemetry, and firmware generated sources should be regenerated from this protobuf change rather than patched by hand.
Related:
This replaces #899, which was closed because it was based on
masterand would roll backdevelop-only protobuf changes such as the NodeDB split when used for firmware regeneration.Checklist before merging