I installed my electric car charger (EVSE) at the end of 2013.

It wasn't on a separate meter since I did the analysis of being on Dominion's Schedule EV (local mirror) and concluded that while it would result in a marginally lower power bill, the restrictions on meter placement due to the terms of the Dominion Blue Book would have made it take years to recoup my investment in conduit, copper, labor, and an electrician dispatch for the non-DIY parts. Indeed, I didn't run a dedicated circuit for the car charger, preferring to feeder-tap the circuit to the welder outlet by the basement door and put in a tiny subpanel with a 40a breaker to feed the charger. I can't weld and charge my car at the same time but that is hardly the end of the world.

That left me, though, without a way to track electricity usage by the car, aside from spitballing it from number of miles traveled or a similar metric.

Finally, I decided to go ahead and buy my own meter base and a meter to put in the circuit so I could watch and see what I was using.

It's worth noting that the technology deployed by Dominion here is AMR (Automatic Meter Reading), not an AMI (Advanced Metering Infrastructure). The line can be blurry between the two since they're two points along an evolutionary spectrum, but the power meter supplied by the power company is an old-school mechanical meter that has an add-on module that speaks ERT in bubble-up mode. Basically, every few seconds there is a burp of low speed data in the 900 MHz ISM band that gives a current set of metrics for the meter. Since it can be picked up hundreds to over a thousand feet away, the meter readers just drive a route with an antenna and pick up the signals.

If you were thinking "gee, I wonder if anyone has done an FOSS implementation of a receiver for that", the answer is "you betcha they have". It talks to the ubiquitous inexpensive DVB-T tuner dongle that gets repurposed all over the place for everything from listening to ADS-B to police scanners.

It's also a great way to get your feet wet in DSP (local mirror).

The signals that rtlamr receives from Dominion's meter get spit out as almost-json-that-doesn't-pass-a-validator, so here it is un-prettyprinted:

{Time:2019-06-30T14:44:54.244 SCM:{ID:12345678 Type: 5 Tamper:{Phy:03 Enc:01} Consumption: 9192051 CRC:0x544D}}

That's all it sends - Standard Consumption Messages - no interval data, no net metering, or anything else like that. I suppose that if I were to acquire a grid tied solar array I'd get a different meter. Of note here is that the ITron R300 add-in module in my utility-supplied meter reads in quanta of 10 watt hours (my June 21st meter reading per my power bill was 91255 and per the above SCM message, my current reading is 9192051).

I'd been under the impression that all SCMs were accurate down to that level, or at least all low-feature ERT senders from Itron or its predecessor organizations.

Turns out I was wrong. The meters I got off eBay (hey, buy two, they're under $22 each) were Itron C1SR Centron Form 2S meters, with 2002 manufacture dates set up for passive remote reading with ERT. Unfortunately, the data they burp out, while sent more frequently than my house meter, is limited in resolution by its reporting quanta of 1000 watt hours (1 kWh) - a difference in resolution of two orders of magnitude.

{Time:2019-06-30T14:45:04.105 SCM:{ID:87654321 Type: 4 Tamper:{Phy:00 Enc:02} Consumption:   82415 CRC:0x3205}}

In simplest terms, with a load of a scant 7 kW, we get 7 increments an hour, which does not make for nice pretty graphs. Dominion's meter appears to spit out data every 5-30 seconds (though this may be an artifact of my receive frequency window size and how wide their frequency hopping window is), and if presented with the same load would see an increment of at least 1 at most updates.

So, the search continues - fortunately putting in a new meter is super easy since it literally pops into a utility-grade meter socket, and I'm not complaining about what I've got since I have already tracked about 100 kWh worth of power usage in less than a week; I just want tighter resolution.

The documentation on such meters tends to not go into wire format, so you have to read between the lines on stuff like SCM+ developer notes (extended format SCM with a larger device ID field since they ran out of their initial address space). I am left wondering if type 5 vs. type 4 SCM messages carry the implication of different resolutions with them.

To do: put it in influxdb and grafana.