Discuss BlueGiga Support (and Control+ activation on it)

[Sodoshi]

Adding Control+ Support ( Mistakenly posted under #58 because the hub describes as a 88012 WeDo 2.0 hub...)
Have made a repo: https://github.com/Sodoshi/SharpBrick.PoweredUp.Bluegiga
Will try and make this more generic to fit SharpBrick observables.

[tthiery]

Control+ is already supported. 88012 is the SharpBrick.PoweredUp.TechnicMediumHub in the source code. Sorry for the confusion on the labeling.

[tthiery]

Can we clarify what we are talking here. I am a bit confused.

• I think you target Control+ hardware (TechnicMediumHub 88012, TechnicLargeLinearMotor 88013 and TechnicXLargeLinearMotor 88014. These should be already supported in the SharpBrick.PoweredUp library (at least working with my hardware ;))
• I think you are working on an awesome Bluetooth Adapter for a Bluegiga Dongle
• I think you are not working on anything related to WeDo 2.0 ;)

Can you hint me, where your current obstacles are?

[Sodoshi]

When I started work on connecting up an 88012 (I bought the liebherr-r-9800-excavator-42100 kit), it refused to work with any of my existing Bluetooth adapters. After some research, it seemed the latest version of the 88012 uses BLED112 for Control+, and the only BLED112 adapter I could find was the BlueGiga. That's when my painful journey began. (The only existing code I could find to work was the S2Bot, and I wanted c#). When I use Sharp to connect to my hub, it identified as a WeDo 2.0 hub, so I got confused, so apologies for that.

[Sodoshi]

My biggest current issue is identifying ports. I can't find any code that can dynamically identify them yet, and the TechnicMediumHub ports aren't working for the motors, only for lights, accelerometer, etc.

[tthiery]

Hmmm. When you got 88012s... So the TechnicMediumHub... These work including ports and everything.

Some hints

• if you have not recently connected to the control+ app, do it now. Maybe your hubs have an older firmware version. I did that when I bought mine from BrickLink
• first, check your BT stack. By default hubs are identified using BLE manufacturer data and in a concrete offset. That might explain your WeDo 2.0 identification problem. There is an API PoweredUpHost.Create which bypasses the above problem. One of the examples use the code instead of the discovery.
• Use the cli project and type dotnet run -- device list. Dump the result here. That should expose the ports if the BLE stack work correctly.

[tthiery]

@Sodoshi I have not heard anything ... can I assist you with something?

[Sodoshi]

I'm good for the moment. I found the source of my confusion:
https://education.lego.com/en-gb/support/wedo-2/bluetooth-driver
Lego's WeDo 2.0 documentation said Bluegiga is their only 'supported' dongle, so I stupidly bought one thinking Control+ and WeDo2 need the same BLED 112.
I bought another dongle and got Control+ working with your code as-is, but I still want to revisit what I started and make Bluegiga work too (because I'm bloody-minded that way).
You can close down this issue for now. When I've got some more production-ready code together (rather than the ropy patch I made to prove things), I'll pull it for you.

[tthiery]

Awesome. I agree. I think a BLE driver with proper support for advertisement and characteristics etc... should work fine.

I will keep this open as I want to have an active communication with my consumers ;)

[tthiery]

Hi @Sodoshi ... bloody-minded 😀 opinion about whether we should put this to its well deserved closed issue state or are you continue thinking about developing this BLE adapter? Any other update?

[dkurok]

Hi, not sure wether @Sodoshi did some work on BlueGiga-BLED112-support...
I did an implementation and tested all examples - they work (under Windows; should also work on Raspberry Pi or any Linux able to run .NET becaue the Bluegiga-Dongle is just a serial-device / COM-port).
I have only one issue with it:
I tried to talk to two Hubs (Technic Medium Hubs). It seems that the HubId of a Hub is always set to 0x00 and this is somehow incorrect. I could get two Hubs working by using Hub.Configure(hubid) and setting the HubId to the actual connection (byte) which the adapter has to the hub. But this is dynamic! I have also added this example.
Are you interested in making a Push-request on my changes?

[tthiery]

@dkurok Yes, HubId is currently set to 0. I do not have multiple hubs by hand and honestly, did not investigate into the networking aspects of it. The HubId ... to my limited understanding ... makes sense once you have on BLE connection addressing a network of hubs when speaking to one of them. Kind of a mesh.

Regards HubId & Meshing: Feel free to create a second issue apart of this and we can discuss a suitable design & contribution.

Regards BlueGiga support: If @Sodoshi does not react, let us further discuss if you want to publish your code. Would be awesome.

[Sodoshi]

I'd love to see @dkurok push. I've switched to a non-bled adapter for now, but I'd happily help test.

[dkurok]

Hi, I did a pull-request now; hopefully I did it the correct way - newbe to GitHub in handling open source pojects
@tthiery : Regards HubId: I tested again and after one of my Hubs received an update of the firmware (I tried Control+-app) everything works fine now. So no need to change something with HubId; as of the protocol from Lego this has always to be 0x00 and seems to be an extension for the future where one hub can control others (so a mesh of Hubs where one is controlling others)
My eample with two Motors (part of the pull-request) now works and there is no need to assign a HubId. The connection to the correct Hub is in the responsibility of the bluetooth-implementation (commands are send to a device, which is connected on a hub which has a bluetooth connection at a given time)