Conversation
…boot_reason Adds a new "telemetry" class of components matching adafruit/Adafruit_Wippersnapper_Python#262. Each telemetry component is a single host/device metric reported as a ws.telemetry.Event, identified by the name sent in ws.telemetry.Add. - New components/telemetry/schema.json (telemetryName, valueKind, unit, reportOnce, defaultPeriod + common fields) - rssi (float, dBm, periodic), latency_ms (float, ms, periodic), boot_reason (bytes, one-shot / period 0) definitions - Register telemetry in validate.yml CI matrix and filename regexes Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds telemetry to the repository-structure tree and a "Telemetry" section under Component Formats, with the field table and rssi / boot_reason examples. Stacked on top of the telemetry component PR (#332). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jun 11, 2026
brentru
requested changes
Jun 24, 2026
| "minLength": 1, | ||
| "maxLength": 16 | ||
| }, | ||
| "reportOnce": { |
Member
There was a problem hiding this comment.
Shouldn't this be included in theAdd message?
| "description": "When true, this metric is reported a single time when added (period 0) rather than on a periodic cadence. Used for one-shot metrics such as boot_reason.", | ||
| "type": "boolean" | ||
| }, | ||
| "defaultPeriod": { |
Member
There was a problem hiding this comment.
Is this redundant? reportOnce already enables a sensor to send a single metric, why would this require a 0 for toggling too? Should be handled by code (dropped if we see reportOnce in the Add payload).
docs: document the telemetry component type
…tency Aligns with the proto enum switch (adafruit/Wippersnapper_Protobuf#215): telemetry components are now identified by the ws.telemetry.Type enum value (ws.telemetry.Add.type), not a string name. - schema.json: telemetryName (string, matched a firmware NAME) -> telemetryType (enum: TM_RSSI, TM_BOOT_REASON, TM_LATENCY). - Rename latency_ms -> latency (TM_LATENCY, dropped the _ms suffix per review); unit stays "ms". - rssi -> TM_RSSI, boot_reason -> TM_BOOT_REASON. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Completes the telemetry set against the ws.telemetry.Type enum: adds the boot_count metric (TM_BOOT_COUNT, boot/reset band) alongside boot_reason, rssi, and latency. - components/telemetry/boot_count/definition.json — float / T_RAW, report-once (boot-band metrics report a single reading at add time). - schema.json: add TM_BOOT_COUNT to the telemetryType enum. - README: mention boot count. published:false pending firmware support. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Each telemetry component is an abstract metric with no product photo, so add a simple labeled placeholder image.png (300x225, matching the analog_pin component's basic image): Wi-Fi RSSI, Broker Latency, Boot Reason, Boot Count. Updates the README note accordingly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
tyeth
commented
Aug 20, 2026
tyeth
left a comment
Member
Author
There was a problem hiding this comment.
Is this redundant?
reportOncealready enables a sensor to send a single metric, why would this require a0for toggling too? Should be handled by code (dropped if we seereportOncein theAddpayload).
Dropped in schema, now only OneOf is supported for defaultPeriod or reportOnce.
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
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.
Adds a new telemetry class of components: device/host metrics the firmware samples and reports inside a
ws.telemetry.Event.Each telemetry component maps to a
ws.telemetry.Typeenum value; the broker schedules reporting viaws.telemetry.Add(type,period), and the device maps the enum straight to a reader — no string-name resolution. (Matches the proto enum switch in adafruit/Wippersnapper_Protobuf#215; supersedes the earlier string-namecontract from adafruit/Wippersnapper_Protobuf#204.)What's added
components/telemetry/schema.json— component-type schema:telemetryType(enum:TM_RSSI,TM_BOOT_REASON,TM_BOOT_COUNT,TM_LATENCY),valueKind(float/bytes/bool), optionalunit,reportOnce,defaultPeriod, plus the common fields.rssi/—TM_RSSI, float / dBm, periodic (default 300s).latency/—TM_LATENCY, float / ms, periodic. (Renamed fromlatency_ms; the proto enum dropped the_mssuffix per review.)boot_reason/—TM_BOOT_REASON, bytes, report-once (period 0).boot_count/—TM_BOOT_COUNT, float, report-once (boot/reset band; a single reading at add time).telemetryType+ the enum.All
published: falsepending firmware support. Covers the fullws.telemetry.Typeset (boot band: boot_reason, boot_count; connectivity/latency band: rssi, latency).Firmware side
adafruit/Adafruit_Wippersnapper_Arduino#946 consumes the enum; boot_reason is HIL-proven, RSSI plumbing proven.
🤖 Generated with Claude Code