Hyprland always crashes on launch

Hyprland Version
 System/Version info
OS: Arch Linux
GPU: Intel Corporation Iris Plug Graphics G1 (Ice Lake) (rev 07)
hyprland: 0.35.0-2

Bug or Regression?
Bug
Description
Upon running the Hyprland command, the program immediately crashes without ever creating a graphical environment. I can currently run both sway and weston without issue on this same system.
How to reproduce
Install Hyprland from the Arch Linux main repository with pacman -Syu hyprland. After installation, execute the Hyprland command from the tty. Hyprland logs its startup process before reaching a line that reads:
[ERR] Invalid rulev2 found: nomaximizerequest

After which it reports crashing and advises I consult the crash report. I have attached the latest crash report. The only line I have modified from the default in hyprland.conf is the monitor setting, which I have set as follows:
monitor=eDP-1,1920x1080,0x0,1
Crash reports, logs, images, videos
--------------------------------------------
   Hyprland Crash Report
--------------------------------------------
Calm down, it was a misinput! MISINPUT!

Hyprland received signal 6 (Aborted)

Version: d9757b61bfb7dcfaf3d903092435a1aaff52b7ed
Tag: v0.35.0-78-gd9757b61

System info:
	System name: Linux
	Node name: melvilleArch
	Release: 6.7.6-arch1-1
	Version: #1 SMP PREEMPT_DYNAMIC Fri, 23 Feb 2024 16:31:48 +0000

GPU:
	00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Plus Graphics G1 (Ice Lake) [8086:8a56] (rev 07) (prog-if 00 [VGA controller])

os-release:
	NAME="Arch Linux"
	PRETTY_NAME="Arch Linux"
	ID=arch
	BUILD_ID=rolling
	ANSI_COLOR="38;2;23;147;209"
	HOME_URL="https://archlinux.org/"
	DOCUMENTATION_URL="https://wiki.archlinux.org/"
	SUPPORT_URL="https://bbs.archlinux.org/"
	BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
	PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
	LOGO=archlinux-logo

Backtrace:
	#0 | Hyprland(_Z12getBacktracev+0x48) [0x57114ca9ac98]
		getBacktrace()
		??:?
	#1 | Hyprland(_ZN13CrashReporter18createAndSaveCrashEi+0x6da) [0x57114ca49d3a]
		CrashReporter::createAndSaveCrash(int)
		??:?
	#2 | Hyprland(_Z25handleUnrecoverableSignali+0x41) [0x57114c9bda31]
		handleUnrecoverableSignal(int)
		??:?
	#3 | /usr/lib/libc.so.6(+0x3c770) [0x7fa4f016e770]
		??
		??:0
	#4 | /usr/lib/libc.so.6(+0x8d32c) [0x7fa4f01bf32c]
		SubsurfaceTree::destroySurfaceTree(SSurfaceTreeNode*) [clone .cold]
		SubsurfaceTree.cpp:?
	#5 | /usr/lib/libc.so.6(gsignal+0x18) [0x7fa4f016e6c8]
		??
		??:0
	#6 | /usr/lib/libc.so.6(abort+0xd7) [0x7fa4f01564b8]
		??
		??:0
	#7 | /usr/lib/libc.so.6(+0x25395) [0x7fa4f0157395]
		??
		??:0
	#8 | /usr/lib/libc.so.6(+0x972a7) [0x7fa4f01c92a7]
		CInputManager::newKeyboard(wlr_input_device*) [clone .cold]
		InputManager.cpp:?
	#9 | /usr/lib/libc.so.6(+0x995b4) [0x7fa4f01cb5b4]
		CInputManager::onTouchDown(wlr_touch_down_event*) [clone .cold]
		Touch.cpp:?
	#10 | /usr/lib/libc.so.6(__libc_free+0x73) [0x7fa4f01cde93]
		std::__format::_Sink_iter<char> std::__format::__do_vformat_to<std::__format::_Sink_iter<char>, char, std::basic_format_context<std::__format::_Sink_iter<char>, char> >(std::__format::_Sink_iter<char>, std::basic_string_view<char, std::char_traits<char> >, std::basic_format_args<std::basic_format_context<std::__format::_Sink_iter<char>, char> > const&, std::locale const*) [clone .constprop.0] [clone .isra.0] [clone .cold]
		TextInputV1.cpp:?
	#11 | Hyprland(_ZN13CHyprRenderer16applyMonitorRuleEP8CMonitorP12SMonitorRuleb+0xc07) [0x57114cb8b5e7]
		CHyprRenderer::applyMonitorRule(CMonitor*, SMonitorRule*, bool)
		??:?
	#12 | Hyprland(_ZN8CMonitor9onConnectEb+0xdff) [0x57114caa856f]
		CMonitor::onConnect(bool)
		??:?
	#13 | Hyprland(_ZN6Events18listener_newOutputEP11wl_listenerPv+0x145) [0x57114ca7b1d5]
		Events::listener_newOutput(wl_listener*, void*)
		??:?
	#14 | /usr/lib/libwayland-server.so.0(wl_signal_emit_mutable+0x7e) [0x7fa4f0dbd01e]
		??
		??:0
	#15 | /usr/lib/libwayland-server.so.0(wl_signal_emit_mutable+0x7e) [0x7fa4f0dbd01e]
		??
		??:0
	#16 | /usr/lib/libwlroots.so.13032(+0x46ded) [0x7fa4f0e4cded]
		??
		??:0
	#17 | /usr/lib/libwlroots.so.13032(+0x4735c) [0x7fa4f0e4d35c]
		??
		??:0
	#18 | /usr/lib/libwlroots.so.13032(+0x54d66) [0x7fa4f0e5ad66]
		??
		??:0
	#19 | Hyprland(_ZN11CCompositor15startCompositorEv+0x58c) [0x57114c9d1bbc]
		CCompositor::startCompositor()
		??:?
	#20 | Hyprland(main+0x7b5) [0x57114c9a7a35]
		main
		??:?
	#21 | /usr/lib/libc.so.6(+0x25cd0) [0x7fa4f0157cd0]
		??
		??:0
	#22 | /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7fa4f0157d8a]
		??
		??:0
	#23 | Hyprland(_start+0x25) [0x57114c9bd8b5]
		_start
		??:?

Log tail:
[LOG] New keyboard created, pointers Hypr: 57114e3bb3d0 and WLR: 57114e567708
[LOG] Attached a keyboard with name Power Button
[LOG] Registered signal for owner 57114e5bc1a0: 57114e617b00 -> 57114e5bc1a8 (owner: Keyboard)
[LOG] Registered signal for owner 57114e5bc1a0: 57114e617af0 -> 57114e5bc210 (owner: Keyboard)
[LOG] Registered signal for owner 57114e5bc1a0: 57114e6179d0 -> 57114e5bc2e0 (owner: Keyboard)
[LOG] Registered signal for owner 57114e5bc1a0: 57114e617b10 -> 57114e5bc278 (owner: Keyboard)
[LOG] ApplyConfigToKeyboard for "power-button-1", hasconfig: 0
[LOG] Attempting to create a keymap for layout us with variant  (rules: , model: , options: )
[LOG] Set the keyboard layout to us and variant to  for keyboard "Power Button"
[LOG] New keyboard created, pointers Hypr: 57114e5bc1a0 and WLR: 57114e6179b8
[LOG] Attached a switch device with name Lid Switch
[LOG] New switch with name "Lid Switch" added
[LOG] Registered signal for owner 57114e568700: 57114e653048 -> 57114e568710 (owner: SwitchDevice)
[LOG] Registered signal for owner 57114e568700: 57114e653068 -> 57114e568778 (owner: SwitchDevice)
[LOG] Attached a mouse with name MSFT0001:01 04F3:3140 Touchpad
[LOG] New mouse has libinput sens 0.00 (0.00) with accel profile 2 (2)
[LOG] Applied config to mouse msft0001:01-04f3:3140-touchpad, sens 0.00
[LOG] Registered signal for owner 57114e5fb310: 57114e63dcc0 -> 57114e5fb3d0 (owner: Mouse)
[LOG] New mouse created, pointer WLR: 57114e63dca8
[LOG] Attached a mouse with name MSFT0001:01 04F3:3140 Mouse
[LOG] New mouse has libinput sens 0.00 (0.00) with accel profile 2 (2)
[LOG] Applied config to mouse msft0001:01-04f3:3140-touchpad, sens 0.00
[LOG] Applied config to mouse msft0001:01-04f3:3140-mouse, sens 0.00
[LOG] Registered signal for owner 57114e5a93d0: 57114e63e1f0 -> 57114e5a9490 (owner: Mouse)
[LOG] New mouse created, pointer WLR: 57114e63e1d8
[LOG] Attached a keyboard with name Ideapad extra buttons
[LOG] Registered signal for owner 57114e5bb600: 57114e63e940 -> 57114e5bb608 (owner: Keyboard)
[LOG] Registered signal for owner 57114e5bb600: 57114e63e930 -> 57114e5bb670 (owner: Keyboard)
[LOG] Registered signal for owner 57114e5bb600: 57114e63e810 -> 57114e5bb740 (owner: Keyboard)
[LOG] Registered signal for owner 57114e5bb600: 57114e63e950 -> 57114e5bb6d8 (owner: Keyboard)
[LOG] ApplyConfigToKeyboard for "ideapad-extra-buttons", hasconfig: 0
[LOG] Attempting to create a keymap for layout us with variant  (rules: , model: , options: )
[LOG] Set the keyboard layout to us and variant to  for keyboard "Ideapad extra buttons"
[LOG] New keyboard created, pointers Hypr: 57114e5bb600 and WLR: 57114e63e7f8
[LOG] Attached a keyboard with name AT Translated Set 2 keyboard
[LOG] Registered signal for owner 57114e68efe0: 57114e68ebf0 -> 57114e68efe8 (owner: Keyboard)
[LOG] Registered signal for owner 57114e68efe0: 57114e68ebe0 -> 57114e68f050 (owner: Keyboard)
[LOG] Registered signal for owner 57114e68efe0: 57114e68eac0 -> 57114e68f120 (owner: Keyboard)
[LOG] Registered signal for owner 57114e68efe0: 57114e68ec00 -> 57114e68f0b8 (owner: Keyboard)
[LOG] ApplyConfigToKeyboard for "at-translated-set-2-keyboard", hasconfig: 0
[LOG] Attempting to create a keymap for layout us with variant  (rules: , model: , options: )
[LOG] Set the keyboard layout to us and variant to  for keyboard "AT Translated Set 2 keyboard"
[LOG] New keyboard created, pointers Hypr: 57114e68efe0 and WLR: 57114e68eaa8
[LOG] Registered signal for owner 57114e6b7630: 57114e6c87d8 -> 57114e6b7a50 (owner: )
[LOG] Registered signal for owner 57114e6b7630: 57114e6c8868 -> 57114e6b7ab8 (owner: )
[LOG] Registered signal for owner 57114e6b7630: 57114e6c8858 -> 57114e6b7b20 (owner: )
[LOG] Registered signal for owner 57114e6b7630: 57114e6c87e8 -> 57114e6b7b88 (owner: )
[LOG] Registered signal for owner 57114e6b7630: 57114e6c87f8 -> 57114e6b7bf0 (owner: )
[LOG] Registered signal for owner 57114e6b7630: 57114e6c8818 -> 57114e6b7c58 (owner: )
[LOG] Registered signal for owner 57114e6b7630: 57114e6c8838 -> 57114e6b7cc0 (owner: )
[LOG] Applying monitor rule for eDP-1

Can you check whether you have nomaximizerequest in the config and comment it out?

Commented out, now I no longer get that [ERR] line, but it still crashes immediately.

it looks like an issue on your end, the stacktrace is completely trashed too.


REQUEST:: Cone/Pyramid/Cylinder primitive types for collision/physics bounds

As mentioned, Godot's physics engine is missing a very common shape type for use as a collision bound.
We have fancy shapes like capsule and convex, but we still lack a trio of basic collider shapes, that is the cone, the cylinder, and the pyramid.
Getting these committed will more or less complete the set as far as collision bounds go, I hope you will find it a good thing to include.

Pyramid is not a problem, but the others are not common at all on physics engines, given the SAT algorithm can't be used. They only exist in Bullet, which uses a different collision algorithm called GJK+EPA. I don't like this algorithm much because for games it's a little imprecise and requires users to set-up margins manually to all convex shapes.
As such, this can't be done. Even PhysX does not support cylinders


Additional details are needed

Steps for deploying the .bna file to the web playground should be updated to include specifics on what to click on e.g. "click on Deploy a new business network then click on drop here to upload or browse .... "

@odrodrig - Hi Oliver - I have add the additional detail - please review and if you feel it is complete - go ahead and close this issue. tx


Add Netdata sensor

Description:
Added netdata sensor: https://github.com/firehol/netdata
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for configuration.yaml (if applicable):
sensor:
  - platform: netdata
    host: xxxxxx
    resources:
      - memory_free
      - memory_used

Checklist:
If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] Tests have been added to verify that the new code works.

I will fix this weekend.

I re-worked the PR in #4743 with a couple of small improvements and lint fixes.


Add support for PAdES-LT and PAdES-LTA

This PR adds support for PAdES-LT and PAdES-LTA profiles as specified in ETSI 102 778. In these profiles, recovation data and a full certificate chain is embedded into the signature, allowing for long-term validation.
In user-centric terms, this will lead to a "Signature is LTV enabled" in Adobe Reader.

Overruling snyk, as shown volunarability in a lib is irrelevant for open-pd-sign


Is it possible to add the ability to alter the escape chance for jester?

Already can in the config

We can adjust whether it can escape or how fast it is when it escapes but not the chance, which feels like it's 100%.


feat: change commit shifted batches to accept different shifts

In a similar spirit to the API changes introduced in #194, this PR changes commit_shifted_batches to support a different shift for each polynomial.
This is useful when committing to different tables with different max constraint degrees.

Changes included in #244 (adapted to updated FRI)


defaultGateway6.interface without defaultGateway6.address

Issue description
he.net tunnelbroker's instructs to set up the default gateway for IPv6 without the address of the gateway, using only dev.

So
defaultGateway6 = { /* address = "???"; */ interface  = "he-ipv6"; };

supposes to be a valid setup.
Although #12500 introduced the option to configure defaultGateway6.address and defaultGateway6.interface independently, absense of defaultGateway6.address (or setting it to "") results in no routing entry added silently

networking.interfaces."he-ipv6".routes = [{ address = "::"; prefixLength = 0; }] instead of defaultGateway6 does solve this


Error when trying to create the app service

I am logged into my Azure account. When attempting to create the app service received the following error:
System.Net.Http.HttpRequestException: {"error":{"code":"AuthorizationFailed","message":"The client<EMAIL_ADDRESS>with object id 'e49920c6-73a5-4c60-bd40-79ef138cf5bd' does not have authorization to perform action 'Microsoft.Resources/subscriptions/resourcegroups/write' over scope '/subscriptions/5daaa09b-c21c-46f3-ad4a-a2077e71e2d3/resourcegroups/myResourceGroup'."}}
at Microsoft.VisualStudio.Web.WindowsAzure.Provisioning.ResourceProvisioningControlModel.<ThrowOnUnexpectedStatusCode>d__174.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.WindowsAzure.Client.ARMCaller.HttpResponseExtensions.<DeserializeEntityJsonAsync>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.WindowsAzure.Client.ARMCaller.ARMRootExtensions.<DeserializeEntityAsync>d__51.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)    at Microsoft.WindowsAzure.Client.ARMCaller.EntityExtensions.<PutAsync>d__251.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Web.WindowsAzure.Provisioning.ResourceProvisioningControlModel.<DeferredDeploymentRunner>d__176.MoveNext()

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7d2cee61-876f-cb0f-61bd-349356e79491
Version Independent ID: d2fd1aff-2d1d-6c5d-e75f-64d81085a1e0
Content: Host your Teams app in Azure - Teams
Content Source: msteams-platform/get-started/get-started-dotnet-in-azure.md
Product: msteams
GitHub Login: @o365devx
Microsoft Alias: o365devx

How does this relate to MIcrosoft Teams?

I was following the hello world tutorial for creating an app in Teams. I reached this point and had this error and could not proceed. I do not know if this error was due to the example files I am using, the instructions I am following or something with my Azure account. I could not find much on this error on the internet.

I just tried it and it worked fine - this is a problem with the Azure account you are logged in with. It doesn't have permissions to do something on whatever it picked by default to do it on.
Do you have more than one Azure account? Or maybe it's brand new? This query surfaced a lot of good results.

Yes, this does work locally and with ngrok. This account is not new, and I have run some IOT projects on Azure with this account. So now I need to figure out why I am being blocked in Azure. Thank you for your help.

There's something about how the defaults are set that's messing up - I don't know how to reverse engineer the resource group or subscription IDs unfortunately. If you find anything please let us know - you may not be the first to run into this.

In the Create App Service screen under Subscription, I was picking the wrong one. It was showing me several that I do not even have access too. Once I picked the correct one it worked fine.


pull: Poll System

A litte Poll System, commands:
!poll start voteitem1 voteitem2 and so on
!poll stop
!poll reset
!poll getList
Command for vote
!vote voteItem

https://www.internalpointers.com/post/squash-commits-into-one-git


qstopmotion: use ffmpeg instead of ffmpeg_3

Motivation for this change
https://github.com/NixOS/nixpkgs/issues/120705
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 123477 at f70656b8 run on x86_64-linux 1

2 packages built successfully:

qstopmotion
tests.trivial

1 suggestion:

warning: patch-phase
patchPhase should not be overridden, use postPatch instead.
Near pkgs/applications/video/qstopmotion/default.nix:59:3:
   |
59 |   patchPhase = ''
   |   ^


IPV6: Track Interface: Doesn't allow full use of all prefix bits

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I'm convinced that mine is new.
Describe the bug
Having an existing interface setup
Request /60 from provider
Add another interface.
Set TRACK INTERFACE to WAN
set prefix id to 15 (b'1111')
get error message about prefix id out of range
(also /var/etc/dhcp6c_.conf DOES NOT get rewritten
To Reproduce
Having an existing interface setup
Request /60 from provider
Add another interface.
Set TRACK INTERFACE to WAN
set prefix id to 15 (b'1111')
get error message about prefix id out of range
(also /var/etc/dhcp6c_.conf DOES NOT get rewritten
Expected behavior
for a /60 ability to use prefix id's 0 (b'0000') to 15 (b'1111').
and re-write dhcp6c_.conf and restart dhcp6c
on ANY change to IPv6 parameters on the tracking interfaces.
Screenshots
If applicable, add screenshots to help explain your problem.
Relevant log files
If applicable, information from log files supporting your claim.
Additional context
Add any other context about the problem here.
Environment
Software version used and hardware type if relevant.
e.g.:
OPNsense 19.1.6 (amd64, OpenSSL).
Intel® i3-7100U Quadcore
Network Intel® 82583V x 6

The prefix ID is hexadecimal - entering '15' equals 10101b. Valid prefix IDs for a /60 delegated prefix are '0' to 'F', so the 'out of range' error message is correct.

That should be explained in the help, and given as additional information in the error message.


Improvements to Makefile, linting, and circleci.yml

Use gometalinter for linting

runs more linters
does everything in parallel
handles exiting with non-zero when a linter fails
supports a whitelist with // nolint
makes installation easier (install one tool then use --install instead of installing each thing separately)

Improve the cirlceci config

store the build artifacts so they can be downloaded
label the steps

Makefile improvements

put the build artifacts into a dist/ directory
run unit tests for all packages, not a single package
allow building of a binary without running lint and test every time

Cleanup vendor/

vendor.conf included some unused packages, apparently vndr is still broken and doesn't work about these unused packages.

Also fix existing lint errors.

I also notice that this doesn't specify a go version in the circleci config. This should probably test against a specific version of go. I haven't made that change as part of this PR.


Remove abstractlogger from ExecutionEngineV2

Hi guys, here are some issues I have faced while using abstractlogger.Logger in the graph-go-tools.  Please help to assess

The logger interface doesn't support log with context.Context. Context normally contains helpful information like request id or trace id which support to trace and debug the issue
Each company has its own log solution, abstractlogger seems to stick to zap logger interface that seems not convenient for us to use. The engine just better throws the error outside instead of requiring logger.

Thanks

Could you extend abstract logger with your implementation? Or remove it and return meaningful errors instead? I'm not yet sure what direction to go, but open to discussion.

abstractlogger doesn't have a license, so that needs to be addressed for most folks to be able to consume graphql-go-tools today.
https://github.com/jensneuse/abstractlogger/issues/1


Icon for .moon extension

Hey!
I often code MoonScript, and I was wondering if you could add icons for it to RPC?
Currently how it looks:

It would be amazing if you added it.

Will be added soon™.

https://github.com/leonardssh/vscord/commit/43e6d1069e09
Moon script needs a icon


{"code": 20003, "detail": "Your AccountSid or AuthToken was incorrect.", "message": "Authentication Error - No credentials provided", "more_info": "https://www.twilio.com/docs/errors/20003", "status": 401}

Hello,
I am getting this error:
{"code": 20003, "detail": "Your AccountSid or AuthToken was incorrect.", "message": "Authentication Error - No credentials provided", "more_info": "https://www.twilio.com/docs/errors/20003", "status": 401}
I dont see any logs on Studio.
When testing using Curl, same AcctSID and Auth Token, it works.
response3 = HTTParty.post("https://studio.twilio.com/v1/Flows/FWbXX/Executions", body: {To: "+XX", From: "+XX", Parameters: parameters})
puts response3
I tried this without success:
response3 = HTTParty.post("https://studio.twilio.com/v1/Flows/FWbXX/Executions", :headers => {
"Authorization" => "Basic AC6XX:aXX"}"
What is the correct way to authenticate the Studio call?
Thanks,
Al

Hello Al!
HTTParty will want you to pass the basic auth in the URL param:
response3 =<EMAIL_ADDRESS>body: {To: "+19706312302", From: "+17205730108", Parameters: parameters})
Where you replace {AcctSID}:{AuthToken}
Let me know if this works for you.

It worked ! Thank you!


Can I c# programming in this application ?

Hello. I want to buy this application but I have a couple of questions. Is it possible to program normally in c# in this application and will it be possible to use the code written here to work later with it in Unity

Yes there's C# too but it's Remote Compiled i.e. you need Internet connection. Unlike local compiled languages.


Replace Courier Prime with Courier Badi

This will add Arabic, Greek and Vietnamese support.

Fixed by 87f7fc4


java.lang.NoClassDefFoundError: org/apache/commons/lang3/RandomStringUtils

Search first

[X] I searched and no similar issues were found

Description
After Upgrading from Version 4.26.0 to 4.27.0 a compile/runtime dependency to org.apache.commons.lang3.RandomStringUtils has been added. This dependency was previously only a test-dependency and with https://github.com/liquibase/liquibase/commit/3daa688c6a99ed131687036ba4e40cd743c4b3c8 this becomes a transitive dependency during the runtime. The error occurs on startup with a fresh DB on which the hole setup (including the creation of the databasechangelog-table) has to be done.
Steps To Reproduce

create a new empty DB
start a spring-boot application which automatically runs the DB-migration on startup

During the startup the following error happens:
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'liquibase' defined in class path resource [org/springframework/boot/autoconfigure/liquibase/LiquibaseAutoConfiguration$LiquibaseConfiguration.class]: org/apache/commons/lang3/RandomStringUtils
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1788)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:600)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:522)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:337)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:335)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:200)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:313)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:200)
	at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:254)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1443)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1353)
	at org.springframework.beans.factory.support.ConstructorResolver.resolveAutowiredArgument(ConstructorResolver.java:904)
	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:782)
	... 61 common frames omitted
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/lang3/RandomStringUtils
	at liquibase.util.StringUtil.randomIdentifer(StringUtil.java:765)
	at liquibase.Scope.generateScopeId(Scope.java:154)
	at liquibase.Scope.<init>(Scope.java:147)
	at liquibase.Scope.enter(Scope.java:222)
	at liquibase.Scope.child(Scope.java:196)
	at liquibase.Scope.child(Scope.java:189)
	at liquibase.Scope.child(Scope.java:168)
	at liquibase.Scope.child(Scope.java:256)
	at liquibase.configuration.ConfigurationValueUtils.convertDataType(ConfigurationValueUtils.java:22)
	at liquibase.configuration.ConfiguredValue.getValue(ConfiguredValue.java:40)
	at liquibase.configuration.LiquibaseConfiguration.getCurrentConfiguredValue(LiquibaseConfiguration.java:149)
	at liquibase.configuration.ConfigurationDefinition.getCurrentConfiguredValue(ConfigurationDefinition.java:106)
	at liquibase.configuration.ConfigurationDefinition.getCurrentConfiguredValue(ConfigurationDefinition.java:90)
	at liquibase.integration.spring.SpringLiquibase.afterPropertiesSet(SpringLiquibase.java:228)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1835)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1784)
	... 74 common frames omitted
Caused by: java.lang.ClassNotFoundException: org.apache.commons.lang3.RandomStringUtils
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1353)
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1165)
	... 90 common frames omitted

Expected/Desired Behavior
The DB should be initialized with all its tables and no extra dependency to org.apache.commons.lang3.RandomStringUtils should be needed.
Liquibase Version
4.27.0
Database Vendor & Version
No response
Liquibase Integration
spring boot
Liquibase Extensions
No response
OS and/or Infrastructure Type/Provider
No response
Additional Context
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR (Thank you!)

@RenBrand - This is a new library that was added recently. Could you check your POM file and see if you're excluding this import. If you are, please remove the exclusion. If not, please let us know so we can look into this further.

@kevin-atx In our application we only use commons-lang3 in tests and hence it only has scope "test" and we do not exclude it explicitly anywhere. The application itself doesn't (and shouldn't) use this dependency at all.

Hi @RenBrand.
I think the defined test scope could be causing this issue. Could you please try removing the test scope from your pom?
Thanks,
Daniel.

@RenBrand - it looks like we recently added the org.apache.commons.lang3.RandomStringUtils library as required. That is why you are now seeing the NoClassDefFound error. You will need to add org.apache.commons.lang3.RandomStringUtils to your POM as a new library required by liquibase-core.

@kevin-atx - this adds another library (~600KB) we don't use with a lot of new functionality we don't use neither. This adds also to the footprint of your library which only uses one small function from the entire library, so is it really worth the usage?

I've also had this problem and would prefer not to need to ship this dependency, but i understand the reasons for adding it.
However, you have it (Apache Commons Lang) as an example of a dependency you do not include in this section of your documentation: https://contribute.liquibase.com/code/architecture/dependencies/
For completeness I feel you should update that section.
Best regards,
Nils Tornberg

I've also had this problem and would prefer not to need to ship this dependency, but i understand the reasons for adding it.
However, you have it (Apache Commons Lang) as an example of a dependency you do not include in this section of your documentation: https://contribute.liquibase.com/code/architecture/dependencies/ For completeness I feel you should update that section.
Best regards, Nils Tornberg

That's right, @JeppNils! We have created an internal ticket to update this page. Thank you for pointing this out.
@AMBERMW13 - @adrian-velonis1: could you guys look at that ticket when you have time?  I'll close this one as we will address documentation in a separate (internal) ticket.
Daniel.

[DOC] https://datical.atlassian.net/browse/PD-4826
Changes made and awaiting approval. Will be live shortly.


Ansys OS Download page

The two sections have too large of text. It should be smaller, please seem image below.

@Anthony-Hopkins-star - Appreciate if you could leave the link to the page and try to modify the text styles in the underlying document and see whether that helps.
cc: @shehjadkhan-ansys


Add option to shown reminder even when ring volume is not muted

Is your feature request related to a problem? Please describe.
I want to use this app to remind myself when the media volume is not muted regardless of the ring volume.
Describe the solution you'd like
Add an option to ignore the state of the ring volume.
Describe alternatives you've considered
Forking this app, but I don't want to do that.
Additional context
Media is muted most of the time and I only enable it when I want to watch something.

Hello, I'm in the process of doing this feature :)

@yoobi Can you check the code of my app https://github.com/mueller-ma/Coffee/ before and implement the PreferenceActivity and Prefs.kt similar here?

Sure, you can assign me #25 as well

Also the repo doesn't have the label Hacktoberfest :)

Also the repo doesn't have the label Hacktoberfest :)

I added the label.


🚩 Enable PnC with OCPP 201

The EVerest team has enabled PnC for OCPP 201
https://github.com/EVerest/everest-core/pull/588
They have also added documentation on how to configure the EvseSecurity module
https://github.com/EVerest/everest-core/blob/main/modules/EvseSecurity/doc.rst
and a simple HOWTO guide
https://github.com/EVerest/EVerest/blob/main/docs/tutorials/how_to_plug_and_charge/index.rst
More details are at:
https://github.com/EVerest/EVerest/commit/03f1039724653a7272b03850f4df8c861810684e#diff-c18cbe481f4e2f2cc3c9c5992561e64464244edcbcda0c2d08bbb0e0987ef23a
Note that the simple guide uses a simple CSMS, created in the EVerest org, that is based on the MobilityHouse package and the CertificateInstallationResponse from josev.
This issue will track the steps required to enable PnC, first with the toy CSMS and then with a real CSMS such as MaEVe
@jhoshiko @activeshadow @sahabulh for visibility and collaboration

I start this process by bumping the images up to 2024.3.0-rc1 which has all the changes required
https://github.com/EVerest/everest-demo/pull/36
@jhoshiko @sahabulh @activeshadow the new images do work now. I merged the PR at 11:04, so I guess the images had not been built and tagged correctly at the time of the demo.
$ git branch
  change_base_expose_admin_panel
* main
  turn_on_basic_testing

$ docker compose -f docker-compose.yml up

everest-demo-manager-1      | 2024-03-27 19:10:38.939593 [INFO] manager          :: 🚙🚙🚙 All modules are initialized. EVerest up and running [12680ms] 🚙🚙🚙
everest-demo-manager-1      | 2024-03-27 19:10:39.201290 [INFO] connector_1:Evs  :: Ignoring BSP Event, BSP is not enabled yet.
everest-demo-manager-1      | 2024-03-27 19:10:39.519746 [INFO] connector_1:Evs  :: Max AC hardware capabilities: 32A/3ph
everest-demo-manager-1      | 2024-03-27 19:10:39.622471 [INFO] connector_1:Evs  :: AC HLC mode enabled.
everest-demo-manager-1      | 2024-03-27 19:10:39.711235 [INFO] connector_1:Evs  :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀

@sahabulh just to summarize what we discussed, I think we should start by getting PnC to work with the everest OCPP CSMS and the everest certs. Basically, have an MRE for https://github.com/EVerest/EVerest/blob/main/docs/tutorials/how_to_plug_and_charge/index.rst so that we can all verify that it works and/or get support to get it to work. Note that this will involve swapping out MaEVe with the everest-ocpp

Here are the errors that I currently see with the EVerest + MaEVe MRE

AC 3ph 16A - charges
2024-03-27 19:29:58.535984 [INFO] car_simulator_1  :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] }
2024-03-27 19:29:59.787339 [INFO] car_simulator_1  :: { cmd: 'iec_wait_pwr_ready', args: [], exec: [Function (anonymous)] }
2024-03-27 19:30:00.045576 [INFO] evse_manager_1:  :: SYS  Session logging started.
2024-03-27 19:30:00.045819 [INFO] evse_manager_1:  :: EVSE IEC Session Started: EVConnected
2024-03-27 19:30:00.904600 [INFO] token_provider_  :: Publishing new dummy token: {"id_token":{"value":"DEADBEEF","type":"ISO14443"},"authorization_type":"RFID","prevalidated":false,"connectors":[1]}
2024-03-27 19:30:00.905934 [INFO] auth:Auth        :: Received new token: {
    "authorization_type": "RFID",
    "connectors": [
        1
    ],
    "id_token": {
        "type": "ISO14443",
        "value": "DEADBEEF"
    },
    "prevalidated": false
}
2024-03-27 19:30:00.949437 [INFO] ocpp:OCPP201     :: Found invalid entry in AuthCache: Sending new request
2024-03-27 19:30:00.977911 [INFO] auth:Auth        :: Providing authorization to connector#1
2024-03-27 19:30:01.021761 [INFO] auth:Auth        :: Result for token: DEADBEEF: ACCEPTED
2024-03-27 19:30:01.051450 [INFO] evse_manager_1:  :: EVSE IEC EIM Authorization received
2024-03-27 19:30:01.052224 [INFO] evse_manager_1:  :: EVSE IEC Transaction Started (0 kWh)
2024-03-27 19:30:01.053450 [INFO] evse_manager_1:  :: EVSE IEC AC mode, HLC disabled. We are in X1 so we can go directly to nominal PWM.
2024-03-27 19:30:01.054361 [INFO] evse_manager_1:  :: EVSE IEC Charger state: Wait for Auth->PrepareCharging
2024-03-27 19:30:01.055537 [INFO] evse_manager_1:  :: EVSE IEC Set PWM On (33.33333432674408%) took 0 ms
2024-03-27 19:30:01.299438 [INFO] car_simulator_1  :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] }
2024-03-27 19:30:02.552925 [INFO] car_simulator_1  :: {
  cmd: 'draw_power_regulated',
  args: [ 16, 3 ],
  exec: [Function (anonymous)]
}
2024-03-27 19:30:02.553519 [INFO] car_simulator_1  :: { cmd: 'sleep', args: [ 36000 ], exec: [Function (anonymous)] }
2024-03-27 19:30:02.762512 [INFO] evse_manager_1:  ::                                     CAR IEC Event CarRequestedPower
2024-03-27 19:30:02.764185 [INFO] evse_manager_1:  :: EVSE IEC Charger state: PrepareCharging->Charging
2024-03-27 19:30:03.011993 [INFO] evse_manager_1:  :: EVSE IEC Event PowerOn

AC ISO 15118-2 (stuck in PrepareCharging because EV did not transition to state C)
2024-03-27 19:31:59.063549 [INFO] car_simulator_1  :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] }
2024-03-27 19:32:00.434078 [INFO] car_simulator_1  :: {
  cmd: 'iso_wait_slac_matched',
  args: [],
  exec: [Function (anonymous)]
}
2024-03-27 19:32:00.707643 [INFO] evse_manager_1:  :: SYS  Session logging started.
2024-03-27 19:32:00.708011 [INFO] evse_manager_1:  :: EVSE IEC Session Started: EVConnected
2024-03-27 19:32:02.211203 [INFO] evse_security:E  :: TPM Key: false
2024-03-27 19:32:02.221328 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-27 19:32:02.247820 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-27 19:32:02.353932 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-27 19:32:02.375542 [INFO] token_provider_  :: Publishing new dummy token: {"id_token":{"value":"DEADBEEF","type":"ISO14443"},"authorization_type":"RFID","prevalidated":false,"connectors":[1]}
2024-03-27 19:32:02.377216 [INFO] auth:Auth        :: Received new token: {
    "authorization_type": "RFID",
    "connectors": [
        1
    ],
    "id_token": {
        "type": "ISO14443",
        "value": "DEADBEEF"
    },
    "prevalidated": false
}
2024-03-27 19:32:02.380813 [INFO] ocpp:OCPP201     :: Found invalid entry in AuthCache: Sending new request
2024-03-27 19:32:02.420947 [INFO] auth:Auth        :: Providing authorization to connector#1
2024-03-27 19:32:02.463764 [INFO] auth:Auth        :: Result for token: DEADBEEF: ACCEPTED
2024-03-27 19:32:02.513495 [INFO] evse_manager_1:  :: EVSE IEC EIM Authorization received
2024-03-27 19:32:02.513925 [INFO] evse_manager_1:  :: EVSE IEC Transaction Started (0 kWh)
2024-03-27 19:32:02.514674 [INFO] evse_manager_1:  :: EVSE IEC AC mode, HLC disabled. We are in X1 so we can go directly to nominal PWM.
2024-03-27 19:32:02.515188 [INFO] evse_manager_1:  :: EVSE IEC Charger state: Wait for Auth->PrepareCharging
2024-03-27 19:32:02.516020 [INFO] evse_manager_1:  :: EVSE IEC Set PWM On (33.33333432674408%) took 0 ms
2024-03-27 19:32:32.584624 [INFO] evse_manager_1:  :: EVSE IEC EV did not transition to state C, trying one legacy wakeup according to IEC61851-1 A.5.3
2024-03-27 19:32:32.585052 [INFO] evse_manager_1:  :: EVSE IEC Charger state: PrepareCharging->T_step_EF
2024-03-27 19:32:32.585289 [INFO] evse_manager_1:  :: EVSE IEC Enter T_step_EF
2024-03-27 19:32:32.585509 [INFO] evse_manager_1:  :: EVSE IEC Set PWM F

DC ISO 15118-2 (same, stuck in PrepareCharging because EV did not transition to state C)
2024-03-27 19:42:21.966157 [INFO] evse_manager_1:  :: EVSE IEC EIM Authorization received
2024-03-27 19:42:21.966727 [INFO] evse_manager_1:  :: EVSE IEC Transaction Started (0 kWh)
2024-03-27 19:42:21.967707 [INFO] evse_manager_1:  :: EVSE IEC AC mode, HLC disabled. We are in X1 so we can go directly to nominal PWM.
2024-03-27 19:42:21.968182 [INFO] evse_manager_1:  :: EVSE IEC Charger state: Wait for Auth->PrepareCharging
2024-03-27 19:42:21.969481 [INFO] evse_manager_1:  :: EVSE IEC Set PWM On (33.33333432674408%) took 0 ms
2024-03-27 19:42:21.969878 [INFO] auth:Auth        :: Result for token: DEADBEEF: ACCEPTED
2024-03-27 19:42:52.041236 [INFO] evse_manager_1:  :: EVSE IEC EV did not transition to state C, trying one legacy wakeup according to IEC61851-1 A.5.3
2024-03-27 19:42:52.041565 [INFO] evse_manager_1:  :: EVSE IEC Charger state: PrepareCharging->T_step_EF
2024-03-27 19:42:52.041953 [INFO] evse_manager_1:  :: EVSE IEC Enter T_step_EF
2024-03-27 19:42:52.042342 [INFO] evse_manager_1:  :: EVSE IEC Set PWM F
2024-03-27 19:42:52.568280 [INFO] evse_security:E  :: TPM Key: false
2024-03-27 19:42:52.577468 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-27 19:42:52.605590 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-27 19:42:52.722513 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-27 19:42:56.139256 [INFO] evse_manager_1:  :: EVSE IEC Exit T_step_EF
2024-03-27 19:42:56.139610 [INFO] evse_manager_1:  :: EVSE IEC Set PWM On (33.33333432674408%) took 0 ms
2024-03-27 19:42:56.183460 [INFO] evse_manager_1:  :: EVSE IEC Charger state: T_step_EF->PrepareCharging
2024-03-27 19:42:56.364121 [INFO] evse_manager_1:  ::                                     CAR IEC Event CarRequestedStopPower
2024-03-27 19:42:56.364550 [INFO] evse_manager_1:  ::                                     CAR IEC Event CarPluggedIn
2024-03-27 19:42:56.364889 [INFO] evse_manager_1:  ::                                     CAR IEC Event EFtoBCD

Checking if it is OCPP by using the DC ISO 15118-2 demo (works, so probably some issue with OCPP, unless the messages sent are different in the two nodered UIs)
$ bash demo-iso15118-2-dc.sh
2024-03-27 12:36:40 2024-03-27 19:36:40.004714 [INFO] iso15118_charge  :: Protocol negotiation was successful. Selected protocol is ISO15118
2024-03-27 12:36:40 2024-03-27 19:36:40.046311 [INFO] evse_manager:Ev  ::                                     CAR ISO V2G SupportedAppProtocolReq
2024-03-27 12:36:40 2024-03-27 19:36:40.088060 [INFO] evse_manager:Ev  :: EVSE ISO V2G SupportedAppProtocolRes
2024-03-27 12:36:41
2024-03-27 12:36:41 2024-03-27 19:36:41.221266 [INFO] iso15118_charge  :: SessionSetupReq.EVCCID: 02:42:AC:1F:00:03
2024-03-27 12:36:41
2024-03-27 12:36:41 2024-03-27 19:36:41.221395 [INFO] iso15118_charge  :: No session_id found or not equal to the id from the preceding v2g session.
For debugging, I just used the following
$ docker exec -it everest-ac-demo-manager-1 /bin/bash
80c64be33b3c:/workspace# ps -aef
PID   USER     TIME  COMMAND
    1 root      0:00 tail -f /dev/null
   20 root      0:00 sh /workspace/build/run-scripts/run-sil-ocpp201.sh
80c64be33b3c:/workspace# pkill 20
80c64be33b3c:/workspace# sh /workspace/build/run-scripts/run-sil-ocpp201-pnc.sh

with this, I can launch the PnC SIL demo but it fails with the following error

2024-03-27 19:50:39.385065 [INFO] evse_manager_1:  :: EVSE ISO V2G PaymentServiceSelectionRes

2024-03-27 19:50:40.473354 [INFO] iso15118_charge  :: CertificateInstallation-phase started

2024-03-27 19:50:40.475812 [INFO] iso15118_charge  :: Waiting for the CertInstallationExiRes msg
2024-03-27 19:50:41.520308 [INFO] evse_security:E  :: TPM Key: false
2024-03-27 19:50:41.531967 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-27 19:50:41.556340 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-27 19:50:43.013342 [CRIT] manager         int boot(const boost::program_options::variables_map&) :: Module iso15118_charger (pid: 628) exited with status: 11. Terminating all modules.

On re-running, I got more details - I am not sure if this is an artifact of fact that we are re-running on the same EVSE (due to stored stated from the previous run).
2024-03-27 19:54:29.592371 [INFO] evse_manager_1:  :: EVSE ISO V2G PaymentServiceSelectionRes

2024-03-27 19:54:30.674003 [INFO] iso15118_charge  :: CertificateInstallation-phase started

2024-03-27 19:54:30.675022 [INFO] iso15118_charge  :: Waiting for the CertInstallationExiRes msg
2024-03-27 19:54:35.175801 [ERRO] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: CertificateInstallationRes timeout occured

2024-03-27 19:54:35.176044 [ERRO] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Failed response code detected for message "Certificate Installation", error: Response FAILED

2024-03-27 19:54:35.178897 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Response message (type 10) not configured within 98 ms (took 4505 ms)
2024-03-27 19:54:35.180075 [INFO] evse_manager_1:  ::                                     CAR ISO V2G CertificateInstallationReq
2024-03-27 19:54:35.182786 [INFO] evse_manager_1:  :: EVSE ISO V2G CertificateInstallationRes
2024-03-27 19:54:35.273141 [ERRO] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: EXI message (ns=urn:iso:15118:2:2013:MsgDef) where validation failed: 8098020ed0f57f3ed7de5f906082002400402000020000201000
2024-03-27 19:54:36.739655 [CRIT] manager         int boot(const boost::program_options::variables_map&) :: Module iso15118_charger (pid: 1112) exited with status: 11. Terminating all modules.
2024-03-27 19:54:36.741794 [INFO] manager          :: SIGTERM of child: api (pid: 1090) succeeded.
2024-03-27 19:54:36.742117 [INFO] manager          :: SIGTERM of child: auth (pid: 1091) succeeded.

@sahabulh would be interesting to see if you get the same error from the OCPP-CSMS, or whether that works correctly.
Given that the error seems to be with validating the EXI message for the CertificateInstallationRes, it may well be a CSMS issue, since with OCPP enabled, the CSMS sends the certificate to the EVSE and then to the car. Maybe we haven't set up the EVCC leaf cert correctly in the CSMS?
Also @crr-snl for visibility

Here are the errors that I currently see with the EVerest + MaEVe MRE
AC 3ph 16A - charges
AC ISO 15118-2 (stuck in PrepareCharging because EV did not transition to state C)
DC ISO 15118-2 (same, stuck in PrepareCharging because EV did not transition to state C)
Checking if it is OCPP by using the DC ISO 15118-2 demo (works)
So the ISO 15118-2 failures are probably some issue with OCPP, unless the messages sent are different in the two nodered UIs or there is some other config SIL issue

What steps did you follow here for these four tests?

What steps did you follow here for these four tests?

$ bash demo-iso15118-2-ac-plus-ocpp.sh -3

Then in the UI, select the connection mode using the dropdown

What steps did you follow here for these four tests?

$ bash demo-iso15118-2-ac-plus-ocpp.sh -3

Then in the UI, select the connection mode using the dropdown Check with @jhoshiko if you have questions - he was able to run them and got the same results

I got the exact same results. Works for the first and the last. Stuck at prepare charging with the "didn't transition to state C" error.

To use OCPP 201 PnC, we need to change the demo script to launch the PnC SIL The correct way (after all this is working) is change the last line of the demo-iso15118-2-ac-plus-ocpp.sh script. For debugging, I just used the following
$ docker exec -it everest-ac-demo-manager-1 /bin/bash
80c64be33b3c:/workspace# ps -aef
PID   USER     TIME  COMMAND
    1 root      0:00 tail -f /dev/null
   20 root      0:00 sh /workspace/build/run-scripts/run-sil-ocpp201.sh
80c64be33b3c:/workspace# pkill 20
80c64be33b3c:/workspace# sh /workspace/build/run-scripts/run-sil-ocpp201-pnc.sh

with this, I can launch the PnC SIL demo but it fails with the following error

2024-03-27 19:50:39.385065 [INFO] evse_manager_1:  :: EVSE ISO V2G PaymentServiceSelectionRes

2024-03-27 19:50:40.473354 [INFO] iso15118_charge  :: CertificateInstallation-phase started

2024-03-27 19:50:40.475812 [INFO] iso15118_charge  :: Waiting for the CertInstallationExiRes msg
2024-03-27 19:50:41.520308 [INFO] evse_security:E  :: TPM Key: false
2024-03-27 19:50:41.531967 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-27 19:50:41.556340 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-27 19:50:43.013342 [CRIT] manager         int boot(const boost::program_options::variables_map&) :: Module iso15118_charger (pid: 628) exited with status: 11. Terminating all modules.

On re-running, I got more details - I am not sure if this is an artifact of fact that we are re-running on the same EVSE (due to stored stated from the previous run).
2024-03-27 19:54:29.592371 [INFO] evse_manager_1:  :: EVSE ISO V2G PaymentServiceSelectionRes

2024-03-27 19:54:30.674003 [INFO] iso15118_charge  :: CertificateInstallation-phase started

2024-03-27 19:54:30.675022 [INFO] iso15118_charge  :: Waiting for the CertInstallationExiRes msg
2024-03-27 19:54:35.175801 [ERRO] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: CertificateInstallationRes timeout occured

2024-03-27 19:54:35.176044 [ERRO] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Failed response code detected for message "Certificate Installation", error: Response FAILED

2024-03-27 19:54:35.178897 [WARN] iso15118_charge void dlog_func(dloglevel_t, const char*, int, const char*, const char*, ...) :: Response message (type 10) not configured within 98 ms (took 4505 ms)
2024-03-27 19:54:35.180075 [INFO] evse_manager_1:  ::                                     CAR ISO V2G CertificateInstallationReq
2024-03-27 19:54:35.182786 [INFO] evse_manager_1:  :: EVSE ISO V2G CertificateInstallationRes
2024-03-27 19:54:35.273141 [ERRO] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: EXI message (ns=urn:iso:15118:2:2013:MsgDef) where validation failed: 8098020ed0f57f3ed7de5f906082002400402000020000201000
2024-03-27 19:54:36.739655 [CRIT] manager         int boot(const boost::program_options::variables_map&) :: Module iso15118_charger (pid: 1112) exited with status: 11. Terminating all modules.
2024-03-27 19:54:36.741794 [INFO] manager          :: SIGTERM of child: api (pid: 1090) succeeded.
2024-03-27 19:54:36.742117 [INFO] manager          :: SIGTERM of child: auth (pid: 1091) succeeded.

@sahabulh would be interesting to see if you get the same error from the OCPP-CSMS, or whether that works correctly. Given that the error seems to be with validating the EXI message for the CertificateInstallationRes, it may well be a CSMS issue, since with OCPP enabled, the CSMS sends the certificate to the EVSE and then to the car. Maybe we haven't set up the EVCC leaf cert correctly in the CSMS?
Also @CRR-SNL for visibility

For this, did you use the demo-iso15118-2-ac-plus-ocpp.sh script and only changed the script in the last line from run-sil-ocpp201.sh to run-sil-ocpp201-pnc.sh? But we have to follow this to start the default CSMS, right?

For this, did you use the demo-iso15118-2-ac-plus-ocpp.sh script and only changed the script in the last line from run-sil-ocpp201.sh to run-sil-ocpp201-pnc.sh? But we have to follow this to start the default CSMS, right?

I did not test with the default CSMS. I only tested with MaEVe. That is why I said

would be interesting to see if you get the same error from the OCPP-CSMS, or whether that works correctly.

Okay. I tried to run with the only change being in the last line (run-sil-ocpp201.sh changed to run-sil-ocpp201-pnc.sh). What is weird is that it still waits for the RFID swap. And it works after the swap. Why is it waiting for RFID swap? With PnC shouldn't it automatically connect after the car plugs in?
Here is my log:
2024-03-28 00:16:58.285193 [INFO] ocpp:OCPP201     :: All EVSE ready. Starting OCPP2.0.1 service
2024-03-28 00:16:58.480805 [WARN] ocpp:OCPP201    ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.VerifyCsmsCommonName
2024-03-28 00:16:58.481011 [WARN] ocpp:OCPP201    ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.UseTPM
2024-03-28 00:16:58.481114 [WARN] ocpp:OCPP201    ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.VerifyCsmsAllowWildcards
2024-03-28 00:16:58.486054 [INFO] ocpp:OCPP201     :: Connecting TLS websocket to uri: wss://host.docker.internal/ws/cp001 with security-profile 3
2024-03-28 00:16:58.542558 [INFO] evse_security:E  :: TPM Key: false
2024-03-28 00:16:58.543000 [INFO] evse_security:E  :: TPM Key: false
2024-03-28 00:16:58.543731 [WARN] evse_security:E evse_security::GetKeyPairResult evse_security::EvseSecurity::get_key_pair_internal(evse_security::LeafCertificateType, evse_security::EncodingFormat) :: CSMS leaf requires full bundle, but full bundle not found at path: "/workspace/dist/etc/everest/certs/client/csms"
2024-03-28 00:16:58.544256 [INFO] ocpp:OCPP201     :: Using certificate: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.pem"
2024-03-28 00:16:58.544652 [INFO] ocpp:OCPP201     :: Using key file: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.key"
2024-03-28 00:16:58.585111 [INFO] evse_security:E  :: Building new certificate hierarchy!
2024-03-28 00:16:58.633034 [INFO] evse_security:E  :: Requesting certificate file: [CSMS] file:"/workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-03-28 00:16:58.588785 [DEBG] ocpp:OCPP201     :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-03-28 00:16:58.721267 [INFO] evse_security:E  :: Requesting certificate file: [CSMS] file:"/workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-03-28 00:16:58.793384 [INFO] ocpp:OCPP201     :: OCPP client successfully connected to TLS websocket server
2024-03-28 00:16:58.799108 [INFO] ocpp:OCPP201     :: Received BootNotificationResponse: {
    "currentTime": "2024-03-28T00:16:58.000Z",
    "interval": 300,
    "status": "Accepted"
}
with messageId: b69bd176-6415-4462-9395-617d1aaa75d1
2024-03-28 00:16:58.826974 [INFO] evse_security:E  :: TPM Key: false
2024-03-28 00:16:58.832650 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:16:58.869118 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:16:59.357461 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:17:04.413110 [INFO] evse_security:E  :: TPM Key: false
2024-03-28 00:17:04.427248 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:17:04.445052 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:17:04.530943 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:17:09.579638 [INFO] evse_security:E  :: TPM Key: false
2024-03-28 00:17:56.018370 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:17:56.036945 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:17:56.122307 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:17:58.860548 [INFO] ocpp:OCPP201     :: Checking if CSMS client certificate has expired
2024-03-28 00:17:58.909636 [INFO] evse_security:E  :: TPM Key: false
2024-03-28 00:17:58.911874 [INFO] evse_security:E  :: TPM Key: false
2024-03-28 00:17:58.915443 [WARN] evse_security:E evse_security::GetKeyPairResult evse_security::EvseSecurity::get_key_pair_internal(evse_security::LeafCertificateType, evse_security::EncodingFormat) :: CSMS leaf requires full bundle, but full bundle not found at path: "/workspace/dist/etc/everest/certs/client/csms"
2024-03-28 00:17:58.919243 [INFO] ocpp:OCPP201     :: CSMS client certificate is still valid.
2024-03-28 00:18:01.167070 [INFO] evse_security:E  :: TPM Key: false
2024-03-28 00:18:01.172253 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:18:01.173282 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:18:01.259220 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:18:06.306875 [INFO] evse_security:E  :: TPM Key: false
2024-03-28 00:18:06.311643 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:18:06.348985 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:18:06.434725 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:18:06.870924 [INFO] car_simulator_1  :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] }
2024-03-28 00:18:08.236743 [INFO] car_simulator_1  :: { cmd: 'iec_wait_pwr_ready', args: [], exec: [Function (anonymous)] }
2024-03-28 00:18:08.577190 [INFO] evse_manager_1:  :: SYS  Session logging started.
2024-03-28 00:18:08.577327 [INFO] evse_manager_1:  :: EVSE IEC Session Started: EVConnected
2024-03-28 00:18:11.444435 [INFO] evse_security:E  :: TPM Key: false
2024-03-28 00:18:11.452260 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:18:11.486184 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:18:11.576637 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:18:12.673179 [INFO] token_provider_  :: Publishing new dummy token: {"id_token":{"value":"DEADBEEF","type":"ISO14443"},"authorization_type":"RFID","prevalidated":false,"connectors":[1]}
2024-03-28 00:18:12.673765 [INFO] auth:Auth        :: Received new token: {
    "authorization_type": "RFID",
    "connectors": [
        1
    ],
    "id_token": {
        "type": "ISO14443",
        "value": "DEADBEEF"
    },
    "prevalidated": false
}
2024-03-28 00:18:12.717353 [INFO] ocpp:OCPP201     :: Found invalid entry in AuthCache: Sending new request
2024-03-28 00:18:12.764985 [INFO] auth:Auth        :: Providing authorization to connector#1
2024-03-28 00:18:12.782011 [INFO] evse_manager_1:  :: EVSE IEC EIM Authorization received
2024-03-28 00:18:12.782261 [INFO] evse_manager_1:  :: EVSE IEC Transaction Started (0 kWh)
2024-03-28 00:18:12.782671 [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-03-28 00:18:12.782751 [INFO] evse_manager_1:  :: EVSE IEC Charger state: Wait for Auth->PrepareCharging
2024-03-28 00:18:12.782992 [INFO] evse_manager_1:  :: EVSE IEC Set PWM On (33.33333432674408%) took 0 ms
2024-03-28 00:18:12.812947 [INFO] auth:Auth        :: Result for token: DEADBEEF: ACCEPTED
2024-03-28 00:18:12.989675 [INFO] car_simulator_1  :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] }
2024-03-28 00:18:14.240989 [INFO] car_simulator_1  :: {
  cmd: 'draw_power_regulated',
  args: [ 16, 3 ],
  exec: [Function (anonymous)]
}
2024-03-28 00:18:14.241208 [INFO] car_simulator_1  :: { cmd: 'sleep', args: [ 36000 ], exec: [Function (anonymous)] }
2024-03-28 00:18:14.407407 [INFO] evse_manager_1:  ::                                     CAR IEC Event CarRequestedPower
2024-03-28 00:18:14.407660 [INFO] evse_manager_1:  :: EVSE IEC Charger state: PrepareCharging->Charging
2024-03-28 00:18:14.660076 [INFO] evse_manager_1:  :: EVSE IEC Event PowerOn
2024-03-28 00:18:32.094872 [INFO] evse_security:E  :: TPM Key: false
2024-03-28 00:18:32.099614 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-28 00:18:32.136943 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-28 00:18:32.223925 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-03-28 00:18:33.408519 [INFO] car_simulator_1  :: { cmd: 'unplug', args: [], exec: [Function (anonymous)] }
2024-03-28 00:18:33.683883 [INFO] evse_manager_1:  :: EVSE IEC Event PowerOff
2024-03-28 00:18:33.900909 [INFO] evse_manager_1:  :: EVSE ISO SLAC UNMATCHED
2024-03-28 00:18:33.901120 [INFO] evse_manager_1:  :: EVSE ISO D-LINK_READY (false)
2024-03-28 00:18:33.902827 [INFO] evse_manager_1:  ::                                     CAR IEC Event CarUnplugged
2024-03-28 00:18:33.902933 [INFO] evse_manager_1:  :: EVSE IEC Charger state: Charging->StoppingCharging
2024-03-28 00:18:33.903119 [INFO] evse_manager_1:  :: EVSE IEC Set PWM Off
2024-03-28 00:18:33.945031 [INFO] evse_manager_1:  :: EVSE IEC Charger state: StoppingCharging->Finished
2024-03-28 00:18:33.945369 [INFO] evse_manager_1:  :: EVSE IEC Transaction Finished: EVDisconnected (0.054 kWh)
2024-03-28 00:18:34.033137 [INFO] evse_manager_1:  :: EVSE IEC Session Finished
2024-03-28 00:18:34.033280 [INFO] evse_manager_1:  :: SYS  Session logging stopped.

Yep, using the AC ISO 15118-2 Plug&Charge from the dropdown menu, I got the same certificate installation error reported before.

We can actually turn off the certificate installation service in the config yaml file. Should we try that? We can use a patch in that case for the initial test.

I did try the OCPP-CSMS first. But it throws a JSON validation error when I try to start it. That's why I was doing what you did to see if I get the same results. Anyways, I will post the error I am getting when I return home. In the meantime, can anyone please try to start the OCPP-CSMS and check if any error happens?

@sahabulh can you please update this issue with your findings from yesterday so that I can take over?

My recommendation would be the following:

First get ISO 15118-2 to work with OCPP with EIM

Currently ISO 15118-2 without OCPP and with EIM works
ISO 15118-2 with OCPP and with EIM does not work

Then get ISO 15118-2 to work with OCPP and PnC

In both cases, as I said, I would start with the recommended OCPP-CSMS and get help if needed to get that to work. Once we have a working solution, we can try the more complicated MaEVe CSMS

So, by "ISO 15118-2 with OCPP and with EIM does not work" you mean it is not working with the AC ISO 15118-2 selected from the dropdown, right? Because the default AC 3ph 16A  works. The AC ISO 15118-2 wasn't working in the previous (2024.2.0) version also.

Yes, the default AC 3ph 16A is what I mean. I do not think it supports ISO 15118-2; you can verify from the logs or from the node-red config on the messages sent to the MQTT server.
Yes, it was not working in a previous version also. However, EVerest with ISO 15118-2 and OCPP 201 (at least PnC) was not expected to work in a previous release. As you can see from the first message in this issue (https://github.com/EVerest/everest-demo/issues/35#issue-2211002442), the EVerest team has now implemented https://github.com/EVerest/everest-core/pull/588 this support. So we should be able to test it.
I am suggesting starting with ISO 15118-2 EIM instead of PnC since it is simpler.

But I think AC ISO 15118-2 uses PnC. When we test the old version before the recent bump, we were using EIM. But AC ISO 15118-2 still didn't work. Another dropdown option named AC ISO 15118-2 Plug&Charge was added. I thought that was meant for the PnC, and the old one for the EIM?

I did not say that AC ISO 15118-2 uses PnC. It uses EIM.

I don't know what to do to make AC ISO 15118-2 work. Should I post it on Zulip?

Sure.
Or you can try to look at the differences between ISO 15118-2 with OCPP (does not work) and ISO 15118-2 without OCPP (works). The issue is almost certainly something related to OCPP.

@sahabulh any updates on timeline? I want to work on this a bit tonight (before @activeshadow starts working on it tomorrow) but don't want to duplicate your work

Sorry, I am juggling two things at once. That's why it is taking so long. I have an MRE here where I am testing OCPP-CSMS. It is producing this error. Please see if I am doing something wrong.

Log:
2024-03-29 00:47:27.840633 [INFO] ocpp:OCPP201     :: OCPP certificates path: /workspace/dist/etc/everest/certs
2024-03-29 00:47:27.929207 [INFO] ocpp:OCPP201     :: Established connection to device model database successfully: "/workspace/dist/share/everest/modules/OCPP201/device_model_storage.db"
2024-03-29 00:47:27.986398 [INFO] ocpp:OCPP201     :: Successfully retrieved Device Model from DeviceModelStorage
2024-03-29 00:47:28.078463 [INFO] ocpp:OCPP201     :: Logging OCPP messages to log file: /tmp/everest_ocpp_logs/2024-03-29T00:47:28.078Z.log
2024-03-29 00:47:28.078544 [INFO] ocpp:OCPP201     :: Logging OCPP messages to html file: /tmp/everest_ocpp_logs/2024-03-29T00:47:28.078Z.html
2024-03-29 00:47:28.078574 [INFO] ocpp:OCPP201     :: Logging SecurityEvents to file
2024-03-29 00:47:28.079071 [INFO] ocpp:OCPP201     :: TxStartPoint from device model: PowerPathClosed
2024-03-29 00:47:28.132853 [INFO] evse_manager_2:  :: Ignoring BSP Event, BSP is not enabled yet.2024-03-29 00:47:28.132853 [INFO] evse_manager_1:  :: Ignoring BSP Event, BSP is not enabled yet.

2024-03-29 00:47:28.137394 [INFO] evse_manager_2:  :: Max AC hardware capabilities: 32A/3ph
2024-03-29 00:47:28.277123 [INFO] evse_manager_2:  :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀
2024-03-29 00:47:28.364811 [INFO] ocpp:OCPP201     :: EVSE 2 ready.
2024-03-29 00:47:28.372706 [INFO] evse_manager_1:  :: Max AC hardware capabilities: 32A/3ph
2024-03-29 00:47:28.424956 [INFO] evse_manager_1:  :: AC HLC mode enabled.
2024-03-29 00:47:28.605218 [INFO] evse_manager_1:  :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀
2024-03-29 00:47:28.649516 [INFO] ocpp:OCPP201     :: EVSE 1 ready.
2024-03-29 00:47:28.649681 [INFO] ocpp:OCPP201     :: All EVSE ready. Starting OCPP2.0.1 service
2024-03-29 00:47:28.931689 [INFO] ocpp:OCPP201     :: Connecting to plain websocket at uri: ws://localhost:9000/cp001 with security profile: 1
2024-03-29 00:47:28.933941 [ERRO] ocpp:OCPP201    void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int) :: Failed to connect to websocket server, error_code: 2, reason: Underlying Transport Error, HTTP response code: 0, category: websocketpp.transport, transport error code: 0, Transport error category: system
2024-03-29 00:47:28.934256 [INFO] ocpp:OCPP201     :: Reconnecting in: 3000ms, attempt: 1
2024-03-29 00:47:28.995027 [INFO] evse_security:E  :: TPM Key: false
2024-03-29 00:47:29.002625 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-29 00:47:29.029026 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-29 00:47:29.029227 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: Got unexpected message type from CSMS, expected: GetCertificateStatusResponse, got: InternalError, will retry.
2024-03-29 00:47:31.936503 [INFO] ocpp:OCPP201     :: Reconnecting to plain websocket at uri: ws://localhost:9000/cp001 with security profile: 1
2024-03-29 00:47:31.938174 [ERRO] ocpp:OCPP201    void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int) :: Failed to connect to websocket server, error_code: 2, reason: Underlying Transport Error, HTTP response code: 0, category: websocketpp.transport, transport error code: 0, Transport error category: system
2024-03-29 00:47:31.938391 [INFO] ocpp:OCPP201     :: Reconnecting in: 7000ms, attempt: 2
2024-03-29 00:47:34.032144 [INFO] evse_security:E  :: TPM Key: false
2024-03-29 00:47:34.036821 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-29 00:47:34.072912 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 2 certificates
2024-03-29 00:47:34.073046 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: Got unexpected message type from CSMS, expected: GetCertificateStatusResponse, got: InternalError, will retry.

I will post the issues in Zulip later tonight. Posting it now will not help much as it is past midnight there. Meanwhile, I will try to compare the files you suggested.

I am trying to build EVerest from scratch and test the OCPP-CSMS. If it works, we will know there is something wrong with the demo.

Sorry, I am juggling two things at once. That's why it is taking so long. I have an MRE here where I am testing OCPP-CSMS. It is producing this error. Please see if I am doing something wrong. You will have to clone the repo and run the script from there.
Log:
I wish the websocket errors were more details. It is difficult to understand what the codes mean. On the other hand, MaEVe's errors are very detailed.

Update on this: I thought maybe I should try SP 0 which is mentioned here as this doesn't apparently require any authentication. But when I tested it produced the following error:
2024-03-29 01:46:25.419132 [INFO] evse_manager_1:  :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀
2024-03-29 01:46:25.461963 [INFO] ocpp:OCPP201     :: EVSE 1 ready.
2024-03-29 01:46:25.462222 [INFO] ocpp:OCPP201     :: All EVSE ready. Starting OCPP2.0.1 service
terminate called after throwing an instance of 'std::invalid_argument'
  what():  security_profile = 0 not officially allowed in OCPP 2.0.1
2024-03-29 01:46:25.808518 [CRIT] manager         int boot(const boost::program_options::variables_map&) :: Module ocpp (pid: 141) exited with status: 134. Terminating all modules.

@shankari or @sahabulh how do I configure the connection URI that libocpp will use to connect to the CSMS (OCPP server)? I wondering if right now it's defaulting to localhost:9000, which won't work if the EVSE and the CSMS aren't running in the same network namespace.
I've found documentation on configuring the OCPP module in the EVerest manager but I'm not seeing anything about the CSMS URI. Is it a config option or a setting in the DB?

It is a setting in the DB (e.g. https://github.com/EVerest/everest-demo/issues/25#issuecomment-1987368280)
The current version uses a different variable ID (it should be in the issue but I can't find it now) but should be the same otherwise

d documentation on configuring the OCPP module in the EVerest manager but I'm not seeing anything about the CSMS URI. Is it a config option or a setting in the DB?

@activeshadow , you will have to change the address and port here if you want to it on the server side.

@shankari @activeshadow I am talking with Cornelius here in case you want to participate or just observe.

@sahabulh @shankari okay so I think my version of Sahabul's MRE (here) is getting further along now, but I'm not sure how to test the actual PnC stuff...

@activeshadow https://github.com/EVerest/everest-demo/issues/35#issuecomment-2023858854

@shankari thanks for the link to the comment, but what do I do in the UI to test PnC, since right now from what I can tell it's still making me do the RFID swipe to authenticate.

select the PnC option from the dropdown below Connector 1

@shankari okay yeah I did that and it's waiting for auth so I assume I'm hitting a cert issue where the EV is missing a MO cert or it's not getting transmitted as expected.
I'll keep digging.

Yup, missing certs.
Starting software in the loop simulation using script run-sil-ocpp201-pnc.sh
2024-03-29 19:47:47.315311 [INFO] manager          ::   ________      __                _
2024-03-29 19:47:47.315383 [INFO] manager          ::  |  ____\ \    / /               | |
2024-03-29 19:47:47.315394 [INFO] manager          ::  | |__   \ \  / /__ _ __ ___  ___| |_
2024-03-29 19:47:47.315403 [INFO] manager          ::  |  __|   \ \/ / _ \ '__/ _ \/ __| __|
2024-03-29 19:47:47.315411 [INFO] manager          ::  | |____   \  /  __/ | |  __/\__ \ |_
2024-03-29 19:47:47.315419 [INFO] manager          ::  |______|   \/ \___|_|  \___||___/\__|
2024-03-29 19:47:47.315427 [INFO] manager          ::
2024-03-29 19:47:47.315436 [INFO] manager          :: Using MQTT broker mqtt-server:1883
2024-03-29 19:47:47.337469 [INFO] everest_ctrl     :: Launching controller service on port 8849
2024-03-29 19:47:47.358939 [INFO] manager          :: Loading config file at: /ext/source/config/config-sil-ocpp201-pnc.yaml
2024-03-29 19:47:47.705870 [INFO] manager          :: Config loading completed in 371ms
2024-03-29 19:48:04.054125 [INFO] auth:Auth        :: Module auth initialized [16197ms]
2024-03-29 19:48:04.060131 [INFO] api:API          :: Module api initialized [16295ms]
2024-03-29 19:48:06.858030 [INFO] energy_manager:  :: Module energy_manager initialized [17392ms]
2024-03-29 19:48:07.751391 [INFO] evse_manager_1:  :: Module evse_manager_1 initialized [17396ms]
2024-03-29 19:48:12.251491 [INFO] evse_manager_2:  :: Module evse_manager_2 initialized [20499ms]
2024-03-29 19:48:18.554437 [WARN] evse_security:E evse_security::EvseSecurity::EvseSecurity(const evse_security::FilePaths&, const std::optional<std::__cxx11::basic_string<char> >&, const std::optional<long unsigned int>&, const std::optional<long unsigned int>&, const std::optional<std::chrono::duration<long int> >&, const std::optional<std::chrono::duration<long int> >&) :: Could not find configured V2G bundle file at: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem, creating default!
2024-03-29 19:48:18.559398 [WARN] evse_security:E evse_security::EvseSecurity::EvseSecurity(const evse_security::FilePaths&, const std::optional<std::__cxx11::basic_string<char> >&, const std::optional<long unsigned int>&, const std::optional<long unsigned int>&, const std::optional<std::chrono::duration<long int> >&, const std::optional<std::chrono::duration<long int> >&) :: Could not find configured MO bundle file at: /workspace/dist/etc/everest/certs/ca/mo/MO_ROOT_CA.pem, creating default!
2024-03-29 19:48:18.648055 [WARN] evse_security:E evse_security::EvseSecurity::EvseSecurity(const evse_security::FilePaths&, const std::optional<std::__cxx11::basic_string<char> >&, const std::optional<long unsigned int>&, const std::optional<long unsigned int>&, const std::optional<std::chrono::duration<long int> >&, const std::optional<std::chrono::duration<long int> >&) :: Could not find configured MF bundle file at: /workspace/dist/etc/everest/certs/ca/mf/MF_ROOT_CA.pem, creating default!
2024-03-29 19:48:18.754874 [INFO] grid_connection  :: Module grid_connection_point initialized [22906ms]
2024-03-29 19:48:18.854660 [INFO] evse_security:E  :: Module evse_security initialized [25803ms]

2024-03-29 19:48:22.956284 [INFO] iso15118_charge  :: TCP server on eth0 is listening on port [fe80::42:acff:fe13:4%160]:61341

2024-03-29 19:48:22.956555 [INFO] iso15118_charge  :: TLS server on eth0 is listening on port [fe80::42:acff:fe13:4%160]:64109

2024-03-29 19:48:22.956696 [INFO] iso15118_charge  :: SDP socket setup succeeded
2024-03-29 19:48:22.957213 [INFO] iso15118_charge  :: Module iso15118_charger initialized [20905ms]
2024-03-29 19:48:23.849121 [INFO] ocpp:OCPP201     :: Module ocpp initialized [18087ms]
2024-03-29 19:48:25.663325 [INFO] system:System    :: Module system initialized [17104ms]
2024-03-29 19:48:25.953887 [INFO] token_provider_  :: Module token_provider_1 initialized [14805ms]
2024-03-29 19:48:27.359436 [INFO] manager          :: 🚙🚙🚙 All modules are initialized. EVerest up and running [40047ms] 🚙🚙🚙
2024-03-29 19:48:27.364200 [INFO] ocpp:OCPP201     :: OCPP certificates path: /workspace/dist/etc/everest/certs
2024-03-29 19:48:27.552843 [INFO] ocpp:OCPP201     :: Established connection to device model database successfully: "/workspace/dist/share/everest/modules/OCPP201/device_model_storage.db"
2024-03-29 19:48:27.569391 [INFO] ocpp:OCPP201     :: Successfully retrieved Device Model from DeviceModelStorage
2024-03-29 19:48:27.663066 [INFO] evse_manager_1:  :: Ignoring BSP Event, BSP is not enabled yet.
2024-03-29 19:48:27.769178 [INFO] ocpp:OCPP201     :: Logging OCPP messages to log file: /tmp/everest_ocpp_logs/2024-03-29T19:48:27.769Z.log
2024-03-29 19:48:27.769394 [INFO] ocpp:OCPP201     :: Logging OCPP messages to html file: /tmp/everest_ocpp_logs/2024-03-29T19:48:27.769Z.html
2024-03-29 19:48:27.769521 [INFO] ocpp:OCPP201     :: Logging SecurityEvents to file
2024-03-29 19:48:27.771755 [INFO] ocpp:OCPP201     :: TxStartPoint from device model: PowerPathClosed
2024-03-29 19:48:27.949557 [INFO] evse_manager_2:  :: Ignoring BSP Event, BSP is not enabled yet.
2024-03-29 19:48:28.065309 [INFO] evse_manager_2:  :: Max AC hardware capabilities: 32A/3ph
2024-03-29 19:48:28.203459 [INFO] evse_manager_2:  :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀
2024-03-29 19:48:28.287028 [INFO] ocpp:OCPP201     :: EVSE 2 ready.
2024-03-29 19:48:28.327823 [INFO] evse_manager_1:  :: Max AC hardware capabilities: 32A/3ph
2024-03-29 19:48:28.419715 [INFO] evse_manager_1:  :: AC HLC mode enabled.
2024-03-29 19:48:28.550976 [INFO] evse_manager_1:  :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀
2024-03-29 19:48:28.594617 [INFO] ocpp:OCPP201     :: EVSE 1 ready.
2024-03-29 19:48:28.594792 [INFO] ocpp:OCPP201     :: All EVSE ready. Starting OCPP2.0.1 service
2024-03-29 19:48:28.773090 [WARN] ocpp:OCPP201    ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.VerifyCsmsCommonName
2024-03-29 19:48:28.773260 [WARN] ocpp:OCPP201    ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.UseTPM
2024-03-29 19:48:28.773339 [WARN] ocpp:OCPP201    ocpp::v201::GetVariableStatusEnum ocpp::v201::DeviceModel::request_value_internal(const ocpp::v201::Component&, const ocpp::v201::Variable&, const ocpp::v201::AttributeEnum&, std::string&, bool) :: unknown variable in InternalCtrlr.VerifyCsmsAllowWildcards
2024-03-29 19:48:28.775132 [INFO] ocpp:OCPP201     :: Connecting to plain websocket at uri: ws://host.docker.internal/ws/cp001 with security profile: 1
2024-03-29 19:48:28.778314 [WARN] evse_security:E evse_security::GetKeyPairResult evse_security::EvseSecurity::get_key_pair_internal(evse_security::LeafCertificateType, evse_security::EncodingFormat) :: Could not find any key pair
2024-03-29 19:48:28.778442 [ERRO] evse_security:E evse_security::OCSPRequestDataList evse_security::EvseSecurity::get_v2g_ocsp_request_data() :: Could not get key pair, for v2g ocsp request!
2024-03-29 19:48:28.779216 [INFO] ocpp:OCPP201     :: OCPP client successfully connected to plain websocket server
2024-03-29 19:48:28.787497 [INFO] ocpp:OCPP201     :: Received BootNotificationResponse: {
    "currentTime": "2024-03-29T19:48:28.786Z",
    "interval": 300,
    "status": "Accepted"
}
with messageId: 75f34dca-d0f3-4b10-ac48-01fb4bcbfbec
2024-03-29 19:48:28.818793 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 0 certificates
2024-03-29 19:48:28.818913 [INFO] ocpp:OCPP201     :: libocpp: Done updating OCSP cache
2024-03-29 19:49:26.846370 [INFO] car_simulator_1  :: { cmd: 'sleep', args: [ 1 ], exec: [Function (anonymous)] }
2024-03-29 19:49:28.197119 [INFO] car_simulator_1  :: {
  cmd: 'iso_wait_slac_matched',
  args: [],
  exec: [Function (anonymous)]
}
2024-03-29 19:49:28.640558 [INFO] evse_manager_1:  :: SYS  Session logging started.
2024-03-29 19:49:28.640954 [INFO] evse_manager_1:  :: EVSE IEC Session Started: EVConnected
2024-03-29 19:49:31.029010 [INFO] evse_manager_1:  :: EVSE ISO SLAC MATCHED
2024-03-29 19:49:31.029551 [INFO] evse_manager_1:  :: EVSE ISO D-LINK_READY (true)
2024-03-29 19:49:31.201259 [INFO] car_simulator_1  :: {
  cmd: 'iso_start_v2g_session',
  args: [ 'contract', 'ac_three_phase_core' ],
  exec: [Function (anonymous)]
}
2024-03-29 19:49:31.245125 [INFO] car_simulator_1  :: { cmd: 'iso_wait_pwr_ready', args: [], exec: [Function (anonymous)] }

2024-03-29 19:49:33.786101 [INFO] iso15118_charge  :: Received packet from [fe80::42:acff:fe13:4]:42455 with security 0x00 and protocol 0x00

2024-03-29 19:49:33.786282 [INFO] iso15118_charge  :: SDP requested TLS, announcing TLS

2024-03-29 19:49:33.786419 [INFO] iso15118_charge  :: sendto([fe80::42:acff:fe13:4]:42455) succeeded
2024-03-29 19:49:33.793436 [ERRO] iso15118_car    pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: SSLError when trying to connect to host fe80::42:acff:fe13:4 and port 64109
Traceback (most recent call last):
  File "/workspace/dist/libexec/everest/modules/PyEvJosev/../../3rd_party/josev/iso15118/evcc/comm_session_handler.py", line 420, in start_comm_session
    self.tcp_client = await TCPClient.create(
  File "/workspace/dist/libexec/everest/modules/PyEvJosev/../../3rd_party/josev/iso15118/evcc/transport/tcp_client.py", line 43, in create
    self = TCPClient(session_handler_queue, port, is_tls)
  File "/workspace/dist/libexec/everest/modules/PyEvJosev/../../3rd_party/josev/iso15118/evcc/transport/tcp_client.py", line 30, in __init__
    self.ssl_context = get_ssl_context(False, self.ciphersuites)
  File "/workspace/dist/libexec/everest/modules/PyEvJosev/../../3rd_party/josev/iso15118/shared/security.py", line 184, in get_ssl_context
    ssl_context.load_verify_locations(
ssl.SSLError: [X509: NO_CERTIFICATE_OR_CRL_FOUND] no certificate or crl found (_ssl.c:4149)

@activeshadow it is stuck in waiting for auth because the server crashed during auth. Please see the output that I got at
https://github.com/EVerest/everest-demo/issues/35#issuecomment-2023858854
Note that this is with MaEVe. I would suggest reproducing this, and then seeing if the behavior is different with OCPP-CSMS

@activeshadow and @sahabulh it looks like both of you are still working on this. When you are done, can you please submit a PR of where you are so I can pick up from there? At least for me, working on the same task as others gets very confusing.

@activeshadow it is stuck in waiting for auth because the server crashed during auth. Please see the output that I got at #35 (comment)
Note that this is with MaEVe. I would suggest reproducing this, and then seeing if the behavior is different with OCPP-CSMS

@shankari my error looks to be different. It's not a program termination error, rather it's a certificate not found error. I'm looking into it now.

@shankari @activeshadow I am done. It is working with MaEVe + AC ISO 15118-2 + PnC. Did little hack to ignore OCSP temporarily. I also disabled CertificateInstallation. For details, check the Zulip topic linked previously. I will submit a PR as soon as possible.

@sahabulh I'm not able to reproduce but that's okay. I'll wait for your PR then go from there.
Can you explain why you chose to disable certificate installation in the EV Car module? It may be in the Zulip chat but would also be great to have it documented here (or in the PR) so we know where to go from there.
I'm seeing an issue with the EV Car module (Josev) not being able to find certificates. The V2G certificate it can't load is in the container, so I'm wondering if the prefix path Josev is using is not correct, but I didn't have a chance to run that to ground yet. I'm wondering if you disabling certificate installation gets around this, but if so I'd be curious as to why.

@sahabulh I'm not able to reproduce but that's okay. I'll wait for your PR then go from there.
Can you explain why you chose to disable certificate installation in the EV Car module? It may be in the Zulip chat but would also be great to have it documented here (or in the PR) so we know where to go from there.
I'm seeing an issue with the EV Car module (Josev) not being able to find certificates. The V2G certificate it can't load is in the container, so I'm wondering if the prefix path Josev is using is not correct, but I didn't have a chance to run that to ground yet. I'm wondering if you disabling certificate installation gets around this, but if so I'd be curious as to why.

@sahabulh I'm not able to reproduce but that's okay. I'll wait for your PR then go from there.

I submitted the PR.

Can you explain why you chose to disable certificate installation in the EV Car module? It may be in the Zulip chat but would also be great to have it documented here (or in the PR) so we know where to go from there.

Craig was against it given that we have limited time before the virtual demo. MaEVe currently uses hubject to handle CertificateInstallation request. We don't want that. Which means additional work make the local handling work.

I'm seeing an issue with the EV Car module (Josev) not being able to find certificates. The V2G certificate it can't load is in the container, so I'm wondering if the prefix path Josev is using is not correct, but I didn't have a chance to run that to ground yet. I'm wondering if you disabling certificate installation gets around this, but if so I'd be curious as to why.

What error are you getting? Can you please post a log?

The related PR is here: #38. It works fine in terms of the state machine, and we end up in the Charging state, but the power drawn is zero (see screenshot below).

Charging, but no power drawn
Values coming from the power meter (powermeter/TotalKWattHr or powermeter/totakKw)

I am not sure where those logs come from. I also checked the logs, and there is a negotiation that happens in the ISO protocol V2G PaymentServiceSelectionReq/Res, then Transaction Started (0 kWh) and then V2G ChargeParameterDiscoveryReq/Res and then Event CarRequestedPower (see attached HTML with EXI messages). But I can't find an online EXI decoder to understand what the messages represent.

Tried to install https://github.com/FlUxIuS/V2Gdecoder to decode EXI.
$ java -jar /tmp/V2Gdecoder.jar -s "..."
WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.
com.siemens.ct.exi.core.exceptions.EXIException: XML Schema document (./schemas/V2G_CI_MsgDef.xsd) not found.
	at com.siemens.ct.exi.grammars.EXIContentModelBuilder.loadGrammars(EXIContentModelBuilder.java:161)
	at com.siemens.ct.exi.grammars.EXIContentModelBuilder.loadGrammars(EXIContentModelBuilder.java:197)

Trying to compile instead resulted in
$ mvn compile assembly:single
[INFO] Scanning for projects...
[INFO]
[INFO] -----------------< com.fluxlus.V2Gdecoder:V2Gdecoder >------------------
[INFO] Building V2Gdecoder 1.0-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[WARNING] The POM for com.v2gclarity.risev2g:rise-v2g-shared:jar:1.2.6 is missing, no dependency information available
[WARNING] The POM for com.sun.xml.bind:jaxb-core:jar:2.2.11 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details
[WARNING] The POM for com.sun.xml.bind:jaxb-impl:jar:2.2.11 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.367 s
[INFO] Finished at: 2024-04-01T22:41:20-07:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project V2Gdecoder: Could not resolve dependencies for project com.fluxlus.V2Gdecoder:V2Gdecoder:jar:1.0-SNAPSHOT: The following artifacts could not be resolved: com.v2gclarity.risev2g:rise-v2g-shared:jar:1.2.6 (absent): com.v2gclarity.risev2g:rise-v2g-shared:jar:1.2.6 was not found in file:///Users/kshankar/Desktop/data/joet-everest/V2Gdecoder/src/lib/ during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of project-local-repo has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

Trying to run the precomputed jar from the releases against the checked out schema from the repo...

That doesn't give an error, but it doesn't decode either. I just get a null value as the result.
Let's try to incorporate the ISO 15118-2 decoder into this node-red

Piet told me here that there is an issue with the SIL which causes this. As we are seeing the ChargingStatusReq/Res pairs going back and forth between the EV and EVSE, it means that ISO 15118 with PnC is working. Maybe we can ignore this for now? Or ask them about their plan to fix it?
I think the priority now should be on the EonTi certs and make the OCSP response or revocation status checking work. I plan to work on this in the weekend and maybe create a new pull request. Is it okay?

@sahabulh we should file an issue for the SIL to be fixed. This is not a super-high priority, in fact, Piet told me that the related developer was out on vacation, but I don't want it to fall through the cracks.

About how I tested it, I changed nothing except for the CSMS_LEAF.pem and the CSMS_LEAF.key files. I just regenerated these using the old CPO SUB CA 2 where the CN is CSMSCert rather than host.docker.internal.

@sahabulh

Yes, please file an issue for the SIL to be fixed
Yes, please create a new issue for the EonTI certs

You can put in the details https://github.com/EVerest/everest-demo/issues/35#issuecomment-2062619392 into that issue.
wrt next steps on the EonTI issue, I would suggest asking EonTI to generate certs with the modified CN host.docker.internal to verify that this is the only issue.
Having done that, you should notify Craig, Ryan and EonTI (please make sure to cc me as well). This should be part of Craig's upcoming work around best practices for PKI infrastructure.

@shankari Joshua had opened an issue for testing EonTi certs, so rather than creating a new one, I am just reusing that issue.

Having done that, you should notify Craig, Ryan and EonTI (please make sure to cc me as well). This should be part of Craig's upcoming work around best practices for PKI infrastructure.

I didn't understand you here fully. What should I say?

Yes, please file an issue for the SIL to be fixed

Posted it last week in here. Let me know if any modification is needed.

Hello, since this ticket is still open I hope you don't mind if I comment.
The charge stalling behavior mentioned earier in the thread with AC ISO15118-2 https://github.com/EVerest/everest-demo/issues/35#issuecomment-2023837531 is still occuring when using  CitrineOS and MaEVe CSMS when tls_active is set to true in config-sil-ocpp201-pnc.yaml when running demo-iso15118-2-ocpp-201.sh in everest-demo.
The same behaviour also occurs when testing pnc with the everest-dev-environment adjusted to use run-sil-ocpp201-pnc with nodered using config-sil-iso15118-ac-flow.json against CitrineOS:
PrepareCharging->EVSE Paused
2024-12-14 03:18:50.347121 [INFO] ocpp:OCPP201     :: Found valid entry in AuthCache
2024-12-14 03:18:50.393550 [INFO] auth:Auth        :: Providing authorization to connector#1
2024-12-14 03:18:50.490231 [INFO] auth:Auth        :: Result for token: DEADBEEF: ACCEPTED
2024-12-14 03:18:50.539886 [INFO] evse_manager_1:  :: EVSE IEC EIM Authorization received
2024-12-14 03:18:50.632658 [INFO] evse_manager_1:  :: EVSE IEC Transaction Started (0 kWh)
2024-12-14 03:18:50.633209 [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-12-14 03:18:50.633275 [INFO] evse_manager_1:  :: EVSE IEC Charger state: Wait for Auth->PrepareCharging
2024-12-14 03:18:50.633496 [INFO] evse_manager_1:  :: EVSE IEC Set PWM On (26.66666805744171%) took 0 ms
2024-12-14 03:18:50.818246 [INFO] evse_manager_1:  :: EVSE IEC Set PWM Off
2024-12-14 03:18:50.993968 [INFO] evse_manager_1:  :: EVSE IEC Transaction Finished: DeAuthorized (0 kWh)
2024-12-14 03:18:50.995486 [INFO] evse_manager_1:  :: EVSE IEC Charger state: PrepareCharging->EVSE Paused
2024-12-14 03:18:50.996205 [INFO] evse_manager_1:  :: EVSE IEC Set PWM Off
2024-12-14 03:18:51.064178 [WARN] ocpp:OCPP201    virtual bool ocpp::v201::ChargePoint::on_charging_state_changed(uint32_t, ocpp::v201::ChargingStateEnum, ocpp::v201::TriggerReasonEnum) :: Can not change charging state: no transaction for evse id 1
2024-12-14 03:18:51.064437 [WARN] ocpp:OCPP201    virtual bool ocpp::v201::ChargePoint::on_charging_state_changed(uint32_t, ocpp::v201::ChargingStateEnum, ocpp::v201::TriggerReasonEnum) :: Can not change charging state: no transaction for evse id 1
2024-12-14 03:19:04.778167 [WARN] ocpp:OCPP201    void module::OCPP201::set_external_limits(const std::vector<ocpp::v201::CompositeSchedule>&) :: Can not apply external limits! No evse energy sink configured for evse_id: 0
2024-12-14 03:19:04.778288 [WARN] ocpp:OCPP201    void module::OCPP201::set_external_limits(const std::vector<ocpp::v201::CompositeSchedule>&) :: Can not apply external limits! No evse energy sink configured for evse_id: 1

This doesn't occur when using ocpp-csms following the EVerest plug and charge tutorial https://github.com/EVerest/EVerest/blob/main/docs/tutorials/how_to_plug_and_charge/index.rst using run-sil-ocpp-pnc.sh. In this case the EVerest manager and ocpp-csms logs are also sufficiently verbose to see the eMAID handoff even though config-sil-ocpp.yaml doesn't have a tls_active field.
Are there additional plans to improve EVerest manager compatibility with CitrineOS CSMS?
Thanks very much.


No auto-play for NA servers form EU

I cant auto start the game if I use NA server from EU. The program stuck after login at PLAY button and have to manually press play to start the game.
I dont have this problem if i log into EU servers.

Confirming that this problem exists for EU servers logging in from NA and, also, not for NA servers logging in from NA.

Ok, made this work ok. Not sure why but autoplay was unchecked on only the EU servers for me. Redid the logfile for each, made sure to check autoplay and now all is good. Still can't explain why autoplay got unchecked only for these servers. I have 20 accounts and it only happened on EU servers. Once again, I'm in NA.


Consider upgrade bonuses and multiple purchases in determining next best purchase

It would be interesting if cookie monster suggested not just the next best purchase (building or upgrade), but a series of purchases.
For example the overall PP for  buying  a building upgrade for building A then a few buildings A might be more effective than just buying building B (although building B's PP is better RIGHT NOW).

I guess this is related to the "left till next achievement" I stumbled on when I today loaded the javascript directly from git, when the old link stopped working.
The "left till next achievement" looks wonderful.
I hope there's going to be a easier way to find them, then hovering over each and every building,
like some icon or extra text on the building when "left till next achievement" has a lower PP then the building itself.


Request for Okta access for new developers

Description
In preparation for getting into the on-call rotation, it seems likely that the Pipeline engineering team will all need Okta access.
Specific Requested resources
Access for Okta (whichever staging or production level is necessary for on-call duty) granted to Jimmy Fagan (jimmyfagan@navapbc.com), Victor Chaparro (victorchaparro@navapbc.com), and Jessica Willis (jessicawillis@navapbc.com).
Existing Resources?
Not aware of any existing resources that we will need to delete or modify for this
Additional Context
Not sure exactly which roles need Okta access or not, but it seems like most folks on other teams do have access; if Okta access is generally given to non-engineers as well, it would be nice to verify that Avniel Dravid has access too as part of this.

This is now done by Sharons team!