5. Technical - Week One
Week one so far has been all I could have hoped for and more. The other interns and I have taken the opportunity most evenings to do some exploring of the San Diego coastline, the project I’ve been assigned has been challenging but steady, and I’ve come to feel quite at home with the work/play lifestyle out here. I’ll talk about the work I’m doing as detailed as I can without violating any sort of Intellectual Property rules and without boring any reader to death. This one will be purely technical so feel free to jump to another if this isn’t your thing.
Going back to the description of the project in the last blog, my first task is to research and select a suitable database for the Electric Vehicle Autonomous Renewable Chargers (EV ARC) to post to. The systems can feed information about it’s inverters’ voltages and current, which allows us to determine if solar power is being produced, whether the internal batteries are charging, and whether there exists a load (e.g. a vehicle plugged in and charging). Each system has a secure cellular Linux router that has the capability to run Python scripts. This is essential to getting this project off the ground. Without this router, the data could never be uploaded to an external database. Currently, the system pushes inverter data to a SQL database stored on a paid server and no action is taken with regards to the delivering it to the owner of the EV ARC. I believe Bryan uses it to debug errors in remote systems and that’s about it.
So, is a SQL database good enough?
Let’s have a think about our overall goal: create a customer experience such that they can view and control their EV ARCs on many platforms. My initial fear was that SQL may be too rigid for app development. A relational database like SQL requires a lot of management and generally provides difficulties in developing front-end tools. Relational databases have a fraught relationship with applications written in object-oriented programming languages like Java, PHP, and Python, and both Android and iOS apps are written in OOP languages. The alternative is NoSQL. When the term was invented I believe it was to literally mean No SQL - no relationships, unstructured - but people have now given it a backronym of Not Only SQL, as some of the features of SQL are present like querying, even though the syntax differs. Either way, when dealing with large amounts of data and for ease of read access via mobile apps I see NoSQL as the best approach. Our data can be accessed via APIs and can be read in the form of simple Key/Value pairs within documents. Each document would represent one current state upload to the database. Clear and simple. Time to choose our NoSQL DB.
In the past, I’ve had experience developing my own Android applications using a NoSQL Backend-as-a-Service database called Parse. The company was bought over by Facebook in 2013, which was great as you could use their API to login via Facebook on your apps and export all the data to the Parse DB. However, in 2016, Facebook shut down it down and open-sourced it. It never regained the number 1 spot. I had very briefly used another company’s BaaS called Firebase. This was brand new at the time and I never completed the app to utilise it fully. This led me to check if it still exists. It does and, guess what, it was acquired by Google. They swallow up every decent tech company these days. At least with this, though, I have little fear that it will shut down. They are implementing cutting-edge technology such as realtime databases, cloud functions, machine learning, the works. Firebase, or Cloud Firestore, the section I’ll be using, looks like it is here to stay. Good for the longevity of the apps I’m going to make. After a little more research, I settled on Firestore. They provide authentication for apps, really straightforward DB read/write access, and custom security rules that can limit access of any subset of users.
I discussed the proposed platform with Bryan and he is onboard with the idea. As I said earlier, Bryan has a Python script that posts the inverter data. But that is only the inverter data. With this we can’t see what charging ports are being used, what voltage the EV ARC outputs, the number or length of charging sessions, the number of EV miles stored in the batteries, etc. This is data a user surely wants, and it all comes from the two suppliers of the chargers within the EV ARC. I’ll need to access their APIs and parse the data. Next port of call is to refactor Bryan’s script to upload to Firestore and to figure out how to get this charger data.
Bryan’s script is a pretty good script in that it reads the registers of the EV ARC, takes the appropriate data, and uploads it to a SQL database using PHP POST. It doesn’t follow programming standards, like object-oriented approach, or even functional programming. It’s all just one long script with variables instantiated randomly down the script. Refactoring it to OOP not only makes it more maintainable but it also allows me to have a separate file for the specific configurations of the EV ARC the file is deployed on. This means any time a new EV ARC is built, only the config file needs to change to suit. This didn’t take me too long once I understood the aim of the script.
Now, I’m sure this has been enough technical splurge for you so I’ll end it there for now. I’ll talk about the frustrating challenges of accessing the charger APIs in the next blog. As I’m working 9-6 Monday-Friday, most of the play time is done at the weekends so look out for those blogs if you’d rather swerve the nerd jargon. Thanks for reading. I’ll see you in the one next one.
|Previous Post||Next Post|