Cosmik42

Are you talking about supporting this?

V1.5 is out - 08/21/19 ---------------------------- - Control+ Hub - Implementation complete, including new L + XL Technic motors - Fix a bug with EV3 preventing the use of more than one sensor at a time - Fix a UI bug related to the Section part of the Self-Driving Module. That section now properly redraws after window resize. You can download the build here: https://www.dropbox.com/sh/o3i9653vwx755ps/AABfxfpL_4SeoBS4HyCVZLT_a?dl=1

Hi Didicas, So the fact that you have 4 all the time is the main issue here. The program believes a train is passing by when the value is below 5. So basicaly the program is confused because sensor triggers where he believes no train should be at. I could try to create a custom build to validate this theory with you. Will write you on PM.

This was SUPER useful! I only have a single sensor, so you playing around totally put me on the right track. Given what you describe, I believe I have found the source of the issue. Will send you a private build for you to test.

This is mostly what 1.4 implements!

It looks great!

Just refreshed the images which expired a long time ago.

Also, I just refresh the tutorial for the self-driving module. Check it out:

Ok, so you have fixed the first problem. 2 reasons why you have issues: - 3 sections for 2 trains can be problematic. Try with 1 train first. - Unfortunately I was never able to have WeDo 1.0 work properly with SBrick. First ensure a super fresh battery. The number 4 when no train is here is too low. It should much higher. Ultimately I recommend you use WeDo 2.0 hubs if you can.

This seems to be your problem. Click configure on your train, switch to Train Motor. If it is already like this, switch to something, close, reopen and switch again to this setting. Let me know.

Alright V1.4 is out! - Includes a way to limit the devices capable of connecting : * Only devices from a project. * Only devices from a global list. - I fix the latest Boost Hub firmware update issue by fixing the correct port Ids for that version. - Self-Driving Tutorial images have been fixed. Link to the latest version: https://www.dropbox.com/sh/pvwv4czhueadlb3/AAAif-h-vPGz7Q1w3iwZMFkVa?dl=1

I will try to repro your issue. There shouldn't be any issue for this kind of scenario so I need to investigate.

I have ordered that 4x4 set to get my first Control+ hub. Should have it this week and will try to implement before next Saturday. I confirm this is fixed. Will release in 1.4!

Hi everyone, I sincerly apologise for having been away for so long. On the pro side of things I am the CEO of a company that is a major growth, and have left me with no mental and physical time to engage with this project. However, I plan on spending Sunday 18th all day to catch up with it: - Implement MAC-Address limitation. - Clean it up and share it with the community. I am sure that once my code is available to all, the community can take it to the next level. As for NXT, it is not implemented and Jetro is right, I connect to EV3 via standard bluetooth. Thanks for your patience!

Here is what you are looking for (Port.Colors) public enum Colors { BLACK = 0, PINK = 1, PURPLE = 2, BLUE = 3, LBLUE = 4, CYAN = 5, GREEN = 6, YELLOW = 7, ORANGE = 8, RED = 9, WHITE = 10, NONE = 255 }

The is no software (BAP side) limitation to the number of hubs. Only hardware/firmware.

Sorry you had a bad experience with it. I never attend convetion and even though this was discussed previously, I indeed never provided a solution for it. I will see what I can do.

So here is the official build without the Alpha mention. Thank you so much everyone for the super reactive testing. I will update the first page to officially put this new version at the top of the stack. Latest Build: https://www.dropbox.com/sh/q4yhiyfgrtd3udx/AAB1nrm2637Ix4J2r40tXLFOa?dl=1

Thanks for running all these tests! I will test it on non upgrade devices on Friday, once I am back home!

Alright guys - so I have a build, but it is not tested. I am on the road until Friday at which day I will be able to properly test my fixes localy. For now I call if V1.3 Alpha to indicate its nature. You can download it here: https://www.dropbox.com/sh/q4yhiyfgrtd3udx/AAB1nrm2637Ix4J2r40tXLFOa?dl=1 Would appreciate if some of you can test its stability!

So my biggest issue is that on my side I need to keep both version compatible. I cannot simply move to 0x51 because then I'll break backward compatibility. I think my best option is to recreate the virtual AB group. About to investigate how to do this.

Alright - will experiment as well on my side as well tonight!

That sounds pretty serious and worthy of immediate attention. You updated the firmware via the latest app? @Mr Hobbles - did you notice an update in the protocol with this update?

This is totally doable This has always been in my mind, but I never found the time to make it happen. It create some much more complex edge cases unfortunately.

Actually you can already do it! Simply set your lights as motors and you can achieve this without further code from me.