Project: Programs to allow interactions between old Lego Control Interfaces (RCX, Lego Interface B, others?)

[Bliss]

@Toastie, thank you.  I hope you'll have time to test this and I'm looking forward to read your comments and suggestions too...

Why did I start this other Interface B project?

@AJB2K3 is working on a standalone version Blockly programming for Lego Interface B and RCX but still need quite some intallation...  Did not try his new exe installation package...  But I liked the idea and interface.

@maehw is designing a web UI to TEST the Interface B that is also a great project since it does only need a Chrome browser.

So all this gave me the idea to try to create an ONLINE web programming interface for MULTIPLE Lego Interface B's.

The ultimate goals being:

• No install besides having chrome or edge on your PC, Linux, OSX, Android computer/tablet.  And of course having the hardware required.
• Simple and intuitive programming language for end user.  Blockly is hard to beat and I've read that it is even used in Smart Home software like OpenHAB..

And I must admit that I have lots fun dseigning this with the help of AI.

I wasn't sure with blockly realy, having played a bit with UIFlow by M5Stack for programming ESP32's, which is blockly based and for serious big project, it might be ugly I think...
But the simplicity is unbeatable.

Then, after I had the first draft ready, I had great fun trying things in blockly to control my interface B.

And the more I add blocks and features, the more I like the Blockly IDE now lol...

I have a bunch of ideas to improve and add fonctionalities.

Stay tune for more...

Edited Saturday at 10:31 PM by Bliss

[AJB2K3]

@Bliss Is it my programming or is the rotation sensor not very accurate?

 

[Bliss]

2 hours ago, AJB2K3 said:

@Bliss Is it my programming or is the rotation sensor not very accurate?

 

Rotation sensor for me is quite accurate but has its limits.

If you turn too fast, it will loose precision. 
There are only two bits for the amount of change since last frame...
These 2 bits represent the "speed" amount and is used to increment the counter.
Increment can be 0, 1, 2, 3. 
3 is the max speed.

Also, you may have a faulty sensor...

 

[Gunners TekZone]

Well, I had a thought (it happens once in awhile )... How to link two different Interface-Bs that are running under completely different processes?

So, it turns out that a simple 9v style cable between two interface-Bs, one on an output of the 1st and the other end on an input the 2nd just works... Even if the only other thing they share is the power grid.  Which makes sense once I thought of it... One is essentially "closing the contact" of the two wires in the cable, while the other is seeing that as a simple switch.

So just for giggles, I have Bliss's blocky program taking a button press from my LegoB2, processing it as an output on LegoB3 which is wired up to my 3rd Interface-B (formerly LegoB1) running independently off it's usual ESP32, and processing my Node-Red (on an Raspberry Pi) running (amongst other processes) a MQTT lamp control flow.

Thus in a simple roundabout way, I can have Blocky running logic to control an entirely separate MQTT setup.

This is what I call FUN in my foggy moments  

Edited Monday at 04:18 AM by Gunners TekZone

[Bliss]

@Gunners TekZone,

I'm planning to add MQTT Client support to the my Lego interface B Blockly Online version eventually, if it is doable...

With MQTT Client, you should be able to exchange data between Interface B Running Blockly in Chrome and Interface B running with ESP32 and Micropython... and any other MQTT enable devices in your smarthome...

 

[AJB2K3]

23 minutes ago, Bliss said:

@Gunners TekZone,

I'm planning to add MQTT Client support to the my Lego interface B Blockly Online version eventually, if it is doable...

With MQTT Client, you should be able to exchange data between Interface B Running Blockly in Chrome and Interface B running with ESP32 and Micropython... and any other MQTT enable devices in your smarthome...

 

@Bliss Its possible using pymqtt.

[Gunners TekZone]

I don't do the IoT thing much.  I prefer to keep my home networking, as limited as it is, entirely away from the cloud.  And since I don't get out much, that works just fine for me 

My current experiment at least keeps my MQTT credentials entirely mine, no need to share with a web based application.

Edited Monday at 06:23 AM by Gunners TekZone

[AJB2K3]

I got a bit board and added WeDo1.0 to my test software. Turns out that gemini can handle code for it without problems.

[Bliss]

I added new unblocking timers in the Control Category.

Unblocking means that it will not block your "Flow" as will do a WAIT Time block.

It's very powerful and versatile but you must be carefull, especially when using it in repeat forever loop.

Every time you call "After time DO", it creates a new timer instance...

The "Named Timer after time do" version allow to name a timer and you can cancel the timer before it reaches its time preset with the Named Timer Cancel Block.

Every time you call a same Named Timer block, it restarts at 0 even if not completed a previous call.

Examples:

 
This is not in a loop, so it executes the flow from top to bottom and finishes in a fraction of second. 
This will start a timer 5 sec, and activate output B while out A stays off and finish the program immediately (prints Finished in the status window)
After 5sec the program is finished, the Output A will be activated and Output B will turn OFF!

 

  
In the examples above, you have 2 versions of the program uses a repeat forever loop with a scan time of 0.05 sec.  Left program uses the "after time do "block" and the other one uses the Named version.
The left one, if you keep pressing touch sensor on Input 1, it will create  like 20 different "after time do" instances...
The right one, if you keep pressing input 1, it will keep restarting the timer T1, thus, it will start to count the time when you release the touch sensor...

So in the DO part of this timer, someone could even think to put another repeat loop and start a separate process...  But be carefull...  It could generate write faults to the serial as it could try to send commands at the same time...
I will implement a command queue for the serial write...  will be done in the next update...

 

In the above example, the Output A is flashing on/off (0.5s on, 05s off) while you can use the touch sensor on input 1 to control independantly the output B with a very good responsivness.
EDIT: I added even more timer function to help with the Named Timer block (Timer is Done?, Timer is Running? etc)  So I updated also the example above).

I noticed that if you go on another tab in the same chrome window, the blockly program is not responsive so you must stat in the Lego Blockly tab while executing a program.
So it's better to run a program in its own chrome window...  (Keep the window maximized as it aslo slow down the program when minimized)

 

Edited Tuesday at 12:52 AM by Bliss

[Toastie]

39 minutes ago, Bliss said:

and finish the program immediately

Holly crap!

I did not have the time to enjoy your code, dam-ned. It is "written exam time" - repeating in eternal motion every semester. You know, when the grandparents die like flies and horrible diseases break out  Keeps me busy as I like as many students to pass at least.

But: Does this mean, the "flow" of the program just continues after having "read" the blocks, leaving a timer active as a fire and forget "thingy" (as long as I do not cancel it)? Remotely comparable (maybe, I am just guessing) to hardware timers used back in the days (they never cared about further code after being triggered ). Or the timers I am using in RCX byte code (OK, translated into that by NQC)?

Best
Thorsten

[Bliss]

Yes, 

So, while a WAIT time block would pause the execution of a program and resume after the time as elapsed, the "After time do" block will let the program continue after it starts. (It starts after the program "read" the block indeed)

This allow to do sort of multi tasking as shown in my last example.

 

[Bliss]

Ok, good news.

After many trials and gemini/copilot incomplete replies to my request, I managed to have a code to connect to android through an HC-05 BT/serial adapter (As my picture few post behinds).

It should still work on the other plateforms like windows, osx, linux as usual with a serial adapter or HC-05 but I had to use some filters in the JS code to allow connections on android with a BT device.

So for Android, for the moment, YOU MUST use a HC-05 or alike board.  HC-05 uses standard Bluetooth. 
HM-10 board is a BLE board and should be compatible with Chrome but I think I would need to use another API in my code like WebBluetooth or something like that which I'm not ready for now...

IMPORTANT: You must update your Chrome on Android with the latest version.

1- Make sure your Chrome is updated above version 137...
2- Pair your HC-05 Board using the key pass 1234.
3- You must use a TTL to RS232 as shown in my setup few posts before. Connect RX from HC-05 to RX on the TTL/RS232 adapter, and TX to TX...
4- Connect your RS-232 to TTL DB9 to the Interface B.  You may need a sex changer.
5- Go in chrome on you android device / tablet and open my blockly page: https://blissca.github.io/lego-blockly/index.html
6- Click connect.  It may ask you for permission which you should allow.  Then it will show you the HC-05 that you select and connect.

I tested on an Android phone, it's working but it would be way better on a tablet.

Edited Wednesday at 04:57 AM by Bliss

[AJB2K3]

On 3/16/2026 at 6:21 AM, Gunners TekZone said:

I don't do the IoT thing much.  I prefer to keep my home networking, as limited as it is, entirely away from the cloud.  And since I don't get out much, that works just fine for me 

My current experiment at least keeps my MQTT credentials entirely mine, no need to share with a web based application.

I actually have on my desk a stand alone MQTT setup that doesn’t need external web access. It runs all the software on a single raspberry pi 4 with just local network only. I built it for testing M5Stack sensors and was built from a guide in the raspberry pi magazine

[Gunners TekZone]

8 hours ago, AJB2K3 said:

I actually have on my desk a stand alone MQTT setup that doesn’t need external web access.

Same.  Mine is a RPi3b+ that runs my MQTT broker and Node-Red service.  I run it solely internal and "headless", as in no KB/display but still running the desktop with local VNC access.

Node-Red can read and control all the inputs/outputs on the MQTT connected Interface-B, and handles the "logic" of what to do and when.

[Toastie]

Folks, are we still on target regarding this thread's topic title?

As said, I believe I lost it somewhere, then came back on track with @Bliss' web solution. But now I am losing it again: Is an MQTT broker (I have no idea what it is good for, even after googling it) essential within the scope of controlling "old LEGO Control Interfaces"? Or is it more for controlling several serial (RS232, not RS485) devices, who don't have an address type thing out of the box, using one sort of master program?

If so then this broker thing somehow routes the serial packets to the target recipient? Which is fine, but I was hoping more for modern programs running on current machines which are "controlling" (i.e., are the brain) the muscle devices (i.e., Interface A+B). 

I have a different take on PBricks (CodePilot, Cybermaster, RCX, Scout, Spybot, MicroScout, NXT, EV3): These are more than "simple" sensor data providers and output boosters, as Interface A+B are. They all have a brain that wants to do something on its own. Some are not the brightest candles on the cake, but are trying hard. Even Control Centers I and II have brain. And yes, all these can be simply controlled from one master program, heck, I am doing it ion my train layout, which features all but EV3 PBricks. However, the RCX', Scouts and NXTs just receive two byte LEGO messages (ID and command) and then act on their own by interpreting the messages.

So back to my question: Is this the ultimate goal (making full use of PBrick capabilities) or does this work here focus more on "remote control" with sensor data feedback?

Sorry for asking, too many things happening here on my side at the same time.

All the best
Thorsten   

 

[AJB2K3]

https://github.com/Ajb2k3/ULI
This is my offline version and so far I have 2 interface B, 1 RCX and WeDo 1.0 all operating from the same program.
This unfortunately (I have just learned) uses Blocking commands which cause delays in the response of the program and the Interface B.
I'm looking to implement non blocking asynchronous code but my brain has stopped braining.

A broker is a light weight software that just receives and transmits messages between devices. It doesn't act on the message just sends them on.
I still have to suss out implementing the Cybermaster, spybot and others but apparently with spybot then you get PF.

Edited Wednesday at 08:41 PM by AJB2K3

[Toastie]

17 minutes ago, AJB2K3 said:

but apparently with spybot then you get PF

What exactly does that mean? The Sypbots are using "the same" byte code protocol + heavy extensions as the RCX, aren't they? I am using BricxCC/NQC to program and interact with all the supported PBricks.

PF is a completely separate protocol - the LEGOINO implementation of Cornelius Munz, running on ESPs and Arduinos, incorporates the entire PF protocol (I included in my ESP32 MulPI code). I never heard that Spybots do talk PF?

Best
Thorsten  

[Gunners TekZone]

38 minutes ago, Toastie said:

If so then this broker thing somehow routes the serial packets to the target recipient? Which is fine, but I was hoping more for modern programs running on current machines which are "controlling" (i.e., are the brain) the muscle devices (i.e., Interface A+B). 

Sorry if getting off track... Although I do believe that using a "newer" hardware, running various software that can fully read and control the Interface-B is what I currently have going...

38 minutes ago, Toastie said:

But now I am losing it again: Is an MQTT broker (I have no idea what it is good for, even after googling it)

To supply a summary of MQTT (as that is all I understand anyhow) is that it is a communications protocol that Publishes (sends) and Subscribes (receives) messages to and from multiple diverse devices.  The MQTT Broker program acts as a central distribution hub for this process.

In my case I have an ESP32 running Bliss's MQTT program for the Interface-B.  This program Pubishes (sends) out Input port data and Subscribes (receives) values for the Output ports.  I use this process via my "control flow" on Node-Red (which is independently doing other stuff as well).  

My MQTT Broker and Node-Red run on a Raspberry Pi... Thus I am using two different "modern" hardware devices and a few "modern" programming languages (Python and JavaScript) to orchestrate the Interface-B action.

38 minutes ago, Toastie said:

Is this the ultimate goal (making full use of PBrick capabilities) or does this work here focus more on "remote control" with sensor data feedback?

Personally, I am trying to do both... Control the Interface-B with anything other than Control lab on a full PC, and the RCX as a remotely controlled device under the same centralized oversight.

Thus, while I have not yet integrated such, I would like to expand my existing process to also interact with RCX.  Although I would probably prefer to use another ESP32, communicating to Node-Red via MQTT to control either a LEGO IR Tower (or just an IR transceiver) to send/receive RCX compatible codes.  Thus a button press on an Interface-B can activate an action on one or more RCX bricks, and vice versa.

Edited Wednesday at 09:12 PM by Gunners TekZone

[Bliss]

MQTT is a very popular protocol in IoT world especially smart homes...

I find it very relevant even for Lego controllers to allow them to communicate with external world...

So while developping "Drivers" for old lego stuff, if it is possible, why not integrate MQTT client as well.
I find myself this "add-on" to be great.

I have a small PC that runs Home Assistant with MQTT and Node-Red Addons...

I could use an IKEA Zigbee button to interact with my lego interface B and RCX through MQTT.

So yes, it is relevant for some of us but not mandatory to operate the Lego Bricks.  Just an amazing addon that is worth to talk about, at least a little ;-) .

 

And since I'm doing some Javascript for the Online Blockly project, I'm thinking maybe eventually to bring the Lego Interface B JS driver into Node-Red ...  
But this is another project...