Hacker's ramblings

Remember this one?

My new utility meter has an RJ-12 in the bottom of the unit. Naming of this port is really weird as it is called HAN, P1, HAN/P1 or P1/HAN. In Norway the port is RJ-45 and they call it HAN, for Home Area Network.Original RJ-12 from Netherlands was called P1, which is short for ... P1? I dunno! Just to be safe, manufacturers combine those two. In reality they just add to confusion.

Assuming, one wanted to see in detail how much energy is created by solar panels on the roof and combine that information with data from electricity utility meter, it would be possible to see how much money is being saved with the panels. Having detailed information on how regular household utilized electricity is a nice side effect of that.

Now that we're in Finland (not Norway, not Nethernalds), the regulation is from SESKO and in section 4.6 Physical Interface is as follows:

The RJ12 connector (6P6C connector) is used as the physical interface and the interface meets the requirements of "P1 Companion Standard".

Further, the mentioned document is from Netherlands and describes the physical interface:

Now two things need to happen:

1. Utility company needs to enable the P1/HAN -port. The port is disabled by default. Utility company needs to pay license money for each open port to Landis+Gyr.
2. Data pouring from the port needs to be read with a suitable piece of hardware. Protocol is M-Bus, a TTL signal.

Given Internet has tons of possibilities, a suitable open-source reader exists: P1IB. All the necessary data is freely available at https://github.com/remne/p1ib. Software, hardware and 3D-printer models for the case. Obviously, there is an option to go buy one pre-built.

After tinkering with hardware, enabling a MQTT data-pump on both solar panels and utility meter. Setting up a MQTT-broker to receive the published data and a Home Assistant software to have a cherry on top. Final result looks like this:

In Energy-section of Home Assistant, there are number of data visualizations. Top-left bar diagram indicates how much electricity is being consumed by the household. Blue is electricity purhcase from grid with money. Yellow is electricity produced by solar panels. Bottom side, purple, is electricity sold to utility company's grid from solar panels.

Bracket with time 12:00 has hours 11, 12 and 13 in it. As an example, during hour 12 house consumed 0.8 kWh of electricity. Of that 0.61 kWh was solar power (yay! free!) and 0.18 kWh was purchased from utility company (uff! €). However, during that hour solar production was 1,74 kWh, of which 1,13 kWh was returned back to grid. Funny how averages work, there must have been clouds or spike in consumption for the need to purchase more. On the other hand, there were plenty of times where excess energy was available. In theory, I'll get some money out of that excess. Practically: I don't. Transfer in and out costs money to me and all my potential proceeds go to transfer.

Looking at other parts of the visualizations: Obviously, the good thing is I do consume 50% of my own production, making it 42% of all my consumption. What happened after taking the screenshot was the obvious sunset. My solar panels are unable to produce anything, so all my consumed electricyt was from the grid. As a daily record, after sunset hours did increase daily net consumption by couple kWh.

Next up: Now that we know what electricity costs and the rate it flows in and out, it is easy to apply money on top of all this. It should be possible to estimate correctness of initial payback time of solar panel investment.

DLMS/COSEM or Device Language Message Specification / Companion Specification for Energy Metering is something IEC 62056 set of standards define. The use case is to enable a consumer to access readings of a smart meter. Technology is robust, it was introduced in Netherlands nearly 30 years ago. Accessing data is also very straightforward, DLMS.dev has instructions for this.

Port and magnet-attaching reader look like these:

Simple & robust. Then there is the but -part. (there always is one)

My electricity meter (let's state the obvious: provided by my utility company) looks like this:

Unit is a Landis+Gyr E450 and it has the port ... aaand the port doesn't work. In my books "work" would indicate some sort of data flow. To sort this out, I contacted tech support with questions. The reply I got was astonishing! DLMS is disabled for all units because of expensive license fee. The greedy bastards at Landis+Gyr want more money for (EU) 2019/944 given consumer rights. As the price is steep, my provider chose not to comply, which translates into no data for me.

Given EU laws and regulations, the story does not end there. In their infinite wisdom, L+G license fee for HAN P1 interface makes commercial sense, so:

Now I'm running a Landis+Gyr E360.

Obviously, the HAN P1 doesn't work yet. It needs to be enabled from network control. For the mentioned license fee. I'll get back to this when I have any data.

Last month I bumped into an incompatible DisplayPort -cable. There are many different speeds and DP 2.0 requires so much more on your cable to achieve those speeds 4K, 5K and 8K monitors require.

A famous phrase states "Go big or go home!" So I did that. Went big:

These two cables with 8K and 10K spec should have the oompf required to run any of my future monitors.

Color-coding is puzzling to me:

No matter how much I do looking & searching, there isn't anything I can find on those colors. My obvious assumption is for the manufacturer Deltaco to mark 8K with a red connector and 10K with a blue. Exactly what cable speed that translates into, I dunno. My speculation is with UHBR13.5 and UHBR20, but that's only my guess.

In my previous post on the topic I did complain on lacking markings. The boxes have semi-reasonable markings, cables have none. Besides the undocumented color coding.

I you'd compare USB-A -connectors:

Or USB4-connectors:

Both have well documented system. DisplayPort, not so much.