Build Configuration Documentation

[eric-ott]

Problems

• Some of the language was hard to understand, IE what a project was, subproject, what the settings.gradle and build.gradle were meant for.
• Getting this to work on my own took forever, just to get fake weather to be there. It was hard to find the needed drivers to do this, and how to add them, just did not make full sense to me
• I was unable to figure out how to add a process to this, even when I spent time to troubleshoot it, either there would be an error and the gradle would not build the process because it could not find some file, or it would just not be present in the node. (Biggest example of this, was in sensor-process-geoloc, which had an error that sensorhub-process-vecmath was not found in the project, and I was unable to figure out how to fix it. Or the Basicmath process was not present in the node when I was able to add it) (The only way I was able to figure these things out on my own, was by reading the User Documents to find out where everything was, just was not clear where these sensors were located)

Fixes

• I added sections that added more information to technical terms, to explain what it does in more simple terms. How and why we are using build/settings.gradle and other questions I had to look up.
• Added a section on how to add the fake weather section, as a workflow example, so someone could follow along, and not have to spent hours troubleshooting, (Mostly they know where things are in "paths" and how to call them for gradle to find)
• Additionally, when you do add something to the Node, it was unclear that you had to rebuild the Node, so added a note to do that, starting from the gradlew build command. Since it was unclear to me, a newer user would also see that unclear.

Comments

• First, I had trouble getting any process to add to my Node, either there would be an error that the gradle could not find the additional files, which I was unsure how to rewrite that section, which is why there is not fix on my end to it, as I would not be able to fix it.
• Second, when it comes to our addons, there is so many addons we have, but there is no easy way for a user to find the right addon needed for their project. Which is why I propose we do two things to fix this issue
• • First, we need to create a list, either an excel sheet, drop down menu, something that is a glossary of every single addon we offer, what it does and where to find it. So that, when users want to use an addon, they can find an addon they want to add to their configuration, they can find it, and see what it does.
• • Second, since we are using Claude in our workflow, there should be a way to create a Claude model, trained only on our systems, and our addons. So there is a section in the OpenSensorHub website that allows people to enter exactly what they are looking for, and the AI agent can either point them to an existing addon we have that fulfills the need exactly, points them to one that fits it partly but then tells them how to manipulate it so they can get it to fulfill their need, or if nothing is available help them create an addon that fulfills this need. This is useful as we attempt to first make it easier to find our addons and make it closer to our no code goal. (I am will to work on creating this agent if this is something the company wants to attempt to create, however, I will need help in adding it to the website, as I can train Agents, but adding one to the website is something I have not done)