Bliss

In version: Version: 2026-05-20-0052 New WeDo 2.0 hub support: The following example will change the color of the WeDo2 LED randomly every time you press on the WeDo green button (short press) Another example for the Distance and Tilt Sensors: It only supports the WeDo 2.0 Sensors and simple motor that came with the set. There is a piezo inside the WeDo 2.0 hub but I find it almost inaudible (at least for me), so I did not implement it. I can add it if someone realy want it in blockly...

In version: 2026-05-17-2324 I improved the tilt block that works for BOOST and Technic hub internal tilt sensors (Choose port "TILT") (Boost does not have axis Z). I will add soon the Accel and Gyro and Gesture blocks (Technic Hubs)... I'm not too sure about the values they give. Accelerometer give mG (milli-G) that gives a number that could be used for the tilt but I prefer the Tilt block as it give Degree of tilt... Gyro gives DPS (Degree Per Second) so I think it must detect moving or accelerating, not sure yet... From what I can find about it, they use BLE (BLE use 2.4 ghz). They did not make their protocol public but there might be people that have done some reverse engineering etc... I'm glad to know there are other alternatives but I will put this in the very bottom of my todo list for the moment.

Thank you very much for all this information and link to your work. I just found out today about the existence of Lego Dimensions... And I saw some toy pads not too expensive on marketplace around my location. I will certainly try to add support for this in Lego Blockly. Thanks also to @Toastie to bring this up...

I finally got a Techinc control+ hub with one XL and one L motors. It seems to work with Lego Blockly out of the box with all the motor blocks. But technic hub has new internal sensors to handle that I have to take care off... Stay tune for more...

I had to search for what is CaDA... If I understand well, it is non lego bricks company... I had no idea who they are... For the moment, I have enough only with Lego devices :-) Wow, I never heard of this... And after some search, I see that LEGO Dimensions pad are for Game console like WII, XBOX, PS4 etc... So they have different protocol (and cable ?) I would guess according to which console you have?

I guess you mean by USB V2 and BT V2, using the serial Interface A v2 in blockly. One with a usb cable directly to arduino (USB) and BT using an HC-05 set at 115kb on pin 0 and 1 (Using voltage divider on Arduino Tx). I did not test the BT for long I admit. But remember that if you occasionnaly hide you Lego Blockly app window, this will throttle the app and you will eventually loose connection. The blockly app must have the focus at all time. I'm using more the app in the chrome browser in its own Tab and if I switch to another tab, the device will eventually disconnect... Also, make sure you disable energy saving for your CPU and monitor. I also use a function in Javascript called wakelock to keep chrome from slowing down after idle time... I guess for the arduino (int A) the 115kb through HC-05 is not the best option... For the BLE, what did you test exactly? I'm a bit curious to know if some have tested the LPF2 blocks yet which I tested only with Boost hub and its motors and sensors... I'm missing data for the other hubs/sensors etc but I should get a technic hub soon. If you connect to the Technic hub successfully, check the chrome console (press F12). Then, Check for the unknown ioType that list all the modes available for this sensor. Technic hub has an IMU sensor I think (Inertia Measurement Unit) which is more complex than the Tilt sensor from boost and WeDo 2.0... You can copy paste in a code window here what it after the green text in the console window for new sensor IO types. I can then try to add support for it... (I think the sensor ioType is 58 (0x3A hex) and there must be many possible modes...

Lego-Blockly LPF2 driver: I added some Sensors for the LPF2 (toolbox, LPF2 -> Input) Please update to version: Version: 2026-05-14-2320 I tested with the sensors that comes with the BOOST set and also WeDo 2.0. Note that the WeDo 2.0 hub does not work with LPF2 last specification and I will do a separate driver for the WeDo 2.0 eventually, but its sensors/motor work well with LPF2 Blockly driver. EDIT 2026-05-15 In version Version: 2026-05-15-1106 The motor command angle, pos and time will wait until completion before going to next block. If you want your code to do something else while those commands execute, just put those command in a separate task EDIT 2026-05-16 In version Version: 2026-05-16-0301 The LPF2 device will be ready faster. There was a duplicate in the port information requests that made tons of requests at the beginning and I also keep a hard coded "dictionary" of the known ioType I have in hand (Boost set internal and external sensors and motors, WeDo 2.0 sensors and motors). So the code does not request "mode" information for known i/o Types. I also got a mindstorms robot inventor set but the firmware does not use the LPF2 BLE. It's using some BT like a HC-05 that makes com ports at the PC. However, I flashed the spike firmware in the hub, and now it is BLE but it uses a different protocol than LPF2... Apparantly I would have to use the PyBrick firmware to make it LPF2 compatible... I also tried to connect the Mindstorm inventor motors to Boost hub but the Boost firmware does not support the high resolution encoder of those motor. I can only use the motor Power command with those motors on the boost... The Inventor set Color sensor and also Distance sensor do not work with the boost hub tested with the Pup app... I will try later to flash the Inventor with the PyBrick fw... to be continued.

Hello @AJB2K3, Please have a look to the following post (with pictures) for all instructions: You need a USB to Serial adapter that has the DTR pin, a LED (I tested with Bright White LED) and a resistor. I personnaly preferred and tested with a USB to TTL module (FTDI) like shown in the pics. Also, I only tested with the Lego Code Pilot brick. For the Code Pilot and Scout, the codes are listed in the ScoutSDK document (Link provided in the post I linked above). I have no idea how it can be used with SpyBots... REMEMBER, Lego Blockly can only SEND VLL, not receive. Let me know how it works for you.

I don't want to ruin your enjoyment, but those battery operated BLE PUp devices autonomy is very disappointing. The motors look great, but they are power hungry... (Compared to an old 9v geared motor...) and BLE takes on the batteries too... I put 6x AAA batteries in my Boost, tested motors, sensors once in a while for a couple minutes, and within few days, batteries were drained. Apparently, the PUp hub for train is even worst. Like 30 min train running time max. With a wired Int.B, I can leave it powered 24/7... I ended up doing the power cord hack on the Boost (without damaging the hub)... I've seen some rechargeable battery pack exist for more recent LPF2 devices? but not sure which ones...

Hello all, Please update to version: Version: 2026-05-14-0204 If it does not update automatically, you can use shift-ctrl-R and if it resists, delete the cache of your browser. I fixed a bug for the Wait Until Time block. I have broken this a little while ago and just found out about it while testing the new LPF2 device... I'm actively working on the implementation of LPF2 (Powered UP, Boost, Technic Hub etc...) In this version you will find a very basic LPF2 driver. Only motor blocks are there but will add more blocks shortly. There is a lot to do... It is a big one. I have only one device for testing and this is the Lego Boost (Lego Move Hub). But I might buy a technic hub as it seems to be still available at Lego Store. I would like to get a Robot Inventor or Spike Prime set but those are so expensive these days... I hope some of you will have time to test LPF2. In the Boost, there are virual ports that are automatically defined to operate both Motor AB (or CD) synchronously. Some LPF2 devices do not support combined motors and some other hubs support combined motors but you have to create the virtual ports and it could be any mixed pair of ports.. I will add support later for this. Next step is to add some sensors (In the actual version, there is only the motor tacho feedback...) Please note: When you connect to the LPF2 device, it will connect fast enough but it takes roughly 20 sec for the device to be really ready as there are many request at the beginning to built the portInfo table... What are the LPF2 motor blocks: motor power: Run the motor at a certain power -100 to -1 for CCW, 1 to 100 for CW, 0 = Stop Float and 127 = Stop Brake. motor stop: stop motor with brake type option: 0=float, >0 = Brake. (Same as above with power 0 or 127, but added for convenience) motor speed: run motor at constant speed. If you try to slow it down, it will fight to keep constant speed until it reached the adjustable max power . Speed = -100 to + 100, 0 will brake and HOLD. You must use motor stop block to stop without hold. motor set rotation count: this is to reset the motor built in encoder value. motor angle: run motor up to a certain relative position in degree. You can use negative or positive angle. motor position: run motor up to a certain absolute position. motor run for time: run the motor for the specified time in ms at the specified speed. Note that for the angle and position block, it does not stop exactly at the specified position specially if the speed is high... But at lower speed, it is precised enough. There is a feature I did not implement but I will at least try it, it's the user accel / decel profile that is used for all motor commands that could maybe help to achieve more precision. Motor speed, angle and position blocks work only for motors with internal tacho.

Mimic interface-B, I thing I already talked about it when thinking on how to implement interface-A but no, it is not on my to-do list for the moment. I do not see the gain for such a project since you need to make hardware modifications (for example, remplacing hardware inside a dead interface B, could be the controller only or maybe also the H-Bridge etc...). For now, the Int.B (A real functional one) is working wireless with BT both on PC and Android with a HC-05 or alike with Lego Blockly. For the Wi-Fi, I could do an ESP32 bridge for Int.B as I did for Interface A (It's on my list but not a priority for the moment) but it's quite another setup and you need to use nginx on you blockly machine and it does not work on android device... You still have the Int.B ESP32 Micropython project I did and presented in another thread on this forum that make Int.B fully Autonomous like an RCX/EV3 brick. It's a Int.B driver module working on ESP32 using micropython and you can put your own program in the esp32 along with other modules like MQTT and control your Int.B with your phone and or your smart home using MQTT... BUT, the user must make his program in MicroPython. No blockly ... YET...

I added Input Counter blocks in Lego Int. A v2 and Lego Int. B as well. These are raising edge counter (0->1 only). These counter are done in the drive code of the devices so it is very fast and sync. The generic counter block is still ok but for device inputs, it might miss a pulse sometime because it is not synchronous with the input packet reading... It looks like the rotation counter but the rotation counter counts both edge 0->1 and 1->0. Example of use with a Wait Until block: Or with the use of a user defined function with output called Count1 that has an input value variable "Preset" and that output true when preset count is reached. This allow to see the accumulated value incrementing live while waiting to reach the preset:

This board should be fine to run the WebSocket Bridge. I'm using ESP32 MiniKIT myself which I like cause the 4 pins I need are all aligned together. Pins used: VCC, GND, IO16 (RX2), IO17(TX2) I re-wrote my github Readme file in https://github.com/BlissCA/lego-blockly/tree/main I added a folder called WebSocket and inside this folder there is a README_WS.md. If you are interested to test, please read the README_WS and let me know here if you have any questions. Latest version of Lego Blockly is: Version: 2026-05-07-1412 Please, use Ctrl-Shift R to make sure it loads to latest version. PLEASE NOTE: When you connect to Intertface A using WebSocket, the javascript uses "https://127.0.0.1:7890" local URL to discover any ESP32 WS Bridge alive. Since we use self signed certificate, you will see a small message at the top (In chrome, it is at the right of the address bar) that says this is not Secure. This is unarmful and will not stop Blockly to run.

For Web Socket (WiFi), it might do the job. However, ESP32 wroom is more mature for this matter. This new UNO R4 is not cheap though compared to a cheap clone Nano/UNO with a cheap ESP32 Wroom Mini. S3 has only BLE. It does not support bluetooth classic. BLE is longer range but is much slower than BT Classic. An HC-05 would be faster. However I tried ESP32 Wroom BT to see if it was better than HC-05 and I did not see much gain so I abandonned the project but it was working somehow.

Correct me if I'm wrong but your display + mega setup is for testing "Interface A" inputs and outputs only, there is no lego project program running in this setup? This is the setup we see on LVL1 website right? The version 1 of Interface A blockly driver using arduino is using LVL1 arduino code so I guess you could add the necessary code in arduino to support the touch screen but you would need to add some kind of button, on the touch screen maybe, to switch between outputs controlled by the screen or outputs controlled by blockly so they don't fight each other... However, I'm planning to get rid of v1 arduino code and replace it with v2 arduino code which is a totally different code not compatible with LVL1 as it is more like Int.B protocol in v2 version. But it does not mean you cannot integrate the touch screen to v2 arduino code... It just might be less obvious as the original LVL1 touch screen mega program would have to be modified a bit. Both versions are still avail in lego blockly but I encourage every one to start using Int.A v2 and convert their v1 blockly program to v2.... Why did I make a Int.A Arduino v2? It's to try to optimize serial requests... Every time we checked inputs in a loop, it was doing a read request to the arduino... If we check input 6 and 7 in a loop, it was 2 separate read request. In v2 arduino sends a packet with all input states (even output states). Blockly app read continuously in a separate internal routine like Interface B. In v1, LVL1 version is using TEXT commands and it takes few bytes per command. (1 byte for each characters) v2 now uses only byte opCode. Like interface B. I'm not sure it is realy faster and efficient but it feels like it is ;-)