GianCann

@Mr Hobbles have you seen the H/W Network command? I discovered that the Remote Control can act only as RC or Role Peripheral... So, is the Hub that act as Central Role when connected to the Remote Control. In other words, is the Hub that subscribe the Port Value notification from the remote control to obtain the status of the buttons.

No. The exception is present also without send any message. The difference it's made only by the presence (or not) of the NOTIFY property.

This is my code to try the emulation of a PUP Hub https://github.com/GianCann/ATS/tree/master/ESP32_LEGO With this code I get that the LEGO App connecting to my ESP32 and send some initial requests to the Hub... But there is a problem: The LEGO App crash with the NOTIFY property set to the characteristic. In you remove BLECharacteristic::PROPERTY_NOTIFY from the characteristic's constructor (line 93) the LEGO App works but it's not able to receive notification from the Hub (so, isn't useful).

Shinichiro has published many other informations here: https://github.com/bricklife/LEGO-Mario-Reveng/

Ok... but if you want to start from the "basic first" I think that first step is to explore the LWP implementation in the Hub. Your BLE code it's not complete and if you add PROPERTY_NOTIFY to the characteristics (as same in the original hub), the result is a crash of the LEGO App one moment after established the connection. If your project is based on the idea of emulation of a Technic Hub (with the opportunity to play with him trought LEGO App or remote control), the starting point is the investigation of the things that are new. 1) Control a LEGO Hub with LWP is a new thing? No... There are many, many example! 2) Control a PUP sensor/motor is a new thing? No... There are many example! 3) Act as LWP peripheral is a new thing?... Uhmmm! Yes... at least, in the past two year that I use deeply the PUP system, I don't have seen any project about this. Only your sketch of code (that not work when you go beyond the simple connection-established). So, from my point of view, before talk about hardware/RTOS/dual core and so much, I think that it's not so useful to go forward until you have explored THIS "basic first" point. The LWP compatible mode is the only and very "killer feature" of your idea. I think you are aware of it. Are you sure that this thing can really work?

No confusion guys... I've only added some information to the discussion. Yes, @ruppie... Later I publish the code to manage the color sensor from a hardware other than the smart hub. @Mr HobblesHobbles I think the remote control can work both as a peripheral and a central role (in the LWP documentation we talk about this type of device). Now that I have an idea (and a basic project) of how to emulate a Smart Hub, I will try to see if I can also connect Remote Control. I'm still on vacation for a couple of days, and I haven't brought all the material to "play" with me: I really miss the Remote Controller!

This is the complete initial handshake from Hub <-> App. (I have used a City Hub to make some test, updated with the last LEGO firmware) Note: values are in decimal When the BLE connection is done between the devices, the hub send this data to the other device (app or remote control): (in red: common header + message type, in black: payload) Hub > (5 0 4 0 0) > Hub Attached I/O (Port 0, Detach I/O) Hub > (5 0 4 1 0) > Hub Attached I/O (Port 0, Detach I/O) Hub > (15 0 4 50 1 23 0 0 0 0 16 0 0 0 16) > Hub Attached I/O (Port 50, Attached I/O, TypeID 23 = Hub Light) Hub > (15 0 4 59 1 21 0 2 0 0 0 2 0 0 0) > Hub Attached I/O (Port 59, Attached I/O, TypeID 21 = Battery Current) Hub > (15 0 4 60 1 20 0 2 0 0 0 2 0 0 0) > Hub Attached I/O (Port 60, Attached I/O, TypeID 20 = Battery Voltage) Now, the LEGO App send these informations request, obtaining relative replies from the hub: (in red: common header + message type + operation type [alway 0x06: Update-upstream], in black: payload) App > get HW Version: Hub > (9 0 1 4 6 0 0 0 1) > to be decoded... App > get FW Version: Hub > (9 0 1 3 6 0 0 2 17) > to be decoded... App > get Radio Version: Hub > (12 0 1 9 6 50 95 48 50 95 48 49) > 2_02_01 (is as string???) App > get Manufaturer Name: Hub > (20 0 1 8 6 76 69 71 79 32 83 121 115 116 101 109 32 65 47 83) > LEGO System A/S App > get Battery Type: Hub > (6 0 1 7 6 0) > Normal battery type App > get LWP Version: Hub > (7 0 1 10 6 0 3) > LWP 3.0 App > get Primary Mac: Hub > (11 0 1 13 6 144 132 43 12 12 18) > 90:84:2B:0C:0C:12 And finally, the LEGO App send these informations request, subscribing for further notification of values changes App > get & subscribe Button State: Hub > (6 0 1 2 6 0) > Button state = False App > get & subscribe RSSI: Hub > (6 0 1 5 6 0) > RSSI = 0 (Maximum level) App > get & subscribe Battery Voltage: Hub > (6 0 1 6 6 100) > Battery at 100% (note: I have used fresh battery!) App > get & subscribe Adv. Name: Hub > (14 0 1 1 6 83 109 97 114 116 32 72 117 98) > Smart Hub So, @ruppie, now you have a new piece to step forward

Ok, this is what the App ask to the Hub: Request the actual status and subscribe notification for these alerts (0x03 > MSG_TYPE Hub Alters): 0x02 High Current 0x04 Over Power Condition 0x01 Low Voltage 0x03 Low Signal Strength After this, the App request info about these Hub properties (0x01 > MSG_TYPE Hub Properties): 0x04 HW Version 0x03 FW Version 0x09 Radio FW Version 0x08 Manufacturer Name 0x07 Battery Type 0x0A LWP Version 0x0D Primary MAC Address And request value/subscribe notification for these other properties: 0x02 Button State 0x05 RSSI 0x06 Battery Voltage 0x01 Advertising Name So, the "fake HUB", at least have to respond to these information.

I had a few minutes to work with the PC. This is the first series of message sent form the LEGO app to the "Fake HUB" (I used an ESP32 ATOM Matrix from M5Stack) Note: I have removed from the output the first two bytes (message lenght and Hub ID) of the Common Message Header. So, the leght of the entire message received on BLE characteristic is specified in "Rcv x bytes", and I report only the useful information 10:25:49.997 -> Starting BLE work! 10:25:50.646 -> Characteristic defined! Now you can read it in your phone! 10:25:59.626 -> Device connected 10:26:00.339 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x2(�) 0x1(�) 10:26:00.339 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x2(�) 0x3(�) 10:26:00.339 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x4(�) 0x1(�) 10:26:00.339 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x4(�) 0x3(�) 10:26:00.373 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x1(�) 0x1(�) 10:26:00.406 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x1(�) 0x3(�) 10:26:00.406 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x3(�) 0x1(�) 10:26:00.406 -> Rcv 5 bytes : MSG_TYPE=0x3 PAYLOAD=0x3(�) 0x3(�) 10:26:00.406 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x4(�) 0x5(�) 10:26:00.406 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x3(�) 0x5(�) 10:26:00.440 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x9( ) 0x5(�) 10:26:00.440 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x8(�) 0x5(�) 10:26:00.474 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x7(�) 0x5(�) 10:26:00.474 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0xA(�) 0x5(�) 10:26:00.474 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0xD( ) 0x5(�) 10:26:00.508 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x2(�) 0x2(�) 10:26:00.541 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x2(�) 0x5(�) 10:26:00.541 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x5(�) 0x2(�) 10:26:00.541 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x5(�) 0x5(�) 10:26:00.541 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x6(�) 0x2(�) 10:26:00.574 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x6(�) 0x5(�) 10:26:00.574 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x1(�) 0x2(�) 10:26:00.574 -> Rcv 5 bytes : MSG_TYPE=0x1 PAYLOAD=0x1(�) 0x5(�) After this series of command, I tried to "change" the name of the HUB (only to send command, of course) with the text LEGO 10:26:20.523 -> Rcv 9 bytes : MSG_TYPE=0x1 PAYLOAD=0x1() 0x1() 0x4C(L) 0x45(E) 0x47(G) 0x4F(O) So, the communication between the App and the fake HUB works. I also tried to simulate the sending of a simple motor drive command but this I have not received. Probably it is necessary to respond first to the various commands that the App has sent (the first are for the subscription of some alerts).

In the first post you have declared that you haved successfull connect the Powered Up App with your "custom" HUB that emulate BLE profile of a smart hub. In theory, at this point, you can connect also a PU Remote Control. Don't care the fact that Control+ App don't connect (or better, don't work) it they don't find a specific configuration on device's port. Do you have a remote control to make a simple test?

I think it's possible to do @Mr Hobbles

Other useful source of information: https://github.com/JorgePe/BOOSTreveng and https://ofalcao.pt/blog/series/sniffing-the-lego-interactive-motor (the entire blog of @MajorAlvega is a interesting source for LEGO and electronics fan)

In this moment I am on the beach without my PC so I can't send the code of my simple "color sensor reader"... in the meantime I try to reply to your question (send via PM) about the LEGO UART protocol: After that the sensor has sent his "presentation data", the hub reply with an ACK byte, close the communication at 2400 bps and reopen the channel to maximum speed trasmission declared by the sensor in the presentation data. From this point and beyond, the sensor start to send his data for each value change and each time the hub required this wich a 0x02 byte (SYNC) (if I remember well, every 100ms). The sensor/motore can have several "working mode" (listed in the presentation data) and the hub can switch to another mode sending a specific message to sensor/motor. I forked the technical-info from Pybricks project, adding some other info (I also made a pull request to merge with the original source): https://github.com/GianCann/technical-info/blob/master/uart-protocol.md Take a look here, and if you have any question, ask without problem ;)

Ok, this is very comprensible. However, the Bluetooth communication part is probably the easiest thing to implement. The "big" problem is managing the UART protocol simultaneously on multiple ports, as well as the more complex management of individual motors/sensors. In any case, if I can help you I am here ;)

Hi @ruppie (I have read your PM, but I'm in vacation and I'm not so reactive to reply). I understand what you want to do, but I don't understand the need since there is already hardware designed in the smallest details and, above all, with a very small dimensions. What is the advantage that a different hardware could offer? Especially now that there is an alternative firmware for the original LEGO HW that can easily extend the entire Powered Up ecosystem? Obviously I will provide you all my (little) knowledge accumulated in these months, but I don't find your project very stimulating. The advice, however, is to study the LEGO hardware and the Pybricks firmware to make the most of this combination. Tell me more why you want to make new hardware compatible with LWP (as a BLE server device) that is useful beyond the simple "I did this" Note: I don't know what your skill is in developing on embedded systems. I can only tell you that, by studying the Pybricks sources every day (to try to learn something new), what you want to achieve is very, very complex.

The "action bricks" works well? When the train goes over the action brick, the train react to these? Only the sound is the problem?

New info from Shinichiro: Current status.. Port 0: 0x47 Accelerometer & Gyro? - Mode 0: Accelerometer (XYZ) - 3 bytes - Mode 1: Gyro? - 4 bytes Port 1: 0x49 Color & Barcode Sensor - Mode 0: Barcode & Color Index - 4 bytes - Mode 1: RGB Color - 3 bytes Port 2: 0x4a Costume Sensor - Mode 0: Costume - 6 bit Port 3: 0x46 Game Information? - Mode 0: ?? - Mode 1: ?? - Mode 2: Game start, Goal, Coin, Sleep, and more - 4 bytes

Try this https://controllab.io/

No. Not at this time.

Impossible... when the hub is connected to Chrome, the Bluetooth button change his function to "Disconnect from hub". Paired not mean that the hub is "controlled" by code.pybricks.com Read here: https://github.com/pybricks/support/issues/49 @Lok24 read also here: https://github.com/pybricks/support/issues/74

Yes, I can confirm. But isn't Pybricks related. It's a BLE "problem" (I hava same problems also with original firmware). Two hubs in the same time, but in different Chrome windows? Can you explain better?

Usually, LEGO use a CC2640 (sure in City and Technic Hub)

Shinichiro has wrote a post on LEGO PoweredUp Community. Tilt sensor? Mario has a tilt sensor inside. We waiting for other info at soon...

Shinichiro Oba, on Facebook, has published this info about the new LEGO Mario set: Just got my set of LEGO Super Mario 71360 in Japan! It seems that the LEGO Mario is a new device of Powered Up Platform because it supports LEGO Wireless Protocol. https://lego.github.io/lego-ble-wireless-protocol-docs/ System Type and Device Number: 0x43 Internal IOs: Port 0: Unknown IO Type (0x47) Port 1: Color and Barcode Sensor? (0x49) Port 2: Unknown IO Type (0x4a) Port 3: Unknown IO Type (0x46) Port 6: Voltage Sensor (0x14) Yoshihito Isogawa has published this video:

Yes, Right.... I forgot about this motor ;)