ormus-solutions/libreembed-claude-code/iot-protocols
- community
Checking that the SKILL.md file is still in the repository.
IoT protocol reference: selection matrix, MQTT QoS flows and LWT, topic design, CoAP observe and block-wise transfer, LwM2M objects and firmware update, BLE GATT and connection tuning, LoRaWAN airtime and classes, and Paho, Zephyr, and ESP-IDF client code. Use when designing or debugging the protocol layer of a connected device.
Install
npx vskill@latest install ormus-solutions/libreembed-claude-code/iot-protocolsSKILL.md
IoT protocols pattern library
Reference patterns for MQTT, CoAP, LwM2M, BLE GATT, LoRaWAN, Thread, and Zigbee.
Protocol selection matrix
| Constraint | MQTT (TCP) | CoAP (UDP) | LoRaWAN | BLE GATT | NB-IoT / LTE-M | Thread | |
|---|---|---|---|---|---|---|---|
| 10-year battery target | No | Maybe | Yes | Yes (peripheral) | Maybe | Maybe | |
| Internet reach | Yes | Yes | Yes (via gateway) | No | Yes | Maybe (via border router) | |
| > 100 m range | Yes (via WiFi) | Yes (via WiFi) | Yes (up to 10 km) | No | Yes | Yes (mesh) | |
| > 1 kbps throughput | Yes | Yes | No | Yes | Yes | Yes | |
| At-least-once delivery | Yes (QoS ≥ 1) | Yes (CON) | Yes (confirmed) | Yes (indications) | Yes | Yes | |
| Standard cloud ecosystem | Yes | Yes (less mature) | Yes (TTN, etc.) | No | Yes | Maybe |
MQTT state machines
QoS 1 publish flow
Retransmit logic:
- If PUBACK not received within timeout (default 5-30s), publisher retransmits with DUP=1.
- Subscriber may receive duplicate; deduplicate on app-side via msg_id.
QoS 2 publish flow
State persisted at publisher between PUBLISH and PUBCOMP. Retransmit PUBLISH if PUBREC times out; retransmit PUBREL if PUBCOMP times out.
LWT setup
In the CONNECT packet:
When broker detects ungraceful disconnect (TCP RST, keep-alive timeout), it publishes the will message. Subscribers see "device offline" without explicit signaling.
Topic design
Hierarchical with predictable structure:
Examples:
/acme/sensor/dev-abc-123/temperature/acme/sensor/dev-abc-123/cmd/+(subscribe with wildcard)/acme/+/+/alerts(subscribe to all alerts across all device types)
Wildcards:
+: matches exactly one level#: matches all remaining levels (must be last)
CoAP semantics
Observe pattern
Server-side state: list of observers per resource. Each notification increments the Observe number.
Block-wise transfer
For payloads > MTU (~ 1100 bytes over Ethernet, less over LoRaWAN):
Request blocks 0, 1, 2, ... until M (more-blocks) flag is 0.
LwM2M object model
Standard objects (URN style: /object_id/instance_id/resource_id):
OMA LwM2M standardizes the IDs. Custom objects use object IDs ≥ 26241 (vendor range).
Firmware update flow
If anything fails, /5/0/5 (Update Result) is set to the appropriate code (1=success, 2=insufficient storage, 3=insufficient memory, 4=connection lost, 5=integrity check failure, 6=unsupported package type, 7=invalid URI, 8=firmware update failed, 9=unsupported protocol).
BLE GATT design
Service + characteristic tree
Standard services (use when possible — phones auto-recognize):
| UUID | Service | |
|---|---|---|
| 0x180A | Device Information | |
| 0x180F | Battery | |
| 0x180D | Heart Rate | |
| 0x1812 | HID | |
| 0x181C | User Data | |
| 0x181D | Weight Scale |
Connection parameter tuning
For power on the peripheral:
| Param | Low power | Low latency | |
|---|---|---|---|
| Min connection interval | 1000 ms | 7.5 ms | |
| Max connection interval | 2000 ms | 15 ms | |
| Slave latency | 4 | 0 | |
| Supervision timeout | 6000 ms | 1000 ms |
iOS overrides these. Aim for 30-50 ms connection interval if iOS support matters.
MTU negotiation
Default MTU: 23 bytes (20 bytes payload after ATT overhead).
Negotiated MTU: up to 247 (most stacks) or 517 (BLE 5.x).
Larger MTU = fewer fragments = lower latency for large transfers. Request MTU during connection setup.
LoRaWAN bandwidth planning
Air time table (EU 868 MHz, SF7-SF12)
For a 13-byte application payload (26 bytes on air after the 13-byte LoRaWAN header and MIC), 125 kHz, coding rate 4/5, 8-symbol preamble, low data rate optimization on at SF11 and SF12:
| SF | Time on air | Sensitivity | Range | |
|---|---|---|---|---|
| 7 | 62 ms | -123 dBm | ~2 km open field | |
| 8 | 113 ms | -126 dBm | ~3 km | |
| 9 | 206 ms | -129 dBm | ~5 km | |
| 10 | 412 ms | -132 dBm | ~7 km | |
| 11 | 823 ms | -134.5 dBm | ~10 km | |
| 12 | 1647 ms | -137 dBm | ~15 km |
EU 868 1% duty cycle allows 36 s of airtime per hour. At SF12 that is 36 / 1.647 s ≈ 21 uplinks per hour, at most one every ~163 seconds (99 × the airtime off after each uplink). ADR is essential.
Class trade-offs
| Class | Downlink latency | Power | Use case | |
|---|---|---|---|---|
| A | Up to next uplink | Lowest | Sensors, infrequent transmitters | |
| B | Up to beacon period (e.g., 128 s) | Medium | Scheduled control | |
| C | < 1 second | Highest | Actuators, always-on receive |
Common mistakes catalog
"MQTT client reconnects every few minutes"
NAT timeout. The router between the device and broker closes the TCP connection after idle period. Solutions:
- Reduce MQTT keep-alive below the NAT timeout (often 60s is safe)
- Use TCP keep-alive at OS level
"BLE device disconnects randomly"
Supervision timeout too short, or peer requesting incompatible connection params. Check:
- Supervision timeout ≥ (1 + slave_latency) × max_conn_interval × 4
- Peer (e.g., iOS) accepts your requested intervals
"LoRaWAN device works in lab, fails in field"
Lab probably had clear line of sight to gateway. Field has obstacles. ADR will adapt SF up but may not be enough; check signal margin and consider repositioning gateway.
"Device occasionally sends garbled payloads"
CRC isn't catching corruption. Check:
- Stack handles all framing errors (UART parity / CAN CRC / radio CRC)
- Payload is properly framed at application layer
- Endianness is consistent across MCU + cloud
"Cloud sees device as offline immediately after deploy"
LWT was published because graceful disconnect didn't happen. Common causes:
- Power glitch during firmware boot
- Bug in disconnect sequence
- Reset before MQTT graceful disconnect
"Battery drops to 80% on Day 1 then stable"
Lithium battery passivation layer. Not a real drain — the chemistry recovers. Expect this.
Code patterns
IoT protocol patterns for constrained MCUs and embedded Linux.
MQTT Topic Structure
Well-structured topic hierarchy enables flexible filtering and routing:
LWT (Last Will and Testament) configuration:
On connect, publish: device/{id}/status = {"online":true} retained.
Paho MQTT C Client (Linux/RTOS)
BLE Advertising (nRF52840, nRF Connect SDK)
This is the start of the file. Read the full SKILL.md on GitHub.
Security
- Security scanPassed, 90 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingplugins/iot-protocols/skills/iot-protocols/SKILL.md
Popularity
- 7-day trend score
- 0
Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/ormus-solutions/libreembed-claude-code/iot-protocols)