Concerned about the future of LEGO remote control options

[Toastie]

13 minutes ago, gyenesvi said:

True, especially if we realize that they could actually simply be controlled by a PU hub if there was a conversion cable. Do such 3rd party cables exist?

In terms of "ready for purchase"? People as @dr_spock have shown what is needed - if you have the skills. China is always a good way to find these cables. However, with all the active electronics inside many PUp motors you need to fake a PUp train motor as substitute for any PF or 9V motor, as a PUp hub "recognizes" what you plugged in. And refuses to do anything not compatible with the data/wiring at one of its ports.

Some of my PUp (City) 2 port hub equipped trains run on 9V train motors. Others (way more controllable) use PUp L motors, with PID speed control enabled.

Best
Thorsten

     

[2GodBDGlory]

31 minutes ago, gyenesvi said:

True, especially if we realize that they could actually simply be controlled by a PU hub if there was a conversion cable. Do such 3rd party cables exist?

Yep, they do! I definitely saw some of those while I was poking around AliExpress this morning

[gyenesvi]

21 minutes ago, Toastie said:

In terms of "ready for purchase"?

Of course :)

21 minutes ago, Toastie said:

However, with all the active electronics inside many PUp motors you need to fake a PUp train motor as substitute for any PF or 9V motor, as a PUp hub "recognizes" what you plugged in. And refuses to do anything not compatible with the data/wiring at one of its ports.

I don't think that would be a problem for the basic use case of controlling a dumb DC motor, hopefully that is supported for anything you plug in, even if it's not recognized..

12 minutes ago, 2GodBDGlory said:

Yep, they do! I definitely saw some of those while I was poking around AliExpress this morning

Okay, I searched and found these links, they have a couple of useful looking items!

https://www.aliexpress.com/item/1005004183256378.html

https://www.aliexpress.com/item/1005005203252084.html

Edited Wednesday at 10:05 PM by gyenesvi

[Toastie]

29 minutes ago, gyenesvi said:

I don't think that would be a problem for the basic use case of controlling a dumb DC motor, hopefully that is supported for anything you plug in, even if it's not recognized..

You'd wished for, right? I did. But no, you need to make a lill bridge between the 6 pins of the PUp plug, that is all there is. Did TLG provide such a solution? Well - of course not . But that is my entire point regarding TLG abandoning backward compatibility - in my view, on purpose.

Best
Thorsten 

[Glaysche]

1 hour ago, gyenesvi said:

You mean just because the HW has Bluetooth capabilities, right? I mean it's obviously true in that sense, but kind of useless without supporting (official) firmware. I think the firmware is an important part of the equation, because it's really rare that we users have the knowledge to change the firmware of a company's proprietary hardware, we are kind of super lucky with the existence of PyBricks. If that would not be the case, it would be as if the hardware did not support the Xbox controller, so I would give that to TLG.

My thesis in my first message was that PoweredUp hardware is really good and TLG completely failed at writing software.  The hardware team chose to use BLE for communication which is a great decision expressly because it is an industry standard.  This made it possible to talk to other devices using that same industry standard.  They could have tried to build some proprietary radio communication system, for example, which would have been a disaster.  The Lego hardware team that designed PoweredUp, in my opinion, really thought things through and built something general purpose, standards based, and extensible.  The software team failed to deliver.

[Toastie]

21 minutes ago, Glaysche said:

The software team failed to deliver.

Yup.

I don't think they are LEGO teams though, I believe they were temporally hired. As was the software team. Hardware (along with firmware, which is a 1:1 endeavor) is one smooth thing, maybe with a few upgrades here and there. In contrast, operating software is orchestrating the whole ecosystem, and that is where the real challenge is. Along with the required persistence. TLG never had in modern times.

Best
Thorsten  

[gyenesvi]

13 hours ago, Toastie said:

You'd wished for, right? I did. But no, you need to make a lill bridge between the 6 pins of the PUp plug, that is all there is. Did TLG provide such a solution? Well - of course not . But that is my entire point regarding TLG abandoning backward compatibility - in my view, on purpose.

Oh, that's a bummer. So you did actually try it and it didn't work? I don't get the thing about the bridge on the 6 pins, what does that mean?

12 hours ago, Glaysche said:

My thesis in my first message was that PoweredUp hardware is really good and TLG completely failed at writing software.  The hardware team chose to use BLE for communication which is a great decision expressly because it is an industry standard.  This made it possible to talk to other devices using that same industry standard.  They could have tried to build some proprietary radio communication system, for example, which would have been a disaster.  The Lego hardware team that designed PoweredUp, in my opinion, really thought things through and built something general purpose, standards based, and extensible.  The software team failed to deliver.

Well I do get that, I agree that using BLE is better than proprietary radio technology and enables connectivity to other devices. I think where we diverge is whether we consider the firmware as "part" of the hardware side or the software side. I think it's more close to the hardware side, it's typically developed in collaboration with the hardware development team; it cannot be an independent component on top of the bare hardware as it is itself the programming interface to the hardware. That's why I say the hardware is not that much useful without proper firmware. So the next logical question is how good is the official firmware? I tend to think that a programmable firmware similar to Pybricks could have been more flexible/useful than a closed firmware with a fixed communication protocol. The fixed firmware and communication protocol actually prohibits the connectivity with 3rd party BLE capable components, like gamepad controllers. So in this sense, I'd say even the hardware is half baked, in some sense a closed system with missing components. We just got lucky that someone managed to hack it. But it's not the case for example with the all-in-one technic car hub, it hasn't been hacked yet.

[Toastie]

1 hour ago, gyenesvi said:

Oh, that's a bummer. So you did actually try it and it didn't work? I don't get the thing about the bridge on the 6 pins, what does that mean?

Yup.

The "smart" Pup motors tell the hub what kind of motor they actually are - via data flow upon plugging them him. I believe Philo has sniffed that protocol and gives some information about it on his Reference Website . You can then poll these (hub-deciphered, i.e., the hub assigns a two-digit number to that specific actuator type, as per LWP3.0 protocol) data, once the connection is established and decide from there what you want to do in your program. You can use appropriate speed (and not power) settings, so that your motor will (within limits you set as well, until everything maxes out of course), run with constant rpm and so on. The LEGO apps do that as well, and specifically the LEGO PoweredUp app actually lets you select more advanced programming blocks, once a "smart" motor is attached. 

The PUp train motor is "dumb", as naturally are all PF and 9V motors: 9V only had the two power wires (DC or PWM), PF the 2 permanent power lines (DC) and in addition the 2 PWM controlled power wires. PUp has 6 wires, as above + 2 x data. The PUp train motor has also a 6 wire cable, and does the "bridging", as described below and in the video, internally. 

When PUp wires 4 and 5 as well as 3 and 6 are joined together, and the PUp connector is plugged into a PUp hub, the hub assumes a dumb PUp train motor was attached (when these bridges are not there, it refuses to do anything on that port). And then just provides the usual power (not speed) setting 0 - 7, as it has been for ages in LEGO world.

And as per usual @BatteryPoweredBricks has made a wonderful video about this; there are also some threads, particularly in the Train forum here on EB, about that DIY "trick":

So this works for all dumb 9V, RC, PF motors. In other words, TLG could have made such adapters at very low cost for backward compatibility reasons to let PUp hubs power the 9V, RC, PF world motors.

Note: It is some years ago, when I made these PUp/PF, PUp/9V adapters for my purposes - so I may not recall all details accurately. Others may very well do, so folks, please correct me, when I was writing nonsense!

Best regards
Thorsten 

Edited Thursday at 03:17 PM by Toastie

[Toastie]

2 hours ago, gyenesvi said:

But it's not the case for example with the all-in-one technic car hub, it hasn't been hacked yet.

Well, it is underway, as @Repkovsky pointed out on the first page (as it appears on my computer) of this thread:

https://github.com/DanieleBenedettelli/TechnicMoveHub 

Best
Thorsten 

[Glaysche]

2 hours ago, gyenesvi said:

Well I do get that, I agree that using BLE is better than proprietary radio technology and enables connectivity to other devices. I think where we diverge is whether we consider the firmware as "part" of the hardware side or the software side. I think it's more close to the hardware side, it's typically developed in collaboration with the hardware development team; it cannot be an independent component on top of the bare hardware as it is itself the programming interface to the hardware. That's why I say the hardware is not that much useful without proper firmware. So the next logical question is how good is the official firmware? I tend to think that a programmable firmware similar to Pybricks could have been more flexible/useful than a closed firmware with a fixed communication protocol. The fixed firmware and communication protocol actually prohibits the connectivity with 3rd party BLE capable components, like gamepad controllers. So in this sense, I'd say even the hardware is half baked, in some sense a closed system with missing components. We just got lucky that someone managed to hack it. But it's not the case for example with the all-in-one technic car hub, it hasn't been hacked yet.

I guess our categorization or terminology is different, then.  The firmware that really matters is the base level firmware that allows you to install new firmware anytime you want.  Lego did a good job there, too.  This is what allows PyBricks to work.  In fact, Lego also built a way to update firmware over Bluetooth that you can see when you use the Control+ app with a brand new hub.  With this as a basis, Lego could have improved the firmware over time, filling in functionality they didn't ship with at first.  That effectively turns the firmware into software.  This updatable firmware is code that needs to be maintained and improved by a software team as all the software improves.  If Lego had wanted to offer an Xbox-controller-without-smart-device mode, they could have shipped it at any time with a simple upgrade to the software running on the hub.

[gyenesvi]

1 hour ago, Toastie said:

When PUp wires 4 and 5 as well as 3 and 6 are joined together, and the PUp connector is plugged into a PUp hub, the hub assumes a dumb PUp train motor was attached (when these bridges are not there, it refuses to do anything on that port). And then just provides the usual power (not speed) setting 0 - 7, as it has been for ages in LEGO world.

I did know about that identification in the protocol and the different modes, but I assumed it is only required for enabling the advanced functionality, and the base functionality would run regardless. I didn't know how this is implemented for the dumb motors, thanks for the explanation. Do you know if this identification/disabling is happening in the Lego firmware or somewhere at a deeper level? Specifically, to use a dumb motor with Pybricks, do we need to use this hack as well, or does Pybricks skip this check and allow control of dumb motors?

1 hour ago, Toastie said:

And as per usual @BatteryPoweredBricks has made a wonderful video about this; there are also some threads, particularly in the Train forum here on EB, about that DIY "trick":

That's a great DIY video indeed, thanks for the reference!

1 hour ago, Toastie said:

Well, it is underway, as @Repkovsky pointed out on the first page (as it appears on my computer) of this thread:

Interesting to know that the communication protocol is getting reverse engineered, though that does not allow us to change the firmware to PyBricks.

45 minutes ago, Glaysche said:

I guess our categorization or terminology is different, then.  The firmware that really matters is the base level firmware that allows you to install new firmware anytime you want.  Lego did a good job there, too.  This is what allows PyBricks to work.  In fact, Lego also built a way to update firmware over Bluetooth that you can see when you use the Control+ app with a brand new hub.  With this as a basis, Lego could have improved the firmware over time, filling in functionality they didn't ship with at first.  That effectively turns the firmware into software.  This updatable firmware is code that needs to be maintained and improved by a software team as all the software improves.  If Lego had wanted to offer an Xbox-controller-without-smart-device mode, they could have shipped it at any time with a simple upgrade to the software running on the hub.

In this sense of firmware, I do agree with you.

[Toastie]

19 minutes ago, gyenesvi said:

Specifically, to use a dumb motor with Pybricks, do we need to use this hack as well, or does Pybricks skip this check and allow control of dumb motors?

No, I am not sure about that, I believe it is a firmware based thing. I bet @Pybricks will know all about that!

Best
Thorsten

[Moz]

I suspect TLG have discovered how annoying smart devices are for long term anything. Us Lego customers expect that if we buy a Lego product it will work effectively forever (people still use micromotors!) But the smart device world is not like that. Some smart devices now come with support for a promised seven whole years! But even during that time the apps for them will need several updates, possibly major rewrites. So TLG is on a treadmill where every new app they put out comes with an implicit "keep maintaining this forever". Just like SBrick are struggling with their one(ish) app...

I wouldn't be surprised to see TLG officially support something like an xbox controller, via a deal with the manufacturer and likely some mkind of cross-promoted set+game. Or just a straight up Official Lego Controller{tm} that you likely buy as an additional thing (complete with howls of outrage from Lego fans who don't have a box of spare wheels and tyres in a cupboard somwhere that they're keeping just in case their main box of spare wheels and tyres ever runs low). I wouldn't object to buying one, $50 or $100 controller for the next five+ years of sets, especially if it was backward compatible with the existing powered up hubs. Ideally they'd make it programmable or "accidentally leak" the necessary details.

OTOH I keep hoping that TLG with start putting the PU hubs in as optional accessories because I don't need more of them and replacing the batteries is a PITA.

[m2fel]

On 3/25/2026 at 5:02 PM, Glaysche said:

Just a correction here.  When used with PyBricks where the hubs talk directly to each other with no smart device involved, there is basically zero lag.  If you try to use it with the PoweredUp app through the smart device, there is quite a bit of lag.  The hardware supports this use case quite well.

In my original message, I forgot to mention using an xbox controller.  The hardware obviously supports that as well.

Hello! This is exactly what I'm looking for. I want to build a proportional remote out of bricks, including one hub and motors to run a vehicle (42124?). I scanned the Pybricks homepage and found some hints.

Since this seems difficult for me, could someone point me to a place with finished instructions for a remote? I would rather build than force myself through code, trial and error, or start from scratch. It would be really appreciated!

 

[Glaysche]

14 hours ago, m2fel said:

Hello! This is exactly what I'm looking for. I want to build a proportional remote out of bricks, including one hub and motors to run a vehicle (42124?). I scanned the Pybricks homepage and found some hints.

Since this seems difficult for me, could someone point me to a place with finished instructions for a remote? I would rather build than force myself through code, trial and error, or start from scratch. It would be really appreciated!

 

You may be able to use my robotic arm as a model although what you would do would be simpler.  If you look at the Rebrickable page, you can download the Python code called Robot_mk5_software_v1.zip.  There are seven Python files in there for the 7 different hubs used in the robotic arm and remote control.

Before you start, I would suggest looking at the getting started section for PyBricks: https://pybricks.com/learn/

If you look at remote_1.py, here it is in its entirety:

# Remote 1: A1 & A2

from pybricks.hubs import EssentialHub
from pybricks.pupdevices import Motor
from pybricks.parameters import Port
from pybricks.tools import wait

hub = EssentialHub(broadcast_channel=3)

A1 = Motor(Port.A)
A1.reset_angle()
A2 = Motor(Port.B)
A2.reset_angle()

while True:
    a1_angle = A1.angle()
    a2_angle = A2.angle()
    hub.ble.broadcast((a1_angle, a2_angle))
#    print((a1_angle, a2_angle))
    wait(50)

 

 

The important things to note:

• "broadcast_channel=3" passed into the EssentialHub.  This says which channel you are broadcasting on over Bluetooth.  This needs to match the receiver side.
• 'A1' and 'A2' stand for axis 1 and axis 2.  These are the motors I am using as angle sensors.
• The hub.ble.broadcast(...) actually sends out the positions of the motors.  I am doing that in a tight loop with a 50ms pause

 

In my code, the hubs on the robot are much more complicated because of the calibration routines.  Look at 'shoulder_v5.py'. There are a couple of interesting bits:

    async def process_remote(self) -> None:
        while True:
            received = self.hub.ble.observe(3)
            if received is not None:
                a1, a2 = received
                self.a1.track_target(a1)
                self.a2.track_target(a2)
            await wait(50)

This reads data from Blutooth with the self.hub.ble.observe(3) -- note it is the same channel we are sending over above.  You can see the code for 'track_target()' elsewhere in the file.  It calls the 'track_target()' method on the motor after doing some math.  This tells the motor to go to that position as fast as it can.  Another important bit is that you need to tell the hub to listen to channel 3 in this example:

        self.hub = PrimeHub(broadcast_channel=1, observe_channels=[2, 3, 7])

In this example, it is listening on channels 2, 3, and 7.  In my robotic arm, the hubs talk to each other quite a bit.

[LabManager]

While this will not be an out-of-box solution, it's possible to use a custom programmable joystick like M5Stack Atom JoyStick. It has Blutooth LE support inside it's ESP32 core, so it can be connected to the PUP hubs (where BLE is the only option for communication).

With some Arduino code using legoino library, you can write sketches to control your model. Even if coding in C++ looks more challenging compared to Python, this should not be a problem with modern AI agents. And there's no need to update the hub's firmware to PyBricks since legoino implements LEGO's wireless protocol which is built-in in stock firmware.

[m2fel]

@Glaysche Thank you. This is exactly the starting point I was looking for!

@LabManager Building a remote with a programmable joystick would be awesome but it looks way harder than building a remote using Pybricks. Thus I will go for hub to hub communication.