Home Monitoring Re-Write Number Four!

Since getting the Tesla Powerwall installed, our trusted Wattson has not been able to display correct figures as it can’t tell if we are importing or exporting until the Powerwall is full.  The Wattson displays a relatively static value of +150W indicating that we’re importing, yet the data from the various other devices in the house contradicts that figure.

So it’s time to say goodbye to Wattson and hand it on to a neighbour and hope they get some use out of it.

Wattson’s demise is a great excuse to upgrade to a tablet and display a lot more information than just whether we’re importing or exporting, so I’ve gone out and bought a Samsung Galaxy Tab A from JL to replace Wattson.

In order to display more information on the tablet, I needed to re-write the home monitoring application and start graphing the data at home rather than relying on PVOutput.  PVOutput is a great website, but it’s limited to a 5 minute picture of what’s going on and I’ve run out of fields to upload data, even though I donate to get extra fields! Wattson has gotten us used to being able to see what’s going on instantly rather than waiting for a snapshot 5 minutes later.

The second re-write I did of the home monitoring application in 2015 has been running well for a few years, but despite what I wrote back then about it being maintainable, it was a pain to add in a new datasource and it was written in my least favourite framework – Mule.

Since then I’ve tried re-writing it in Node.js, but that code was less than elegant and not tested at all… It also relied on a heavy weight MySQL database which I wanted to avoid if possible. HSQLDB may be a bit basic, but it’s served me well for many years and allows me to make changes to the files in a text editor if required.

I did learn something valuable from the Node.js re-write – consolidate the five tables I had before into one large table. I’ve changed the following five tables

to a single table for ease of storing the data and to save space.

The previous database file size was 640MB (note that’s more than 200MB per year as I blogged about the database being 400MB only last year) vs. the new single table layout file size of 240MB. Every field in the database except the composite primary keys are nullable. This allows the data to be stored into the table in any order, after all I can’t guarantee which Arduino will send it’s data first.

The next step was to work out how to convert the database from the original layout to the new layout without having my pc running at 100% for over 2 hours (the first time I loaded the data from the old tables to the new table, this is exactly what happened!). The trick was to not insert based on a select union, but to use the HSQLDB merge functionality. The two hour ETL turned into a three minute ETL. This much improved ETL time allows me to take a copy of the old database (the in use one) at any time, transform it and check the new app is compatible with the schema and can write data into the new layout correctly.

As I’ve mentioned above, the new application is no longer based on Mule and instead is a Spring Boot app.   The home monitoring application receives input using Spring MVC controllers and persists the data to the database against the date and time (rounded to the minute).

At the service layer, there’s also three separate scheduled services, one for uploading PVOutput data once a minute, one for requesting the EE addons status page and scraping the data every hour and one for calling the Tesla Powerwall API every five seconds.

EE addons status page scraping I hear you say… “what’s that for?”  We no longer have fixed line internet and rely on EE 4G internet, which is great until we run out of data two days before the end of the month!  The EE addons status page displays how much data you have used, how much is remaining and how long until the next period.  Since I’ve now got the option to display a lot of different data on the tablet, it seemed sensible to display the EE data allowance too!

For anyone interested in doing something similar, here’s a class I’ve written to read the HTML and trim it to extract the right bits of information. The fields aren’t accessible as I don’t store the information – I simply pass it straight to Splunk via toString.

package uk.co.vsf.home.monitoring.service.ee;

import java.util.regex.Matcher;
import java.util.regex.Pattern;

import org.apache.commons.lang3.StringUtils;
import org.apache.commons.lang3.builder.ReflectionToStringBuilder;
import static org.apache.commons.lang3.StringUtils.*;

public class EeDataStatus {

	private static final String ALLOWANCE_LEFT = "allowance__left";
	private static final String ALLOWANCE_TIMESPAN = "allowance__timespan";
	private static final String BOLD_END = "</b>";
	private static final String BOLD_START = "<b>";
	private static final String SPAN_END = "</span>";
	private static final String SPAN_START = "<span>";
	private static final String DOUBLE_SPACE = "  ";

	private final String allowance;
	private final String remaining;
	private final String timeRemaining;

	public EeDataStatus(final String response) {
		String allowance = response.substring(response.indexOf(ALLOWANCE_LEFT) + ALLOWANCE_LEFT.length());
		allowance = allowance.substring(0, allowance.indexOf(SPAN_END));

		Pattern pattern = Pattern.compile("(\\d+.*\\d*GB)");
		Matcher matcher = pattern.matcher(allowance);

		matcher.find();
		this.remaining = matcher.group();
		matcher.find();
		this.allowance = matcher.group();

		String timespan = response.substring(response.indexOf(ALLOWANCE_TIMESPAN) + ALLOWANCE_TIMESPAN.length());
		timespan = timespan.substring(0, timespan.indexOf(SPAN_END));
		timespan = timespan.substring(timespan.indexOf(SPAN_START) + SPAN_START.length());
		timespan = timespan.replaceAll(BOLD_END, EMPTY).replaceAll(BOLD_START, EMPTY);
		timespan = timespan.replaceAll(CR, EMPTY);
		timespan = timespan.replaceAll(LF, EMPTY);
		timespan = timespan.replaceAll(DOUBLE_SPACE, SPACE);
		timespan = StringUtils.trim(timespan);
		this.timeRemaining = timespan;
	}

	@Override
	public String toString() {
		return new ReflectionToStringBuilder(this).toString();
	}
}

When I tried writing the home monitoring application in Node.js I gave Prometheus a go to see whether that would be a good tool for graphing at home.  It worked well when graphing small sets of data, but when I tried to graph over a years worth of data, it either errored because there was too much data coming back from the query, or took a vast amount of time to refresh the graph.  It’s possible I wasn’t using the tool correctly, but I decided it wasn’t for me in this use case because of the inability to graph large amounts of data and because it’s not as intuitive as the graphing tool I’ve chosen to go with.

So what graphing tool have I chosen?  Splunk 🙂

I chose Splunk for a number of reasons:

  1. I’ll be sending less than 500MB to Splunk a day, so it’s free 😀
  2. It’s incredibly intuitive to search through data in Splunk, so I should be able to give my dad a basic lesson and he can create graphs for himself. I had considered the ELK stack, but the searching language isn’t quite as intuitive…
  3. Splunk doesn’t care about the schema of the data you throw at it.  This makes it easy to work with as I can add/remove fields when required and not have to change a schema.

Writing the data to Splunk uses the ToStringBuilder JSON format and a Log4j socket appender.  The ToStringBuilder format is configured at bootup via the following component.

package uk.co.vsf.home.monitoring;

import org.apache.commons.lang3.builder.ToStringBuilder;
import org.apache.commons.lang3.builder.ToStringStyle;
import org.springframework.stereotype.Component;

@Component
public class ToStringBuilderStyleComponent {

	public ToStringBuilderStyleComponent() {
		ToStringBuilder.setDefaultStyle(ToStringStyle.JSON_STYLE);
	}
}

And I chose the Log4j socket appender because it doesn’t require the use of tokens to talk to Splunk.

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="warn">
    <Appenders>
        <Socket name="socket" host="SERVER NAME" port="9500">
            <PatternLayout pattern="%m%n"/>
        </Socket>
        <Console name="STDOUT" target="SYSTEM_OUT">
        </Console>
    </Appenders>
    <Loggers>
        <Logger name="uk.co.vsf.home.monitoring" level="info" additivity="false">
            <AppenderRef ref="socket" />
            <AppenderRef ref="STDOUT" />
        </Logger>

	...

</Configuration>

Bringing it all together, we’ve gone from Wattson which displayed only one figure – house load – as shown in the (albeit not great) picture below:

To this 😀

And this complicated device/application diagram

Hopefully this incarnation of the home monitoring application will last a few years, but I suspect I’ll be re-writing it all again at some point 🙂

References
Tesla Powerwall 2 API https://github.com/vloschiavo/powerwall2/
Log4j2 Socket Appender https://logging.apache.org/log4j/2.x/manual/appenders.html#SocketAppender

Tesla Powerwall and Rolec Car Charger

Last Friday we have our Tesla Powerwall installed and at the same time the electricians installed my Rolec car charger.  I was most excited about the Powerwall as I’ll hardly use the car charger and the Powerwall has an API which means I can add extra data to my home monitoring 😀

The whole process from emailing Tesla with some questions to getting the Powerwall has taken a while, mostly because we had to get some electrics fitted in the house before asking for a quote from Tesla.

The sign-up process is quick – fill in a brief form and pay a deposit by card.  The quote process after signing up is a lot more involved… You walk around your house taking lots of pictures and writing descriptions of where you’d like the Powerwall installed.  I’d prefer they sent out someone and I think it would have taken just as long for them to walk around my house assessing the various locations and Solar equipment as it took me to fill in the form – 2 and a half hours!  If you’re in the same boat, take pictures with a phone and fill the form in later on a laptop – you’ll save yourself a lot of hassle.

Once the quote form is filled in it goes off to your local installer (mine was 50 odd miles away) who takes a look and tells Tesla how much for their part installing the Powerwall will be.  I found this bit a little odd as we’d given various locations in the house where the Powerwall could go, but we weren’t told where it would go, so ended up asking for our installers details to contact him directly.

After you’re happy with the quote (cost of Powerwall + Installation) your installer then sends a request to the DNO who decides whether you can output from the Powerwall at 3.68 or 5kW.  This bit is the slowest part in the whole process and took around 8 weeks…!  Luckily our DNO was happy for us to output at 5kW from the battery (apologies if this isn’t the correct technical speak!  I’m no good with electrickery).

Mark Cawood (of Cawoods Electricians) and his team arrived around 8:30am on Friday morning.  You don’t get a sense of the size or weight of the Powerwall until you see it in person being lifted out the back of a van!

By 1:30pm the Powerwall and charging point were installed and the Powerwall just needed configuring.  I was surprised the process of configuring the Powerwall was so complicated and problematic.  It took around 30 minutes of trying various connections (wifi, ethernet and 3G) and filling the same form in 5 times to get the Powerwall correctly configured and setup.

By 2:30pm Mark and the guys had cleared up, given us a full demo of how to use the car charger, including some useful tips on how to store the charge cable, made sure we had access on our mobiles to the Tesla app and our Powerwall data and said their goodbyes.

I’d highly recommend Mark and the team if you’re looking to get a Powerwall or solar panels installed.  They were very friendly, tidied up and did a neat job of all the cable runs, answered loads(!) of questions we had, made sure we were able to see our Powerwall on the various devices we own and made sure I knew how to use the car charger.

Since installing the Powerwall we’ve used a grand total of 23 units, far less than our normal 60 odd units.  We’ve even had two complete 100% self-powered days where the solar and Powerwall have provided 100% of our power requirements for the day.

As for the car charger – I haven’t used it yet – still reads 0.26kWh consumed!  I’m trying to spend as little as possible on fuel during the spring-summer months since charging at work is free 😉

Tesla Powerwall!!

In my post about ordering a home car charger I mentioned that I was using the same electricians to install the charger at the same time as they install another product that I’m super excited about – well I’ve order a Tesla Powerwall!!

😀

When I picked up my car from the dealer, he said to me “you excited to pick up your new car?” my response… “well not really…” But when it comes to a Tesla Powerwall 😀 I couldn’t be more excited!

I’ve got a few more weeks to wait until it’ll be delivered and fitted as I’m waiting for a DNO approval to fit the battery, but hopefully it’ll be up and running in time for the summer.