My journey with WordPress goes way back, in 2006, to be exact. Over the years I’ve been first and foremost a user (running various blogs on WP), but I’ve also developed on the platform and run various plugin businesses too. For a while, I also ran an agency where I advocated hard for the benefits of open-source systems and WordPress specifically. This was at a time when the vast majority of websites were either custom coded or run on proprietary closed-source CMS systems, even before the growth of social media.

Back then WordPress really was the solution to democratizing publishing (its slogan) but over the past circa 20 years of its existence, things have changed a lot.

I’ve already highlighted my concerns with the trajectory it has been taking over the past few years, as well as raising doubts whether the slew of acquisitions are a good thing for the space.

Today I want to bring attention to a particular Trac ticket about a change in the .org codebase that took everyone by surprise.

The most commonly cited superpower of WordPress is its community, but there are serious reasons to think that this community is very fractured.

In my view, WordPress community is very generic and we need to understand what we mean when we speak about that. Here’s my take on what makes up the WP community:

• WordPress leadership
• plugin and theme developers that create free and premium products for WP
• service providers (WP-specific or not) that create solutions using WP as part of their toolset
• millions of end users who have no interest beyond using WP to power their site/s

The unique selling point of WordPress really is its flexibility. That flexibility comes from the fact that thousands of developers have built plugins and themes to cater to every possible need a website builder can have.

WordPress leadership, with founder Matt Mullenweg firmly at the helm and in control of things, likes to preach about community as one whole part, but it has become increasingly obvious that this is a fallacy.

Plugin and theme developers have felt unappreciated for many years, with many incidents over WordPress’ history fueling this feeling.

The removal of plugin growth stats is the latest such incident, and the public outcry from developers and users (and the responses from WordPress leadership) has really illustrated that things are severely broken at the top and we need to find a fix to avoid WordPress going into a long-term death spiral.

Here’s what went down.

On Friday 30th September 2022, the active install growth chart in the plugin repository was officially removed in a commit by Scott Reilly (coffee2code), a Tech Ninja at Audrey HC, LLC – an investment and research company run by Matt Mullenweg – WordPress co-founder and CEO of Automattic.

A very vague reason was given for the change, and in the ensuing hours and days many plugin developers were up in arms, and rightly so. A discussion ensued on WordPress trac, and there has been no resolution yet.

The ticket in question is #6511, go and have a look at the comments there before you come back to read the rest of this post.

I will add my two cents while looking at the bigger picture, because I believe that decisions like this really are very impactful in the long run.

In my humble opinion, failure to address the multitude of questions raised and going directly contrary to the wishes of the much-hailed “WordPress community” would confirm the following:

• WordPress is decentralized only in name; in practice being a centralized entity with power in the hands of a few who can decide whatever they want without having to give any justification for their decisions.
• There is no real incentive to help people build small businesses and earn a living through building plugins within the WordPress ecosystem. It is more desirable for acquisitions to happen more and more in order for the few big companies to obtain tighter and fuller control of the WordPress experience.
• Individual developers and small teams can no longer compete reasonably with the long-time big players and should be preparing for acquisition by said big players, and looking at moving into other systems that have more opportunity and a growing rather than shrinking pie.

It is understandable that there are many interests involved, and as in any other industry, money talks, but I think an honest discussion must be had on the future of WordPress.

Actions like the one raised in this ticket only fuel the idea that the big guys in this space no longer care about the people whose work (whether voluntary contributions to WP core or through running plugin/theme businesses) has enabled WordPress to be in the dominant position it is today.

Hopefully, this Trac ticket will serve as the beginning of a more open WordPress and a confirmation that plugin developers still matter and are very much appreciated in the community. That is truly my hope, as the opposite would paint a very bad future for those building businesses within the WordPress plugin ecosystem.

This is an article that reflects on the high number of acquisitions we’ve seen happen in the past few years (2018-2021) within the WordPress space. There are basically a handful of companies behind all the big acquisitions, so there is no doubt that the product space is becoming more centralized, and these big companies now wield enormous power.

This article is an adaptation from a comment I left on the article on the WP Mayor blog entitled Is There a Future for Small WordPress Businesses?. Check that out as well.

Having moved out of WordPress myself (aside from being a normal user, running my own blogs on it) a few years ago, I can empathize with Pippin’s reasons for selling. It’s never easy to let go of a successful business, even if there is good money to be made in selling it, and I’m really happy for him. I remember when Pippin was just starting out in WordPress, and he’s been a massive positive influence on WordPress over many years, putting a lot of energy into not only building his products but also educating thousands through his articles on development and later his insights on running a WordPress business. He deserved every bit of success while running his businesses and the handsome payout one gets when selling a company of this scale.

I happened to write some of my thoughts on WordPress last year, so check out that article for my opinions, which remain relevant today.

While the streak of acquisitions we’ve been seeing in the WordPress space are to be expected, they are also a sign that the space has changed a lot over the almost two decades since WordPress’ inception. Particularly the last 5-10 years have seen accelerated growth. Leaving aside any emotional reactions one might have, I think it’s important for everyone involved with WordPress to be clear on what WordPress is nowadays and where it stands in the grand scheme of things.

For that, we need to start with an understanding of the web’s history and where WordPress fits in. WordPress caught the wave of the transition between Web 1.0 and Web 2.0.

Web 1.0 refers to the read-only, static, version of the internet, where there were relatively few sources of information and there were high barriers to publishing your own content and obtaining visibility. The web in those days was just an extension of traditional one-way media like TV and radio.

Web 2.0 changed everything, and it became known as the read-write web, meaning that now we could interact with things on the web and more importantly publish our own content. That’s where WordPress and other similar open-source projects came in. WordPress eventually came to dominate the open-source blogging and CMS market.

At that point in time, it was very cool to have your own website or blog, and people were relishing the prospect of being able to share their thoughts online. The revolution was huge, and we saw a big shift in information decentralization, moving from the big-money media to independent small publishers and individual bloggers. Knowing HTML and CSS as well as your way around domains and hosting was a badge of honor, this stuff was very cool back then.

Over the years, however, many of the ideals that WordPress and Web 2.0 stood for were lost by the wayside. Users started preferring the ease-of-use of centralized platforms like Facebook and Instagram, and web blogging itself went into a decline. Of course, WordPress moved beyond being just a blogging platform, and the addition of e-commerce capabilities made it a very nice all-rounder tool. However, it also lost its way for a few years (more on that in my blog post) before the big push for Gutenberg in a last-ditch attempt to stay relevant in the publishing space when faced with formidably polished publishing interfaces by Squarespace, Wix and other hosted platforms. Only time will tell whether this move was even successful, as the Gutenberg plugin is literally one of the most hated plugins I’ve ever seen, with an overwhelming number of 1-star reviews in the WP repository as of today.

In any case, I think that WordPress is by no means the web darling it once was. The spate of acquisitions we see happening definitely increase centralization and move away from one of the core ideals that the early WordPress community espoused – that of decentralization and power to the small guy. Let’s remember that WordPress enabled thousands of young web enthusiasts from all over the world to make a living online and even start their own web businesses selling themes, plugins or related services. In those early WordPress years, it was one of the only avenues for geographically or financially disadvantaged people to get out of the rut they were in. It was definitely a lifesaver for me and I will forever be grateful to WordPress as an open-source project and the wonderful people I met in this community.

Now, the big deal is that we are moving towards Web 3.0. It’s already happening, driven mainly by the invention of Bitcoin, which paved the way to more expansive blockchains like Ethereum that enable smart contracts, decentralized finance and even governance structures through DAOs.

In many ways, I feel the same about crypto and Web 3.0 as I did when WordPress and the shift to Web 2.0 happened. The focus is again on the principles of decentralization, permissionless access, censorship resistance, as well as the new ideas of monetization and privacy.

For the technically-inclined, here’s a nice overview of Web 3.0 architecture. If you haven’t yet dabbled with Web 3.0 apps and want to know more, it’s a great read. It requires quite a paradigm shift and from a development standpoint, I feel that it’s a bigger leap to make compared to the one we made from Web 1.0 to Web 2.0 and I don’t think many people in WordPress are taking notice. WordPress is a tool built by and for millennials, but the new generations are used to different ways of publishing online. Within the WordPress space, meanwhile, we just obsess about the market share that magically grows year after year, but I don’t think that metric is that relevant anymore. WordPress is no longer a sexy and revolutionary tool as it once was, and that’s the more important fact to keep in mind.

Zooming back into the WordPress space, I do believe that these acquisitions are not great news for product owners in general. In this particular case, there are the specific hazards that Carl Hancock and Mark mention. This is one reason why I feel that the WordPress space has grown a lot but at the same time remained very immature in certain areas. The lack of an official plugin store (app store) has driven almost all premium plugin developers to use either EDD or Freemius. These two businesses in turn become excellent acquisition targets, and if you’re worried about the EDD acquisition, wait till Freemius gets acquired. The latter is a hosted service, so they hold all the important data and metrics on their end, and they’d be visible to any company that acquires them. The founders of Freemius are friends of mine, and again, they provided a sorely needed product in the WordPress space, and worked extremely hard at making it a success, but this big danger remains in the case of an eventual acquisition, which in my opinion is only a question of time.

Now, whether you like it or not, the future of WordPress involves many more acquisitions and centralization. With the big players getting bigger, it is undoubtedly harder for the traditional single web enthusiast or developer to develop a product that generates meaningful income. This is not something new, however, it’s already been the case for several years. There will be success stories, but they will be fewer and further between.

The first decision you need to take, in my opinion, is whether you want to be in the WordPress space at all. As I mentioned, personally I find Web 3.0 much closer to my ideals and so I’m devoting my time there. You could also be building apps for Shopify or other platforms, or building a SAAS. I don’t see any special advantages in building a WordPress business over some of the alternatives I mention. It used to feature a lower barrier of entry technically and financially speaking, but I don’t think this is the case anymore.

If you still love WordPress and feel strongly that you want to build products for WP, then perhaps it’s time to focus more on building businesses that are “built to sell”, as Pippin himself mentioned in his announcement post. You might want to think twice about building a competitor to EDD, Yoast SEO, AffiliateWP, and other major plugins, because it’s extremely hard for you to compete. Instead, you might want to focus on businesses that the big companies in the space will find interesting as an acquisition target. That will provide you with a potential big payday as well as a very probably job with a successful company should you accept that proposition.

I hope this was helpful, as always I like to be honest about things with no bad intentions. I am really curious to see what’s in store for WordPress in the years to come, and as a user I hope it remains a major player as a publishing tool, not only in the much-touted market share, but in actual functionality and ease-of-use. Who knows, maybe WordPress also somehow crosses over to Web 3.0 as well.

I love building stuff with my son, and one of our latest projects (admittedly more apt for me than for him as he’s too young to be building these kits), was the Lego buggy 42124. This is a great kit that is fun to build but it is let down by the fact that it is controlled using a smartphone. I don’t like using smartphone remote controls and I definitely don’t want my son looking at a screen at a young age, so I set out to figure out a way to use a hardware remote control.

Turns out it’s quite easy to do. I used Pybricks to add custom code to the Lego hub, then ordered a Lego remote to pair with the buggy.

The code I used can be found below. I set the left red button to “ludicrous mode” which enables the buggy to function at full speed. Otherwise, I set it to run at 50% speed since my son is too young to control it at max speed, especially indoors. This way we can both use it and have some fun while using the appropriate speeds.

Lego Buggy (42124)

from pybricks.pupdevices import Motor, Remote
from pybricks.parameters import Port, Direction, Stop, Button
from pybricks.hubs import TechnicHub
from pybricks.tools import wait

# Initialize the motors.
steer = Motor(Port.B)
front = Motor(Port.A, Direction.COUNTERCLOCKWISE)

# Connect to the remote.
remote = Remote()

# Initialize the hub.
hub = TechnicHub()

# Read the current settings
old_kp, old_ki, old_kd, _, _ = steer.control.pid()

# Set new values
steer.control.pid(kp=old_kp*4, kd=old_kd*0.4)

# Find the steering endpoint on the left and right.
# The middle is in between.
left_end = steer.run_until_stalled(-200, then=Stop.HOLD)
right_end = steer.run_until_stalled(200, then=Stop.HOLD)

# We are now at the right. Reset this angle to be half the difference.
# That puts zero in the middle.
steer.reset_angle((right_end - left_end)/2)
steer.run_target(speed=200, target_angle=0, wait=False)

# Set steering angle for the buggy
steer_angle = (((right_end - left_end)/2)-5)
print('steer angle:',steer_angle)

# Now we can start driving!
while True:
    # Check which buttons are pressed.
    pressed = remote.buttons.pressed()

    # Choose the steer angle based on the right controls.
    if Button.LEFT_PLUS in pressed:
        steer.run_target(1400, -steer_angle, Stop.HOLD, False)
    elif Button.LEFT_MINUS in pressed:
        steer.run_target(1400, steer_angle, Stop.HOLD, False)
    else:
        steer.track_target(0)

    # Top speed controls
    top_speed = 50
    if Button.LEFT in pressed:
        top_speed = 100         

    # Choose the drive speed based on the left controls.
    drive_speed = 0
    if Button.RIGHT_PLUS in pressed:
        drive_speed += top_speed
    if Button.RIGHT_MINUS in pressed:
        drive_speed -= top_speed
    if Button.RIGHT in pressed:
        print('Battery voltage:',(hub.battery.voltage())/1000,"V")
        wait(100)          

    # Apply the selected speed.
    front.dc(drive_speed)

    # Wait.
    wait(10)

Lego Top Gear Rally Car (42109)

I also bought the Lego Top Gear Rally Car (42109) and used similar code with a second remote I bought. Now we can race the cars against each other. I can adjust the speed of each through code to adapt it to our different abilities.

Here’s the code I used on this car. I added some things like changing the remote light buttons and naming the remote so that the car would connect to a specific remote out of the two I have, and thus avoid confusion. I also correspondingly changed the hub’s light color.

from pybricks.pupdevices import Motor, Remote
from pybricks.parameters import Port, Direction, Stop, Button, Color
from pybricks.hubs import TechnicHub
from pybricks.tools import wait

# Initialize the motors.
steer = Motor(Port.B)
front = Motor(Port.D, Direction.COUNTERCLOCKWISE)

# Connect to the remote and set the light on the remote
remote = Remote('topgear', timeout=None)
remote.light.on(Color.RED)

# Print the current name of the remote.
print(remote.name())

# Choose a new name.
remote.name('topgear')

# Initialize the hub.
hub = TechnicHub()
hub.light.on(Color.RED)

# Read the current settings
old_kp, old_ki, old_kd, _, _ = steer.control.pid()

# Set new values
steer.control.pid(kp=old_kp*4, kd=old_kd*0.4)

# Set initial top speed value
top_speed = 100

# Find the steering endpoint on the left and right.
# The middle is in between.
left_end = steer.run_until_stalled(-200, then=Stop.HOLD)
right_end = steer.run_until_stalled(200, then=Stop.HOLD)

# We are now at the right. Reset this angle to be half the difference.
# That puts zero in the middle.
steer.reset_angle((right_end - left_end)/2)
steer.run_target(speed=200, target_angle=0, wait=False)

# Set steering angle for the buggy
steer_angle = (((right_end - left_end)/2)-5)

# Now we can start driving!
while True:
    # Check which buttons are pressed.
    pressed = remote.buttons.pressed()

    # Choose the steer angle based on the right controls.
    if Button.LEFT_PLUS in pressed:
        steer.run_target(1400, -steer_angle, Stop.HOLD, False)
    elif Button.LEFT_MINUS in pressed:
        steer.run_target(1400, steer_angle, Stop.HOLD, False)
    else:
        steer.track_target(0)

    # Top speed controls
    if Button.LEFT in pressed:
        top_speed = 75
    if Button.RIGHT in pressed:
        top_speed = 100   
    if ((Button.RIGHT in pressed) and (Button.LEFT in pressed)):
        top_speed = 40 

    # Choose the drive speed based on the left controls.
    drive_speed = 0
    if Button.RIGHT_PLUS in pressed:
        drive_speed -= top_speed
    if Button.RIGHT_MINUS in pressed:
        drive_speed += top_speed

    # Print battery voltage    
    if Button.RIGHT in pressed:
        print('Battery voltage:',(hub.battery.voltage())/1000,"V")
        wait(100)           

    # Apply the selected speed.
    front.dc(drive_speed)

    # Wait.
    wait(10)

Lego Go Kart (42109 variant)

from pybricks.pupdevices import Motor, Remote
from pybricks.parameters import Port, Direction, Stop, Button, Color
from pybricks.hubs import TechnicHub
from pybricks.tools import wait

# Initialize the motors.
steer = Motor(Port.B)
front = Motor(Port.D, Direction.COUNTERCLOCKWISE)

# Connect to the remote and set the light on the remote
remote = Remote('topgear', timeout=None)
remote.light.on(Color.GREEN)

# Print the current name of the remote.
print(remote.name())

# Choose a new name.
remote.name('kart')

# Initialize the hub.
hub = TechnicHub()
hub.light.on(Color.GREEN)

# Read the current settings
old_kp, old_ki, old_kd, _, _ = steer.control.pid()

# Set new values
steer.control.pid(kp=old_kp*4, kd=old_kd*0.4)

# Set initial top speed value
top_speed = 100

# Find the steering endpoint on the left and right.
# The middle is in between.
left_end = steer.run_until_stalled(-200, then=Stop.HOLD)
right_end = steer.run_until_stalled(200, then=Stop.HOLD)

# We are now at the right. Reset this angle to be half the difference.
# That puts zero in the middle.
steer.reset_angle((right_end - left_end)/2)
steer.run_target(speed=200, target_angle=0, wait=False)

# Set steering angle for the buggy
steer_angle = (((right_end - left_end)/2)-5)

# Now we can start driving!
while True:
    # Check which buttons are pressed.
    pressed = remote.buttons.pressed()

    # Choose the steer angle based on the right controls.
    if Button.LEFT_PLUS in pressed:
        steer.run_target(1400, -steer_angle, Stop.HOLD, False)
    elif Button.LEFT_MINUS in pressed:
        steer.run_target(1400, steer_angle, Stop.HOLD, False)
    else:
        steer.track_target(0)

    # Top speed controls
    if Button.LEFT in pressed:
        top_speed = 75
    if Button.RIGHT in pressed:
        top_speed = 100   
    if ((Button.RIGHT in pressed) and (Button.LEFT in pressed)):
        top_speed = 40 

    # Choose the drive speed based on the left controls.
    drive_speed = 0
    if Button.RIGHT_PLUS in pressed:
        drive_speed -= top_speed
    if Button.RIGHT_MINUS in pressed:
        drive_speed += top_speed

    # Print battery voltage    
    if Button.RIGHT in pressed:
        print('Battery voltage:',(hub.battery.voltage())/1000,"V")
        wait(100)           

    # Apply the selected speed.
    front.dc(drive_speed)

    # Wait.
    wait(10)

Lego 4×4 Extreme Off-Roader (42099)

from pybricks.pupdevices import Motor, Remote
from pybricks.parameters import Port, Direction, Stop, Button
from pybricks.tools import wait

# Initialize the motors.
steer = Motor(Port.C)
front = Motor(Port.A, Direction.COUNTERCLOCKWISE)
rear = Motor(Port.B, Direction.COUNTERCLOCKWISE)

# Lower the acceleration so the car starts and stops realistically.
front.control.limits(acceleration=1000)
rear.control.limits(acceleration=1000)

# Connect to the remote.
remote = Remote()

# Find the steering endpoint on the left and right.
# The middle is in between.
left_end = steer.run_until_stalled(-200, then=Stop.HOLD)
right_end = steer.run_until_stalled(200, then=Stop.HOLD)

# We are now at the right. Reset this angle to be half the difference.
# That puts zero in the middle.
steer.reset_angle((right_end - left_end) / 2)
steer.run_target(speed=200, target_angle=0, wait=False)

# Now we can start driving!
while True:
    # Check which buttons are pressed.
    pressed = remote.buttons.pressed()

    # Choose the steer angle based on the left controls.
    steer_angle = 0
    if Button.LEFT_PLUS in pressed:
        steer_angle -= 75
    if Button.LEFT_MINUS in pressed:
        steer_angle += 75

    # Steer to the selected angle.
    steer.run_target(500, steer_angle, wait=False)

    # Choose the drive speed based on the right controls.
    drive_speed = 0
    if Button.RIGHT_PLUS in pressed:
        drive_speed += 1000
    if Button.RIGHT_MINUS in pressed:
        drive_speed -= 1000

    # Apply the selected speed.
    front.run(drive_speed)
    rear.run(drive_speed)

    # Wait.
    wait(10)

Troubleshooting

If you’re having issues getting the code to work, you can try both editors:

• beta.pybricks.com
• code.pybricks.com

You can also use this code to verify that a connection is being successfully made by your controller with the hub:

from pybricks.hubs import TechnicHub
from pybricks.pupdevices import Remote
from pybricks.parameters import Button, Color
from pybricks.tools import wait

hub = TechnicHub()

# Make the light red while we connect.
hub.light.on(Color.RED)

# Connect to the remote.
my_remote = Remote() 

# Make the light green when we are connected.
hub.light.on(Color.GREEN)

while True:
    # For any button press, make the light magenta.
    # Otherwise make it yellow.
    if my_remote.buttons.pressed():
        hub.light.on(Color.MAGENTA)
    else:
        hub.light.on(Color.YELLOW)
    wait(10)

Lego 42124 Trike Variant

from pybricks.pupdevices import Motor, Remote
from pybricks.parameters import Port, Direction, Stop, Button
from pybricks.hubs import TechnicHub
from pybricks.tools import wait

# Initialize the motors.
steer = Motor(Port.B)
front = Motor(Port.A, Direction.COUNTERCLOCKWISE)

# Connect to the remote.
remote = Remote()

# Initialize the hub.
hub = TechnicHub()

# Read the current settings
old_kp, old_ki, old_kd, _, _ = steer.control.pid()

# Set new values
steer.control.pid(kp=old_kp*0.5, kd=old_kd*1)

# Find the steering endpoint on the left and right.
# The middle is in between.
left_end = steer.run_until_stalled(-200, then=Stop.HOLD)
right_end = steer.run_until_stalled(200, then=Stop.HOLD)

print('left end:',left_end)
print('right end:', right_end)

# We are now at the right. Reset this angle to be half the difference.
# That puts zero in the middle.
steer.reset_angle((right_end - left_end)/2)
steer.run_target(speed=100, target_angle=0, wait=False)

# Set steering angle for the buggy
steer_angle = (((right_end - left_end)/2)-20)
print('steer angle:',steer_angle)

# Now we can start driving!
while True:
    # Check which buttons are pressed.
    pressed = remote.buttons.pressed()

    # Choose the steer angle based on the right controls.
    if Button.LEFT_PLUS in pressed:
        steer.run_target(400, -steer_angle, Stop.HOLD, False)
    elif Button.LEFT_MINUS in pressed:
        steer.run_target(400, steer_angle, Stop.HOLD, False)
    else:
        current_angle = steer.angle()
        deadband = 3  # Define a deadband range of +/- 3 degrees
        if current_angle > deadband:
            steer.track_target(0)
        elif current_angle < -deadband:
            steer.track_target(0)
        else:
            steer.stop()

    # Top speed controls
    top_speed = 50
    if Button.LEFT in pressed:
        top_speed = 100         

    # Choose the drive speed based on the left controls.
    drive_speed = 0
    if Button.RIGHT_PLUS in pressed:
        drive_speed += top_speed
    if Button.RIGHT_MINUS in pressed:
        drive_speed -= top_speed
    if Button.RIGHT in pressed:
        print('Battery voltage:',(hub.battery.voltage())/1000,"V")
        wait(100)          

    # Apply the selected speed.
    front.dc(drive_speed)

    # Wait.
    wait(10)

Lego 51515 Robot Inventor

You can also use the same principles to connect to the Lego 51515 Robot Inventor hub. There are many things you can build with that kit, but below you can find the general framework for connecting the Lego remote to the 51515 hub:

from pybricks.hubs import InventorHub
from pybricks.pupdevices import Remote
from pybricks.parameters import Button
from pybricks.tools import wait

# Initialize the hub and the remote
hub = InventorHub()
remote = Remote()

while True:
    # Check if a button on the remote is pressed
    pressed = remote.buttons.pressed()

    if Button.LEFT in pressed:
        # Code for when the left button is pressed
        pass
    elif Button.RIGHT in pressed:
        # Code for when the right button is pressed
        pass
    
    # Delay to avoid rapid polling
    wait(10)

Using a PS4 Controller via BrickController2

BrickController2 is an app that lets you control LEGO creations with game controllers. To use a PS4 controller with BrickController2, follow these steps:

1. Pair the PS4 Controller with Your Device:a. Put the PS4 controller in pairing mode by holding down the “Share” and “PS” buttons at the same time until the light bar starts flashing.b. On your device (whether it’s an Android or iOS), open the Bluetooth settings.

   c. Look for the PS4 controller in the list of available devices. It might show up as “Wireless Controller” or something similar.

   d. Tap on the PS4 controller’s name in the list to pair it with your device. You might be prompted to confirm the pairing.

2. Open BrickController2:a. Make sure you’ve set up your LEGO devices in the app.b. In the “Controllers” section, you should see the PS4 controller listed if it’s connected. If not, try disconnecting and reconnecting the PS4 controller via Bluetooth.
3. Assign Controls:a. Once the PS4 controller is recognized in BrickController2, you can start assigning its buttons to control specific functions of your LEGO creation. This can include movement directions, rotations, or other actions.
4. Play and Control:Once you’ve set up the controls, you can use your PS4 controller to play with and control your LEGO models. Ensure the LEGO devices and the controller are both connected and in range for optimal performance.

Further Reading

• Brickset – reviews of Lego sets
• Rebrickable – alternate builds
  • GoPro mod
• MOCHub – “my own creation”
• RacingBrick on Youtube – fantastic Lego builds channel

Powerlink adapters are a fantastic invention that help those who have poor WiFi connections at home get a decent signal through the powerlines. I’ve tried various solutions to be able to make the best use of my fibre optic connections in rooms where the WiFi connection was playing around, and have finally settled on the Netgear adaptors.

I just wanted to write a few notes down here for my future self and others who might be in the market for one of these devices.

I’ve also tried the Devolo and TP-link options. I got the best product from each of these brands, but the Netgear was the clear winner. In fact, although it advertised lower speeds than the Devolo, it still came up on top in the end.

The difference between the Netgear and Devolo was very significant. I could reach the same upload speed with both but download speed on the Devolo was half that of the Netgear.

An interesting fact is that it’s the upload speed that suffered most with WiFi connections. I’m not sure why that is so.