Control+ General Discussion

[suffocation]

I think a point that's being missed here is that any assumed advantages of PU over PF are completely offset by the extortionate cost of PU motors.

Also, I rebuilt my crawler crane with PU instead of PF - no noticeable advantages other than the fact that PU XLs have more mounting points. On the downside, the PU hub is bigger and heavier than its BuWizz counterpart; it doesn't allow cable stacking; it has no ludicrous mode; it's grossly underpowered.

Just my two pence as a talentless beer swiller.

Edited June 3, 2020 by suffocation

[OlSom]

Just now, kbalage said:

I'm just wondering what's "bad" in PU and what was not possible to do with it that you could perform with SBrick & PF.

Size and weight of the hub mostly, along with not doing anything PF + SBrick cannot do in a smaller package. I also have servo issues with the BrickController app, so using my XBox controller for steering isn't really as smooth as it should be, while it works great with the SBrick.

Having to rely on your guides to piece together something to control a MOC as simple as car with drive and steering is also really awful (and still no interface for it), how do we not still not have that? I guess that's my fault though, these were known issues back then too.

[kbalage]

9 hours ago, howitzer said:

I wonder if there will be an option to and share your programmed control profiles easily online for others to download?

Since this feature is available in Boost already I don't see any reason why it wouldn't be added to the Powered Up app as well with time.

If someone has questions/doubts about the development path and the future of Powered Up, I suggest to watch the interview I made with the app's product owner. I don't say "everything is awesome" and PU is already where it is supposed to be, I think TLG's biggest mistake was not starting the development a few years earlier and I think the whole project still has less resources assigned that it deserves.

Apparently there was a decision made in the early days, the development was focusing on two ends of the user spectrum. Simple control profiles were developed for the sets for casual users, and the coding block environment was created for the skilled ones who are familiar with coding, leaving the majority of the MOCers who want customization but don't like coding without a proper solution. Of course we are free to moan about this, but the team is aware and focusing the development to provide a proper solution. Customizable interfaces are coming, proper servo control is coming. 

A few years ago when we only had PF everyone was complaining about the lack of a modern solution and was praising BuWizz and SBrick for their app-focused innovations. Now that we have it in an official form I see a lot of people complaining to have the good old PF system back because PU is app-based. PF is still available for everyone if a simple solution is needed, I'm happy to see an alternative approach that has much more potential that the old system had. 

[dr_spock]

The price of PU motors do seem in line with Mindstorm motors that have similiar functionalitiy.  I've been reusing my less expensive PF motors with PU when I only need to use on/off or speed control programmability. 

 

 

[howitzer]

38 minutes ago, kbalage said:

Since this feature is available in Boost already I don't see any reason why it wouldn't be added to the Powered Up app as well with time.

If someone has questions/doubts about the development path and the future of Powered Up, I suggest to watch the interview I made with the app's product owner. I don't say "everything is awesome" and PU is already where it is supposed to be, I think TLG's biggest mistake was not starting the development a few years earlier and I think the whole project still has less resources assigned that it deserves.

Apparently there was a decision made in the early days, the development was focusing on two ends of the user spectrum. Simple control profiles were developed for the sets for casual users, and the coding block environment was created for the skilled ones who are familiar with coding, leaving the majority of the MOCers who want customization but don't like coding without a proper solution. Of course we are free to moan about this, but the team is aware and focusing the development to provide a proper solution. Customizable interfaces are coming, proper servo control is coming. 

A few years ago when we only had PF everyone was complaining about the lack of a modern solution and was praising BuWizz and SBrick for their app-focused innovations. Now that we have it in an official form I see a lot of people complaining to have the good old PF system back because PU is app-based. PF is still available for everyone if a simple solution is needed, I'm happy to see an alternative approach that has much more potential that the old system had. 

Yeah, it seems logical to have shareable control profiles, no reason not to implement that kind of functionality.

Many people seem to think that PU is a finished product with no more major features in development, while I think it's obvious that it's a work in progress, and it's only a matter of time when we'll see the things people have been asking. While PU is currently lacking many useful features, I'm sure in a couple of years it'll be much more useful system for all MOCers.

[OlSom]

I'm not saying it's all bad, but the usability is very far from what it could have been.

34 minutes ago, kbalage said:

whole project still has less resources assigned that it deserves.

How little does it have when individuals in their free time can come up with much more user friendly solutions? (BrickController and Controlz)

39 minutes ago, kbalage said:

two ends of the user spectrum

This is where the main issue is I think, the block "coding" end of the user base seems excessively small based on the kind of motorized MOCs I see here and Instagram, with the vast majority of functions only requiring proportional control, servo control, or a simple on/off switch.

37 minutes ago, kbalage said:

and was praising BuWizz and SBrick for their app-focused innovations

I don't think anyone would have praised either of them if their software wasn't able to control simple MOCs this long after their release 

[kbalage]

6 minutes ago, OlSom said:

How little does it have when individuals in their free time can come up with much more user friendly solutions? (BrickController and Controlz)

Those solutions use only a fraction of the potential in the system, no use of sensors, interactive features of the motors etc. And yes, I totally agree that TLG missed the point with the approach they took, I think the release schedule should have been different. As I see they wanted to provide access to the advanced features as soon as possible, since those are the ones differentiating PU from PF, providing an added value. 

9 minutes ago, OlSom said:

I don't think anyone would have praised either of them if their software wasn't able to control simple MOCs this long after their release 

People usually forget how simple the BuWizz or the SBrick apps were in their early years, lacking some very basic features, they also needed years to become versatile and useful. But the response from TLG was too slow, so now we are in a situation where the PU environment still has major features added with every release, instead of having a mature and fully capable system released on day one. 

[OlSom]

I suppose it's not that bad, just disappointing considering the cost. I guess I'll make it a point to use PU stuff in my next truck.

[allanp]

5 hours ago, kbalage said:

I'm just wondering what's "bad" in PU and what was not possible to do with it that you could perform with SBrick & PF.

Have we not been vocal enough for you to know the answer to that question already? I thought we complained too much!  To gather what you probably already knew:

If you already know the complaints about PU then you can skip this list as there's nothing that hasn't been said already.

1) You can't stack the connectors (PF and Sbrick allow many connectors to be stacked)

2) for every 4 motors or lights you have to use 6 batteries (stacking ports for both motors and IR receivers allowed many more motors and lights to run off 6 batteries)

3) The Technic line currently has an L motor and an XL PU motor, both of which have very similar speed and very similar torque, so what's the point of having 2 different motors when their performance characteristics are basically interchangeable? (To be fair it's early days and I guess more motors are coming, but I bet they will all be very slow and not as good as the buggy motor)

4) The motors are actually NOT interchangeable. If you want to make a MOC using an existing profile you have to use the same motors in the same ports, even though their performance is near identical. (PF didn't need profiles so no issue with that)

5) You can't use use the 9v motors, such as the 5x4 ungeared motor and the buggy motor (You can with PF and Sbrick and I doubt there will be another motor with the power of the buggy motor or the speed of the ungeared 9v motor)

6) Making custom creations with PU is not fun for me. I don't consider coding to be intimidating. They call it the "advanced" end of the spectrum but it's still coding for kids. I just find it boring and tedious and I have no desire to learn it. I never got into mindstorms for that reason. I like Technic, I don't like coding. They are completely different things and to have to do one to fully embrace the other is ridiculous. I wouldn't have any problem with the option to code being there, I would welcome the choice for those that do want it because choice is good, if it wasn't for the fact that there's no other, non third party option. Once there is another completely non code block based alternative that's not 3rd party then I look forward to being able to applaud it for helping to bring Lego into the 21st century, but not before. (PF doesn't have this problem and Sbrick doesn't need you to use code blocks)

7) It's crazy expensive. For less money than these plastic geared Chinese PU motors I can buy a hobby grade servo motor with all steel gears, ball bearing races, enough torque to snap a Lego axle, zero backlash and fine precision control (with hundreds if not thousands of steps) in a package that would fit in a 2x5x2 brick, and it doesn't need coding to work (PF and Sbrick seem more reasonably priced)

8) Lack of physical controllers. Now even when I'm playing with (erm....I mean operating ) my Lego creations I'm looking at a phone screen!

Now please understand, I don't want this to feel like an attack on the work ethic of anybody actually working on PU, honestly I really don't. Whilst I can see the flaws I can also see how much work has gone into PU already. But I know what it's like to be part of, and lead projects that you really sweat over but you know isn't being welcomed or appreciated, but it's been dropped on you from high up like a turd from the gods. You don't get to choose what to prioritise, you just have to turn their ramblings into a workable reality.

But whilst I firmly believe I have listed some of the worst aspects of PU, it could be that they are only problems from an AFOL perspective. I don't actually know how fixing any of those issues would make much of a difference to TLGs target audience. Does TLGs target audience care that they can't stack the connectors or use the buggy motor which they probably haven't heard of? (maybe they do, I know I would have, but I don't know) Does TLGs latest push toward AFOLs consist of any actual listening or is it just marketing? You'll have to tune in next year to find out!

Edited June 3, 2020 by allanp

[kbalage]

43 minutes ago, allanp said:

Have we not been vocal enough for you to know the answer to that question already? I thought we complained too much!  

I was actually asking about that specific situation, I'm totally aware of the issues that were raised during the past 2 years (partially by myself included). PU is not perfect, but it's a step forward for a smarter way of controlling LEGO, and that required several changes. I'm not trying to defend anyone, just trying to provide thoughts from another perspective. Let's see:

46 minutes ago, allanp said:

1) You can't stack the connectors (PF and Sbrick allow many connectors to be stacked)

You can't stack sensors and smart motors, simple as that. Since TLG wanted to add more functionality and interactivity to the system they had to go this way. 

48 minutes ago, allanp said:

2) for every 4 motors or lights you have to use 6 batteries (stacking ports for both motors and IR receivers allowed many more motors and lights to run off 6 batteries)

True, but running 4+ motors from a single power source would already affect their performance in the PF world as well. I don't think there are that many applications where you would connect more than 2 IR receivers to a single battery box. Regarding the lights TLG needs to come up with a better solution that they have currently, a "smart" port replicator with control electronics but without battery would be a possible solution. Since the connected motor/light/etc. type can be detected it is simple to restrict the type of devices to ensure the required power level is still provided.

53 minutes ago, allanp said:

3) The Technic line currently has an L motor and an XL PU motor, both of which have very similar speed and very similar torque, so what's the point of having 2 different motors when their performance characteristics are basically interchangeable?

Their difference is very similar to the PF L & XL motors when they are geared to the same speed. The PU XL motor is simply geared up internally compared to the PF equivalent (or not geared down, not sure about that).

55 minutes ago, allanp said:

4) The motors are actually NOT interchangeable. If you want to make a MOC using an existing profile you have to use the same motors in the same ports, even though their performance is near identical. (PF didn't need profiles so no issue with that)

This is only the case if you want to use the official Control+ profile. In their case restrictions are needed because the profile simply wouldn't work if you connect e.g. a simple M motor to the port where the steering L motor is supposed to be. If you want to make a MOC then you shouldn't use the Control+ profiles, but the Powered Up app. Yes I know you still don't have customizable interfaces etc. but it does not mean there won't be any solutions for that. Again PF didn't need profiles because it was a simple IR based system without any advanced controls, anything extra was added by 3rd party solutions. 

57 minutes ago, allanp said:

5) You can't use use the 9v motors, such as the 5x4 ungeared motor and the buggy motor (You can with PF and Sbrick and I doubt there will be another motor with the power of the buggy motor or the speed of the ungeared 9v motor)

No you can't, but while with PF IR you could physically connect a buggy motor to the IR receiver but it only provided you a fraction of the original performance. With a simple DIY or 3rd party converter cable you can run them at the same level with a PU hub as well. 

1 hour ago, allanp said:

6) Making custom creations with PU is not fun for me. I don't consider coding to be intimidating. They call it the "advanced" end of the spectrum but it's still coding for kids. I just find it boring and tedious and I have no desire to learn it. I never got into mindstorms for that reason. I like Technic, I don't like coding. They are completely different things and to have to do one to fully embrace the other is ridiculous. I wouldn't have any problem with the option to code being there, I would welcome the choice for those that do want it because choice is good, if it wasn't for the fact that there's no other, non third party option. Once there is another completely non code block based alternative that's not 3rd party then I look forward to being able to applaud it for helping to bring Lego into the 21st century, but not before. (PF doesn't have this problem and Sbrick doesn't need you to use code blocks)

That's an issue we addressed multiple times and I'm sure a solution will be provided. It still might not be perfect for anyone as it will not rely on dumb IR remote controls, but a less complicated software interface is coming. PF does not have this problem because it is a dumb IR-based system, no sensors, interactive motors, nothing. If you want to stick to that then you are welcome to use it, we are still using buggy motors that were discontinued like 10 years ago so I don't see PF going away anytime soon for simple applications. Btw if you like SBrick without coding then make sure to avoid the next generation of their app ;) 

And PU gives you a simple "dumb" control solution already - if you use the AAA hub and the remote (that technically has the same functionality as the PF IR remote) then you can control the 2 connected motors without any apps. It does not cover yet all aspects as it won't give you servo-style control for the L/XL motors but it again only depends on a fw update. 

1 hour ago, allanp said:

7) It's crazy expensive. For less money than these plastic geared Chinese PU motors I can buy a hobby grade servo motor with all steel gears, ball bearing races, enough torque to snap a Lego axle, zero backlash and fine precision control (with hundreds if not thousands of steps) in a package that would fit in a 2x5x2 brick, and it doesn't need coding to work (PF and Sbrick seem more reasonably priced)

I don't see why you should not do that if that's a good solution for you, but don't forget that hobby grade servo still requires a controller that you also need to buy. SBrick only gives you a control solution without motors, sensors etc. so it will be always more "reasonably priced". If you compare a Technic hub ($90) and try provide the same functionality with SBrick then the math looks like this - SBrick + extension cable + AA battery box + WeDo tilt sensor = $59 + $3 + $7 + $27 = $96

1 hour ago, allanp said:

8) Lack of physical controllers. Now even when I'm playing with (erm....I mean operating ) my Lego creations I'm looking at a phone screen!

That's an issue TLG will need to resolve for sure. The current controller is not sophisticated enough for advanced controls, they need to come up with a proper one that allows proportional control with joysticks.

We can run these circles over and over again, but from my point of view saying "PU sucks, PF was the king" is simply wrong. In the past 2 years I can't tell you how many times I raised concerns on several different platforms, because I did not like either what I saw. But it always helps if you try to understand the reasons behind the decisions made on the other side of the fence, and formulating constructive criticism is quite important too. Whatever we say, TLG will not revert back to PF just because "those were the good old days". AFOLs are important for the company but they are a toy manufacturer for kids in the first place, so if they develop a new remote control ecosystem then it will be kid-focused in the first place, that means providing a possibility for visual coding will get a higher priority on their list than crazy fast buggy motors, high precision servos and all these things. But I'm still sure they'll listen if we tell them what is still missing from their ecosystem for us and how that can be possibly added to make AFOLs happy as well. 

[Bartybum]

57 minutes ago, kbalage said:

You can't stack sensors and smart motors, simple as that. Since TLG wanted to add more functionality and interactivity to the system they had to go this way.

Does this mean channel distributors are not possible?

Edited June 3, 2020 by Bartybum

[Bartybum]

3 hours ago, kbalage said:

True, but running 4+ motors from a single power source would already affect their performance in the PF world as well. I don't think there are that many applications where you would connect more than 2 IR receivers to a single battery box.

I can think of a fair few that would need at least five motors to provide a playable experience for a full RC MOC. These would all need to be decked out with a gearbox that can change between operating modes, to avoid having to buy twice the amount of electronics:

1. A backhoe would need outriggers coupled to the gearbox:

• Front loader mode: drive, steering, lift arm, bucket ,outriggers/gearbox
• Backhoe mode: hinge/slewing, boom, dipper arm, bucket, outriggers/gearbox

2. A combine harvester:

• Field mode: drive, steering, PTO, spreader conveyor belt, gearbox
• Secondary mode: unloader arm, hopper lid, attachment lift, attachment lock, gearbox

3. A knuckle crane truck:

• Drive mode: drive, steering, outriggers, turntable, gearbox
• Crane mode: main boom, telescopic boom, telescope, winch, gearbox

4. A tractor with two attachments:

• Drive mode: drive, steering, PTO 1, PTO 2, gearbox
• Secondary mode: attachment lock 1, attachment lock 2, attachment lift 1, attachment lift 2, gearbox

5. Madoca1977's wingbody truck only uses one battery box, and four IR receivers. There's no space inside that thing for two smart hubs.

I could probably find even more examples but I gotta go study

Edited June 4, 2020 by Bartybum

[dhc6twinotter]

On 6/2/2020 at 5:29 PM, AVCampos said:

What do you mean? All PUp hubs (except perhaps the Duplo train) are programmable, and in the case of SPIKE, having a device permanently connected isn't required.

 

Yes, you're right.  I wasn't clear in what I was saying.  Sorry.  What I should've said is that the interface is poorly implemented.  I will admit though, I haven't used it, and my opinion is just based on what I've read elsewhere.

 

5 hours ago, kbalage said:

True, but running 4+ motors from a single power source would already affect their performance in the PF world as well. I don't think there are that many applications where you would connect more than 2 IR receivers to a single battery box. Regarding the lights TLG needs to come up with a better solution that they have currently, a "smart" port replicator with control electronics but without battery would be a possible solution. Since the connected motor/light/etc. type can be detected it is simple to restrict the type of devices to ensure the required power level is still provided.

Their difference is very similar to the PF L & XL motors when they are geared to the same speed. The PU XL motor is simply geared up internally compared to the PF equivalent (or not geared down, not sure about that).

 

I've built MOCs with 9 motors, but I only controlled 3-4 motors at a time.  I'm currently building a MOC with 11 PF motors (including seven servos), four IR receivers, three sets of PF lights and Two PF switches; all connected to two PF AA battery boxes.  I'd only have, at the most, five motors running at once, and that would be very briefly.  Building that would require four PU hubs, which would be impossible due to space.  To me, the biggest limiting factor of PU is only having 4 ports on the hub.  I love that PU can connect four hubs together, but I have never built a MOC that would have the room for four hubs.

For me to fully embrace PU, I would have to see the following:

-A way to have at least eight ports per battery box by either (1) A new hub with eight ports (even if it only allowed max of four ports powered at once), (2) separate bluetooth receivers with four ports each that can plug into a hub, or (3) an adapter that would allow port stacking on the current hubs (even if it meant the motors become dumb motors)
-Much lower price for motors, or the introduction of cheaper dumb L and XL motors
-Extension Cables (which I'm sure are coming)
-Improved PU app interface (which I'm sure is also coming)

The first two points are the most important to me.  I don't see myself investing in PU unless those happen.  I would love to have 16 ports with only two hubs.  That would be sweet.  And cheaper motors.

Just my $.02.

 

Edited June 4, 2020 by dhc6twinotter

[allanp]

@kbalage Thank you for taking the time to my reply to my rather long comment. 

I think your comments here and also the time you take to create tutorials for PU is an asset to TLG. It reminds me of when I was younger and called the customer service number to help me with an issue I was having and they directed me to the (very young at the time) online AFOL community, it's how I found Lugnet. We've been helping people with their issues ever since! Maybe that's a good reason to listen to (and not just market towards) AFOLs 

[kbalage]

8 hours ago, Bartybum said:

Does this mean channel distributors are not possible?

Dumb splitters are certainly not possible, you need to put in the required electronics to give you more ports.

5 hours ago, Bartybum said:

I can think of a fair few that would need at least five motors to provide a playable experience for a full RC MOC. These would all need to be decked out with a gearbox that can change between operating modes, to avoid having to buy twice the amount of electronics

These are valid examples, for 5 functions I'd use one AA and one AAA battery box. If there's space for a PF AA battery box and 3 IR receivers or 2 SBricks then there'll be space for those 2 PU units as well :)

But I'm sure there'd be plenty of examples that were working with PF or a PF+3rd party solution and will not be easy to replicate with PU. My own 42069 mod is like that, it had 8 motors (4 L for driving, 1 servo for steering, 3 M for the functions) and 4 PF lights ,and all these were operated by 2 BuWizz units hidden in the back of the truck. That's why I'm saying that PU might not be a solution for everyone, I firmly believe that PF and the 3rd party options will live on for quite a while. There'll be a possibility to go the interactive way with all the sensors, smart motors and advanced coding functions, or the PF way with many connected devices but less smart functions (or some with a 3rd party controller).

TLG simply cannot provide a solution that fits all needs, e.g. they decided to use a universal plug that works in all of their connected products from the dumb M motor to the advanced sensors but that means they lost stackability. That's a trade-off where the majority of their customers will enjoy the benefits, but a minority of the advanced MOCers will not be satisfied. I will also keep using both systems and try to choose a solution that is best for that specific situation. 

[Bartybum]

45 minutes ago, kbalage said:

If there's space for a PF AA battery box and 3 IR receivers or 2 SBricks then there'll be space for those 2 PU units as well :)

Surely you can understand that's a really huge assumption though. The PF and receivers can all be separated throughout the structure, whereas both PU hubs need large cubic volumes to fit. While that may be fine for, say, a combine harvester, excavator, crawler crane or mobile crane, there's going to be a pretty big struggle to fit them into a backhoe, tractor or crane truck.

45 minutes ago, kbalage said:

I firmly believe that PF and the 3rd party options will live on for quite a while.

Totally agree here. The buggy motor's prominence on the third party market is evidence of that.

45 minutes ago, kbalage said:

TLG simply cannot provide a solution that fits all needs, e.g. they decided to use a universal plug that works in all of their connected products from the dumb M motor to the advanced sensors but that means they lost stackability.

That's certainly true. I'm fine with losing stackability.

45 minutes ago, kbalage said:

There'll be a possibility to go the interactive way with all the sensors, smart motors and advanced coding functions, or the PF way with many connected devices but less smart functions

Thing is, must these really be mutually exclusive? If you split the smart hub into a separate battery box and smart receiver, suddenly they can fit in a lot more places AND you get to keep all the extra fancy functions. That alone would at least begin to take the sting off the cost of PU.

Edited June 4, 2020 by Bartybum

[kbalage]

7 minutes ago, Bartybum said:

Surely you can understand that's a really huge assumption though. The PF and receivers can all be separated throughout the structure, whereas both PU hubs need large cubic volumes to fit.

I was referring to the AA + AAA hub solution. The AAA hub is not very different from a volume perspective if we compare it to multiple IR receivers or the SBricks, especially with all the PF plugs attached. The latter ones surely can be distributed better but in most cases this can be a resolvable challenge.

8 minutes ago, Bartybum said:

Thing is, must these really be mutually exclusive? If you split the smart hub into a separate battery box and smart receiver, suddenly they can fit in a lot more places AND you get to keep all the extra fancy functions. That alone would at least begin to take the sting off the cost of PU.

We'll see if TLG will recognize the need for such solution from the AFOL community and if it fits into their production pipeline. I'm afraid their hw development is still mostly based on the demand from the projects' side (the sets being developed), and anything official that has 4+ motors will be probably big enough to house 2 Technic hubs (e.g. Liebherr), or will include a gearbox to switch between the different functions and they make it work with a single hub. Maybe it's time to push the Technic designers to come up with something relatively small and complex enough that requires this solution and try to convince the managers to turn it to an official product :)  

 

[Bartybum]

1 hour ago, kbalage said:

I was referring to the AA + AAA hub solution. The AAA hub is not very different from a volume perspective if we compare it to multiple IR receivers or the SBricks, especially with all the PF plugs attached. The latter ones surely can be distributed better but in most cases this can be a resolvable challenge.

Apologies, I must have misunderstood. Ultimately, using just one hub would be vastly preferred, BUT combining the AA and AAA hubs (if they do a receiver then that AAA hub is gonna be really good) does indeed mean that your space requirements are a little bit less demanding (even if not by that much).

[howitzer]

Something that would probably help a lot here would be separating the power source from the other electronics. Batteries are the biggest space hog in the hub, so if there was a controller with all the other circuitry+ports and it connected to the power source with a simple cable, one could envision traditional battery boxes, rechargeable batteries and even a transformer for wall socket, all of which could be located somewhere else than the controller hub. The controller hub could also be hidden inside the structure with a "button extension" to turn it on, as it wouldn't have to be accessible for battery changes like the current hub. Maybe there could even be a simple port attachment that would in essence make the battery box a dumb motor controller like the PF battery box is.

[Ngoc Nguyen]

Thank God the dumb battery box is here.

[Aris]

Dumb = rechargeable? 

[AVCampos]

Most likely it'll contain the same AA caddy as the Technic hub. And I hope so: just like people worry that app-controlled stuff will be useless in the future when the apps get discontinued, I worry that in the future any present rechargeable batteries will be discontinued. I'm glad my RCXs use AAs instead of proprietary rechargeables, otherwise I wouldn't be able to use them nowadays.

[howitzer]

I'm pretty sure it's not rechargeable, considering the reasons why TLG doesn't make every power source rechargeable already. But being dumb, it's much easier to integrate into MOCs than the smart hubs so it's a welcome addition in any case.

[Toastie]

2 hours ago, Ngoc Nguyen said:

Thank God the dumb battery box is here.

That makes me feel so much better

I'll go with @suffocation and have another beer on these very good news.

Best
Thorsten

[kbalage]

I really don't understand why it didn't get a speed regulator (actually 2 of them) like the PF rechargeable battery box, could have been much more useful.