How do I retrieve charging station logs with Get Diagnostics?

What is Get Diagnostics?

Get Diagnostics is an OCPP command that tells a charging station to package up its internal log files and upload them to a destination you choose. These logs are written by the charging station's own firmware, so they often hold far more detail than the OCPP messages you can already see in Monta, which makes them valuable when you're investigating a hardware fault, a failed session, or building evidence for a warranty claim or manufacturer support request.

Monta Control lets you send this command remotely, so you don't need to be on-site. Depending on the charging station's OCPP version and capabilities, Monta sends one of:

• OCPP 1.6: GetDiagnostics (standard logs) or GetLog (extended diagnostics and security logs, via the OCA security extensions)
• OCPP 2.0.1: GetLog

Before you start

1. Check that your charging station supports Get Diagnostics. Support is hardware-specific: it varies by brand, model, and firmware version, and some models do not support it at all. Many charging stations advertise which transfer protocols they accept via the OCPP SupportedFileTransferProtocols configuration key; if your model reports it, use one of the listed protocols. If you're unsure, check with the manufacturer.
2. Have an upload destination ready: a URL the charging station can reach and write to. See Using a third-party server or Setting up your own server below.
3. Make sure the charging station is online. Get Diagnostics only works while the station is connected; the request is rejected for offline stations.

How to use Get Diagnostics in Monta Control

1. In Monta Control, go to Charging Stations in the sidebar.
2. Search for the station by name or identity and click it to open its detail view.
3. Open the Actions menu and select Get Diagnostics.
4. In the dialog, fill in:
   • Diagnostics Type sets what to retrieve:
     • Standard: the standard diagnostics log (OCPP 1.6 GetDiagnostics). Start here unless you have a specific reason not to.
     • Diagnostics: extended diagnostics log (uses GetLog; requires security-extension or OCPP 2.0.1 support on the station).
     • Security Log: the station's security event log (also uses GetLog).
   • Upload Location (required): the full URL where the station should upload the file (for example ftps://user:password@logs.example.com/diagnostics/ or https://logs.example.com/upload). Monta validates that this is a well-formed URL. See Tips for the Upload Location URL below.
   • Start Date/Time (optional): the oldest logs to include. Leave empty to include all available logs.
   • Stop Date/Time (optional): the latest logs to include. Leave empty to include logs up to now.
5. Click Send.

What happens next

• The charging station acknowledges the request. If it accepts, Monta shows a confirmation, usually including the filename the station will upload (for example diag-20260311T100000.zip).
• The charging station collects and packages its logs, then uploads the file to your Upload Location.
• As it works, the station reports progress through DiagnosticsStatusNotification messages: Idle → Uploading → Uploaded (or UploadFailed). You can monitor these in the OCPP Logs tab in Monta Control.
• Once the upload succeeds, retrieve and open the file from your own server, since it lands on the destination you provided, not in Monta. See Retrieving the file with an FTP client below.

Using a third-party server

If you don't want to run your own server, several hosted file-transfer services can act as the upload destination. These are quick to set up, and a server that's already on the public internet sidesteps the home or office network problems described in the next section. But you take on the security and data-handling responsibility for whatever you point a charging station at.

Free / temporary (good for a one-off test)

• SFTPCloud free FTP server (sftpcloud.io/tools/free-ftp-server) spins up a temporary FTPS/SFTP server for a short period (around 60 minutes). Useful for a quick test using its FTPS endpoint. Treat anything you upload to a free, unauthenticated temporary server as potentially public, and use it only for a throwaway test, never for real diagnostic data.

Managed / paid (for ongoing use)

Examples of managed file-transfer services that offer FTPS and/or HTTPS endpoints include SFTPCloud (paid plans, the same provider as the free tool above), SFTP To Go, Files.com, DriveHQ, Couchdrop, and the cloud providers' own managed offerings (for example AWS Transfer Family and Azure Blob Storage's FTPS support).

Setting up your own server

Running the destination yourself is the most secure option, because you control exactly who can reach it and what happens to the data. On Linux, vsftpd is well suited to this; on Windows, FileZilla Server is a common choice. Rather than a step-by-step recipe (which varies by distribution and version), here are the principles to follow. Consult the official vsftpd documentation or your chosen server's docs for the exact configuration.

Security principles

• Use a dedicated account with a strong, unique password, locked (chrooted/jailed) to a single upload directory and nothing else. Never use a real admin login.
• Prefer FTPS (FTP over TLS) or HTTPS so credentials and data are encrypted in transit. Avoid plain FTP/HTTP unless the server is only reachable over a private network.
• Restrict inbound access with a firewall, ideally allowing only the IP ranges your charging stations use.
• Remember the file can contain sensitive operational data: store it securely and delete it once you've finished your investigation.

Reaching the server from the charging station

• You'll usually need port forwarding. Charging stations typically sit on mobile/4G or a separate network and reach your server over the public internet, so your router/firewall must forward the relevant ports to the machine running the server: for FTP/FTPS, both the control port and the passive-mode data port range; for HTTP/HTTPS, the web port.
• FTP behind NAT is fiddly. FTP's passive-data ports often do not pass cleanly through home or office NAT routers, which is a common reason uploads silently fail. If you cannot get a self-hosted FTP server working, a hosted service (previous section) is often the path of least resistance.
• Best option of all: keep the server off the public internet. If your server sits in the same VPN or private network as your charging stations, the station can reach it without any public exposure, and you can skip port forwarding entirely. This is by far the safest setup. Point the Upload Location at the server's private address.

Retrieving the file with an FTP client

The diagnostic file lands on your server, not in Monta, so you need a way to connect to that server, create the folder you point the station at, and download the file once it arrives. FileZilla is a free file-transfer client that works for this. Monta has no affiliation with FileZilla and does not endorse it, but we have found it works well for this purpose; other tools are available. This matters most with the free temporary server above, where you only have a short window to grab the file.

1. Install FileZilla. Download the free FileZilla Client from filezilla-project.org and install it.
2. Open the Site Manager (File > Site Manager > New site) and enter your server details:
   • Protocol: choose FTP - File Transfer Protocol, then set Encryption to Require explicit FTP over TLS for FTPS. (You can instead choose SFTP for retrieval only. Remember Monta itself cannot upload over SFTP, so this is only for downloading.)
   • Host: your server's address (for the free SFTPCloud server, the host shown on its page, for example eu-central-1.sftpcloud.io).
   • Port: as provided (FTP/FTPS is commonly 21).
   • Logon Type: Normal, then enter the User and Password.
3. Connect. Click Connect and accept the server's TLS certificate if prompted. The right-hand (remote) pane now shows the server's files.
4. Create the upload folder (recommended). In the right-hand pane, right-click and choose Create directory, then name it to match your Upload Location, for example diagnostics. Pre-creating the folder avoids failures on stations that will not create a missing directory. Your Upload Location URL then ends with that folder, for example ftps://user:password@host/diagnostics/.
5. Retrieve the file. After you run Get Diagnostics and the station reports Uploaded, click the refresh button in your FTP client. The uploaded file appears in the folder. Drag it to a local folder to download it.

Tips for the Upload Location URL

The Upload Location is the part people most often get wrong. A few things to know:

• Use a full, valid URL. Monta checks that the value is a well-formed URL. Include the scheme (ftp://, ftps://, http://, https://), the host, and the path where the file should be written.
• Supported schemes only: ftp, ftps, http, https. Anything else (notably sftp or scp) is rejected by Monta, even if your charging station's firmware can technically upload over that protocol.
• FTP vs FTPS: ftp:// is unencrypted, so credentials and data travel in cleartext. ftps:// wraps the same protocol in TLS so it's encrypted. Prefer FTPS whenever the charging station and server support it.
• Embedding credentials in the URL: for FTP/FTPS you can put the username and password directly in the URL: ftps://username:password@host/path/. Be aware these credentials can appear in cleartext in logs (both on the Monta side and on the charging station), so use a dedicated, low-privilege account, not a real admin login, and rotate it if needed.
• Include a trailing path/directory where appropriate (for example .../diagnostics/) so the station knows where to write, and so the uploaded file is easy to find. Create that folder on your server first (see Retrieving the file with an FTP client above); some stations will not create a missing directory.
• Time range support varies. Leaving Start Date/Time and Stop Date/Time empty is the simplest and most compatible choice. Not all charging stations honour the time filter, and some cannot upload long ranges because the file gets too large. If a request with a wide range fails, try a narrower one.
• Some stations require HTTP/HTTPS, not FTP. Accepted upload protocols are hardware-specific: some models only accept HTTP/HTTPS, others FTP/FTPS. If one scheme is rejected or fails, try another that the manufacturer documents as supported.
• HTTP servers may receive a PUT or a POST. If you build an HTTP/HTTPS endpoint, be aware different models upload differently (some use PUT, some POST, occasionally as an octet-stream), so your server may need to accept both.
• Encrypted or archived payloads: some manufacturers compress the logs into a vendor-specific archive (for example a .tar.gz containing several files) and some encrypt the contents. If the file is unreadable, you may need a tool or key from the manufacturer to open it. This is outside Monta's control.

Important things to know

• Not all brands and models support Get Diagnostics. Support for GetDiagnostics/GetLog, the time-range filter, the log format, and which upload protocols are accepted all vary by manufacturer and even by firmware version. Some models do not support the feature at all. The OCPP standard does not strictly define how diagnostics uploads must work, which is why behaviour differs so widely between vendors. If the station rejects the command or the upload never completes, the model may simply not support it.
• The logs come from the charging station, not from Monta. Their content, format, size limits, and how far back they go are all determined by the manufacturer's firmware. Large time ranges can produce large files and slow uploads.
• Monta does not provide support for specific brand/model log behaviour. We provide the mechanism to send the command and the field to enter your destination. We can't interpret manufacturer-specific log formats, tell you why a particular model rejected the request, or decrypt vendor-encrypted files.
• For hardware-specific questions, contact the manufacturer. If a charging station rejects Get Diagnostics, uploads an unreadable file, or behaves inconsistently, the manufacturer's support team is the right place to find out what that model supports and how to read its logs.

Troubleshooting