dali/gateway
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Enhance Gateway Network and Runtime Functionality

Browse Source 
- Added a check in GatewayNetworkService::handleDaliRawFrame to ensure raw reporting is enabled for the gateway before processing the frame.
- Extended the JSON snapshot in GatewayNetworkService::gatewaySnapshotJson to include additional operation-related fields for each channel, providing more detailed status information.
- Updated GatewayRuntime::classifyCommandPriority to include new opcodes (0x66 and 0x67) in the control command classification, improving command handling.

Signed-off-by: Tony <tonylu@tony-cloud.com>
This commit is contained in:
Tony
2026-06-13 20:13:33 +08:00
parent 530f0ecf12
commit fc4e9016cf
8 changed files with 1269 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+54 -6
View File
@@ -51,12 +51,14 @@ broadcast targets are never queried for refresh.
Gateway feature opcode `0x06` keeps the Lua-compatible low-byte feature bits,
advertises cache support with bit `0x40`, advertises gateway/channel name
support with bit `0x80`, and advertises the native C++ gateway type with bit
`0x0100`. Gateway opcode `0x05` reads and writes user-facing gateway identity:
operation `0x00` reads the channel name, `0x01` writes the channel name,
`0x02` reads the physical gateway device name, and `0x03` writes the physical
gateway device name. Empty writes reset to the default name. Gateway opcode
`0x39` returns cache summary and target snapshots so frontend clients can read
cached state without issuing live DALI queries on supported gateways.
`0x0100`. Bit `0x0200` advertises the generic gateway operation protocol, and
bit `0x0400` advertises explicit raw-report leases. Gateway opcode `0x05` reads
and writes user-facing gateway identity: operation `0x00` reads the channel
name, `0x01` writes the channel name, `0x02` reads the physical gateway device
name, and `0x03` writes the physical gateway device name. Empty writes reset to
the default name. Gateway opcode `0x39` returns cache summary and target
snapshots so frontend clients can read cached state without issuing live DALI
queries on supported gateways.
Gateway opcode `0x09` with address/data `0x00/0x00` is a chip-level channel-id
report. It returns the enabled DALI channel ids so clients do not need to probe
@@ -73,6 +75,52 @@ channel number after the serial matches, so BLE/Wi-Fi configuration and DALI
send/query commands can target a channel even when its variable channel id is
unknown.
## Gateway operation protocol
Opcode `0x67` starts, aborts, and polls gateway-executed high-level DALI
operations. Clients send one compact gateway command and the controller runs the
required DTR setup, device-type select, query chain, retry, or address iteration
on the gateway. The command frame is:
- Start: `28 01 <gw> 67 01 <requestId> <operationIdLo> <operationIdHi> <payloadLenLo> <payloadLenHi> <TLV...> <checksum>`.
- Abort: `28 01 <gw> 67 02 <requestId> 00 00 00 00 <checksum>`.
- Status: `28 01 <gw> 67 03 <requestId> 00 00 00 00 <checksum>`.
Multi-byte fields are little-endian. TLV payload fields use
`{fieldId:u8, type:u8, len:u8, value...}`. Types are `0x01` u8, `0x02` u16,
`0x03` u32, `0x04` signed i32, `0x05` bool, and `0x06` byte list. Dynamic
snapshot metadata is returned as repeated byte-list entries using compact
`key=value` payloads.
Operation events are emitted as
`22 67 <gw> <requestId> <operationIdLo> <operationIdHi> <event> <status> <progress> <target> <count> <checksum>`.
Event values are accepted `0x00`, progress `0x01`, item result `0x02`,
completed `0x03`, aborted `0x04`, and error `0x05`. Status values are ok
`0x00`, busy `0x01`, invalid `0x02`, unsupported `0x03`, no response `0x04`,
failed `0x05`, and aborted `0x06`.
Large result payloads are emitted as chunks:
`22 68 <gw> <requestId> <operationIdLo> <operationIdHi> <total> <index> <chunkLen> <TLV...> <checksum>`.
Clients assemble chunks by gateway, request id, and operation id before
processing result TLVs.
The initial C++ executor accepts the shared `BridgeOperation` numeric ids for
raw send/query, brightness/on/off/recall, color-temperature and DT8 RGB/XY/RGBW
setters, DT1/DT4/DT5/DT6/DT8 snapshots, group masks, scene levels/maps, address
settings, short-address range search, and short-address allocation/reset/stop.
Unsupported ids return an `unsupported` operation error so old clients can fall
back to their app-side workflow. Legacy opcodes such as `0x12`, `0x13`, `0x14`,
`0x30`, `0x32`, `0x60`-`0x65`, and `0x39` remain available for compatibility.
Opcode `0x66` controls passive raw-report leases. Command
`28 01 <gw> 66 01 <enabled> <ttlLo> <ttlHi> <checksum>` enables or disables a
volatile per-gateway lease; `ttl=0` disables. The response is
`22 66 <gw> <status> <enabled> <ttlLo> <ttlHi> <checksum>`. Passive raw DALI
notifications over UDP, BLE raw characteristics, ESP-NOW setup UART mirroring,
and gateway notification opcodes `0x01` and `0x65` are suppressed unless the
lease is active. Direct command/query responses still work without a raw-report
lease.
## Current status
The native rewrite now wires a shared `gateway_core` bootstrap component, a multi-channel `dali_domain` wrapper over `dali_cpp`, a local vendored `dali` hardware backend from the LuatOS ESP-IDF port with raw receive fan-out, an initial `gateway_runtime` service that provides persistent settings, device info, Lua-compatible command framing helpers, and Lua-style query command deduplication, plus a `gateway_controller` service that starts the gateway command task, dispatches core Lua gateway opcodes, and owns internal scene/group state. The gateway app also includes a `gateway_ble` NimBLE bridge that advertises a Lua-compatible GATT service and forwards `FFF3` framed notifications, incoming `FFF1`/`FFF2`/`FFF3` writes, and native raw DALI frame notifications into the matching raw channel, a `gateway_network` service that provides the native HTTP `/info`, `GET`/`POST /dali/cmd`, `/led/1`, `/led/0`, `/jq.js`, UDP control-plane router on port `2020`, W5500 SPI Ethernet with DHCP, Wi-Fi STA lifecycle, ESP-Touch smartconfig credential provisioning, the Lua-style `LAMMIN_Gateway` setup AP on `192.168.3.1`, ESP-NOW setup ingress for Lua-compatible `connReq`/`connAck`/`echo`/`cmd`/`data`/`uart` packets, native raw DALI frame forwarding back to connected setup peers, setup AP GPIO entry, and optional Wi-Fi credential reset GPIO handling, and an optional `gateway_485_control` bridge that claims UART0 for Lua-compatible framed command ingress plus `0x22` notification egress when the console is moved off UART0. Startup behavior is configured in `main/Kconfig.projbuild`: BLE and wired Ethernet are enabled by default, W5500 initialization and startup probe failures are ignored by default for boards without populated Ethernet hardware by fully disabling Ethernet for that boot, Wi-Fi STA, smartconfig, and ESP-NOW setup mode are disabled by default, the built-in USB Serial/JTAG interface stays in debug mode unless the optional USB setup bridge mode is selected, and the UART0 control bridge stays disabled unless the deployment explicitly repurposes UART0 away from the ESP-IDF console. Runtime settings and internal scene/group data are cached in RAM after load, skip unchanged flash writes, and batch Wi-Fi credential commits to reduce flash stalls on ESP32-S3 boards where flash and PSRAM share the SPI bus. The gateway app exposes per-channel PHY selection through `main/Kconfig.projbuild`; each channel can be disabled, bound to the native DALI GPIO HAL, or bound to a UART1/UART2 serial PHY. The checked-in `sdkconfig` is aligned with the app's custom 16 MB partition table so the Wi-Fi/BLE/network-enabled image fits the OTA app slots.