[go: nahoru, domu]
Jump to content

Project:Sandbox: Difference between revisions

From mediawiki.org
Browse history interactively
← Older editNewer edit →
Content deleted Content added
VisualWikitext
No edit summary
Tags: Reverted Visual edit
Hazard-Bot (talk | contribs)
Bots
12,976 edits
m Bot: Automatically cleaned
Tags: Replaced Manual revert
Line 1: Line 1:
{{Please leave this line alone and write below (this is the coloured heading)}}
{{Please leave this line alone and write below (this is the coloured heading)}}
'''= Introduction ='''

'''== Purpose =='''

This document is an effort to describe the BLE Services and Characteristics supported by the Nexxtender Home. It is not written by someone knowledgeable about the subject, but is based on the study of the external behavior of the product. No guarantees on its correctness can be given. Use at your own risk.

<nowiki>*</nowiki> Section <nowiki>[[#Generic Access characteristics]]</nowiki>

<nowiki>*</nowiki> Section <nowiki>[[#Services]]</nowiki> gives an overview of the supported services.

<nowiki>*</nowiki> Section <nowiki>[[#Generic Access characteristics]]</nowiki> discusses the characteristics supported by the ''<nowiki>''Generic Access''</nowiki>'' service.

<nowiki>*</nowiki> Section <nowiki>[[#Generic Attribute characteristics]]</nowiki> discusses the characteristics supported by the ''<nowiki>''Generic Attributes''</nowiki>'' service.

<nowiki>*</nowiki> Section <nowiki>[[#Device Information characteristics]]</nowiki> discusses the characteristics supported by the ''<nowiki>''Device Information''</nowiki>'' service.

<nowiki>*</nowiki> Section <nowiki>[[#Generic characteristics]]</nowiki> discusses the characteristics supported by the ''<nowiki>''Generic''</nowiki>'' service.

<nowiki>*</nowiki> Section <nowiki>[[#CDR characteristics]]</nowiki> discusses the characteristics supported by the ''<nowiki>''CDR''</nowiki>'' service.

<nowiki>*</nowiki> Section <nowiki>[[#CCDT characteristics]]</nowiki> discusses the characteristics supported by the ''<nowiki>''CCDT''</nowiki>'' service.

<nowiki>*</nowiki> Section <nowiki>[[#Firmware characteristics]]</nowiki> discusses the characteristics supported by the ''<nowiki>''Firmware''</nowiki>'' service.

<nowiki>*</nowiki> Section <nowiki>[[#Charging characteristics]]</nowiki> discusses the characteristics supported by the ''<nowiki>''Charging''</nowiki>'' service.

'''== Acronyms and Definitions =='''

<nowiki>{| class="wikitable"</nowiki>

|+ Glossary

|-

! Term !! Definition

|-

<nowiki>|</nowiki> <nowiki>[https://bluetoothle.wiki/start BLE]</nowiki> <nowiki>||</nowiki> Bluetooth Low Energy

|-

| CT || Nexxtender Current Transformer attached to the grid

|-

<nowiki>|</nowiki> <nowiki>[https://en.wikipedia.org/wiki/CBOR CBOR]</nowiki> <nowiki>||</nowiki> Concise Binary Object Representation

|-

<nowiki>|</nowiki> <nowiki>[https://www.mydiego.lu/en Diego]</nowiki> <nowiki>||</nowiki> Diego has taken over the nexxtmove.me web site and the Nexxtmove apps from Powerdale

|-

<nowiki>|</nowiki> <nowiki>[https://bluetoothle.wiki/gatt GATT]</nowiki> <nowiki>||</nowiki> Generic Attributes

|-

<nowiki>|</nowiki> <nowiki>[https://www.cebeo.be/catalog/nl-be/products/powerdale-laadpaal-nexxtender-home-1-4kw-22-kw-t2-cable-7m-rcm-bluetooth-6496973 HOME]</nowiki> <nowiki>||</nowiki> Nexxtender wall mountable charger

|-

<nowiki>|</nowiki> <nowiki>[https://en.wikipedia.org/wiki/Endianness Little-endian]</nowiki> <nowiki>||</nowiki> A little-endian system stores the least significant byte of a word at the smallest memory address

|-

| Nexxtender || Powerdale brand name for car chargers

|-

<nowiki>|</nowiki> <nowiki>[https://play.google.com/store/apps/details?id=com.powerdale.nexxtender&hl=nl Nexxtmove]</nowiki> <nowiki>||</nowiki> Android app to control the HOME

|-

<nowiki>|</nowiki> <nowiki>[https://play.google.com/store/apps/details?id=com.powerdale.homeinstaller&hl=nl Nexxtender Installer]</nowiki> <nowiki>||</nowiki> Nexxtmove app for installers. Seems to be a superset of Nexxtmove.

|-

<nowiki>|</nowiki> <nowiki>[https://www.brusselstimes.com/935740/belgian-charging-station-giant-powerdales-bankruptcy-leaves-users-stranded Powerdale]</nowiki> <nowiki>||</nowiki> Manufacturer of the Nexxtender products. Out of business.

|-

<nowiki>|</nowiki> <nowiki>[https://en.wikipedia.org/wiki/Unix_time Unix Time]</nowiki> <nowiki>||</nowiki> Number of seconds since 1/1/1970 00:00

|}

'''== Referenced Material =='''

The following materials are to be used in conjunction with or are referenced by this document:

<nowiki><ref name="ref1">https://github.com/geertmeersman/nexxtender</ref></nowiki>

<nowiki><ref name="ref2">https://github.com/toSvenson/nexxtender-ble</ref></nowiki>

<nowiki><ref name="ref3">Nexxtender Installer_2.2.6_Apkpure.apk</code> downloaded from https://apkpure.net/nexxtender-installer/com.powerdale.homeinstaller/download</ref></nowiki>

<nowiki><ref name="ref4"">https://gathering.tweakers.net/forum/list_messages/2206384</ref></nowiki>

'''= Services ='''

The following services are used.

<nowiki>{| class="wikitable"</nowiki>

|-

! UUID !! Name

|-

<!-- Without the XML comment in next line , Eclipse<nowiki>'s wikitext preview does not handle the '''bold'''</nowiki> correctly-->

| 0000<!-- -->'''<nowiki>'''1800'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Generic Access

|-

| 0000<!-- -->'''<nowiki>'''1801'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Generic Attribute

|-

| 0000<!-- -->'''<nowiki>'''180a'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Device Information

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''c1'''</nowiki>''' || Generic

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''c1'''</nowiki>''' || CDR <nowiki><ref>0xC1 seems to be used for both </nowiki>''<nowiki>''Generic''</nowiki>'' and ''<nowiki>''CDR''</nowiki>''.<nowiki></ref></nowiki>

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''c5'''</nowiki>''' || CCDT

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''c9'''</nowiki>''' || FIRMWARE

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''ce'''</nowiki>''' || CHARGING

|}

'''= Generic Access characteristics ='''

The following Characteristics of the Generic Access service are used.

<nowiki>{| class="wikitable"</nowiki>

|-

! UUID !! Name !! Readable !! Writable !! Writable Without Response !! Notify !! Coding

|-

| 0000<!-- -->'''<nowiki>'''2a00'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Device Name || x || x || x || || ASCII

|-

| 0000<!-- -->'''<nowiki>'''2a01'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Appearance || || x || x || || HEX

|-

| 0000<!-- -->'''<nowiki>'''2a04'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Peripheral Preferred Connection Parameters || x || || || || HEX

|}

'''== Device Name characteristic =='''

My Nexxtender Home returns the ASCII string “HOME2_”

'''== Appearance characteristic =='''

My Nexxtender Home returns the HEX array “00 00”.

'''== Peripheral Preferred Connection Parameters characteristic =='''

My Nexxtender Home returns the HEX array “FF FF FF FF 00 00 FF FF”.

'''= Generic Attribute characteristics ='''

The following Characteristics of the Generic Attribute service are used.

<nowiki>{| class="wikitable"</nowiki>

|-

! UUID !! Name !! Readable !! Writable !! Writable Without Response !! Notify !! Coding

|-

|0000<!-- -->'''<nowiki>'''2a05'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Service Changed || || || || || ||

|}

'''== Service Changed characteristic =='''

Not readable on my Nexxtender Home, only subscribable.

'''= Device Information characteristics ='''

The following Characteristics of the Device Information service are used.

<nowiki>{| class="wikitable"</nowiki>

|-

! UUID !! Name !! Readable !! Writable !! Writable Without Response !! Notify !! Coding

|-

| 0000<!-- -->'''<nowiki>'''2a24'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Model Number String || x || x || || || ASCII

|-

| 0000<!-- -->'''<nowiki>'''2a25'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Serial Number String || x || x || || || ASCII

|-

| 0000<!-- -->'''<nowiki>'''2a26'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Firmware Revision String || x || x || || || ASCII

|-

| 0000<!-- -->'''<nowiki>'''2a27'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Hardware Revision String || x || x || || || ASCII

|}

'''== Model Number String =='''

My Nexxtender Home returns the HEX array “36 30 32 31 31 00 00 00 00 00 00 00 00 00 00 00” representing the ASCII string “60211” followed by 11 00’s.

'''== Serial Number String =='''

My Nexxtender Home returns the HEX array “30 30 30 30 35 00 00 00 00 00 00 00 00 00 00 00” representing the ASCII string “00005” followed by 11 00’s.

'''== Firmware Revision String =='''

My Nexxtender Home returns the HEX array “32 2E 35 33 2E 32 00 00 00 00 00 00 00 00 00 00” representing the ASCII string “2.53.2” followed by 10 00’s.

'''== Hardware Revision String =='''

My Nexxtender Home returns the HEX array “41 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00” representing the ASCII string “A2” followed by 14 00’s.

'''= Still Unknown service characteristics ='''

For the following Characteristics I did not determine the associated service yet.

<nowiki>{| class="wikitable"</nowiki>

|-

! UUID !! Name !! Readable !! Writable !! Writable Without Response !! Notify !! Coding

|-

| 0000<!-- -->'''<nowiki>'''2aed'''</nowiki>'''-0000-1000-8000-00805f9b34fb || Date UTC Characteristic || || || || || ||

|-

| 0000<!-- -->'''<nowiki>'''2902'''</nowiki>'''-0000-1000-8000-00805f9b34fb || [GATT] Client Characteristic Configuration Descriptor || || || || || ||

|-

<nowiki>|</nowiki> f4000001-f0a2-9b06-0c59-1bc4763b5c00 <nowiki>||</nowiki> RX Service UID<nowiki><span style="color:red">?</span></nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki>

|-

<nowiki>|</nowiki> f4000002-f0a2-9b06-0c59-1bc4763b5c00 <nowiki>||</nowiki> RX Char UID<nowiki><span style="color:red">?</span></nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki>

|-

<nowiki>|</nowiki> f4000003-f0a2-9b06-0c59-1bc4763b5c00 <nowiki>||</nowiki> TX Char UID<nowiki><span style="color:red">?</span></nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki> <nowiki>||</nowiki>

|}

'''= Generic characteristics ='''

The following Characteristics of the ''<nowiki>''Generic''</nowiki>'' service are used.

<nowiki>{| class="wikitable"</nowiki>

|-

! UUID !! Name !! Readable !! Writable !! Writable Without Response !! Notify !! Coding

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''dd'''</nowiki>''' || GENERIC_COMMAND || || x || || || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''de'''</nowiki>''' || GENERIC_STATUS || x || || || x || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''df'''</nowiki>''' || GENERIC_DATA || x || x || || x || ||

|}

GENERIC_COMMAND(0xDD), GENERIC_STATUS(0xDE) and GENERIC_DATA(0xDF) work together to perform an operation. An operation can trigger some action, or reads or writes configuration data. Each operation is identified with a 2 bytes ''<nowiki>''Operation''</nowiki>''. Each operation ''<nowiki>''Operation''</nowiki>'' can be performed using these 3 registers, as is explained further and starts by writing an <nowiki>''</nowiki>Operation” to GENERIC_COMMAND(0xDD). The scenario is each time similar. Are the following scenarios correct<nowiki><span style="color:red">?</span></nowiki>

Scenario for performing an ''<nowiki>''Operation''</nowiki>'' that does not read/write a value:

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Operation)

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the status.

Scenario for performing an ''<nowiki>''Operation''</nowiki>'' that writes a value:

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Operation)

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the status, indicating if the target is ready to recieve the data to be written.

<nowiki>#</nowiki> The client writes a GENERIC_DATA(0xDF) with the actual data that must be written for ''<nowiki>''Operation''</nowiki>''.

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the status, indicating if the data was successfully written.

Scenario for performing an ''<nowiki>''Operation''</nowiki>'' that reads a value:

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Operation)

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the status, indicating if the target is ready to return the requested data.

<nowiki>#</nowiki> The client reads GENERIC_DATA(0xDF) and gets the requested data.

The two bytes ''<nowiki>''Operation''</nowiki>'' seems to be made up of:

<nowiki>*</nowiki> MSB: an ''<nowiki>''operation type''</nowiki>''. An ''<nowiki>''operation type''</nowiki>'' groups operations that belong to the same functionality. Supported operation types are

<nowiki>**</nowiki> 0x00: ''<nowiki>''Loader''</nowiki>''

<nowiki>**</nowiki> 0x10: ''<nowiki>''Event''</nowiki>'' <nowiki><span style="color:red">?</span></nowiki>

<nowiki>**</nowiki> 0x20: ''<nowiki>''Metric''</nowiki>''<nowiki><span style="color:red">?</span></nowiki>

<nowiki>**</nowiki> 0x30: ''<nowiki>''Badge''</nowiki>''

<nowiki>**</nowiki> 0x40: ''<nowiki>''Time''</nowiki>''

<nowiki>**</nowiki> 0x50: ''<nowiki>''Config''</nowiki>''

<nowiki>*</nowiki> LSB: an ''<nowiki>''operation id''</nowiki>'' within the ''<nowiki>''operation type''</nowiki>''.

The two bytes ''<nowiki>''status''</nowiki>'' returned by GENERIC_STATUS(0xDE) is also coded on 2 bytes:

<nowiki>*</nowiki> MSB: the same ''<nowiki>''operation type''</nowiki>'' as for ''<nowiki>''Operation''</nowiki>''

<nowiki>*</nowiki> LSB: an ''<nowiki>''error id''</nowiki>'' within the ''<nowiki>''status''</nowiki>''.

'''== Loader operations =='''

'''=== Loader operation ids ==='''

These operations have no additional configuration data that is read or written Expected status codes are explained in <nowiki>[[#Loader status]]</nowiki>

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Description

|-

| 0x0001 || Start charging with the default settings

|-

| 0x0002 || Start charging Max

|-

<nowiki>|</nowiki> 0x0003 <nowiki>||</nowiki> Start charging Auto. What is this<nowiki><span style="color:red">?</span></nowiki>

|-

| 0x0004 || Start charging Eco

|-

| 0x0006 || Stop charging

|}

'''=== Loader status ==='''

Possible ''<nowiki>''Loader status''</nowiki>'' values are:

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Status

|-

| 0x0001 || UNLOCKED

|-

| 0x0002 || UNLOCKED_FORCE_MAX

|-

| 0x0003 || UNLOCKED_FORCE_ECO

|-

| Other || UNKNOWN

|}

'''== Event operations =='''

'''=== Event operation ids ==='''

Seems to deal with BLE events, not charging events. Can this be confirmed<nowiki><span style="color:red">?</span></nowiki>

Expected status codes are explained in <nowiki>[[#Event status]]</nowiki>

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Description

|-

| 0x1001 || NEXT

|-

| 0x1002 || UPDATE_STATUS

|}

'''=== Event status ==='''

Possible ''<nowiki>''Event status''</nowiki>'' values are:

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Status

|-

| 0x10nn || nn: the number of ''<nowiki>''remaining events''</nowiki>'' to read

|}

'''=== Event list operation ==='''

This operation starts the procedure for obtaining the event list.

The procedure is as follows:

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(NEXT (0x1001))

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the ''<nowiki>''remaining events''</nowiki>''.

<nowiki>#</nowiki> If the number of ''<nowiki>''remaining events''</nowiki>'' is 0, the procedure is complete. Client writes GENERIC_COMMAND(0xDD)(UPDATE_STATUS (0x1002)) <nowiki><span style="color:red">?</span></nowiki>

<nowiki>#</nowiki> If the number of ''<nowiki>''remaining events''</nowiki>'' is not 0, the client reads GENERIC_DATA(0xDF) and gets the data of the next event.

<nowiki>#</nowiki> Repeat top level step 2.

Can this be confirmed<nowiki><span style="color:red">?</span></nowiki>

'''== Metric operations =='''

'''=== Metric operation ids ==='''

Seems to deal with metrics. Which metrics<nowiki><span style="color:red">?</span></nowiki>

Expected status codes are explained in <nowiki>[[#Metric status]]</nowiki>

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Description

|-

| 0x2001 || NEXT

|-

| 0x2002 || UPDATE_STATUS

|}

'''=== Metric status ==='''

Possible ''<nowiki>''Metric status''</nowiki>'' values are:

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Status

|-

| 0x20nn || nn: the number of ''<nowiki>''remaining metrics''</nowiki>'' to read

|}

'''=== Metrics list operation ==='''

This operation starts the procedure for obtaining the metrics list.

The procedure is as follows:

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(NEXT (0x2001))

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the ''<nowiki>''remaining metrics''</nowiki>''.

<nowiki>#</nowiki> If the number of ''<nowiki>''remaining metrics''</nowiki>'' is 0, the procedure is complete. Client writes GENERIC_COMMAND(0xDD)(UPDATE_STATUS (0x2002)) <nowiki><span style="color:red">?</span></nowiki>

<nowiki>#</nowiki> If the number of ''<nowiki>''remaining metrics''</nowiki>'' is not 0, the client reads GENERIC_DATA(0xDF) and gets the data of the next metric.

<nowiki>#</nowiki> Repeat top level step 2.

Can this be confirmed<nowiki><span style="color:red">?</span></nowiki>

'''== Badge operations =='''

'''=== Badge operation ids ==='''

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Description

|-

| 0x3001 || Add badge in default charging mode

|-

| 0x3002 || Add badge in MAX charging mode

|-

| 0x3004 || Delete badge

|-

| 0x3005 || Badge list start

|-

| 0x3006 || Badge list next

|}

Expected status codes are explained in <nowiki>[[#Badge status]]</nowiki>

'''=== Badge status ==='''

Possible ''<nowiki>''Badge status''</nowiki>'' values are:

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Status

|-

| 0x3001 || WAIT_ADD

|-

| 0x3002 || WAIT_ADD

|-

| 0x3004|| WAIT_DELETE

|-

| 0x3005|| NEXT

|-

| 0x3007|| FINISH

|-

| 0x3008 || ADDED

|-

| 0x3009 || EXISTS

|-

| Other || UNKNOWN

|}

'''=== Add badge in default charging mode operation ==='''

This operation starts the procedure for adding a badge to the whitelist of the Nexxtender Home. The new badge will always load in the default charging mode. The whitelist is the list of badges allowed in Private mode.

The procedure is as follows:

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Add badge in default charging mode (0x3001))

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtains the status. If the status code is WAIT_ADD (0x3001), it indicates that the Nexxtender Home is waiting for the new badge to be presented by the user.

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtains one of the following

<nowiki>#*</nowiki> ADDED (0x3008), indicating that the new badge is presented and successfully added.

<nowiki>#*</nowiki> EXISTS(0x3009), indicating that the presented badge already existed in the Nexxtender Home. Nothing is changed<nowiki><span style="color:red">?</span></nowiki>

<nowiki>#*</nowiki> other, unknown error.

<nowiki>#</nowiki> In case of ADDED (0x3008), the client reads GENERIC_DATA(0xDF) and gets the data of the new badge.

The ISO 14443-3 UID of the added badge is returned. Depending on the UID length the following is returned.

4-byte UID:

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3 !! 4

|-

| UID length (4) || UID0 || UID1 || UID2 || UID3

|}

7-byte UID:

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7

|-

| UID length (4) || UID0 || UID1 || UID2 || UID3 || UID4 || UID5 || UID6

|}

10-byte UID:

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10

|-

| UID length (4) || UID0 || UID1 || UID2 || UID3 || UID4 || UID5 || UID6 || UID7 || UID8 || UID9

|}

The 7-byte version is in use on my Nexxtender Home. I don’t know if the 4-byte or 10-byte format is accepted.

'''=== Add badge in MAX charging mode operation ==='''

This operation starts the procedure for adding a badge to the Nexxtender Home. The new badge will always load in the MAX charging mode, independently of the default charging mode.

The procedure is exactly the same as for <nowiki>[[#Add badge in default charging mode operation]]</nowiki>, except that command ''<nowiki>''Add badge in default charging mode''</nowiki>'' (0x3001) is replaced with ''<nowiki>''Add badge in MAX charging mode''</nowiki>'' (0x3002). Also the status code WAIT_ADD (0x3001) is expected to be changed into WAIT_ADD (0x3002).

'''=== Delete Badge operation ==='''

This operation starts the procedure for deleting a badge from the badge whitelist of the Nexxtender Home.

The procedure is as follows:

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Delete badge (0x3004))

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, and obtains the status code WAIT_DELETE (x3004)

<nowiki>#</nowiki> The client writes a GENERIC_DATA(0xDF) with the identification of the badge that must be deleted. The format of the identification equals the one described in <nowiki>[[#Add badge in default charging mode operation]]</nowiki>.

<nowiki>#</nowiki> Do we need to wait for a notification on GENERIC_STATUS(0xDE) with a status code<nowiki><span style="color:red">?</span></nowiki>

'''=== Badge list operation ==='''

This operation starts the procedure for obtaining the badge whitelist of the Nexxtender Home.

The procedure is as follows:

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Badge list start (0x3005))

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change,and obtains the following status codes:

<nowiki>##</nowiki> FINISH (0x3007): indicating that the end of the list was reached. No data to be read from GENERIC_DATA(0xDF).

<nowiki>##</nowiki> NEXT (0x3005): indicating that one more badge is available

<nowiki>###</nowiki> The client reads GENERIC_DATA(0xDF) and gets the data of the badge. The returned format equals the one described in <nowiki>[[#Add badge in default charging mode operation]]</nowiki>. The context (Default or MAX charging mode) is apparently not returned.

<nowiki>###</nowiki> Client writes GENERIC_COMMAND(0xDD)(Badge list next (0x3006))

<nowiki>###</nowiki> Repeat top level step 2.

'''== Time operations =='''

'''=== Time operation ids ==='''

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Description

|-

| 0x4001 || Time Set

|-

| 0x4002 || Time Get

|}

Expected status codes are explained in <nowiki>[[#Time status]]</nowiki>

'''=== Time status ==='''

Possible ''<nowiki>''Time status''</nowiki>'' values are:

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Status

|-

| 0x4001 || READY

|-

| 0x4002 || SUCCESS

|-

| 0x4003 || POPPED

|-

| Other || UNKNOWN

|}

'''=== Time Set operation ==='''

This is an operation that writes the time.

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Time Set(0x4001))

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, and obtains the status code READY (0x4001), indicating that the generic data is ready to be written.

<nowiki>#</nowiki> The client writes a GENERIC_DATA(0xDF) with the time to set.

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, and obtains the status code SUCCESS (0x4002), indicating that the time was successfully written.

The time format is as follows

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3

|-

| colspan="4"|timestamp

|}

<nowiki>*</nowiki> Client ''<nowiki>''timestamp''</nowiki>'': Current time in <nowiki>[https://en.wikipedia.org/wiki/Unix_time Unix Time]</nowiki>. 4 byte unsigned integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

'''=== Time Get operation ==='''

This is an operation that reads the time.

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Time Get(0x4002))

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, and obtains the status code POPPED (0x4003), indicating that the generic data is ready to be read.

<nowiki>#</nowiki> The client reads GENERIC_DATA(0xDF) and gets the requested time.

The time format is as follows

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3

|-

| colspan="4"|timestamp

|}

<nowiki>*</nowiki> Client ''<nowiki>''timestamp''</nowiki>'': Current time in <nowiki>[https://en.wikipedia.org/wiki/Unix_time Unix Time]</nowiki>. 4 byte unsigned integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

'''== Config operations =='''

'''=== Config operation ids ==='''

These operations have additional configuration data to read or write. Depending on the status code, additional operations are send to set/get the configuration data.

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Description

|-

| 0x5001 || Config Set

|-

| 0x5002 || Config Get

|-

| 0x5003 || Config CBOR Set

|-

| 0x5004|| Config CBOR Get

|}

Expected status codes are explained in <nowiki>[[#Config status]]</nowiki>

'''=== Config Status ==='''

Possible ''<nowiki>''Config status''</nowiki>'' values are:

<nowiki>{| class="wikitable"</nowiki>

|-

! Value !! Status

|-

| 0x5001 || READY (after a Config Set)

|-

| 0x5002 || SUCCESS (after a Config set)

|-

| 0x5003 || POPPED (after a Config Get)

|-

| 0x5004 || READY (after a Config CBOR Set)

|-

| 0x5005 || SUCCESS (after a Config CBOR set)

|-

| 0x5006 || POPPED (after a Config CBOR Get)

|-

| Other || UNKNOWN

|}

'''=== Config Set operation ==='''

This is an operation that writes a value.

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Config Set(0x5001))

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the status code READY (0x5001), indicating that the generic data is ready to be written.

<nowiki>#</nowiki> The client writes a GENERIC_DATA(0xDF) with the actual data that must be written for Config Set.

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the status code SUCCESS (0x5002), indicating that the data was successfully written.

The following configuration data can be changed

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3 !! 4

|-

| maxGrid || maxDevice || mode || colspan="2" | crc16

|}

<nowiki>*</nowiki> ''<nowiki>''maxGrid''</nowiki>'': see <nowiki>[[#Config_1_1]]</nowiki>. 1 byte unsigned integer.

<nowiki>*</nowiki> ''<nowiki>''maxDevice''</nowiki>'': see <nowiki>[[#Config_1_1]]</nowiki>. 1 byte unsigned integer.

<nowiki>*</nowiki> ''<nowiki>''mode''</nowiki>'': see <nowiki>[[#Config_1_1]]</nowiki>. 1 byte unsigned integer.

<nowiki>*</nowiki> crc16: CRC-16/MODBUS over previous 3 bytes. 2 bytes.

'''=== Config CBOR Set operation ==='''

This is an operation that writes a value. It is similar to <nowiki>[[#Config Set operation]]</nowiki>, but the input is in CBOR format.

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Config CBOR Set(0x5003))

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the status code READY (0x5004), indicating that the generic data is ready to be written.

<nowiki>#</nowiki> The client writes a GENERIC_DATA(0xDF) with the actual data that must be written for Config Set.

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the status code SUCCESS (0x5005), indicating that the data was successfully written.

In config CBOR, a CBOR coded array of elements is used, with additionally 2 bytes at the end with the crc over the preceding CBOR array. The following fields can be included. See <nowiki>[[#Config CBOR Set operation]]</nowiki> for their explanation.

<nowiki>*</nowiki> 1: ''<nowiki>''chargeMode''</nowiki>''

<nowiki>*</nowiki> 4: ''<nowiki>''iMax''</nowiki>''

<nowiki>*</nowiki> 5: ''<nowiki>''iEvseMax''</nowiki>''

<nowiki>*</nowiki> 7: ''<nowiki>''iLevel1''</nowiki>''

<nowiki>*</nowiki> 9: ''<nowiki>''phaseSeq''</nowiki>''

<nowiki>*</nowiki> 12: ''<nowiki>''touWeekStart''</nowiki>''

<nowiki>*</nowiki> 13: ''<nowiki>''touWeekStop''</nowiki>''

<nowiki>*</nowiki> 14: ''<nowiki>''touWeekendStart''</nowiki>''

<nowiki>*</nowiki> 15: ''<nowiki>''touWeekendStop''</nowiki>''

<nowiki>*</nowiki> 19: ''<nowiki>''iCapacity''</nowiki>''

'''=== Config Get operation ==='''

This is an operation that reads a value. The expected success scenario is as follows:

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Config Get(0x5002))

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the status code POPPED (0x5003), indicating that the generic data is ready to be read.

<nowiki>#</nowiki> The client reads GENERIC_DATA(0xDF) and gets the requested data.

The requested data can be in 2 formats: Config_1_0 or Config_1_1, probably according to the age of teh loader.

'''==== Config_1_0 ===='''

In Config_1_0, 13 bytes related to the the configuration are returned.

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 12

|-

| maxGrid || mode || safe || colspan="2" | touWeekStart || colspan="2" | touWeekEnd || colspan="2" | touWeekendStart || colspan="2" | touWeekendEnd || colspan="2" | crc16 ||

|}

<nowiki>*</nowiki> ''<nowiki>''maxGrid''</nowiki>'': Peak grid consumption limit in A. 1 byte unsigned integer. Set this to a lower values if you have a peak tariff contract.

<nowiki>*</nowiki> ''<nowiki>''mode''</nowiki>'' : the default charging mode.

<nowiki>**</nowiki> 0: ECO_PRIVATE

<nowiki>**</nowiki> 1: MAX_PRIVATE

<nowiki>**</nowiki> 4: ECO_OPEN

<nowiki>**</nowiki> 5: MAX_OPEN

<nowiki>**</nowiki> others: Unkown/Error

<nowiki>*</nowiki> ''<nowiki>''safe''</nowiki>'' : <nowiki><span style="color:red">?</span></nowiki>

<nowiki>*</nowiki> ''<nowiki>''touWeekStart''</nowiki>'': off peak weekdays start time. Start time of each weekday in minutes since midnight. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> ''<nowiki>''touWeekEnd''</nowiki>'': off peak weekdays end time. End time of each weekday in minutes since midnight. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> ''<nowiki>''touWeekendStart''</nowiki>'': off peak weekend start time. Start time of each weekend day in minutes since midnight. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> ''<nowiki>''touWeekendEnd''</nowiki>'': off peak weekend end time. End time of each weekend day in minutes since midnight. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

'''==== Config_1_1 ===='''

In Config_1_1, 15 bytes related to the configuration are returned.

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 12 !! 13 !! 14

|-

| maxGrid || maxDevice || mode || safe || networkType || colspan="2" | touWeekStart || colspan="2" | touWeekEnd || colspan="2" | touWeekendStart || colspan="2" | touWeekendEnd || colspan="2" | crc16 ||

|}

<nowiki>*</nowiki> ''<nowiki>''maxGrid''</nowiki>'': Peak grid consumption limit in A. 1 byte unsigned integer. Set this to a lower values if you have a peak tariff contract.

<nowiki>*</nowiki> ''<nowiki>''maxDevice''</nowiki>'': maximum charging speed in A for the device. 1 byte unsigned integer.

<nowiki>*</nowiki> ''<nowiki>''mode''</nowiki>'' : the default charging mode. Bit 0 seems to code Eco/Max. Bit 2 seems to code Open/Private.

<nowiki>**</nowiki> 0: ECO_PRIVATE

<nowiki>**</nowiki> 1: MAX_PRIVATE

<nowiki>**</nowiki> 4: ECO_OPEN

<nowiki>**</nowiki> 5: MAX_OPEN

<nowiki>**</nowiki> others: Unkown/Error

<nowiki>*</nowiki> ''<nowiki>''safe''</nowiki>'' : offload minimum<nowiki><span style="color:red">?</span></nowiki>

<nowiki>*</nowiki> ''<nowiki>''networkType''</nowiki>'': bit coded byte. bit 1 coded the Connection type:

<nowiki>**</nowiki> 0x0: Mono/Tri+N

<nowiki>**</nowiki> 0x1: Tri

<nowiki>*</nowiki> ''<nowiki>''touWeekStart''</nowiki>'': off peak weekdays start time. Start time of each weekday in minutes since midnight. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> ''<nowiki>''touWeekEnd''</nowiki>'': off peak weekdays end time. End time of each weekday in minutes since midnight. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> ''<nowiki>''touWeekendStart''</nowiki>'': off peak weekend start time. Start time of each weekend day in minutes since midnight. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> ''<nowiki>''touWeekendEnd''</nowiki>'': off peak weekend end time. End time of each weekend day in minutes since midnight. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

'''=== Config CBOR Get operation ==='''

This is an operation that reads a value. It is similar to <nowiki>[[#Config Get operation]]</nowiki>, but the output is in CBOR format.

The expected success scenario is as follows:

<nowiki>#</nowiki> Client writes GENERIC_COMMAND(0xDD)(Config CBOR Get(0x5004))

<nowiki>#</nowiki> Client reads GENERIC_STATUS(0xDE) when notified of a change, obtaining the status code POPPED (0x5006), indicating that the generic data

<nowiki>#</nowiki> The client reads GENERIC_DATA(0xDF) and gets the requested data.

In config CBOR, a CBOR coded array of elements is returned, with additionally 2 bytes at the end with the crc over the preceding CBOR array. The following fields can be included when read: See also the previous section:

<nowiki>*</nowiki> 1: ''<nowiki>''chargeMode''</nowiki>'', see ''<nowiki>''Mode''</nowiki>'' in <nowiki>[[#Config_1_1]]</nowiki>

<nowiki>*</nowiki> 2: ''<nowiki>''modbusSlaveAddress''</nowiki>'', not used.

<nowiki>*</nowiki> 3: ''<nowiki>''cycleRate''</nowiki>'', not used.

<nowiki>*</nowiki> 4: ''<nowiki>''iMax''</nowiki>'', see ''<nowiki>''maxGrid''</nowiki>'' in <nowiki>[[#Config_1_1]]</nowiki>

<nowiki>*</nowiki> 5: ''<nowiki>''iEvseMax''</nowiki>'', see ''<nowiki>''maxDevice''</nowiki>'' in <nowiki>[[#Config_1_1]]</nowiki>

<nowiki>*</nowiki> 6: ''<nowiki>''iEvseMin''</nowiki>'', minimum charging speed in A for the device (also called minDevice)

<nowiki>*</nowiki> 7: ''<nowiki>''iLevel1''</nowiki>'', see ''<nowiki>''safe''</nowiki>'' in <nowiki>[[#Config_1_1]]</nowiki>

<nowiki>*</nowiki> 8: ''<nowiki>''solarMode''</nowiki>'', not used.

<nowiki>*</nowiki> 9: ''<nowiki>''phaseSeq''</nowiki>'',see ''<nowiki>''networkType''</nowiki>'' in <nowiki>[[#Config_1_1]]</nowiki>

<nowiki>*</nowiki> 10: ''<nowiki>''chargingPhases''</nowiki>'', not used.

<nowiki>*</nowiki> 11: ''<nowiki>''blePin''</nowiki>'', not used.

<nowiki>*</nowiki> 12: ''<nowiki>''touWeekStart''</nowiki>'', see ''<nowiki>''touWeekStart''</nowiki>'' in <nowiki>[[#Config_1_1]]</nowiki>

<nowiki>*</nowiki> 13: ''<nowiki>''touWeekStop''</nowiki>'', see ''<nowiki>''touWeekStop''</nowiki>'' in <nowiki>[[#Config_1_1]]</nowiki>

<nowiki>*</nowiki> 14: ''<nowiki>''touWeekendStart''</nowiki>'', see ''<nowiki>''touWeekendStart''</nowiki>'' in <nowiki>[[#Config_1_1]]</nowiki>

<nowiki>*</nowiki> 15: ''<nowiki>''touWeekendStop''</nowiki>'', see ''<nowiki>''touWeekendStop''</nowiki>'' in <nowiki>[[#Config_1_1]]</nowiki>

<nowiki>*</nowiki> 16: ''<nowiki>''timezone''</nowiki>'', not used.

<nowiki>*</nowiki> 17: ''<nowiki>''relayOffPeriod''</nowiki>'', not used.

<nowiki>*</nowiki> 18: ''<nowiki>''externalRegulation''</nowiki>'', not used.

<nowiki>*</nowiki> 19: ''<nowiki>''iCapacity''</nowiki>'', <nowiki><span style="color:red">?</span></nowiki>

'''= CDR characteristics ='''

The following Characteristics of the ''<nowiki>''CDR''</nowiki>'' service (also known as Transaction Service) are used.

'''<nowiki>'''Note'''</nowiki>''': If the BLEGatt device is considered as “generic”, these characteristics are send under the ''<nowiki>''Generic''</nowiki>'' (C1) service instead of the ''<nowiki>''CDR''</nowiki>'' (C1) service. Unclear to me when that happens<nowiki><span style="color:red">?</span></nowiki>

<nowiki>{| class="wikitable"</nowiki>

|-

! UUID !! Name !! Readable !! Writable !! Writable Without Response !! Notify !! Coding

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''c2'''</nowiki>''' || CDR_COMMAND || || x || || || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''c3'''</nowiki>''' || CDR_STATUS || x || || || x || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''c4'''</nowiki>''' || CDR_RECORD || x || || || || ||

|}

CDR_COMMAND(0xC2), CDR_STATUS(0xC3) and CDR_DATA(0xC4) work together to load transaction records from the charger. For each record to read, the client writes a CDR_COMMAND(0xC2) to read the next, waits for the correct CDR_STATUS(0xC3) and then reads the next record using CDR_DATA(0xC4).

'''= CCDT characteristics ='''

The following Characteristics of the ''<nowiki>''CCDT''</nowiki>'' service are used.

'''<nowiki>'''Note'''</nowiki>''': If the BLEGatt device is considered as “generic”, these characteristics are send under the ''<nowiki>''Generic''</nowiki>'' (C1) service instead of the ''<nowiki>''CCDT''</nowiki>'' (C5) service. Unclear to me when that happens<nowiki><span style="color:red">?</span></nowiki>

<nowiki>{| class="wikitable"</nowiki>

|-

! UUID !! Name !! Readable !! Writable !! Writable Without Response !! Notify !! Coding

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''c5'''</nowiki>''' || CCDT || || || || || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''c6'''</nowiki>''' || CCDT_COMMAND || || x || || || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''c7'''</nowiki>''' || CCDT_STATUS || x || || || x || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''c8'''</nowiki>''' || CDDT_RECORD || x || || || || ||

|}

'''= Firmware characteristics ='''

The following Characteristics of the ''<nowiki>''Firmware''</nowiki>'' service are used.

'''<nowiki>'''Note'''</nowiki>''': If the BLEGatt device is considered as “generic”, these characteristics are send under the ''<nowiki>''Generic''</nowiki>'' (C1) service instead of the ''<nowiki>''Firmware''</nowiki>'' (C9) service. Unclear to me when that happens<nowiki><span style="color:red">?</span></nowiki>

<nowiki>{| class="wikitable"</nowiki>

|-

! UUID !! Name !! Readable !! Writable !! Writable Without Response !! Notify !! Coding

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''ca'''</nowiki>''' || FIRMWARE_COMMAND || || x || || || ||

|-

|fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''cb'''</nowiki>''' || FIRMWARE_STATUS || x || || || x || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''cc'''</nowiki>''' || FIRMWARE_WANTED_CHUNK || x || || || x || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''cc'''</nowiki>''' || FIRMWARE_DATA_CHUNK || || x || || || ||

|}

'''== Charging characteristics =='''

The following Characteristics of the ''<nowiki>''Charging''</nowiki>'' service are used.

'''<nowiki>'''Note'''</nowiki>''': If the BLEGatt device is considered as “generic”, these characteristics are send under the ''<nowiki>''Generic''</nowiki>'' (C1) service instead of the ''<nowiki>''Charging''</nowiki>'' (CE) service. Unclear to me when that happens<nowiki><span style="color:red">?</span></nowiki>

<nowiki>{| class="wikitable"</nowiki>

|-

! UUID !! Name !! Readable !! Writable !! Writable Without Response !! Notify !! Coding

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''cf'''</nowiki>''' || CHARGING_BASIC_DATA || x || || || x || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''d0'''</nowiki>''' || CHARGING_GRID_DATA || x || || || x || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''da'''</nowiki>''' || CHARGING_CAR_DATA || x || || || x || ||

|-

| fd47416a-95fb-4206-88b5-b4a8045f75<!-- -->'''<nowiki>'''db'''</nowiki>''' || CHARGING_ADVANCED_DATA || x || || || x || ||

|}

'''== CHARGING_BASIC_DATA (0xCF) =='''

Returns 16 bytes

The 16 bytes are structured as follows.

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3 !!4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 12 !! 13 !! 14 !! 15 !!

|-

| colspan="2" | seconds || discriminator || status || colspan="4" | RFU || colspan="4" | energy || RFU || phasecount || colspan="2" | RFU

|}

<nowiki>*</nowiki> Charging ''<nowiki>''seconds''</nowiki>'': number of seconds since start of charging<nowiki><span style="color:red">?</span></nowiki> 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Charging ''<nowiki>''discriminator''</nowiki>'' state: Unsigned byte.

According to <nowiki><ref name=ref1>https://github.com/geertmeersman/nexxtender </ref></nowiki>, the following values are supported:

<nowiki>**</nowiki> 1: Started

<nowiki>**</nowiki> 2: Charging

<nowiki>**</nowiki> 3: Stopped

<nowiki>**</nowiki> Others: Unknown

<nowiki>*</nowiki> Charging ''<nowiki>''status''</nowiki>'': Unsigned byte. According to <nowiki><ref name="ref1" /></nowiki>, the following values are supported:

<nowiki>**</nowiki> ‘B’: Plugged

<nowiki>**</nowiki> ‘C’ <nowiki>&</nowiki>amp; ‘D’: Charging

<nowiki>**</nowiki> ‘E’ <nowiki>&</nowiki>amp; ‘F’: Fault

<nowiki>**</nowiki> Others: Unplugged/Unknown

<nowiki>*</nowiki> Charging ''<nowiki>''energy''</nowiki>'': Total energy in Wh charged during this session<nowiki><span style="color:red">?</span></nowiki> 4 byte unsigned integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Charging ''<nowiki>''phasecount''</nowiki>'': Charging Phase Count. Unsigned byte.

'''== CHARGING_GRID_DATA (0xD0) =='''

Returns 16 bytes related to the current electrical current on the grid. This is the current as measured by the 3 Current Transformers (CT). The 16 bytes are structured as follows.

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3 !!4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 12 !! 13 !! 14 !! 15 !!

|-

| colspan="4" | timestamp || colspan="2" | L1 || colspan="2" | L2 || colspan="2" | L3 || colspan="2" | consumed || colspan="2" | interval ||colspan="2" | crc16 ||

|}

<nowiki>*</nowiki> Grid ''<nowiki>''timestamp''</nowiki>'': Current time in <nowiki>[https://en.wikipedia.org/wiki/Unix_time Unix Time]</nowiki>. 4 byte unsigned integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Grid ''<nowiki>''L1''</nowiki>'': Phase L1 current in dA. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Grid ''<nowiki>''L2''</nowiki>'': Phase L2 current in dA. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Grid ''<nowiki>''L3''</nowiki>'': Phase L3 current in dA. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Grid ''<nowiki>''consumed''</nowiki>'': Total power consumption from the grid in Watt<nowiki><span style="color:red">?</span></nowiki> 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Grid ''<nowiki>''interval''</nowiki>'': 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>. Unclear what it is. According to <nowiki><ref name="ref1" /></nowiki> it <nowiki>&</nowiki>gt; is a counter that goes from 0-<nowiki>&</nowiki>gt;900 (15 minutes)

<nowiki>*</nowiki> crc16: CRC-16/MODBUS over previous 14 bytes. 2 bytes.

Example hexadecimal return value <nowiki><code>26 45 2A 66 00 00 00 00 00 00 36 00 EA 02 C6 25</code></nowiki>

'''== CHARGING_CAR_DATA (0xDA) =='''

Returns 16 bytes related to the current electrical current towards the car. This is the current as provided by the charger to the car. The 16 bytes are structured as follows.

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3 !!4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 12 !! 13 !! 14 !! 15 !!

|-

| colspan="4" | timestamp || colspan="2" | L1 || colspan="2" | L2 || colspan="2" | L3 || colspan="2" | P1 || colspan="2" | P2 ||colspan="2" | P3 ||

|}

<nowiki>*</nowiki> Car ''<nowiki>''timestamp''</nowiki>'': Current time in <nowiki>[https://en.wikipedia.org/wiki/Unix_time Unix Time]</nowiki>. 4 byte unsigned integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Car ''<nowiki>''L1''</nowiki>'': Phase L1 current in dA. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Car ''<nowiki>''L2''</nowiki>'': Phase L2 current in dA. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Car ''<nowiki>''L3''</nowiki>'': Phase L3 current in dA. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Car ''<nowiki>''P1''</nowiki>'': Phase L1 power consumption from the car in Watt. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Car ''<nowiki>''P2''</nowiki>'': Phase L2 power consumption from the car in Watt. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Car ''<nowiki>''P3''</nowiki>'': Phase L3 power consumption from the car in Watt. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

'''== CHARGING_ADVANCED_DATA (0xDB) =='''

Returns 18 bytes related to the advanced charging data. The 18 bytes are structured as follows.

<nowiki>{| class="wikitable"</nowiki>

|-

! 0 !! 1 !! 2 !! 3 !!4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 12 !! 13 !! 14 !! 15 !! 16 !! 17 !!

|-

| colspan="4" | timestamp || colspan="2" | iAvailable || colspan="4" | gridPower || colspan="4" | carPower || authorizationStatus || errorCode || colspan="4" | crc16 ||

|}

<nowiki>*</nowiki> Advanced ''<nowiki>''timestamp''</nowiki>'': Current time in <nowiki>[https://en.wikipedia.org/wiki/Unix_time Unix Time]</nowiki>. 4 byte unsigned integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Advanced ''<nowiki>''iAvailable''</nowiki>'': Available capacity in A. 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Advanced ''<nowiki>''gridPower''</nowiki>'': total power consumption from the grid in Watt. What is the difference with Grid ''<nowiki>''consumed''</nowiki>''<nowiki><span style="color:red">?</span></nowiki> 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Advanced ''<nowiki>''carPower''</nowiki>'': total power consumption from the car in Watt. Is this the sum of Car ''<nowiki>''P1''</nowiki>'', ''<nowiki>''P2''</nowiki>'' and ''<nowiki>''P3''</nowiki>''<nowiki><span style="color:red">?</span></nowiki> 2 byte signed integer in <nowiki>[https://en.wikipedia.org/wiki/Endianness little-endian]</nowiki>.

<nowiki>*</nowiki> Advanced ''<nowiki>''authorizationStatus''</nowiki>'': Unsigned byte with following bit coding:

<nowiki>{| class="wikitable"</nowiki>

|-

! 7 !! 6 !! 5 !! 4 !! 3 !! 2 !! 1 !! 0 !! Authorizaton Status Authorizaton Status Authorizaton Status Authorizaton Status !!

|-

| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || Unauthorized ||

|-

| 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || Authorized default ||

|-

| 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || Charge stopped in app ||

|-

| 0 || 0 || 0 || 1 || 0 || 0 || 0 || 0 || Charge paused ||

|-

| 0 || 0 || 1 || 0 || 0 || 0 || 1 || 0 || Authorized MAX ||

|-

| 0 || 1 || 0 || 0 || 0 || 0 || 1 || 0 || Authorized ECO ||

|-

| x || x || x || x || x || x || x || x || Any other value: Unknown ||

|-

|}

<nowiki>*</nowiki> Advanced ''<nowiki>''errorCode''</nowiki>'': Error code returned by the Nexxtender Home. Values unknown. Unsigned byte.

<nowiki>*</nowiki> ''<nowiki>''crc16''</nowiki>'' : CRC-16/MODBUS over previous 16 bytes. 2 bytes.

'''= Examples Values ='''

'''== When no charging occurs =='''

Using the LightBlue app I read the following values:

<nowiki><pre>&</nowiki>gt; C3: HEX 00 00 00 00

&amp;gt; C4: HEX 00 00 00 00 F1 96 27 66 53 8D 13 00 00 00 00 00 00 00 00 00 2D C0 27 66 98 DE 13 00 60 00 B7 00

&amp;gt; C7: HEX 00 00 00 00

&amp;gt; C8: HEX 2D C0 27 66 98 DE 13 00 00 00 60 00 00 00 1A FB

&amp;gt; CB: HEX 10 FF CD AB 78 56 34 12

&amp;gt; CC: HEX 00 00

&amp;gt; CF: HEX 00 00 03 00 00 00 00 00 00 00 00 00 00 00

&amp;gt; D0: HEX FB 0E 2D 66 00 00 00 00 00 00 37 00 13 03 88 14

&amp;gt; DA: HEX 2E 0F 2D 66 00 00 00 00 00 00 00 00 00 00 00 00 C9 03

&amp;gt; DB: HEX 66 0F 2D 66 06 00 FE FF FF FF 00 00 00 00 01 00 97 64

&amp;gt; DE: HEX 01 00

<nowiki>&</nowiki>gt; DF: HEX 2D C0 27 66 02 01 01 00 00 00 00 00 00 00 00 00 00 00 F9 <nowiki></pre></nowiki>

'''= Plantuml test ='''

<nowiki>[[File:doc/diagrams/firstDiagram.svg]]</nowiki>

'''= Mermaid Test ='''

```mermaid

flowchart

subgraph "`**Power**`"

direction TB

Grid[fa:fa-bolt Power Grid] <-->|Pfa:fa-bolt|B(( ))

B -->|Pfa:fa-house| Home[fa:fa-house Home ]

Solar[fa:fa-solar-panel Solar Panels]-->|Pfa:fa-solar-panel| B

B -->|Pfa:fa-charging-station| Charger[fa:fa-charging-station Nexxtender Home Charger]

Charger -->|Pfa:fa-car| Car[fa:fa-car EV]

end

subgraph "`**Control**`"

direction TB

Charger<-.->|<nowiki><i class="fa-brands fa-bluetooth"></i></nowiki> BLE| Nexxtmove[fa:fa-mobile-screen Nexxtmove app]

Nexxtmove <-.->|fa:fa-globe Internet| Nexxtmove.me[fa:fa-globe www.Nexxtmove.me]

Charger o-.-o|fa:fa-nfc-symbol RF|Badge[fa:fa-credit-card Badge]

end

%% Force better placing with invisible link

<nowiki>Car ~~~ Nexxtmove</nowiki>

<nowiki>Car ~~~ Badge</nowiki>

```

'''= Record handling ='''

Kind of records can be CDR, CCDT, EVENT, METRIC, CONFIG, BASIC_DATA. Each record contains: kind, serialNumber, firmwareVersion and payload.

<nowiki><pre>+ AbstractBLEService</nowiki>

+ AbstractBLERecordService

+ BLEIndexService (CCDT)

+ BLETransactionService (CDR)

+ AbstractBLEGenericService

+ AbstractBLELogService

+ BLEEventService

+ BLEMetricService<nowiki></pre></nowiki>

AbstractBLERecordService seems to use 3 registers: COMMAND, STATUS and RECORD. For each record to read, the client writes a COMMAND to read the next, waits for the correct STATUS and then reads the next record from RECORD. My guess is that the UPDATE_STATUS comand indictaes to the device that all records are correctly downloaded and can be removed from the device<nowiki><span style="color:red">?</span></nowiki>

'''= Notes ='''

<nowiki><references /></nowiki>

Revision as of 15:45, 26 June 2024

Edit this page

This "sandbox" page is to allow you to carry out experiments. Please feel free to try your skills at formatting here. If you want to learn more about how to edit a wiki, please read this introduction or the tutorial at Wikipedia. This Sandbox is for the classic editing interface. You can also perform test edits to Structured Discussions/Sandbox. There's also a Sandbox for the VisualEditor.

To edit, click here or "Edit" at the top of the page, make your changes in the dialog box, and click the "Publish changes…" button when you are finished. Please do not add material that is any way offensive, that is copyrighted, or that is at all libelous.

Content added here will not stay permanently; this page is cleared regularly.

Edit

Testing Area

Retrieved from "https://www.mediawiki.org/w/index.php?title=Project:Sandbox&oldid=6604437"