Defensive coding

Business systems can be written over long periods of time and in a variety of scripts and languages, and we (A&A) are no exception. Some of the systems started life more than 26 years ago and even before A&A existed.

Obviously all of the code, and scripts and web applications and so on have been updated over the years in many ways. If nothing else the advances in security best practice alone are reasons to update systems.

One aspect to the way some of the code has been written is "defensive coding". This is basically assuming the worst can happen (either by accident or malice by an attacker) and trying to ensure the outcome of such will always be "safe" in some way.

The way we (A&A) do Direct Debits is one example of this. At every stage in a very complicated set of processes and scripts we try to assume the worse and take the safest action on failure. And one area of this is the notices sent to customers. There are a load of rules we should follow, and (seemingly unlike so many other companies) we try very hard to follow the rules very very carefully.

For example, if we have notified a customer that we will "collect £20 on, or immediately after, the 1st of each month" we record that fact and try to ensure that DDs only go in if that is the case. The rules allow up to 3 working days later, but the second we are not collecting £20 exactly, or it is not exactly on the 1st or within 3 working days, we cannot rely on that notice and so the DD is not allowed. Indeed, if we notify the customer anything else such as cancelling a collection, we discard the record of that notice so a new notice has to be issued.

Another aspect is checking it all worked, this is a key step for defensive coding - scripts and systems to check things that should work have worked. Such a system flashed lights, dinged my phone, and even set off the very loud teletype in my hall in an attempt to make quite sure I knew things were not quite right and that some intervention may be needed. That said, the comments on Mastodon and call from staff were also a clue something had happened!

So what did happen yesterday?

With all of this in mind, shit happens, and did yesterday, and a load of A&A customers were told their 1st June DD collection was cancelled. So what happened?

The root cause was an update to one of our billing systems SQL servers. We do updates to all sorts of servers all the time, and it seems the timing of this was unfortunate. Many updates are to ensure all security patches are applied, and so done as soon as possible.

Once again, defensive code - the systems generating billing records, e.g. for calls, queue them up until the SQL server is back. And the billing system using these databases to make bills will re-run a few hours later if there is any issue accessing the data so just delaying bills slightly.

The problem is that there was, apparently, a small window each month where there is a process of "working out what people will be billed in two working days". This is a test/dummy billing run. This is done to confirm the regular direct debits are as expected and ensure they are submitted to BACS two days in advance, so two working days before the 1st of the month, i.e. yesterday. That was the system that failed to access the database, and unlike normally billing runs, which can run a few hours later, it left a load of customers set up to not be expecting a bill on the 1st.

This is a small window, and as a result it meant that a load of customers were not expected to have a bill on the 1st, even though they will. If the bill on the 1st had an issue it would have run a few hours later and still billed. But this was a test/dummy bill run in advance and run only once a day.

It is not just the 1st, we have billing on 4 week cycles, and every full moon, and all of these work in the same way.

What happened then is the direct debits scheduled for the 1st were cancelled because the test/dummy billing run did not say a bill was expected. The system sending the cancel emails knows to also forget the previous notice of collection. This means that not only were "cancel" emails sent, but once the bills do happen on the 1st they will need a new Direct Debit collection notice email for 5 working days to be sent - so following the DD rules.

It means people will have a DD collections on the 8th, not the 1st, and then from the following month should be back to normal.

Whilst it is a mistake, the system, being defensively coded, has followed the DD rules for notices to the letter, delaying collections, and sending new notices.

What have we done?

We have changed the logic slightly, which means this should not happen in quite the same way, but we have also made sure the ops team know not to do an update in the middle of this test billing run in future.

Sorry for any inconvenience caused by an extra week's credit / time to pay on your bills. As always we try to learn from our mistakes. And well done to my staff handling all the calls and emails today on this.

SQFMI Watchy (first impressions)

I decided to get a Watchy to play with - mainly as a learning exercise, and I think for that it will be perfect. It was not that expensive (£48.80+VAT from Mouser, and free delivery). It comes as a kit which is very easy to assemble (probably because of the hassle of EMC, CE, UKCA, etc) but it is sold as a development device so not unreasonable, IMHO.

Hardware

The hardware is an ESP32, plastic case, rubber strap, battery, accelerometer, vibrator, real time clock chip, 4 buttons, a 200x200 e-paper display, USB connector, and battery charging circuit.

This is quite a nice set of hardware. My main concern is the e-paper display is not, in any way, protected, other than the recess in the case. I understand a screen protector may be available. As a watch it is slightly chunky, probably more than necessary. But it is nice. They have a milled aluminium case option as well.

Out of the box

Obviously it is a kit and needs assembly, which is very easy, but then it does work. However, I would have expected it to be a bit more slick to be honest. This has been around a few years now. Small details like...

• Button pushes are not handled well, e.g. you can select an item in the menu and immediately have clicked the menu for the item - an example is Set Clock, which you have to press to select very briefly or you have skipped the "hour" and moved on to "minutes". Button response and handling could be a lot better. (Obviously the clock is ideally set by NTP over WIFi).
• It lacks simple setting like time zone, even without DST, this seems like a setting a watch should have. It can be set, but by editing an include file in the code and re-flashing. The nicer default code also grabs weather but has a default city code set of New York, and you have to edit the include file to change that. A UI for that may be harder, but remember it has the option of serving a web page for more complex settings, so could handle this.
• The 7 segment font is nice at full size but looks badly scaled down on smaller digits, which is a shame.
• You expect to be able to upgrade the firmware, and there is an option. But the option says to go to a web site from bluetooth enabled phone, and click next. But the web site is the main page for Watchy and that has no hint of any tool for loading new code by any means. Why not have a simple WiFI OTA upgrade option?

P.S. I did not even consider, but for some, choice of 12 or 24 hour clock needs to be an option.

Trying some other code (examples)

Mouser say it works with Arduino, MicroPython, and ESP-IDF. The main reason to getting it was it works with ESP-IDF as that is what I use.

However, it seems it works with Arduino and PlatformIO. I see nothing on the web site about an ESP-IDF build environment.

I went for the simple option of loading Arduino. I don't like it, but it works, and the instructions were simple enough and only a few steps. It worked seamlessly to load new code, and that is where I found the include file for location and time zone and city.

There are a load of "example" watch faces, but they are all pretty crap. They are a fixed background and time in a different font. I mean there is one that looks like a DOS screen with time on the files listed. It is not good as a watch face really, but I see what they are getting at. But the others are all a similar theme, they just have time and maybe date in different font on a static image.

I would have hoped for something more interesting. Faces with sunrise/set, or moon phase, or an analogue face. But all the examples are boring. Now, I may well be missing a treasure trove of code somewhere on The Internet, but a poor impression to start with.

It would have made sense for the "standard" build to have a choice of "faces" as an option, all in the same code, even.

Learning exercise

As I say, the main reason is a learning exercise, so I hope to make my own code for this from scratch. This means e-paper drivers (I have done some before, so not hard), and accelerometer, and RTC, all of which should be simple. I can then make a nicer watch app for a start, I am sure. But not sure I would use as a watch. I know I have done a good job if one of the grand kids wants it when I am done. I was pondering showing solar production stats on it even.

But longer term there are a load of things I can learn using this as a test platform.

• Ways to manage battery power, e.g. deep sleep until end of minute when updating time, and maybe the low power sub processor to check for button presses in between. That is all useful stuff to learn as they are features of the ESP32 and important for a lot of applications, not just a Watch.
• Battery charging - I have not done battery based boards, but this has a battery and does charging. This is a good starting point to get my designs handling batteries sensibly.
• Directly connected e-paper. I have played with e-paper but always as a "module", a display and board and some chips and a row of 0.1" connectors. This is directly e-paper to a connector on the board. This would be good to do on any design I have using e-paper. It makes it cheaper and smaller than using a module. So this gives me a way to do it (PCB wise) and a test platform.
• Direct antenna. This uses the ESP32 chip directly with printed antenna. I have not dared do that myself. But if someone has done the work, I can copy what they did. It makes for less space and cheaper part and production than using the ESP32 modules. Definitely worth a try.
• The accelerometer is not something I have touched before, so would be fun, but outside a watch I do not expect a use for it yet. The same is true of the RTC chip - they are generally quite simple.

Will I find the time?

This is perhaps more of a challenge. If I can get it off the ground with my own code, even just working the display, then I think I'll make a complete ESP-IDF based Watchy platform myself. I'll see how it goes.

Battery

And an update - I loaded the latest code and fully charged, and that was a week ago. It is still going. I am impressed, especially as it has been using WiFi to check weather to display and get NTP, regularly.

I am tempted to leave it until it stops. Being e-paper it should leave a time of death on its display in much the same way as an old mechanical watch in a murder mystery would do so, allowing a detective to prove the accurate time of death just after the medical examiner has got it wildly wrong.

Update: It lasted just under 3 weeks (20.5 days ish).

Shoe laces

I have not posted for a bit, mainly due to the broken rib or two, broken elbow, damaged wrists and knee, and bruises, smashed glasses, and basically typing for more than a few minutes hurting.

So a simple PSA...

[yes, for those that are failing to put 2 and 2 together here, the injuries are a result of this shoe lace error]

If you have shoes with laces like this (Salomon brand) :-

There is a pocket in the tongue for them. It is no good just pushing them through the loop at the end to keep them out of the way (well, that worked on the previous shoes, but don't risk it).

Right, now time to pop to chemist for more pain killers.

Update: The stronger pain killers are helping, but very evident when they start to wear off, still.

USB Lead (and the state of modern tech and advertising)

I wanted a simple dumb USB power lead, basically from USB-A with GND and 5V to a USB-C plug, for my coasters.

I looked and I looked, I could not find anything simple. Indeed this is typical of the things I found:-

As you can perhaps see, it shows a lot of active components in the USB-C plug. Indeed, it claims advancements from 2018 (1A) to 2020 (2A) and 2022 (3A) charging, perhaps justifying these many active components.

I did not want that, I did not even need D-/D+ connecting, just GND and 5V, so I looked and looked, and eventually decided to get some anyway. Basically as long as they worked for power, I could ignore the extra "tech" that may be in there.

I suspect you can all guess what happened next...

I got an extra lead, so I could cut it open. It is surprisingly hard to cut off the plastic/rubber with a broken elbow and bruised wrists, but I managed...

Yep, there are no active components, this is, indeed, just GND, 5V, D- and D+ connected. Indeed the other side is not much more and seems to be one resistor fitted. It may be there were 2 and I killed it with a pen knife - that would be consistent with CC1/CC2 connections to tell a device this is a dumb USB-A passthrough.

So this is what I wanted, a simple GND/5V pass through.

But in what way could this remotely be an improvement from the 2018 1A design or 2020 2A design? I mean how is this remotely as depicted. How is this remotely legal advertising?

Update: They are offering me a full refund, if I ask for it - wanna bet it will be in exchange for cancelling review? TBH not bothered about a refund.

TX1812Z5 and WS2812B

I have used the classic WS2812B LED strips, they are very common, and AdaFruit do a lot.

They have a serial data line, in and out, on each RGB LED, and GND and 5V, making them ideal to make an LED strip will all programmable LEDs.

They work by sending a serial stream of short+long or long+short bits, 24 bits per LED, so the first LED "eats" the first 24 bits and then passes on the rest. A gap then means all done and they can all load the LED pattern. The data is around 1.25uS per bit, so even with hundreds of LEDs, this is really fast to update.

There are standard drivers, including for ESP IDF on the ESP32s I use.

But, try as I might, I could not find any of these common 5mm x 5mm "neopixel" RGB LED modules on LCSC/JLCPCB for an LED ring project. They had them on LSCS, and in stock, but would not pick up on a BOM on JLCPCB, or even allow a parts buy from LCSC, crazy!

What they did have is a much smaller, 2.1mm x 2.1mm, TX1812Z5 based, modules. And a Chinese data sheet!

So, tentatively, I designed boards using these and ordered. They are smaller, which is nice. The design was fun, C code to make circular tracks...

I was lucky - JLC queried the pin 1, as I did not (originally) have any pin 1 mark on silk screen, and only then did I realise the pin numbering for the 4 pins was different to the common 5x5 LED modules. So I was able to cancel the order at that point. Had that not happened I would have a number of duff boards!

Having got the pin out right, I ordered again. Then I had a slight panic. The LEDs are run on 5V, and hence a USB lead feeding the inner ring as 5V there. For 24 LEDs in the ring a USB-C will be fine. But, I spotted in the Chinese data sheet that min VIH is 0.7VDD which would be 3.5V, and I am driving from 3.3V data line as that works with a normal neopixel module. It was too late to cancel. But to be fair, WS2812B says 0.7VDD as well, and I know that works with 3.3V.

I also spotted that the timing was 295ns and 595ns not the timing for WS2812B which is 400ns+850ns or 800ns+450ns. Thankfully this would be easy enough to fix in software.

To my surprise, it just worked. The only issue was my PCB sandwich design is a bugger to solder the boards together. Timing and voltage do not seem to be an issue!

The project is a PCB sandwich, with top being a coaster for an (empty) fancy bottle on each table at a wedding. It is going to be awesome.

Customs

I have been ordering a few PCBs from China lately.

Choice of shipper...

The first thing is that JLCPCB offer a choice of shipper, and some options. The main one is pre-paid duty/taxes, or paid on receipt.

The pre-paid seems like an obvious choice, but there is a catch. The pre-paid adds more than just the UK VAT 20%, more like 25%, and, importantly, does not give a VAT INVOICE, so we cannot reclaim it. So pre-paid is basically 25% more expensive!

So post paid. And that works.

Importing and VAT

Things clearly have changed a bit, and it depends on all sorts of things, but most of my deliveries have simply "arrived" and that is it.

This is good! This is almost scary - no VAT to pay or claim. It is right, financially, as a business, any VAT we pay on import we would reclaim, just like buying anything else with VAT for the business use.

Reading more on this, it seems some couriers are sensible working with HMRC, and we gave JLCPCB a VAT number, and magically that all works out. Essentially it cancels out.

But there seem to be thresholds and things, and on at least on occasion I had a demand for VAT from courier. They sent that before it even got to customs and I paid, and no delay, which is good. The nice thing is I got a proper VAT invoice, and so could reclaim it. The annoying thing is the £5 admin fee they charge.

But mostly stuff arrives and no VAT. Yay!

Duty

But it seems there is also the possibility of "duty" on an import, and I don't think I can reclaim that.

This depends on product you have shipped, and I have learned my mistake here.

Mostly these PCBs are very much "development" boards. They are general purpose boards with a processor. But I made the mistake of marking one as "heating" because it would, but default, be used to control an air-con unit.

It seems that attracts a duty of 2% somehow. And the bill came later, long after delivery, with the extra £5 charge.

So did I categorise it wrongly? I think so - all of these boards are general purpose dev boards which seems to have no duty. I don't make it a "heating" board until it gets here and I load code. So I won't make that mistake again.

Admin fees

My big gripes is admin fees, even if £5, from couriers. They are paid to get the parcel to me and that involves a lot of costs and admin, all of which are very predictable.

But if there is duty or VAT they need the recipient to pay that - which is fine, and I can do that.

But they charge a £5, or similar, fee for handling that. They really don't need to, it is all automated, or could be, and HMRC Direct Debit them at the end of the month. The only admin/cost they have is if someone queries, and really, the query, in my case, is because of the admin fee itself, so shooting themselves in the foot here.

The problem is that I don't think the admin fee is a legally enforceable charge. They usually get away with it because they will not deliver until you pay, but sometimes they do, and chase you later.

What is the legality of this?

Firstly I am not a lawyer, but my feeling is that if this was a simple legal and legitimate charge the conversations with the likes of DHL would be a lot simpler. They are not. They were not with FedEx either.

For a start: Royal Mail have legislation to allow them to charge an admin fee. That alone tells me that there is no a legal basis for non Royal Mail - else they would not need a special law to make it legal.

I queried with DHL.

You agreed the charges.

The first argument was I agreed the charges, and the reason is that terms DHL have with the seller include a clause that: "When ordering DHL's services you, as "Shipper", are agreeing, on your behalf and on behalf of the consignee of the Shipment ("Consignee") and anyone else with an interest in the Shipment that these Terms and Conditions shall apply." And further in 'Section 5: Shipment Charges, Duties and Fees.'"

This is a hell of a stretch - why would any shipper agree to that, as they don't have authority to act as an agent for their customer to agree a contract with DHL on their behalf. I mean they could try that in their terms (and I don't believe they do), but no way that will work with most customers. Agreeing a contract as an agent is huge!. It could mean agreeing anything. I mean what if DHL's admin fee was £1,000,000? Agreed on behalf of the recipient? No customer will hand the seller authority to bind them to some unseen contract terms. And worse, the "anyone else with an interest in the Shipment" as that is not even their customer. No way that gets close to legal, in my view. And if the customer as a "consumer" that falls foul of a lot of consumer protection laws.

I pushed this, and pushed this, and stated I did not believe I had given the seller any authority to act as my agent to agree a contract with DHL.

Finally I get: "I am not advising that you have entered a contract with DHL." - yay! Huge win there.

The fee is for HMRC?

I then ask, if not contractual, what the legal bases is, and eventually get the rather oddly worded: "The legal basis is that the charges is supplied from HMRC."

Well the "duty" is, and I paid that (it was £5.09). But the extra charge is clearly not for HMRC, it is "DHL's deferment fee".

They also suggested the £5.09 was VAT not Duty, but have not issued new paperwork to say that (2% VAT?).

So this is the second lie they have told (in my opinion) to try and get me to pay.

Blackmail

The last resort is: "If you do not wish to pay this invoice, we are to call our customer service team and advise that the goods are to be returned to China accordingly."

This is the blackmail - pay our fee, even though no legal basis for it, or we will not deliver.

The only snag is I got the goods over a week ago.

Scam?

To be honest this is, in my view, a scam. I cannot explain it any other way.

Handling the VAT/Duty is not expensive, it is simple, and something I am sure they automate. It is just one of the many admin and costs they have getting a parcel from China to UK, something the sender paid them to do.

Picking on this one thing to charge the recipient is silly. It is no different to deciding to charge the recipient for the diesel for the van to get to recipient as some sort of surcharge. It should be part of the costs of getting the parcel here, as paid by the sender.

The only reason they do this is (a) they are charging the VAT/Duty anyway so can tack this on with no effort, and (b) they can usually blackmail you that you won't get your parcel until you pay.

This is no different to a "speculative invoice scam" where someone sends a company an invoice for something that has no legal basis in the hope the accounts department will pay it. Seriously, it is invoicing for a charge that has no legal basis, not contract, just "because you can".

VAT

One possible option is to get an HMRC deferment account myself, and advise DHL, and other couriers, to use that.

I am tempted, as simpler, but it seems VAT is done specially now anyway, which is why most of my parcels have no issue. And if I ensure all my PCBs are "development" (which they are until I zap them otherwise) I probably avoid duty anyway. That said there is this magic £135 level that matters somehow, so maybe it is worth it anyway.

We'll see how it goes.

Result?

They stopped replying, and the last thing they threatened was returning the parcel to China.

Now they have sent a credit note for the £5 *AND* the duty charge. Even though I paid the duty.

It would make sense if they had returned the parcel to China, I guess.

I guess I take this as a win!

FedEx

It gets crazier - I have two FedEx from same sender. The sender automate everything so labels will have VAT number I am sure. I'll know if/when it finally arrives.

Yesterday, FedEx, just arrived, no problem. No VAT bill. Just worked. Yay!

Today, FedEx advise VAT due for next package (plus admin fee).

This is silly as both DHL and FedEx say they do "Postponed VAT" (PVA) by default, so both should do this for VAT, even if not Duty. This was just VAT.

I have paid FedEx under duress, as they will not deliver until paid, and I got a "receipt" just for payment, but no paperwork to say VAT paid! So I asked for...

1. A proper VAT receipt so I can reclaim.
2. An explanation of why PVA (and hence no fee) done.
3. An explanation of why the admin fee is valid legally, and refund if not.

Notably, I have said if they consider the fee viable under some sort of contract, which I dispute we have, but if they do, then I consider them in breach of said contract as they state on their web site they will do PVA by default. Their failure to do that has caused me admin to pay them and account on my VAT return, so not only do I want their admin fee back for the breach, I want them to pay me for my extra admin. We'll see what they say.

Update: Finally get a paper invoice, nice, except it does not say paid, and looks like they want paying (again). But also includes the original "commercial invoice" from JLC which *does* correctly show our VAT number, so PVA should have been applied.