veezer

@Entalyan I bumped it to v0.9.2 to get rid of those extra json print statements.

Yes, I can probably clean those extra debug messages in the next release. The way the messages work is the bricknil program talks to a web server (written using Quart, which is an async-style Flask) via a TCP socket, and the web server provides a websocket interface to the realtime peripheral updates. This should let people run the frontend code on a different machine if needed (since I want to use a raspberrypi for bricknil and don't want it getting bogged down with display updates). Also, easy enough for people to put their own favorite stack in front of that socket interface.

@Toastie thank you! That worked; was able to place an order for usd $21 with shipping from a storefront with good feedback in Europe. As far as I know the US does not charge duty on orders totaling $800 or less per day. Appreciate the tip, saved me over $30! Now I need to figure out how to get this in the Harry Potter train ;-)

Hmm, the Bricklink inventory of hubs for these prices seem to have disappeared. I shouldn't have waited to pick one up; now I'll need to fork out $50 from lego.

Coming in the next release is a web dashboard that will show the status of all the peripherals in your running BrickNil program. It's display only right now, but I hope to add control capability to this dashboard at some point too. Here's an example where the program is controlling my duplo train, with the motor ramping up at intervals, changing LED color, and displaying speed and wheel revolutions, as well as the reflectivity sensor reading.

Ah I see. "User error", halt and catch fire :-)

I don't use Windows, but the comments above make me wonder if there's some confusion about the Bluetooth standards involved. The pairing procedure to the OS only applies to Bluetooth Classic devices, which as far as I know, is not supported by the LPF2/PoweredUp hubs (or at least the Boost and train hubs). Instead, these hubs connect via BluetoothLE which does not involve an explicit and permanent pairing between the computer OS and the hub. Rather, the connection is handled when the app runs and looks for a BluetoothLE device advertising a specific service type; when the app then connects to this service, the app and hub are linked for the duration of that app session. If you're worried the hub is being "captured" by a rogue app that's running continuously, then shouldn't the LED on the hub be a solid white signaling an active link?

@Toastie as far as I know, there is no other way to update the PoweredUp Hub (aka Hub No.4) besides the Lego train/batmobile app. Yes, the future is here and pretty soon we’ll need an app to flush the toilet Maybe one of these days someone can capture a network and BLE trace of what the app is doing during the update process... some of the Bluetooth protocol fw update is documented but you’d still need to know where to grab the image from and I assume there’s some checksum validation process

Cool! Great to hear! Let me know if you spot any bugs or issues.

Just wanted to note that v0.9 is out. It adds support for using the Wedo peripherals (motor, tilt sensor, motion sensor). Also working on a web dashboard for the library, which should come out once we hit 1.0. Only thing to note is that according to @Mr Hobbles the virtual port behavior has changed on the PoweredUp hub with the new firmware, so if you're controlling two motors ganged into one virtual port, it won't work yet. I'll add support for that at some point once the Boost hub gets a firmware update or I get my hands on another motor.

I didn't even know the 0x60 command existed (it's not documented in the LEGO wireless protocol doc); I've been using the 0x51 command for all the motors like train and the boost internal and external motors (although I don't have access to the batmobile to check that) and it's been working fine all this time.

I see now that the Lego US shop let's you order all of these standalone parts (except the train motor 88011 which does show up in a search but throws an error on the product page). $50 for the Pup hub and $14 for the train motor. Not bad. https://shop.lego.com/en-US/search?q=hub

This looks awesome! It's great they added a lot of ports to this hub

Updated: Version 0.8.2 is now out, and adds support for external motors (which was the last outstanding peripheral from Pup/Boost). Absolute positioning and relative rotation are now supported.

@Entalyan Great to hear it's working! Thanks for your feedback (and @David Lechner's help) to get the ble_id working on Win/Linux. Very interesting to see how you're using it; I can see that it would be pretty neat to have Lego hubs integrated as part of a larger automation system with other devices! Are you using some other software automation tool that's controlling and sending the MQTT messages, or is it your own code? Oh, and just noticed that you probably need to add a `await q.task_done()` after you do the q.get(). while True: item = await q.get() await q.task_done() This will probably be needed to have a clean exit if you implement a 'quit' command and you have a `await q.join()` statement to close out the queue processing.

@Entalyan regarding 2), yes you're right, that line setting the log level is incorrect in the documentation. I've fixed the README to reflect the proper way, which you've already figured out. Sorry about that. Regarding 1), I think it is a Windows 10 issue. I don't have a windows box right now to debug this, so would you mind opening a bug report at https://github.com/virantha/bricknil/issues and pasting in everything that gets logged with logging.DEBUG setting? From the logs you have there, it does seem like we need to fix where the windows-specific code is pulling in the broadcast UUID.

@David Lechner I've uploaded new pypi packages based on your changes (bricknil 0.8, bricknil-bleak 0.3.1). Let me know if you see any issues.

Thanks, David! Saw your pull request adding support for Windows 10. I’ll get your additions merged and the updates into pypi later today. Appreciate the work!

Hi all, although I briefly mentioned this in a thread over in the Lego Trains sub-forum, I thought it might be useful to create a new thread to announce my new Python library for controlling PoweredUp and Boost hubs/sensors/motors called BrickNil. It's open-source and written to support the newest Python 3.7+ while taking full advantage of modern async programming features. I mainly wrote it to have a cross-platform set of libraries in Python with a clean concurrent programming interface. I've tested on Mac OS X and a Raspberry PI, although I'm pretty sure it should work on any Linux system. Win10 support was added by @David Lechner. It should support all the sensors and motors that are provided in Boost, PoweredUp, and Duplo Trains, and I hope to have Wedo support at some point soon. If anyone finds this useful and finds any bugs or has some feature-requests, please do let me know. You can find the project documentation here: BrickNil - Control LEGO Bluetooth Sensors and Motors with Python Installation available as a standard Python library: pip install bricknil Examples: look under examples/ in the github source https://github.com/virantha/bricknil And here's a quick but non-trivial example of what using the library looks like. This program sets the speed of a train depending on how close your hand is to a vision sensor, and will quit the program if you wave your hand more than three times in front of it. from curio import sleep from bricknil import attach, start from bricknil.hub import PoweredUpHub from bricknil.sensor import TrainMotor, VisionSensor from bricknil.process import Process @attach(VisionSensor, name='train_sensor', capabilities=['sense_count', 'sense_distance']) @attach(TrainMotor, name='motor') class Train(PoweredUpHub): async def train_sensor_change(self): distance = self.train_sensor.value[VisionSensor.capability.sense_distance] count = self.train_sensor.value[VisionSensor.capability.sense_count] if count > 3: # Wave your hand more than three times in front of the sensor and the program ends self.keep_running = False # The closer your hand gets to the sensor, the faster the motor runs self.motor_speed = (10-distance)*10 # Flag a change self.sensor_change = True async def run(self): self.motor_speed = 0 self.keep_running = True self.sensor_change = False while self.keep_running: if self.sensor_change: await self.motor.ramp_speed(self.motor_speed, 900) # Ramp to new speed in 0.9 seconds self.sensor_change = False await sleep(1) async def system(): train = Train('My Train') if __name__ == '__main__': Process.level = Process.MSG_LEVEL.INFO start(system) And here's a quick video of where it's being used to relay button presses from the PoweredUp remote to control Vernie the Robot (Boost hub). And of course, I can't say enough about how helpful all the posts on Lego hardware in these forums have been to getting this library to work, and in particular the inspiration from the NodeJS PoweredUP library that forum member MrHobbles has created.

@Lok24 I was commenting on the fact that someone mentioned that the commands setting acceleration and deceleration profiles (0x81 subcommand 0x05/0x06) apply to the train motor. I don't believe that is the case.

After a fair bit of experimentation, I actually don’t think the train motors support the accel/decel profiles. It was fairly straightforward to get those working with the Boost hub internal motors, so I don’t think it’s an issue with the commands. Rather, I think the train motors are rather dumb; they can’t report back speed and tach position like the the other motors. Might be one of the reasons the built in ramp profile commands return errors with train motors. I’d love to be proven wrong though!

[edit] So, I probably shouldn't have picked a name for this project at 3am without doing a search first. I didn't know about the other Blue Brick layout software. So, I've gone ahead and renamed this project to BrickNil, and updated the links below [/edit] Just wanted to mention that v0.1 v0.3 of my BlueBrick BrickNil Python async library for interfacing to Boost and PoweredUp Hubs is now published, open-source licensed under Apache2.0. Source is on github, and docs are at https://virantha.github.io/bricknil/ Still early days, and only on Mac OS X so far, but supports all the Boost and PoweredUp Train motors and sensors I could find. I did spend some time figuring out how to do arbitrary mode combinations on the sensors, so I thought I'd share some of that back here since I learned so much from everyone's contribution on this thread. This is really useful when you want to, for example, get the raw 3-axis accelerometer data plus the tilt data from a Boost hub at the same time. There's some extra information (still incomplete) on each sensor I was able to get by querying the hub based on the protocol, and that lists more information on the specific mode combinations supported here: https://virantha.github.io/bricknil/lego_api/lego.html All the information is what's reported back from the sensors directly (in other words, no interpretation from me). Some things I don't understand yet, but here's how I combine multiple mode updates, taken from my BlueBrick BrickNil API documentation, after much experimentation and parsing of the official LEGO wireless protocol: * **Multiple capabilities** - This is more complicated because we need to put the sensor port into CombinedMode Send a [0x42, port, 0x02] message to lock the port Send multiple 0x41 messages to activate each capability/mode we want updates from Send a [0x42, port, 0x01, ..] message with the following bytes: 0x00 = Row entry 0 in the supported combination mode table. (hard-coded for simplicity here because LEGO seems to only use this entry most of the time) For each mode/capability, send a byte like the following: Upper 4-bits is mode number Lower 4-bits is the dataset number For example, for getting RGB values, it's mode 6, and we want all three datasets (for each color), so we'd add three bytes [0x60, 0x61, 0x62]. If you just wanted the Red value, you just append [0x60] Send a [0x42, port, 0x03] message to unlock the port Now, when the sensor sends back values, it uses 0x46 messages with the following byte sequence: Port id 16-bit entry where the true bits mark which mode has values included in this message. (So 0x00 0x05 means values from Modes 2 and 0) Then the set of values from the sensor, which are ordered by Mode number (so the sensor reading from mode 0 would come before the reading from mode 2) Each set of values includes however many bytes are needed to represent each dataset (for example, up to 3 for RGB colors), and the byte-width of each value (4 bytes for a 32-bit int)

Thanks for all the great info in this thread, and the wonderful NodeJS library from @Mr Hobbles. I've been working on an async-event-based Python library that presents a similar interface to control these hubs that works under OS X (should work under Linux too); if there's any interest, I can probably spend some time open sourcing it once I get it a bit more polished.