Closed maximklakov closed 3 years ago
Hi @maximklakov ! Thanks for that issue. I will have a look on that project and maybe i can implement the BuWizz and SBrick protocols additionally. But then it would be usefull to have a layer over the protocols which have all the same methods to control motors and read in sensors
Yeah, probably some sort of a base abstract class with generally available methods like Connect, GetName or SetMotorSpeed, and more extended implementations with brick-specific methods.
Sbrick have published their protocol a while ago, Buwizz unfortunately not, as i know.
An addition; SBrick and Buwizz do not support new sensor, because they do not support neither new PU sensors, nor pu motors
I tend not to implement the Buwizz and SBrick protocols because it is currently a library covering lego protocols. I think it would be better to implement an additional library which covers the other protocols and the user who wants to interact with different protocols can then link different libraries together in one sketch. I would like to keep it separate.
For shure this would be the better decision, don't mix up different things ;-)
Lego world has two main competitors to a standard PF controls, and those are SBrick and BuWizz. They work through Bluetooth interface, and support controlling with phones or tablets. They were a great substitution for PF receivers for many years, and a lot of Lego funs has at least one of them. It would be nice if your library could also support those two - in that case you would probably cover 90% of all LEGO receivers (except various Chinese copies). The only solution, that reverse engineers their protocols I found is here: https://github.com/imurvai/brickcontroller2 But I cannot even compile and run it.