Mr Hobbles

Actually the color sensor is officially called a "Distance and Color Sensor" and is capable of reporting distances from 1 - 25cm (ish). All you talked about is currently possible...just not through the official Lego apps. :) I'm already using coloured bricks on the track to change switches and start/stop different trains.

Well the hub only has two ports, so your options are 2x train motors, or 1x color sensor and 1x train motor. :) In any event, if you're capable of writing code, take a look at this library I've written, as it will do what you want (https://github.com/nathankunicki/node-lpf2).

That was me - it's not a hacked app, but it is a custom app/code running on my laptop. No modifications to the Lego components required at all.

No, you've confused channels with outputs. :) Buttons on the left are for output A, buttons on the right for B. There are five channels (colors), which you can cycle between by pressing the green button in the middle. So you can have 10 trains per remote.

It's actually hardcoded in the sensors firmware to only detect 10 colors - "None", Pink, Purple, Blue, Light Blue, Cyan, Green, Yellow, Orange, Red, and White. I don't know if these correspond to Lego brick colors exactly. These are the same colors as appear in the Boost app for programming. The sensor has other modes that can be activated (distance only, distance and color, light intensity), but I don't know if anyone has found one for raw color values.

Oh I absolutely agree, this is my plan too! However it's perhaps overkill for someone who just wants to make a tram go ping-pong between two points. Ps. Thanks for the kind words, hopefully some people will find the library useful.

If you take the official remote control and app out of the equation, then what you are left with is the ability to communicate directly with the hub from a Bluetooth enabled laptop/device by writing code. I've released a library to help other programmers write code that talks to the Hub (https://github.com/nathankunicki/node-lpf2). By writing code: 1) Yes, you can make a WeDo motor run continuously. (This is not possible using the official remote, it only runs for as long as the button is pressed). 2) Yes, you can drive both ports at the same time. 3) Yes...kinda. In my experiments I've noticed that the train motor runs slightly slower in reverse at the same power level. Not sure why. In my code I adjust for this by adjusting the power level up slightly when running in reverse. But yes you can have one port run in reverse at the same time as the other port running forward if you want. Also note that we have the remote figured out too, and can connect this to a laptop. So by using a laptop in between the remote and the hub we can interpret the button presses as we want and make the hub do whatever we want, in essence overriding the default remote behaviour. I personally have my train remote controlling a Lego Boost Vernie robot at the moment. :) In fact its one of my code examples: https://github.com/nathankunicki/node-lpf2/blob/master/examples/vernie_remote.js No, it does not just work by itself. It needs to be connected to a Bluetooth device that is running the logic. In my example video the hub is connected to my laptop, running some Node.js code, written with the library mentioned above. It works by: a) Hub is connected to laptop. b) Hub sends color sensor data back to laptop continuously. c) Code on laptop detects when color sensor data matches the desired colors. d) Laptop then sends new motor commands to the hub to reverse the direction. I have no idea how power consuming it is. I think @JopieK is working on an iOS (And Android? :)) app that can take the place of laptop and custom code and maybe make it a bit more normal-user friendly...

I stand corrected! And I even remember watching that video too. Oh dear. Lego should update their FAQ. :) Speaking of which, I wonder when/if we'll get answers to our earlier questions?

When using a remote, looks like no, there is a limit of 2 hubs per channel, according to that FAQ.

Well, Lego rarely tells anyone their upcoming products roadmap, so I'd expect a lot more to come shortly. We know of the WeDo 2.0 medium motors getting a general release in the App Powered Batmobile, and the lights will be available sometime soon(tm). We're still missing x-large motors, servo motors, and a more Technic-appropriate hub, to name but a few. We'll just have to see what else they've got planned. I'm personally hoping for a splitter cable, a PF adapter cable, an extension cable, and a polarity reversing switch.

Yes, and that's definitely a desired option, but at this point it's added complexity. For example despite the compatibility of Boost/WeDo stuff with Powered Up, there's no way for the average joe to take advantage of it without having fairly advanced programming knowledge, at least until Lego or the community release more apps. Someone earlier in the thread mentioned having a tram that can go back and forth between two points, essentially using the color sensor to reverse direction. Simple functionality, and highly desired, I've seen many people want to do this. The Duplo train is capable of this (out of the box!), but LPF2 is not. I wonder if LEGO could have put a color sensor into the bottom of the train motor with no added wires. I also really hope that Lego releases a easy coding app like Boost, but compatible with Powered Up, so trains can be easily programmed.

Hah, well done, I was curious about that. :) I agree - the tech in there is much more impressive/useful as it has the built in color sensor, LED, and speaker. Would be nice if the normal Powered Up hub had some of that too. Perhaps "Hub No.1", "Hub No.2", or "Hub No.3" might have? ;) I also notice on the LEGO replacement parts service that the remote is labelled "Handset No.2". I'm guessing there's another one due for release at some point? Perhaps with more joystick like controls like the Technic PF remote. Also note, I've finally opened up my library, see here if you're curious - https://github.com/nathankunicki/node-lpf2. It's a Node.js library written in TypeScript.

And a PF/9v conversion cable, and a polarity reversing cable. :)

On the remote? The LED on the hub works the same as Boost hub, but I haven't figure out how to control the remote's LED yet. The 5 ports I was talking about are what the remote reports (2 are the buttons).

The benefits of a standard protocol! LEGO has really thought this through. Pretty much guessing. When the hub connects it advertises all its ports, and what device (if any) is connected to it. The remote advertises 5 when it powers up, 0x00, 0x01, and three others. I have no idea what the other three do right now. Maybe one is the LED? But that's inconsistent to how the LED works on other hubs). One of them also has an "attached" id 0x38, which is interesting as the buttons are 0x37, so it might be some other functionality of the remote? I then decided to fire off a standard port activation message, starting at 0x00, and moving upwards if I got no notifications. Luckily, 0x00 worked perfectly. :)

Exactly. Port 0x00 for left, 0x01 for right, sensorMode 0x00. You start getting 0x45 notifications (same as color sensor), and byte 5 is the button state. Button states are: x01 up pressed, 0xff down pressed, 0x7f stop pressed, 0x00 released (Looks like 0x00 is emitted for release regardless of which button was pressed. If you want determine what button was released I guess you need to maintain state somewhere in your application as to the last pressed button). Did you manage to get the remote's LED color to change? The hub was simple, works the same as the boost hub, but the remote LED appears to be different.

Annnd I've sussed out the remote. :) Port 0x00 appears to be the buttons on the left hand side, and 0x01 is on the right. They are advertised as sensor type 0x37. Activating the sensor with mode 0x00 begins button press notifications, emitted from the remote as standard sensor messages.

Woo hoo, it's very exciting isn't it! I've uploaded a YouTube video of the simplest example I could think of:

I got my hands on the Cargo Train earlier! First thing I did, take out the Hub, and start hacking away. Things I've discovered. 1. As @JopieK said, service ID is the same. 2. manufacturerData is *different* between the powered up remote, powered up hub, and boost move hub. Byte 3 appears to be the type of the hub. Boost is 0x40, Powered Up Hub is 0x41, and Powered Up Remote is 0x42. 3. Train motor is *not* the same as the WeDo 2.0 motor! It has ID of 0x02, whereas WeDo 2.0 motor is 0x01 as previously reported. 4. I've managed to get all the Boost and WeDo 2.0 sensors working! In fact they pretty much worked out of the box, It's the exact same protocol as Boost. 5. I haven't yet figured out how to control the LED, or detect button presses on the remote. I'll be publishing my code shortly. EDIT: Also note, as a result of the WeDo 2.0 motor having a different ID, the Remote *does* behave properly out of the box (ie. app-powered Batmobile style). As long as your finger is on the button, the motor goes. When you let go, it stops.

Thanks for the tip, bought the Passenger Train, collecting on Saturday, which is two days earlier than I was hoping to get it! :) I plan to get the Cargo Train from Argos using about £50 worth of Nectar points.

Thanks for that. It does indeed look like the service UUID's are the same. And given that the local/device name can be changed by users in the official apps, we can't rely on those to tell the difference between the PU Hub and Boost Hub. I wonder if the manufacturer data is different. Re. the Batman set, indeed, just a PU Hub and 2x WeDo 2.0 motors. It explains why the remote is not bundled with it - it is not capable of driving those motors in the fashion the app does. As the WeDo 2.0 motors have the same type as the train motor, pressing up/down on the remote would increase/decrease speed, rather than only turn them on for as long as the button is held.

Could you paste the service UUID of the Powered Up Hub and Remote? :) Also the manufacturerData string if you can get it. The back of the Batmobile box did the rounds a few days ago, seems the contents are the Powered Up Hub (same from train) and two WeDo 2.0 motors.

The whole localName changes. There is also a manufacturerData string, which I assume is a unique ID for Lego and probably consistent between hubs (I'll check on my WeDo 2.0 hub tonight). I don't have a Powered Up hub or remote yet, I'm going by the information given to me earlier in the thread. But once I get one in a couple of days I'll try and see what else is different. The WeDo 2.0 and Boost Hubs are quite different in how they work (although they support mostly the same LPF2 components). WeDo 2.0 advertises with a service UUID of "000015231212efde1523785feabcd123", whereas the Boost Hub advertises with a service UUID of "000016231212efde1623785feabcd123" (Notice the 5 or 6). Also the wire protocol is quite different. You can tell this without connecting the hub, merely looking at the advertised data during discovery. @JopieK stated earlier that the PU hub and remote both advertise under the same service UUID as the Boost hub so I was hoping to rely on the localName, but given this can be changed by users, I'll have to rely on something else. After you've connected to the hub, the hub blasts a whole bunch of messages to you. One of those messages tells you about what ports are available on the device, so this will definitely be different between the hubs. But this requires connecting first, it can't be determined during discovery.

I've discovered in my testing that after you change the Boost Move Hub's name using the Boost app, it changes the advertised BLE localName. This means that there's no way to reliably tell a Boost Move Hub apart from a Powered Up Hub or Remote in code, as the service UUID's are also the same, and the local name can't be relied upon. Is there something I'm missing? I assume the Boost and Powered Up apps refuse to connect to Hubs of the wrong type but I can't test yet as the trains aren't released for another three days (local shops don't have them yet). I can probably tell the Hubs apart after an initial connection by watching the port advertisements, but that requires connecting first, then disconnecting if its the wrong type.

Hey, Slightly random question, but does anyone know if the fictional Lego train/transport company has been given a name anywhere? We've seen the double arrow with circle logo used on trains and buses over the years, but does the organisation have a name? In my head it's something like "Lego City Transit Authority", or "Transport for Lego City", but would love to know if its been stated officially. :) Cheers