Entalyan

I chose to use 4DBrix sensors and motors for my layout, at first because of the documentation they provided, and later because of the excellent service the EU distributor provided. It might be a little bit more expensive (although I haven't checked before now, it was not prohibitive in any case), but the documentation for use with Arduino, and the availability of the nControl software, sealed the deal for me. I hope this business model works out for them, and someone will provide these components at some point, since I will need more at some point in the future.

A thing to take into consideration here is that while WiFi as a protocol will support loads of devices, not all routers do. As I understand it, they support up to a certain number (related to the amount of channels), and then start switching (quickly) between them. You might need to get more professional routers (the enterprisey ones can handle hundreds of devices), and take care to not require super-fast latency. What I am using myself is just a wired solution for most devices, except for the trains. The sensors, switch motors and LEDs are all just wired into Arduinos, which are then wired into a PC or Raspberry PI, which will then handle the remote control. This limits the amount of devices controlled over BlueTooth. Right now I am using BlueTooth for the trains, but I just bought some ESP32 chips that support both BlueTooth and WiFi, and are small enough to mount inside of a train (similar to the Wemos D1 in the posted video, which is an ESP8266, the predecessor to the ESP32, I think). I was thinking of trying to write a WiFi<->BlueTooth bridge for them at some point, so they could act as stand-alone controllers. This is a long-term project though, since interfacing with the Lego stuff over BlueTooth proved a bit too difficult / out-of-my-wheelhouse the last time I tried it (I use bricknil, a Python library, right now), as well as working on a better control tool to run on the main PC.

Ah cool, I will see about upgrading my main project to 0.9.2 as well then. It seems your own wishes are pretty similar to mine, regarding the raspberry running the controlling code. This is why I bolted on the MQTT system, which I could later replace with the websocket system. I am not entirely sure if I want to yet, because it would be 'yet another protocol' in my stack, but it is nice to have the option.

That is pretty cool! Since I am using your library as a backend controller, I don't really need a dashboard myself, but I do need ways to interact with the python script (that wraps your library) from my own application. A web/REST API would be great for that, and is probably already underneath the dashboard, or relatively simple to bolt onto it. By the way, in my main project I am still using 0.8.2, but on a test machine I upgraded to 0.9.1. On the test machine the messages printed to the screen at the INFO level suddenly contain JSON messages besides the regular messages. Is this working as designed? I was using the screen messages to feed information back into my own front-end, and this, while easier to parse, required me to change the input filter a bit.

Great that we might be able to order these directly. The prices did strike me as a bit high, so instead of a separate hub+train motor (for converting an old 9v train to PU) I will just buy a few passenger trains. Just a little bit more expensive, but you get a whole train and some track :) I do hope more of this stuff becomes available though, since I would like to use the distance sensors and servos for automation, and I'ld prefer not to have to invest in the older PF stuff (since I am just starting out).

@veezer Thanks for the tip regarding the task_done(). Building a clean exit hasn't been a top priority so far, I had enough trouble getting it running in the first place ;) As for controlling this using MQTT: I will first write my own application for this, since that seems easiest. I only really started this whole project 2 weeks ago, and it involves a lot of things I am unfamiliar with (Python, integration async libraries with synchronous ones, Arduinos, wiring, etc.), so I am taking baby steps. The idea is to build a slowly growing ecosystem out of small parts, so I don't burn out on any single task. Doing all the things below (and whatever else I think of) in 1 single massive project would probably put too much pressure on it, making it feel more like work and less like a hobby. My list of ideas include (in no particular order): Using NiFi to control the logic Using Kafka instead of MQTT Develop web or tablet app (instead of desktop) Put NFC chips on the trains and cars to identify then while they pass Automate a 'railyard', where I can reconfigure trains using NFC chips Put the whole thing in containers on Kubernetes Hosting the control software in the cloud for remote access And that is just for the soft/hardware part. Of course I also want to add more trains and buildings in Lego ;) By the way, I updated to 0.8.2, and my regression test was successful. The functionality I was using is still working. I have no way to test the new features though.

@veezer As discussed on github, the new version now works perfectly with the new ID selector, thanks! :) I will be moving the code onto a linux box in the future, then I will test there. I have also gotten MQTT set up to work with the library, so the basic version of what I want this code to do is ready: import logging import paho.mqtt.client as mqtt from curio import UniversalQueue, sleep, spawn from bricknil import attach, start from bricknil.hub import PoweredUpHub from bricknil.sensor import TrainMotor from bricknil.process import Process def on_message(client, userdata, message): #print("message received " ,str(message.payload.decode("utf-8"))) q.put(str(message.payload.decode("utf-8"))) async def start_MQTT(): client = mqtt.Client("P1") client.on_message=on_message client.connect("127.0.0.1") client.loop_start() client.subscribe("trains/pup/cargo1") q = UniversalQueue() @attach(TrainMotor, name='motor') class Train(PoweredUpHub): async def run(self): self.message_info("Running") m = await spawn(start_MQTT) self.message_info("Started MQTT") while True: item = await q.get() if item is not None: if item == "start": await self.starttrain() if item == "stop": await self.stoptrain() async def starttrain(self): self.message_info('Increasing speed') await self.motor.ramp_speed(80,5000) async def stoptrain(self): self.message_info('Coming to a stop') await self.motor.ramp_speed(0,1000) async def system(): hub = Train('GreenCargoTrain', ble_id="90:84:2B:0B:DD:BF") if __name__ == '__main__': logging.basicConfig(level=logging.INFO) start(system) It is still ugly and could use some professionalization, but I will get to that later. Using this library and code I can control my trains using MQTT, which I chose to automate all my devices (sensors and switches mostly right now). This way I can create a simple UI interacting only with MQTT that can fully automate my train layout. I thought you might like to know what people would be using this for ;)

Hiya, thank you (both) for this library! It works great (with the 0.8 version) on Windows 10. Once I get a grip on how the async/await pattern works in Python/curio I will definitely add this to my project (I am trying to send commands to my trains through MQTT so I can easily integrate it with other IoT-like devices). I have 2 minor remarks on the project and/or documentation, and they are: 1) On my machine (Win10) the UUID is not actually showing, instead a MAC-like address is given. This has made it hard to select a specific device. From inside the main run() method in Train I have added self.message_info("BLE_ID:"+self.ble_id) which outputs INFO:GreenCargoTrain.2:BLE_ID:90:84:2B:0B:DD:BF I have tried setting the logging to DEBUG, and using all the UUID's that are in there, including the Device advertised UUID, but no luck. For example, without setting a specific UUID it finds the train: INFO:BLE Event Q.0:checking manufacturer ID for device named Unknown for HUB NO.4 INFO:BLE Event Q.0:found device Unknown INFO:BLE Event Q.0:Device advertised: {'00002a00-0000-1000-8000-00805f9b34fb': <Windows.Devices.Bluetooth.GenericAttributeProfile.GattCharacteristic object at 0x071A27D0>, '00002a01-0000-1000-8000-00805f9b34fb': <Windows.Devices.Bluetooth.GenericAttributeProfile.GattCharacteristic object at 0x071A2D50>, '00002a04-0000-1000-8000-00805f9b34fb': <Windows.Devices.Bluetooth.GenericAttributeProfile.GattCharacteristic object at 0x071A2D70>, '00002a05-0000-1000-8000-00805f9b34fb': <Windows.Devices.Bluetooth.GenericAttributeProfile.GattCharacteristic object at 0x071A2A70>, '00001624-1212-efde-1623-785feabcd123': <Windows.Devices.Bluetooth.GenericAttributeProfile.GattCharacteristic object at 0x071A2870>} INFO:BLE Event Q.0:Connected to device HUB NO.4:90:84:2B:0B:DD:BF But when putting any of those UUID's in there (the first one in this example) I get: hub = Train("GreenCargoTrain", ble_id="00002a05-0000-1000-8000-00805f9b34fb") INFO:BLE Event Q.0:checking manufacturer ID for device named Unknown for HUB NO.4 INFO:BLE Event Q.0:Address 90:84:2B:0B:DD:BF is not a match This feels like it might be a Windows issue... 2) The following line in the example does not seem to work on my machine. Process.level = Process.MSG_LEVEL.INFO I changed it to: logging.basicConfig(level=logging.INFO) That does work, and I noticed you have the same code in other examples on website.

If you ever do decide to open source it (or part of it), let me/us know. I am having some issues getting my own application to properly connect to the PUP hub in my train, and would like to see how you solved that. The Bluetooth API has so far been quite annoying to wrangle into something useful :p

I agree, I would like to run the 9V as well, but that will have to wait. The PU/PF system is a lot cheaper and easier to get started with right now. I am more comfortable dealing with software than I am with electronics, so being able to control the trains using software without having to do too much wiring is a big help. I did order a bunch of Arduinos, which is the closest to doing any hardware work I have ever done, so having to regulate voltage on a track seems a bridge too far right now. Still have to wait a while before they get delivered though, so started on writing a UI for my planned MQTT-based control mechanism. While I wait for the electronics to arrive I can make some progress on that, so that when they are here I can focus fully on getting them working.

Hi everyone, I just joined both this site and the hobby in general. I wanted to get into Lego trains for a while now, and this site has been a great resource for inspiration so far. I am planning to work on automating my layout as far as possible, and I found some great information here, so I decided to join up. I don't have a lot to show yet, since my entire kit exists of an old 9V train and related sets, and the new PU cargo train, but this is likely to soon expand. When I have something to share I will do that here, but for now I just wanted to say hi.

Thank you very much for publishing this project. The mere fact that it exists has convinced me to choose the PU system as my platform for the trains, which made the price of starting out go down dramatically from trying to get my hands on PF or 9V components. I used this tool to connect to my trains and it worked immediately, so I am very happy. While I am waiting for more parts to arrive (Arduinos, 4DBrix switch controllers and trains) I will be using this to control the trains remotely. Right now there is no API or other possibility to access the tool's functionality from an external program, am I correct? Since I will be using some custom parts (4DBrix switch motors with Arduinos) I want to be able to script against all my components, so will probably be writing my own custom code, and being able to use your tool as an intermediary would save a lot of time :p