Soalan Lazim

Biasanya berkaitan kelewatan segerak status atau "kegagalan lembut". OCPP 1.6 bergantung pada StatusNotification untuk melaporkan status konektor; gangguan rangkaian atau heartbeat terputus menyebabkan platform masih menunjukkan status lama. OCPP 2.0.1 memperbaikinya melalui TransactionEvent dan pemantauan lebih halus, tetapi jika pengecas mengesan kegagalan (butang kecemasan ditekan, kegagalan gun-lock) tanpa melaporkan NotifyEvent tepat masa, app masih boleh tersilap anggap tersedia. Kami cadangkan papar "masa kemas kini status terakhir" di halaman butiran.

Kelewatan permulaan biasanya berlaku semasa perjalanan Authorize dan StartTransaction (1.6) atau TransactionEvent(Started) (2.0.1). Jika WebSocket heartbeat antara platform dan pengecas tidak stabil, atau isyarat pengecas lemah, arahan dihantar semula. OCPP 1.6 perlu menunggu platform memulangkan transaction ID sebelum mengecas, manakala model acara 2.0.1 secara teori lebih pantas — tetapi firmware yang mengendalikan TransactionEvent dengan buruk masih boleh menyebabkan lag.

Ini kes status tak segerak tipikal. Dalam OCPP 1.6, jika pengecas berhenti kerana suhu tinggi, perlindungan bocoran atau s unplugged (tanpa menghantar StopTransaction betul), platform mungkin masih menunjukkan sedang mengecas kerana tidak menerima StatusNotification(Faulted/Available). OCPP 2.0.1 menggunakan TransactionEvent(Ended) yang lebih ketat tetapi perlu implementasi betul di sisi pengecas. Platform perlu ada logik "timeout heartbeat automatik tutup pesanan tempatan" sebagai safety net.

Plug-and-charge (PnC/ISO 15118) ialah keupayaan asli OCPP 2.0.1; OCPP 1.6 tidak menyokong PnC standard. Jika platform mempunyai pengecas kedua-dua protokol, app patut papar label keupayaan mengikut versi protokol dan konfigurasi sebenar setiap pengecas. Jika 2.0.1 certificate chain tidak dikonfigur betul, PnC gagal — app patut fallback kepada arahan "sila imbas untuk mula".

Diagnosis mengikut susunan Rangkaian → WebSocket → OCPP: ① semak pengecas boleh capai alamat wss:// platform (DNS, firewall, port 443); ② semak Charge Point Identity dan URL path padanan tepat (cth. /ocpp/CP001 kes huruf atau suffix salah); ③ OCPP 1.6 periksa Heartbeat normal; OCPP 2.0.1 periksa Heartbeat selepas BootNotification dan security event log. Jika skrin pengecas normal tetapi OCPP offline, biasanya modul OCPP hang atau SIM habis kuota.

Perlu, tetapi boleh diabstrakkan. Mesej kedua-dua tidak serasi: 1.6 guna StartTransaction/StopTransaction, 2.0.1 guna TransactionEvent; konfigurasi 1.6 melalui ChangeConfiguration key-value, 2.0.1 melalui device model SetVariables/GetVariables berstruktur. Cadang platform membina model "charging session" bersatu di atas lapisan protokol, memetakan mesej kedua-dua protokol ke satu objek perniagaan, elak pembangunan berulang.

OCPP 1.6 RemoteStartTransaction menghendaki pengecas buat local auth (cth. Authorize) dahulu; jika cache whitelist tempatan tamat tempoh atau konfigurasi AuthorizeRemoteTxRequests salah, ia menolak. OCPP 2.0.1 RequestStartTransaction lebih ketat, perlu AvailabilityState EVSE dan Connector berstatus Operative dahulu. Jika WebSocket dead (TCP pass tetapi lapisan aplikasi tiada respons), arahan timeout — perlu TriggerMessage atau pengesanan heartbeat timeout untuk reset sambungan.

OCPP 2.0.1 pengurusan firmware lebih selamat dan boleh dijejak. UpdateFirmware 1.6 biasanya "hantar URL → pengecas muat turun → pengecas restart", platform suka tahu kemajuan dan hasil pengesahan; 2.0.1 PublishFirmware + UpdateFirmware menyokong muat turun chunked, pengesahan keselamatan dan laporan status — lebih sesuai operasi berskala besar. Jika platform masih dominan 1.6, cadangkan langkah "sahkan nombor versi melalui BootNotification selepas penataran".

"Sokongan OCPP 1.6" bukan bermakna "plug-and-play". Titik putus biasa: format WebSocket URL (slash hujung, kes huruf path, guna wss atau tidak), Charge Point Identity tak sepadan, subprotocol belum dirunding (ocpp1.6), sijil TLS tidak dipercayai pengecas (firmware lama tidak kenal CA baru). OCPP 2.0.1 juga memerlukan padanan security profile; jika platform paksa TLS tetapi pengecas hanya menyokong basic auth, handshake gagal terus.

Tidak boleh bertukar automatik. Versi OCPP ditetapkan semasa WebSocket handshake melalui subprotocol (cth. ocpp1.6, ocpp2.0.1); firmware biasanya hanya laksanakan satu versi. Platform perlu route ke protocol handler bersesuaian berdasarkan BootNotification atau path URL. Pengecas fizikal sama tidak boleh "naik taraf" dari 1.6 ke 2.0.1 semasa berjalan, kecuali ganti firmware dan konfigurasi semula.

Pada 1.6, platform perlu meneka keupayaan pengecas melalui GetConfiguration dengan banyak vendor key; device model 2.0.1 menstandarkan struktur pokok EVSE → Connector → Component → Variable, platform boleh baca/tulis tepat contohnya ambang suhu gun tertentu, status relay tertentu. Peningkatan kualitatif untuk O&M halus dan diagnosis jauh, tetapi backend perlu restructure modul pengurusan konfigurasi — tidak boleh terus guna storan key-value rata gaya 1.6.

1.6 menyokong SetChargingProfile asas (statik atau kurva berasaskan masa ringkas) tetapi kurang kerjasama grid dan penyesuaian dinamik. 2.0.1 lebih lengkap: ChargingStationExternalConstraints, hantar had kuasa dinamik, penjadualan kluster banyak pengecas, dan boleh bersekutu dengan ChargeParameterDiscovery ISO 15118. Jika stesen perlukan "orderly charging" atau "demand control", pengecas 2.0.1 lebih baik — tetapi enjin jadual pengecasan platform perlu dinaik taraf sewajarnya.

Kami menyediakan empat model: francais, pembelian peralatan, operasi tapak dan penyelesaian korporat, meliputi ejen, pengurusan hartanah dan pengendali armada. Hantar PertanyaanBeritahu kami tentang tapak dan hasrat kerjasama anda, pasukan perniagaan akan menghubungi dalam 24 jam dengan anggaran pelan dan sokongan tinjauan tapak; anda juga boleh menghantar email terus melalui halaman "Hubungi Kami".