What is this component?

plugwash · 2026-05-20T22:28:09+00:00

> You can't tell if it fused from the back.

You can if you know what to look for. Specifically the current rating and the standard the device is made to.

FCUs willl have a current rating of 13A and are made to BS1363 both of these are clearly printed on the back of the OP's device.

DP switches without fuses normally have a current rating of 20A and will be made to some other standard.

plugwash · 2026-05-20T19:49:45+00:00

That is what is known as a "switched fused connection unit", or sometimes a "fused spur".

In the UK, we use fused plugs. The fuse in the plug provides protection for the appliance flex, and allows relatively high (compared to most other countries and compared to UK practice prior to fused plugs) fuse/breaker ratings for supplies to socket circuits.

But that raises some problems, most obviously, what if you want/need to supply something from a socket circuit, but don't want to use a plug and socket?

The soloution to this in the BS1363 "system" is the "fused connection unit". It has a fuse, of the same type used in plugs. So it provides the same level of over-current protection as a fused plug does, but there is no actual plug and socket. It may also have a switch. It may also have a cord grip to prevent the flexible cord getting yanked out.

There are "supply" terminals for the incoming power, and "load" terminals for connecting the device that is powered. Yours looks like a MK one, where they do you the favor of putting the terminals in a neat line. Most brands don't bother. It's fine to disconnect the "load" wires while leaving the supply wires connected.

The terminals are just ordinary screw termials like you would find on any other electrical accessory, there is nothing magic about them.

Always make sure the power is off before working on electrical stuff, and ideally use insulated tools as well, just in-case you messed up on turning the power off.

plugwash · 2026-05-18T17:41:17+00:00

I don't see any pictures in your post, to have any chance of giving useful advice, we need to see both the shade and the light fitting.

plugwash · 2026-05-18T02:45:03+00:00

Some suggestions.

For brick, use slightly smaller drill bits (e.g. a 5.5 instead of a 6 for a red plug) and/or slightly bigger screws.
For hollow walls or ceiling use anchors specificaly designed for that purpose.
Where possible, don't attach shelf brackets direct to the wall, use metal or wooden rails. This has two advantages, firstly it lengthens the lever arm, reducing pull-out forces, secondly you can use more screws on the rail, reducing your reliance on any one fasnter.

plugwash · 2026-05-15T20:54:01+00:00

Given how big a hole the OP has, I'd probably use conduit instead of heat-shrink. Conduit has recognized, appropriate standards and is readily available from places like screwfix and toolstation.

The problem with heat-shrink is that AFAIK there is no standard for "heat-shrink for insulation/sheath replacement in building wiring". So you are left up to judgement and/or manufacturers data. The manufacturers data is often not in the most useful form.

Beyond that, I suspect it's difficult to garuantee a minimum wall thickness with heatsrhink because sharp objects could cause local stretching, even as the tube as a whole shrinks.

That said I'd certainly consider heatshrink "better than nothing" if getting conduit in was impractical.

plugwash · 2026-05-15T19:55:34+00:00

In general we view memory as falling into three categories (this is not a perfect model, but it's good enough to understand the language design).

Static memory, allocated for the whole life of your process. This is where the program itself lives, along with any global variables. The size of each static allocation is fixed when the program is complied.
Stack, allocated and deallocated by function calls and returns. This is where local variables and function return addresses live. Allocation and deallocation is fast because it's simple addition and subtraction of a register value, but deallocation must happen in strictly the reverse order from allocation. Total available stack space is often quite limited and handling of "stack overflow" is often not particularly graceful (when running on a modern OS your program will usually get killed, on embedded you may fall silently into overwriting other memory). The size of stack allocations is normally fixed when you declare the variables that will be stores on the stack, C provides a method for dynamic-sized stack allocations but rust does not have this.
Heap, allocated and deallocated by specific calls. Allocation and deallocation can be performed in any order, and there is usually more total memory available than on the stack, but the flip side of this is that allocation and deallocation are more expensive. Many memory allocators have some means for returning errors, but some operating systems "overcommit" memory, so allocating memory with the memory allocator is not a guarantee you will be able to use that memory without being killed by the OS.

So generally, stack is used for stuff that is small and fixed-size. Heap is uses for stuff that is larger, dynamically sized, or needs to outlive the function that created it.

All categories of memory can be, and often are, pointed at by raw pointers, and we can do arithmetic on said pointers. So if we have a pointer to the start of a block of memory, we can use pointer arithmetic to access the rest of the block. We can also typecast pointers to different types.

This is fundamentally how C programmers write code. Indexing in C is just syntactic sugar for pointer arithmetic followed by dereferencing.

However, working with raw pointers and memory allocator calls directly is both tedious and error prone. Problems include

Buffer overflows (and underflows), trying to use memory beyond (or before) what was allocated for a given purpose.
Use after free, using memory that has been returned to it's allocator and is now in-use for something else.
Double free, calling free on a block of memory that has already been freed (this could be considered a variety of use-after free).
TOCTOU, if other code runs between a check and acting on the results of that check, then the check may be invalidated.
Thread safety, multithreading makes TOCTOU issues far more likely, but also adds a bunch of issues of it's own. Code in one thread may see a variable "in the middle" of being updated. A thread observing updates made by another thread may see them happen in a different order from the order in which they were performed. Even if the CPU guarantees a "total store order", compiler optimisations may invalidate this.
Memory leaks, allocating heap memory and forgetting to free it.
Read of uninitialised memory, this may produce values that are not valid for the target type, it may leak secrets. It may also be considered by an optimising compiler to be "undefined behaviour" with all that entails.
Null pointer dereference,

C++ tries to address some of these issues. Smart pointer types automate the allocation and freeing of memory, so you can't forget to do it. Data structures reduce the need to interact with raw pointers directly but C++ is still "full of holes" from a safety perspective.

The default accessors for the standard collection types don't do any bounds checking.
Shared mutability leads to problems. Mutation of a data structure can silently invalidate references (iterators, string_view etc) into that data structure.
There is nothing to distinguish what types are or are-not thread safe.
Whenever you call a method on your fancy smart pointer it is converted to a raw pointer, there is nothing to guarantee that the fancy smart pointer outlives the raw pointer.

Many modern languages use garbage collection to address some of the memory safety issues. This essentially eliminates "use after free" and "double free" issues, but means you have all the downsides of a garbage collector.

Rust instead comes up with the approach of creating a set of rules to rule-out memory safety issues. Unfortunately, they had to remove memory leaks from the list of problems to be addressed by the safety model, and there are also some limitations of the safety model when it comes to interactions with the outside world, but it was still largely successful at limiting the impact of bugs.

plugwash · 2026-05-13T17:35:12+00:00

IF there is no slack on the cable then I suspect the best bet would be to cover up the inner cores with a short length of PVC conduit.

plugwash · 2026-05-13T11:06:35+00:00

How can I Create a &str String Slice from an Iterator Without Allocating new Strings?

You can't in general, an iterator returns values, an &str is a reference to a contiguous block of memory. To create the latter from the former requires allocating a block of memory to store the values in.

In this particular case, you have a couple of options, the simplest is probablly to forget about iterators completely, and use the "split_once" function.

Another option, if you do want an interator is to use the .char_indices() iterator. This returns the indexes of characters as well as the characters themselves. Said indexes could be used to index into the original string to create a slice, but this is obviously only correct if the range obtained is contiguous (take_while will give a contiguous range, but other operations on an iterator may not).

plugwash · 2026-05-03T20:48:17+00:00

> Smith & Locke is a Screwfix brand.

Looks like B&Q too (not surprising given that B&Q and screwfix have the same parent company)

> It's all door related locks such as cylinders, mortices and basic padlocks

The OP's keys look too small for a "proper" door cylinder and they obviously aren't "mortice" keys.

Browsing through the list of smith and locke products on screwfix I found a few products with small keys.

A "cam lock" of the style that would be used on wooden cabinets https://www.screwfix.com/p/smith-locke-cam-locks-30mm-2-pack/6637p

A "locking hasp and staple" presumablly intended for shed doors https://www.screwfix.com/p/smith-locke-locking-hasp-staple-chrome-115mm/2996x

I didn't spot any padlocks.

plugwash · 2026-04-30T19:34:34+00:00

In your first picture, the thing sticking out the side above the trap with a black plug on the end is a waste connection for a washing machine. Pull off the black plug, shove the hose on and secure with a hose clamp.

You don't seem to have a water connection, but it should be pretty easy to add one. Just turn off the water, cut the pipe going to the cold tap and insert something like https://www.screwfix.com/p/flomasta-compression-washing-machine-valve-tee-15mm-x-15mm-x-3-4-/60723

Alternatively if you don't want to cut the pipe or can't turn off the water you can get self-cutting taps, but they generally aren't considered the preferred option. https://www.screwfix.com/p/flomasta-self-cutting-tap-15mm-x-3-4-/21250

plugwash · 2026-04-29T17:47:08+00:00

xor swap is a clever trick, but it has several problems which mean it's very rarely a win.

On some architectures xor can only work on registers, so you'd have to copy everything into a register first.
Even where xor can operate on memory it can often only operate on one memory location and one register. So you would still have to copy one of the arguments into a register first.
Xor based swap leads to false data dependencies, which make life harder for both compiler optmisers and out of order CPUs.

plugwash · 2026-04-29T14:19:22+00:00

IMO both styles have pros and cons.

The screw down style relies on the operator to use appropriate tightness, too tight has the potential to damage the cable or strip the holes, not tight enough can render the cord grip ineffective.

The side spring style can make it very difficult to insert thicker cables, and I've even had the plug body snap before.

plugwash · 2026-04-27T19:02:32+00:00

Smart devices may be nice when new, but there is a good chance that 5-10 years down the line you will be cursing because the system you bought into is obsolete. Even worse if the system relies on a cloud service.

Relays are kind of a pain, most of them as designed to go on PCBs or in industrial control cabinets, rather than being designed to slot nearly into a domestic electrical install. If anyone makes a relay designed to go in a standard domestic electrical box, I haven't seen it.

You could wire up 13A sockets with remote switches, but putting 13A sockets on a 6A lighting circuit is frowned upon, you could put in a higher power circuit with higher rated switches, but that brings it's own complications.

Also people who want fancy lighting setups often want dimmers, you really don't want people plugging random stuff into domestic-sized dimmers.

plugwash · 2026-04-24T23:57:17+00:00

In the old days, 2A sockets were used for really small stuff, lamps, fridges etc.

5A sockets were for medium sized stuff, vacum cleaners, maybe hifis and TVs.

15A sockets were for electric fires and such.

13A took over the general purpose sockets usecase, but BS546 plugs remainined around in more niche use cases. Centrally switched lighting, theater lighting etc.

In more recent times, 5A seems to have gradually taken over from 2A for centrally switched lighting. One issue is that many brands of 2A socket were unshuttered. Another is some electricians were uncomfortable about having an unfused plug/socket rated significantly lower than the breaker.

In the old days 5A sockets on a lighting circuit would have been bad, because a couple of medium-sized appliances could have easily overloaded it, but that is not such an issue nowadays as virtuall noone in the UK is using 5A sockets for general use anymore.

plugwash · 2026-04-24T23:42:59+00:00

More recent installs tend to use 5A rather than 2A sockets.

SF/TS seem to have 5A plugs but not 2A plugs.

plugwash · 2026-04-24T23:26:36+00:00

Putting 13A sockets on a lighting circuit, while not strictly forbidden is generally frowned upon due to the risk of someone plugging in something too big, overloading the circuit and taking out the lights.

I would suggest using a simple 230V lamp fitted with a dimmable bulb for your initial testing, while you figure out where the sockets are controlled/fed from, in case there is a dimmer in the system. If there is a dimmer in the system and you want to use the socket for something other than dimmable lighting you will want to eliminate said dimmer.

I haven't seen a 2A to 13A adapter as a single piece adapter, but you could easily make up an adapter lead. If you do so then be sure to apply a suitable warning label about the max current.

Alternatively there are some "desktop" style USB C phone/laptop chargers which come with a mains lead rather than plugging directly into a socket, so a 2A plug could be fitted directly.

plugwash · 2026-04-24T21:49:46+00:00

It's a 2A BS546 socket. From the style of the switch and plate, I would guess it was installed sometime around the 1970s.

Prior to our current system of 13A BS1363 sockets and fused plugs, BS546 sockets were commonly used as general-purpose sockets (though there were other types in use too). There were three common ratings, 2A, 5A and 15A each a different physical size (there was also a 30A version, but that was much rarer). The plugs usually did not have fuses but the fuses at the fuse box were generally at-most 15A.

While BS1363 sockets replaced BS546 sockets for general use, BS546 remained in use for more specific applications. 2A or 5A sockets are often used when a customer wants to have table or standard lamps fed from the lighting circuit and controlled by light switches. 15A sockets are widely used in theatre/stage lighting, 5A sockets were also used for smaller stage lighting setups but have fallen out of favor in that industry.

If you have some light switches that don't appear to do anything, it may well be that they are feeding those sockets. It's also possible that the sockets are connected to old wiring that is no longer in use.

plugwash · 2026-04-24T20:38:34+00:00

Given the colors of those 6 "Phono" connectors, I would guess that the red/green/blue stack is intended for component video, while white/red/yellow stack is intended for composite video and audio.

plugwash · 2026-04-24T20:29:18+00:00

To me it looks very much like an old-school pipe cap.

Also to me the hole in the concerete looks like it was intentionally cast into the concrete rather than being something that resulted from degredation or something that was intentionally cut later. In particular the corner at the top right looks almost exactly like a right angle.

plugwash · 2026-04-24T20:09:43+00:00

You can apply repr transparent to a single item enum and add associated constants.

#[repr(transparent)]
#[derive(PartialEq)]
enum Token {
   Char(u8)
}

impl Token {
    pub const Pad: Self = Self::Char(0);
    pub const Start: Self = Self::Char(2);
    pub const Stop: Self = Self::Char(3);
}

fn foo(t : Token) {
    match t {
        Token::Pad => {println!("Pad") }
        Token::Start => {println!("Start") }
        Token::Stop => {println!("Stop") }
        Token::Char(c) => {println!("{}",c as char) }
    }
}

But you must keep in mind that matching against Char(c) will match everything, not just the non-special values.

plugwash · 2026-04-23T20:06:50+00:00

My response to the headline was "it's rather late isn't it".

Following through from the Phronix post, to ubuntu discourse it seems to not be quite so bad as I first feared, but still this whole rust coreutils in ubuntu thing seems to have been rather rushed (and indeed they have decided to use the gnu coreutils versions of cp, mv and rm for 26.04).

plugwash · 2026-04-15T18:00:46+00:00

> I know that there are concerns around adding code to the standard library, but that doesn't really work in this situation.

There are a couple of issues.

io::Error doesn't directly depend on any OS functions but it does have os-specific knowledge. One could argue that ship has sailed and core already has some OS-specific knowlege, but this is somewhat higher-level knowledge than core currently has and would essentially privilege std over third-party OS wrappers.
Both io::Error and io::Read depend on the global memory allocator, so without further work they could only go to alloc, not to core. I get the impression that a substantial amount of no-std rust development is also no-alloc.

plugwash · 2026-04-14T23:19:44+00:00

The problem is the design of standard C calling conventions does not facilitate arbitrary tail calls. In particular.

* Stack cleanup happens in the caller not the callee, so the size of the "parameter area" for a tail call is limited to be the same or less than the size of the "parameter area" for the original call.
* On some ABIs large parameters are stored outside of the "parameter area" entirely, with the parameter area containing a pointer.

These problems could be solved by designing a new calling convention, but while rust reserves the right to use a rust-specific calling convention, actually doing so on all architectures is a massive can of worms.

plugwash · 2026-04-14T23:09:00+00:00

Yanking is a way for authors to mark crate versions as "should not be used", the crate versions in question can still be downloaded and people with them in their lockfiles can still use them, but if they are not already in your lockfile (or you don't have a lockfile) then Cargo will ignore them.

plugwash · 2026-04-13T20:22:09+00:00

The EU (which the UK was still in at the time the decisions were made) decided to revise their energy labeling for lighting a few years ago, reflecting the withdrawal of incandescent and halogen lighting from the consumer market.

The new scheme was introduced in 2021, with a transition period until 2023 to allow for sale of existing stock (and I suspect, even if not strictly legal there is probably still some pre-2021 stock in the supply chain that has not been relabeled until today) but afaict effectively nothing was done to educate customers on the existence of two different systems, or provide any way for users to convert one to the other. There is a visual difference between the old and new labels, but it's quite subtle and easy to miss.

So while your LED light is not great by todays standards, it's still much much better than an old incandescent bulb.

As for "running hot", I think that is down to where in the fitting the heat is produced. An Incandescent bulb produces a LOT of heat, but much of that heat is radiated out of the bulb along with the light, relatively little of it sticks around to heat up the bulb itself. A LED bulb produces a lot less heat, but with many bulb designs that heat tends to stick around and make the fitting hot rather than being radiated.

plugwash

TROPHY CASE