central setup and definition of all gpio and wiring aspects

[gisma]

Up to now there is a lack of documentation of the wiring and setup of the gpio. Only the hall sensors are explicitly defined. That means e.g. the temp/humidity sensor of ardadfruit is taking the default values from the library script and hence is wired to the gpio 4 . This seems to me highly cumbersome and error prone, because one has kind of to reverse engineer through the code and hardware to identify the old or integrate new sensors. I would suggest to define this explicit e.g. in the lift class (because it is seemingly initialized here) or old school but more transparent in a sensor-setup yaml file or something else.

[jonashoechst]

There clearly is a lack of documentation. All relevant options for configuration of a sensor are exposed through the yaml configuration.

For the case of the AM2302 this can be found here: https://github.com/Nature40/pysensorproxy/blob/master/sensorproxy/sensors/environment.py#L13-L18

The example configuration file finally defines pin 4 as the GPIO pin used for the AM2302.

[gisma]

Actually I know - that is exactly what I have described reverse engineering... ;-)

[jonashoechst]

Actually this is also explained in the readme file: https://github.com/Nature40/pysensorproxy/blob/master/README.md#static-configuration-sensorproxyyml

Could you please elaborate a little on what you are missing? I might not have gotten the point here.

[gisma]

Sorry for not clarifying it precisely. Depending on sensors and how to connect them it should be forced to define these parameters more clearly and obligatory in the yaml file. For the AM2302 the line https://github.com/Nature40/pysensorproxy/blob/9c392e186311e2c376f1622fe5d32d987c39f999/examples/moon_sensortest/sensorproxy.yml#L17 is not very clear because it seems to be optional. But it is indeed obligatory. If I write a pin: 5 nothing will work anymore. Other sensors like the lumen sensor is routed through the rtc and using the I2C bus. Nobody knows this and it would be helpful to set a defaul like pin: SCLRTC or something like this. It would be helpful if this is configured and documented consistently in the yaml configuration file. In addition it would be helpful to write down somewhere what is the logic of sensor implementation - i.e. getting started with new sensors which leads through this process step wise. I think this will make it much easier to deal in a flexible way with sensors. At least it would be helpful to have agetting started and a frizzing wire scheme according to a fully documented yaml file... ;-)

[jonashoechst]

I think one has to differentiate here. For pysensorproxy defining which pin is used for which sensor is clearly too much. pysensorproxy is intended to be used as an independent generic sensor logging tool, thus no fritzing schemes or configuration files but examples should be documented here.

From my point of view this part of the documentation belongs inside of the Sensorboxes-Images repository, as it contains the blueprint for configuration of our sensorboxes. There you will also find an (unfortunately outdated) frizzing scheme of our first generation Sensorbox.

What would be in the right place in this repository is the documentation of the individual sensor implementations. I suggest to document this in the code and generate a documentation (e.g. HTML) from it.

[gisma]

Actually tis is a very similar discussion as in #49. If pysensorproxy is intended to be this kind of interface than we need a total redesign. At the moment it is not at all similar to this vision. If it would be like this you are right but at the moment we are dealing with something else. IMO it is really confusing to get a hold on what is belonging to what and doing what. It is a question of reorganization and consolidation I am talking about. It is the time of the "users" that means my time that is spent in this cruising around in an in transparent and poorly documented structure. IMO we do not need to discuss deatails furhter on, I am absolutely willing to discuss the whole thing to find a better solution.

But first we need a running version.