Skip to content

Add VL53L0 distance sensor.#9706

Draft
smavridis wants to merge 5 commits intomeshtastic:developfrom
smavridis:vl53l0
Draft

Add VL53L0 distance sensor.#9706
smavridis wants to merge 5 commits intomeshtastic:developfrom
smavridis:vl53l0

Conversation

@smavridis
Copy link
Copy Markdown

@smavridis smavridis commented Feb 21, 2026

Added new Environment Telemetry class VL53L0XSensor. Tested with a Heltec V3.

I have deployed it with a Heltec V3, currently my only meshtastic/lora device.
Expecting RAK and Xiao boards to ensure no issues, but delayed due to Chinese New Year.

This is my first contribution, i read the contribution guide and signed the CLA, let me know if i have missed anything.

Thank you for the Meshtastic project.

🤝 Attestations

  • I have tested that my proposed changes behave as described.
  • I have tested that my proposed changes do not cause any obvious regressions on the following devices:
    • Heltec (Lora32) V3

@CLAassistant
Copy link
Copy Markdown

CLAassistant commented Feb 21, 2026

CLA assistant check
All committers have signed the CLA.

@CLAassistant
Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


Stelios Mavridis seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You have signed the CLA already but the status is still pending? Let us recheck it.

@github-actions
Copy link
Copy Markdown
Contributor

@smavridis, Welcome to Meshtastic!

Thanks for opening your first pull request. We really appreciate it.

We discuss work as a team in discord, please join us in the #firmware channel.
There's a big backlog of patches at the moment. If you have time,
please help us with some code review and testing of other PRs!

Welcome to the team 😄

@github-actions github-actions bot added first-contribution hardware-support Hardware related: new devices or modules, problems specific to hardware labels Feb 21, 2026
@smavridis smavridis force-pushed the vl53l0 branch 6 times, most recently from f81d8d3 to 9e1e5a7 Compare February 25, 2026 01:09
@fifieldt
Copy link
Copy Markdown
Member

Hey! Thanks for the patch :) For adding the sensor type, a patch needs to be made to the meshtastic/protobufs repo. If you can't find it let us know!

@smavridis
Copy link
Copy Markdown
Author

Hey! Thanks for the patch :) For adding the sensor type, a patch needs to be made to the meshtastic/protobufs repo. If you can't find it let us know!

Thanks for the heads-up, i added the VL53L0 enum in TelemetrySensorType.
Is there anything else i am missing?

@fifieldt
Copy link
Copy Markdown
Member

That should be all that's required, thanks!

@smavridis
Copy link
Copy Markdown
Author

Thank you @fifieldt and @caveman99 for your help and guidance.
Glad to be part of this project.

Comment thread src/detect/ScanI2CTwoWire.cpp Outdated
type = TSL2561;
logFoundDevice("TSL2561", (uint8_t)addr.address);
switch (registerValue) {
case 0x00 ... 0x04:
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getRegisterValue() defaults to 0x00 when no bytes are read, so bus/read failures can be misdetected as VL53L0X.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did not thinkof that and was testing with the sensor so wasnt checking that scenario, will fix.

VL53L0X_RangingMeasurementData_t measure;
vl53l0x.rangingTest(&measure, false);

measurement->variant.environment_metrics.has_distance = true;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

measure.RangeStatus should be checked for out-of-range/error readings before deciding that the result is valid

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, i didn't know it had such Status.

@smavridis
Copy link
Copy Markdown
Author

I addressed the issues by @robekl (thanks), detection of sensors and ranging should be more robust.
Ideally i should have checked a setup with the other sensors, but i don't have any at hand.

}
break;
case TSL25911_ADDR:
registerValue = getRegisterValue(ScanI2CTwoWire::RegisterLocation(addr, 0xA0 | 0x12), 1);
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity the bitwise OR of the register addresses always seemed wierd to me.
Doesn't that mean that the old code was reading register 0xB2 rather than 0xA0 and/or 0x12.
Am i missing some weird overload or c++ magic?

@smavridis smavridis marked this pull request as draft February 26, 2026 23:15
@smavridis
Copy link
Copy Markdown
Author

I converted this to a draft, since i decided to extend it a bit more.
Looking around i found i can add a State Message in to implement configuration of the sensor by the user.
I will be adding an option for setting the sensitivity/range of the sensor.
I think this will make it more usable for any other user that might be interested in the sensor.
Ill be following the SEN5X sensor as it seems to also have State.

@smavridis
Copy link
Copy Markdown
Author

I have added the State message and serialization/de-serialization logic.
I can see from the boot log that the load function gets called, but since the state was never written, no state gets loaded.

I think i am still missing some sort of registration so that the application knows that a configuration/option exists for the sensor but i cant really understand where/how that is done.

I did see a handleAdminMessage() function which i guess is relevant but i still think i am missing something.

@smavridis
Copy link
Copy Markdown
Author

So i tried to figure out how to add/modify the android application to add a configuration menu for the sensor ... unfortunately it is way above my skill level of Android/kotlin, etc ... i might try to touch it again at a latter time or hopefully some good soul does it instead.

Failing that i switched to providing a menu option in the firmware.
I have made the first steps and added a top level menu 'Sensors' in the System view.
I also considered initially to put it on the Environment Telemetry view, but since it is about received telemetry rather that local sensors i think it is not suitable.

At this point i wanted to get some feedback from you @fifieldt @robekl on the approach and any suggestions or ideas you might have.

I will try tomorrow to see how to call access the VL53L0X object to get/set state and configuration, so ill get back to you.

Thank you for your time.

Comment thread src/mesh/generated/meshtastic/telemetry.pb.h
@caveman99
Copy link
Copy Markdown
Member

The settings changes for your sensor need to be wired in the AdminModule and with additional functions in your sensor code, to process the changes. For testing this, it's best to use the python CLI client, since the protobufs can be updated there without too much hassle. Android App would be the next step.

@smavridis
Copy link
Copy Markdown
Author

Thanks for the feedback @caveman99.
I removed the generated files as requested.
I also modified the admin.proto and implemented a handleAdminMessage.
However i cant get/set the new variable so i am still missing something?
Perhaps that's what you mean by AdminModule, should i modify AdminModule.cpp?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

first-contribution hardware-support Hardware related: new devices or modules, problems specific to hardware

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants