Uncaught Error: The specified module could not be found./?~\AppData\Local\Temp\360zip$Temp\36...

Prerequisites

[ ] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: <https://github.com/issues?q=is%3Aissue user%3Aatom>
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

Steps to Reproduce

Expected behavior:

Actual behavior:

Versions
Atom: 1.60.0 ia32
Electron: 9.4.4
OS: Unknown Windows version
Thrown From: Atom Core
Stack Trace
Uncaught Error: The specified module could not be found.
\?\C:\Users\Mabel\AppData\Local\Temp\360zip$Temp\360$0\Atom\resources\app.asar.unpacked\node_modules\keyboard-layout\build\Release\keyboard-layout-manager.node
At electron/js2c/asar.js:140

Error: The specified module could not be found.
\\?\C:\Users\Mabel\AppData\Local\Temp\360zip$Temp\360$0\Atom\resources\app.asar.unpacked\node_modules\keyboard-layout\build\Release\keyboard-layout-manager.node
    at process.func [as dlopen] (electron/js2c/asar.js:140:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)
    at Object.func [as .node] (electron/js2c/asar.js:149:18)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Module._load (internal/modules/cjs/loader.js:727:14)
    at Function.Module._load (electron/js2c/asar.js:769:28)
    at Module.require (/app.asar/static/index.js:72:46)
    at require (internal/modules/cjs/helpers.js:74:18)
    at customRequire (~/AppData/Local/Temp/360zip$Temp/360$0/Atom/resources/app/static/<embedded>:1:802772)
    at get_KeyboardLayoutManager (~/AppData/Local/Temp/360zip$Temp/360$0/Atom/resources/app/static/<embedded>:14:2877135)
    at get_manager (~/AppData/Local/Temp/360zip$Temp/360$0/Atom/resources/app/static/<embedded>:14:2877237)
    at Object.getCurrentKeyboardLayout (~/AppData/Local/Temp/360zip$Temp/360$0/Atom/resources/app/static/<embedded>:14:2877363)
    at e.keystrokeForKeyboardEvent (~/AppData/Local/Temp/360zip$Temp/360$0/Atom/resources/app/static/<embedded>:14:1121318)
    at KeymapManager.keystrokeForKeyboardEvent (~/AppData/Local/Temp/360zip$Temp/360$0/Atom/resources/app/static/<embedded>:11:1225566)
    at KeymapManager.handleKeyboardEvent (~/AppData/Local/Temp/360zip$Temp/360$0/Atom/resources/app/static/<embedded>:11:1223551)
    at WindowEventHandler.handleDocumentKeyEvent (~/AppData/Local/Temp/360zip$Temp/360$0/Atom/resources/app/static/<embedded>:11:286682)

Commands
     -1:38.3.0 core:save-as (input.hidden-input)

Non-Core Packages

Additional Information

Hello, thanks for creating an issue here, but:
GitHub is ending support for Atom and archiving, so please do not create any new issues or pull requests unless you want to discuss. - I am not a developer.
Thank you.

Hello there!
Thanks for creating the issue, but you need at least a description and some steps to reproduce (unless it doesn't apply to you).
Hope this Helps!


ALIAS lab Dell 740xd network interface names don't exist

task path: /root/jetpack/external.yml:10
changed: [undercloud] => {"changed": true, "cmd": "for i in /sys/class/net/*\ndo\n  udevcontent=`udevadm info -p $i --query property`\n  if [[ $udevcontent =~ enp140s0f1 ]]\n  then\n    ext_i
nterface=`echo $i | cut -d '/' -f 5`\n    break\n  fi\ndone\necho $ext_interface\n", "delta": "0:00:00.058717", "end": "2020-05-04 14:20:04.191614", "rc": 0, "start": "2020-05-04 14:20:04.132
897", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}
TASK [set ext_iface] *********************************************************************************************************************************************************
task path: /root/jetpack/external.yml:23
ok: [undercloud] => {"ansible_facts": {"ext_iface": ""}, "changed": false}
TASK [set ext_iface] *********************************************************************************************************************************************************
task path: /root/jetpack/external.yml:28
skipping: [undercloud] => {"changed": false, "skip_reason": "Conditional result was False"}
TASK [create vlan interface on external interface] ***************************************************************************************************************************
task path: /root/jetpack/external.yml:33
fatal: [undercloud]: FAILED! => {"changed": true, "cmd": "ip link add link  name .300 type vlan id 300\nip link set dev  up\nip link set dev .300 up\nip a a <IP_ADDRESS>/24 brd <IP_ADDRESS> dev
 .300\n", "delta": "0:00:00.015098", "end": "2020-05-04 14:20:04.699105", "msg": "non-zero return code", "rc": 1, "start": "2020-05-04 14:20:04.684007", "stderr": "Cannot find device \"name\"
\nCannot find device \"up\"\nCannot find device \".300\"\nCannot find device \".300\"", "stderr_lines": ["Cannot find device \"name\"", "Cannot find device \"up\"", "Cannot find device \".300
\"", "Cannot find device \".300\""], "stdout": "", "stdout_lines": []}
...ignoring

This happens because the external interface is expected to match enp140s0f1, which doesn't exist. Neither does enp140s0f0. The correct naming for the interfaces should be enp134s0f0 and enp134s0f1, which would match ens7f0 and ens7f1 respectively.

closing as the fix is merged


Adjust release notes and page extension docs to reflect permission changes

Thanks to @timgraham for pointing this out :)
@evildmp I've added the warning at the bottom.

Coverage remained the same at 82.459% when pulling 6af9da5ae587d9bc8e7aabbd8ae22ca6fdc565f8 on czpython:fixes/adjust-3.4-release-notes into 9e0dc693214f3d33323a5a74a53277d5ea5103ce on divio:develop.

@timgraham @evildmp Thanks for the feedback. I've updated accordingly.

Coverage remained the same at 82.459% when pulling abb68a573345363cac15f44cfa0e8d95b2414fc4 on czpython:fixes/adjust-3.4-release-notes into f4c8448a19bb0e1f603c9d012bde381ceb86301d on divio:develop.

Coverage remained the same at 82.459% when pulling c5725d1316957a4d5da316facb07bec118498be2 on czpython:fixes/adjust-3.4-release-notes into 9cd62fa3e046f0907e6f306fb86d53eb9a566687 on divio:develop.


The syntax of the registerCommand() function seems pretty clear.  I think this is where we will be setting the value of the mod.iso_departure_time.
Here's my thought process: because I'm currently setting the default to be empty (the command being iso_set_departure_time ), I think the c.args[] array should be empty as a result.  Thus, we can check the size of the array, and only set the departure time if len(c.args) > 0.

This is just a theory... it seems the framework currently doesn't support such optional arguments, but I see no reason this would explode if I tried this approach.  Knock on wood!  Drat.  Looks like we do filter by the number of arguments (link)... Guess we do have to re-interprite the empty string on the UI side of things.

I believe we won't need to keep track of the time left (like the sleep command), but worth mentioning that this is something that occurs.

It seems like those are the only two places where this file'll need to be changed.  The changes themselves seem simple (I already have them mocked up), but I have to go back and tweak the UI so that the base case (no input) passes the length(c.args) check.  Once these are written, I need to see where the value should be used in the JsEvManager simulation loop

Finally figured out how to check for a non-input.  I expected "null", or "", but you had to leave the check entirely blank.  Now that this is sorted, we have a default value of "null", which can then be parsed in JsEvManager's index.js.  Woot!

Cool!  I think we can now check off the two boxes.  We can incorporate the new command as follows...

 JS code added to `index.js`
function simdata_reset_defaults(mod) {
  // More definitions above...
  mod.v2g_finished = false;
  mod.iso_stopped = false;
  mod.iso_departure_time = null; // null if not sent, otherwise 32u
  // More below...
}

// intermediate code...

function registerAllCommands(mod) {
// more definitions above...
  registerCmd(mod, 'iso_set_departure_time', 1, (mod, c) => {
    if(length(c.args[0]) !== 'null') {
      try { // wrap this in a try/catch to filter bad inputs
        const dt = Number(c.args[0])
        mod.iso_departure_time = dt
      }
      catch {
        // We should add some rigerous error handling here.
        mod.iso_departure_time = null
      }
      return // Should this return anything?  Let's say no for now.
    }
    // "empty" input of null.
    mod.iso_departure_time = null
  })

// more below...
}

Next task is figuring out where we need to use this new mod.iso_departure_time variable!

Checking through all the use cases in
https://github.com/EVerest/everest-demo/issues/64#issue-2409427125 before creating the patches and rebuilding the image...

 ✅  ISO 15118-2 with EIM
2024-07-17 05:26:52.858781 [INFO] evse_manager_1:  ::                                     CAR ISO V2G AuthorizationReq
2024-07-17 05:26:52.946452 [INFO] evse_manager_1:  :: EVSE ISO V2G AuthorizationRes
2024-07-17 05:26:52.969742 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Decoded message (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message":{"Header":{"SessionID":"38495F5FD7F4FEF8"},"Body":{"AuthorizationRes":{"ResponseCode":"OK","EVSEProcessing":"Ongoing_WaitingForCustomerInteraction"}}}}
2024-07-17 05:26:52.970081 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: AuthorizationRes received
2024-07-17 05:26:52.970443 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Message to encode (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message": {"Header": {"SessionID": "38495F5FD7F4FEF8"}, "Body": {"AuthorizationReq": {}}}}
2024-07-17 05:26:53.108889 [INFO] token_provider_  :: Publishing new dummy token: {"id_token":{"value":"DEADBEEF","type":"ISO14443"},"authorization_type":"RFID","prevalidated":false,"connectors":[1]}
2024-07-17 05:26:53.111436 [INFO] auth:Auth        :: Received new token: {
    "authorization_type": "RFID",
    "connectors": [
        1
    ],
    "id_token": {
        "type": "ISO14443",
        "value": "DEADBEEF"
    },
    "prevalidated": false
}
2024-07-17 05:26:53.119891 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_message(const ocpp::EnhancedMessage<ocpp::v201::MessageType>&) :: Handle_message called: [3,"ef4eb97f-c70f-4ef7-918b-558dfc87f4a0",{"idTokenInfo":{"status":"Accepted"}}]
2024-07-17 05:26:53.120003 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_message(const ocpp::EnhancedMessage<ocpp::v201::MessageType>&) :: json_message called: [3,"ef4eb97f-c70f-4ef7-918b-558dfc87f4a0",{"idTokenInfo":{"status":"Accepted"}}]
2024-07-17 05:26:53.154799 [INFO] auth:Auth        :: Providing authorization to connector#1
2024-07-17 05:26:53.198815 [INFO] evse_manager_1:  :: EVSE IEC EIM Authorization received
2024-07-17 05:26:53.243563 [INFO] auth:Auth        :: Result for token: DEADBEEF: ACCEPTED
2024-07-17 05:26:53.284737 [INFO] evse_manager_1:  :: EVSE IEC Transaction Started (0 kWh)
2024-07-17 05:26:53.285476 [INFO] evse_manager_1:  :: EVSE IEC AC mode, HLC enabled(X1), matching already started. We are in X1 so we can go directly to nominal PWM.
2024-07-17 05:26:53.285866 [INFO] evse_manager_1:  :: EVSE IEC Charger state: Wait for Auth->PrepareCharging
2024-07-17 05:26:53.286306 [INFO] evse_manager_1:  :: EVSE IEC Set PWM On (53.33333611488342%) took 0 ms
2024-07-17 05:26:53.322824 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_message(const ocpp::EnhancedMessage<ocpp::v201::MessageType>&) :: Handle_message called: [3,"0e47e5be-2723-4766-9c3e-f8a3c5884c82",{"idTokenInfo":{"status":"Accepted"}}]
2024-07-17 05:26:53.322934 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_message(const ocpp::EnhancedMessage<ocpp::v201::MessageType>&) :: json_message called: [3,"0e47e5be-2723-4766-9c3e-f8a3c5884c82",{"idTokenInfo":{"status":"Accepted"}}]
2024-07-17 05:26:53.511130 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Sent AuthorizationReq
2024-07-17 05:26:53.511346 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: IN CPM: Entered state Authorization
2024-07-17 05:26:53.512614 [INFO] evse_manager_1:  ::                                     CAR ISO V2G AuthorizationReq
2024-07-17 05:26:53.612152 [INFO] evse_manager_1:  :: EVSE ISO V2G AuthorizationRes
2024-07-17 05:26:53.657368 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Decoded message (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message":{"Header":{"SessionID":"38495F5FD7F4FEF8"},"Body":{"AuthorizationRes":{"ResponseCode":"OK","EVSEProcessing":"Finished"}}}}

2024-07-17 05:26:53.658770 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Message to encode (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message": {"Header": {"SessionID": "38495F5FD7F4FEF8"}, "Body": {"ChargeParameterDiscoveryReq": {"RequestedEnergyTransferMode": "AC_three_phase_core", "AC_EVChargeParameter": {"DepartureTime": 0, "EAmount": {"Value": 60, "Multiplier": 3, "Unit": "Wh"}, "EVMaxVoltage": {"Value": 400, "Multiplier": 0, "Unit": "V"}, "EVMaxCurrent": {"Value": 32000, "Multiplier": -3, "Unit": "A"}, "EVMinCurrent": {"Value": 10, "Multiplier": 0, "Unit": "A"}}}}}}
2024-07-17 05:26:53.669817 [INFO] energy_manager:  ::                                NO TRADE
2024-07-17 05:26:53.670003 [INFO] energy_manager:  :: Sending enfored limits (import) to :evse_manager_1 {
    "ac_max_current_A": 32.0
}
2024-07-17 05:26:53.670173 [INFO] energy_manager:  :: returning optimized values vector of length 1
2024-07-17 05:26:53.670229 [INFO] energy_manager:  :: evse_manager_1 Enforce limits 32A -9999W

2024-07-17 05:26:53.798979 [ERRO] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: In ISO15118 charger impl, after updating AC max current to 32.000000, we get 32.000000

2024-07-17 05:26:54.221176 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Sent ChargeParameterDiscoveryReq2024-07-17 05:26:54.221200 [INFO] iso15118_charge  :: Parameter-phase started

2024-07-17 05:26:54.221597 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: IN CPM: Entered state ChargeParameterDiscovery

2024-07-17 05:26:54.222291 [INFO] iso15118_charge  :: Selected energy transfer mode: AC_three_phase_core

2024-07-17 05:26:54.222384 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: before adjusting for departure time, max_current 32.000000, nom_voltage 230, pmax 22080, departure_duration 0

2024-07-17 05:26:54.222472 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Requested departure time 0, requested energy 60000.000000

2024-07-17 05:26:54.222630 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: No departure time specified, not modifying defaults
2024-07-17 05:26:54.345396 [INFO] evse_manager_1:  ::                                     CAR ISO V2G ChargeParameterDiscoveryReq
2024-07-17 05:26:54.345918 [INFO] evse_manager_1:  :: EVSE ISO V2G ChargeParameterDiscoveryRes
2024-07-17 05:26:54.361148 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Decoded message (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message":{"Header":{"SessionID":"38495F5FD7F4FEF8"},"Body":{"ChargeParameterDiscoveryRes":{"ResponseCode":"OK","EVSEProcessing":"Finished","SAScheduleList":{"SAScheduleTuple":[{"SAScheduleTupleID":1,"PMaxSchedule":{"PMaxScheduleEntry":[{"RelativeTimeInterval":{"start":0,"duration":86400},"PMax":{"Multiplier":0,"Unit":"W","Value":22080}}]}}]},"AC_EVSEChargeParameter":{"AC_EVSEStatus":{"NotificationMaxDelay":0,"EVSENotification":"None","RCD":false},"EVSENominalVoltage":{"Multiplier":-1,"Unit":"V","Value":2300},"EVSEMaxCurrent":{"Multiplier":-1,"Unit":"A","Value":320}}}}}}

 ✅  ISO 15118-2 with PnC
2024-07-17 05:29:42.580675 [INFO] evse_security:E  :: Verifying leaf certificate: MO
2024-07-17 05:29:42.581188 [INFO] evse_security:E  :: Building new certificate hierarchy!
2024-07-17 05:29:42.583688 [INFO] evse_security:E  :: Building new certificate hierarchy!
2024-07-17 05:29:42.590223 [INFO] ocpp:OCPP201     :: Local contract validation result: Valid
2024-07-17 05:29:42.602074 [INFO] ocpp:OCPP201     :: Online: Pass generated OCSP data to CSMS
2024-07-17 05:29:42.673267 [INFO] evse_manager_1:  :: EVSE ISO V2G PaymentDetailsRes
2024-07-17 05:29:42.733027 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Decoded message (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message":{"Header":{"SessionID":"1DAFFFFC9FFFCBFD"},"Body":{"PaymentDetailsRes":{"ResponseCode":"OK","GenChallenge":"SHW/LuZPgYXBA2IORcV0KA==","EVSETimeStamp":1721194182}}}}
2024-07-17 05:29:42.733471 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: PaymentDetailsRes received
2024-07-17 05:29:42.733834 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Message to encode (ns=urn:iso:15118:2:2013:MsgDef): {"AuthorizationReq": {"Id": "id1", "GenChallenge": "SHW/LuZPgYXBA2IORcV0KA=="}}
2024-07-17 05:29:42.807949 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Message to encode (ns=http://www.w3.org/2000/09/xmldsig#): {"SignedInfo": {"CanonicalizationMethod": {"Algorithm": "http://www.w3.org/TR/canonical-exi/"}, "SignatureMethod": {"Algorithm": "http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"}, "Reference": [{"Transforms": {"Transform": [{"Algorithm": "http://www.w3.org/TR/canonical-exi/"}]}, "DigestMethod": {"Algorithm": "http://www.w3.org/2001/04/xmlenc#sha256"}, "DigestValue": "igy86RSjDnqr0zgJyHvmA22sw2Pa4MZUjls1fD4wr6Q=", "URI": "#id1"}]}}
2024-07-17 05:29:42.866226 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Message to encode (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message": {"Header": {"SessionID": "1DAFFFFC9FFFCBFD", "Signature": {"SignedInfo": {"CanonicalizationMethod": {"Algorithm": "http://www.w3.org/TR/canonical-exi/"}, "SignatureMethod": {"Algorithm": "http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"}, "Reference": [{"Transforms": {"Transform": [{"Algorithm": "http://www.w3.org/TR/canonical-exi/"}]}, "DigestMethod": {"Algorithm": "http://www.w3.org/2001/04/xmlenc#sha256"}, "DigestValue": "igy86RSjDnqr0zgJyHvmA22sw2Pa4MZUjls1fD4wr6Q=", "URI": "#id1"}]}, "SignatureValue": {"value": "7fErTqgPm8AavdXoO66LzuTcm99sXi7jtuCIPEeYdicJFddMk069TeD3BbkrDd7a0DHniDdoIoxQtudSrzktHA=="}}}, "Body": {"AuthorizationReq": {"Id": "id1", "GenChallenge": "SHW/LuZPgYXBA2IORcV0KA=="}}}}
2024-07-17 05:29:43.195410 [INFO] energy_manager:  ::                                NO TRADE
2024-07-17 05:29:43.195570 [INFO] energy_manager:  :: Sending enfored limits (import) to :evse_manager_1 {
    "ac_max_current_A": 32.0
}
2024-07-17 05:29:43.195653 [INFO] energy_manager:  :: returning optimized values vector of length 1
2024-07-17 05:29:43.195698 [INFO] energy_manager:  :: evse_manager_1 Enforce limits 32A -9999W
2024-07-17 05:29:43.239967 [INFO] ocpp:OCPP201     :: CSMS idToken status: Accepted
2024-07-17 05:29:43.240037 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_message(const ocpp::EnhancedMessage<ocpp::v201::MessageType>&) :: Handle_message called: [3,"c4a03b06-2c3e-4fa2-87ba-e2f429cf7518",{"certificateStatus":"Accepted","idTokenInfo":{"status":"Accepted"}}]
2024-07-17 05:29:43.240078 [INFO] ocpp:OCPP201     :: CSMS certificate status: Accepted
2024-07-17 05:29:43.240163 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_message(const ocpp::EnhancedMessage<ocpp::v201::MessageType>&) :: json_message called: [3,"c4a03b06-2c3e-4fa2-87ba-e2f429cf7518",{"certificateStatus":"Accepted","idTokenInfo":{"status":"Accepted"}}]
2024-07-17 05:29:43.242539 [INFO] auth:Auth        :: Providing authorization to connector#1

2024-07-17 05:29:43.335486 [INFO] evse_manager_1:  :: EVSE IEC Transaction Started (0 kWh)
2024-07-17 05:29:43.336958 [INFO] evse_manager_1:  :: EVSE IEC PnC Authorization received
2024-07-17 05:29:43.337172 [INFO] auth:Auth        :: Result for token: UKSWI123456789G: ACCEPTED
2024-07-17 05:29:43.337266 [INFO] evse_manager_1:  :: EVSE IEC AC mode, HLC enabled, PnC auth received. We will continue with 5percent independent on how we started.
2024-07-17 05:29:43.337710 [INFO] evse_manager_1:  :: EVSE IEC Charger state: Wait for Auth->PrepareCharging

2024-07-17 05:29:43.584358 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Message to encode (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message": {"Header": {"SessionID": "1DAFFFFC9FFFCBFD"}, "Body": {"ChargeParameterDiscoveryReq": {"RequestedEnergyTransferMode": "AC_three_phase_core", "AC_EVChargeParameter": {"DepartureTime": 0, "EAmount": {"Value": 60, "Multiplier": 3, "Unit": "Wh"}, "EVMaxVoltage": {"Value": 400, "Multiplier": 0, "Unit": "V"}, "EVMaxCurrent": {"Value": 32000, "Multiplier": -3, "Unit": "A"}, "EVMinCurrent": {"Value": 10, "Multiplier": 0, "Unit": "A"}}}}}}

2024-07-17 05:29:44.130266 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: IN CPM: Entered state ChargeParameterDiscovery

2024-07-17 05:29:44.131397 [INFO] iso15118_charge  :: Selected energy transfer mode: AC_three_phase_core

2024-07-17 05:29:44.131434 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: before adjusting for departure time, max_current 32.000000, nom_voltage 230, pmax 22080, departure_duration 0

2024-07-17 05:29:44.131487 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Requested departure time 0, requested energy 60000.000000

2024-07-17 05:29:44.131639 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: No departure time specified, not modifying defaults
2024-07-17 05:29:44.173059 [INFO] evse_manager_1:  ::                                     CAR ISO V2G ChargeParameterDiscoveryReq
2024-07-17 05:29:44.230977 [INFO] evse_manager_1:  :: EVSE ISO V2G ChargeParameterDiscoveryRes
2024-07-17 05:29:44.251371 [INFO] energy_manager:  ::                                NO TRADE
2024-07-17 05:29:44.251528 [INFO] energy_manager:  :: Sending enfored limits (import) to :evse_manager_1 {
    "ac_max_current_A": 32.0
}
2024-07-17 05:29:44.251608 [INFO] energy_manager:  :: returning optimized values vector of length 1
2024-07-17 05:29:44.251649 [INFO] energy_manager:  :: evse_manager_1 Enforce limits 32A -9999W

2024-07-17 05:29:44.272120 [ERRO] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: In ISO15118 charger impl, after updating AC max current to 32.000000, we get 32.000000
2024-07-17 05:29:44.280874 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Decoded message (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message":{"Header":{"SessionID":"1DAFFFFC9FFFCBFD"},"Body":{"ChargeParameterDiscoveryRes":{"ResponseCode":"OK","EVSEProcessing":"Finished","SAScheduleList":{"SAScheduleTuple":[{"SAScheduleTupleID":1,"PMaxSchedule":{"PMaxScheduleEntry":[{"RelativeTimeInterval":{"start":0,"duration":86400},"PMax":{"Multiplier":0,"Unit":"W","Value":22080}}]}}]},"AC_EVSEChargeParameter":{"AC_EVSEStatus":{"NotificationMaxDelay":0,"EVSENotification":"None","RCD":false},"EVSENominalVoltage":{"Multiplier":-1,"Unit":"V","Value":2300},"EVSEMaxCurrent":{"Multiplier":-1,"Unit":"A","Value":320}}}}}}

 ✅  Grid control only:
2024-07-17 05:34:52.012809 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_set_charging_profile_req(ocpp::Call<ocpp::v201::SetChargingProfileRequest>) :: Received SetChargingProfile: {
    "chargingProfile": {
        "chargingProfileKind": "Absolute",
        "chargingProfilePurpose": "TxDefaultProfile",
        "chargingSchedule": [
            {
                "chargingRateUnit": "A",
                "chargingSchedulePeriod": [
                    {
                        "limit": 10.0,
                        "numberPhases": 3,
                        "startPeriod": 0
                    }
                ],
                "duration": 14400,
                "id": 0,
                "minChargingRate": 0.0,
                "startSchedule": "2024-07-17T05:00:00.000Z"
            }
        ],
        "id": 1,
        "recurrencyKind": "Daily",
        "stackLevel": 1
    },
    "evseId": 0
}
with messageId: d68997ec-3f34-4c07-a0b2-35696bb4d236
2024-07-17 05:34:52.013904 [WARN] ocpp:OCPP201    module::OCPP201::ready()::<lambda()> :: Received a new Charging Schedules from the CSMS or another actor.
2024-07-17 05:34:52.014023 [INFO] ocpp:OCPP201     :: ProfileId #1 Kind: Absolute
2024-07-17 05:34:52.015490 [INFO] ocpp:OCPP201     :: #1 find_period_at> 2024-07-17T05:00:00.000Z
2024-07-17 05:34:52.015572 [INFO] ocpp:OCPP201     ::    find_period_at>        start_time> 2024-07-17T05:34:52.013Z
2024-07-17 05:34:52.015641 [INFO] ocpp:OCPP201     ::    find_period_at> period_start_time> 2024-07-17T05:00:00.000Z
2024-07-17 05:34:52.015680 [INFO] ocpp:OCPP201     ::    find_period_at>   period_end_time> 2024-07-17T09:00:00.000Z
2024-07-17 05:34:52.015788 [INFO] ocpp:OCPP201     :: PeriodDateTimePair>  period: {
    "limit": 10.0,
    "numberPhases": 3,
    "startPeriod": 0
} end_time: 2024-07-17T09:00:00.000Z
2024-07-17 05:34:52.015854 [INFO] ocpp:OCPP201     :: period.has_value() limit = 6900
2024-07-17 05:34:52.015883 [INFO] ocpp:OCPP201     :: period.has_value() stackLevel = 6900
2024-07-17 05:34:52.015946 [INFO] ocpp:OCPP201     :: ProfileId #1 Kind: Absolute
2024-07-17 05:34:52.016023 [INFO] ocpp:OCPP201     :: #1 find_period_at> 2024-07-17T05:00:00.000Z
2024-07-17 05:34:52.016108 [INFO] ocpp:OCPP201     ::    find_period_at>        start_time> 2024-07-17T05:34:52.015Z
2024-07-17 05:34:52.016191 [INFO] ocpp:OCPP201     ::    find_period_at> period_start_time> 2024-07-17T05:00:00.000Z
2024-07-17 05:34:52.016267 [INFO] ocpp:OCPP201     ::    find_period_at>   period_end_time> 2024-07-17T09:00:00.000Z
2024-07-17 05:34:52.016359 [INFO] ocpp:OCPP201     :: PeriodDateTimePair>  period: {
    "limit": 10.0,
    "numberPhases": 3,
    "startPeriod": 0
} end_time: 2024-07-17T09:00:00.000Z
2024-07-17 05:34:52.016552 [INFO] ocpp:OCPP201     :: period.has_value() limit = 6900
2024-07-17 05:34:52.016642 [INFO] ocpp:OCPP201     :: period.has_value() stackLevel = 6900
2024-07-17 05:34:52.016741 [WARN] ocpp:OCPP201    void module::OCPP201::set_external_limits(const std::map<int, ocpp::v201::CompositeSchedule>&) :: OCPP sets the following external limits for EVSE 1:
{
    "schedule_import": [
        {
            "limits_to_leaves": {
                "total_power_W": 6900.0
            },
            "limits_to_root": {},
            "timestamp": "2024-07-17T05:34:52.016Z"
        }
    ]
}
2024-07-17 05:34:52.101397 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_set_charging_profile_req(ocpp::Call<ocpp::v201::SetChargingProfileRequest>) :: Received profile validity: Validsetting response to {
    "status": "Accepted"
}

2024-07-17 05:34:53.627015 [INFO] energy_manager:  :: Sending enfored limits (import) to :evse_manager_1 {
    "ac_max_current_A": 10.0,
    "total_power_W": 6900.0
}
2024-07-17 05:34:53.627201 [INFO] energy_manager:  :: returning optimized values vector of length 1
2024-07-17 05:34:53.627355 [INFO] energy_manager:  :: evse_manager_1 Enforce limits 10A 6900W

2024-07-17 05:37:34.852689 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Message to encode (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message": {"Header": {"SessionID": "04BEFFFD5E3E2D1F"}, "Body": {"ChargeParameterDiscoveryReq": {"RequestedEnergyTransferMode": "AC_three_phase_core", "AC_EVChargeParameter": {"DepartureTime": 0, "EAmount": {"Value": 60, "Multiplier": 3, "Unit": "Wh"}, "EVMaxVoltage": {"Value": 400, "Multiplier": 0, "Unit": "V"}, "EVMaxCurrent": {"Value": 32000, "Multiplier": -3, "Unit": "A"}, "EVMinCurrent": {"Value": 10, "Multiplier": 0, "Unit": "A"}}}}}}
2024-07-17 05:37:35.191665 [INFO] energy_manager:  ::                                NO TRADE
2024-07-17 05:37:35.191813 [INFO] energy_manager:  :: Sending enfored limits (import) to :evse_manager_1 {
    "ac_max_current_A": 10.0,
    "total_power_W": 6900.0
}
2024-07-17 05:37:35.191897 [INFO] energy_manager:  :: returning optimized values vector of length 1
2024-07-17 05:37:35.191941 [INFO] energy_manager:  :: evse_manager_1 Enforce limits 10A 6900W

2024-07-17 05:37:35.237998 [ERRO] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: In ISO15118 charger impl, after updating AC max current to 10.000000, we get 10.000000

2024-07-17 05:37:35.419301 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Sent ChargeParameterDiscoveryReq
2024-07-17 05:37:35.419390 [INFO] iso15118_charge  :: Parameter-phase started
2024-07-17 05:37:35.419529 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: IN CPM: Entered state ChargeParameterDiscovery

2024-07-17 05:37:35.421443 [INFO] iso15118_charge  :: Selected energy transfer mode: AC_three_phase_core

2024-07-17 05:37:35.421574 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: before adjusting for departure time, max_current 10.000000, nom_voltage 230, pmax 6900, departure_duration 0

2024-07-17 05:37:35.421708 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Requested departure time 0, requested energy 60000.000000

2024-07-17 05:37:35.421760 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: No departure time specified, not modifying defaults
2024-07-17 05:37:35.464370 [INFO] evse_manager_1:  ::                                     CAR ISO V2G ChargeParameterDiscoveryReq
2024-07-17 05:37:35.540813 [INFO] evse_manager_1:  :: EVSE ISO V2G ChargeParameterDiscoveryRes
2024-07-17 05:37:35.565544 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Decoded message (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message":{"Header":{"SessionID":"04BEFFFD5E3E2D1F"},"Body":{"ChargeParameterDiscoveryRes":{"ResponseCode":"OK","EVSEProcessing":"Finished","SAScheduleList":{"SAScheduleTuple":[{"SAScheduleTupleID":1,"PMaxSchedule":{"PMaxScheduleEntry":[{"RelativeTimeInterval":{"start":0,"duration":86400},"PMax":{"Multiplier":0,"Unit":"W","Value":6900}}]}}]},"AC_EVSEChargeParameter":{"AC_EVSEStatus":{"NotificationMaxDelay":0,"EVSENotification":"None","RCD":false},"EVSENominalVoltage":{"Multiplier":-1,"Unit":"V","Value":2300},"EVSEMaxCurrent":{"Multiplier":-1,"Unit":"A","Value":100}}}}}}

 ✅  Car control only:
2024-07-17 05:40:17.936464 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Message to encode (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message": {"Header": {"SessionID": "E99ADD77AEE9AB57"}, "Body": {"ChargeParameterDiscoveryReq": {"RequestedEnergyTransferMode": "AC_three_phase_core", "AC_EVChargeParameter": {"DepartureTime": 21600, "EAmount": {"Value": 60, "Multiplier": 3, "Unit": "Wh"}, "EVMaxVoltage": {"Value": 400, "Multiplier": 0, "Unit": "V"}, "EVMaxCurrent": {"Value": 32000, "Multiplier": -3, "Unit": "A"}, "EVMinCurrent": {"Value": 10, "Multiplier": 0, "Unit": "A"}}}}}}

2024-07-17 05:40:18.491092 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Sent ChargeParameterDiscoveryReq
2024-07-17 05:40:18.491239 [INFO] iso15118_charge  :: Parameter-phase started
2024-07-17 05:40:18.491390 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: IN CPM: Entered state ChargeParameterDiscovery

2024-07-17 05:40:18.492649 [INFO] iso15118_charge  :: Selected energy transfer mode: AC_three_phase_core

2024-07-17 05:40:18.492750 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: before adjusting for departure time, max_current 32.000000, nom_voltage 230, pmax 22080, departure_duration 21600

2024-07-17 05:40:18.492852 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Requested departure time 21600, requested energy 60000.000000

2024-07-17 05:40:18.492998 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Departure time specified, checking to see if we can lower requirements

2024-07-17 05:40:18.493082 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Min hours to charge 2.717391, requested departure time in hours 6, plenty of time to charge

2024-07-17 05:40:18.493173 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: lowering pmax = 10000, max_current = 15.000000, pmax float = 10000.000000
2024-07-17 05:40:18.536658 [INFO] evse_manager_1:  ::                                     CAR ISO V2G ChargeParameterDiscoveryReq
2024-07-17 05:40:18.591812 [INFO] evse_manager_1:  :: EVSE ISO V2G ChargeParameterDiscoveryRes
2024-07-17 05:40:18.642948 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Decoded message (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message":{"Header":{"SessionID":"E99ADD77AEE9AB57"},"Body":{"ChargeParameterDiscoveryRes":{"ResponseCode":"OK","EVSEProcessing":"Finished","SAScheduleList":{"SAScheduleTuple":[{"SAScheduleTupleID":1,"PMaxSchedule":{"PMaxScheduleEntry":[{"RelativeTimeInterval":{"start":0,"duration":21600},"PMax":{"Multiplier":0,"Unit":"W","Value":10000}}]}}]},"AC_EVSEChargeParameter":{"AC_EVSEStatus":{"NotificationMaxDelay":0,"EVSENotification":"None","RCD":false},"EVSENominalVoltage":{"Multiplier":-1,"Unit":"V","Value":2300},"EVSEMaxCurrent":{"Multiplier":-1,"Unit":"A","Value":150}}}}}}

 ✅  Car control only:
2024-07-17 05:42:55.825199 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_set_charging_profile_req(ocpp::Call<ocpp::v201::SetChargingProfileRequest>) :: Received SetChargingProfile: {
    "chargingProfile": {
        "chargingProfileKind": "Absolute",
        "chargingProfilePurpose": "TxDefaultProfile",
        "chargingSchedule": [
            {
                "chargingRateUnit": "A",
                "chargingSchedulePeriod": [
                    {
                        "limit": 10.0,
                        "numberPhases": 3,
                        "startPeriod": 0
                    }
                ],
                "duration": 14400,
                "id": 0,
                "minChargingRate": 0.0,
                "startSchedule": "2024-07-17T05:00:00.000Z"
            }
        ],
        "id": 1,
        "recurrencyKind": "Daily",
        "stackLevel": 1
    },
    "evseId": 0
}
with messageId: e2335550-296a-4788-945c-1ab12d9db16b
2024-07-17 05:42:55.825956 [WARN] ocpp:OCPP201    module::OCPP201::ready()::<lambda()> :: Received a new Charging Schedules from the CSMS or another actor.
2024-07-17 05:42:55.826071 [INFO] ocpp:OCPP201     :: ProfileId #1 Kind: Absolute
2024-07-17 05:42:55.826156 [INFO] ocpp:OCPP201     :: #1 find_period_at> 2024-07-17T05:00:00.000Z
2024-07-17 05:42:55.826229 [INFO] ocpp:OCPP201     ::    find_period_at>        start_time> 2024-07-17T05:42:55.826Z
2024-07-17 05:42:55.826295 [INFO] ocpp:OCPP201     ::    find_period_at> period_start_time> 2024-07-17T05:00:00.000Z
2024-07-17 05:42:55.826379 [INFO] ocpp:OCPP201     ::    find_period_at>   period_end_time> 2024-07-17T09:00:00.000Z
2024-07-17 05:42:55.826485 [INFO] ocpp:OCPP201     :: PeriodDateTimePair>  period: {
    "limit": 10.0,
    "numberPhases": 3,
    "startPeriod": 0
} end_time: 2024-07-17T09:00:00.000Z
2024-07-17 05:42:55.826542 [INFO] ocpp:OCPP201     :: period.has_value() limit = 6900
2024-07-17 05:42:55.826599 [INFO] ocpp:OCPP201     :: period.has_value() stackLevel = 6900
2024-07-17 05:42:55.826708 [INFO] ocpp:OCPP201     :: ProfileId #1 Kind: Absolute
2024-07-17 05:42:55.826780 [INFO] ocpp:OCPP201     :: #1 find_period_at> 2024-07-17T05:00:00.000Z
2024-07-17 05:42:55.826818 [INFO] ocpp:OCPP201     ::    find_period_at>        start_time> 2024-07-17T05:42:55.826Z
2024-07-17 05:42:55.826874 [INFO] ocpp:OCPP201     ::    find_period_at> period_start_time> 2024-07-17T05:00:00.000Z
2024-07-17 05:42:55.826914 [INFO] ocpp:OCPP201     ::    find_period_at>   period_end_time> 2024-07-17T09:00:00.000Z
2024-07-17 05:42:55.827017 [INFO] ocpp:OCPP201     :: PeriodDateTimePair>  period: {
    "limit": 10.0,
    "numberPhases": 3,
    "startPeriod": 0
} end_time: 2024-07-17T09:00:00.000Z
2024-07-17 05:42:55.827078 [INFO] ocpp:OCPP201     :: period.has_value() limit = 6900
2024-07-17 05:42:55.827183 [INFO] ocpp:OCPP201     :: period.has_value() stackLevel = 6900
2024-07-17 05:42:55.827403 [WARN] ocpp:OCPP201    void module::OCPP201::set_external_limits(const std::map<int, ocpp::v201::CompositeSchedule>&) :: OCPP sets the following external limits for EVSE 1:
{
    "schedule_import": [
        {
            "limits_to_leaves": {
                "total_power_W": 6900.0
            },
            "limits_to_root": {},
            "timestamp": "2024-07-17T05:42:55.827Z"
        }
    ]
}
2024-07-17 05:42:55.870185 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_set_charging_profile_req(ocpp::Call<ocpp::v201::SetChargingProfileRequest>) :: Received profile validity: Validsetting response to {
    "status": "Accepted"
}
2024-07-17 05:42:56.506056 [INFO] energy_manager:  ::                                NO TRADE
2024-07-17 05:42:56.506315 [INFO] energy_manager:  :: Sending enfored limits (import) to :evse_manager_1 {
    "ac_max_current_A": 32.0
}

2024-07-17 05:43:51.483290 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Message to encode (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message": {"Header": {"SessionID": "0738DD6AFFFFB167"}, "Body": {"ChargeParameterDiscoveryReq": {"RequestedEnergyTransferMode": "AC_three_phase_core", "AC_EVChargeParameter": {"DepartureTime": 10800, "EAmount": {"Value": 60, "Multiplier": 3, "Unit": "Wh"}, "EVMaxVoltage": {"Value": 400, "Multiplier": 0, "Unit": "V"}, "EVMaxCurrent": {"Value": 32000, "Multiplier": -3, "Unit": "A"}, "EVMinCurrent": {"Value": 10, "Multiplier": 0, "Unit": "A"}}}}}}

2024-07-17 05:43:51.503903 [ERRO] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: In ISO15118 charger impl, after updating AC max current to 10.000000, we get 10.000000

2024-07-17 05:43:52.031880 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Sent ChargeParameterDiscoveryReq
2024-07-17 05:43:52.031926 [INFO] iso15118_charge  :: Parameter-phase started
2024-07-17 05:43:52.032167 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: IN CPM: Entered state ChargeParameterDiscovery

2024-07-17 05:43:52.033775 [INFO] iso15118_charge  :: Selected energy transfer mode: AC_three_phase_core

2024-07-17 05:43:52.033891 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: before adjusting for departure time, max_current 10.000000, nom_voltage 230, pmax 6900, departure_duration 10800

2024-07-17 05:43:52.033967 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Requested departure time 10800, requested energy 60000.000000

2024-07-17 05:43:52.034149 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Departure time specified, checking to see if we can lower requirements

2024-07-17 05:43:52.034241 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Min hours to charge 8.695652, requested departure time in hours 0.000000, pmax is unchanged
2024-07-17 05:43:52.075350 [INFO] evse_manager_1:  ::                                     CAR ISO V2G ChargeParameterDiscoveryReq
2024-07-17 05:43:52.132122 [INFO] evse_manager_1:  :: EVSE ISO V2G ChargeParameterDiscoveryRes
2024-07-17 05:43:52.183445 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Decoded message (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message":{"Header":{"SessionID":"0738DD6AFFFFB167"},"Body":{"ChargeParameterDiscoveryRes":{"ResponseCode":"OK","EVSEProcessing":"Finished","SAScheduleList":{"SAScheduleTuple":[{"SAScheduleTupleID":1,"PMaxSchedule":{"PMaxScheduleEntry":[{"RelativeTimeInterval":{"start":0,"duration":10800},"PMax":{"Multiplier":0,"Unit":"W","Value":6900}}]}}]},"AC_EVSEChargeParameter":{"AC_EVSEStatus":{"NotificationMaxDelay":0,"EVSENotification":"None","RCD":false},"EVSENominalVoltage":{"Multiplier":-1,"Unit":"V","Value":2300},"EVSEMaxCurrent":{"Multiplier":-1,"Unit":"A","Value":100}}}}}}

 ✅  Real world example:
2024-07-17 05:52:13.701297 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_set_charging_profile_req(ocpp::Call<ocpp::v201::SetChargingProfileRequest>) :: Received SetChargingProfile: {
    "chargingProfile": {
        "chargingProfileKind": "Absolute",
        "chargingProfilePurpose": "TxDefaultProfile",
        "chargingSchedule": [
            {
                "chargingRateUnit": "A",
                "chargingSchedulePeriod": [
                    {
                        "limit": 20.0,
                        "numberPhases": 3,
                        "startPeriod": 0
                    }
                ],
                "duration": 43200,
                "id": 0,
                "minChargingRate": 0.0,
                "startSchedule": "2024-07-17T05:00:00.000Z"
            }
        ],
        "id": 1,
        "recurrencyKind": "Daily",
        "stackLevel": 1
    },
    "evseId": 0
}
with messageId: cc632a87-e852-4527-9c79-3468d337d2c2
2024-07-17 05:52:13.702079 [WARN] ocpp:OCPP201    module::OCPP201::ready()::<lambda()> :: Received a new Charging Schedules from the CSMS or another actor.
2024-07-17 05:52:13.702196 [INFO] ocpp:OCPP201     :: ProfileId #1 Kind: Absolute
2024-07-17 05:52:13.702241 [INFO] ocpp:OCPP201     :: #1 find_period_at> 2024-07-17T05:00:00.000Z
2024-07-17 05:52:13.702314 [INFO] ocpp:OCPP201     ::    find_period_at>        start_time> 2024-07-17T05:52:13.702Z
2024-07-17 05:52:13.702380 [INFO] ocpp:OCPP201     ::    find_period_at> period_start_time> 2024-07-17T05:00:00.000Z
2024-07-17 05:52:13.702444 [INFO] ocpp:OCPP201     ::    find_period_at>   period_end_time> 2024-07-17T17:00:00.000Z
2024-07-17 05:52:13.702525 [INFO] ocpp:OCPP201     :: PeriodDateTimePair>  period: {
    "limit": 20.0,
    "numberPhases": 3,
    "startPeriod": 0
} end_time: 2024-07-17T17:00:00.000Z
2024-07-17 05:52:13.702642 [INFO] ocpp:OCPP201     :: period.has_value() limit = 13800
2024-07-17 05:52:13.702673 [INFO] ocpp:OCPP201     :: period.has_value() stackLevel = 13800
2024-07-17 05:52:13.702794 [INFO] ocpp:OCPP201     :: ProfileId #1 Kind: Absolute
2024-07-17 05:52:13.702861 [INFO] ocpp:OCPP201     :: #1 find_period_at> 2024-07-17T05:00:00.000Z
2024-07-17 05:52:13.702939 [INFO] ocpp:OCPP201     ::    find_period_at>        start_time> 2024-07-17T05:52:13.702Z
2024-07-17 05:52:13.703029 [INFO] ocpp:OCPP201     ::    find_period_at> period_start_time> 2024-07-17T05:00:00.000Z
2024-07-17 05:52:13.703185 [INFO] ocpp:OCPP201     ::    find_period_at>   period_end_time> 2024-07-17T17:00:00.000Z
2024-07-17 05:52:13.703336 [INFO] ocpp:OCPP201     :: PeriodDateTimePair>  period: {
    "limit": 20.0,
    "numberPhases": 3,
    "startPeriod": 0
} end_time: 2024-07-17T17:00:00.000Z
2024-07-17 05:52:13.703417 [INFO] ocpp:OCPP201     :: period.has_value() limit = 13800
2024-07-17 05:52:13.703514 [INFO] ocpp:OCPP201     :: period.has_value() stackLevel = 13800
2024-07-17 05:52:13.703703 [WARN] ocpp:OCPP201    void module::OCPP201::set_external_limits(const std::map<int, ocpp::v201::CompositeSchedule>&) :: OCPP sets the following external limits for EVSE 1:
{
    "schedule_import": [
        {
            "limits_to_leaves": {
                "total_power_W": 13800.0
            },
            "limits_to_root": {},
            "timestamp": "2024-07-17T05:52:13.703Z"
        }
    ]
}
2024-07-17 05:52:13.746946 [ERRO] ocpp:OCPP201    void ocpp::v201::ChargePoint::handle_set_charging_profile_req(ocpp::Call<ocpp::v201::SetChargingProfileRequest>) :: Received profile validity: Validsetting response to {
    "status": "Accepted"
}
2024-07-17 05:52:14.744009 [INFO] energy_manager:  ::                                NO TRADE
2024-07-17 05:52:14.744212 [INFO] energy_manager:  :: Sending enfored limits (import) to :evse_manager_1 {
    "ac_max_current_A": 20.0,
    "total_power_W": 13800.0
}

2024-07-17 05:53:02.228504 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Message to encode (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message": {"Header": {"SessionID": "7D7AD7F4FFBB7BF3"}, "Body": {"ChargeParameterDiscoveryReq": {"RequestedEnergyTransferMode": "AC_three_phase_core", "AC_EVChargeParameter": {"DepartureTime": 57600, "EAmount": {"Value": 85, "Multiplier": 3, "Unit": "Wh"}, "EVMaxVoltage": {"Value": 400, "Multiplier": 0, "Unit": "V"}, "EVMaxCurrent": {"Value": 32000, "Multiplier": -3, "Unit": "A"}, "EVMinCurrent": {"Value": 10, "Multiplier": 0, "Unit": "A"}}}}}}

2024-07-17 05:53:02.775731 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Sent ChargeParameterDiscoveryReq
2024-07-17 05:53:02.775782 [INFO] iso15118_charge  :: Parameter-phase started
2024-07-17 05:53:02.775972 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: IN CPM: Entered state ChargeParameterDiscovery

2024-07-17 05:53:02.777052 [INFO] iso15118_charge  :: Selected energy transfer mode: AC_three_phase_core

2024-07-17 05:53:02.777200 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: before adjusting for departure time, max_current 20.000000, nom_voltage 230, pmax 13800, departure_duration 57600

2024-07-17 05:53:02.777277 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Requested departure time 57600, requested energy 85000.000000

2024-07-17 05:53:02.777381 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Departure time specified, checking to see if we can lower requirements

2024-07-17 05:53:02.777478 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Min hours to charge 6.159420, requested departure time in hours 16, plenty of time to charge

2024-07-17 05:53:02.777545 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: lowering pmax = 5313, max_current = 8.000000, pmax float = 5312.500000
2024-07-17 05:53:02.819216 [INFO] evse_manager_1:  ::                                     CAR ISO V2G ChargeParameterDiscoveryReq
2024-07-17 05:53:02.875625 [INFO] evse_manager_1:  :: EVSE ISO V2G ChargeParameterDiscoveryRes
2024-07-17 05:53:02.923324 [DEBG] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Decoded message (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message":{"Header":{"SessionID":"7D7AD7F4FFBB7BF3"},"Body":{"ChargeParameterDiscoveryRes":{"ResponseCode":"OK","EVSEProcessing":"Finished","SAScheduleList":{"SAScheduleTuple":[{"SAScheduleTupleID":1,"PMaxSchedule":{"PMaxScheduleEntry":[{"RelativeTimeInterval":{"start":0,"duration":57600},"PMax":{"Multiplier":0,"Unit":"W","Value":5313}}]}}]},"AC_EVSEChargeParameter":{"AC_EVSEStatus":{"NotificationMaxDelay":0,"EVSENotification":"None","RCD":false},"EVSENominalVoltage":{"Multiplier":-1,"Unit":"V","Value":2300},"EVSEMaxCurrent":{"Multiplier":-1,"Unit":"A","Value":80}}}}}}

@the-bay-kay Absolutely! There will be other opportunities to demo the more polished version, including maybe at the JO All Hands!

You should also plumb through the EAmount (either after the departure time or in parallel, depending on whatever is easier). The request is really the combination of the two - think of it in terms of phone charging if you don't have experience with EV charging: "I'm here for 4 hours and I want to fill in enough charge to get to 80%".
"I'm here for 4 hours" is not as useful; do you want to just top up a bit before you go home, or do you have plans for a long subway ride and want to make sure that you will be able to listen to music the whole way?

Ok! Coffee's made, back to it:

[ ] Step zero is adding EAmount -- while the NodeRED changes are fresh on my mind, let's quickly (🤞) hack that in.
Looking through JsEvManagerIndex, I think we're done with the changes?  It feels like that was too easy...  But I cannot see where else the mod objects are used beyond the simulation loop?  Let's pencil this in as done, and move to the next file

I'm still 80% sure we need to  car_simulatorImpl.cpp, but let's set that aside for now in the hopes that's an equally quick change

[ ] I think the last key piece is If we can connect the UI to Pyjosev and any other python modules (perhaps I'm missing something, good to be cautious!).  I think the last step will be figuring out how Pyjosev chats with JsEvManager to get values like Max Current, and then I'll need to connect the two modules together.

@the-bay-kay

I am 99% sure you don't need to change car_simulatorImpl.hpp (at least, I didn't have to last time)
I would suggest looking at the payment method as a value to pass through since you also have the example of a clean PR focused on adding it.

But great progress so far, and 🤞 that this is wrapped up soon!

When adding EAmount:

[ ] This is defined as a Complex Type in table 94, specifically a physical value.  These objects hold a value, physical unit, and physical symbol.  For the input, let's plan to have just the value, and we can tack on the Wh /  Watt-Hour after
Because these values will eventually be part of the same packet, let's set this to be sent with the departureTime.  We'll have to:

[ ] Rename the command accordingly:  Let's call this iso_set_dtea, for now
[ ] Set a protocol:  Let's say that the order is
[x] We have another tough call:  for the sake of time, I think we should still be sending this over to the carsim (JsEvManager, etc) on its own command (b/c it only is sent on Request / Response, etc.).  That being said -- if the Max Current is also part of the ChargeReqType (see ISO 15118-2 Figure 88), shouldn't these values be bundled together??  I'd like to figure that out after the dust has settled.

@shankari , quick clarifying question:  Under the hood, the EAmount represents a number of Watt-Hours.  Setting this by hand seems rather clunky -- should we make the input a percentage instead?  We could then calculate the Watt-Hours needed to reach that percentage on the back-end (though I may need some help with that process!).  Because of [V2G 742], we will already need to do some calculations to figure out the WH left in a given charge resumption, so this may be something we want to tack on.  If we want completely granular control, however, I can leave the input as the raw EAmount.

We can make the input a %, but then we would need to also allow the user to specify the battery capacity. In cars, similar to phones, you can have a wide variety of battery capacities.
What would be really cool as a future change, IMHO, would be to find a mapping between car (make, model year) and battery capacity (ideally through an API) and then allow users to specify that and the %.
Actually, I think we can do that with the EPA database if we specify miles. EPA has an MPGe or similar rating for electric cars. If we can hook into that, we can allow users to specify make, model, year and miles needed. We should then be able to calculate MPGe and then convert that back to energy. And honestly that is what makes the most sense from a user perspective - I want to make sure that I have enough miles to get to my destination.

That would be cool!  Makes sense -- for now, I'll stick with the raw EAmount for ease of implementation,
(Though ease may be the word, I don't know why setting a flow context is so finicky... Definitely still missing something lol)

OK -- I had to use change nodes to set flow contexts (I couldn't just set them from the JS, which seems bizarre to me -- everything I've read said you could do so without any initialization.....), so we've got both signal values being set now.
For bookkeeping, here's the JSON file:
flow_w_eadt.json

Ok -- the change to the index should be as simple as...
function simdata_reset_defaults(mod) {
  // More defaults...
  mod.iso_eamount = null; // null if not sent, otherwise complex type
  mod.iso_departure_time = null; // null if not sent, otherwise 32u
  // More defaults....
}

  // More Code...
  registerCmd(mod, 'iso_set_departure_time', 2, (mod, c) => {
    if(length(c.args[0]) !== 'null') {
      try { // wrap this in a try/catch to filter bad inputs
        const dt = Number(c.args[0]);
        mod.iso_departure_time = dt;
        const eamount_value = Number(c.args[1]);
        mod.iso_eamount = {"Value": eamount_value, "Multiplier": 3, "Unit": "Wh"};
      }
      catch {
        // We should add some rigerous error handling here.
        mod.iso_departure_time = null
        mod.iso_eamount = null
      }
      return // Should this return anything?  Let's say no for now.
    }
  })

Cool! Final sprint, let's hope getting the PyJosev changes is the last piece.

So close!!  Odds are I can't properly test / debug this in the next 15m, but here's the changes I've made:

Pyjosev/module.py
    def _handler_start_charging(self, args) -> bool:

        self._es.EnergyTransferMode = args['EnergyTransferMode']
        self._es.DepartureTime = args['DepartureTime'] # new
        self._es.DepartureTime = args['EAmount'] # new
        self._ready_event.set()

        return True

EXT-SWITCHEV-ISO15118/iso15118/evcc/everest/evstate.py
@dataclass
class EVState:
    # Common
    PaymentOption: str = ''
    EAmount: int = 60
    DepartureTime: int = 86400
    EnergyTransferMode: str = ''
    StopCharging = False
    Pause = False

EXT-SWITCHEV-ISO15118/iso15118/evcc/
    async def get_charge_params_v2(self, protocol: Protocol) -> ChargeParamsV2:
    # more code above...
            ac_charge_params = ACEVChargeParameter(
                departure_time=EVEREST_CONTEXT.departureTime,
                e_amount=e_amount,
                ev_max_voltage=ev_max_voltage,
                ev_max_current=ev_max_current,
                ev_min_current=ev_min_current,
            )
        else:
            ev_energy_request = PVEVEnergyRequest(
                multiplier=1, value=6000, unit=UnitSymbol.WATT_HOURS
            )
            dc_charge_params = DCEVChargeParameter(
                departure_time=EVEREST_CONTEXT.departureTime,
                dc_ev_status=await self.get_dc_ev_status(),
                ev_maximum_current_limit=self.dc_ev_charge_params.dc_max_current_limit,
                ev_maximum_power_limit=self.dc_ev_charge_params.dc_max_power_limit,
                ev_maximum_voltage_limit=self.dc_ev_charge_params.dc_max_voltage_limit,
                ev_energy_capacity=self.dc_ev_charge_params.dc_energy_capacity,
                ev_energy_request=ev_energy_request,
                full_soc=100,
                bulk_soc=80,
            )

Since I haven't tested each piece together, I don't think this is demo-quality.  I'm also not entirely convinced I've changed the EXT-SWITCHEV-ISO15118 changes correctly, I think there's got to be either (i) a way to pipe this change through an existing context variable, or (ii) a place that I'm missing the addition of the EVEREST_CONTEXT.

That does look right. I think you need to await for the calls into the EVSE_CONTEXT. Let me check in some code that will allow you to replicate my demo from today morning. You can also add some logs to verify what you are sending out 😄

@the-bay-kay you should be able to check out
https://github.com/US-JOET/everest-demo/tree/demo-with-departure-time-all-in-custom-image to run this demo
Changes to develop using it instead of just running:

On line 94, comment out the github and comment in the cp -r

Note: we should fix this so that if the {DEMO_REPO} starts with https or git we clone otherwise we copy

 92 echo "Cloning EVerest from ${DEMO_REPO} into ${DEMO_DIR}/everest-demo"
 93 # git clone --branch "${DEMO_BRANCH}" "${DEMO_REPO}" everest-demo
 94 cp -r "${DEMO_REPO}" everest-demo

Comment out the last line so that you can start and stop the manager manually

380 if [[ "$DEMO_VERSION" =~ v2.0.1 ]]; then
381   echo "Starting software in the loop simulation"
382   # docker exec everest-ac-demo-manager-1 sh /ext/source/build/run-scripts/run-sil-ocpp201-pnc.sh
383 fi

Start the manager manually by running the following command in the docker terminal

sh /ext/source/build/run-scripts/run-sil-ocpp201-pnc.sh

Edit anything in /ext/source/modules or build/dist/libexec/everest/3rd_party/josev/iso15118/ for the EV simulator and restart (javascript and python don't require recompile)

It seems I misunderstood the process of exporting flows -- the JSON files I exported don't contain all of the changes I made... All of the module updates have been made, I just need to rewrite the UI nodes again 🤦  Shouldn't take too long...

If nothing else, this has been a trial-by-fire for Node-RED 😅  Note to self: next time you're exporting an important flow, be sure to export the entire project... Otherwise, you may have to re-write your entire UI...   Well, killed an hour, but we're back to where we were!  Time to finally integrate...

The button I missed

The file: ALL_FLOWS_eadt_integration.json

Modifying /ext/source/modules/simulation/JsEvManager/index.js, I'm not seeing any of the logs I've added.  I do, however, see the logs from other functions within this file (see the code example under the cut).  Is this the right file?  It seems that the changes aren't registered when I restart the manager...

 Code containing logs

Looking for other places we can find JsEvManager, we find...
/ext/source/modules/simulation/JsEvManager # find / -type d -name JsEvManager
/ext/source/build/dist/libexec/everest/modules/JsEvManager
/ext/source/build/modules/simulation/JsEvManager
/ext/source/modules/simulation/JsEvManager

My next thought was to modify /ext/source/build/dist/libexec/everest/modules/JsEvManager/index.js -- if I make a typo in this file, we fail to restart the manager (this makes me assume this is our file of interest).  When editing this file, however, we begin to hang on the "Preparing Charging" phase.  Please see the video below for additional context.
Aha -- this might be an issue...
2024-07-23 18:26:23.288800 [WARN] car_simulator_1 EverestJs::Init(Napi::Env, Napi::Object)::<lambda(const Napi::CallbackInfo&)> :: Ignoring command iso_set_departure_time with 2 arguments

Why is this getting ignored? Time to find out...

Video of Freeze on "Prepare Charging"
https://github.com/user-attachments/assets/9e01c5f8-61e9-4bb3-be25-da8361ac90e1

Tracing through the code, it seems the command ignore occurs at parseSimCommands(mod, str) {}
function parseSimCommands(mod, str) {
// Code above
  const c = mod.registeredCmds[cmdname];
  if (c === undefined || args.length !== c.numargs) {
    evlog.Warning(`Ignoring command ${cmdname} with ${args.length} arguments`)
  }
}

So, let's look at the two conditions:  Looking at the error in the previous post, it says the ignored command took two arguments.  Looking at our registered command, we should be correctly setting numargs:
  registerCmd(mod, 'iso_set_departure_time', 2, (mod, c) => {
    evlog.debug(`iso_set_departure_time: c.args is: ${c.args}`);

    try { // wrap this in a try/catch to filter bad inputs
      const dt = Number(c.args[0]);
      mod.iso_departure_time = dt;
      const eamount_value = Number(c.args[1]);
      mod.iso_eamount = {"Value": eamount_value, "Multiplier": 3, "Unit": "Wh"};
    }
    catch {
      mod.iso_departure_time = 86400;
      mod.iso_eamount = 60;
    }

    evlog.debug(` mod.iso_departure_time is: ${mod.iso_departure_time}`);
    evlog.debug(` mod.iso_eamount is: ${mod.iso_eamount}`);

    return // Should this return anything?  Let's say no for now.
  });

So, my guess is that we are not correctly registering this command.  The name seems correct, numargs is correct -- Clearly I'm missing a step

Before I get into furhter exploration, I will be moving forward with editing /ext/source/modules/simulation/JsEvManager/index.js, as it is the file I've seen changes registered (placing logs in parseSimCommands show up here, and not when changed in other versions of this file).
Now, to continue untangling this bug. In some shape or form, the command is being sent to the simulator.  We have the following logs...
2024-07-23 20:35:06.623620 [INFO] car_simulator_1  :: {
  cmd: 'iso_set_departure_time',
  args: [ 3601, 2 ],
  exec: [Function (anonymous)]
}

Which appear to come from the next_command function.  From what I can tell, this call is then coming from simulation_loop.  So, we're at least successfully passing the command from Node-RED into the loop!  Tiny victories.
Let's see what form this command takes. , next_command advances the loopCurrentCommand, and then runs current_command, which retrieves mod.simCommands[mod.loopCurrentCommand];.   As we know, simCommands is set with parseSimCommands...  Which is where we got the ignore command issue before... Are we actually parsing this function properly? Or are we ignoring it? Which is it?!  Let's take a step back for a minute, and record these logs more methodically...

I'm still unsure how we got that command in the SimCommands -- going back and adding the dummy signature...
  registerCmd(mod, 'iso_set_departure_time', 2, (mod, c) => {
    evlog.info(`Katie: c.args is: ${c.args}`);
  });

We still receive the same error...
2024-07-23 21:42:24.596009 [WARN] car_simulator_1 EverestJs::Init(Napi::Env, Napi::Object)::<lambda(const Napi::CallbackInfo&)> :: Ignoring command iso_set_departure_time with 2 arguments

My assumption was:

We register iso_set_departure_time in registerAllCmds
When the command sequence is set from Node_RED / MQTT, this parsed command is then matched to the list of registered commands

Looking at the code, I cannot find any additional command registration steps... But, because the command is being ignored, we can assume I do not correctly understand the command registration process.  Let's step way back, and see how other commands were implemented.

Implementing a dummy version of my command...
registerCmd(mod, 'iso_set_departure_time', 2, (mod, c) => {
    evlog.info(`Katie: c.args is: ${c.args}`);
  });

We run into the same looping issue....  The only thing I can think of is to add a "return true", as I can see that in several of the other commands, and I did not include it before link

return // Should this return anything?  Let's say no for now

So, what happens if we tack on a return true? The code executes fine! Note to past me: we should have said yes 🤦 Let's update my code and see if it works now

Yuo, that was my issue... Below is the latest iteration of the command: Time to start debugging the remaining functions!

New command registration
registerCmd(mod, 'iso_set_departure_time', 2, (mod, c) => {
    try {
      mod.iso_departure_time = Number(c.args[0]);
      mod.iso_eamount = Number(c.args[1]);
    }
    catch {
      evlog.warning(`Incorect input to iso_set_departure_time, non-int value passed in! `);
      mod.iso_departure_time = 86400;
      mod.iso_eamount = 60;
      return false;
    }
    evlog.info(`iso_departure_time is: ${mod.iso_departure_time}`);
    evlog.info(`iso_departure_time is: ${mod.iso_eamount}`);
    return true;

});

Ok, baby steps: Attempting to add the following code to /ext/source/build/dist/libexec/everest/modules/PyEvJosev/module.py
    def _handler_start_charging(self, args) -> bool:

        self._es.EnergyTransferMode = args['EnergyTransferMode']
        self._es.DepartureTime = args['DepartureTime'] # New Variable
        self._es.EAmount = args['EAmount'] # New Variable

        log.debug('PyEVJosevModule: Departure Time is %s' % self._es.DepartureTime)
        log.debug('PyEVJosevModule: EAmount is %s' % self._es.DepartureTime)

        self._ready_event.set()

        return True

Results in the following critical failure when we attempt to start charging....

Yikes! Though, frankly, expected -- I think I need to be modifying more of the files in Pyjosev's iso15118 before we run this -- it's not a "one file per" addition, like we could do with JsEvManager.  (E.g., I think we need to modify simulator.py and the others before this works).  Will update this evening!

I was close -- we need to define these values in ev_states.py, not simulator.py, before using them in modules.py.  Adding the following code allows us to successfully plug in and charge.  Woot! Now we just need to hook these values up to the functions in simulator.py, and we should be good to go

 `ev_states.py` changes
# SPDX-License-Identifier: Apache-2.0
# Copyright 2020 - 2023 Pionix GmbH and Contributors to EVerest
from dataclasses import dataclass, field

DEFAULT_DC_MAX_CURRENT_LIMIT_A = 300
DEFAULT_DC_MAX_POWER_LIMIT_W = 150000
DEFAULT_DC_MAX_VOLTAGE_LIMIT_V = 900
DEFAULT_ENERGY_CAPACITY_WH = 60000
DEFAULT_TARGET_CURRENT_A = 5
DEFAULT_TARGET_VOLTAGE_V = 200

@dataclass
class EVState:
    # Common
    PaymentOption: str = ''
    EAmount: int = 60
    DepartureTime: int = 86400
    EnergyTransferMode: str = ''
    StopCharging = False
    Pause = False

    # DC
    dc_max_current_limit: float = DEFAULT_DC_MAX_CURRENT_LIMIT_A
    dc_max_power_limit: float = DEFAULT_DC_MAX_POWER_LIMIT_W
    dc_max_voltage_limit: float = DEFAULT_DC_MAX_VOLTAGE_LIMIT_V
    dc_energy_capacity: float = DEFAULT_ENERGY_CAPACITY_WH
    dc_target_current: float = DEFAULT_TARGET_CURRENT_A
    dc_target_voltage: float = DEFAULT_TARGET_VOLTAGE_V

    # DC BPT
    dc_discharge_max_current_limit: float = 0
    dc_discharge_max_power_limit: float = 0
    dc_discharge_target_current: float = 0

    # SAE J2847/2
    SAEJ2847_V2H_V2G_Active = False
    minimal_soc = 20

    def reset(self):
        self.StopCharging = False
        self.Pause = False

Hm, at first I thought I only needed to modify evcc/controller/simulator.py... On closer inspection, it seems secc/controller/py also utilizes departure time values... I should read further into the changes made to see which files I need to connect to.

Running grep -Rnw '/ext/source/build/dist/libexec/everest/3rd_party/josev/' -e 'departure_time' results in the output of the following files (those marked I have already inspected / edited).  Each file has the prefix /ext/source/build/dist/libexec/everest/3rd_party/josev/iso15118/...

[x] shared/messages/iso15118_2/common_messages.py

The data type is correct, we shouldn't need to touch this

[x] shared/messages/iso15118_20/common_messages.py

As above, will 2x check these two.

[ ] secc/states/iso15118_2_states.py
[ ] secc/controller/simulator.py
[ ] secc/controller/interface.py
[ ] secc/controller/ev_data.py

At a glance, I believe we will be able to ignore this one, but let's actually read through and make sure before crossing it off.

[ ] evcc/controller/simulator.py

So, that leaves us with 5 files to check... I've already modified evcc/everest/ev_states.py and  /ext/source/build/dist/libexec/everest/modules/PyEVJosev/module.py... Let's work down the list and see what we need to change

Unlike my previous attempt at writing this, it seems our context variable is EVEREST_CHARGER_STATE, not EVEREST_EV_STATE.  I think that was my issue -- let's see if we can't slot those values in

Just crossing my i's and dotting my t's -- the Field aliases for DepartureTime are already set, so we won't have to worry about those... So we should be able to access the departure time as such? Let's see

Looking at paymentMethod, we also edit the secc... Do we need to do this?  E.g., should we add the following:
async def get_evse_departure_time(self) -> int:
        return EVEREST_CHARGER_STATE.DepartureTime

    async def get_evse_eamount(self) -> int:
        return EVEREST_CHARGER_STATE.EAmount

I'm unsure -- let's go ahead and do so for now.
Next, we move on to /evcc/simulator.py.  Let's update the aformentioned functions as follows...

 simulator.py changes
async def get_charge_params_v2(self, protocol: Protocol) -> ChargeParamsV2:
  # More code...
  ac_charge_params = ACEVChargeParameter(
                departure_time=EVEREST_EV_STATE.DepartureTime,
                e_amount=EVEREST_EV_STATE.EAmount,
   # More code...
   ev_energy_request = PVEVEnergyRequest( # Should this be changed to match EAmount? Need to investigate
                multiplier=1, value=6000, unit=UnitSymbol.WATT_HOURS
            )
            dc_charge_params = DCEVChargeParameter(
                departure_time=EVEREST_EV_STATE.DepartureTime,

     # More code...
    async def get_scheduled_se_params(
        self, selected_energy_service: SelectedEnergyService
    ) -> ScheduledScheduleExchangeReqParams:
    # Etc...
        scheduled_params = ScheduledScheduleExchangeReqParams(
                departure_time=EVEREST_EV_STATE.DepartureTime,
                # Etc...

    async def get_dynamic_se_params(
        self, selected_energy_service: SelectedEnergyService
    ) -> DynamicScheduleExchangeReqParams:
        """Overrides EVControllerInterface.get_dynamic_se_params()."""
        dynamic_params = DynamicScheduleExchangeReqParams(
            departure_time=EVEREST_EV_STATE.DepartureTime,

      # Dynamic Mode
        dynamic_params = DynamicACChargeLoopReqParams(
            departure_time=EVEREST_EV_STATE.DepartureTime,
            # etc...

     async def get_charge_params_v2h(self, protocol: Protocol) -> ChargeParamsV2:
     # more code...
         dc_charge_params = DCEVChargeParameter(
                departure_time=EVEREST_EV_STATE.DepartureTime,

I think we need to switch a few of the PVEamounts, but let's start with this for now...

The good news -- this change doesn't crash!
The bad news -- this change doesn't seem to have propagated through...

What am I missing here?  Let's investigate further

Let's work from the top down now:

Where is AC_EVChargeParameter set?  In iso15118/shared/messages/iso15118_2/body.py, which is a field alias for ac_charge_parameter.

This then comes from our old friend, evse_data.py : This is done in the function call update_ac_charge_parameters_v2, which is called by

iso15118_2_states.py, in the function process_message.  That's new!

This process_message command checks for a charge_params_req.ac_charge_params, set by msg.body.charge_parameter_discovery_req.

So, let's look for where this discovery req comes from...

The 85 here is a good hint as to where our issue is.  Searching in the evcc/simulator.py, we find the only 85 is in the following function:
> ![image](https://private-user-images.githubusercontent.com/98350084/351761299-94f7d171-8c8d-41b8-aa15-ef5da3d334cf.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjE4MzI4MzIsIm5iZiI6MTcyMTgzMjUzMiwicGF0aCI6Ii85ODM1MDA4NC8zNTE3NjEyOTktOTRmN2QxNzEtOGM4ZC00MWI4LWFhMTUtZWY1ZGEzZDMzNGNmLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzI0VDE0NDg1MlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTdjZDU4ZDM0MmJlNzk2MzZmYTQ2N2E0ZWYzZWNmNGUwNzMwODY2M2Y4N2MyYjc0NzdmNzllMjU0YTU4NGI3Y2MmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.da7piBh0YhhxF2lARoqT1jPF6ZP0dcLZT92yolZM-nQ)

The `85` in the default EAmount value gives us a hint as to where our issue is.  Looking through `simulator.py`, we find the only `85` to be in the following:
```python
> ![image](https://private-user-images.githubusercontent.com/98350084/351761299-94f7d171-8c8d-41b8-aa15-ef5da3d334cf.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjE4MzI4MzIsIm5iZiI6MTcyMTgzMjUzMiwicGF0aCI6Ii85ODM1MDA4NC8zNTE3NjEyOTktOTRmN2QxNzEtOGM4ZC00MWI4LWFhMTUtZWY1ZGEzZDMzNGNmLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzI0VDE0NDg1MlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTdjZDU4ZDM0MmJlNzk2MzZmYTQ2N2E0ZWYzZWNmNGUwNzMwODY2M2Y4N2MyYjc0NzdmNzllMjU0YTU4NGI3Y2MmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.da7piBh0YhhxF2lARoqT1jPF6ZP0dcLZT92yolZM-nQ)

The `85` in the default EAmount value gives us a hint as to where our issue is.  Looking through `simulator.py`, we find the only `85` to be in the following:
```python
    async def get_charge_params_v2(self, protocol: Protocol) -> ChargeParamsV2:
        """Overrides EVControllerInterface.get_charge_params_v2()."""
        ac_charge_params = None
        dc_charge_params = None

        if (await self.get_energy_transfer_mode(protocol)).startswith("AC"):
            e_amount = PVEAmount(multiplier=3, value=85,
                                 unit=UnitSymbol.WATT_HOURS)
            ev_max_voltage = PVEVMaxVoltage(

Aha.  So, it appears we need to set the departureTime here as well, let's fix that

Wait -- we set the departure time in this function!
if (await self.get_energy_transfer_mode(protocol)).startswith("AC"):
            e_amount = PVEAmount(multiplier=3, value=85,
                                 unit=UnitSymbol.WATT_HOURS)
            ev_max_voltage = PVEVMaxVoltage(
                multiplier=0, value=400, unit=UnitSymbol.VOLTAGE
            )
            ev_max_current = PVEVMaxCurrent(
                multiplier=-3, value=32000, unit=UnitSymbol.AMPERE
            )
            ev_min_current = PVEVMinCurrent(
                multiplier=0, value=10, unit=UnitSymbol.AMPERE
            )
            ac_charge_params = ACEVChargeParameter(
                departure_time=EVEREST_EV_STATE.DepartureTime,
                e_amount=EVEREST_EV_STATE.EAmount,
                ev_max_voltage=ev_max_voltage,
                ev_max_current=ev_max_current,
                ev_min_current=ev_min_current,
            )

Why aren't we getting a new value from `EVEREST_EV_STATE.DepartureTime ?!?  Good to know we can read that value, but we're not setting it correctly, darn.  At least we have a lead

So, looking at iso15118_2_states.py:
departure_time = (
            ev_data_context.departure_time if ev_data_context.departure_time else 0
        )

        if not departure_time:
            departure_time = 0
        else:
            # EVerest code start #
            d_Time_utc = datetime.utcnow() + timedelta(seconds=departure_time)
            format = "%Y-%m-%dT%H:%M:%SZ"  # "yyyy-MM-dd'T'HH:mm:ss'Z'"
            EVEREST_CTX.publish('DepartureTime', d_Time_utc.strftime(format))
            # EVerest code end #

I guess I stopped reading at the first ev_data_context.  Yeah, let's publish DepartureTime as an int and see if that fixes things

Well, had to take a step back.  I'm assuming I messed up copying over some of my altered files.  We're receiving the same error as before...

Except both ev_state.py and module.py have been changed, as before.  Maybe I forgot to copy over module.py... Let's start adding things back one at a time, and do this methodically.

Let's trace this back:

When we call self._es.DepartureTime =args['DepartureTime'], the self is a JOSEV_context from /evcc/context.py.

Then, the _es is an EVState, which is defined in /evcc/ev_state.py....

...Which we've edited already, and have defined DepartureTime as follows:@dataclass
  class EVState:
      # Common
      PaymentOption: str = ''
      EAmount: int = 60
      DepartureTime: int = 86400

How is this different from the PaymentOption?? I've already ruled out the AuthNum changes, as I believe there is not an equivalent change that we need to make... Will keep digging

So, let's run an experiment...  If we comment out the currently working PaymentOption...
@dataclass
  class EVState:
      # Common
      # PaymentOption: str = ''
      EAmount: int = 60
      DepartureTime: int = 86400

And then re-run the code, we charge without issue... So we know this isn't the critical piece.  Where else is PaymentOption used?

Let's look for the files where PaymentOption is used (link), and make a list of files that we can ignore:

ev_state.py: We're already looking at this file
secc/controller/simulator.py: ditto
secc/controller/ev_data.py: Notable, as this is what seems to be setting the context variables.  We pass through the SASScheduleTuple, which I believe is already handled.
secc/comm_session_handler.py: This is a utilization of PaymentOption, not a definition utilizing it (auth handler)
secc/states/iso15118_2_states.py: Payment is used within PaymentServiceSelection, not relevant
secc/states/din_spec_states.py: Ditto
shared/messages/iso15118_2/datatypes.py: departure_time is already defined (?)
tests/*

On the list of potential suspects:

shared/messages/din_spec/datatypes.py
secc/everest/charger_station.py
`shared/messages/din_spec/body.py
evcc/comm_session_handler.py
shared/messages/iso15118_2/body.py

So, without another lead, let's go down the list...

Progress!  Modifying charger_state.py to add DepartureTime: 86400 seems to have worked!  Now, we can run the plug & Charge without issue.
To recap the status of the integration:

[x] JsEvManager/index/js
[x] PyEvJosev/module.py
[x] .../secc/everest/charger_state/py
[ ] .../secc/controller/simulator.
[ ] .../secc/controller/simulator.py

I would not expect that you need to change any of the SECC code. I didn't have to change any of it when I set the departure time by editing files.

I would not expect that you need to change any of the SECC code. I didn't have to change any of it when I set the departure time by editing files.

That was my assumption as well -- I'm somewhat unsure as to why this issue was happening, but I think I've solved it.
Changing onlymodule.py, evcc/ev_state.py and evcc.simulator.py , the simulator is running, but the departure time change isn't propagating:

 Screenshots

The good news: Changing the default in ev_state.py does work... why aren't we getting the signal from the UI??

I was so sure I was missing something on the (iso15118)[https://github.com/EVerest/ext-switchev-iso15118/tree/7f16c4b2c1307ce73798215f34b8fe06862bbae1] side of things, I forgot to really trace through module.py 😅 I'm 95% sure this is my issue.
As currently written, we're trying to gather the departure time as follows:
    def _handler_start_charging(self, args) -> bool:
        log.info(str(args))
        self._es.EnergyTransferMode = args['EnergyTransferMode']
        self._es.DepartureTime = args['DepartureTime']
        self._es.EAmount = args['EAmount'
# ..

Having added this log, we find that the args are:
[{'EnergyTransferMode': 'AC_three_phase_core', 'PaymentOption': 'Contract'}]

Can't exactly fetch what isn't there... Let's see where the args is set

Ok, tracing the code:

_handler_start_charging is defined in module.py, but not called here.  Rather, this is a member function of the PyJosevModule class.
We then instantiate an object of this class, call start_evcc_handler(), which in turn calls evcc_handler_main_loop, which instantiates an EVCCHandler(), running its start function.  So, let's track that down in the ext-switch-iso15118 repo
evcc/__init__.py shows us that EVCCHandler inherits from CommunicationSessionHandler, and calls start_session_handler...

I'll keep going from here, but it feels like I'm starting to lose the forest for the trees.  I just can't find where the handler_start_charging is called -- if we can find where those args are passed in, I think I'll better understand why we're not receiving the other data

Aha!  I had been confused as to the relationship between JsEvManager and PyJosEv until now -- I suppose that is because I didn't read through index.js carefully enough... As we can see on this line, we pass the args in here!  That seems to be what I missed, lets go ahead and patch that.

Making the aforementioned changes, we can now the default in index.js and watch it propagate completely!  Currently, we have:

[x] Node-red talks to the registerCmd(mod, iso_set_departure_time`)
[ ] Set departure time is not successfully setting the departure time before
[x] The EAMount / DepTime (currenty, default) is passed to module.py, which
[x]  passes the values to ev_state.py and simulator.py
So, let's check off that last box

It seems the order of our commands is slightly out-of-wack... Looking at the logs:

The values are being sent to module.py before set_departure_time is processed in the simulation loop.  Perhaps we need to update the order in our UI command sequence?

Success!!  Just needed to deploy the flow changes, and that was the final piece.  Will edit this comment with videos of the changes in each permutation, and then include the files / how to run after.

Working on reproducibility now -- the above videos show it running, currently attempting to add the files to a fresh install & make the demo run smoothly.  Will update with instructions once I have a reproducible demo!

Now that we have a working demo, we can pivot to incorporating the SetChargingProfile functionality.  Modifying the demo script maeve-set-charging-profile.sh as follows...
# Adding a -v for debugging...
curl -v -X POST \                                                                                "http://localhost:9410/api/v0/cs/${CS}/setchargingprofile" \                                                                                -H "Content-Type: application/json" \                                                                                -d "$JSON_DATA"

Shows us that the issue is indeed with the post.  Running the script with one of our Charging Profiles (with a properly adjusted timestamp), we get the following output:

I believe our issue is the second half of this... let's investigate further

Yup: Looking at the maeve-csms-manager-1 logs, looks like our POST is happening OK...

Let's dig into the files and see why we're not reading this

Wait, this is using 001 instead of cp001?!

Wait, this is using 001 instead of cp001?!

OH!  Good catch lol -- yup, that was the issue.  At least it's an easy fix... 😅

Demos are now working with a default values {EA=60, DepartureTime=86400}.  Now, the twist is making DepartureTime (DT) optional, as per [V2G2-361].  To do this, we need to:

[x] Change the NodeRed to send an empty DT value by default (we use an empty string)
[x] In JsEvManager, we now fill in "Null" as the type for DT if no value is given
[x] iso15118/evcc/ev_state.py now has the DT Default as Optional[int] = None
[ ] In iso15118/evcc/ev_state.py, only add the DT field to ACChargeParameter if DT has been specified

Once these are (i) implemented and (ii) confirmed to be working, the plan is to:

[ ] Create an image via docker commit,
[ ] Take this image, add it to GHCR and tag it
[ ] Commit the changes to the demo branch
[ ] Open PRs for the corresponding modules*

After these are done, we can move forward with updating the demo.
*Merging the demo to the main branches may be tricky, because I believe our PaymentMethod strategy in our demo differs from what is currently implemented (link to relevant discussion).  Will cross that bridge when we come to it!

Taking some time to clean up my code and refactor while making these changes.  We have a design decision to make:  When should we filter out an empty DepartureTime?
My first though was to do so in the iso15118/evcc/simulator.py call -- I believe this is the most logical answer, as this is the final layer between the Python & C++ code.  That being said, we could  check for null and not include this value within mod.uses_list.ev[0].call.start_charging(args);, located in JsEvManager/index.html.  I don't think this is as valuable (I think we'd still need to update the typing to optional in EvState.py), but I think the thought was worth recording.

Ah - it seems that passing in the null value was enough, we don't need to tweak iso15118/evcc/simulator.py:

Since this is functionally what we want, and we want a working demo up asap 'll go ahead and commit the image to ghcr.

Aside: I'm not 100% satisfied with our working solution.  Per [V2G2-361] of ISO 15118-2, DepartureTime is an optional extension of the AC_EVChargeParameterType.  As written, we send an empty DT as DepartureTime: Null.  This is then interpreted in as "No DepartureTime was set".  While functionally identical, this is not the same as excluding the DepartureTIme field entirely.
Perhaps I'm splitting hairs, but I think our implementation should hug as closely to the spec as possible.  This is fine for a hack-y proof of concept, but I think we should re-factor this to better match the spec.  I've got some thoughts on how we'd do so, but I can save that for the PR discussion (this issue has gotten quite bulky as is!)

I've got an image successfully build, but am running into some hiccups adding it to the demo's us-joet repo.  I've successfully pushed a copy to my personal account (link), but I can only link to repos I own (which makes sense).  Attempting to push to us-joet/everest-demo/manager results in a "403: Forbidden" error.  Perhaps this is an issue with my token authorization? My token doesn't have a "configure SSO" option, I'll dig further

 Screenshot of Error

@the-bay-kay this is almost certainly a permissions issue. Since this is a temporary stage anyway, you can just make your package be public and point to it. We can then fix the permissions before the final version.

The latest image can be found here -- just tested with a completely fresh install, seems to work perfectly!  Will push the changes to everest-demo, then we can close this issue and move onto the more complex changes involving the SAScheduleList.

@shankari the PR for these changes has been made! Will start moving these changes into individual demo-wrapup PRs, as we did with the initial CharIn changes.

@the-bay-kay we probably want to move on to the full demo before that for two reasons:

we still haven't resolved the previous demo wrap ups
we aim to have the full demo done in a month, which is already a bit tight

We now have a demo of the departure time using the lowest_viable_power algorithm, so closing this issue.
We will track the next stage of this - supporting multiple options that the EV will choose between, in a different issue.


tree items with many children hang browser

https://nda.ya.ru/t/D4Zkbcn176xy6F

Previously all child items was dispatched to store in 1 dispatch: https://github.com/ydb-platform/ydb-embedded-ui/blob/6a3a5949ccccbe053e063276648ad4322ff9c063/src/containers/Tenant/Schema/SchemaTree/SchemaTree.tsx#L54
Currently, there is a dispatch for every child item: https://github.com/ydb-platform/ydb-embedded-ui/blob/main/src/store/reducers/schema/schema.ts#L84
Appeared after this PR: https://github.com/ydb-platform/ydb-embedded-ui/pull/948


Dbeaver connects to mysql to check the partition, which interface is called?

Description
If I want to add a data source, the bottom layer uses the mysql driver, and I want to change the logic of obtaining the partition information of the table, how will I modify it?

DBeaver Version
23.1.3
Operating System
macos
Database and driver
No response
Steps to reproduce
No response
Additional context
No response

Hello @liujiwen-up

I want to change the logic of obtaining the partition information of the table

How exactly do you want to change this info?

It's been a while since no update here. If the issue is still actual please let me know and provide additional information.


Add full Org member / collaborator to Terraform file/s for chubberlisk

Hi there
This is the GitHub-Collaborator repository bot.
The collaborator chubberlisk was found to be missing from the file/s in this pull request.
This is because the collaborator is a full organization member and is able to join repositories outside of Terraform.
This pull request ensures we keep track of those collaborators and which repositories they are accessing.
Edit the pull request file/s because some of the data about the collaborator is missing.

will do it manually


Feature request: Rust Cargo.toml dependencies auto completion

Right now it is not possible to see which crates from crates.io are available underneath [dependencies] table in Cargo.toml.
Is there any plan to include this feature in the project's future roadmap?
If so, I don't mind working on it.

There is no active work planned so you would indeed need to implement it.
I'm a bit worried of such feature increasing the risk of users falling for typosquat attacks. It's easy to auto-complete the wrong crate. See https://blog.phylum.io/rust-malware-staged-on-crates-io/ for examples. Ideally the auto-completion should sort the results by decreasing download or something like that.
(Note that this looks related to #472 and might share some code.)

I don't think it's our responsibility to provide such completions. Taplo should provide only what is given by schema, and any other additional information should be done via specialised extension/tooling (e.g.: https://github.com/serayuzgur/crates).

Hey @ia0, do you mind helping me setup the project to atleast run the extension. Once I launch the extension I get a connection client error for some reason.

I'm not sure what you mean. You already can run the extension according to the bug report. Maybe you mean a custom development version? In that case (assuming Linux) you would need to change your PATH to also contain your target/debug or target/release directory, and restart your editor.

Yes for a development. I am using a mac but should be simliar. Here are the steps I followed:

Cloned repo
Added directories to my PATH in my ~/.zshrc

export PATH=$PATH:$HOME/dev/repos/taplo/target/debug
export PATH=$PATH:$HOME/dev/repos/taplo/target/release

Ran yarn install && yarn build inside taplo/editors/vscode
Launched the extension from vscode launch.json file
Than I run into this error when I try to change the schema:

https://github.com/tamasfe/taplo/assets/89588024/a9b3439b-1041-4ae4-ac44-46125aa912cf
This has something to do with the lsp not being able to connect but I can't seem to figure it out. Am I missing something?

I don't know VS Code, but the PATH is in the wrong order, you want to search in the custom directories first:
export PATH=$HOME/dev/repos/taplo/target/debug:$PATH
export PATH=$HOME/dev/repos/taplo/target/release:$PATH

Closing since it's out of scope for the project.


define a maximum concurrency level

We currently spawn as many things concurrently as we can, and as seen in #8 this can cause 3-stooges syndrome where tasks start timing out even though each one individually could easily resolve in time. We should have some upper limit on concurrency to manage this, or... do something more robust.


Swift 5.7.1 not available

Describe the bug
When running the action with swift-version 5.7.1 one gets the error Error: Version "5.7.1" is not available.
Is this a question of just adding that released version to swift-versions.ts and then it would just work?
Workflow configuration (please complete the following information):

Action version (uses): swift-actions/setup-swift@v1
Platform (runs-on): ubuntu-latest and macos-latest
Swift version (swift-version): 5.7.1

Ah, I just saw https://github.com/swift-actions/setup-swift/pull/499

Do I understand that #499 is blocked on windows problems? Is there any chance to get the update out at least for other platform in the meantime?

I don't think it's blocked on windows support, I just pushed to the PR again to not bump windows for now

Fixed in #499 and released as 1.20.0 🎉


[Bug]: Behaviors are not used in SimpleManager

What happened?
FastJ's current implementation of SimpleManager does not use Behaviors whatsoever. There is no place in which behaviors are updated, or initialized, nor destroyed.
How to Reproduce the Error
1. Add a behavior to any game object in a SimpleManager
2. Run the program
3. See error

FastJ Version
1.5.0 (Latest Version)
Java Version
Java 11, Java 16
Relevant Exceptions/Log Output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hi there... about this issue, couldn't all game managers extend an abstract game class that contains the init(), update() and such functions? The main game loop can then run the abstract class functions for which the main game class is passed as an instance..

Hi there... about this issue, couldn't all game managers extend an abstract game class that contains the init(), update() and such functions? The main game loop can then run the abstract class functions for which the main game class is passed as an instance..

That's how the current solution runs, yes. The LogicManager interface defines the methods that all logic managers need to handle.
My thoughts are to require methods that handle behaviors, so that they could then be called by the game loop. This works for both SimpleManager and SceneManager (this can just call the handler methods of the current scene).


V1.3 support model to edit entry

@jazerler You might want to look into it and use it in logic.  close #119

Codecov Report

Merging #125 into master will decrease coverage by 0.08%.
The diff coverage is 53.84%.

@@             Coverage Diff              @@
##             master     #125      +/-   ##
============================================
- Coverage     67.07%   66.99%   -0.09%
- Complexity      568      571       +3
============================================
  Files           100      100
  Lines          2032     2045      +13
  Branches        215      217       +2
============================================
+ Hits           1363     1370       +7
- Misses          580      585       +5
- Partials         89       90       +1

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/seedu/address/model/Journal.java
74.35% <0.00%> (-4.02%)
13.00 <0.00> (ø)

src/main/java/seedu/address/model/Model.java
100.00% <ø> (ø)
1.00 <0.00> (ø)

...rc/main/java/seedu/address/model/ModelManager.java
91.89% <0.00%> (-3.89%)
30.00 <0.00> (ø)

...a/seedu/address/model/journal/UniqueEntryList.java
93.10% <87.50%> (-2.14%)
15.00 <3.00> (+3.00)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ee8006c...b31bbc6. Read the comment docs.


Improved RegexValidator documentation

I've found myself wondering a few times over the years whether it uses re.search() or re.match(), so make that explicit. Also extract the behavior description above the attribute descriptons, and provide more links to the regex documentation.

I say over the years quite truthfully.. I found a note-to-self from 22 June 2016 to make this docs change 😅

@adamchainz Thanks :+1:


[Bug] Voice Activity icon doesn't change to mute if user is server-muted

Addon Name and Version
VoiceActivity 1.5.1
Discord Version
Stable 153481 (c00173e)
Describe the bug
If a user is in a voice channel but is server-muted, then the icon added by VoiceActivity is still the speaker icon instead of the mute icon.
In the below screenshot, the voice users in the member list, from top to bottom:

user who is server-muted
user who is server-muted
mod who is self-muted
mod who is unmuted
user who is server-muted

However, they all show the speaking/unmuted icon except for the mod who is manually muted.
To Reproduce
Server mute a channel and then look at the member list
Screenshots

Thanks for the report! I’ll take a look at it when I get back to my computer.


:hp-image: Attribute in Readme.adoc is incorrect.

Hi @anthonny
According to the docs, this is how you declare a blog post cover image:
= Build API Docs for the RHQ Project
:hp-tags: Maven, RHQ, API Docs
:hp-image: http://github.com/jaredmorgs/jaredmorgs.github.io/images/covers/open_source.jpg
:published_at: 2015-02-16

Based on other images I've used in my blogs, you need to declare this as:
:hp-image: http://jaredmorgs.github.io/images/covers/open_source.jpg
This works for me on jaredmorgs.github.com.
I've created this PR to fix the issue.
I also cleaned up the other parameter descriptions.

Can also declare by relative path right?
this works for me - covers/open_source.jpg

@adi-ads :+1: