Hi,
I have coded it with index 48. You can download a version from here:
Please give it a try and let me know if that’s what we need.
Cheers,
K.
1 Like
Hi,
Wow, thank you for this! I will give it a go for sure.
Meanwhile I tried getting a good set of raw data for several scenarios (feeding into grid, zero injection, pv producing and consuming from grid, pv not producing and consuming from grid).
I will analyse fields 48 and 49 on these scenarios. So far I believe field 48 is the good one (and enough), but want to be sure.
These days I have been swamped by work, so I’m getting a bit slow with this analysis.
Thank you,
Hugo
Hi, I now have new FW on my EV charger (1.13) and it seems that they opened the HTTP API as well for EV charging. I also googled the some people already accessed it, API description on GitHub - nazar-pc/solax-local-api-docs: Solax local API docs. Any possibility it as well in near future, otherwise I would probably just write rule to parse the file and update items manually…
Hi,
is it this one?
https://github.com/nazar-pc/solax-local-api-docs/blob/master/DataEvCharger.txt
We can implement it. I will need a real data from your system and some help to ensure that I have coded properly the channels (e.g. that the exact index return the proper values).
I have made it in a way so I can unit test the parsers which should ease a lot the overall process but I will need some help from you because I’m doing it in the dark. 
Cheers,
K.
Yes, I believe this should fit the API response. Guess it needs new “thing” for EV
This is the result:
curl -d "optType=ReadRealTimeData&pwd=xxxxxx" -X POST http://192.168.107.17
{"SN":"SQXXXXXXXX","ver":"3.004.11","type":1,"Data":[0,0,24354,24316,23945,0,0,0,0,0,0,0,0,0,302,0,101,35463,65455,0,3,0,64730,0,31,0,0,15,0,0,0,0,0,4992,4992,4988,4864,789,6150,1,0,0,0,0,0,0,0,0,1,100,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1836,775,6150,0,1,1,1,0,0,120,1205,1000,0,50,0,0,1,1,0],"Information":[11.000,1,"C3XXXXXXXXX",1,1.13,1.01,0.00,0.00,0.00,1],"OCPPServer":"","OCPPChargerId":""}
I just masked the sensitive data on Public forum. Seems devices starting with SQ* are EV chargers, with SR* inverters…
Ready to be test rabbit or guineapig 
Thank you. I’ll have a look when I have time. This weekend I’m travelling cross-country so will see if I can accommodate it.
As a start, it would be great if you could give me some important values / channels that make sense to be included from your perspective.
… or maybe all that are listed in the text file from this github repo?
P.S. The first post in this thread has been updated with the relevant work-in-progress branches, so you can check the progress there. As a start I added your raw data to a new test file which should be our starting validation point…
Hello,
I just tried to install the Binding via the Openhab Console and UI, but I can not find it!
OH-Version: 4.0.1
How can I install that binding?
Thanks!
Not 100% sure, but I believe it was introduced in 4.1 and the most recent (and most stable as well) version is in 4.2 milestones.
Thank you, I really appreciate the effort you are putting into this in your free time, so completely no stress…
I’m a “data freak” so I tend to collect (and store in influx) all available data if possible, but my take on the most important fields is:
DeviceState: Data[0],
DeviceMode: Data[1],
EQ_Single: Data[12] / 10, # kWh
EQ_Total: read32BitUnsigned(Data[14], Data[15]) / 10, # kWh
Total_ChargePower: Data[11],
Temp1_Plug: Data[23], # °C
Temp2_PCB: Data[24], # °C
CP_State: Data[26],
ChargingDuration: read32BitUnsigned(Data[80], Data[81]), # seconds
And if it would be possible to parse the data out of the response:
Type_power: Data[87],
Type_phase: Data[88],
For testing purposes I created a new “export” during operation (Eco mode, 6kWh).
{"SN":"SQXXXXXXXXXX","ver":"3.004.11","type":1,"Data":[2,2,23914,23991,23895,1517,1513,1519,3654,3657,3656,10968,44,0,346,0,65434,35463,65459,65508,65513,27,402,0,43,0,2,15,0,0,0,0,0,5004,5000,4996,10518,1547,6150,4,0,0,0,0,0,0,0,0,1,100,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1717,0,3114,1547,6150,0,1,1,1,0,0,121,584,266,0,50,0,0,1,1,0],"Information":[11.000,1,"CXXXXXXXXXX",1,1.13,1.01,0.00,0.00,0.00,1],"OCPPServer":"","OCPPChargerId":""}
Hi,
I started to look into the parser and I wanted to ask you if you have any idea about the possible translations for the channels of the different values. From what I see probably where we have A, B, C it’s the three phases. Do you know the meaning of the following channels? Could you propose a translations for them?
See some inline questions by me in italic next to the calculations.
I have no idea what these EQ values mean. kWh should be energy but for what?
EQ_Single: Data[12] / 10, # kWh
EQ_Total: read32BitUnsigned(Data[14], Data[15]) / 10, # kWh
Total_ChargePower: Data[11],
Is this the feed-in current/power from the electricity provider? (per phase and the last is total)
Extern_CurrentA: read16BitSigned(Data[16]) / 100,
Extern_CurrentB: read16BitSigned(Data[17]) / 100,
Extern_CurrentC: read16BitSigned(Data[18]) / 100,
Extern_PowerA: read16BitSigned(Data[19]),
Extern_PowerB: read16BitSigned(Data[20]),
Extern_PowerC: read16BitSigned(Data[21]),
Extern_TotalPower: read16BitSigned(Data[22]),
Some translation suggestions for these temperatures would be good. I guess the one is next to the EV plug and the other is the internal temperature of the charger (the PCB)
Temp1_Plug: Data[23], # °C
Temp2_PCB: Data[24], # °C
*What is this?!? *
CP_State: Data[26],
*What is this?!? *
OCPP_offline_mode: Data[85],
Any clue what this type is? I see below there are certain tresholds in the parser. Can you check if these change when you switch from Eco to some other modes?
Type_power: Data[87],
Type_phase: Data[88],
Type_charger: Data[89],
I used as a source the link I pasted above. Will continue without any particular names but would be good if we can define them so I can use the same (or similar) names in the code. Wherever possible we should reuse the channel names from the inverters.
I have now finally got my new network dongle, the V4 model with both wifi and LAN. I’d just like to report that it works like a charm out of the box with this binding, thanks for good work! I get values out of all the channels I have tested so far. Anything special that would be worth testing?
1 Like
@Vaclav_Provaznik I have coded most of the stuff and would greatly appreciate some feedback about the channels naming as per my previous post.
Please let me know if you could accomodate this as I don’t want to refactor them later too much…
Hi Konstantin,
thanks a lot, sorry, I somehow missed the previous post.
Let me try to comment my best guess, but I am not sure, so if at some point of time there would be “alpha” version, I could test it and compare data with “native” app:
EQ_Single: Data[12] / 10, # kWh - I think this is energy that has been charged in current charging session
EQ_Total: read32BitUnsigned(Data[14], Data[15]) / 10, # kWh - - I think this is energy that has been charged in all charging sessions
Total_ChargePower: Data[11] - I think this is the Power towards the car
Is this the feed-in current/power from the electricity provider? (per phase and the last is total) I think you are right, but I am not sure if this is related to electricity provider or external side of the charger. The charger seems to be able to be configured to read external meter either from network or from invertor
Extern_CurrentA: read16BitSigned(Data[16]) / 100,
Extern_CurrentB: read16BitSigned(Data[17]) / 100,
Extern_CurrentC: read16BitSigned(Data[18]) / 100,
Extern_PowerA: read16BitSigned(Data[19]),
Extern_PowerB: read16BitSigned(Data[20]),
Extern_PowerC: read16BitSigned(Data[21]),
Extern_TotalPower: read16BitSigned(Data[22]),
Some translation suggestions for these temperatures would be good. I guess the one is next to the EV plug and the other is the internal temperature of the charger (the PCB) I would think the same
Temp1_Plug: Data[23], # °C
Temp2_PCB: Data[24], # °C
*What is this?!? *
CP_State: Data[26], Not sure, the original text says “Advanced settings unavailable when set to 1 or 2”, but I think this can also be "Chargin point state which according to manual can be IDLE, STOP, CHARGE, FULL, FAULT and REMOTE UPGRADE
*What is this?!? *
OCPP_offline_mode: Data[85], **I would think this is flag wather the OCCP server is offline - I believe OCCP allows the charging station to be part of broader network managed by the OCCP server"
Any clue what this type is? I see below there are certain tresholds in the parser. Can you check if these change when you switch from Eco to some other modes?
Type_power: Data[87],
Type_phase: Data[88],
Type_charger: Data[89],
I found following:
Type_power apparently defines power levels for ECO charging:
1: [
** {text: “Level 1 6A”, code: 6},**
** {text: “Level 2 10A”, code: 10}**
]
else: [
** {text: “Level 1 6A”, code: 6},**
** {text: “Level 2 10A”, code: 10},**
** {text: “Level 3 16A”, code: 16},**
** {text: “Level 4 20A”, code: 20},**
** {text: “Level 5 25A”, code: 25}**
]
Type_phase:
0: Three-phase
Type_charger and OCPP_offline_mode are related somehow:
if Type_charger == 0 || (Type_charger == 1 && OCPP_offline_mode == 0)
render settings
else
nothing
Not sure if it helped
Hi guys,
probably a noob problem. Sorry for posting.
I have a X3HybridG4 ->type 14. Most data I am receiving fine → the binding works ok.
But I can’t get the battery-state-of-charge in formation. In my openhab interface I get:
(unknown)lock_fill
Invalid Link
solax:local-connect-inverter:localInverter:battery-state-of-charge
I use the item from the example:
Number solaxBatterySoc "Battery SoC [%.0f %%]" <batterylevel> (gsolax_inverter,EveryChangePersist) { channel="solax:local-connect-inverter:localInverter:battery-state-of-charge" }
Has the channel name changed? Or anything obviously wrong?
Yours,
J
just figured is out. It is now called battery-level.
Maybe someone wants to update the official documentation?
Cheers
1 Like
Why don’t you do yourself ? There’s a link at the bottom of each docs page.
Actually the documentation is OK but I just figured that the example is wrong.
Would appreciate if you could update it. If not, I will do so in the next feature that I work now - the EV charger.
P.S. Just checked it and it looks OK in the code’s readme…
Hi again,
I would need to make a fork on GitHub. I think this is not useful…
I can’t edit Solax - Bindings | openHAB otherwise.
Sorry,
J
Hopefully very soon. Problem is I’m very busy at work and also at home lately but I’m working with a slow pace on the implementation
I appreciate and I am grateful, no stres… just wanted to say that alpha-testing may lead to better understanding/naming what different data means.