The most bewildering and complicated way to pay
OCPI is a standard for public charging stations for electric cars. The idea is that someone goes up, operates the charging device much like a gas pump, charges their vehicle, and drives away.
So how do I pay for something, at say, an API level? That’s easy!
First you get an authorization header assigned to you. Now you create a 64-byte UUID that you pass to a credentials URL. Inside that payload there’s also a party code (a 3 character code corresponding to who you are, as if the authorization header wasn’t enough), a country code, and a URL parameter which points to a callback on a server that you control.
Why? Because the remote server will use that callback to find out if you are running a compatible version of the API that you are trying to communicate with. So your server at that callback should list the versions of the protocol that you support.
If the remote server finds a compatible version listed on your server, then it will look for a list of command directives on your server, which should have a tokens end point, more about that later.
Are you with me? We are still just talking about trying to pay for something…note that this simplified diagram below is leaving out the implication of a number of these requirements.
Cool, now the remote server will issue you a new token and you can discard the UUID that you generated beforehand. The server will then try to see if you still have the token by going to your token endpoint on your server, at which point you should send it back the OCPI formatted token to tell the remote server that it’s still a valid token.
So now that you have that token you can get the location data of the available chargers!
Once you find one, you’ll notice that it has a location_id and an evse_uid, you need both, despite the implication of what “u” stands for in evse_uid. Once you have this, you’ll have to generate another token, an auth id, use the token generated from the dance above, both ids, and then do a POST to the RESERVE_NOW end point, then the START_SESSION end point, then the UNLOCK_CHARGER end point, using the session data from beforehand of course.
And that’s it. Well I think. See, it has taken me 22 emails spread out over 6 weeks and extensive reading into the protocol to get this far. I have to admit that I still haven’t successfully been able to start a charge from an existing account, with thousands of dollars in it, as of this writing (edit: success happened about a week later). I think I know why though…
These people are are on crack.
If I have an account with a service, with money in it, and I want to pay for something, then I should have a way to do something like:
curl -X POST -H “Authorization: <secret>” https://zombo/authorize/id
And that’s it.
I shouldn’t have to say, write my own personal OCPI server that talks to the remote OCPI server so they can be penpals just to authorize a payment on an existing account. We also shouldn’t be taking moves from the XML validation playbook where we have some elaborate coronation ceremony to establish protocol cadence like we’re the V.44 modem standard.
To be honest, none of this is surprising. Elaborate impenetrable architecture that is as arcane as possible, almost as if there’s a game with some kind of point system for obtuseness, has become immensely fashionable.
The modern office has done away with overly fancy business clothing and replaced it with just overly fancy business.
As exquisite and complicated as possible.
Somewhere, about 10 years ago, this became the most coveted merit of a good engineer — be perplexing and difficult; as if a Victorian Englander fancied programming for high fashion.
I feel like there was this industry-wide pep talk that I just missed:
If you want to be a serious professional programmer, you must create profoundly complicated Rube Goldberg machine solutions to simple problems. For instance, use as many callbacks and event systems as possible. Make sure stack dumps are useless and stepping into functions just sends the user into a nearly infinite series of nesting dolls, concealing the true cause of the issues for as long as possible.
This must be it. There’s some secret mysterious oath to make everything secret and mysterious.
I’ve seen people in lecture halls holding bated breath in a cult-like awe, as they bask in stories like “I’m hot-loading a transpiled language, released last week, and I use JSON blobs in mongo to create SASS that then gets JIT compiled to CSS and inject it all into the page to display a paragraph of text.” they gasp, “How extravagant! What a lavish solution! What excellent execution! 10MB of code for 1KB of text! How victorious!”
I see these startups with entire floors of engineers, heck entire buildings, all dedicated to writing what should be really simple things … like an application to pick up your laundry or walk your dog. Somehow the industry decided $100,000 problems become more important when you spend $10,000,000 on them and take 2 years to do them instead of 2 months:
CTO: Make simple things grandiose! We need to justify that series B round somehow! Quick, let’s move things around in our UI again like we’re a group of absentminded interior decorators.
Now we’re really changing the world with, say, that vegetable home delivery service. Look at how ostentatious our giant Kafka mess is! We rewrite the entire back-end in a different language every time a senior manager gets swapped, just like a real company!
30 years ago, people thought computer programmers were insane because computers were hard and resource constrained. The tooling was slow and buggy so productive people had to be savant-level good especially with no world-wide-web to cheat with.
These days, people think computer programmers are insane because well, most of them just are.
