reorganization of *sensorbox* repos

[gisma]

I feel a strong need to reorganize and relink the sensorbox related repos. I feel pretty uncomfortable with this grassroot like structure. Before we starting linking and producing readmes webpages etc. we should be consistent. I would suggest a new structure and everybody who feel concerned may review it.

[gisma]

any constrains to rename pysensorproxy in Sensorboxes-control or anything that makes clear that it is the controlling software for the sensorboxes...

[jonashoechst]

I'd really like to think of pysensorproxy as a more generic measurement tool and thus would vote against prefixing it with Sensorbox-. However it should be clarified, which repositories contain wich part of the implementation and do which job.

[Friessn]

Just that I understand correctly, the pysensorproxy repo contains the code that can also be implemented outside the sensorboxes setup (lift, liftsystem, planet), but for instance in some satellite setups (e.g. bat caves. nest camera)? So the aim is that for instance 'audio.py' contains generic methods for any kind of audio recording setups independent of the microphone I use and independent of whether its attached to a raspi, a raspi zero or an arduino?

[gisma]

as a more generic measurement tool a

I strongly disagree with this point. It is nothing else like a hard coded framework for sensorboxes. Everything is integrated the wiring the sensors the pi 3 etc. it is definitely not a generic measurement tool. It is software for "our" sensorbox concept.

At the moment we just don't have time ressources for a high end perfect software framework. We need a working prototype. And we need a more transparent organisation and documentation of our various tasks. I think this has the highest priority.

[Friessn]

I support @jonashoechst premise on a conceptual level, but at the current stage the organistation and documentation is more important, especially if the codebase is as hardwired as chris says. Thus, I agree with @gisma and would vote for Sensorboxes-control

[gisma]

In a conceptual way i agree. However We are far away from this. Maybe in year 4. We can mit develop our software alomg guidelines that are nice. First of all itmeed to work. So ist ist mit the Name of the repo nur the intended Spirit that WE are discussing.

[gisma]

Right in the moment and up to a unknown point I see the pysensorproxy as a Sensorboxes-Core-Control software repo. For the envisioned concept of @jonashoechst we need a much more comprehensive framework of which pysensorproxy would be one part. I am not strugggling for this name but I feel unconfortable with the name and intention that ist linked to this name. So ask for a real arguments and a decision.

[jonashoechst]

First, please let me say, that renaming the repo and it's software comes a the cost of requiring time (cross-references in other repositories, etc.). So for the sake of having a working prototype, I would like to step back from this for now.

To get the interaction and the structure of the different repos straight, I've written about the current state in the Sensorboxes Documentation, subpage Raspberry-Pi based Sensorboxes.

From my point of view, the current status of pysensorproxy is NOT hardwired. There exists a mechanism for hardware-specific configuration, namely sensorproxy.aml. Where custom configuration is possible, these options are exposed through the yml configuration, as done for:

• AM2302 temp/humid sensor, for the connection pin;
• Audio recording, for various options, such as the card and the device.

To weaken the goal stated in my above comment, I would propose the following: pysensorproxy should become a tool to schedule, execute and transmit environmental measurements based on the Raspberry PI platform. From my point of view, this will be an affordable target (again, not right now), such that other researchers might want to use the software, but not too much overhead for our project.