LCHCS log download timing out, SSH credentials?

[coma24]

My LCHCS web interface works fine, I have it connected to my 2.4GHz wifi (not the 5Ghz wifi). I can see the serial number, limited charging stats, and even use the ping tool. What I CANNOT do, though, is download the logs. I'm using the devtools in the browser and it appears that when you first go to the maintenance page, it asynchronously requests 'compresslog.cgi'. Based on the underlying javascript code, this function should return the filename of the compressed log. Unfortunately, the HTTP request times out after 60 secs (a timeout value in the web server on the charger...I've tried it with CURL after spoofing the session cookie and other headers with a 3 minute timeout for the client and it still fails after 60 secs).

It appears there is 1) an ENGINEERING mode (requires engineering password) which might be of use, and 2) You can ssh to the charger (it's running sshd on port 22), but I don't have any credentials to login.

I've REBOOTED the charger and the logs still timeout. I've even FACTORY RESET (requiring me to reconfigure the whole charger to reconnect to my SSID) with no luck....the 'total energy delivered' stat is still there, which means it's not fully erasing all the data.

Any ideas for how to pull the logs which are apparently now so bloated, they can't be gzipped or zipped inside of 60 secs? Or, anyone know the Engineering passwd or SSH credentials?

 

[coma24]

@borski if your LCHCS web interface is working 100%, can you go into browser dev tools and check what is returned by the compresslog.cgi fetch? I suspect it's the filename of the compressed log. I'm trying to determine the format of that path, and to see if it's static or dynamic. If it's static, then I might be able to fetch the compressed file myself, depending on the mechanism which is creating it.

 

[coma24]

Failing that, can anyone who DOES have a a working web interface go to the maintenance page, press F12 in their browser, go to the Network tab, then refresh the page? You'll see 'compresslog.cgi' as one of the requests. Wait for it to go from "(pending)" to being complete, then click on it and visit the RESPONSE tab to see what came back from that request. If you can post the filename that's returned, I'm trying to determine if the resulting compressed file has the same name everytime, or whether it's entirely dynamic, or static with a timestamp, perhaps.

Example:

 

[L-Dude]

Even though I can’t understand any of this, I find it to be a fascinating read. Carry on, gentlemen.

 

[coma24]

Even though I can’t understand any of this, I find it to be a fascinating read. Carry on, gentlemen.

Apologies, my posts were aimed fairly and squarely at those with technical backgrounds.

Here's a summary that should help. The LCHCS is a small computer running Linux. It has a web server and some supporting scripts which provide the web interface that you see, containing the serial number, model number, firmware versions, charging history etc.

The computer maintains a set of log files with all sorts of details about charging sessions and what it's doing. Those log files are, presumably, fairly large (keep that in mind for later).

When you visit the maintenance page in the interface, it doesn't present everything all at once. Instead, a skeleton page with headings/titles is returned. The browser then makes background requests to a number of scripts which eventually return data which is used to populate bits and pieces on the screen...this is why there is a delay between when you first visit the maintenance page and when the meaningful data is actually shown to you.

Examples of those scripts are:
- serialnum.cgi (returns the serial number of the unit)
- getsysteminfo.cgi (returns firmware and safety version numbers, among other things).
- compresslog.cgi (this is the one that isn't working for me...what it normally returns is the filename of the compressed logfile that it just created so that the 'download log' button knows WHAT to download.

My issue is that 'compresslog' is taking too long to run. The web server on the LCHCS is giving up after 60 secs, which means the browser is never given the filename of the compressed log file, which ultimately means, I can't download the log files that I need from my charger to help Lucid debug the "19kw -> 8kw" throttling issue that many people are seeing with the Air.

 

[coma24]

@borski if your LCHCS web interface is working 100%, can you go into browser dev tools and check what is returned by the compresslog.cgi fetch? I suspect it's the filename of the compressed log. I'm trying to determine the format of that path, and to see if it's static or dynamic. If it's static, then I might be able to fetch the compressed file myself, depending on the mechanism which is creating it.

*clicking heels 3 times* Borski?

 

[coupedncal]

I have looked up the IP address of my Air from my wifi router device list. The address is not pingable from a locally connected laptop nor is it listening on port 80 or 443 (not reachable from a browser). How was it someone here was able to reach a landing page?

 

[coma24]

I have looked up the IP address of my Air from my wifi router device list. The address is not pingable from a locally connected laptop nor is it listening on port 80 or 443 (not reachable from a browser). How was it someone here was able to reach a landing page?

The charger, not the car itself.

 

[tonybot]

Will check this out tomorrow and let you know. I did try to download the logs the other day but it didn’t work. I didn’t troubleshoot further though.

 

[coupedncal]

The charger, not the car itself.

Ahh. Thank you for clarifying. I misread this threads as someone was able to connect into the car to download logs etc. I have a Tesla wall charger and that combined with charging data we get from the Air app is sufficient for my needs. But getting into the car to download statistics and logs would be whole lot more interesting to me. Imagine if the car logs showed the correlation of proximity of phone key and the unlock getting executed. The use cases for the car logs are endless for us geeks.

 

[msaunders9430]

Failing that, can anyone who DOES have a a working web interface go to the maintenance page, press F12 in their browser, go to the Network tab, then refresh the page? You'll see 'compresslog.cgi' as one of the requests. Wait for it to go from "(pending)" to being complete, then click on it and visit the RESPONSE tab to see what came back from that request. If you can post the filename that's returned, I'm trying to determine if the resulting compressed file has the same name everytime, or whether it's entirely dynamic, or static with a timestamp, perhaps.

Example:
View attachment 33503

Did you ever solve the issue of downloading charger logs?

Below is the information I see based on what you requested.