OCPP 1.6J Complete Overview

zappi remains connected to the myenergi servers, but it now enables OCPP communication via the cloud. This means that zappi can interact with other platforms using the Open Charge Point Protocol without any direct integration effort. Customers can continue using the myenergi app or myaccount portal for data monitoring as they prefer. Whilst the majority of the work was done in the cloud, some specific OCPP firmware Events were created to enable this solution.

Note: While there is no strict restriction on controlling a charger from the myenergi app while it’s connected to OCPP, it is not recommended. Doing so could potentially lead to undesired behaviour for the OCPP platform or result in conflicting commands being sent. It’s advisable to exercise caution and consider the implications of such actions.

A WebSocket connection is created between the myenergi servers and the OCPP platform.

To establish a WebSocket connection between the myenergi servers and the OCPP platform, there are two options:

• Via Myenergi Myaccount Portal: Owners can create the WebSocket connection themselves by configuring it in the myenergi myaccount portal.
• Via Technical Support with Customer Permission: Alternatively, an administrator can set up the connection through the Technical Support Team, provided they have the customer’s permission.

Note: A charger can only be connected to ONE OCPP platform at anytime. A customer can turn on or off OCPP, or change the backend connection via their myenergi myaccount.

Warning: It is the customer’s responsibility to agree a contract between them and OCPP platform provider, by turning on OCPP they’ll be sharing their real time status and consumption data with the platform provider they choose. The provider will also be able to control the charge point.

• Cloud-Hosted OCPP Service: The OCPP service is hosted in the cloud, which means it operates externally to zappi and is accessible over the internet.
• Internal IP Addresses and Security: For security reasons, it is not possible to set an internal IP address as the backend URI for a locally hosted OCPP Platform.
• External IP Address or Dynamic Naming Service (DNS): Customers who wish to use OCPP with a platform hosted within their internal network must provide an externally facing IP address.
• Security Best Practices: Always follow security best practices when configuring network access for OCPP services. Exposing internal devices directly to the internet can pose risks, so consider using firewalls, VPNs, and secure communication protocols.

The following information can be configured by either of the two interfaces when setting up OCPP:

The Backend URI which serves the same purpose as a web address (URL). It informs the charger where it should connect to.

The authorization key serves as a security measure for some platforms. Its purpose is to verify that the charger is indeed who it claims to be. However, it’s important to note that not all platforms implement this feature—it remains purely optional.

The Charge Box identity is typically based on the zappi serial number by default. However, certain platforms may require or recommend changing this identifier. It’s like giving your zappi a unique digital name to distinguish it within the charging ecosystem.

The username - In the context of OCPP, it’s advisable for the username to align with the chargebox identity unless the specific platform instructs otherwise. Consistency between these identifiers ensures smooth communication and accurate recognition within the system.

The platform offers support for both secure websockets (wss://) and unsecured websockets (ws://).

Here are some key points to consider:

• Secure Web Sockets (wss://): It is recommended to use secure web sockets wherever possible. When you opt for wss://, the data exchanged between the charge point and the platform is encrypted, enhancing security during communication.
• UK Smart Charging Regulations: If you operate in Great Britain, it’s crucial to take this into account. The UK smart charging regulations mandate encrypted transport of data. Therefore, using secure web sockets aligns with compliance requirements.

When changing the OCPP platform or establishing a new OCPP connection, it’s important to note the following: 

• Reboot Requirement: A reboot may be necessary. Fortunately, this is automatically triggered by the service.
• Car Plugged In: However, please be aware that if a car is currently plugged in, the reboot will not be executed. Therefore, unplug any vehicle before proceeding with the OCPP setup.

When utilizing OCPP, it is highly recommended to set up each zappi as its own vHub. This configuration ensures swift and responsive handling of any commands issued via OCPP.

By isolating each zappi, you enhance reliability and streamline communication within the system

Troubleshooting connection issues

Allow a few minutes for the connection to be established, try rebooting the charger and verify the WebSocket URI is correct.

The following message types are supported:

• Boot Notification
• Heartbeat
• Status Notification
• Start and End Transaction
• MeterValues
• Authorize
• Get and Change Configuration
• Update Firmware
• Set Charging Profile
• Clear Charging Profile
• Get Composite Schedule
• Change Availability
• Reset
• Unlock Connector
• Remote Start/Stop Transaction.
• Trigger Message

In the context of OCPP, all messages follow a request-response pattern. Here are the key points:

• Initiator Message:

  Depending on the specific message type, it can be initiated by either the charger (such as zappi) or the platform.

  These messages serve as the initial communication trigger.

• Request and Response:

  In most cases, you will observe a request followed by a corresponding response.

  This ensures that the communication flow is well-defined and that both parties (charger and platform) understand each other’s intentions.

A boot notification message serves as a crucial communication from a charge point to a platform. Here are the key points:

Trigger Conditions:

The boot notification is only triggered under specific circumstances:

• When zappi reboots
• When the WebSocket connection is re-established after a period of disconnection

Purpose and Contents:

The boot notification documents essential details about the charge point:

• Identity: This identifies the specific zappi (It’s chargeBoxID).

• Manufacturer: Indicates the chargers maker.

• Current Firmware Version: Specifies the installed firmware version.

By providing this information, the boot notification ensures that the platform has accurate and up-to-date details about the connected charge point.

 "BootNotification",  {  "chargeBoxSerialNumber": "91234567",  "chargePointModel": "Zappi",  "chargePointSerialNumber": "91234567",  "chargePointVendor": "Myenergi",  "firmwareVersion": "5540",  "iccid": "",  "imsi": "",  "meterType": "",  "meterSerialNumber": "91234567"  } ]

Current Time and Heartbeat Interval:

• The backend typically responds with the current time and specifies the interval at which heartbeats should be sent.

• Heartbeats serve as periodic signals to maintain the connection’s health.

Status Information:

• The backend also sends a status in the boot notification response.

• If the status is “Pending”, the service will wait until an “Accepted” status is received before sending any further OCPP messages.
• Alternatively, the backend may send information to the platform only when explicitly requested via a Trigger Message.

Warning: If no interval is provided for heartbeats zappi defaults to a heartbeat every 60 seconds

Warning: zappi will adjust it’s heartbeat interval as requested in the boot notification response if it differs to it’s current configuration. The default is 60 seconds

[  3,  "322ec9f4-1cc3-4af4-8733-3542ea6741c8",  {  "currentTime": "2024-04-02T11:44:38Z",  "interval": 30,  "status": "Accepted"  } ]

Status Notifications play a crucial role in communication between a charger (such as zappi) and a platform using OCPP. Here are the key points:

Purpose

• Status notifications inform the platform about the current status of the charger.

• Unlike me-link status messages, these notifications are sent only once (once acknowledged) when a specific event or state change occurs.

Connector ID:

• A status notification contains a connector ID.

• For zappi , this is almost exclusively connector 1, as zappi has only one connector.

• Occasionally, you may encounter connector 0 status messages during startup. These messages refer to the entire availability of the charging station and are required by some platforms.

Types of status notification

There are different types of status notification you need to be aware of in OCPP.

Here are the different types of status notifications in OCPP:

Available:

• In this state, the charger has no EV plugged in but is free of faults and ready to charge.

Unavailable:

• The charger is not available for charging. This could be due to a firmware update or a forced availability change by the charge point operator.

Preparing:

• An EV has plugged in, but it has not yet been successfully authorized for charging (for example, using the mobile app for payment).

Warning: Preparing state is also sent if a user has authorized charging but not yet plugged into the zappi

SuspendedEV:

• The user has met the prerequisites to start charging (such as plugging in and paying), but the vehicle prevents charging. This could be due to the vehicle already reaching its desired state of charge, having a timer set, or experiencing a charging fault.

SuspendedEVSE:

• The user has met the prerequisites to start charging (such as plugging in and paying), but zappi is preventing charging. This might be due to a smart charge delay or a charging schedule set via OCPP charging profiles.

Finishing:

• The user is no longer authorized to charge, even though they were previously authorized. However, they are still plugged into the charge point. This state allows the platform’s app to display the correct status of the charge point as ‘busy’, as it remains occupied by a vehicle.

Faulted:

• A fault has occurred on the charge point.

Warning: SuspendedEVSE and SuspendedEV messages should only be used when the charger has a transaction in progress—specifically, between a startTransaction and a StopTransaction message.

Purpose of Heartbeat Messages:

• Heartbeat messages serve as a way for the charger and the platform to verify their ongoing connection.

• They act like a digital handshake, ensuring that both parties are still actively communicating.

Agreeing on Heartbeat Interval:

• During the initial connection, the platform and the charger agree on the interval at which heartbeat messages should be sent.

• This interval is crucial for maintaining a healthy connection.

Heartbeat Process:

• The charger initiates the heartbeat at the defined interval.

• The backend (platform) responds to confirm receipt.

• This continuous exchange ensures that both sides are aware of each other’s presence.

Detecting Connection Issues:

• If a number of heartbeats are missed, the platform determines that the connection is no longer healthy.

• In such cases, the charger is marked as offline.

Some platforms only send heartbeats occasionally such as every 24 hours, and therefore utilize the WebSocket Ping method to keep the connection open. The interval of this Ping can be adjusted in the OCPP configuration. - The heartbeat interval is adjustable via the OCPP configuration

Purpose

• MeterValues are sent only during a transaction (between a startTransaction and StopTransaction).

• They provide metering information on the current charging session.

Default Measurand:

• By default, MeterValues provide the current consumption (Energy.Active.Import.Register).

Configurability

• MeterValues are fully configurable.

• Operators can specify the measurands they wish to receive and the interval at which they want to receive them.

Transmission Intervals:

• MeterValues are sent at defined intervals (customizable in the OCPP configuration).

• These intervals occur between the startTransaction and StopTransaction messages, regardless of whether energy is flowing or charging is suspended.

MeterValues are customisable in the OCPP configuration. See configuration parameters for a full list of available parameters

StartTransaction and StopTransaction Messages should not be confused with RemoteStartTransaction and RemoteStartTransaction which are different messages.

StartTransaction Message:

• Purpose: Notifies the platform that a charging transaction has started.

• Information Provided:

  Start meter reading: Indicates the initial meter reading at the beginning of the transaction.

  TAGID: An identifier used by the platform to determine the user or entity initiating the charging session.

StopTransaction Message:

• Purpose: Informs the platform that a charging transaction has ended.

• information Provided:

  End meter reading: Indicates the final energy consumption at the end of the transaction.

  TAGID: Continues to identify the user or entity associated with the completed charging session.

These messages play a crucial role in accurate billing and effective management of EV charging sessions.

• The TAGID field in OCPP messages doesn’t exclusively indicate that a charging session was started by an RFID card. While RFID cards are commonly associated with TAGIDs, other scenarios exist as well. For instance:

   

  App Charging Sessions:

  When users initiate charging sessions via a mobile app, the app often passes an identifier (such as a user ID or session token) in the TAGID field.

  This allows the platform to identify the customer associated with the charging session, even if RFID cards weren’t involved.

   

  Custom Identifiers:

  Some charging operators use custom identifiers (beyond RFID) to track and manage charging sessions.

  These identifiers can be associated with specific users, vehicles, or billing accounts.

  The PlugandChargeID is an example of a custom Identifier used in OCPP for free vend transactions. (See Configuration Parameters for more information).

  In summary, while TAGIDs can be misleading, they serve as a flexible mechanism for associating charging sessions with relevant information, regardless of the initiation method.

When troubleshooting a reported issue where a charging session hasn’t logged properly, checking the TAGID sent in the start transaction is a crucial step. Here’s why:

• TAGID Significance:

  The TAGID (identifier) included in the start transaction message helps identify the user or entity initiating the charging session.

  It serves as a unique reference associated with the charging event.

• Root Cause Identification:

  By examining the TAGID, you can often pinpoint the root cause of the problem.

• Common scenarios include:

  Incorrect TAGID: If an incorrect or unrecognized TAGID was sent, it could lead to session logging issues.

  App vs. PIN: Differentiating between sessions initiated via mobile apps (which may pass custom identifiers) and those using PIN Codes.

• Troubleshooting Steps:

  Verify that the TAGID matches the expected user or vehicle.

  Check for any discrepancies in the start transaction data.

  Investigate any mismatched or missing TAGIDs.

  If you suspect that the TAGID was randomly generated or matches the PlugandChargeID, it’s essential to verify that the freeCharging parameter in the OCPP configuration is False and the zappi lock settings are configured as EVPLUGGED - ON EVUNPLUGGED - ON CHARGE - OFF

Remember, accurate TAGID handling ensures proper session logging and billing

Moving platforms during an ongoing transaction carries significant implications:

• Open Transactions and Data Integrity:

  If a charging session is left open due to platform migration, it can lead to inaccurate transaction data.

  This may affect billing, reporting, and overall system reliability.

• Future Requests and Rejections:

  Changing OCPP platforms while a transaction is active can result in future requests to start charging being rejected.

  The new platform may not recognize the ongoing session, leading to potential issues.

• Unplugging Vehicles Before Migration:

  Unplugging any connected vehicle before changing platforms is critical.

  This ensures that the ongoing transaction is properly closed before the migration occurs.

• Prompting Users to Stop Charging:

  Verify that the TAGID matches the expected user or vehicle.

  Check for any discrepancies in the start transaction data.

  Investigate any mismatched or missing TAGIDs.

  In the myaccount interface, when a customer attempts to move a charger to a different platform, they are prompted to stop the charging session.

  This step helps prevent inadvertent platform changes during active transactions.

These messages are sent from a platform to zappi, as there name suggests they allow remote starting and stop charging sessions (such as from a mobile app or web UI)

• RemoteStartTransaction: Allows the platform to remotely initiate a charging session on a specific charge point. It includes relevant parameters such as connector ID and TAGID.

• RemoteStopTransaction: Enables the platform to remotely stop an ongoing charging session. It also includes the connector ID and TAGID.

RemoteStart/Stop Transaction messages still rely on start and stop transaction messages for accurate billing. You’ll still see start and stop transaction messages from the charger when using these commands.

When dealing with RemoteStartTransactions in OCPP, it’s essential to consider the following scenarios:

• Charger State:

  A RemoteStartTransaction may be rejected if the charger is not in the correct state.

  Ensure that the charger is ready and available for charging before initiating a remote start

• Charger Unavailability:

  If the charger is marked as unavailable (due to maintenance, firmware updates, or other reasons), the platform may reject the start request.

  Verify the charger’s availability status.

• Ongoing Transactions:

  The platform may reject a remote start if it believes a transaction is already in progress.

  Check whether any active charging sessions exist.

•  Rebooting the Charger:

  If a remote start request is consistently rejected, rebooting the charger can often resolve the issue.

  Rebooting helps reset the charger’s state and communication.

When initiating a charging session using OCPP (Open Charge Point Protocol), the RemoteStartTransaction command plays a crucial role and can be sent even when a vehicle is not plugged in:

• Sending RemoteStartTransaction Before Plugging In:

  You can send a RemoteStartTransaction command to the charge point even before physically plugging in the vehicle.

  Upon receiving this command, the charge point will change its status to “Preparing”.

  This step allows the central system to signal its intent to start a charging session.

• ConnectionTimeOut OCPP Parameter:

  The ConnectionTimeOut parameter in OCPP specifies the maximum duration within which the vehicle must be plugged in after the RemoteStartTransaction command.

  If the vehicle is not plugged in within this time frame, the charge point will revert to the “Available” status.

  In other words, if no physical connection occurs during the specified time, the charge point will not proceed with charging and authorization is cancelled.

• Starting the Charging Session:

  Once the vehicle is plugged in within the defined ConnectionTimeOut, the charge point will send a new StatusNotification to the central system and a StartTransaction message.

  This notification indicates that the charge point has transitioned from “Preparing” to “Charging”.

  At this point, the charging session officially begins, and the charge point starts delivering power to the vehicle.

• Purpose of Authorization Messages:

  Authorization messages are crucial when a user interacts with the zappi..

  Their primary role is to validate whether a user (via PIN code) is authorized to initiate a charging session.

• PIN Codes:

  Currently, zappi supports PIN Codes OR RemoteStarttTransaction for authorization.

• Backend Decision-Making Process:

  When the backend provider receives an authorize message from zappi:

  It evaluates the validity of the provided UID.

  Based on this evaluation, the backend responds with one of the following outcomes:

  Accepted: If the UID corresponds to an authorized user, the backend approves the charging request.

  Blocked: If there are specific restrictions (such as a blocked account or other security measures), the backend prevents charging.

  Rejected: If the UID is invalid or unauthorized, the backend rejects the charging request.

• Virtual OCPP Tag ID Creation for PIN codes:

  The OCPP tag ID is generated when a user first creates a PIN in their myenergi myaccount.

  This initial association ensures that subsequent PIN entries are linked to this unique identifier.

  Role of the OCPP Tag ID:

  The OCPP tag ID acts as a bridge between the zappi and the backend operator (such as a central system or charging network).

  It facilitates secure communication during the charging process.

  Only the virtual OCPP Tag ID needs to be given to the charge point operator.

  PIN Entry and OCPP Tag ID:

  When a user enters their PIN on the zappi:

  The system associates the entered PIN with the pre-existing virtual OCPP tag ID.

  This linkage ensures that the charging session is authorized and secure.

• OCPP Standard vs. zappi Firmware Update:

  The firmware update process for zappi differs slightly from the OCPP standard approach.

  While zappi supports the necessary commands, it has specific behavior related to firmware downloads.

• Firmware Source:

  zappi will only download firmware from the myenergi firmware server.

  Any FTP server specified in the update firmware server command will be ignored.

  This ensures that firmware updates come exclusively from the trusted myenergi source.

• Status Notifications:

  Throughout the firmware update process, zappi provides status notifications:

  Downloading: Indicates that the firmware is being fetched.

  Downloaded: Confirms successful download.

  Installing: Indicates the installation is in progress.

  Installed: Confirms successful installation.

  Installation Failed: Notifies if the installation encounters issues.

  Download Failed: Notifies if the download process fails.

• Scheduled Installation Time:

  zappi allows users to schedule the time when it will attempt to install the firmware.

  The scheduled time must be provided in UTC (Coordinated Universal Time).

•  Retry Attempts:

  Users can define how many times zappi should attempt to install the firmware.

  This feature ensures resilience in case of any transient issues during installation.

Warning: It’s not possible to install firmware with a vehicle connected. Ensure any vehicle is disconnected before installing.

• Purpose of Change Availability Command:

  The change availability command allows operators to control whether a charging station (such as zappi) is available for charging.

  It provides flexibility in managing station availability based on operational needs.

   

• Commercial Mode Support:

  When zappi operates in commercial mode, it fully supports the change availability command.

  In this mode, zappi displays messages when charging is not possible and rejects both remote and local charging sessions.

   

• Adjusting IsOperative OCPP Parameter:

  When an operator sends the change availability command:

  The IsOperative OCPP configuration parameter is adjusted accordingly.

  This parameter controls whether zappi is available for charging.

   

• Handling Ongoing Charging Sessions:

  If a vehicle is currently charging and a change to unavailable is requested:

  zappi will schedule the availability change to occur at the next unplug event.

  This ensures that ongoing charging sessions are not abruptly interrupted.

   

• Availability Status:

  The relevant statuses for zappi’s availability are:

  Available: Indicates that the charging station is ready for use.

  Unavailable: Indicates that the charging station is not currently available for charging.

• Purpose of OCPP Reset Command:

  The OCPP reset command allows you to reboot zappi .

  It should only be used when no vehicle is connected to the charge point.

   

• Types of Resets:

  In OCPP, there are two types of reset:

  Hard Reset: This type of reset is more forceful and akin to a complete system reboot.

  Soft Reset: A softer reset that attempts to gracefully restart the system without abrupt interruption.

   

• Effect on zappi:

  On the zappi charging system, both hard and soft resets have the same effect:

  Any ongoing transaction is stopped by moving zappi to STOP mode

  The charger reboots, clearing any temporary states or issues.

  It ensures that the system is ready for the next charging session.

  Charging will not resume after reboot

   

• Practical Considerations:

  When sending either of these reset types, zappi will respond by initiating the reboot process.

  It’s a useful tool for maintenance or troubleshooting scenarios.

  Remember: It is mandatory to unplug any connected vehicle before executing a reset command to ensure safety and prevent interruptions.

• Scenario:

  The unlock connector command is relevant when a charging cable becomes stuck in the untethered zappi unit.

  This situation can occur due to various reasons, such as mechanical issues or human error.

   

• User Intervention:

  When a user encounters a stuck cable, they can send the unlock connector command via OCPP.

  This command prompts zappi to take specific actions to release the cable.

   

• Zappi’s Response:

  Upon receiving the command:

  zappi will stop any ongoing charging sessions (if applicable).

  It will then release the cable from the connector.

  This allows the user to safely remove the cable.

   

• Applicability:

  The unlock connector command applies exclusively to untethered (socketed) versions of zappi.

  In these units, the charging cable is not physically attached to the charger.

  The customer should also ensure there cable is disconnected from the EV side to allow the command to be successful.

In summary, the unlock connector command ensures that users can safely retrieve a stuck cable from an untethered zappi

• Purpose of Trigger Message:

  The trigger message serves as a mechanism for an OCPP platform (such as a central system or charging network operator) to force a charge point (like zappi) to send specific messages on request.

  It is typically used when the operator suspects that the status or behavior of the charge point is incorrect.

   

• Supported Messages:

  On zappi, the following messages can be requested via the trigger message command:

  Heartbeats: These periodic messages indicate that the charge point is operational.

  StatusNotifications: These messages provide real-time updates about the charge point’s status (e.g., available, charging, fault).

  MeterValues: These messages convey energy consumption data for the current transaction.

Warning: MeterValues can only be requested if there is an ongoing transaction (charging session). Otherwise, zappi will respond with “rejected.”

• Relaying Last Received Message:

  The trigger message service relays the last message that the myenergi servers received from the zappi.

  If no messages of the requested type have been received, the request will be rejected.

   

• Practical Considerations:

  Operators can use trigger messages to verify the charge point’s behavior or troubleshoot any anomalies.

  It ensures that the charge point communicates accurately and promptly.

  If the communication between myenergi and zappi has failed it may not reflect the accurate state of the charging station.

• Purpose of Set Charging Profile Command:

   

  The Set Charging Profile command allows operators to precisely control when the zappi charger charges and the power or current allowed to flow to a vehicle during specific time intervals.

  These powerful commands are stored locally on the zappi unit, ensuring that schedules are adhered to even in the event of communication failures.

   

• Types of Charging Profiles Supported:

  Zappi supports two types of charging profiles:

  TxProfile: These profiles apply to specific transactions (charging sessions).

  TxDefaultProfile: If no TxProfile is available for a given transaction, the TxDefaultProfile takes precedence.

   

• Multiple Schedules within a Profile:

  Each charging profile (TxDefault and Tx Profile) can contain multiple schedules.

  For example, consider a profile with the following time-based schedules:

   

  Midnight: 0A (no charging)

   

  8 am: 32A (full power)

   

  10 am: 12A (reduced power)

Each of these schedules utilizes one of the 48 charging slots available on zappi. (3 slots in this case)

This flexibility allows you to create customized charging behavior throughout the day.

• TxDefault Profile and Overwriting:

  There exists one TxDefaultProfile per device.

  When a further TxDefaultProfile is sent, it overwrites the existing TxDefaultProfile .

  In other words, the latest TxDefaultProfile takes precedence over any previously set profiles.

   

• Stacking Profiles and Priority:

  Profiles can be stacked up to 15 times.

  Each stack level defines the priority when there is a clash between schedules.

   

• Absolute or Recurring Schedules:

  Charging profiles can be either absolute (specific date and time) or recurring (daily or weekly).

   

• Power Limits in Amps or Watts:

  Charging profiles allow defining power limits in amps or watts.

  Amps are recommended to account for voltage variations; a minimum threshold of 6A ensures charging occurs.

  Any limit below 6A results in the vehicle not charging.

   

• Clearing Profiles at Transaction End:

  TxProfiles are cleared at the end of a transaction.

  This occurs when a stop transaction message is sent to the OCPP platform.

   

• Display and User Communciation:

  When a schedule is active but zappi is not charging, it displays the next time the vehicle will start charging.

  The myenergi app shows the status “Waiting for Schedule”

   

• When no profiles are active or installed:

  When no schedules are active, the charger has no restrictions and will charge at full power (32A).

   

• Commercial Mode Requirement:

  Charging profiles are available only when commercial mode is active.

  In commercial mode, all timed boosts and other schedules on zappi are ignored.

  Frequency of schedules and Flash Memory Protection:

  The frequency of schedules is the operator’s choice.

  However, only 26 slot writes can be made within a 60-minute period to protect zappi’s flash memory from excessive wear.

  zappi avoids writing any slot that already matches what it has stored.

  zappi can store a maximum of 48 slots for charging profiles or schedules.

   

• Site and Device Limits

  zappi will continue to obey site and device limits regardless of the charging profile set.

   

• In summary, charging profiles allow for flexible scheduling, and each profile can accommodate various power settings at different times. The TxDefaultProfile ensures consistent behavior across the device, and operators must be mindful of overwriting existing profiles and limits described above.

Warning: With charging profiles the number of devices that be load managed is dependent on the platform you choose and if the local regulations allow cloud based load management. The local load control built into zappi still has a device limit at 5 devices and can be used with or without charging profiles. (including v-hub). 

Warning: Charging Profiles are optional you do not have to set them for a vehicle to start charging. If no profiles are installed the charger will charge at full power (taking into account any device or site limit restrictions).

• Purpose of Clear Charging Profile Command:

  The clear charging profile command allows an OCPP operator to remove any installed profiles on a device (such as zappi).

  Operators can use this command to manage charging profiles effectively.

   

• Types of Clear Profiles Command:

  The operator can clear profiles in two ways:

  Clear All Profiles of a Specific Type (e.g., TxProfile or TxDefault Profiles).

  Clear a Specific Profile by providing its type and charging profile ID.

   

• Response Handling:

  If the myenergi OCPP service cannot find a profile with the specified parameters, it will respond with “Unknown.”

  When the profile is successfully uninstalled, it will respond with “Accepted.”

   

• zappi Behavior on Profile Clearing:

  When a profile is cleared on zappi:

  The mapped charging slot on zappi is not deleted; instead, the duration parameter is set to 0

  Any limits associated with the profile are also set to 0 to indicate that it is no longer active on zappi.

• Purpose of GetCompositeSchedule Command:

  The GetCompositeSchedule command serves as a query to retrieve information about the charging profiles (schedules) associated with a specific zappi.

  Operators can use this command to understand the existing schedules and their configurations.

   

• Response from Myenergi Service:

  When the Get Composite Schedule command is sent:

  The myenergi service responds by sending a list of profiles mapped to charging slots for that particular zappi in the database.

  This response is provided in JSON format.

Considerations Regarding Profile Accuracy: Operators should be aware that the profiles returned reflect the current state of the zappi in the specific environment.

If the zappi has been factory reset, the retrieved profiles may not accurately reflect the charging profiles installed in those scenarios.

Warning: OCPP configuration changes must be made by the third party platform, they cannot be made on the myenergi as this would lead to a synchronization issue.

• Change Configuration Message:

  The Change Configuration message allows you to modify the behavior and settings of the charge point dynamically.

  It provides a way to adjust various parameters without requiring physical intervention or manual adjustments.

   

• Mapping to zappi Settings:

  Some of the Change Configuration parameters are directly mapped to existing zappi settings.

  When you change these parameters, they correspondingly affect the behavior of zappi.

  For example, you can fine-tune aspects like charging modes, lock functions, and other operational features.

Warning: Parameter names and values are case sensitive, pay particular attention to this when changing configuration values. A ‘Not Supported’ response indicates a parameter name or value is not recognised

• AuthorizationKey:

  The AuthorizationKey serves as a unique password for the charge point.

  Some operators use it to verify that the charger is genuinely communicating with the backend provider.

  Not all operators employ this feature, but those who do may periodically rotate the authorization key.

  If a new authorization key is provided, zappi will attempt to reconnect using the updated key.

   

• HeartbeatInterval:

  The HeartbeatInterval determines how frequently the charger sends heartbeat measures to the platform.

  By default, this interval is set to 60 seconds.

  Heartbeat messages help maintain the connection and signal that the charger is operational.

   

• ConnectionTimeOut:

  The ConnectionTimeOut parameter defines the duration within which a user must plug in their electric vehicle (EV) after successfully authorizing a session.

  If the user doesn’t connect the EV within this time frame, zappi will relock, and the user will need to reauthorise.

  This parameter corresponds to the LockTimeOut setting on the zappi charger.

  MeterValuesSampledData:

  The MeterValuesSampledData parameter specifies which measurands are included in the MeterValues message.

  By default, it includes the current session consumption (Energy.Active.Import.Register).

  You can request additional measurands by adding them to the MeterValuesSampledData setting, separated by commas.

  For example, if you want to receive both the current power being delivered to the vehicle and the consumption, you can specify: Energy.Active.Import.Register, Power.Active.Import.

   

• The following measurands can be requested by entering the following values into the comma separated list:

  Current.Import

  Current.Offered

  Energy.Active.Import.Register

  Frequency

  Power.Active.Import

  Power.Factor

  Voltage

Warning: zappi will handle regional variations in separator. It's not an issue if a backend uses a semi colon as a separator rather then a comma.

• MeterValueSampleInterval:

  The MeterValueSampleInterval parameter determines how frequently the charge point sends MeterValues during a transaction.

  By default, this interval is set to 900 seconds (which translates to 15 minutes).

  However, some platforms may require more frequent updates for real-time monitoring and data collection.

   

• Adjusting the Frequency:

  If the default interval isn’t sufficient for your use case, you can lower the frequency by decreasing the MeterValueSampleInterval.

  For example, if you want more frequent updates (e.g., every 60 seconds), you can adjust the interval accordingly.

Warning: There is no limit on how frequent MeterValues can be requested although anything lower then every 30 seconds is not recommended.

• StopTransactionOnInvalidId:

  The StopTransactionOnInvalidId parameter is specific to OCPP.

  It defines how zappi should respond when it receives a non-accepted authorization status in response to a StartTransaction message.

  This situation typically occurs when:

  The backend system does not recognize the provided TAGID (e.g., PIN Code Virtual Tag ID or other authorization method).

  Too much time has elapsed between user authorization and the receipt of the StartTransaction message.

  The decision point lies in whether zappi should stop charging or ignore this response.

   

• Behavior Options:

  When configuring StopTransactionOnInvalidId, you have two options:

  True: If set to True, zappi will stop an ongoing charging transaction when it receives an invalid response.

  False: If set to False, zappi will continue charging even if the response is invalid.

   

• Use Case Considerations:

  Choosing the appropriate behavior depends on your specific use case and preferences.

  If security and strict adherence to authorization are critical, setting it to True ensures that charging stops promptly when an invalid response occurs.

  If you prioritize uninterrupted charging and prefer to handle invalid responses differently (e.g., logging them without stopping the session), then set it to False.

   

• TransactionMessageAttempts:

  The TransactionMessageAttempts parameter determines how many times the OCPP service will attempt to resend a StartTransaction or StopTransaction message if the backend does not respond.

  In other words, it specifies the maximum number of retries for transaction-related messages.

  When a response is not received within the expected time frame, the OCPP service will retry up to the specified limit.

   

• TransactionMessageRetryInterval:

  The TransactionMessageRetryInterval parameter defines the time interval (in seconds) between each retry attempt for sending StartTransaction or StopTransaction messages.

  If the initial attempt fails or if the backend does not respond, the OCPP service waits for this interval before retrying.

  Adjusting this interval allows you to fine-tune the retry behavior based on your requirements

   

• UnlockConnectorOnEVSideDisconnect is an OCPP specific parameter.

  It controls how a charger behaves when a charging session is stopped by unplugging the cable from the vehicle first.

  When set to True, the cable can be removed when the vehicle is unplugged first.

  When set to False, the cable remains locked (like a tethered unit).

  By Default UnlockConnectorOnEVSideDisconnect is True

  This reduces the need to press the ('+') button on zappi when releasing the connector.

   

• LocalAuthListEnabled:

  LocalAuthListEnabled is an OCPP-specific parameter.

  It determines whether zappi should allow charging when a PIN (Personal Identification Number) is entered.

  Here’s how it works:

  If LocalAuthListEnabled is set to true, zappi will allow charging to start without further checks based on locally stored PINs.

  If LocalAuthListEnabled is set to false, zappi will validate the PIN by creating an Authorize event.

  Essentially, it controls whether locally stored PINs are sufficient for authorization or if an external validation process (such as an Authorize event) is required.

Warning: If a device disconnects from the internet master PIN code entry will be allowed to prevent the unit being bricked.

• OCPPChargeMode:

  OCPPChargeMode is a parameter that exists at the intersection of OCPP and zappi-specific behavior.

  It allows the three distinct charging modes available on zappi to be integrated with OCPP.

  Here’s how it works:

  When a charging session is initiated via a remoteStartTransaction command (typically from a central system or backend), the OCPPChargeMode parameter comes into play.

  Operators can define which charging mode the zappi should transition to, when the charging session starts.

  The available modes are:

  Eco: This mode prioritizes energy efficiency and uses surplus solar power if available.

  Eco_Plus: Similar to ECO, but with additional features for maximizing self-consumption.

  Fast: In this mode, zappi charges at the maximum available power (without considering solar surplus).

  By setting the OCPPChargeMode, operators can tailor the charging behavior to their specific requirements.

Warning: OCPPChargeMode only impacts charging started by RemoteStartTransaction commands

• RandomSmartChargeDelay (Great Britain Only):

  RandomSmartChargeDelay is a zappi-specific parameter.

  It determines whether a smart charge delay should be applied when a charging session starts.

  Here’s how it works:

  When a charging session begins, the smart charge delay introduces a random delay before the charging actually starts.

  If you set the value of RandomSmartChargeDelay to 0, it will override the random delay, and charging will start immediately without any delay.

  RandomSmartChargeDelay is only overridden when zappi is using OCPP commercial mode.

   

Warning: The delay should only be overridden if the operator plans to implement the random delay themselves. Failure to do so may result in non-compliance with the UK Smart Charging Regulations

Warning: The delay length is not adjustable via this parameter. Any value greater then 0 will generate a random delay of up to 10 minutes.

• FreeCharging is an OCPP-specific parameter.

  It determines whether authorization is required to start and stop a charging session.

   

• Here’s how it works:

  If FreeCharging is set to true, charging sessions can start and stop without any authorization requirements. Essentially, no PIN code or other validation is needed.

  If FreeCharging is set to false, authorization becomes necessary. Users must provide a valid PIN code or initiate the charging session using a RemoteStartTransaction command.

• PlugAndChargeID

  The plugandchargeID parameter plays a crucial role in charging sessions initiated without explicit authorization (such as using a PIN code or a mobile app)

  Here’s how it works: When a user simply plugs in their electric vehicle (EV) to the charger (without any additional authentication steps), the charging session starts.

  The plugandchargeID is the unique identifier for a free charging session.

  It allows the charging data to be associated with a specific customer account or vehicle on the third-party platform (such as a charging network or utility provider).

  Essentially, it enables tracking and management of free charging sessions without requiring user input.

  If the Plug and Charge ID is left blank a random UID will be generated for each charging session

   

   

   

Warning: Starting charging sessions from the myenergi app will generate charging sessions using the PlugAndChargeID (free charging) as these sessions were started with no authorisation from the OCPP platform.

• AuthorizeRemoteTxRequest is an OCPP-specific parameter.

  It plays a role in the authorization flow for a charging session.

   

• Here’s how it works:

  When a remoteStartTransaction request is received (typically from a central system or backend), zappi evaluates this parameter.

  If AuthorizeRemoteTxRequest is set to True, zappi generates an Authorize event in response to the remoteStartTransaction request.

  The Authorize event contains the TAGID (identification associated with the user or vehicle) provided in the remoteStartTransaction request.

  This behavior is optional and may vary based on the specific platform or operator requirements.

   

• CommercialMode is a zappi-specific OCPP parameter.

  It determines whether the commercial screens (presumably related to display or user interface) are activated along with other commercial mode functions.

   

• Here’s how it works:

   

  When CommercialMode is enabled (set to true), it activates additional features and screens specifically designed for commercial use.

  These features may include customized displays, billing information, and other business-related functionalities.

  For the best OCPP (charging protocol) experience, it is recommended to enable CommercialMode on zappi chargers, especially when they are being used outside of residential applications.

   

• Some OCPP functionality is not available when commercial mode is disabled.

Warning: Enabling Commercial Mode on zappi chargers restricts access to the menus via the master PIN code unless Maintenance Mode is specifically enabled. This ensures that only authorized personnel can make changes or adjustments to the charger’s settings.

• Maintenance Mode allows access to the charger menus via the master PIN code, specifically when Commercial Mode is enabled.

   

• Here’s how it works:

  When Commercial Mode is active only screens related to commercial use are visible to the user.

  Regular users (such as EV owners) should not have access to the charger setting menus.

  By enabling Maintenance Mode, authorized personnel (such as technicians or administrators) can still access the menus using the master PIN code.

  It ensures that only those with the necessary credentials can make changes or adjustments to the charger’s settings during maintenance or troubleshooting.

• FreeVendScreen is a zappi-specific OCPP parameter.

  It comes into play when Commercial Mode is enabled on the charger.

   

• Here’s how it works:

  When FreeVendScreen is set to true, the zappi display will show a message stating “Free Charging: Plug in to start charging.”

  Essentially, it informs users that they can start charging without any authentication (such as entering a PIN or using an app).

  This feature is ideal for scenarios where no additional authorization steps are necessary.

  However, if charging is free but authentication is still required (for tracking or other purposes), it’s recommended to set this parameter to false

  FreeVendScreen is best for scenarios where no authentication is necessary to start charging. If charging is free but authentication is required to start charging it’s recommended to set this parameter to false

  Warning: FreeVendScreen adjusts the message displayed on the zappi charger’s screen, but it does not directly impact whether authorization is required to start charging. The crucial parameter for determining authorization requirements is FreeCharging in the OCPP configuration.

   

• To achieve the desired behavior:

  Ensure that FreeCharging is set correctly in the OCPP configuration.

  If charging is free but authentication (such as a PIN code or app-based authorization) is still necessary, set FreeCharging to false.

  If no authentication is required for free charging, set FreeCharging to true.

• TariffType is a zappi-specific OCPP parameter.

  It comes into play when Commercial Mode is enabled on the charger.

   

• Here’s how it works:

  TariffType allows the operator (charging station owner or administrator) to determine the tariff structure displayed to end users during charging sessions.

  The operator can choose from the following tariff structures:

  TARIFF_KWH: Displays the cost per kilowatt-hour (kWh) in the format £0.00.

  TARIFF_MINUTE: Displays the cost per minute in the format £0.00.

  TARIFF_CONNECTION_FEE: Displays a one-off cost (sometimes referred to as a session fee) in the format £0.00.

  TARIFF_IDLE_FEE: Displays a cost per minute when the vehicle is plugged in but not actively charging.

   

• Operators configuring tariffs for zappi have the flexibility to create composite tariff structures by combining multiple components. For instance, they can define a tariff that includes both a price per kilowatt-hour (kWh) and an idle fee. This is achieved by entering these components as comma-separated lists, such as TARIFF_KWH, TARIFF_IDLE_FEE.

  NOTE HERE The TariffType parameter determines the visibility of tariff components, but each component has its own separate configuration parameter. These individual parameters allow fine-tuning of pricing details for a more customized charging experience.

  Considering screen display limitations, it’s advisable to limit the number of tariff structures to two along with an idle fee. This approach ensures a clear and concise presentation for users

  The tariff parameters serve the crucial purpose of displaying the tariff information to the user during charging sessions. However, the actual billing and cost calculation for those sessions remain the responsibility of the OCPP platform.

  It’s crucial for operators to be aware of local regulations and compliance requirements when implementing tariff structures. Here are some considerations:

   

• Regional Acceptance: Different regions or countries may have specific rules regarding acceptable tariff types. Operators should research and understand the local regulations to ensure that the chosen tariff structures align with legal requirements.

   

• MID Meter: In some cases, accurate billing necessitates the use of a Measurement Instruments Directive (MID)-approved meter. The MID ensures that energy measurements are precise and comply with European Union standards. Operators should verify whether their charging stations require an MID meter for billing accuracy.

   

• Operator Responsibility: Ultimately, it is the operator’s responsibility to adhere to regulations, provide transparent pricing information, and maintain accurate billing practices. By doing so, they can create a positive experience for users while meeting legal obligations.

   

• PricekWh: This parameter enables the operator (charging station owner or administrator) to adjust the price per kilowatt-hour (kWh) value displayed on the zappi. It allows customization of the charging cost based on energy consumption. When setting this information you should consider:

   

• Tariff Type Compatibility: To ensure accurate display on the zappi screen, it’s crucial to set the Tariff Type parameter to TARIFF_KWH. This alignment ensures that the correct pricing information is presented to users during charging sessions.

   

• Input Format: When entering the value for PricekWh, use the format 0.00. No currency symbols or additional units are necessary; these details are automatically generated by zappi.

   

Warning:Currently only GBP is supported for pricing

• PriceMinute: This parameter enables the operator (charging station owner or administrator) to adjust the price per minute value displayed on the zappi. It allows customization of the charging cost based on duration. When setting this information you should consider:

   

• Tariff Type Compatibility: To ensure accurate display on the zappi screen, it’s crucial to set the TariffType parameter to TARIFF_MINUTE. This alignment ensures that the correct pricing information is presented to users during charging sessions.

   

• Input Format: When entering the value for PriceMinute, use the format 0.00. No currency symbols or additional units are necessary; these details are automatically generated by zappi.

   

Warning:Currently only GBP is supported for pricing

• IdleFee: This parameter allows the operator (charging station owner or administrator) to adjust the price per minute when no energy is flowing to the vehicle. It is displayed on the zappi and allows customization of the charging cost based on duration.

   

• Tariff Type Compatibility: To ensure accurate display on the zappi screen, it’s crucial to set the TariffType parameter to TARIFF_IDLE_FEE. This alignment ensures that the correct pricing information is presented to users during charging sessions.

   

• Input Format: When entering the value for PriceIdleFee, use the format 0.00. No currency symbols or additional units are necessary; these details are automatically generated by zappi.

  Idle fee is displayed on a separate line to price per minute and are clearly distinguished so they can be used together

   

Warning:Currently only GBP is supported for pricing

• ConnectionFee: This parameter allows the operator (charging station owner or administrator) to adjust the one-off cost associated with a charging session. It is sometimes referred to as a session fee. The purpose of this fee is to cover the initial connection and setup costs.

   

• Tariff Type Compatibility: To ensure accurate display on the zappi screen, it’s crucial to set the TariffType parameter to TARIFF_CONNECTION_FEE. By doing so, the correct pricing information will be presented to users during charging sessions.

   

• Input Format: When entering the value for ConnectionFee, use the format 0.00. No currency symbols or additional units are necessary; these details are automatically generated by zappi.

Warning:Currently only GBP is supported for pricing

• The SupportContact parameter is a zappi-specific OCPP configuration value. When a fault occurs on the charge point, it allows the operator (charging station owner or administrator) to display a support contact number. This ensures that users have immediate access to assistance in case of any issues with the charging station

• What Is IsOperative?

  IsOperative is a parameter within the OCPP that serves as a control mechanism for the “zappi” charging system.

  It determines whether the zappi charger is available for charging or not.

   

• Change Availability Message:

  When a “Change Availability” message is sent (by an operator or system), the OCPP service adjusts the IsOperative parameter.

  This adjustment allows an operator to either put a charge point into service (make it available) or take it out of service (make it unavailable).

   

• Instances of Maintenance:

  The parameter adjustment might occur during maintenance activities.

  For example, if the zappi needs maintenance or repair, the operator can set IsOperative to false, effectively disabling charging.

   

• Effect of IsOperative Being False:

  When IsOperative is set to false:

  zappi will disallow any charging.

  The charging screen will display a message indicating that the charge point is unavailable.

   

• Handling Plugged-In Vehicles:

  If a vehicle is currently plugged into the zappi charger when the IsOperative parameter changes to False:

  zappi will wait for the vehicle to unplug before taking action on the availability change.

   

• Status Notifications:

  Once the availability change is executed:

  zappi will send status notifications for both connector 1 and 0.

  These notifications inform the platform about the change in the charger’s availability.

   

• Applicability in Commercial Mode:

  The IsOperative parameter is relevant only when zappi is operating in commercial mode.

   

In summary, IsOperative controls whether the zappi charger is available for charging, and its adjustment affects the charger’s operational status. During maintenance or other scenarios, operators can use this parameter to manage the availability of the charging point.

IsOperative is writable via the OCPP configuration but typically this change would be made by sending a change availability command to zappi via OCPP

• PaymentURL:

  PaymentURL is a specific configuration parameter in the zappi OCPP service . It’s optional, but when enabled, it serves a useful purpose. Here’s how it works:

  When a user connects their vehicle to the charger, zappi generates a QR code.

  This QR code can be scanned by customers.

  The purpose of the QR code is to direct customers to the correct app or website for payment.

  The operator only needs to provide the URL (web address) they want to direct customers to QR generation is handled by zappi.

  Keep in mind that Payment URL and QR code generation are only available when the system is in commercial mode.

  When the QR code screen is displayed the backlight remains on to allow for easy scanning of the QR code in low light conditions.

  In summary, PaymentURL simplifies the payment process by creating a QR code that guides customers to the right place for payment.

   

   

• AllowPINCode:

  AllowPINCode is a zappi specific OCPP configuration parameter. It’s relevant when the system is in commercial mode.

  When AllowPINCode is enabled, users can enter a PIN code to start charging their vehicle using the zappi charger.

  However, if AllowPINCode is disabled, PIN code entry for starting charging on zappi is not possible.

  In such cases, all charging transactions must be initiated either through the myenergi app or via a RemoteStartTransaction command.

  In summary, AllowPINCode determines whether users can use a PIN code directly on the zappi charger to start charging or if they need to use alternative methods like the app or remote commands.

   

Warning:PIN Code entry becomes possible if the device disconnected from the internet

• ChargerName:

  This is a specific configuration parameter in the zappi system, and it’s relevant when the system is in commercial mode.

  When you set a ChargerName, it allows you to give a custom name to a charger.

  This custom name is then displayed on the charger’s screen for easy identification.

  For example, you could name a charger “Salt House Bay 1” to distinguish it from other chargers.

  In summary, ChargerName simplifies the process of identifying specific chargers by displaying a user-defined name on the charger’s display

   

   

• ChargeID: This is a specific configuration parameter in the zappi system, and it’s relevant when the system is in commercial mode.

  When you set a ChargeID, it allows you to assign a unique ID to a charger.

  This ID is then displayed on the charger’s screen for easy identification.

  It can be the same as the ID shown in the user app or the ID that a user must enter to find the charger in the operator’s app.

  Importantly, the ChargeID does not necessarily have to match the chargeboxID.

  In summary, ChargeID simplifies the process of identifying specific chargers by displaying a custom ID on the charger’s display.

   

   

• appName: This is a specific configuration parameter in the zappi system, and it’s relevant when commercial mode is enabled:

  When you set an appName, it allows you to specify the name of the app that customers must use to start charging.

  For example, if your charging service has a dedicated app called “ZappiCharge,” you can set the appName to “ZappiCharge” so that users know which app to use for initiating charging sessions.

  In summary, appName simplifies the process by clearly indicating which app customers should use to start charging their vehicles.