Skill

domain-iot:protocol-advisor

IoT communication protocol selection and advisory covering MQTT, CoAP, AMQP, HTTP comparison, wireless technologies (Zigbee, Z-Wave, BLE, LoRaWAN, NB-IoT, LTE-M), and protocol bridging patterns for heterogeneous IoT deployments.

Install

npx claudepluginhub rnavarych/alpha-engineer --plugin domain-iot

Tool Access

This skill is limited to using the following tools:

ReadGrepGlobBash

Preview

- Choosing between MQTT, CoAP, AMQP, and HTTP for device communication

Supporting Assets

references/application-layer-protocols.mdreferences/protocol-bridging.mdreferences/wireless-technologies.md

SKILL.md

Similar Skills

skill-lookup

Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.

prompts.chat

157.6k

prompt-lookup

Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.

prompts.chat

157.6k

agent-harness-construction

Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.

everything-claude-code

156.2k

Stats

Parent Repo Stars9

Parent Repo Forks0

Last CommitMar 3, 2026

Actions

View Source View Plugin View on GitHub View README

When to use

Choosing between MQTT, CoAP, AMQP, and HTTP for device communication

Selecting a wireless technology based on range, power, and data rate requirements

Designing a multi-protocol gateway that bridges device-side and cloud-side protocols

Evaluating BLE, Zigbee, Z-Wave, Wi-Fi, LoRaWAN, NB-IoT, or LTE-M for a specific deployment

Building a canonical data model at the gateway boundary for heterogeneous device types

Core principles

Match protocol to the constraint profile — CoAP for 10KB RAM devices, MQTT for everything above that, HTTP only for infrequent config calls

Wireless range and power are the first filter — pick the frequency band before picking the stack; LoRaWAN for kilometers at microwatts, BLE for meters at microwatts

Translate once at the gateway boundary — device speaks Modbus or Zigbee, cloud speaks MQTT; the gateway is the only place that knows both

One cloud identity per gateway, not per device — device authentication stays local; a single gateway credential reduces cloud certificate management overhead dramatically

Buffer at the gateway during outages — the bridge must absorb disconnections; cloud-side consumers should never know the link went down

Reference Files

references/application-layer-protocols.md — MQTT, CoAP, AMQP, HTTP detailed comparison with selection decision matrix across RAM, power, delivery, throughput, and ecosystem maturity

references/wireless-technologies.md — BLE, Zigbee, Z-Wave, Wi-Fi, LoRaWAN, NB-IoT, LTE-M with range/power/data-rate specs and best-fit scenarios

references/protocol-bridging.md — bridge architecture diagrams, gateway design considerations, multi-protocol edge platforms (Eclipse Kura, EdgeX Foundry, Node-RED, Greengrass)

IoT Protocol Advisor

When to use

Choosing between MQTT, CoAP, AMQP, and HTTP for device communication
Selecting a wireless technology based on range, power, and data rate requirements
Designing a multi-protocol gateway that bridges device-side and cloud-side protocols
Evaluating BLE, Zigbee, Z-Wave, Wi-Fi, LoRaWAN, NB-IoT, or LTE-M for a specific deployment
Building a canonical data model at the gateway boundary for heterogeneous device types

Core principles

Match protocol to the constraint profile — CoAP for 10KB RAM devices, MQTT for everything above that, HTTP only for infrequent config calls
Wireless range and power are the first filter — pick the frequency band before picking the stack; LoRaWAN for kilometers at microwatts, BLE for meters at microwatts
Translate once at the gateway boundary — device speaks Modbus or Zigbee, cloud speaks MQTT; the gateway is the only place that knows both
One cloud identity per gateway, not per device — device authentication stays local; a single gateway credential reduces cloud certificate management overhead dramatically
Buffer at the gateway during outages — the bridge must absorb disconnections; cloud-side consumers should never know the link went down

Reference Files

references/application-layer-protocols.md — MQTT, CoAP, AMQP, HTTP detailed comparison with selection decision matrix across RAM, power, delivery, throughput, and ecosystem maturity
references/wireless-technologies.md — BLE, Zigbee, Z-Wave, Wi-Fi, LoRaWAN, NB-IoT, LTE-M with range/power/data-rate specs and best-fit scenarios
references/protocol-bridging.md — bridge architecture diagrams, gateway design considerations, multi-protocol edge platforms (Eclipse Kura, EdgeX Foundry, Node-RED, Greengrass)