Using boost color and distance sensor in mode 1 returns distance as color

[aileo]

I tried to subscribe to a color and distance sensor on a PUP hub on port A using this code (based on the web_bluetooth example):

const poweredUP = new PoweredUP.PoweredUP();
poweredUP.autoSubscribe = false;
poweredUP.on("discover", async (hub) => { // Wait to discover hubs
    await hub.connect(); // Connect to hub
    log(`Connected to ${hub.name}!`);
    hub.sleep(1000)
    hub.subscribe('A', 1);
    hub.on('distance', (port, ...values) => log(`distance on A: ${ JSON.stringify(values) }`));
    hub.on('color', (port, ...values) => log(`color on A: ${ JSON.stringify(values) }`));
    hub.on('colorAndDistance', (port, ...values) => log(`colorAndDistance on A: ${ JSON.stringify(values) }`));
});

And I get this output when I get the sensor closer to an obstacle:

Connected to PoweredUp!
color on A: [10]
distance on A: [null]
colorAndDistance on A: [10,null]
color on A: [9]
distance on A: [null]
colorAndDistance on A: [9,null]
color on A: [8]
distance on A: [null]
colorAndDistance on A: [8,null]
color on A: [7]
distance on A: [null]
colorAndDistance on A: [7,null]
color on A: [6]
distance on A: [null]
colorAndDistance on A: [6,null]
color on A: [5]
distance on A: [null]
colorAndDistance on A: [5,null]
color on A: [4]
distance on A: [null]
colorAndDistance on A: [4,null]
color on A: [2]
distance on A: [null]
colorAndDistance on A: [2,null]
color on A: [3]
distance on A: [null]
colorAndDistance on A: [3,null]
color on A: [2]
distance on A: [null]
colorAndDistance on A: [2,null]

Message structure depends on device mode and I don't think message contains the device mode.
I think it should be relevant to store mode in port informations to handle this. If others thinks the same I can work on a PR.

[aileo]

Problem also occurs with the count mode (2), count is emmited as color until it reach 10.

[nathankellenicki]

Gotcha. Yep, this is a known issue - although the library had the initial aim of letting anyone set whatever mode they wanted, the parsing code was never implemented properly.

This is something that'll hopefully be solved by a mix of #56 and the "new paradigm" discussion.

Edit: I just noticed that #56 if your PR! Thanks!

[nathankellenicki]

This is fixed in v6.0.0 - attached devices are now presented as their own class, which contains proper support for different modes.