Thank you.
So this talk is about how to build something with small thing embedded
Rust and then build something else from this.
This was a site project of mine.
So even though I am developer now working in Clickhouse for a startup,
I did not do this as part of my job.
I also co-founded Dracula, which is something we talked about
in in 2019 about privacy.
And we are also part of a Linux user group in
Akorunia, which is there.
And we are also going to have a conference on free software
and technology, CFT is open if you want to send something.
So first of all, I did this to make an EV charger.
Why make an EV charger? This is the wrong question.
What I wanted to do is learn embedded Rust quickly.
So for me, this has three ways of how to learn anything.
I can read stuff. I can watch others also do things.
But if you are making a project,
it is usually the best way to learn about how things work.
So I could do this with home automation stuff,
like the momentary, community sensors, something like this.
But this is already solved problem.
So it was not really compelling for me.
Or there is also for home automation.
The matter is a new standard that is coming up.
And it is very interesting.
There is not too much land on Rust that I know of.
So I could do something with this.
But the problem is that I also don't know mother.
And I have a rule with side projects.
And my side projects rule number one is that I have to know.
I have to control everything except for the one thing that I want to learn.
So that I don't get distracted by all of the other things that are also variables.
So I thought, okay.
So I have an EV, I could charge it at home for even less.
So why?
Because my parents lived in the countryside in something like this.
So we have a small amount of electricity available.
Less than 2.2 kilowatts, which means less than 10 amps for charging,
which means very slow charging and only at night.
So that we don't disrupt the rest of electronic devices and electricity
things like the fridge and so on.
There are smart chargers in the market.
They usually require physical wiring so that you put a coil from the measures
how much electricity you use in your home in the secret breaker.
And you have to run a wire to whatever the charger is,
which in this case was like 15 meters away and it through the outside.
So you have to make a really lot of mess.
And it's also really expensive for the moment at least.
And in my case, I think that cost matters.
The decisions that led me to have an EV was having cheaper electricity than gas
and cars are depreciating assets.
So you don't really want to spend more on the thing than what you need
because then it doesn't really make sense economically.
And as I said, as I mentioned before, as much chargers are really expensive.
But should they, is the tax so complex?
I'll talk about this at the energy that I promote tomorrow.
The gist of it is that, in my opinion, for this case,
they should probably not be that expensive.
So this is the economics on my side.
In Spain, at home, I can charge less than 18 euros per kilowatt hour.
Usually, on the six months before I did this project, I was charging at about this rate.
So given that I visited my parents, at most twice a month,
then I would save less than 80 years a year by charging at home.
Which means that for me, this must cost less than 160 years.
There's no charging in the market that does this, that cost less than this money.
So it doesn't really make sense to do it.
So first of all, rules to the project.
I have the following rules.
The first one I already mentioned, then make small iterations,
so that I keep myself engaged and I do things that are working one after the other,
and make sure that each iteration provides value,
so that I don't get bored and keep me engaged and continue doing things.
And also, one important thing is that I want to be intentional about
writing things that already work, because otherwise I will get distracted by this kind of things.
And also, I want to learn more of this.
And also, must be functional, so that this is something that I can export as open source
and probably be useful to somebody else.
And also, it's a bit weird.
So if there's two different ways of doing it,
choosing the fastest path is usually the best way for keeping forward with something like this.
So there are some open source projects about doing smart chargers for
forecasts, but they are quite expensive, because most of us usually work in this kind of
projects with the lectures of having nice devices, like a Raspberry Pi or something
that has a full OS that can parse XML with libraries that already exist.
And they're really nice.
But when you try to also compound it with the economics of the things,
then it gets expensive for something that doesn't really exist.
So what I did is step one, I bought the dumbest and cheapest chargers I could find.
This was 60 bucks, so that I could understand it.
The second step, this is the thing, so that I could see what's inside.
And it's really not much.
There's a bunch of wires, I measured that they could support the chargers.
And I was not being, it was not less expensive, because it didn't work.
And it didn't have enough of the hardware.
And it has this small chip on the top right that is just sending a post,
motivated with a post to the car to let it know how much it can charge.
In this very box, I could fit an SP32 as you can see there with the debug wires that already existed
in the board, I was surprised by that.
So I could even do it like that.
But let's not get ahead of her shots.
So how do we split this?
First of all, I will need a wattmeter to measure how much energy is at home.
And then this is, I think, that can be built in an SP32, which I can use in battle thrust for.
And then I need something that can tell the car how fast it can charge.
This can be something using some of these standards, or something else.
And it is something else I'll talk about it in five minutes after.
So my experience with ESPRS, I like it.
This is currently an expression product, so it is official by the people from the SP32 community.
It's less mature than the C++ SDK.
But the experience is so much better, because everything with cargo just works.
And this is one of the things that I want to highlight about how good the ecosystem in Rust is,
because with cargo build and cargo run, you just have everything.
Well, when you get to dependencies, you will get all of the things necessary for flashing the device,
and for selecting which USB device it is, and so on.
And this works in all of these OS's.
I tested on, if you have them, because I wanted to see if the experience was as good.
And it is, with C++, it's not as much.
I can tell you.
There's two versions of this.
In case you want to do something with this, there's the IDF version,
which is the C++ SDK.
It is nice because it allows you to use the full STD Rust, which is very convenient.
And it has all of the nice cities about being able to work with the normal type memory, the Wi-Fi, the TCP stack,
and so on.
It also has an embedded HTTP server, which is very convenient for my case.
And then there's the other bare-one project, which uses no STD,
and you have to build your own concurrency planning.
There's an embassy and other projects.
For that, and then you have to roll out your own TCP implementation, HTTP and so on.
So I used the IDF version for my first iteration of this, because of the number one and two.
And I initially was most of the hardware in the main.
So first of all, this was just a toy project, and then I started to rewrite things into something that worked with the lifetime,
so on for each of the parts, because I wanted to create a set up mode to be able to change the Wi-Fi connection,
and so on, we have having to re-flash the device.
And I even allowed to hot-black an SPI LCD screen, because I wanted to see things
while not connected to a laptop to see, to try to debug when things were not working.
So this is the layout of how, which things I did first and which things were pushed forward.
The last thing was implementing a web hook, you will see what in two slides.
And this is what the hardware actually looks like when plugged in.
The thing you see on the top right is just a current transformer, that measures the jumpers that are running through the line,
and then there's the ESPN as small voltage converter to run to three volts DC.
So now what? I already had this.
I could use the car up manually on the phone to calculate the amps and do it manually,
but this is very cumbersome. I did this for a few days. It didn't really scale.
Then I built a script in Python that I run from my laptop,
and from there I used the car API to tell it how fast it could charge.
But that wasn't convenient. I had to remember to have the laptop on to have the script running,
and I just didn't all the time, so I built a back end in Rust. Why?
Well, first of all, I need to do something that can get an API,
and preferably with this properties.
It's easy for me to, if it can just deploy a single static binary,
and if it's configured with a Tamil file or something like that,
and then I wanted to have a database to store all of the energy logs for all of the times,
to have an historic versions of how much energy was being used and so on.
I decided on rocket, because it had these things and also type level guards,
which I believe are amazing to ensure that you are authenticated and so on,
and also ready to make it so easy to implement.
So I don't get those by somebody random on the internet,
and then logging is built in, which is nice.
So this product uses that, and then I even,
one of the iterations of the words was just, I also wanted to see how much energy was being used,
and then I ended up even rendering an SVT with the energy usage,
so that I could see things of it a bit more interesting.
I only had one piece missing, which is the main point of the talk,
which is how do I communicate with the car?
Well, there's basically two main standard ways of doing this.
One of them is sending a pulse with modulation over one of the wires
in the charger.
These are twice physically out there in the charger's dimension.
There's also an ISO, which allows you to send XML over Ethernet over one of the wires also,
which is cumbersome, because also it requires you to send Ethernet frames,
which is one more level of complexity.
It is, the modem itself is not cheap.
I mean, not cheap for embedded standards.
And the modem, I believe, is not implemented in open-source or I didn't see it in an embedded fashion.
These things are implemented, but as I mentioned, they require expensive hardware,
which makes it not a cost-effective in my case to use.
Also, the IUC standard, the lowest you can send is 5 amps,
and since the most I had was 10, I already was halfway out of the range,
so of what I could use.
Then there's a car vendor API, which is what I ended up using,
because it was cheaper for me to go this route,
but I didn't want to commit to only needing to do one of these.
So I wanted to make this a sensible for other people,
and maybe in the future for open-source chargers.
So what I did is in the crate, where I built the backend,
I created this fairing, a fairing is a thing that you can put in rockets,
so that it attaches on every request or an ignite or any other parts of the life cycle.
And it does most of the heavy lifting,
and you just have to provide two different things.
One is basically this EV charge handler trade,
which is so first of all, the fairing is really simple,
only connect what you do, what this does is,
I just guard against only doing one change over the car at a time,
so that even if I have multiple requests,
only one of them will go to the car, the others will just measure the energy,
go to the log, but then do nothing else.
That's why I have a mutex here.
And then this is the charge handler implementation that you will have to provide for any other charger or any other API.
Just have to do four methods, which is what?
You're saying it's some name, the distribuile, then you have to return,
whichever kind of structure you want that we will keep on the fairing.
Then something that gets the state, so that you will have some internal state that you can rely on,
and then a function to request changing the, changing the apps.
The state also has to deal with four things, which is whether the car is charging,
because otherwise it doesn't make sense, so we will do nothing,
and also some other small things, and whether the car is nearby,
because if you can already know how far away it is,
then we can rate limit this, and for example, the car is in another town, like 500 kilometers away,
then you will say, okay, let's wait for five hours, because you will not go that far to wherever it is.
This is the current interface.
This is the SVG, and some of the parts that you can see there are times where maybe the system crashed,
or it was not connected or so on.
And then I have a couple of criticisms of rocket, what I used.
In general, I think it was a pretty nice and pretty easy to build,
but a think is a bit hard, because, well, in general, maybe this is something that happens with other parts of trust.
But in rocket, even though the requests are handled asynchronously,
it's not easy to move part of the work to outside the life cycle of the request and do it in another set.
We had to roll out on your own a lot of different things.
I managed to do it with static life time, so it was a bit cumbersome,
so I didn't end up pushing it to the source code.
And then there's the last part of this, which is this was a side project.
It's really efficient for doing this, how much does it take?
Well, the short answer is hyperlifias.
Why?
Well, this was basically a one-month total time for all of this,
in two weeks I had things already working,
and two weeks side project commitment level,
meaning not a lot of time.
And also, I believe that more than efficiency,
the interesting part about this is whether this is enjoyable.
And I believe it is a lot more than in other languages,
because compile them errors are very useful once you understand them,
because the compiler is really great,
but highlighting the different things that you could be wrong about.
So there's less runtime panics.
There's a bit of them, but also in the embedded controllers,
usually when you have a panic,
the handler can just restart the microcontroller from scratch.
So even when you have a problem,
it's not really something that you can't get away from.
You can, the microcontroller will restart,
and if it's not in a very weird situation,
you will just start from scratch, from a working state.
So you can recover.
And then it's very fast to compile,
especially compared to the C++ projects,
depending on how you build the compilation units.
This is something that cargo really does very well.
So there's a bit of future work with this.
Part of this would be re-implementing the wattmeter part
with the no-SD version,
because currently the version, which is the idea,
the C++ SDK, has a problem that it is quite big.
The full binary takes a while to flash,
takes maybe a minute and a half,
because it has to bundle the Wi-Fi,
the handling of all the DCP stack,
the web server, and other things that I am not using,
like Bluetooth and so on.
So by using NoSD, I could cut down on this,
because more things would be in-rust,
and it would be easier to just not include as dependencies.
And also, it would be nice to make,
and I also, 15-1-1-8 charger,
which is the one that talks XML.
In ESP32, I believe, instead of using a Raspberry Pi,
but this is something that I didn't see,
yet, as part of all of this,
because all of them just require you to build full OS,
I mentioned in the beginning,
and then it's a lot of work for only for that.
And that's it.
Yeah. So any questions?
What's I to fast?
In understanding your return on investment trade-offs,
how many thousand kilometers a year do you drive?
How many thousand kilometers a year do you drive to
understand your trade-offs for your investment?
How many thousand dollars?
How much do you drive?
How many thousand kilometers per year?
Okay, so I usually drive around 30,000 dollars.
Okay.
How many kilometers per year?
That's a twice average.
Yeah.
Okay.
Any more questions?
Yeah.
Which type of ESP did you use?
Which type?
Did you ever mention the binaries?
Get quite big.
Did you ever hit the limit of the flesh?
Yeah.
Which type of EVSE?
Yeah.
Oh, the type of ESP I used.
I used the ESP32, nothing else after that.
The risk five days.
Yes.
No.
It didn't hit the limit of flesh ice.
But yeah.
That is a concern.
That's actually part of why I wanted to use the
the No. STD version because that would be
leaving me a lot more room to play with other staff
in building my own things.
All right.
If there's no more questions,
can we thank San Diego?
Thank you.