Bliss

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 ;-)

@Toastie, Wow, I knew from your other threads and posts that you don't do things halfway and this is no exception. This is a very cool setup as you can easily use USB or BT (HC-05). I'm working on a version based on the Int.A V2, but is uses WebSocket through wifi. It's using an ESP32 to make the bridge between wifi and the Arduino serial. ESP32 (WIFI) here replaces an HC-05 (BT) It still under testing and I'm not sure I will officially release it as the setup is a bit more complex to get a bit more speed and a lot more distance... The setup for the WebSocket Bridge requires: Need Wifi (goes through a wifi router. I guess everybody has wifi at home... I guess it could work with ESP32 in AP mode... I did not test this) Wire RX2, TX2 of ESP32 to TX, RX of arduino... Need nginx sofware on the computer that has blockly (small exe and conf file) Upload the Lego9750_ws sketch (which is almost the same as the v2) into an arduino uno or nano. (This is temporary as I want to adapt so it is the same sketch) Upload a ESP32_WS_Bridge sketch into an ESP32 Wroom (I use mini esp32 devkit) You must edit the sketch to enter your wifi ssid and password before you upload. Once uploaded, use the arduino IDE serial debug to get the IP address of the ESP32 Edit the nginx.conf to put this ip address. Start NGINX. Enter https://127.0.0.1 in chrome to accept security warning and get the welcome to nginx page... In blockly, select Int.A WS and connect... Use the same blocks as for Int.A V2... So as you can see, it's more setup but it's feasible. After many iterations, it's appears to work reliably but it has not been easy. So i might add the files in my github and some instructions but not sure anyone will use it :-)

@Toastie, I'm surprised because as far as I remember, @Gunners TekZone tested the arduino v1 with his lego lines program succesfully and the arduino v1 uses analog inputs for the Int.A inputs 6,7 and a touch sensor pressed was giving a TRUE = 4.5v... Unless he reversed the input in the blockly block? If I have to reverse inputs in the arduino or blockly I'll do it but this is indeed counter intuitive... Did you make a test with the real int.A yet just to make sure? Thank you for your help!

@Toastie, You want the sketch to redirect Int.A Inp 6, 7 (Arduino pin 7, 8) to arduino pin 12, 13 defined as output to drive LEDs to show input status? Why not wire LED's directly on the input pins 7, 8? Anyway, I did modify the sketch Lego9750_v2 to redirect input pins 7, 8 to output pins 12, 13. (Note that Pin 13 is already wired internally to the "L" Led on the arduino... https://github.com/BlissCA/lego-blockly/tree/main/SketchArduino Note that Lego9750_V2 is using INPUT_PULLUP for the input pins. The Int.A should already send 0v for OFF (FALSE) and 5v for ON (TRUE) (4.5?) to the arduino input pins. But if you wire a dry contact from a button or touch sensor that uses dry contact directly between ground and the arduino input pins (NO INT.A) , it will be reverse. When Touch not pressed, Input will have 5v, when touch is pressed, input will have 0v. You might prefer to use a 1K pull down resistor on a dry contact switch to have input true when a touch sensor is pressed (5v goes to one pin of button contact and other pin goes to 1k resistor that also goes to arduino input pin and the other end of resistor goes to Gnd). (Not using Int.A as I said)

Latest version of Lego Blockly has both version of Int.A driver, v1 and v2. They have their own set of blocks. You cannot use Int.A (v1) blocks for int.A v2 and vice versa. It's temporary, eventually, I will remove one of the int.A version after more thorough testing. v2 has different input pins as I said earlier Inp 06 and 07 goes on arduino dig pins 7 , 8 now. The arduino sketch for int.A v2 has only one file and it emulates int.B protocol at some point: It uses the same key phrase to connect and start a continuous packet stream... It uses Byte commands rather than text (not same opCode though)... For input counting, v2 uses same principle as Int.B. 2 bit value that the driver in Javascript handle to make an internal counter. Note that it's counting input changes (0->1 and 1-> 0).

@Toastie So, I managed to enter AT mode (heard that from you, I did not know about this setting. Default is 9600 so it was working fine with Int.B). AT Mode for HC-05: - You must use an FTDI to configure the HC-05 in AT MODE! - Then press Button on HC05 (or put enable to gnd) and Power on the FTDI AND HC-05. Led blinks slowly twice I think on HC05 to confirm it is in AT mode. - Then using Termite, you configure the port of your FTDI to 38400 baud and connect to the HC-05. - Type command AT+UART to show actual config. Then enter command AT+UART=115200,0,0. - Power cycle the HC-05... I had to google this to find how to do this procedure :-) After that, I tried using level converter but it generates too much noise. So I used the resistor divider trick for the HC-05 RX (Arduino TX) and wired the HC-05 TX directly to Arduino RX. Now, the HC-05 appears to work fine with Arduino v1 and v2 @ 115200 baud but it is slower than using direct USB... But I think it is still usable... With v1 arduino sketch, you can test the commands using Termite or equivalent terminal program by sending for exemple "PORT 0 ON" (no quotes). In windows 11, when you pair the HC-05, it creates like 3 com ports if not more... You must choose the SPP Dev. For me, SPP Dev COM17 is the one working. My wiring to Arduino Nano (Same for UNO): Power Supply 5.2v (+) goes to arduino Vin, (-) goes to GND (in my case, goes to Bread board GND rail). HC05 5v goes to Arduino 5V (NOT Vin). In my case, I wired Arduino 5V to Breadboard (+) rail and HC05 5v to (+) rail. HC05 GND to Arduino GND or GND Rail. HC05 TX goes to Arduino RX0 pin. HC05 RX goes to 2K resisor on divider. The other end of 2K resistor goes to GND. Arduino TX1 goes to 1K resistor. The other end goes to the end of 2K resistor that also goes to HC05 RX...

I might have broken things myself has I'm changing the baud rate to test... Please get the very latest version as I put back the baud rate to 115200 for the Int.A v2 and also v1. Note that the Int.A v2 has a continuous input readings happening behind the scene like Int.B, bu a bit faster. Arduino sends packets every 5 ms or so. That means that using the Input On block does not send serial command anymore. It just read the last input status given by the background packet reader... For the HC-05 problem, i'm still on it.

@Toastie, You can try the last version. Since the use of pin 0 and 1 (rx/tx) does not reboot the arduino as the USB does, the wait for "ready" was throwing an error rather than just keep going. I modified the code a little to keep going after the 3 sec boot time required for USB comm. I managed to get it to Connect using the HC-05 (and the Nano) but only with the use of a bi-directional level shifter. But the Outputs don't seem to work for some reason... I'm going to try to lower the baud... In the latest version, there is also a Int.A v2 which I'm testing right now. It does not work yet (at least on my side) with HC-05. This version uses the same output pins but different input pins. I use pin 12 and 13 for inp 6/7 but I'll changed that soon as pin 13 has an internal LED connected to it... EDIT: I replaced input pins on arduino for pin 7 (Inp 6) and pin 8 (inp 7) for the new int.A v2 version. (https://github.com/BlissCA/lego-blockly/tree/main/SketchArduino/Lego9750_V2) This new version uses a simpler byte protocol and is similar to Int.B but at 115200 baud. New version Int.A v2 works great but I had no luck yet with HC-05... I'll keep testing... But you can still use the old version in the meantime.

Hi, Did you connect the GND of the Arduino to the GND of the HC05? (And 5v as well) I think the 115200 baudrate might be a little fast... I read that for windows, 115200 could be the very max limit. I'll do some testing. EDIT: GEMINI Says: The HC-05 module's RX/TX logic levels are 3.3V, despite the module often being powered by a 5V VCC pin. The RX pin is not 5V tolerant, so a voltage divider (e.g., 1kΩ and 2kΩ resistors) is required to reduce a 5V Arduino TX signal to 3.3V, while the HC-05 TX can connect directly to a 5V RX.

I added the Interactive Slider Block (Category "Control" -> "Interactive Control"): With the blue gear, you can adjust the Min Max and Step. In this example, for Int.B, the power can be 0 to 7 step 1.

I added in the newest version, an interactive value block that allows to change values while the blockly program is running: (The number interactive value could be used in the power input of Int.A/B output block to vary the speed live, I'm also planning to add a slider block but I'm not sure yet) Using the blue gear , you can change the type of values (Number, Text, Bool and even a custom drpbox) The Boolean is interesting as it gives a checkbox.

@Toastie, I understand more now. For your test, it would have been interesting to have the number of pulses sent vs the number of pulses received (with the counter). I did some test too, with the arduino int A and also the Interface B. (But not with output wired to input) The timer function is not extremely precise as it depends of the overall Execution time. So when we put a preset of 0.05 sec it may ends at elapsed time of 0.055 and more... Even worst when preset is 0.005 s. So when requesting a 100 hz pulse, for sure you will not achieve the exact frequency for the output... Because, a task loop by itself, takes about 0.005s at each iteration... It's because of the yield time that is internal to the task loop. The yield time is important to make the system responsive but it's affecting the task loops scan time for sure. The Serial commands are also affecting to as it takes some time to execute, even if I changed the baudrates to 115200, It just improved slightly the results... The best would be to make int.A like the Interface B... I.e., internally reading continuously the inputs packet and memorize the last state. Then Blockly input instruction would just read the memory... Also, use bytes commands (opCodes) rather then ASCII commands... And maybe, count inputs inside the arduino... I'm going to modify the Int.A logic (arduino and in blockly) to optimize more...