คำถามที่พบบ่อย

มักเกี่ยวกับความล่าช้าของการซิงค์สถานะหรือ "soft fault" OCPP 1.6 ใช้ StatusNotification รายงานสถานะ connector หากเครือข่ายสั่นหรือ heartbeat ขาด แพลตฟอร์มอาจยังแสดงสถานะเก่า OCPP 2.0.1 ดีขึ้นด้วย TransactionEvent และการเฝ้าดูที่ละเอียดขึ้น แต่ถ้าสถานีพบข้อผิดพลาด (กดปุ่มฉุกเฉิน, gun-lock ผิดปกติ) โดยไม่รายงาน NotifyEvent ทันเวลา แอปอาจเข้าใจผิดว่าใช้ได้ แนะนำให้แสดง "เวลาอัปเดตสถานะล่าสุด" ในหน้ารายละเอียด

ความล่าช้ามักเกิดในกระบวนการ Authorize และ StartTransaction (1.6) หรือ TransactionEvent(Started) (2.0.1) หาก WebSocket heartbeat ระหว่างแพลตฟอร์มกับสถานีไม่เสถียร หรือสัญญาณสถานีอ่อน คำสั่งจะถูกส่งซ้ำ OCPP 1.6 ต้องรอแพลตฟอร์มคืน transaction ID ก่อนจ่ายไฟ ส่วน 2.0.1 ซึ่งขับเคลื่อนด้วยเหตุการณ์เร็วกว่าในทางทฤษฎี แต่ถ้าเฟิร์มแวร์จัดการ TransactionEvent ไม่ดีก็ยังอาจสะดุด

เป็นกรณีสถานะไม่ตรงกันทั่วไป ใน OCPP 1.6 ถ้าสถานีหยุดจากอุณหภูมิสูง ไฟรั่ว หรือหัวชาร์จถูกถอน (โดยไม่ส่ง StopTransaction ที่ถูกต้อง) แพลตฟอร์มอาจยังแสดงกำลังชาร์จเพราะไม่ได้รับ StatusNotification(Faulted/Available) OCPP 2.0.1 ใช้ TransactionEvent(Ended) ซึ่งออกแบบรัดกุมกว่า แต่ต้องให้ฝั่งสถานีทำถูกต้อง ฝั่งแพลตฟอร์มควรมี logic "หมดเวลา heartbeat แล้วปิดคำสั่งซื้ออัตโนมัติ" เป็นเขตอนาคตกันเหตุการณ์นี้

Plug-and-charge (PnC/ISO 15118) เป็นความสามารถพื้นฐานของ OCPP 2.0.1 ส่วน OCPP 1.6 ไม่รองรับ PnC มาตรฐาน หากแพลตฟอร์มมีสถานีทั้งสองโปรโตคอล แอปควรแสดงป้ายความสามารถตามเวอร์ชันโปรโตคอลและการตั้งค่าจริงของแต่ละสถานี ถ้า 2.0.1 ตั้งค่า certificate chain ไม่ถูก PnC ก็จะใช้ไม่ได้ แอปควรกลับไปแจ้ง "กรุณาสแกนเพื่อเริ่ม"

ตรวจตามลำดับ เครือข่าย → WebSocket → OCPP: ①ตรวจว่าสถานีเข้าถึงที่อยู่ wss:// ของแพลตฟอร์มได้หรือไม่ (DNS, firewall, พอร์ต 443) ②ตรวจ Charge Point Identity กับ URL path ตรงกันครบถ้วน (เช่น /ocpp/CP001 ตัวพิมพ์หรือ suffix ผิด) ③OCPP 1.6 ดู Heartbeat ปกติไหม OCPP 2.0.1 ดู Heartbeat หลัง BootNotification และ security event log ถ้าหน้าจอสถานีปกติแต่ OCPP ออฟไลน์ มักเป็นโมดูล OCPP ค้างหรือ SIM หมดยอด

ต้อง แต่ทำ abstraction ได้ ข้อความของสองเวอร์ชันไม่เข้ากัน: 1.6 ใช้ StartTransaction/StopTransaction, 2.0.1 ใช้ TransactionEvent; 1.6 ตั้งค่าด้วย ChangeConfiguration key-value, 2.0.1 ใช้ SetVariables/GetVariables device model แนะนำให้สร้างโมเดล "charging session" รวมเหนือชั้นโปรโตคอล แมปข้อความทั้งสองเข้า business object เดียว ลดการพัฒนาซ้ำซ้อน

OCPP 1.6 RemoteStartTransaction ให้สถานีทำ local auth (เช่น Authorize) ก่อน ถ้า local whitelist cache หมดอายุหรือตั้งค่า AuthorizeRemoteTxRequests ไม่ถูก จะปฏิเสธ OCPP 2.0.1 RequestStartTransaction เข้มงวดกว่า ต้องให้ AvailabilityState ของ EVSE และ Connector เป็น Operative ก่อน ถ้า WebSocket connection แบบตาย (TCP ผ่านแต่แอปเลเยอร์ไม่ตอบ) คำสั่งจะ timeout ต้องใช้ TriggerMessage หรือ heartbeat timeout ตรวจจับและรีเซ็ตการเชื่อมต่อ

OCPP 2.0.1 จัดการเฟิร์มแวร์ปลอดภัยและตรวจสอบย้อนได้กว่า 1.6 UpdateFirmware มักเป็น "ส่ง URL → สถานีดาวน์โหลด → รีสตาร์ท" แพลตฟอร์มรู้ความคืบหน้าและผลตรวจยาก; 2.0.1 PublishFirmware + UpdateFirmware รองรับดาวน์โหลดแบบแบ่งส่วน ตรวจความปลอดภัย และรายงานสถานะ เหมาะกับการดูแลขนาดใหญ่ ถ้ายังเป็น 1.6 หลัก แนะนำเพิ่มขั้น "ตรวจเวอร์ชันผ่าน BootNotification หลังอัปเดต"

"รองรับ OCPP 1.6" ไม่เท่ากับ "ใช้ได้ทันที" จุดตัดที่พบบ่อย: รูปแบบ WebSocket URL (slash ท้าย, ตัวพิมพ์ path, ใช้ wss หรือไม่), Charge Point Identity ไม่ตรง, ยังไม่เจรจา subprotocol (ocpp1.6), ใบรับรอง TLS ที่สถานีไม่เชื่อ (เฟิร์มแวร์เก่าไม่รู้จัก CA ใหม่) OCPP 2.0.1 ต้อง match security profile ด้วย ถ้าแพลตฟอร์มบังคับ TLS แต่สถานีรองรับเฉพาะ basic auth การ handshake จะล้มเหลวทันที

สลับอัตโนมัติไม่ได้ เวอร์ชัน OCPP กำหนดตอน WebSocket handshake ผ่าน subprotocol (เช่น ocpp1.6, ocpp2.0.1) เฟิร์มแวร์มักทำเวอร์ชันเดียว แพลตฟอร์มต้อง route ไป protocol handler ที่ตรงกันจาก BootNotification หรือ path ของ URL สถานีเครื่องเดียวกันเปลี่ยนจาก 1.6 เป็น 2.0.1 กลางทางไม่ได้ นอกจากเปลี่ยนเฟิร์มแวร์และตั้งค่าใหม่

ใน 1.6 แพลตฟอร์มต้องเดาความสามารถของสถานีจาก GetConfiguration ที่มี vendor key กองใหญ่; 2.0.1 device model ใช้โครงสร้างต้นไม้ EVSE → Connector → Component → Variable แพลตฟอร์มอ่าน/เขียนค่าเฉพาะ เช่น threshold อุณหภูมิของหัวชาร์จหัวใดก็ได้ ละเอียดขึ้นมากสำหรับบำรุงรักษาและวินิจฉัยระยะไกล แต่ backend ต้องรื้อระบบจัดการการตั้งค่าจากแบบ key-value แบนเป็นโมเดลโครงสร้าง

1.6 รองรับ SetChargingProfile ระดับพื้นฐาน (static หรือ curve ตามเวลา) แต่ขาดความร่วมมือกับ grid และการปรับแบบไดนามิก 2.0.1 ครบกว่า: ChargingStationExternalConstraints, ส่งกำลังไฟ ceiling แบบไดนามิก, ควบคุมหลายสถานีเป็นกลุ่ม และเชื่อมกับ ChargeParameterDiscovery ของ ISO 15118 ได้ ถ้าสถานีต้อง "orderly charging" หรือ "demand control" สถานี 2.0.1 เหมาะกว่า แต่ charging schedule engine ของแพลตฟอร์มต้องอัปเกรดตาม

เรามีสี่รูปแบบ: แฟรนไชส์ จัดซื้ออุปกรณ์ ดำเนินการสถานี และโซลูชันองค์กร ครอบคลุมทั้งตัวแทน ผู้จัดการอสังหาฯ และผู้ดำเนินการ fleet ส่งคำขอร่วมมือบอกเราเกี่ยวกับสถานที่และความต้องการของคุณ ทีมธุรกิจจะติดต่อกลับภายใน 24 ชั่วโมง พร้อมประเมินแผนและสำรวจหน้างาน หรือส่งอีเมลผ่านหน้า "ติดต่อเรา" ได้โดยตรง