Skip to content

Commit 3417002

Browse files
NerivecKoenkk
andauthored
fix: add docs for new Z2M API endpoints (#4457)
Co-authored-by: Koen Kanters <[email protected]>
1 parent 37f97e4 commit 3417002

File tree

3 files changed

+86
-1
lines changed

3 files changed

+86
-1
lines changed

docgen/device_page_notes.ts

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -34,6 +34,26 @@ Verification: [GitHub PR Comment](https://github.com/Koenkk/zigbee2mqtt.io/pull/
3434
### Touchlink factory reset
3535
See [Touchlink](../guide/usage/touchlink.md)
3636
37+
### Touchlink reset by serial numbers
38+
39+
Using the dedicated action allows to reset Philips Hue devices via the serial number written on the device.
40+
This can be done by going to the Zigbee2QMQTT frontend -> Touchlink -> Philips Hue reset.
41+
42+
Alternatively, you can also use MQTT directly, topic: \`zigbee2mqtt/bridge/request/action\` payload:
43+
44+
\`\`\`json
45+
{
46+
"action": "philips_hue_factory_reset",
47+
"params": {
48+
"serial_numbers": ["3A745C", "806C52"],
49+
"extended_pan_id": "0xa1b2c3d4e5f60123"
50+
}
51+
}
52+
\`\`\`
53+
54+
- \`serial_numbers\`: The "Serial No." of the device(s) to reset (enter exactly as what is printed on the device).
55+
- \`extended_pan_id\`: (Optional) The extended PAN ID of the network the device(s) should try to join after reset. If not provided, the current network's extended PAN ID will be used.
56+
3757
### Hue bridge
3858
When the light is still connected to the Hue bridge, you can simply factory reset the light
3959
by removing it from the bridge via the Hue app. Orphaned lights (configured to connect to a non-existing Zigbee network) can be adopted by a Hue bridge by entering the 6 character serial number in the Philips Hue app.

docs/guide/usage/binding.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -56,6 +56,18 @@ To do this execute the following steps:
5656
3. Bind the remote to the group by sending the following MQTT message.
5757
- `zigbee2mqtt/bridge/request/device/bind` with payload `{"from": "my_remote", "to": "my_group"}`
5858

59+
### Clearing bindings
60+
61+
Using `zigbee2mqtt/bridge/request/device/binds/clear`, bindings can be all or selectively cleared.
62+
63+
To clear all bindings, just send the topic with the payload e.g. `{"target": "my_device"}`.
64+
65+
To selectively clear bindings by IEEE address, send the topic with the payload e.g. `{"target": "my_deivce", "ieee_list": ["0xa1a2a3a4a5a6a7a8", "0xb1b2b3b4b5b6b7b8"]}`.
66+
67+
::: tip
68+
Clearing bindings will automatically adjust the cached data that Zigbee2MQTT uses internally based on the request/response. After successfully executing this requests, bindings in Zigbee2MQTT should reflect actual bindings on the device.
69+
:::
70+
5971
## Devices
6072

6173
Not all devices support this, it basically comes down to the Zigbee implementation of the device itself. Check the device specific page for more info (can be reached via the supported devices page)

docs/guide/usage/mqtt_topics_and_messages.md

Lines changed: 54 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -542,7 +542,13 @@ See [Binding](./binding.md).
542542
543543
See [Binding](./binding.md).
544544
545-
#### zigbee2mqtt/bridge/request/device/configure_reporting
545+
#### zigbee2mqtt/bridge/request/device/binds/clear
546+
547+
See [Binding](./binding.md).
548+
549+
#### zigbee2mqtt/bridge/request/device/reporting/configure
550+
551+
_Alias: `zigbee2mqtt/bridge/request/device/configure_reporting` (deprecated)_
546552
547553
Allows to send a Zigbee configure reporting command to a device. Zigbee devices often have attributes that can report changes in their state, such as temperature, humidity, battery level, etc. Attribute reporting allows these devices to automatically send updates when there is a change in the values of these attributes.
548554
One example is when you change brightness of a bulb with its remote instead of Zigbee2MQTT, the state becomes out of sync.
@@ -567,6 +573,10 @@ The Minimum Reporting Change is like telling your device to speak up only when s
567573
If you set a minimum reporting change of 1 degree for a temperature sensor, it means the sensor won't bother you with updates unless the temperature changes by at least 1 degree.
568574
It's a way to filter out minor fluctuations and focus on important changes in the environment.
569575
576+
::: tip NOTE
577+
Support for `reportable_change` depends on the type of the attribute. For e.g. a `measure`-type attribute would likely support it, but a `enum`-type attribute would not. If supplied and not supported, it is ignored.
578+
:::
579+
570580
To disable reporting set the `maximum_report_interval` to `65535`.
571581
572582
Notes:
@@ -576,6 +586,21 @@ Notes:
576586
- The `reportable_change` value depends on the unit of the attribute, e.g. for temperature 100 means in general 1°C of change.
577587
- To specify options, e.g. the manufacturerCode use e.g. `{"id":"my_bulb","cluster":"genLevelCtrl","attribute":"currentLevel","minimum_report_interval":5,"maximum_report_interval":10,"reportable_change":10,"options":{"manufacturerCode":1234}}`
578588
589+
#### zigbee2mqtt/bridge/request/device/reporting/read
590+
591+
Allows to read the reporting configuration registered on a device.
592+
Attributes must of course be reportable, an error status will be returned for any attribute in the request that is not.
593+
594+
Example payloads:
595+
596+
- For one attribute: `{"id":"my_bulb","endpoint":1,"cluster":"genLevelCtrl","configs":[{"attribute":"currentLevel"}]}`
597+
- For multiple attributes: `{"id":"my_bulb","endpoint":1,"cluster":"genLevelCtrl","configs":[{"attribute":"currentLevel"},{"attribute":"currentFrequency"}]}`
598+
- For manufacturer-specific attribute: `{"id":"my_bulb","endpoint":1,"cluster":"genLevelCtrl","configs":[{"attribute":"currentLevel"}], "manufacturer_code": 0x1234}`
599+
600+
::: tip
601+
Reading reporting config will automatically adjust the cached data that Zigbee2MQTT uses internally based on the request/response. After successfully executing this requests, reporting config in Zigbee2MQTT should reflect the actual reporting config on the device.
602+
:::
603+
579604
### Group
580605
581606
#### zigbee2mqtt/bridge/request/group/remove
@@ -629,3 +654,31 @@ See [Touchlink](./touchlink.md).
629654
#### zigbee2mqtt/bridge/request/touchlink/identify
630655
631656
See [Touchlink](./touchlink.md).
657+
658+
### Action
659+
660+
#### zigbee2mqtt/bridge/request/action
661+
662+
Allows to call specific pre-defined actions, usually manufacturer-specific.
663+
All action names are published in `zigbee2mqtt/bridge/definitions` under `actions`.
664+
665+
The payload for this topic takes the following form (refer to specific actions docs for what `params` should contain):
666+
667+
`{"action":"<action_name>","params":{/* action-specific parameters here */}}`
668+
669+
E.g.:
670+
671+
`{"action":"just_an_example","params":{"abcd": 1, "zyx": "my_device"}}`
672+
673+
::: tip
674+
Specific up-to-date actions/parameters can be observed directly in the source code [https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/converters/actions.ts](https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/converters/actions.ts)
675+
:::
676+
677+
##### Action: `raw`
678+
679+
::: warning
680+
This allows sending requests that could negatively impact or even break your network. Use with caution!
681+
:::
682+
683+
Special action that allows to send entirely custom payloads. The given payload is analyzed to chose the proper method of sending (ZCL, ZDO, etc.).
684+
See link above for parameters details (beyond the scope of this documentation).

0 commit comments

Comments
 (0)