New API endpoints

In the early days, rather than build out a full REST API to access our databases, it was more efficient to use a wrapper called xMysql (https://github.com/o1lab/xmysql), which automatically generates an API over a sql database. This was the mvp approach but the goal has been to migrate away from this and centralize all access points to the database through Apollo. We have committed to this transition with all recent projects, and in this release, we built out a number of endpoints required for our new mobile Harvest application

Updates to prepaid billing logic

It is our commitment to households that we do not bill a house for days where the quality of service was inadequate. After recently releasing the “boost” feature on the pod, homes now have the ability to exceed their daily allowance, we updated our payment logic to not just check for the presence of blackouts, but also check if the user was able to consume their whole allowance. If the entire allowance was consumed, that is considered a billable day.

Store firmware version in timeseries data

Timeseries data is, as the name suggests, data that changes over time. All sensor data that is sent to the cloud from each pod is timeseries data. Relational data, by contrast, stores objects and maps any relationships between them, but is “stateless” or does not capture changes over time. As we focus on reliability and scale, our firmware and hardware team realized that it is important to know the running firmware at any given point in time, to be able to better debug and diagnose issues, so although firmware is stored in our relational database, Apollo now appends the current firmware version is as it receives and stores each timeseries data point. Now we can look back and see exactly what code the pod was running, at any moment in time.

Stability improvements

Bug fixes in this release included:

  • Better error handling of deprecated entities in the database