diff --git a/docs/Zigbee.md b/docs/Zigbee.md
index d494f549af..ed538374c1 100644
--- a/docs/Zigbee.md
+++ b/docs/Zigbee.md
@@ -153,49 +153,6 @@ In this section, we'll give a quick overview of 2 devices:
 
 - [BlitzWolf SHP15 Power Monitoring Plug](https://zigbee.blakadder.com/BlitzWolf_BW-SHP15.html)
 
-## Definition File
-
-From the start, Z2T design was to stick to a low-level view and provide higher level (named) attributes only for a limited set of mostly seen attributes. This raised difficulties and frustration for users with specific devices that use rare attributes, or devices that use non-standard attributes (like Tuya zigbee devices).
-
-We are now providing a **Zigbee Device plugin** mechanisms, using simple text files. These files specify mapping on a per-device type basis. The goal is to fill most of the gap with Zigbee2MQTT (provided that you write the device plugin files). The lightweight nature of plugins permits to load only the plugins required by the devices used, and does not require a sowftare update for new devices.
-
-### How does it work?
-
-You simply copy device plugin files (externsion `*.zb`) in the file system and they are automatically loaded at start.
-
-You can dynamically load new files with `ZbLoad <file>.zb` or unload definitions with `ZbUnload <file>.zb`. When you reload a file with the same name, it is first unloaded.
-
-At Zigbee start, all files with `*.zb` suffix are loaded into memory. Be careful of not saturating memory, especially on ESP8266.
-
-### Zigbee device plugin format
-
-**Zigbee device plugin** have the following format:
-
-- starts with `#Z2Tv1` on the first line
-  - `#` is a marker for comments, and everything from `#` to end of line is ignored
-  - rest of the file is of form **device matcher** followed by **attribute definitions** or **attribute synonyms**
-
-#### **device matchers**
-
-- composed of one or more lines defining the `modelId` and `manufacturerId`. If a field is empty, it matches all values
-- `:<modelId>,<manufacturerId>`
-- example: `:TS0601,_TZE200_sh1btabb` for GiEX water valve
-
-#### **attribute matcher** specifies a cluster/attribute/type tuple and matches an attribute name
-
-- `<cluster 4 hex>/<attribute 4 hex>` or `<cluster 4 hex>/<attribute 4 hex>%<type 2 hex>`
-- Ex: `EF00/0365,IrrigationStartTime` (Tuya cluster EF00 does not need an explicit type)
-- Ex: `0006/4001%bool,OnTime`
-
-#### **attribute synonyms** specifies that a received attribute is a synonym for another attribute
-
-- `<cluster 4 hex>/<attribute 4 hex>=<new_cluster 4 hex>/<new_attribute 4 hex>,<multiplier>`
-- Ex: `EF00/026C=0001/0021,2` converts any EFOO/026C attribute received to `0001/0021` (BatteryPercentage) and multiplies by `2` to convert to ZCL standard.
-
-Multiplier is 8 bit int (-128..127). If `0` or `1`, the value is unchanged. Otherwise the value is converted to `float` and is multiplied by `multiplier` if positive, or divided by `-multiplier` if negative.
-
-I.e. `multiplier=10` means multiply by 10, `multiplier=-5` means divide by 5
-
 ### Sonoff SNZB-02 Sensor
 
 ![SHP15](_media/zigbee/SNZB-02.webp){width="150"}
@@ -909,8 +866,8 @@ MQT: stat/%topic%/RESULT = {"ZbLight":{"Kitchen_Light":{"Device":"0x5ADF","Light
 
 ## Specific Device Configuration
 
-If your device pairs successfully with Zigbee2Tasmota but doesn't report on standardised endpoints you will see messages similar to:
-`{"ZbReceived":{"0x099F":{"0500!00":"010000FF0000","LinkQuality":70}}}`
+If your device pairs successfully with Zigbee2Tasmota but doesn't report on standardised endpoints you will see messages similar to:  
+`{"ZbReceived":{"0x099F":{"0500!00":"010000FF0000","LinkQuality":70}}}`  
 `{"ZbReceived":{"0x7596":{"0006!01":"","LinkQuality":65}}}`
 
 In this case you will have to use rules or an external home automation solution to parse those messages. The following section will focus only on rules to utilize the device inside Tasmota ecosystem.