The round one

As previously blogged, I created an NFC RFID reader based on the PN532 NFC chip.

It works well, and includes red/amber/green LEDs and tamper switch and even contacts for a "door bell". This makes it ideal for access control.

But I decided some cases may look better with a round modules. So I wrote code to measure track lengths in KiCad PCB files, and then code to make a spiral track, which I made the same length, and then made a round version of the same thing.

It works. It worked first time. Indeed, the solder paste and cook worked first time - no re-work - no glitches - just worked. I am really pleased.

One of the small tweaks was around the reverse mount LEDs which used to tombstone in the oven - that is all fixed nicely now.

Other changes are that the connectors are all SMD now to make the other side "clean".

Which leaves me wondering if I should add a logo or something on that side. I am really not sure. I also think purple solder resist may be nicer. The main thing is I want a distinctive appearance / brand that can compete with elechouse on Amazon. Suggestions welcome.

Of course, what is super frustrating is that these are all prototypes - I cannot really make commercially until the global component shortages are sorted and I can actually order 100 of the PN532 or indeed anything else! Once sorted, I plan to put these on Amazon.

ICO and NHS

I have a short email address. Those that know, know, so not posting here.

Suffice to say it is of the form x@x.xx so is only 6 characters. It is 100% valid. I have used it for a couple of decades now - this is not new. I am not alone. [side note, I tried to sort x@xx email, which is not easy, and did not get off the ground, but some people have done this, and it is valid]

I registered to get access to on-line COVID passes with the NHS or is it NHS Digital, or what? To be honest it is not 100% clear. Privacy policies and the like should make this clear, but even now I am not sure. My MP believes it is Welsh government. The fact I am not 100% sure is part of the problem.

[update: https://access.login.nhs.uk/privacy says it is joint data controllers of the devolved (Welsh) administration and NHS Digital]

They would not allow me to register, so I created a temporary address (longer) and registered. Simple. I even have the whole domain rfc2822.uk for this purpose.

I then tried to change the email address to my normal x@x.xx email address, and their system would not accept it.

NHS expecting me to change my personal data to fit them

So I emailed their data controller requiring them, under my right of rectification under (UK) GDPR to correct my email address. They refused. Note the original (temporary) email is no longer valid, and hence meets the definition of not "accurate" personal information. Indeed, I do not even have the domain any more.

I wrote to ICO, and have exchanged several emails to ICO, and escalated and asked for review of the case.

Basically the ICO said: There is nothing in data protection legislation that prevents an organisation from having a system that has a minimum requirement for an email address.

This seems odd, as how can an organisation accurately record personal information if they do not accept a valid email address, i.e. they have a "minimum requirement" for what is "valid"?

This has gone on for some time, and I am not alone, there are others I know with similarly short email addresses that have issues with NHS (and other organisations). There are others I know with related issues on incorrect data validation at "sign up".

Just to be 100% clear, the NHS fully accept my email address is a valid email address, and have emailed me, to that email address, to say so, as have ICO.

I also asked ICO more generic questions about whether an email address is personal information, and if I can expect (require) an organisation to correct it when it is wrong. They confirmed that is the case, so I again wrote to NHS quoting them - no reply. What a surprise.

I have written to my MP as well, and asked them to chase, and they have written to NHS (Welsh Government).

Latest from ICO is "For clarification, as the NHS has not recorded your email address then we are unable to suggest that they are recording inaccurate information. 'Inaccurate' would apply to information that was recorded incorrectly. There is no suggestion that they have done this."

Seriously, I'm shocked. This has, all along, been about the NHS refusing to correct my email address. So I have explained, again, to the ICO, that the NHS have recorded my wrong email address and are refusing to enact my request under my right to rectification to correct it under UK GDPR.

We will see how it goes, but this is a matter that relates not just to email, but other things.

• Organisations will insist someone has to meet some format for a name - a forename and surname (not all have this), a name with more than one letter (not all have this), etc.
• Organisations will insist a UK mobile phone number has to start 07, and organisations will even blacklist some operators 07 mobile numbers as not valid mobile numbers!
• Organisations routinely try to impose rules on email addresses.
• I really expect organisations to have shit when it comes to recording gender, which is rather topical.

The law does not stop companies from having rules to take their service as long as not discriminating based on some protected criteria. They can refuse me because my email address is too short. IMHO this is wrong.

But once they have accepted a customer/client, perhaps with wrong, or temporary personal details, they do have to comply with GDPR and have to correct incorrect personal information. So it would be better if they accept the correct personal information in the first place. In seems to me that GDPR (or UK GDPR) has a flaw in not covering this properly for "sign up". People should not be able to use email address, mobile number, name, or gender, as a reason to refuse to accept a customer/client.

This is even more so when it is not some company, but an organisation like the NHS. I have an NHS presence, I have to, as a UK citizen, and they have data on me right now that is not "accurate". That needs fixing.

Update: 1st Jul: The ICO now seem to be suggesting that because the email address they recorded at the time was correct (accurate) that they do not have to correct it now that it has become inaccurate. This would suggest organisations do not have to update name, address, phone number, email address, well, any personal information they hold when it becomes inaccurate over time. That seems a stretch!

Update: Someone has suggested this is "the same on all GDS platforms", and that it is not fair for me to "bother" the NHS. I appreciate the NHS have a hard time, but if this is the case the all the NHS have to do is contact whoever maintains their platform for them, explain they have a legal requirement to correctly record personal data, so have 30 days to "fix" this, and the NHS will have done what they need. Instead the NHS have so far chosen to spend time arguing with me, and then updating their site to state that an email address has to be at least 7 characters (previously it accepted it but did not send the confirmation email so it did not work). At the end of the day, someone, somewhere, on some platform, just has to change a 7 to a 6 in some code (or better still, follow the RFC for validating email, which will be a simple regex or library). It is not a hard fix for whoever does it - if the layers of people above that, all the way to the NHS, simply tell them to do it.

Euro profile locks - a few tips

Test door, lock sticks out a bit!

Euro profile locks are a doddle to change - it is literally one screw, and you can slide out the old lock and slide in the new locks. They are easy to buy, or order on-line. But a few quick tips:

• You need to order the right size (inside and outside). This is the distance from the centre of the lock to the key slot each side. Usually available in 5mm steps. You want it just right, not sticking out, though good locks have a snap off part if someone does take pliers to it.
• You can order keyed alike locks so they all have the same key, which can be very handy. Somehow people don't realise this!
• There are loads of different quality and prices of locks.
• You can have key both sides, or one side with a thumb turn, or just keyed one side and blank the other side even (half lock).

So, when we moved in, the first thing I did on day 1 was order new locks. Five of them. The house had all been recently re-done and the locks in the house already were all brand new, so a bit of a shame. But I wanted higher quality locks and did not want five different sets of keys (don't people know you can get locks that have the same key?).

Cheaper lock

I ordered like for like, the same size, and keyed both sides as that was what was in the house.

Unfortunately, after a little while we realised the choice of locks was wrong. You do not want keyed both sides. The reason is that the doors were all multipoint locks, and only locked by turning the key. Without that someone can literally walk in from the street (which has happened!). But this means you can only use the door from the inside if you have a key to unlock it. This means if there was a fire in the night when the doors are (obviously) locked, you need a key to get out. Remember the house originally had 5 sets of keys so you need to find the right key for the door by which you are trying to escape from a fire.

The short term fix, a key on a hook by the door, but that is far from ideal. Obviously.

Thumb turn on inside

So I ordered another complete set of locks (getting expensive now) with thumb turn on the inside. This means you can always lock or unlock the door easily from the inside without a key. Importantly it is not hard to unlock if trying to escape a fire. I actually disposed of the first set of locks as no use to me any more.

As some of you know, I have a complete door access control system and alarm system, but changing locks means a locksmith and time and money, so even though we have been here over a year I had not yet changed the locks. I was also researching the right lock for the job. Being a house, I really don't want an "exit button" and an "emergency break glass" by every door. I also wanted a "fail secure" so a power cut when we are away (long enough for battery to drain) does not leave all the doors unlocked. But I also want it "safe" so always possible to get out in a fire even when nothing is working electrically.

So the locks are Abloy EL560. I have been testing on my office/study door, meaning we now have six locks. This is great, it is fail secure (i.e. power fail is locked). But it can always be opened from the inside with the handle, and with a key. It also has signals so you know if opened by handle or key. This is great.

RFID reader

They are being installed in the rest of the house shortly, with my AES DESFire based readers to open from outside - nice and secure, and all links in to the alarm system.

However, if it was to be opened from outside using a key, I would want the alarm to know this, and disarm. The idea is we can trust a key. That is fine, I simply configure the system to disarm when the key is used. The system is very flexible and easy to configure for various types of lock.

Except... I have thumb turns on the locks on the inside. I don't need these now as you can open the door with the inside handle. But if I set the system to trust a key it trusts the thumb turn as well. Someone breaking in only has to turn the thumb turn on any door to disarm the alarm. So yes, obviously, it is not being configured to do that (yet). Indeed, one approach would be you have to enter a PIN on the keypad if not using a DESFire fob, even if you did use a key. Given how easily keys, even high security keys, can be copied or 3D printed, this may be sensible anyway.

The real answer is order locks keyed both sides, or even no key at all on the inside now.

I had a full set of locks just like that from when we first moved in. I have disposed of them. Arg! So another set of locks, six this time.

The moral is never throw anything away, ever!... I should know this already.

IPv8?

I should write up my concept for IP. This is literally stuff I dream of!

This is totally "if I had a time machine and could fix IP at the start" and very much not a "this is what we should move to". The time taken to get IPv6 deployed (over 50% in US now) shows this would never fly.

So my ideas is this...

IP addresses would have multiple levels, tagged at the binary level in some way to allow each level to be different number of bytes, and allow for multiple levels - perhaps top two bits say length of each level. The exact detail on this is not that important other than the fact it is "variable" in some way and a fixed pattern for any IP address to allow hardware to cope. The displayed format is not that important either, but probably a series of decimal numbers with a separator.

The top level of any target IP would be AS number. This is still routing packet by packet, not session routing. So an ISP level core router needs a simple top level binary decisions, is target outside our AS (so send to target AS) or within (so send to next level at byte X in packet). Yes, a router could have more than one role as more than one AS maybe, but in general it is simple. This is the sort of thing that can work at a hardware level in ASICs without too much issue. A CAM at top level for sending to AS and a CAM for "within my network (AS)" level.

Routers below this level are similar - "is it my network" do routing to "next level", or I send "upstream".

The basic idea is that you have a simple routing decision at any "level" and when it gets to that party, an AS, and end user, etc, they have choice how they want to route and assign addresses.

The concept is that the IP would actually go in levels from AS, to areas within an AS (if needed), to customers, to devices on customer networks, and even include "port" within the device. No need for NAT ever. Ultimately extensible at ISP or customer or network level and even within device to allow more ports (which can be an issue). Some limit on levels, and bits at each level, but more than enough.

Yes, TCP and UDP would change to not have a port where it is now, but part of the IP addressing.

As for allocation and RIRs, the allocation would be AS, and anyone with an AS controls as many IPs within that as they need.

More ports

Also, the session connection to a device would be a protocol in itself, for things like TCP (maybe even UDP and others), where the connection is to the device IP address (not a port level) but the payload includes a text port name. So https would be to port "https" not port 443. The reply would confirm the actual target IP (which includes port ID) to use for that connection. This allows target port to be unique without mapping the source IP/port and target IP/port normally needed to identify TCP socket within a device, even as a server. So simpler code (yes, check the IP/ports are right when you match it).

I also think that, unlike IPv6 which has a separate standard header for encryption (which therefore does not actually work for TLS we have now) I think TLS would be an option in the that SYN, along with port name. So port "http" can request TLS or not as a standard start of that session, with things like "use previous authentication session" as an option at the SYN level for faster connections. Ideally the application calls for TCP would make it very simple for any stream to be TLS or not with minimal coding overhead.

Multihoming at TCP level

Also, you need protocols like TCP to be multi-homed at the TCP level. Mobile phones can already do this to some extent. Connect to a name, not an IP, and it has multiple IPs, but allow the IPs to change during the session if needed, either end, as part of the connection protocol. This avoids the need for multihoming at the BGP level, and IPs can start with AS at a top level regardless.

No, not "IP is the route" - still routing path redundancy

Just to be clear, this is not saying the IP is the route to the end point, either. The route taken would be determined by routing protocols like BGP, and still have the alternative paths and redundancy that exists now to get to an AS, and within an AS. The only really difference is that core routing policy would almost certainly not allow announcements below the AS level, and hence keeping routing tables smaller. At present IPv4 does not work (by policy) smaller than a /24, for the same reasons. This just makes a really simple and obvious policy as the inter-AS level. It also means each AS only needs to originate one prefix (their AS) where as now they originate loads of separate blocks. That one prefix is extensible as much as they like. Indeed, the role of RIRs for IP management would pretty much vanish as having an AS would entitle you to allocate IPs under that AS, and originate routing for those IPs from that AS.

Comments and discussion welcome - but remember this is essentially just a thought exercise.

Alternatives rejected

This idea is still per packet - a totally different approach involves a connection based system. Establish a route over the internet as you connect and each point reports the connection id, and at the start you send to the local connection ID which is mapped to next hop connection ID. It could work but is a massive amount of "state" in the core, and I don't think a viable approach. Sorry.

Un-mapping CGNAT for IPv6, etc, with no overhead?

Some links are IPv4 CGNAT (notably Starlink at the moment).

What if I want IPv6.

Well, a simple approach is something like L2TP. The issue is that this is IPv6 over L2TP over UDP over IPv4 over CGNAT, and that means a much reduced MTU. This is not the end of the world if you know you have the reduced MTU, but a shame.

So would there be a way, even if only for outgoing sessions, to "tunnel" the IPv6 over IPv4 with zero overhead?

I think so. You need something in the Internet with IPv6 and something on the network that is stuck behind the IPv4 CGNAT end point.

The trick is that an IPv4 header is 20 bytes shorter. So if you reduced an IPv6 packet to IPv4 you get 20 bytes spare. You could tack something on to the end of the packet, and it should arrive at the tunnel endpoint via the CGNAT over IPv4.

So why not tack on the original external IPv6 address?

Yes, the source address would have to be tracked using NAT of the IPv6. And indeed, one could say you only need to tack on the original IPv6 at the start of the session as once you have created the NAT session you know both IPs involved.

Only catch is that TCP, for example, does not normally have extra data on SYN packets, so you have to check they arrive intact. One would hope so.

OK scrap that - I have a better idea :-)

You establish a link, maybe simply a TCP session, between your devices, outgoing via the CGNAT IPv4 to the far end. You use this to carry some control data. It could even be TLS with client cert, etc, for security.

Every outgoing session you create you send details over your TCP control link to the far end with details of that session, and it allocates an IPv4 UDP or TCP port for you and advises over the TCP control link. You can then send a new packet of the same type, e.g. TCP/UDP, to the far end. This then maps through to the IPv6 addresses you want to use, and the original ports. The CGNAT is then used to carry each new packet in or out over the session map each end.

What makes this even more clever is that you can do incoming new sessions as well. Obviously the IPv6 block being used has to be routed to the outside device. But simply carry the details of the new incoming connection over the TCP control link, and then have the NAT end start an outgoing session. Once established, that is used to carry the incoming packet and the outgoing reply packets. Yes, it could make for a slight odd TCP handshake, and that may need slight messing, e.g. send the SYN and SYN/ACK over TCP control link, but create an outgoing SYN and SYN/ACK exchange over the CGNAT outgoing, setting up the payload sequence numbers to match what the ongoing packets will be using.

This could allow full IPv6 both ways over an IPv4 only CGNAT, and not only would it have no overhead, allowing full MTU, it would actually use fewer 20 bytes per packet after the first control packets, and so be 1.3% more efficient on the wire. Technically you would lose per packet flow labels, but not a lot else. Of course things other than TCP and UDP would be a challenge, but could simply be mapped to look like UDP on the IPv4 if needed.

Of course the same could be done for IPv4, not saving 20 bytes per packet, but basically un-mapping the CGNAT at each end.

A zero overhead tunnel could save one of the classic IT/networking issues "MTU".

Starlink (2)

As I say, impressed, and to be honest even at £89/month inc VAT this is good value...

A doddle to install properly, some tree cover is unavoidable, but it works, and is happily doing 185Mb/s right now. Thanks to Jim to coming round with his drill for me.

The IPv4 is all CGNAT, and the IPv6 is not working yet or reliably. But this "just works" with A&A L2TP providing fixed IPv4 and IPv6 over it. And the latency makes this a very viable service at around 30ms. The package of a Starlink + FireBrick + A&A L2TP is pretty appealing, to be honest.

I really am pretty gobsmacked with how simple this all was to buy and get working - only caveat is "remember to get the Ethernet adaptor".

Security by annoyance

TOTP (Timed One Time Password) uses a secret which is a block of binary data. It suffers from being symmetric in that the server doing the checks, and the user (usually in an app on their phone) both have to know the same secret.

This presents the problem of getting this secret from one to the other. This story is about that journey.

A friend has a customer that wants to use some specific device they already have to provide OTP codes, and so has to send the secret to him to load on to the server.

Firstly, this is not quite how it is usually done - the usual way is the server makes a (new, random) secret, provides it to the customer (often as a QR code), who confirms receipt by entering the current OTP code. All done over https to be secure. Sorted.

But in this case the customer had the secret and wanted to send it.

As I say, the secret is just a small block of binary data, usually expressed as base32.

They sent, by email, an RFC6030 XML file, signed, with base64 coded encrypted secret in it. They also sent a simple 16 byte binary file which is the key, by email.

• The base64 had to be converted to binary
• The first 16 bytes extracted as IV
• The remaining bytes stored, in binary, as the encrypted data
• The IV had to be converted to hex for openssl command line
• The 16 byte binary key file had to be converted to hex for openssl command line
• openssl command line for AES-CBC was run and produced a binary decoded file
• This had to be converted to base32 and loaded on the system as the secret

Was this secure?

Short answer: no. Both parts sent by email. Sent as separate email as obviously no hacker could possibly intercept both emails!!!

Alternatives?

Almost any secure messaging app, e.g. signal, interactively whilst talking to the contact, sent as base32, and ideally as a disappearing message.

Or email the base32 over PGP encrypted email.

Or, well, almost anything else! Reading the Base32 over the phone FFS (though phone calls are rarely encrypted in transit over the network).

Storing the key?

One thing done on the back end system, apart from encrypted disk, etc, is to store the secret encrypted with the users password and salt. The password is not stored, only an argon2 hash. This means you can validate a password+totp code, but you cannot extract either the password or the TOTP key from a leaked copy of the database. I mean, yes, if someone can get a copy of the system and database, and trojan a user in to entering password, they can decode the TOTP as well, but that requires that extra user interaction step for each compromised user record.

P.S. what is my involvement?

Mostly helping my friend out to understand what he had to do. We are all cautious to ensure security, as you would expect.

Shelly Plus 1 GPIO

I am quite impressed with Shelly stuff anyway, but the new "Plus" range has allowed some interesting developments - as they use ESP32, which is the processor I use for my access and alarm system.

This has meant I am able to add bits to the alarm system much more simply than using my custom boards - anywhere I need just an input and/or just an output, for £15.99 I have a device that does the job. As an output it is a dry contact relay, and can be powered from 12V DC, or 24V-240V DC, or 110V-240V AC, so very flexible. Working with alarm system 12V DC or 24V DC is easy. Only catch is it should be 12V not 13.8V so a regulator may be handle, but it seems to cope without, so far.

The input is run at "live" so for mains working needs a proper switch rated for mains such as a light switch (or one of the nice retractive switches). But working on alarm system 12V, a simple contact like a reed switch, or connection to a PIR is simple.

Obviously there are plenty of uses for the alarm system that needs more than one input or one output, but this is pretty useful. I even have one electrically locked door that is just using one for the lock and door open inputs as it is a door that does not need a fob, just needs to be locked when alarm armed, and detect door open as an alarm input ("access", causing alarm if armed).

My new EL560 locks on the house are great as no need for break glass or exit button as they open with the inside handle. But if you have any doors you keep unlocked during the day, you need a way to lock the doors at night. And that needs a button. Well, a Shelly Plus 1 is ideal. The light shows the doors have been locked.

I have also worked out the GPIO:-

• GPIO0: Output for small LED (hard to see through case).
• GPIO4: Input for SW signal (external switch) but needs configuring as pull down.
• GPIO25: Input for small blue button on the case, but needs configuring as pull up.
• GPIO26: Output to work relay.

There are also 6 external connection pins for programming (WARNING: THESE CAN BE LIVE):

• GND
• GPIO0
• EN
• 3V3
• GPIO3 RX to shelly
• GPIO1 TX from shelly
• GPIO16

These can easily be flashed with tasmota too, use the ESP32 solo build. Note I cover two extra GPIO than the usual tasmota config (GPIO0, GPIO25).

A bit more on air-con

I have been tweaking the air-con even more.

The control I have, basically, is to set the target temperature. I can set higher than now, and lower than now, and so make it turn on or off. But sensibly the air-con has controls. It does not run the compressor exactly to match what I say, it turns on for a minimum time, and there are also sorts of laggy effects for the temperature to react. Once compressor was on it stays cool a while and then fan blows cool for a while.

But it is getting silly.

For the last hour or so, even more so. This is not like ±0.1℃, it is more like ±0.05℃.

It is really good. But I was thinking, is this just that it is a cold day in Wales and the temperature happens to be settling where I want? At 22℃?

Well no, it is not that, looking at the power usage I see that it is turning on and off the compressor to work the temperature.

What I did was make it predict on a trend the next 2 minutes and turn on/off (set high/low target) based on that. And it was surprisingly good. This is the power usage showing it is fine tuning it to manage that. It is controlling the temperature to well within ±0.1℃ with no problem.

Wow.

P.S. Just to clarify (as someone asked), this is not switching between heating and cooling (which would use more power), this is turning cooling on and off. It will switch to heating, but only after quite a while of temperature not coming back within range when off - and that can happen on some days in spring/autumn, but usually only once (each way) in the day. It also does automatic fan control.

Starlink

Finally got one for testing, so first experiences.

1. Ordering was simple, but the site is one of these "slick modern sites" that are a pain to find any proper information - very easy to order - not so easy to realise an Ethernet adapter is separate. I have finally ordered one now.

2. Arrived very quickly (ordered 1st June, arrived 6th June, Jubilee in the middle).

3. Very very confusing re "account". The pages all have "sign in". I cannot find any "create account". What I did not know is that when I ordered by simply clicking "apple pay" and double clicking my phone (yes, very slick), is that this "created" an account using the apple pay email address. Once I worked that out I could use the "locked out" link to get a password. They could make that a lot clearer.

4. The instructions are simple, you plug it in and point at the sky and connect to wifi - it makes you then create an SSID/password, but then it works - Internet, several MB/s of it. NAT / IPv4, but yes, works. I now need to find somewhere vaguely sensible to put it - away from trees - may need a pole on the wall.

Of course the next steps are to get the Ethernet adaptor, and start working with FireBrick, see if I can get an IPv6 address; see if L2TP/IPsec/etc tunnels work over it; etc, etc... So R&D to do.

P.S. LOL, you can get to RT.com via Starlink :-)

New air-con, part 6

Well, well, well... I am impressed with 4 Seasons. They have only gone and sorted it.

This is the huge difference between this install and the previous Mitsubishi install from a different company. The customer service to get to the bottom of the problem and fix things.

Firstly, they did discuss this "anti-freeze" mode with Daikin, and whilst we all agreed that turning the fan down was silly, their point, which is very valid, is that it should not be happening at all. The refrigerant should not be getting so cold in the first place - this is a fault condition. That is what needs fixing.

Naturally I leapt to the conclusion that the issue was air-flow. But I was wrong. It seems the advice from Daikin at this point was right - they said to check the refrigerant. Well, pressures had been checked several times. But they suggested there was too little refrigerant. Indeed they suggested (counter intuitively) that we would see these lower temperatures if there was not enough refrigerant. That seems crazy, obviously.

Well, the installer, and I, were rather baffled, but the only thing that basically makes sense is that the system is (over) compensating for the lack of refrigerant, and that is how it ends up colder. And, of course, at the same time, it is unable to carry the heat away properly, so does not work as well.

The symptoms were pretty simple, when cooling, the refrigerant quickly goes down to as low as -10C, which it manages for a few minutes, and then the anti-freeze mode kicks in, and everything stops for 10 minutes, and overall things are not working well.

Now, the refrigerant is settling around 5C with no problem, and cool air is coming out, and the room is quickly cooling. It is not going negative at all, not even getting below 4C. It varies, and I have seen 5C to 8C, but that is "sane".

So what did we fix?

The fix was to completely drain down the system and refill it - simple as that. The big clue was that only 0.9kg of R32 came out. It should have had around 2.5kg. So he emptied, vac'd, and refilled. What I had not appreciated is that these systems come pre-filled for installation, so it seems that somehow it must have come without the right amount - some must have leaked in transit (not good). But the only real test he can do is pressures, and they were fine, so no clue that there was not the required amount of R32.

I'll add some graphs once we have a couple of days running to confirm. But I am sat here on a warm sunny day in a nice cool office. To say that I am over the moon is putting it mildly.

Side effects

A small side effect is that my Daikin wifi modules have way more monitoring and reporting and graphing now. I did loads of work to try and find what was actually happening, turning in to a seriously useful tool.

Next job is the new controller to work with it for when people want manual control but doing a better job than the normal Daikin controller.

Another small side effect is that my previous very tight temp control is now a little less tight as the effect of cooling (or heating) is much more and continues longer, so some level of predictive processing may be needed to manage tighter temp control. Should be pretty easy.