Rick's b.log - entry 2026/03/22

mailto: blog -at- heyrick -dot- eu

Linky TIC interface

This isn't to say that it wasn't without pitfalls. For instance, I unplugged the device from the PC as it was booting, and this trashed the SPIFFS filesystem. No worries, the next reboot will format it.
Nope, it crashed, talked about a task not found, something about canaries, and then coredumped.

I had to switch from "Huge app 3MB, 1MB SPIFFS" to a different model; I think I picked "Minimal 1.5MB app, 700K SPIFFS". Then it worked. The software, when built, uses 42% of the available program space (but note that most of those 1,016,255 bytes is the underlying firmware and not my code), the variables use 14% of dynamic memory (again, much of that is liable to be the firmware).

There doesn't seem to be any protocol for wiping or flashing the SPI filesystem if it gets corrupted; certainly I didn't see an SPIFFS.format() call. So it'll try to mount it, crash out with an error and bring the whole device down. Marvellous.

Anyway, above and beyond that I made all of the debug statements conditional with #ifdef because the traditional TIC runs at 1200bps, so debug statements - even if they aren't going anywhere - will take a notable amount of time - each character will take about 6.6ms to send; 15 characters will take 199.96ms, which is a tenth of a second; and recall this isn't actually doing anything productive - whether or not there's anything connected, it'll still take the time to wiggle the wire.
To put this into context, the generic set of debugging messages made the "letterbox has been opened" LED flash about half its regular speed.
You can leave the messages in place when you're running at 115,200bps but when you're doing a fiftieth of that... you just don't.

I also had to build in conditionals for local debug (115200, 8N1) or proper debug (1200, 7E1). The reason for the difference is because while I can slow the Arduino serial monitor down to 1200bps, it is hardwired to 8N1. Luckily I can use my phone and a USB serial app to do the correct protocol, so the ESP32 can receive data from the electricity meter and output messages to my phone.

"TIC" means Télé-Information Client, it's a protocol by which electronic meters can output some information on the status of the meter and your electricity. The Linky smart meter supports the traditional protocol (1200bps, limited data) or a new "standard" protocol (9600bps, lots of data). For compatibility reasons, the meters will run in the traditional mode by default - and switching over is not something the end user can do. One must submit a request to Enedis along with an explanation of why - and they'll push out a message to tell the meter to switch.
As it happens, at this time I'm primarily interested in the main meter reading, and the current "right now" consumption. Both of these are available in the traditional mode, so I'm using that.

If you're interested in more, Enedis has a datasheet (but it's in French, obvs!).

As was discussed back in January, the actual data transfer is serial data superimposed on a 50kHz carrier. This output is galvanically isolated from the smartmeter electronics, and must be passed through an optoisolator. The output of that, when pulled to 3.3V, can then simply be fed into a serial input and read.

In order to keep things simple, every loop I look at the WiFi (is it still connected?), I look at the reset button (the one to acknowledge the letterbox and turn off the blinking LED, not the one to reset the device - that's hardware, I can't trap that!), the switches in the letterbox, and now I look at the TIC.

The TIC code works by having two buffers. When the TIC routine is entered, it first looks to see if there's any data to examine. Afterwards, it will see if there's any serial data.

The examination happens first so that any pending buffer gets cleared before new data arrives. The read routine doesn't care whether a buffer has been processed or not, it'll just stuff bytes into whatever buffer is the current one.

When looking at the buffer, I look for "BASE" which is the meter reading to an accuracy of three decimal places. In other words, the meter itself shows you the usual kWh reading, but the TIC information provides you with watt-hours. I wonder how often the lamp on the meter blinks, if it's once every time the Wh changes?
Then I look for "IINST1", "IINST2", and "IINST3" which are the instantaneous power levels (in amps) on each phase. There's also provision for looking for "IINST" for single-phase meters. At this time I don't do anything with this information. To give a correct reading, you'd need to multiply this by the voltage on the phase, but this information isn't available in traditional mode. That being said, multiplying by about 230 would be close enough.
And, finally, I look for "PAPP" which is the "apparent power" being delivered. This is reported in volt amps but it's close enough to watts that we can treat them as the same thing. The actual difference is long and technical and has to do with the difference between loads that are resistive (like a kettle) and those that are inductive (like a computer power supply). But, you know, you're running a 2.7kW kettle and the meter is reading 2850 (plus a little for the fridge and some other stuff), yeah, it'll do to think of that as how many watts you're consuming. Not entirely accurate, but close enough.

At this time I don't record any consumption history or averages; that's for another day. Also, I don't bother to calculate and validate the TIC checksum. Once in a while the BASE is read as zero (this might simply be data loss due to the time taken by the debug output), so I simply trap if it's under 10000 (a meter reading of "10") then ignore the value. The other data seems to be as expected.
These values are remembered and when you ask for the /power URL, it'll report the last recorded information. The Linky is continually spewing this, so it'll be updating every two seconds.

Reading the serial port is also really simple, as it's in the Arduino loop() so it gets called a LOT.
If there's any serial data, and that's not a carriage return, put it into the serial buffer and increment the write pointer. If the write pointer reaches the length of the buffer, simply wrap it. This might happen due to delays in the letterbox switch code for trapping if it's a false opening or a real one. It doesn't matter if data gets corrupted, the transmission from the Linky is continuous so it'll fix itself in a couple of seconds.
When a carriage return is read, the buffer is null terminated as is expected by C, the write pointer is reset to the start, and the buffer is swapped for the other one. The routine then bombs out, so it only reads one line at a time. This is to prevent a case where a backlog might cycle between the two buffers without actually trying to read their contents. That is why the buffer examination happens first; so when we come back to the serial reading, the buffer has been dealt with and the serial handler can swap if necessary.

And, well, all of this just runs endlessly in the background.
In order to keep the ESP32 cool, since it isn't actually doing heavy lifting here, I've built the firmware for the slowest (80MHz) clock setting. There's no benefit whatsoever in using the 240MHz option. Sure, it'll take slightly longer for web pages to be served, but that's an acceptable trade-off for the device not being roasting hot; for RF shielding, the ESP32 chips are usually stuck inside little metal cans with no heatsink and no airflow. I've had two ESP32-CAMs die on me, one was hot enough that it started to melt the µSD card. Which, obviously, didn't work either by the end of things.

Here is a photo of the wires coming out of the Linky meter. As I have three-phase, the TIC is at the top. On single-phase meters it's down the bottom.

Here's a photo of the little breadboard with the circuit on it. The optoisolator and current limit/pullup resistors have been tucked underneath the ESP32 module, as it was a convenient place to tap off the 0V and 3.3V. I have used a flying lead (the red wire coming out from underneath) in order that I can disconnect the TIC from the serial port if I want to.

And, finally, here's a screenshot of the stupidly simple report that the device produces. It currently only says the meter reading and the current watts used...but that's exactly what I need to tell if my car has finished charging.
Because, yes, I am exactly the sort of person that would spend money on components and then the time for researching and software development in order to not have to walk the five or six steps to the meter and prod the button a few times to bring up the consumption display on the meter itself. If you think that's painfully lazy, remember that this may require being done a number of times, so it's much less hassle to just open the report in a browser tab and hit refresh once in a while. And since it's really really simple HTML, it's fine on NetSurf.

Remember, I'm using an ESP32-Cam for this, so I can't do anything nifty "just because" like put the readings on an OLED - most of the I/O is taken by the camera and very little of use is tracked out to pins.

My colour perception

The premise is really simple. The screen shows two patches of colour side by side. You just have to click the point where the colours change. Whether or not you can tell the colours apart determines how good your colour perception is.
Which is, frankly, right up the alley of a visually oriented neurodivergent person who uses words like "brick", "teal", and "cyan" instead of "red", "green", and "blue".

There are 40 rounds. Most people get around 0.02. Vince got 0.0085.
I scored 0.0033 and I know I screwed up a couple because I was tired and not paying enough attention.
Amusingly, the site said "Genuinely remarkable. You sailed past the theoretical human limit like it owed you money. I'd accuse you of cheating but I don't actually know how you'd cheat at this.

It's easy. My brain isn't wired up like normal people's brains. And as I said, I'm a very visual person. I learn by seeing. A couple of weeks ago I found a location shown on the publicity photo for a holiday gifted to a retiring colleague by looking at the photo, translating it into what it would look like from above, and then just working around Google's Satellite view until I found it. So me being able to tell one colour from a near identical colour shouldn't be a surprise.

Of course, the downside of this is that I am highly aware of the video compression artefacts where dark colours tend to get smudged into blocks of murky dark grey-brown sludge. Other people don't seem to notice this...or, perhaps those poor sweet summer children think that's how it is supposed to look? I guess if real dark grey and real dark brown look alike to you, you'll not notice this problem. Or maybe I was spoiled growing up with analogue TV which had many faults, but when you had good reception it was pretty decent. Note also that growing up in the UK I'm used to 576 lines of picture, not the 480 that NTSC systems offered. Also PAL had sorted out all the colour faults that led to NTSC being nicknamed "Never Twice the Same Colour". Indeed, no PAL television had or needed a "hue" control on the front.

Anyway, I scored an obviously impressive 0.0033 and I know I could have done better; but I'm happy enough with that result.
Let me know in the comments how you score, should you try it. Oh, and if you try it at night, don't forget to disable night mode (blue reduction) during the test, as that messes with the on-screen colours which may make the test harder.

An old printer

I've not used this since ~1992 - that's ~34 years!

Something of a surprise compared to these days, there were three tabs at the bottom of the front panel to loosen and remove it. Inside, two tabs, one on each side, and the entire top just lifted off.

I stripped down and cleaned the print transport mechanism, and got sidetracked by Amazon. It seems it isn't possible to purchase fanfold paper with sprockets down the sides any more.

Due to age and corrosion to the plastic, the knob to push the platten down (to allow the paper to be lined up) snapped off. Granted, it was a small plastic lug taking a bit of force, but still. Thankfully there was nothing important on the other side of where it was attached, so I bodged a repair by whacking a chunky self-tapping in place to hold the knob where it is supposed to be.

Here is a photo of the circuit board. I think the brown socket at the upper left is for installing a different interface. Given the age of this thing, we're probably talking some form of serial.

I haven't been able to find anything on the PJVI M6364M other than a lot of Chinese sites claiming to sell it, but disagreeing on what shape it is, and none of them saying what it is. This is also mixed in with a lot of hits for the LM6364 which is nothing related.
The important chip is the one at the bottom, the NEC D7810 which is an 8 bit microcontroller with 16 bit data paths internally, 4K ROM, 256 byte RAM, 44 I/O lines, etc.
The chip on the left is an NEC D65006 which is a gate array, though it says that on the board. A gate array is a semi-custom chip that allows a designer to replace a pile of discrete CMOS logic with the same sorts of things embedded into a single chip.

Of interest is the inclusion of a programmable EPROM (in a mass produced commercial product, no less!). It is marked PJWIP 1180U IC6 V182B 27512. IC6 is which socket it goes into. PJWIP may be the author (WIP for work in progress?). 1180U is the model of printer (U for universal?). 27512 is the size of the EPROM, 64K. I wonder if this contains the printer firmware, or if that's embedded in the internal ROM and this thing is maybe a bitmap of all of the character fonts? There are several fonts (Draft, Courier, Prestige, and Prestige Bold) at pitches of 10, 12, 17, and proportionally spaced. I think the Epson may also offer the standard selection of Pica and Elite, though I'm not sure if these are additional or if Courier and Prestige are Panasonic's names for them. At any rate, it's going to need a lot of bitmaps of how to fire the print head for each character (in two printer emulations and multiple language options no less!).

Not so long ago I talked about obscure DIP switches to configure printers. Well, here you go.

There's nothing to say what any of these are for. Thankfully the Internet helps.

I put some fountain pen ink onto the printer ribbon, which had long since dried. Putting it into the printer and invoking the status print just shows marks from the ink on the ribbon. It's possible that the print head has rusted and jammed, though it is making the expected noises.

I have ordered a replacement ribbon from Amazon. If that works, cool, I can play with this. If it doesn't, oh well, I've only lost seven euros and I have a billion other things to spend my time on. In fact at the rate I'm going I'm going to die with oh so many things never done, and I think my Netflix watch list is already longer than my remaining lifespan. Time is so unfair like that.

Well, nothing else I can do right now. I'll have to wait until the ribbon cartridge arrives and see if a new ribbon works. I'd have thought that I'd have seen something, but... let's see what happens.
Another day.

For now, it's quite dark outside, the sun set while I was messing around with this (and it didn't help my back one bit) so we're cruising right into that "stare into the abyss of the freezer and suffer a brain freeze because everything is just too much effort". Yeah, story of my life.

Okay, here's what I've done. I've put a quiche into the oven. It'll be ready in 35 minutes. I'll have that and a couple of yogurts. Simple. ☺
PS: My power consumption heating that is 1760 VA. In case you, like, care.

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺
As of February 2025, commenting is no longer available to UK residents, following the implementation of the vague and overly broad Online Safety Act. You must tick the box below to verify that you are not a UK resident, and you expressly agree if you are in fact a UK resident that you will indemnify me (Richard Murray), as well as the person maintaining my site (Rob O'Donnell), the hosting providers, and so on. It's a shitty law, complain to your MP.
It's not that I don't want to hear from my British friends, it's because your country makes stupid laws.

You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.