📝 ❇️ Test all SIL/HIL Demos #84
Comments
Renegotiation DemoI will be handling this portion of the tests. For this, we will test the following scenarios:
For each of these, we should test
|
|
I can't get the demoes in the main branch to run since they're not compatible with aarch64 "EVerest Demos are currently NOT supported on M1 chips" Oh I see. I guess I just use my personal laptop |
|
On my nrel laptop (2017 MacBook Pro with Intel chip): After purging docker to free up space, runs until it gets the know error: I'll take a quick look over at #78 to see if there's a known fix I can try... Also - draft readME PR #85 |
|
I don't see anything for the nodered ui when running
|
Ah good to see that it is not just my laptop. There is no fix (I tried several options from the issue). We just have to pre-build and change the demo script accordingly. The good news is that I can now pre-build through a CI. I am actively refactoring the demo to use them now, gimme ~ 30 mins more. |
|
It looks like I'm getting this error because nodered isn't up to date. |
|
Are you able to run from Katie's fork? She has updated node-red. I am updating it more formally in #85 but that is blocked on the maeve CSMS |
No I wasn't. I thought I was supposed to be testing the main branch, but I guess I should the use the fork for now. |
|
Yeah, the main branch is WiP |
|
Made a quick change to the node-red flows to fix a bug where we failed during an initial empty DT charging session, but changes are working and pushed! Will update this list with videos of my demo tests, as to not clog this issue with lots of posts. EDIT: Oops, |
|
once we are done, we should set up a meeting to demo to the rest of the team |
|
@the-bay-kay ready to schedule a meeting tomorrow? |
I still have some cleanup to do, let me see how the next 12 hours go. Where I'm at now:
ChargingProfile ChangesRenegotiation.w_o.power.change.1.mp4 |
|
Will be putting my debug findings below a cut for now, as to not clog this issue for others. We can move & format this documentation once the dust settles (to avoid the "under-the-cut" issues). Piping through ISO15118-2 Charging Profile based Power ModulationLet's use the OCPP cases as an example for how to modify the power draw. Looking at the following logs:
Checking for where the charging profiles are processed...
Trying to wrap my head around the interaction between these files: TL;DR, we need to somehow fetch the profile data from EvseV2G (iso15118_charger), and correctly create events for the EvseManager to delegate to the JsYetiSimulator (evse_board_support). Mapping these out visually for my own sanity... So, I think the best place to pass through the ChargingProfile has to be within iso_server.cpp's handle_iso_power_delivery... Let's see how we can propagate these details up to the EvseManager. |
A few errors in the logsLogs!
|
This looks like an old version of the simulator command Example of looking at Node-RED commands
|
|
@shankari I just ran the rest of the tests, everything worked as intended except one edge case! As for the edge case -- I once again got the default "empty DT" wrong in Node-RED it seems. If unmodified at launch, DT defaults to 0 ("empty"). But, if we enter a time, and then delete it, we default to 86400 -- not empty. Woops! With that last change to the node-red flow, we should be good to go. Will LYK when that change is pushed! It shouldn't affect any of the existing patches, just the flow. Video of (DT + EAmount) + OCPP testsEADTDemo.1.mp4 |
|
@the-bay-kay please let me know when that change is pushed so I can clean up your changes so far and get them into main |
|
@shankari Changes are pushed! You can find the list of patches starting here -- some like the device_storage patch will not be relevant, as we discussed with the |
Closed
|
@the-bay-kay I would like to also test something like section 2.4 of the OCPP spec; the external smart charging signal. Could you try to send two separate charging profiles, one from the CSMS and the other from the external controller, and see if that works? |
Sure thing! Looking at OCPP 2.0.1 Part 2, Section K-2.4, I see a few different methods of external smart charging control (IEC 61850, OpenADR, etc.). I may be blanking -- is there a preferred / documented method I should test? Currently looking for some examples of how the community has tested in the past! |
|
Right! At a high level, I understand the difference between CSMS profiles and profiles from local inputs (HEMS, DSO, etc.). How I can emulate one of these schedules within EVerest. E.g., we use the script to send ChargingProfiles |
|
Ah if EVerest/libocpp#828 is not merged, then there will not be support for this. The PR looks pretty complete, though, and it would be a great example of composite schedules, which was the main achievement of the AFS work. Looking at the PR, where does it expect the external limit charging profile to come from? Is it from the websocket connection to the CSMS? What happens if we just send it over that link? |
|
@the-bay-kay this will need some digging, I would suggest that you go back to the charging dial for now |
|
@the-bay-kay I tested after incorporating all patches (#88), and ran into an issue at the end of the charge session Not sure if you actually tested all the way to the end... |
|
Do we expect |
|
the manager is fairly big, but we should not need to take a long time. |
|
I have been off the the VPN for a while now. I could stop it and retry off the VPN, but I worry that if my wifi is just that slow it would take this long again. |
|
It may be that it got stuck when you got off the VPN because of the change to networking. |
|
Trying again totally off VPN, but doesn't seem to be going much faster. Also trying on my personal laptop (2020 Macbook Air with M1 chip), which seems to be going at least twice as fast. Update: work laptop took >20 mins to load Maeve services, just started on the manager/nodered/mqtt |
In <10 minutes all containers were running and the manger was trying to start up, but seems to be stalling right after loading the config file. Oh, just took a long time initialize API module? Ok yeah starting to see the rest of the modules intialized. Ready to charge with an error but no crash: Selected ISO15118-2. Car plugin, swipe RFID, entered "Prepare Charging", then saw "Car Paused", seemed stuck. So unplugged. Tried again with same result, relevant logs below: Going to try giving docker more than the default resource on this laptop to see if it might be a timeout issue. |
|
I wonder if this is an issue with the M1 chip. Normally, I would have said this is a problem with the payment module. But that part seems to be working Let me see what is expected there for a working session.EDIT: Added logs @Abby-Wheelis |
Yes, this is a fresh install of Docker on my personal computer so I actually got an error this time,~ I haven't gotten to exactly compare the logs yet but will do that next~: The logs are definitely different, but the OSError sounds like it may very well be an M1 chip error. Work laptop loading off VPN 45 minutes and counting, very little progress pulling the manager so far. |
|
We do want to be ready to run on M1 chips if possible, so could you take a look at what that error might on the M1 chip. it seems like a fairly consistent network error, not anything specific to everest |
|
@the-bay-kay any updates on #84 (comment) |
For what it's worth, this took ~2 hours and is finally "ready to start charging" First try got the same "retry max reached" as yesterday. I was able to unplug and replug and sucessfully start a charging session! |
Trying to investigate, it doesn't seem like a super well known error, but finding a few things.
The error that I am seeing is an
|
|
Yay! So we can confirm that x86 works, and there isn't anything fundamentally broken. So this must be an M1 issue. |
|
Let's move this to the M1 mac issue (#63) to avoid cluttering this up. |
|
@Abby-Wheelis let's continue testing the x86 version here, assuming it is responsive!?! I am getting an error while setting the charging profile... |
Docker panicked again (The error message really says Stuck in EV Paused it seems. I'm really curious why we're seeing a log that says UPDATE - rebooted and went to charging just fine. Now I can try setting a charging profile? |
|
I am running into issues with setting the charging profile So I am not sure it will actually work. I think you can play around a bit with the departure time (without the charging profile) and then stop for the day 😄 |
|
Will wait for @Abby-Wheelis to finish testing with the final changes and then close. |
|
@Abby-Wheelis final(?!!) changes have been checked in. Might still change some text but running out of time for that now. |
|
I just tried again tonight with a fresh copy, it still took ~2 hours to pull but I was doing work around the house so it didn't matter too much. I plugged/unplugged three times but it just timed out every time and never started charging. I can try again when I get to work tomorrow, but I probably won't be able to pull again unless it really is just the apartment wifi and it's significantly faster in the office. |
I did include this test. Please see timestamp 5:28 of the attached video here. As you can see in the logs I provided, we end up using a schedule of length "2" after reaching the departure time (e.g., we default to the original SASchedule). Let me try to replicate your issues now. I ran into a tag mismatch when pulling the changes in main -- The environment expect |
|
oops! I forgot to push the 0.0.21 version of manager, which I can only build locally. you should be able to re-pull now... |
Testing the charge parameters EA=60, DT = 3600, SimSpeed = 100x , I'm not seeing any errors... LogsLet me test a few other input combinations -- It may be that we're incorrectly flagging the end of profile in some scenarios...
|
|
@the-bay-kay you should be able to use the parameters that I used back in my logs |
Ah, yup -- with {EA: 60, DT: 3200} @ 25x, I'm seeing the crash. Let me investigate further... |
|
Took about an hour, but I just got to test - documenting and attaching logs then signing off for the week to put my head down on some code changes for other projects. 1st try - no departure time set, entered charging fine I think it was just 3 tries, my brain is admittedly not keeping up well with me today. @catarial was looking over my shoulder so might be able to account for what happened too. Logs: Nov18_logs.rtf.zip |
7 tasks
|
I'm getting these errors inconsistently with |
|
@catarial they may be related to the setting that you commented out "Reading from tcp-socket aborted" I also want to highlight that we could also choose to rebuild multi-platform and see if that works better. I am a bit surprised that this happened in the python code given that python is a scripted language. But it looks like the python networking stack may be a thin layer over the underlying C stack, and this flag may just be different between operating systems. Would be interesting to understand that flag in greater detail, including differences between platforms. |
|
This still has the crashing issue, but that is not a blocker for the testival. Moving it out of the milestone. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Goals
In the final stages of prep for CharIN, we want to exhaustively test a variety of Software-In-the-Loop (SIL) and Hardware-In-the-Loop (HIL) demos that we have developed, to ensure that everything is running smoothly prior to the event. These tests will include (but are not limited to):
@shankari ,@Abby-Wheelis , @catarial : Tagging for visibility!
The text was updated successfully, but these errors were encountered: