The Enecsys Gateway is a Zigbee gateway allowing communications between the Enecsys microinverters and their monitoring backend. The Enecsys company is unfortunately defunct since 2015 and their DNS domains have been taken over by a UK enecsys owner who created his own monitoring system on https://enecsys-monitoring.com/
The gateway contains a ETRX2-PA Zigbee module manufactured by Telegesis. More information about this module can be found in the page describing the Enecsys SMI-360-72 Inverter. This module is connected with an UART on the main MCU. The uart settings are 19200 8n1.
When the gateway boots and initializes its radio interfaces it starts to send broadcast frames every 15 seconds:
Some more beacons can be found in gateway-beacon.txt. Unfortunately the beacons are encrypted with an unknown Zigbee Network key. This key is likely preconfigured as it would make sense for such a closed-loop system. Trying to decrypt the messages using the typical Zigbee key used by the Home Automation Profile (0x5A 0x69 0x67 0x42 0x65 0x65 0x41 0x6C 0x6C 0x69 0x61 0x6E 0x63 0x65 0x30 0x39) does not work.
As for the inverter, when it boots it first sends out a standard Beacon Request Zigbee packet every 77 (sic!) seconds, see traffic inverter-beacon.txt:
After receiving an answer to the Beacon Request from the gateway the standard association process starts. This has been captured and is available in zigbee-inverter-connect.pcapng and inverter-associate.txt as a text dump. After the exchange of some data back and forth the gateway indicates that the inverter is connected by incrementing a counter on the LCD.
During the gateway bootup the following network traffic can be seen:
TCP port scan results for the gateway’s IPv4 address:
UDP port scan results for the gateway’s IPv4 address:
The default credentials for the web interface are admin/password. You can tell that the gateway is (c) 2009 as there is no way to change the admin password ;).
The following endpoints have been detected on the device:
| Endpoint | Description | Notes |
|---|---|---|
| / | Main user interface | |
| /index.htm | ” | |
| /debug.htm | Debug interface HTML layout | |
| /ajax.xml | Debug interface polling endpoint | |
| /mpfsupload | MPFS Image Upload |
The main user interface has basic settings like IP address and it can be used to set the remote monitoring server hostname and port. Apart from that NTP and proxy can be configured. Here is a screenshot of the main UI:
The debug interface allows us to see what messages the Zigbee Module UART sends to the main MCU. These appear to be raw decrypted contents of Zigbee frames from the inverters as well as some traffic generated by the Zigbee module firmware itself even when there are no inverters connected. Some of the layout of these messages has been reverse engineered in the section near the end of the document. There is also a status display about the Zigbee network and monitoring server connection. The interface itself looks like this:
The debug UI polls the /ajax.xml endpoint in the background in order to receive the data about the latest messages received from the Zigbee module. The endpoint returns the following XML:
The MPFS is an internal HTTP upload server enabled by default in the Microchip TCP/IP stack. This feature can be used to upload files into the internal flash and possibly even modify firmware. There has been at least one device where this is possible: https://vulners.com/talos/TALOS-2018-0511. In the case of our device this won’t be much use however as all of the Zigbee traffic encryption happens in the Zigbee module and the Microchip MCU is just a simple bridge which forwards the messages to the remote monitoring server.
A number of debug messages have been captured so far when the device and inverter were in various operational modes. Based on simple time correlation the messages sent out from the debug interface seem to be plaintexts for the traffic exchanged via Zigbee. Based on the knowledge gained the development of a parser for the messages has been started: enecsys-watch-zigbee.py. Here is an example set of messages together with their hexdumps:
All of the messages fall into two patterns:
| Message | Flavor | Contents | Checksum | Key-value pairs | Notes |
| WZ=qcE1dwCaxjQAAAZhIQEAAAAMClP1BfcFAJrGNEg=AE,S=2000011689 | WZ | qcE1dwCaxjQAAAZhIQEAAAAMClP1BfcFAJrGNEg= | AE | S=2000011689 | 2000011689 is the serial number of the Zigbee module inside the gateway |
| WS=9QX3BQCaxjQAAAbLIQEAAAAAFDADiAEAAgAAAAAAAAAYAY0AAwQF00 | WS | 9QX3BQCaxjQAAAbLIQEAAAAAFDADiAEAAgAAAAAAAAAYAY0AAwQF | 00 |
The first characters consitute what was named the “flavor” of a message. The flavor determines the syntax of the next parts as well as the message source. After the flavor come the messages contents (encoded with URL-safe base64), two hexadecimal digits which I assume is a checksum of some kind and after the comma key-value pairs. There was only one key-value pair seen so far and that is ‘S’ which contains the serial number of the Zigbee module contained within the gateway that is generating the message.
Based on many observations I have deduced that the WZ messages are generated by the gateway itself as they are present even when there are no inverters connected. The schema used to calculate what I assume to be the checksum has not been reverse-engineered yet. The meaning of the key-value pairs is obvious at this point. Further information is revealed after decoding the base64-encoded payloads. The structure inside is similar for both flavors and a number of common fields are used to encode the source of the message, type, etc. See below:
| Data | Description | Notes |
|---|---|---|
| a9 c1 35 77 00 9a c6 34 | EUI64 of the source | Bytes are inverted, gateway EUI64 is 34:c6:9a:00:77:35:c1:a9 |
| 00 00 07 51 | uptime | Unit is 500ms |
| 21 01 | type | |
| 00 00 00 0f | counter | Sequence number |
| 0a | content length | |
| 53 f5 05 f7 05 00 9a c6 34 48 | content |
Similar for a WS flavored message:
| Data | Description | Notes |
|---|---|---|
| f5 05 f7 05 00 9a c6 34 | EUI64 of the source | Bytes are inverted, inverter EUI64 is 34:c6:9a:00:05:f7:05:f5 |
| 00 00 06 cb | uptime | Unit is 500ms |
| 21 01 | type | |
| 00 00 00 00 | counter | Sequence number |
| 14 | content length | |
| 30 03 88 01 00 02 00 00 00 00 00 00 00 18 01 8d 00 03 04 05 | content |
Most of the interesting information is present in the ‘content’ section of every message, thus far the messages have been documented in the parser script mentioned above. To quickly summarize:
| Flavor | Type | Desciption | Example messages | Notes |
|---|---|---|---|---|
| WZ | 0x2100 | Bootup | WZ=qcE1dwCaxjQAAAAAIQAAAAAAA1BSAg==96,S=2000011689 | |
| WZ=qcE1dwCaxjQAAAAAIQAAAAABGU4SAGS13J5ge-wZ4QAAAAAAAAAAAAAAAAA=DF,S=2000011689 | ||||
| WZ | 0x2101 | Connectivity report | WZ=qcE1dwCaxjQAABDnIQEAAAASClOpwTV3AJrGNEg=9A,S=2000011689 | Sends the EUI64 of other Zigbee devices on the network |
| WZ=qcE1dwCaxjQAAAdRIQEAAAAPClP1BfcFAJrGNEg=60,S=2000011689 | ||||
| WS | 0x2100 | Bootup | WS=9QX3BQCaxjQAAAB4IQAAAAABPXIBAwX3BfVXU0ktMDAwMDMAAAAAAAAAADwAAAAAMDEtMDItMTIgMDI6MjH__wAAAAAAAAAAAAAAAAAAAAA=29 | |
| WS | 0x2101 | Power measurement | WS=9QX3BQCaxjQAAE4HIQEAAAARFDADiAMAAgAAAAAAAEUdAY4AAwAFE1 | Contains DC and AC power, AC frequency, efficiency as well as AC voltage (inverter idle) |
| WS | 0x2102 | Power measurement | WS=9QX3BQCaxjQAAAdYIQIAAAAAFDADiAEAAgAAAAAAAAAZAY0AAwAF81 | Contains DC and AC power, AC frequency, efficiency as well as AC voltage (inverter online) |
The 0x2101 and 0x2102 WS messages seem to contain identical data and look to be related to the state of the inverter itself. For example, the 0x2101 messages are sent always, even when the inverter is connected only to the DC side. However the exact difference is not clear at this point.
Based on a screenshot found for a gateway software that is being sold on eBay (https://www.ebay.com/itm/283656242209) it looks like there are additional items reported by the inverter which have not yet been located:
- serial number
- lifetime kWh
- DC amps
- temperature