Reverse engineering

[faanskit]

Thanks for the amazing work. I've been exploring the endpoints/scrips you provided and want to learn how they were found.
In particular I would like to find endpoints/scripts for collecting historical data.

The WiFi dongle should have at least the capability to store up to 3-days of data according to sales information. Therefore it would be interesting to know if you have additional endpoints/scripts that are yet to discover.

Also, I notice that port 1883 seems to be exposed. 1883 is normally for MQTT.

1.)
Can you please share any documentation you have?

2.)
Can you please share any reverse engineering insights you may have?

3.)
Do you know if there is an endpoint/script for historical data?

4.)
Do you have any insights on this WiFi dongle and MQTT?

BR, /M

[Fufs]

Hi,

This script is quite basic because I only had 2 weeks to play with this inverter and dongle. But to answer your questions:

1. All the documentation I have is in the wiki section. I'll try to add more to it next time I'll have access to it.

2. I started with a nmap port scan. I found 2 open ports, iirc, but 8484 was the one. It listens for http requests on that port. I then setup a proxy on my computer and connected my phone to it. Using Wireshark I sniffed http packets going between the dongle and my phone. That's how I was able to discover the endpoint scripts and necessary query strings. Rest is brute force - trying different values for the the query strings and seeing the response.

3. I haven't been able to find any of that in the app but maybe I haven't looked hard enough. Please give it a go, and tell me what you find.

4. To the best of my knowledge it doesn't have support MQTT, only REST API. I haven't seen any mention of MQTT while scrolling through the local mode of the app. I think the second port might be used for discovery in the app, but I don't quite remember what my finding where.

[faanskit]

Thanks,

If you give me access to the Wiki I can add some more information from my first analysis. I can help document what I've learned so far. I don't think the Wiki followed the fork. But, better I document in your Wiki.

I was not aware that the app communicated directly with the inverter, I just assumed it fetched data from the cloud. Interresting.
Next time I have access to the system I will have to run mitmproxy to see more what happens. Also I may be able to ask for additional permissions in the app for extra features. With some luck I may get installer privileges'.

The Solplanet app shows daily, monthly graphs of data. Hopefully it fetch it locally. Which app did you use? Solplanet?
Did your trace see how the app discovered the unit? mDNS or maybe got it from the Cloud?

My speculation on 1883 is that the inverter send data to the cloud using MQTT. Since this is same supplier as Zeversolar, it is likely so.

/M
ps. If you enable the discussion section in github we can move this thread there...

[Fufs]

I used the Aiswei app (before they switched to the Solplanet app around jan). To be able to communicate directly without the cloud, you need to go to the local mode (from the login screen). As for the fetching, I've only been able to retrieve current stats but you can easily log in a database or, the way I've done it, in home assistant.

[faanskit]

Bummer. Seems like the new app does not have a local mode. At least I could not find a local mode at the login screen.
I'll have to try to install the old version via APK then and poke around.

Reg. logging to database I fully understand, but my application is a bit different.

It's an ESP32 based application and I would want to write as seldom as possible to the Flash to ensure low MTBF. Currently, with SAJ Inverters, I write once per day which will give me many years MTBF. To replicate what I currently got from my SAJ Inverter, I would have to write every 10 minutes to the Flash which will dramatically increase MTBF.

Therefore I will try to see if I can get the data-set from the unit. I would want also to avoid picking data from their cloud application.

[faanskit]

I managed to install the old application and run a few more tests. Not soo much more discovered, only some more documented.
I also documented the API in OpenAPI format, it can be found on the wiki

The fdbg.cgi script is very interesting as looks like a Modbus bridge where you can both read and modify settings. If we can get hold of the Modbus specification there will be more to discover.

[Fufs]

I saw your changes. Nice work!

I have a couple of questions tho. I remember some stuff from my reverse engineering attempts and just want to make sure it's the same for you.

1. I don't think /getdev.cgi requires any query strings. If no device string is provided then it defaults to device=0
2. Could you check the JSON keys for getdev.cgi?device=0? That would be greatly appreciated!
3. Did you get solar data from /getdev.cgi? I thought you had to explicitly call /getdevdata.cgi cuz the regular getdev.cgi only returned some info about firmware and so.
4. Are you sure fac from getdevdata.cgi is the current final acceptance value and not just the frequency of the AC output? (50Hz in Europe, 60Hz in North America)
5. I think pac, qac and sac is real power, reactive power and complex (or more likely apperant) power of the AC output, where sac = pac + ȷ * qac or sac = sqrt(pac^2 + qac^2), depending of whether sac is complex or apparent (which is just the magnitude of the complex power vector). However, iirc, qac was always 0 in my setup.

Other than that, great job. The /fdbg.cgi script looks interesting (especially considering dbg might stand for debug?). I wonder if it could be useful in any way.

[faanskit]

1. I don't think /getdev.cgi requires any query strings. If no device string is provided then it defaults to device=0
2. Could you check the JSON keys for getdev.cgi?device=0? That would be greatly appreciated!

Correct, this parameter can be omitted and reports same as getdev.cgi?device=0

3. Did you get solar data from /getdev.cgi? I thought you had to explicitly call /getdevdata.cgi cuz the regular getdev.cgi only returned some info about firmware and so.

Yes, this is an example from my system (anonymized) for getdev.cgi/device=2.
As you can see, it contain pac, etd and eto.

pac represented the power reported in the app at the time of the test.
etd represented the energy produced today
eto represented the energy produced total.

The add parameter is also interesting. Multiple inverters can be connected to each other via Modbus (RS-485) and use a single WiFi donglein one of the inverters. The add parameter is reported in the AiSWEI app as Modbus address.

{
  "isn": "SP00100000000000",
  "add": 3,
  "rate": 12000,
  "msw": "V610-03043-05",
  "ssw": "V610-60009-00",
  "tsw": "V610-11009-02",
  "pac": 520,
  "etd": 0,
  "eto": 27,
  "err": 0,
  "cmv": "V2.1.2",
  "mty": 51
}

4. Are you sure fac from getdevdata.cgi is the current final acceptance value and not just the frequency of the AC output? (50Hz in Europe, 60Hz in North America)

No, I'm not sure about that. You are likely correct about this. My system keeps reporing values around 5000 (50Hz) consistently.

5. I think pac, qac and sac is real power, reactive power and complex (or more likely apperant) power of the AC output, where sac = pac + ȷ * qac or sac = sqrt(pac^2 + qac^2), depending of whether sac is complex or apparent (which is just the magnitude of the complex power vector). However, iirc, qac was always 0 in my setup.

Makes sense. Same here. pac and sac reports identical values in my setup and qac is always 0.

Other than that, great job. The /fdbg.cgi script looks interesting (especially considering dbg might stand for debug?). I wonder if it could be useful in any way.

In the AiSWEI app you can retrieve and change tons of parameters, where this command is being used.
Same parameters can be downloaded as a report in the Solplanet app, see below.

I'm pretty sure this is some form of a Modbus command/bridge. And, since they use POST for it they actually adhere to idempotency.
E.g.

I'll update/fix the wiki...

[Fufs]

Oh also, could you check if your device uses the V1.0 protocol? I believe it's under /getdev.cgi?device=0

[faanskit]

Yes, it's version 1.0. Content (anonymized) of /getdev.cgi?device=0 below:

{
   "psn":"XXX",
   "key":"XXX",
   "typ":5,
   "nam":"Wi-Fi Stick",
   "mod":"B32000-00",
   "muf":"AISWEI",
   "brd":"AISWEI",
   "hw":"M11",
   "sw":"20A12-013R",
   "wsw":"ESP32-WROOM-32U",
   "tim":"2023-03-21 07:41:56",
   "pdk":"XXX",
   "ser":"XXX",
   "protocol":"V1.0",
   "host":"eu-central-1",
   "port":1883,
   "status":0
}

[Fufs]

Ok, cool. Updated the wiki with new keys.

[pcbenclosure]

Hello! Thank you for the great work. Some conclusions about /fdbg.cgi. POST request to fdbg.cgi with "{"data":"0303145000018009" }" returns 0303020040c074. The query "0303145000018009" appears to be a set of hex codes without an "x" at the beginning. Thus, first byte 03 = x03, second 03 = x03, etc... In this case it looks like a standard request to a modbus server. According to the Aiswei (Solplanet) documentation, the format of the request to the inverter to read the holding register is function code: 0x03.
Decoding request (from faanskit picture attachmen), according to the Solplanet documentation, the result is as follows:
Read Holding Register (Function Code: 0x03):

Request: 03 03 14 50 00 01 80 09
Device ID 1 Byte 0x03 hex = 3dec Inverter modbus address
Function code 1 Byte 0x03hex = 3dec Read Holding Register
Register Address(Hi) 1 Byte 0x14 0x1450 = 5200dec. Register 5200 is the Grid Code of the inverter
Register Address(Lo) 1 Byte 0x50
Register length 2 Byte 0x00, 0x01
CRC(Lo) 1 Byte 0x80
CRC(Hi) 1 Byte 0x09

Response: 03 03 02 00 40 c0 74
Device ID 1 Byte 0x03 hex = 3dec Inverter modbus address
Function code 1 #Byte 0x03hex = 3dec Read Holding Register
Byte count 1 Byte 0x02 2Bytes
Data N × 1 Byte 0x00\0x40 = 64dec = EN 50549-1
CRC(Lo) 1 Byte
CRC(Hi) 1 Byte

As long as there is no error there is nothing to decode
Error：
Device ID 1 Byte
Function code + 0x80 1 Byte
Exception code 1 Byte
CRC(Lo) 1 Byte
CRC(Hi) 1 Byte

In summary, a request was sent to read register 5200 Grid Code and a response containing the type of Grid Code EN 50549-1 was received
Search Google for Grid Code EN 50549 return:
European Standard
Requirements for generating plants to be connected in parallel with distribution networks - Part 1: Connection to a LV distribution network - Generating plants up to and including Type B
From this I can conclude that this inverter is located in Europe.