You are right. I just needed to be a little patient. After some waiting the sensors’ data got populated. But it is not very stable/consistent. All values report 0 very regularly and sometimes for several minutes and then they come back again. Do you see the same behaviour from your side?
My inverter is a hybrid since I have a battery. It would be great if I could have a sensor with the battery’s level and wether it’s charging or discharging. But I’m not knowledgeable with Node-Red. How could I tackle this and extract those values?
How often is your stick set to send data?
The default is 5 (or 6?) minutes but on the custom protocol you can set it to 1 minute
The node red setup I produced is set to “zero” some values after 3 minutes (assuming the sun has gone down and my inverter has turned off)
If yours is hybrid and sends data 24/7 you could delete that top node - it was basically working around that the last value my inverter may send is 20watts that would persist overnight until fresh readings the next day
When the readings show - you should be able to monitor via node-red - do they look “reasonable” values? Obviously, this is based on output from a 4g inverter - conscious the data order may be different from a hybrid.
Hi,
I deleted that top node but I still get a lot of 0 values. During these periods, my LAN-stick is unreachable. I guess it’s very unstable. I added an interval timer that checks the 0 values. If I have multiple within 15 minutes, those are probably real values and I update the sensor. If not, I just wait. It’s not great in terms of accuracy, but at least it looks better on the graphs.
Thank you very much for sharing your work here. I’m really happy not to be dependent on the cloud anymore.
Now I’m hoping someone more clever than me with a hybrid inverter will manage to add the battery information.
With the stick settings as in post 2 above, in node-red I see the connection (top left) change to “1 connection” every minute when the “request to send” part of the payload is sent, and then about 20 secs later it changes back to “0 connections” after the payload is sent (and the values on the right update)
A couple of caveats - if that connection isn’t going on and off in node-red at the rate you expect, try different settings at monitoring stick
Also, the check length node may need tweaking for the actual length of your “good” messages - I was finding occasional duff data (10000 amps) when non-standard messages were being parsed - hence the nodes at the bottom for time stamping and saving non-compliant messages - I ended up with 259 as my “good” message length and anything else classed as bad
I removed this first filter and now the sensors are nicely updated every minute. I’ll see tomorrow if this is consistent.
I’ve been looking for information about gathering data from my stick and stumbled across this post. Perhaps you can help - it’s unclear from your post if your stick is a LAN or WIFI one. I have a ginlong WIFI stick in my solis inverter. I don’t have any of those extra options on the config_hide page about acknowledgements or anything, which I think is key to it.
Even proxying the data and observing, it seems that something is not right as often the stick will give up trying (sending the data 3 times, or sometimes sending it 10-20 times). I watch the data going back and forth - the initial packet, the heartbeat, the full data packet, another heartbeat, and so on. Occasionally, a weird sized data packet appears, sometimes 60 characters, sometimes another size I forget.
While I can emulate the server’s responses and cut it out of the equation completely, the problem is not really the data format, it’s just the fact the stick behaves so randomly. Sometimes it will connect, and send absolutely no data at all! When it does work, however briefly, it will send data repeatedly for a short while.
I wonder if anyone has any advice. Perhaps switching to the LAN stick will be more reliable? Especially if I can get those extra config options.
Mine is a LAN stick - I “thought” the WiFi one was similar (depending on firmware version) except for the extra WiFi settings pages?
Hi,
I have the LAN stick and it’s totally unreliable. After some time, it just stops sending data. I have to pull the network cable and reconnect for it to come alive again. I was wondering if the wifi stick was any better, but apparently not. It’s already my second LAN stick (I believed the first one was broken since it showed the same behaviour).
The wifi stick doesn’t have that manual tab at all, there’s few settings on that page, and on the config_hide page you can basically override the server URL.
I have found web interface of stick locks up if the server B settings aren’t “compatible” (nothing listening etc) but even when that happened it was still sending data to ginlong website.
Only way to reset was to unplug stick from inverter (as that’s where it’s powered from) which gave a short window to access web interface and perform a factory reset.
Doesn’t work on mine, but might be worth trying the firmware upgrade
I alread pulled the stick from the inverter but it doesn’t change the behaviour. When it locks up, it also stops reporting to the cloud.
I would definitely suggest a factory reset via web interface if you haven’t already
Hey guys anyone have a way to easily identify what all the json data from the m.ginglong.com, it’s coming back like this:
_st: "1"
1af: "231.00"
1ag: "0.00"
1ah: "0.00"
1ai: "2.10"
1aj: "0.00"
1ak: "0.00"
1ao: "0"
1ar: "50.01"
1aw: "31.70"
ah: "18313"
2tm: "99"
ze: 2021-05-25T19:44:49.000Z
zf: "103643354"
zg: "FA,CA"
2tp: "0"
zh: "47.88.8.200:10000"
zi: "02"
ap: "0000"
aq: "0000"
zk: "1"
ar: "0000"
2tt: "52.10"
zl: "0"
as: "0000"
1bc: "663.00"
2tu: "10.10"
at: "0000"
1bd: "29.80"
1be: "676.8000000000003"
2tv: "100.00"
1ru: "0"
1bf: "676.8000000000003"
2tw: "100.00"
Anyone have a mapping of the values?
I would suggest capturing it for a few days and putting into a spreadsheet - you’ll then be able to see trends to help identify what’s what.
Eg values that fluctuate up and down, values that are static, values that only increase, values that reset between sundown and sunup etc.
That is how I identified the data in the server B output.
Checkout this project, I’ve been using it (albeit slightly modified to grab some extra values) to scrape the ginlong json data, there are some values already mapped but I took the extra mappings from the json data, there is a section in the json that maps those keys to something more useful.
This is fantastic - but you wouldn’t happen to stumble upon a solution for us WIFI-stick users?
I only have the following settings:
(the IP address is correct by the way)
and I have the following status:
I have setup the node-red flow and the entities are waiting to be fed.
Any help would be GREATLY appreciated!
I’d like to second this. Am stuck in the same boat, with a WIFI Stick setup. THanks for posting this
Hey @abinitio1980 , needless to say this is fantastic.
It did work for me - but only for a day or so? Maybe the stick upgraded their firmware or something, and now it send incompatible data? Who knows. My version right now is “ME-121001-V1.0.6(202006160928)”, don’t know what it was before.
It certainly appears that the data is incompatible; now it seems to send packets of 14 and 248 bytes length, so the flow ignores either.
So I wrote a program to receive data packets and a) log them to the console, b) write them to a file and c) retransmit them somewhere else (right now, the flow); mostly to log the data to file for further analysis. Also created a docker container for it for easier installation.
It seems to me a better coordination in decoding the data format is needed. It took me hours of Googling to find previous solutions (graham0’s and this one), and neither work for me anymore.
Maybe we should establish a proper documentation project, in order to maintain the offset/data field mapping in a more general form than python code or a node flow.
I’ll probably start one for what I find out about my current data; sadly I’m not really good at analysing this kind of binary data. If anyone feels like they can and want to contribute, let me know.
Hi @abinitio1980 I followed your “manual” and everything works fine. All sensors are showing in HA. THX.
The only regret is not being able to get the data in the new Energy tab. I’d guess that’s only for Integrations? It’s a shame, having the data but not able to enjoy the 2021.8 Energy update…
You need to adjust your nodes (eg. DailyGeneration) to contain the fields necessary for it to be recognized as “long term statistics” (Sensor Entity | Home Assistant Developer Docs).
I think the most important one is state_class: total_increasing
. I wasn’t entirely sure what fields are needed exactly, so I just added all of them (eg native_unit_of_measurement
and native_value
). You can leave out last_reset
, that’s calculated automatically when the value decreases for a total_increasing sensor.