everest / everest-core Goto Github PK
View Code? Open in Web Editor NEWLicense: Apache License 2.0
License: Apache License 2.0
Hi,
we have tested the lastest everest-core 2024.01 and accidentially configured a meter on our Tarragon platform, which is not available via Modbus. After the start of EVerest the whole log is flooded (multiple times per second) by error messages from serialcommhub_x, which cause eMMC wearout:
Feb 01 13:53:51 tarragon manager[539]: 2024-02-01 13:53:51.074076 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:51 tarragon manager[539]: 2024-02-01 13:53:51.293540 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:51 tarragon manager[539]: 2024-02-01 13:53:51.423442 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:51 tarragon manager[539]: 2024-02-01 13:53:51.553456 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:52 tarragon manager[539]: 2024-02-01 13:53:52.733426 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:52 tarragon manager[539]: 2024-02-01 13:53:52.863485 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:52 tarragon manager[539]: 2024-02-01 13:53:52.993451 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.203441 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.333437 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.463633 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.673413 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.803650 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Feb 01 13:53:53 tarragon manager[539]: 2024-02-01 13:53:53.933530 [ERRO] serialcommhub_x std::vector<short unsigned int> tiny_modbus::decode_reply(const uint8_t*, int, uint8_t, tiny_modbus::FunctionCode) :: Packet too small: 3 bytes.
Expected behavior:
Such communication issues shouldn't be handled by the modbus library. It would be better to let upper layer handle the issue.
Example:
EVerest Modbus module detects that connection to Modbus slave has been lost. Module logs the event of disconnect and a possible reason. In case the connection to the Modbus slave has been re-established again the EVerest Modbus module the re-connect should be logged.
active_modules:
api:
module: API
connections:
evse_manager:
- module_id: connector
implementation_id: evse
tarragon_bsp:
module: CbTarragonDriver
config_module:
contactor_1_feedback_type: nc
relay_2_name: none
tarragon_pluglock:
module: CbTarragonPlugLock
serialcommhub_x7:
module: SerialCommHub
config_implementation:
main:
serial_port: /dev/ttymxc0
ignore_echo: true
powermeter:
module: GenericPowermeter
config_implementation:
main:
model: Eastron_SDM72DM-V2
powermeter_device_id: 1
connections:
serial_comm_hub:
- module_id: serialcommhub_x7
implementation_id: main
serialcommhub_x8:
module: SerialCommHub
config_implementation:
main:
serial_port: /dev/ttymxc4
ignore_echo: true
connector:
module: EvseManager
config_module:
connector_id: 1
has_ventilation: false
disable_authentication: true
connections:
bsp:
- module_id: tarragon_bsp
implementation_id: evse_board_support
connector_lock:
- module_id: tarragon_pluglock
implementation_id: connector_lock
powermeter_grid_side:
- module_id: powermeter
implementation_id: main
energy_manager:
module: EnergyManager
connections:
energy_trunk:
- module_id: grid_connection_point
implementation_id: energy_grid
grid_connection_point:
module: EnergyNode
config_module:
fuse_limit_A: 16
phase_count: 3
connections:
energy_consumer:
- implementation_id: energy_grid
module_id: connector
The UK smart charging regulations require a random delay whenever the charging current changes, either because of a start/stop of charging or if the current is adapted during charging (e.g. from 16 to 8 amps or 8 amps to 16 amps). The delay needs to be adjustable and should default to 600 seconds.
There are excemptions when the delay requirement does not apply, i.e. whenever the reason for the current change event itself was already sufficiently random.
The idea behind this is that all reasons for changing grid load that are synchronized over larger areas could cause problems in the power grid. E.g. When power comes back after a blackout not all EVs should start charging at the same time. But also a schedule coming from OCPP that is based on price signals is synchronized with many chargers and needs to have a random delay.
Finding out the root cause for a requested current change and verify whether it is already random or not is beyond the scope of everest-core. We should however implement helper functionality to enable those random delays and give external processes the possibility to cancel/enable/disable them.
The Power Meter Bauer BSM-WS36A issues the signed meter values on both start transaction and stop transaction.
To handle it the EvseManager should start the transaction on power meter and wait for the signed meter values.
Additionally: we experienced large waiting times on the Bauer BSM-WS36A meter, that may lead to unexpected behavior when requesting the signed meter synchronously. So the transaction on the meter should start asynchronously to the Auth<->OCPP<->evse_manager interactions.
I'll create a draft PR with some Ideas how to implement it.
Version:
2024.2.0
Module config:
config_module:
connection_timeout: 20
prioritize_authorization_over_stopping_transaction: true
selection_algorithm: PlugEvents
connections:
evse_manager:
- module_id: connector_1
implementation_id: evse
- module_id: connector_2
implementation_id: evse
Describe the problem:
In case when a plug is plugged-in and plugged-out without performing an authorization via RFID, the connector remains in the plug_in_queue although it has already been unplugged. As a result, the plug-selection-algorithm, bases on "PlugEvents", detects the unplugged connector and authorize it for charging when a RFID card is presented, without any plugged-in connectors.
How to reproduce:
Expectation:
The authoziation should not be assigned to any connector until one of them is plugged in.
Describe your solution:
Remove connector ID from list in case "SessionFinished" event has been received
Additional context:
--
As far as I can see the re is no way to send command WRITE_SINGLE_REGISTER to the Modbus device.
Theoretically, it it could be done by "write multiple registers" with count 1. But behaviour of the remote device can be different depending on command that is used.
To my knowledge some functionality of Iskra meter can be only used with WRITE_SINGLE_REGISTER command.
Is it recommended that we copy binaries from build/dist/bin
to ~/.local/bin
since it has already been added to the path?
If so, should it be reflected in the documentation?
using curl
as the target name works, but we should probably define the ALIAS target ourselves if it's missing
At the moment some wifi related operations are still periodically triggered, even if setup_wifi is set to false in the module config.
This can result in messages like:
Failed to connect to non-global ctrl_ifname: <INTERFACE_NAME> error: Permission denied
When running latest build of Everest-core (commit fb24707) and an OCPP server using OCPP 2.0.1, Everest crashes when receiving an InstallCertificate call with an invalid certificate_type value. In this case, an empty string:
InstallCertificate(certificate_type='', certificate='-----BEGIN CERTIFICATE-----\nMIIBwzCCAWigAwIBAgICMDkwCgYIKoZIzj0EAwIwSDESMBAGA1UEAwwJVjJHUm9v\ndENBMRAwDgYDVQQKDAdFVmVyZXN0MQswCQYDVQQGEwJERTETMBEGCgmSJomT8ixk\nARkWA1YyRzAeFw0yMzEwMjcxMzEwNDdaFw0yNDEwMjYxMzEwNDdaMEgxEjAQBgNV\nBAMMCVYyR1Jvb3RDQTEQMA4GA1UECgwHRVZlcmVzdDELMAkGA1UEBhMCREUxEzAR\nBgoJkiaJk/IsZAEZFgNWMkcwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR8yvxy\nBJNJh0WHbOLqgWp4JRNeuKPQid2Ha255X9w/Xc5bFDQG9AacXr3ED/MOdFqSQi/8\nzS1Ez82SbqH9U3xRo0IwQDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIB\nBjAdBgNVHQ4EFgQUDE1ff14OrOE2RsHt9Rg/L6WKrXwwCgYIKoZIzj0EAwIDSQAw\nRgIhAIwKjJ+kafFE0ETE6s9ffmoD6OWX+cnGVySu4bCkSTBLAiEAxJGgTDUdMQK/\ngP+u0NMyffVs8TH/BGgleeieAHDo2Fo=\n-----END CERTIFICATE-----\n', custom_data=None)
Everest logs:
2024-04-20 13:55:56.743403 [INFO] ocpp:OCPP201 :: Received message over TLS websocket polling for process: [2,"314c960a-0a98-401c-87db-45b45f0041d6","InstallCertificate",{"certificateType":"","certificate":"-----BEGIN CERTIFICATE-----\nMIIBwzCCAWigAwIBAgICMDkwCgYIKoZIzj0EAwIwSDESMBAGA1UEAwwJVjJHUm9v\ndENBMRAwDgYDVQQKDAdFVmVyZXN0MQswCQYDVQQGEwJERTETMBEGCgmSJomT8ixk\nARkWA1YyRzAeFw0yMzEwMjcxMzEwNDdaFw0yNDEwMjYxMzEwNDdaMEgxEjAQBgNV\nBAMMCVYyR1Jvb3RDQTEQMA4GA1UECgwHRVZlcmVzdDELMAkGA1UEBhMCREUxEzAR\nBgoJkiaJk/IsZAEZFgNWMkcwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAR8yvxy\nBJNJh0WHbOLqgWp4JRNeuKPQid2Ha255X9w/Xc5bFDQG9AacXr3ED/MOdFqSQi/8\nzS1Ez82SbqH9U3xRo0IwQDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIB\nBjAdBgNVHQ4EFgQUDE1ff14OrOE2RsHt9Rg/L6WKrXwwCgYIKoZIzj0EAwIDSQAw\nRgIhAIwKjJ+kafFE0ETE6s9ffmoD6OWX+cnGVySu4bCkSTBLAiEAxJGgTDUdMQK/\ngP+u0NMyffVs8TH/BGgleeieAHDo2Fo=\n-----END CERTIFICATE-----\n"}]
2024-04-20 13:55:56.743863 [INFO] ocpp:OCPP201 :: Successfully sent last message over TLS websocket!
terminate called after throwing an instance of 'std::out_of_range'
what(): Provided string could not be converted to enum of type InstallCertificateUseEnum
2024-04-20 13:55:56.955979 [CRIT] manager int boot(const boost::program_options::variables_map&) :: Module ocpp (pid: 131088) exited with status: 134. Terminating all modules.
2024-04-20 13:55:56.957800 [INFO] manager :: SIGTERM of child: api (pid: 131066) succeeded.
2024-04-20 13:55:56.957956 [INFO] manager :: SIGTERM of child: auth (pid: 131067) succeeded.
2024-04-20 13:55:56.958003 [INFO] manager :: SIGTERM of child: energy_manager (pid: 131068) succeeded.
2024-04-20 13:55:56.958025 [INFO] manager :: SIGTERM of child: ev_manager_1 (pid: 131069) succeeded.
2024-04-20 13:55:56.958053 [INFO] manager :: SIGTERM of child: ev_manager_2 (pid: 131070) succeeded.
2024-04-20 13:55:56.958224 [INFO] manager :: SIGTERM of child: evse_manager_1 (pid: 131072) succeeded.
2024-04-20 13:55:56.958386 [INFO] manager :: SIGTERM of child: evse_manager_2 (pid: 131073) succeeded.
2024-04-20 13:55:56.958424 [INFO] manager :: SIGTERM of child: evse_security (pid: 131079) succeeded.
2024-04-20 13:55:56.958467 [INFO] manager :: SIGTERM of child: grid_connection_point (pid: 131080) succeeded.
2024-04-20 13:55:56.958497 [INFO] manager :: SIGTERM of child: iso15118_car (pid: 131086) succeeded.
2024-04-20 13:55:56.958537 [INFO] manager :: SIGTERM of child: iso15118_charger (pid: 131087) succeeded.
2024-04-20 13:55:56.958559 [INFO] manager :: SIGTERM of child: slac (pid: 131090) succeeded.
2024-04-20 13:55:56.958597 [INFO] manager :: SIGTERM of child: system (pid: 131091) succeeded.
2024-04-20 13:55:56.958628 [INFO] manager :: SIGTERM of child: token_provider_1 (pid: 131092) succeeded.
2024-04-20 13:55:56.958654 [INFO] manager :: SIGTERM of child: yeti_driver_1 (pid: 131098) succeeded.
2024-04-20 13:55:56.958675 [INFO] manager :: SIGTERM of child: yeti_driver_2 (pid: 131099) succeeded.
2024-04-20 13:55:56.958689 [CRIT] manager int boot(const boost::program_options::variables_map&) :: Exiting manager.
OCPP2.0.1, Simulation
The bug seems to come from the module OCPP201
This is my first issue and I'm a newbie with everest, so I'm sorry if this isn't formatted correctly. Please let me know of any problem that needs fixing in this issue or in general, as well as any missing information that's needed.
The DC Sil gets stuck in the current main commit in the authorization loop. However, the AC SIL works.
Authorization, Simulation
JsDCSupplySimulator
Start config-sil-dc on actual main.
No response
Currently the module does not terminate the HLC communication when the CP state changes from CP state C/D (charging) to B/E/F. The implementation currently relies on the EV to close the HLC communication. This unexpected CP change can be caused by a faulty EV implementation, a defect in the CP cabling or even stray incoming electromagnetic interference.
ISO15118
EvseManager, EvseV2G
SIL:
HIL:
No response
When running make test
directly after configuring with cmake the tests aren't build yet:
Running tests...
Test project /home/andreas/EVworkspaces/reproduce-issue-unit-tests/build
Start 1: everest-core_auth_tests
Could not find executable everest-core_auth_tests
Looked in the following places:
everest-core_auth_tests
everest-core_auth_tests
Release/everest-core_auth_tests
Release/everest-core_auth_tests
Debug/everest-core_auth_tests
Debug/everest-core_auth_tests
MinSizeRel/everest-core_auth_tests
MinSizeRel/everest-core_auth_tests
RelWithDebInfo/everest-core_auth_tests
RelWithDebInfo/everest-core_auth_tests
Deployment/everest-core_auth_tests
Deployment/everest-core_auth_tests
Development/everest-core_auth_tests
Development/everest-core_auth_tests
Unable to find executable: everest-core_auth_tests
1/5 Test #1: everest-core_auth_tests .........................***Not Run 0.00 sec
Start 2: everest-core_EvseManager_tests
Could not find executable everest-core_EvseManager_tests
Looked in the following places:
everest-core_EvseManager_tests
everest-core_EvseManager_tests
Release/everest-core_EvseManager_tests
Release/everest-core_EvseManager_tests
Debug/everest-core_EvseManager_tests
Debug/everest-core_EvseManager_tests
MinSizeRel/everest-core_EvseManager_tests
MinSizeRel/everest-core_EvseManager_tests
RelWithDebInfo/everest-core_EvseManager_tests
RelWithDebInfo/everest-core_EvseManager_tests
Deployment/everest-core_EvseManager_tests
Deployment/everest-core_EvseManager_tests
Development/everest-core_EvseManager_tests
Development/everest-core_EvseManager_tests
Unable to find executable: everest-core_EvseManager_tests
2/5 Test #2: everest-core_EvseManager_tests ..................***Not Run 0.00 sec
Start 3: everest-core_lem_dcbm_400600_controller_tests
Could not find executable everest-core_lem_dcbm_400600_controller_tests
Looked in the following places:
everest-core_lem_dcbm_400600_controller_tests
everest-core_lem_dcbm_400600_controller_tests
Release/everest-core_lem_dcbm_400600_controller_tests
Release/everest-core_lem_dcbm_400600_controller_tests
Debug/everest-core_lem_dcbm_400600_controller_tests
Debug/everest-core_lem_dcbm_400600_controller_tests
MinSizeRel/everest-core_lem_dcbm_400600_controller_tests
MinSizeRel/everest-core_lem_dcbm_400600_controller_tests
RelWithDebInfo/everest-core_lem_dcbm_400600_controller_tests
RelWithDebInfo/everest-core_lem_dcbm_400600_controller_tests
Deployment/everest-core_lem_dcbm_400600_controller_tests
Deployment/everest-core_lem_dcbm_400600_controller_tests
Development/everest-core_lem_dcbm_400600_controller_tests
Development/everest-core_lem_dcbm_400600_controller_tests
Unable to find executable: everest-core_lem_dcbm_400600_controller_tests
3/5 Test #3: everest-core_lem_dcbm_400600_controller_tests ...***Not Run 0.00 sec
Start 4: everest-core_lem_time_sync_helper_tests
Could not find executable everest-core_lem_time_sync_helper_tests
Looked in the following places:
everest-core_lem_time_sync_helper_tests
everest-core_lem_time_sync_helper_tests
Release/everest-core_lem_time_sync_helper_tests
Release/everest-core_lem_time_sync_helper_tests
Debug/everest-core_lem_time_sync_helper_tests
Debug/everest-core_lem_time_sync_helper_tests
MinSizeRel/everest-core_lem_time_sync_helper_tests
MinSizeRel/everest-core_lem_time_sync_helper_tests
RelWithDebInfo/everest-core_lem_time_sync_helper_tests
RelWithDebInfo/everest-core_lem_time_sync_helper_tests
Deployment/everest-core_lem_time_sync_helper_tests
Deployment/everest-core_lem_time_sync_helper_tests
Development/everest-core_lem_time_sync_helper_tests
Development/everest-core_lem_time_sync_helper_tests
Unable to find executable: everest-core_lem_time_sync_helper_tests
4/5 Test #4: everest-core_lem_time_sync_helper_tests .........***Not Run 0.00 sec
Start 5: everest-core_setup_tests
Could not find executable everest-core_setup_tests
Looked in the following places:
everest-core_setup_tests
everest-core_setup_tests
Release/everest-core_setup_tests
Release/everest-core_setup_tests
Debug/everest-core_setup_tests
Debug/everest-core_setup_tests
MinSizeRel/everest-core_setup_tests
MinSizeRel/everest-core_setup_tests
RelWithDebInfo/everest-core_setup_tests
RelWithDebInfo/everest-core_setup_tests
Deployment/everest-core_setup_tests
Deployment/everest-core_setup_tests
Development/everest-core_setup_tests
Development/everest-core_setup_tests
Unable to find executable: everest-core_setup_tests
5/5 Test #5: everest-core_setup_tests ........................***Not Run 0.00 sec
0% tests passed, 5 tests failed out of 5
Total Test time (real) = 0.01 sec
The following tests FAILED:
1 - everest-core_auth_tests (Not Run)
2 - everest-core_EvseManager_tests (Not Run)
3 - everest-core_lem_dcbm_400600_controller_tests (Not Run)
4 - everest-core_lem_time_sync_helper_tests (Not Run)
5 - everest-core_setup_tests (Not Run)
Errors while running CTest
Output from these tests are in: /home/andreas/EVworkspaces/reproduce-issue-unit-tests/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
make: *** [Makefile:91: test] Fehler 8
Testing
All unit tests
The following tests FAILED:
1 - everest-core_auth_tests (Not Run)
2 - everest-core_EvseManager_tests (Not Run)
3 - everest-core_lem_dcbm_400600_controller_tests (Not Run)
4 - everest-core_lem_time_sync_helper_tests (Not Run)
5 - everest-core_setup_tests (Not Run)
Errors while running CTest
mkdir build
cmake ../everest-core -DBUILD_TESTING=ON
make test
No response
Hi,
we have recently implemented the new connector lock interface on our Tarragon platform (everest-core 2023.12.0). During our tests with AC free charging (Dummy token provider), we noticed an unexpected behavior. In case we are in free charging (CP state C, contactor closed) and then switch to CP state E, the plug lock is unlocked before the contactor is open. So it seems the EvseManager has an issue.
Expected behavior:
For safety reason the plug lock should only be opened after the contactor open.
Observed behavior:
After a CP state change from E to C, the plug lock is opened before the contactor is open.
Log:
Jan 23 14:55:20 tarragon manager[7678]: 2024-01-23 14:55:20.465163 [INFO] connector_1:Evs :: CAR IEC Event CarRequestedPower
Jan 23 14:55:20 tarragon manager[7678]: 2024-01-23 14:55:20.466460 [INFO] connector_1:Evs :: EVSE IEC Charger state: PrepareCharging->Charging
Jan 23 14:55:20 tarragon manager[7681]: 2024-01-23 14:55:20.553929 [INFO] tarragon_bsp:Cb :: Closing contactor...
Jan 23 14:55:20 tarragon manager[7681]: 2024-01-23 14:55:20.646881 [INFO] tarragon_bsp:Cb :: Contactor state: CLOSED
Jan 23 14:55:20 tarragon manager[7678]: 2024-01-23 14:55:20.680267 [INFO] connector_1:Evs :: EVSE IEC Event PowerOn
Jan 23 14:55:25 tarragon manager[7681]: 2024-01-23 14:55:25.892872 [INFO] tarragon_bsp:Cb :: CP state change from C to E, U_CP+: 764 mV, U_CP-: -11175 mV
Jan 23 14:55:26 tarragon manager[7677]: 2024-01-23 14:55:26.555977 [INFO] cb_tarragon_plu :: is unlocked
Jan 23 14:55:26 tarragon manager[7681]: 2024-01-23 14:55:26.659319 [INFO] tarragon_bsp:Cb :: Opening contactor...
Jan 23 14:55:26 tarragon manager[7681]: 2024-01-23 14:55:26.691790 [INFO] tarragon_bsp:Cb :: Contactor state: OPEN
Jan 23 14:55:26 tarragon manager[7678]: 2024-01-23 14:55:26.732036 [INFO] connector_1:Evs :: EVSE IEC Event PowerOff
Config:
active_modules:
api:
module: API
connections:
evse_manager:
- module_id: connector_1
implementation_id: evse
auth:
module: Auth
config_module:
connection_timeout: 10
prioritize_authorization_over_stopping_transaction: true
selection_algorithm: PlugEvents
connections:
token_provider:
- module_id: token_provider_1
implementation_id: main
token_validator:
- module_id: token_validator
implementation_id: main
evse_manager:
- module_id: connector_1
implementation_id: evse
cb_tarragon_driver:
module: CbTarragonDriver
connections: {}
cb_tarragon_pluglock:
module: CbTarragonPlugLock
connections: {}
energy_manager:
module: EnergyManager
connections:
energy_trunk:
- module_id: grid_connection_point
implementation_id: energy_grid
connector_1:
module: EvseManager
config_module:
ac_enforce_hlc: false
ac_hlc_enabled: false
ac_hlc_use_5percent: true
ac_nominal_voltage: 230
ac_with_soc: false
charge_mode: AC
connector_id: 1
country_code: DE
dbg_hlc_auth_after_tstep: false
ev_receipt_required: false
evse_id: DE*CHB*E123456*1
has_ventilation: true
max_current_import_A: 16
payment_enable_contract: false
payment_enable_eim: true
session_logging: false
session_logging_path: /tmp/everest-logs
session_logging_xml: false
three_phases: true
connections:
bsp:
- module_id: cb_tarragon_driver
implementation_id: evse_board_support
connector_lock:
- module_id: cb_tarragon_pluglock
implementation_id: connector_lock
grid_connection_point:
module: EnergyNode
config_module:
fuse_limit_A: 63
phase_count: 3
connections:
energy_consumer:
- implementation_id: energy_grid
module_id: connector_1
token_provider_1:
module: DummyTokenProvider
config_implementation:
main:
timeout: 10
token: DEADBEEF
type: RFID
connections:
evse:
- module_id: connector_1
implementation_id: evse
token_validator:
module: DummyTokenValidator
config_implementation:
main:
sleep: 0.25
validation_reason: Token seems valid
validation_result: Accepted
connections: {}
x-module-layout: {}
Hello,
I have to similar configs where one of the uses dummytokenvalidator while the other uses OCPP,
When ever I try to use the ocpp one I get EVSE paused almost immediately after clicking car plugin in the simulator, while when using the dummytokenvalidator, it works perfectly.
when I first created the ocpp config file it was working as expected but out of nowhere it stopped.
Here is the log in both cases:
dummytokenvalidator:
2024-03-06 14:19:51.916337 [INFO] DummyTokenValid :: Got validation request for token: 0123456789ABCD
2024-03-06 14:19:52.416672 [INFO] DummyTokenValid :: Returning validation status: Accepted
2024-03-06 14:19:52.439238 [INFO] auth:Auth :: Providing authorization to connector#1
2024-03-06 14:19:52.769891 [INFO] evse_manager:Ev :: EVSE IEC Set PWM On (5.000000074505806%) took 0 ms
2024-03-06 14:19:52.915920 [INFO] auth:Auth :: Result for token: 0123456789ABCD: ACCEPTED
2024-03-06 14:19:52.977889 [INFO] evse_manager:Ev :: EVSE IEC EIM Authorization received
2024-03-06 14:19:52.978091 [INFO] evse_manager:Ev :: EVSE IEC Transaction Started (0 kWh)
2024-03-06 14:19:52.978408 [INFO] evse_manager:Ev :: EVSE IEC DC mode. We are in 5percent mode so we can continue without further action.
2024-03-06 14:19:52.978506 [INFO] evse_manager:Ev :: EVSE IEC Charger state: Wait for Auth->PrepareCharging
2024-03-06 14:19:54.115482 [INFO] evse_manager:Ev :: EVSE ISO SLAC MATCHED
2024-03-06 14:19:54.135855 [INFO] evse_manager:Ev :: EVSE ISO D-LINK_READY (true)
OCPP:
2024-03-06 14:17:44.156164 [INFO] auth:Auth :: Providing authorization to connector#1
2024-03-06 14:17:44.940664 [INFO] evse_manager:Ev :: EVSE IEC Set PWM On (5.000000074505806%) took 0 ms
2024-03-06 14:17:45.130324 [INFO] auth:Auth :: Result for token: 0123456789ABCD: ACCEPTED
2024-03-06 14:17:45.206881 [INFO] evse_manager:Ev :: EVSE IEC EIM Authorization received
2024-03-06 14:17:45.207509 [INFO] evse_manager:Ev :: EVSE IEC Transaction Started (0 kWh)
2024-03-06 14:17:45.208729 [INFO] evse_manager:Ev :: EVSE IEC DC mode. We are in 5percent mode so we can continue without further action.
2024-03-06 14:17:45.209089 [INFO] evse_manager:Ev :: EVSE IEC Charger state: Wait for Auth->PrepareCharging
2024-03-06 14:17:45.287327 [INFO] OCPP0:OCPP :: EVSE#1: Received TransactionStarted
2024-03-06 14:17:45.616218 [INFO] evse_manager:Ev :: EVSE IEC Transaction Finished: DeAuthorized (0 kWh)
2024-03-06 14:17:45.710445 [INFO] evse_manager:Ev :: EVSE IEC Charger state: PrepareCharging->EVSE Paused
2024-03-06 14:17:45.710753 [INFO] evse_manager:Ev :: EVSE IEC Set PWM Off
2024-03-06 14:17:46.126347 [INFO] evse_manager:Ev :: EVSE ISO SLAC MATCHED
2024-03-06 14:17:46.146723 [INFO] evse_manager:Ev :: EVSE ISO D-LINK_READY (true)
Any help would be appreciated, Thank you!
C++ objects should be created via new and removed via delete. This ensures that their constructors and destructors are properly called.
The v2g_context structure in EvseV2G is mostly pointers and basic types where use of calloc() to create the structure is fine.
However there are some std::string objects included that are not correctly constructed. When free() is called on the v2g_context pointer the strings are not destructed and hence there could be a memory leak.
One option would be to split the v2g_context structure into parts that can be managed via calloc/free and parts that require new/delete.
Starting points:
ISO15118
EvseV2G
Present in the 2024.3.0 release
No response
In commits 138b9db and dda60db, the EvseV2G module was converted to use libevse-security to locate the TLS certificates.
Yet there are still certificate paths for PnC which are (hard-) coded within the source code, e.g. here:
everest-core/modules/EvseV2G/iso_server.cpp
Lines 1226 to 1227 in d40971c
Additionally, EvseV2G could use libevse-security to verify client certificates (etc.), instead of using its own code. (Stage 2, nice to have.)
US-JOET and the Sandia team are developing one-liner demos in everest-demo. We were able to run an AC ISO15118-2 PnC
charging session using MaEVe as the CSMS. Everything works fine except for the fact that while in the Charging phase in the GUI, it shows 0 kW
power being delivered. Please check the attached screenshot. In other modes (i.e., AC 3ph 16A
), it works as expected. We were told that it is a known problem so I am submitting an issue against it.
Energy Management, ISO15118, Simulation
No response
Use this version and the Basic and ISO 15118-2 AC Charging with OCPP 2.0.1 CSMS (MaEVe Security Profile 3)
one-liner to reproduce.
No response
Right now the manager exits EVerest whenever a child (module) dies. Then systemd usually restarts EVerest to recover. If a module hangs in a command handler, the framework will also timeout and exit the module process which results in a restart of EVerest. We recently added some dead-lock detecting mutexes to EvseManager as well to ensure restarts in case a module hangs somewhere.
There is however no generic watchdog functionality that can be used inside of a module to watch a long running thread (e.g. a mainloop thread, or an IO thread) to see if it is still running, so there are still some threads in some modules that may hang without leading to an exit of the module process.
We should ensure that such scenarios will restart EVerest.
Environment:
everest-core:
3e5c467
libiso15118:
EVerest/libiso15118@0f34d53
EV: Trialog Testsystem
Test Sequence:
Expected Behavior:
TLS handshake runs through and v2g communication starts
Observed Behavior:
TLS handshake fails with error message 1:
Feb 01 10:58:57 tarragon01 manager[20097]: 2024-02-01 10:58:57.484532 [INFO] connector_1:Evs :: EVSE ISO SLAC MATCHED
Feb 01 10:58:57 tarragon01 manager[20097]: 2024-02-01 10:58:57.517753 [INFO] connector_1:Evs :: EVSE ISO D-LINK_READY (true)
Feb 01 10:59:03 tarragon01 manager[20097]: 2024-02-01 10:59:03.906353 [INFO] connector_1:Evs :: EVSE ISO Change HLC Limits: 11040W/200A, target_voltage 0, actual_voltage 2, hack_bpt false
Feb 01 10:59:05 tarragon01 manager[20097]: 2024-02-01 10:59:05.342393 [INFO] connector_1:Evs :: EVSE ISO Change HLC Limits: 11040W/200A, target_voltage 0, actual_voltage 0, hack_bpt false
Feb 01 10:59:05 tarragon01 manager[20105]: 2024-02-01 10:59:05.833929 [INFO] iso15118_charge :: Got SDP request
Feb 01 10:59:06 tarragon01 manager[20105]: 2024-02-01 10:59:06.864023 [ERRO] iso15118_charge virtual void module::charger::ISO15118_chargerImpl::ready() :: D20Evse chrashed: Failed to mbedtls_ssl_handshake() (SSL - The connection indicated an EOF)
Feb 01 10:59:06 tarragon01 manager[20105]: 2024-02-01 10:59:06.864738 [INFO] iso15118_charge :: Shutting down SDP server!
TLS handshake fails with error message 2:
Feb 01 10:58:23 tarragon01 manager[12619]: 2024-02-01 10:58:23.580968 [INFO] connector_1:Evs :: EVSE ISO SLAC MATCHED
Feb 01 10:58:23 tarragon01 manager[12619]: 2024-02-01 10:58:23.604079 [INFO] connector_1:Evs :: EVSE ISO D-LINK_READY (true)
Feb 01 10:58:29 tarragon01 manager[12626]: 2024-02-01 10:58:29.900146 [INFO] iso15118_charge :: Got SDP request
Feb 01 10:58:29 tarragon01 manager[12626]: 2024-02-01 10:58:29.912135 [ERRO] iso15118_charge virtual void module::charger::ISO15118_chargerImpl::ready() :: D20Evse chrashed: Failed to mbedtls_net_bind() (NET - Binding of the socket failed)
Feb 01 10:58:29 tarragon01 manager[12626]: 2024-02-01 10:58:29.919936 [INFO] iso15118_charge :: Shutting down SDP
Additional note:
In current main, the following annoying warning gets emitted:
... sqlite_cpp/cpplint.py:50: DeprecationWarning: module 'sre_compile' is deprecated
import sre_compile
If possible, the cmake logic for sqlite_cpp can be disabled - there is no reason why this cpplint.py should run.
Compilation
No response
just build. The warning might depend on the installed python environment.
No response
Hello,
I get the following error while building everest-core on Ubuntu 22.04 according to https://everest.github.io/nightly/general/03_quick_start_guide.html#quickstartguide-helpers.
CMake Error at _deps/libocpp-build/config/v201/cmake_install.cmake:57 (file):
file INSTALL cannot find
"/home/italia.texa.org/mmariotto/repos/checkout/everest-workspace/everest-core/build/_deps/libocpp-build/config/v201/device_model_storage.db":
No such file or directory.
Call Stack (most recent call first):
_deps/libocpp-build/config/cmake_install.cmake:52 (include)
_deps/libocpp-build/cmake_install.cmake:66 (include)
cmake_install.cmake:92 (include)
Building and linking goes fine until the install phase where this error occurs.
Do you have any idea why the device_model_storage.db is missing?
The reservation handler in the Auth module does currently not support reservations of connector 0 (reservations for the whole charging station and not for a specific EVSE/connector).
The goal of this issue is to implement support so that the requirement of OCPP1.6 and OCPP2.0.1 for this use case is fullfiled:
H01.FR.07 of OCPP 2.0.1 Edition 2 FINAL, 2022-12-15:
When the Charging Station has Accepted a ReserveNowRequest without evseId
The Charging Station SHALL make sure that at any time during the validity of the reservation, one EVSE remains available for the reserved IdTokenType.
OCPP1.6 edition 2 FINAL, 2017-09-28:
If the connectorId in the reservation request is 0, then the Charge Point SHALL NOT reserve a specific connector, but SHALL make sure that at any time during the validity of the reservation, one connector remains available for the reserved idTag
When building everest-core
following a procedure similar to the one used in everest-demo
(i.e. using the EVerest CI build-kit container), the first compilation fails with the following error:
ninja: job failed: /usr/bin/ccache /usr/bin/c++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DFMT_SHARED -DONLY_C_LOCALE=0 -DUSE_OS_TZDB=1 -I/ext/source/modules/OCPP201 -I/workspace/build/generated/include -I/workspace/build/generated/modules/OCPP201 -I/workspace/build/_deps/everest-framework-build/generated -I/ext/cache/cpm/everest-framework/63a1c5de90bf26a8034c80c08ab99667b5ea4fb8/everest-framework/include -I/ext/cache/cpm/date/91ef8592e97dd3a2a15aed9de5dbf7e3ff2636eb/date/include -I/ext/cache/cpm/nlohmann_json/b3708972f6694fe462e4112e47aa04f10d2390b4/nlohmann_json/include -I/ext/cache/cpm/nlohmann_json_schema_validator/648e7cc933b58ff9d20a5288445b6172aa5fc67f/nlohmann_json_schema_validator/src -I/ext/cache/cpm/libfmt/db7252a8aa3d829180246c17fb97ef0f367a2322/libfmt/include -I/ext/cache/cpm/liblog/5d578ffd5bc0e07e1c9bd75d269f3692d33a96ca/liblog/include -I/ext/cache/cpm/libocpp/736f6150a3a497aa7dd80d7d9a65dfe59d3613e5/libocpp/include -I/ext/cache/cpm/libtimer/5f95893b9dd3ee5a130229e9a42efaedcd74640b/libtimer/include -I/ext/cache/cpm/libevse-security/548ca4a70a1757b2b6474706e0f4f603bd68f4d6/libevse-security/include -I/ext/source/lib/staging/ocpp -isystem /ext/cache/cpm/websocketpp/5d9dc11d6860090858d1bdaae8c72318d01a0a5a/websocketpp -g -std=gnu++17 -MD -MT modules/CMakeFiles/OCPP201.dir/OCPP201/data_transfer/ocpp_data_transferImpl.cpp.o -MF modules/CMakeFiles/OCPP201.dir/OCPP201/data_transfer/ocpp_data_transferImpl.cpp.o.d -o modules/CMakeFiles/OCPP201.dir/OCPP201/data_transfer/ocpp_data_transferImpl.cpp.o -c /ext/source/modules/OCPP201/data_transfer/ocpp_data_transferImpl.cpp
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
ninja: job failed: /usr/bin/ccache /usr/bin/c++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DFMT_SHARED -DONLY_C_LOCALE=0 -DUSE_OS_TZDB=1 -I/ext/source/modules/OCPP201 -I/workspace/build/generated/include -I/workspace/build/generated/modules/OCPP201 -I/workspace/build/_deps/everest-framework-build/generated -I/ext/cache/cpm/everest-framework/63a1c5de90bf26a8034c80c08ab99667b5ea4fb8/everest-framework/include -I/ext/cache/cpm/date/91ef8592e97dd3a2a15aed9de5dbf7e3ff2636eb/date/include -I/ext/cache/cpm/nlohmann_json/b3708972f6694fe462e4112e47aa04f10d2390b4/nlohmann_json/include -I/ext/cache/cpm/nlohmann_json_schema_validator/648e7cc933b58ff9d20a5288445b6172aa5fc67f/nlohmann_json_schema_validator/src -I/ext/cache/cpm/libfmt/db7252a8aa3d829180246c17fb97ef0f367a2322/libfmt/include -I/ext/cache/cpm/liblog/5d578ffd5bc0e07e1c9bd75d269f3692d33a96ca/liblog/include -I/ext/cache/cpm/libocpp/736f6150a3a497aa7dd80d7d9a65dfe59d3613e5/libocpp/include -I/ext/cache/cpm/libtimer/5f95893b9dd3ee5a130229e9a42efaedcd74640b/libtimer/include -I/ext/cache/cpm/libevse-security/548ca4a70a1757b2b6474706e0f4f603bd68f4d6/libevse-security/include -I/ext/source/lib/staging/ocpp -isystem /ext/cache/cpm/websocketpp/5d9dc11d6860090858d1bdaae8c72318d01a0a5a/websocketpp -g -std=gnu++17 -MD -MT modules/CMakeFiles/OCPP201.dir/OCPP201/auth_provider/auth_token_providerImpl.cpp.o -MF modules/CMakeFiles/OCPP201.dir/OCPP201/auth_provider/auth_token_providerImpl.cpp.o.d -o modules/CMakeFiles/OCPP201.dir/OCPP201/auth_provider/auth_token_providerImpl.cpp.o -c /ext/source/modules/OCPP201/auth_provider/auth_token_providerImpl.cpp
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
ninja: job failed: /usr/bin/ccache /usr/bin/c++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DFMT_SHARED -DONLY_C_LOCALE=0 -DUSE_OS_TZDB=1 -I/ext/source/modules/OCPP201 -I/workspace/build/generated/include -I/workspace/build/generated/modules/OCPP201 -I/workspace/build/_deps/everest-framework-build/generated -I/ext/cache/cpm/everest-framework/63a1c5de90bf26a8034c80c08ab99667b5ea4fb8/everest-framework/include -I/ext/cache/cpm/date/91ef8592e97dd3a2a15aed9de5dbf7e3ff2636eb/date/include -I/ext/cache/cpm/nlohmann_json/b3708972f6694fe462e4112e47aa04f10d2390b4/nlohmann_json/include -I/ext/cache/cpm/nlohmann_json_schema_validator/648e7cc933b58ff9d20a5288445b6172aa5fc67f/nlohmann_json_schema_validator/src -I/ext/cache/cpm/libfmt/db7252a8aa3d829180246c17fb97ef0f367a2322/libfmt/include -I/ext/cache/cpm/liblog/5d578ffd5bc0e07e1c9bd75d269f3692d33a96ca/liblog/include -I/ext/cache/cpm/libocpp/736f6150a3a497aa7dd80d7d9a65dfe59d3613e5/libocpp/include -I/ext/cache/cpm/libtimer/5f95893b9dd3ee5a130229e9a42efaedcd74640b/libtimer/include -I/ext/cache/cpm/libevse-security/548ca4a70a1757b2b6474706e0f4f603bd68f4d6/libevse-security/include -I/ext/source/lib/staging/ocpp -isystem /ext/cache/cpm/websocketpp/5d9dc11d6860090858d1bdaae8c72318d01a0a5a/websocketpp -g -std=gnu++17 -MD -MT modules/CMakeFiles/OCPP201.dir/OCPP201/auth_validator/auth_token_validatorImpl.cpp.o -MF modules/CMakeFiles/OCPP201.dir/OCPP201/auth_validator/auth_token_validatorImpl.cpp.o.d -o modules/CMakeFiles/OCPP201.dir/OCPP201/auth_validator/auth_token_validatorImpl.cpp.o -c /ext/source/modules/OCPP201/auth_validator/auth_token_validatorImpl.cpp
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
ninja: job failed: /usr/bin/ccache /usr/bin/c++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_CHRONO_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_LOG_DYN_LINK -DBOOST_LOG_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DFMT_SHARED -DONLY_C_LOCALE=0 -DUSE_OS_TZDB=1 -I/ext/source/modules/OCPP201 -I/workspace/build/generated/include -I/workspace/build/generated/modules/OCPP201 -I/workspace/build/_deps/everest-framework-build/generated -I/ext/cache/cpm/everest-framework/63a1c5de90bf26a8034c80c08ab99667b5ea4fb8/everest-framework/include -I/ext/cache/cpm/date/91ef8592e97dd3a2a15aed9de5dbf7e3ff2636eb/date/include -I/ext/cache/cpm/nlohmann_json/b3708972f6694fe462e4112e47aa04f10d2390b4/nlohmann_json/include -I/ext/cache/cpm/nlohmann_json_schema_validator/648e7cc933b58ff9d20a5288445b6172aa5fc67f/nlohmann_json_schema_validator/src -I/ext/cache/cpm/libfmt/db7252a8aa3d829180246c17fb97ef0f367a2322/libfmt/include -I/ext/cache/cpm/liblog/5d578ffd5bc0e07e1c9bd75d269f3692d33a96ca/liblog/include -I/ext/cache/cpm/libocpp/736f6150a3a497aa7dd80d7d9a65dfe59d3613e5/libocpp/include -I/ext/cache/cpm/libtimer/5f95893b9dd3ee5a130229e9a42efaedcd74640b/libtimer/include -I/ext/cache/cpm/libevse-security/548ca4a70a1757b2b6474706e0f4f603bd68f4d6/libevse-security/include -I/ext/source/lib/staging/ocpp -isystem /ext/cache/cpm/websocketpp/5d9dc11d6860090858d1bdaae8c72318d01a0a5a/websocketpp -g -std=gnu++17 -MD -MT modules/CMakeFiles/OCPP201.dir/__/generated/modules/OCPP201/ld-ev.cpp.o -MF modules/CMakeFiles/OCPP201.dir/__/generated/modules/OCPP201/ld-ev.cpp.o.d -o modules/CMakeFiles/OCPP201.dir/__/generated/modules/OCPP201/ld-ev.cpp.o -c /workspace/build/generated/modules/OCPP201/ld-ev.cpp
c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
ninja: subcommands failed
However, subsequent builds with cache enabled succeed.
everest-core
repository.docker run -it --name everest-core-build-kit -v .:/ext/source ghcr.io/everest/build-kit-alpine bash
/ext/scripts
directory inside the container:
mkdir -p /ext/scripts && cp /ext/source/.ci/build-kit/compile.sh /ext/scripts
/entrypoint.sh run-script compile
[306/1074]
you should get the compilation error./entrypoint.sh run-script compile
If a contract is rejected, the charger should react accordingly and send a prober ResponseCode to the car. This is not happing right now.
ISO15118
EvseV2G
Geneate an incorrect contract leaf and start a pnc sil
No response
Environment:
Test Sequence:
Expected Behavior:
Observed Behavior:
Trace (stripped down to relevant parts IMHO):
Feb 28 13:30:29 ccc300 manager[2007]: 2024-02-28 13:30:29.356093 [INFO] auth:Auth :: Received new token: {
Feb 28 13:30:29 ccc300 manager[2007]: "authorization_type": "RFID",
Feb 28 13:30:29 ccc300 manager[2007]: "id_token": "DEADBEEF"
Feb 28 13:30:29 ccc300 manager[2007]: }
Feb 28 13:30:29 ccc300 manager[2007]: 2024-02-28 13:30:29.515186 [INFO] auth:Auth :: Connector is reserved but token is not valid for this reservation
Feb 28 13:30:29 ccc300 manager[2007]: 2024-02-28 13:30:29.605651 [INFO] auth:Auth :: Result for token: DEADBEEF: REJECTED
Additional note:
Environment:
everest-core:
3e5c467
Test Sequence:
Expected Behavior:
In case of a SIGTERM the modul should stop recording immediately and write the pcap file completely. There should be no error message in the log of EVerest.
Observed Behavior:
Currently the traces are incomplete in case of a unexpected EVerest restart trough a SIGTERM. This is quite annoying when trying to analyze an unexpected restart of EVerest
Additional note:
Furthermore, an error message seems to appear in the log after every v2g charging session
Feb 01 10:03:11 tarragon manager[2951]: 2024-02-01 10:03:11.640330 [ERRO] packet_sniffer: void module::PacketSniffer::capture(const string&, const string&) :: Error reading packets from interface: eth1, error:
boot_module(async ({
^
TypeError: boot_module is not a function
JsYetiSimulator/index.js:1227:1)
at Module._compile (node:internal/modules/cjs/loader:1376:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
at Module.load (node:internal/modules/cjs/loader:1207:32)
at Module._load (node:internal/modules/cjs/loader:1023:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:135:12)
at node:internal/main/run_main_module:28:49
Node.js v20.11.1
Simulation
JsYetiSimulator
This happens with nodejs version v20.11.1, on Ubuntu 22.04LTS, once the run-sil.sh script is executed. I am using the 2024.6.0 tag.
No response
Trying to compile Everest-core using below steps
cd {EVerest Workspace Directory}/everest-core
mkdir build
cd build
cmake ..
make install
make install is failing with below error
Error :
76%] Building CXX object modules/CMakeFiles/EvseManager.dir/EvseManager/EvseManager.cpp.o
In file included from /home/gvijay/everest-dev-environment/everest-core/modules/EvseManager/EvseManager.cpp:3:
/home/gvijay/everest-dev-environment/everest-core/modules/EvseManager/EvseManager.hpp: In constructor ‘module::EvseManager::EvseManager(const ModuleInfo&, Everest::MqttProvider&, Everest::TelemetryProvider&, std::unique_ptr<evse_managerImplBase>, std::unique_ptr, std::unique_ptr<auth_token_providerImplBase>, std::unique_ptr<uk_random_delayImplBase>, std::unique_ptr<evse_board_supportIntf>, std::vector<std::unique_ptr<ac_rcdIntf> >, std::vector<std::unique_ptr<connector_lockIntf> >, std::vector<std::unique_ptr >, std::vector<std::unique_ptr >, std::vector<std::unique_ptr >, std::vector<std::unique_ptr<ISO15118_chargerIntf> >, std::vector<std::unique_ptr<isolation_monitorIntf> >, std::vector<std::unique_ptr<power_supply_DCIntf> >, module::Conf&)’:
/home/gvijay/everest-dev-environment/everest-core/modules/EvseManager/EvseManager.hpp:126:22: error: use of deleted function ‘constexpr std::atomic<_Tp>::atomic() [with _Tp = std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1, 1000000000> > >]’
126 | config(config){};
| ^
In file included from /usr/include/c++/9/future:42,
from /home/gvijay/everest-dev-environment/everest-framework/include/framework/everest.hpp:7,
from /home/gvijay/everest-dev-environment/everest-framework/include/framework/ModuleAdapter.hpp:6,
from /home/gvijay/everest-dev-environment/everest-core/build/generated/modules/EvseManager/ld-ev.hpp:11,
from /home/gvijay/everest-dev-environment/everest-core/modules/EvseManager/EvseManager.hpp:11,
from /home/gvijay/everest-dev-environment/everest-core/modules/EvseManager/EvseManager.cpp:3:
/usr/include/c++/9/atomic:198:7: note: ‘constexpr std::atomic<_Tp>::atomic() noexcept [with _Tp = std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1, 1000000000> > >]’ is implicitly deleted because its exception-specification does not match the implicit exception-specification ‘’
198 | atomic() noexcept = default;
| ^~~~~~
make[2]: *** [modules/CMakeFiles/EvseManager.dir/build.make:70: modules/CMakeFiles/EvseManager.dir/EvseManager/EvseManager.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:5116: modules/CMakeFiles/EvseManager.dir/all] Error 2
make: *** [Makefile:152: all] Error 2
Other
everest-core
No response
No response
I was investigating why reading the values from the meter always take a while. And it looks like the tiny_modbus_rtu is implemented in the way, that we always return when the response timeout is reached and not earlier.
This maybe not a problem with quick devices, but some devices like Bauer Meter, may have long response time sometimes. So we need to keep the timeout large.
Expected behaviour:
Update configure_network_connection_profile_callback
to work with std::future<ConfigNetworkResult>
instead of bool.
In the API.cpp file when a non-permanent error gets cleared, shouldn't we have the following:
case Event::ErrorCleared:
remove_error_from_list(this->active_errors, error.type);
break;
Currently it just falls back to case Event::PermanentFaultCleared
Other
API.cpp, function SessionInfo::update_state
Version is tag 2024.6.0.
No response
The Setup module provides an API to manage Wi-Fi networks. You can scan to see what networks are available and attempt to connect. Problems occur when a SSID includes values outside of the standard 7-bit ASCII printable character range (with potential issues with leading and trailing white space).
character values outside 32..126 are escaped \n \r \xfe etc.
These are then further escaped over the JSON API.
Attempting to connect to a network using the scanned network information fails when there are any escaped characters in the SSID.
e.g.
everest_api/setup/var/wifi_info
would show an SSID as "ssid":"Plusnet\\xe2\\x82\\xac123"
however
everest_api/setup/cmd/add_network
requires "ssid":"Plusnet€123"
.
Additional issues can occur where different character encoding is used since some characters exist in extended ASCII as well as having UTF-8 multi-byte values.
Other
Setup modue
It is recommended to change the Setup module API to use a hex string as the SSID representation.
This removes all the character and encoding issues and would support the full range of allowable SSIDs according to the Wi-Fi standard. (note there may be SSID values that are not supported by the Linux Wi-Fi code such as wpa_supplicant/hostapd ...)
Applications would need to convert the SSID into a displayable value where needed.
It is recommended to use a programmatic API to wpa_supplicant (rather than wpa_cli) to further remove issues with parameter escaping.
No response
I am working on porting bender isoEV425 code to everest and I find that everest doesn't check Leakage Capacitance reading from bender, and I also looked at ChargeX error code, there is an error code called CapacitanceFault, but it is not also included on everest.
Other, isolation monitor interface
EvseManager,
IMDSimulator,
error types
No response
No response
After resuming the session, EVerest is caught in an auth loop. Although the session is already authorized. It is also unclear whether, for example, the car should send the payment details message again.
ISO15118
Start a pnc sil, pause the session and resume after e.g. 15 seconds.
No response
Currently the EvseV2G module uses the OpenV2G project to encode and decode EXI messages.
The goal now is to replace OpenV2G with the new libcbv2g library.
The libcbv2g contains the generated c EXI code from the cbexigen generator with a CMake integration.
Tasks:
Every contribution is appreciated 😃
Charging sessions can fail for multiple reasons before energy is transferred. Some of the reasons are:
Authorization, Charge Control, ISO15118
EvseManager
The charging station has some options to change its configuration and behavior in order to resolve some of these issues when a replug is performed.
This could be to:
This feature should add support for session failure handling of the charging station in case of one or multiple failed charging sessions in a row. This behavior shall be configurable.
The following configuration parameters shall be added to the EvseManager module:
session_failure_handling_timeout
: Enables session failure handling. If 0, no session failure handling is appliedsession_failure_threshold_s
: Defines the threshold in seconds for how long the session failure handling is applied before the charging station falls back to its standard configurationA failed charging session shall be detected by the EvseManager. A failed charging session can be identified by the EvseManager if a SessionStarted event is initiated but no energy was transferred before a SessionFinished event.
No response
The source code is cross compiled for the raspberry pi with the bullseye toolchain (armv8-rpi4-linux-gnueabihf). The build is success, however, while running the everest manager, a segmentation fault is observed. I traced the segmentation fault to the function call: validator.set_root_schema(schema)
The input argument is a json file. Attached is the file being read by the software
validator.txt
The runtime failure is:
everest-dev.service: Main process exited, code=dumped, status=11/SEGV
systemd[1]: everest-dev.service: Failed with result 'core-dump'.
A new version of IEC61851-23: 2023 was released and will replace the 2014 version. A few things have been changed that touches EVerest in the cable check phase:
CableCheck:
These changes will make user experience significantly worse as cablecheck phase will take quite long on many popular hardware. Anyway, we will need to implement this.
Charge Control
EvseManager, IMDSimulator, isolation monitor interface
We should extend the isolation monitor interface with e.g. a self test command to be able to trigger self testing at a dedicated point in time. Changes in EvseManager cablecheck logic are required to fulfill the other changes.
No response
Hi,
we recently tested AC HLC on our Tarragon platform (everest-core 2023.12.0). After an unsuccessful V2G session, we noticed that EVerest set a duty cycle of 5% during PLC network leave.
Expected behavior:
Starting with sending of CM_SET_KEY.REQ (leave current network) the duty cycle should be set to 100%. Otherwise EVs might start a SLAC session but this would likely fail because of packet lost (reason: PLC node reset / network leave). The duty cycle should be set to 5% only if the PLC node is ready to operate.
Jan 30 08:57:19 tarragon manager[1832]: 2024-01-30 08:57:19.292199 [INFO] iso15118_charge :: TCP connection closed gracefully
Jan 30 08:57:19 tarragon manager[1828]: 2024-01-30 08:57:19.320970 [INFO] connector_1:Evs :: EVSE ISO D-LINK_TERMINATE.req
Jan 30 08:57:19 tarragon manager[1828]: 2024-01-30 08:57:19.322053 [INFO] connector_1:Evs :: EVSE IEC Set PWM Off
Jan 30 08:57:19 tarragon manager[1834]: 2024-01-30 08:57:19.442119 [INFO] tarragon_bsp:Cb :: handle_pwm_off: Setting new duty cycle of 100.00%
Jan 30 08:57:19 tarragon manager[1834]: 2024-01-30 08:57:19.575191 [INFO] tarragon_bsp:Cb :: handle_pwm_on: Setting new duty cycle of 5.00%
Jan 30 08:57:19 tarragon manager[1825]: 2024-01-30 08:57:19.594865 [INFO] EvseSlac0:EvseS :: D-LINK_TERMINATE.request received, leaving network.
Jan 30 08:57:19 tarragon manager[1825]: 2024-01-30 08:57:19.595597 [INFO] EvseSlac0:EvseS :: EvseSlac: Entered Reset state
Jan 30 08:57:19 tarragon manager[1825]: 2024-01-30 08:57:19.597394 [INFO] EvseSlac0:EvseS :: EvseSlac: New NMK key: 51:4E:52:53:48:58:4D:48:46:4F:52:41:35:43:52:4F
Jan 30 08:57:19 tarragon manager[1825]: 2024-01-30 08:57:19.600537 [INFO] EvseSlac0:EvseS :: EvseSlac: Received CM_SET_KEY_CNF
Jan 30 08:57:19 tarragon manager[1825]: 2024-01-30 08:57:19.601028 [INFO] EvseSlac0:EvseS :: EvseSlac: Entered Idle state
Jan 30 08:57:19 tarragon manager[1828]: 2024-01-30 08:57:19.634055 [INFO] connector_1:Evs :: EVSE ISO D-LINK_READY (false)
Jan 30 08:57:19 tarragon manager[1828]: 2024-01-30 08:57:19.651865 [INFO] connector_1:Evs :: EVSE IEC Set PWM On (5.000000074505806%) took 140 ms
Jan 30 08:57:19 tarragon manager[1828]: 2024-01-30 08:57:19.740296 [INFO] connector_1:Evs :: EVSE ISO SLAC UNMATCHED
I had trouble compiling this repo in VSCODE and the Cmake Tools extension due to its preference for Ninja.
However, I found by running export CMAKE_GENERATOR=Ninja
before cmake ..
, I was able to build in VSCODE.
Would the team consider adding this line of code (as optional) to the build documentation for others who wish to use this build environment?
If in the config both payment options are disabled, then the EvseV2G module can not encode the ServiceDiscoveryRes message. Because no payment is provided.
ISO15118
EvseV2G
evse_manager:
module: EvseManager
config_module:
payment_enable_contract: false
payment_enable_eim: false
No response
OCPP Version: 1.6
Description: If we trigger GetDiagnostics against a HTTP server with our Tarragon BSP (EVerest 24.01), we observed lots of unnecessary DiagnosticsStatusNotification with status: "Uploading". Unfortunately i don't have a PCAP trace, so i don't know the result code of the HTTP server from the upload attempt has an influence on this issue.
How to reproduce: Let the Tarragon with EVerest connect via WS to Steve 3.5.0, go to Operations > OCPP v1.6 > GetDiagnostics. Select the chargepoint lesbos_right
, enter the URL of a HTTP server and press "Perform".
Expected behavior: EVerest should only send DiagnosticsStatusNotification with status: "Uploading" once.
CSMS log:
[INFO ] 2024-02-07 16:51:50,744 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [2,"ecc98d9e-50e2-484c-959c-61a934788570","GetDiagnostics",{"location":"http://192.168.1.5/"}]
[INFO ] 2024-02-07 16:51:50,931 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [3,"ecc98d9e-50e2-484c-959c-61a934788570",{"fileName":"diagnostics-2024-02-07T16:51:50.808ZblrG7o"}]
[INFO ] 2024-02-07 16:51:50,935 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"0015c9f2-52c5-487d-abe7-c653ea43ae69","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:50,942 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"0015c9f2-52c5-487d-abe7-c653ea43ae69",{}]
[INFO ] 2024-02-07 16:51:53,121 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"6545fccf-9864-4de5-8b19-589a18f8941c","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,125 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"6545fccf-9864-4de5-8b19-589a18f8941c",{}]
[INFO ] 2024-02-07 16:51:53,144 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"501fcbb4-9486-4c2b-b786-8f7f9f7369bb","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,146 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"501fcbb4-9486-4c2b-b786-8f7f9f7369bb",{}]
[INFO ] 2024-02-07 16:51:53,157 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"66c4961d-09a1-4d4a-853e-dc631b405f84","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,159 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"66c4961d-09a1-4d4a-853e-dc631b405f84",{}]
[INFO ] 2024-02-07 16:51:53,171 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"99db7a2a-5dcc-4d85-a2e6-b41e7dd114d4","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,173 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"99db7a2a-5dcc-4d85-a2e6-b41e7dd114d4",{}]
[INFO ] 2024-02-07 16:51:53,186 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"46a82900-7a04-42ed-a898-0e451c5e5b52","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,188 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"46a82900-7a04-42ed-a898-0e451c5e5b52",{}]
[INFO ] 2024-02-07 16:51:53,198 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"0c887a0a-65c5-4407-a4c5-f36c37345a06","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,201 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"0c887a0a-65c5-4407-a4c5-f36c37345a06",{}]
[INFO ] 2024-02-07 16:51:53,210 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"6325e32b-2bce-413d-a56e-f79530e30da1","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,212 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"6325e32b-2bce-413d-a56e-f79530e30da1",{}]
[INFO ] 2024-02-07 16:51:53,221 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"e6869280-d113-4e48-ab8f-2ca94ab8466f","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,223 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"e6869280-d113-4e48-ab8f-2ca94ab8466f",{}]
[INFO ] 2024-02-07 16:51:53,234 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"0450a63a-8a80-4a45-9e97-b4d645f5f786","DiagnosticsStatusNotification",{"status":"Uploading"}]
[INFO ] 2024-02-07 16:51:53,236 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"0450a63a-8a80-4a45-9e97-b4d645f5f786",{}]
[INFO ] 2024-02-07 16:51:53,246 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Received: [2,"360e092e-2d11-48b6-8923-3379f64d738e","DiagnosticsStatusNotification",{"status":"Uploaded"}]
[INFO ] 2024-02-07 16:51:53,249 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=lesbos_right, sessionId=0cafa312-caba-a2a2-d208-006920ee3159] Sending: [3,"360e092e-2d11-48b6-8923-3379f64d738e",{}]
OCPP configuration:
{
"Internal": {
"ChargePointId": "lesbos_right",
"CentralSystemURI": "ws://192.168.1.5:8081/steve/websocket/CentralSystemService/lesbos_right",
"ChargeBoxSerialNumber": "123",
"ChargePointModel": "Charge Control C",
"ChargePointVendor": "chargebyte",
"FirmwareVersion": "0.1",
"LogMessagesFormat": []
},
"Core": {
"AuthorizeRemoteTxRequests": false,
"ClockAlignedDataInterval": 900,
"ConnectionTimeOut": 10,
"ConnectorPhaseRotation": "0.RST,1.RST",
"GetConfigurationMaxKeys": 100,
"HeartbeatInterval": 86400,
"LocalAuthorizeOffline": false,
"LocalPreAuthorize": false,
"MeterValuesAlignedData": "Energy.Active.Import.Register",
"MeterValuesSampledData": "Energy.Active.Import.Register",
"MeterValueSampleInterval": 0,
"NumberOfConnectors": 1,
"ResetRetries": 1,
"StopTransactionOnEVSideDisconnect": true,
"StopTransactionOnInvalidId": true,
"StopTxnAlignedData": "Energy.Active.Import.Register",
"StopTxnSampledData": "Energy.Active.Import.Register",
"SupportedFeatureProfiles": "Core,FirmwareManagement,RemoteTrigger,Reservation,LocalAuthListManagement,SmartCharging",
"TransactionMessageAttempts": 1,
"TransactionMessageRetryInterval": 10,
"UnlockConnectorOnEVSideDisconnect": true
},
"FirmwareManagement": {
"SupportedFileTransferProtocols": "FTP"
},
"LocalAuthListManagement": {
"LocalAuthListEnabled": true,
"LocalAuthListMaxLength": 42,
"SendLocalListMaxLength": 42
},
"SmartCharging": {
"ChargeProfileMaxStackLevel": 42,
"ChargingScheduleAllowedChargingRateUnit": "Current",
"ChargingScheduleMaxPeriods": 42,
"MaxChargingProfilesInstalled": 42
},
"Security": {
"SecurityProfile": 0
},
"PnC": {
"ISO15118PnCEnabled": true,
"ContractValidationOffline": true
}
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.