nature40 / pysensorproxy Goto Github PK

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.

ifup sometimes takes more than 15 seconds and thus is stopped. The semaphore used to access the lift is not freed, and leads to a non-working lift.

The test mode tests every sensor once (just like on startup)

For now the test can be achieved by running sudo systemctl restart sensorproxy. The web interface is back after ~30s.

kwT

The test protocol should only test the available sensors (hall sensors interactively), but not disconnect the wifi or such.

When logging messages, the Handler runs on the main thread and thus can cause the log to slow down execution; especially when submitting e.g. via influx.

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.

As already discussed there is a major shortcome in the communication of the pi with the TTGO. As far as we have discussed now we will try the following

1. changing the protocol from UDP to TCP (27.02.)
2. if (1) fails adding antennas we have to decide (27.02.) which antennas are suitable (any suggestions)
3. if (2) also fails changing the the controller unit to something else (suggestions welcome)

In the base module there currently exit Sensor, LogSensor (simple values) and FileSensor (creating files, such as audio recordings). The proposal of this issue is, to omit the sensor class and move its functionality in the LogSensor class and implement the FileSensor inherited from the LogSensor.

There are multiple advantages:

• simplification of the code and less code duplication
• a FileSensor would also create a csv file with measurement details (such as an enabled IR filter)

targets:

• environmental sensors
• battery state
• errors

The data needs to be mapped to each individual sensorbox ids

Almost all tested cameras produce black images although there is enough light to produce an image. Back images are about half in size of normal images.

in the insect photo trap all sensors only make sense if the UV-LEDs are set to on. Otherwise all measurements are meaningless. If you start the box between xx:00 and xx:30 the LED is not set to on, but the rest of the measurement are done. It could be very confusing to look on dark videos and images if everything else works fine

Here the lost connection time periods should be integrated. This will be easily up to 15 % difference. This will also enable a first software hack to stop the lift at the bottom and top position and to ignore hall sensor signals in between. The latter means that the hall sensor status has to be checked against the real position.

alsamixer provides a command line interface to bump up the recording level.

When setting heights in descending order, the running time is not correctly implemented, resulting in a non-moving lift.

time is somtimes configured with variables like duration_s, and sometimes with free units, such as interval: "30m".

To debug the lift more efficiently, we should add more logs, as suggested by @gisma.

WiFi Status wer mit wem verbunden ist und natürlich nicht verbunden dazu die geglaubte Höhe//laufzeit
Logische Parameter jslubfahrt hoch runter mit Höhenangabe und normale messefahrt mit Höhenangabe

in #19 we fixed the wifi as far as possible. Now we can move the lift up and downwards and in most cases without stalling.
But we can think about other radio technologies like bluetooth or something like than

The idea behind this features request is, that different measurements may require different data sinks:

• small data such as temperatures and state: LoRa
• photos and images: DTN
• status information: LTE

Thus, there should be a unified interface for potential data sinks. The options and the interface can be discussed here.

This is something one could look into to improve recording quality. Levels and overall recording quality is decent.

Currently, when the energy supply of the sensor is cut off the program does not throw an error message and the measurment seems to continue with the last recorded value. Could you please fix that?

The config should give all information on how to connect sensors, instead of hiding this information in the code.

In the context of the Sensotrail it ist obligatory to make the normal sensoboxes easy accessible via WiFi. I suggest the same logic that is implemented for the rts boxes.

The actual microphone recording settings (set to 100%) generates an extremely silent sound level. Tested with the low budget moicrophone it is not able to record a normal talk of two person 50 cm from the micro. Any suggestions?

eg. Bird Audio measurements need to start relatively to sunrise, accordingly the start and end times should also be able to be configured relatively to sunrise / sunset

mesure multiple times and write average, std deviation

maybe the handshake is not so good and a bad bandwidth is chosen

Could you please change the path variable to store the data in another directory than the tmp directory?

currently, all sensors are tested on startup, which can take a long time, if long audio recording intervals are configured.

In the default setting the audio recording currently only lasts for one second. Can you please create a config file to enable users to specifiy length of audio recording?

Is there a possibility to define the time interval that is stored in one file? It seems to be convinient for pictures and voice recordings to have single files however for temperature/humidity and lumen this is pretty inconvenient.
In addition some of these files contains no data other one data set or two.

If the WiFiManager was not instructed to connect to any network, create an own.

Ganz wichtig ist dabei das Audio und Bildmaterial getrennt von dem Rest sind und so leichter in eine andere Datenpipeline fließen können. Für den Datenschutz muss das einfach getrennt werden.

The last few weeks have shown that the current procedure for setting up and deploying the sensor boxes software on the one hand and troubleshooting on the other hand is not affordable.

To be more detailed:

Flashing all the time for all stations a new image is extremely annoying due to labor intensive steps and waiting periods in addition it is even more error-prone without any attempt of versioning. You will find all kinds of images and versions on all devices. Here the process for real life has to be simplified. IMHO only the software parts that have been changed are patched via scp or rsync and a efficient version management is needed.

Real-time monitoring or normal easy-to-use access in the field via ssh or monitoring via ssh or some other way has to be implemented. At least a full-debug mode is necessary. In the field I just want to check via console what is going on and or wrong. This is an absolute high priority feature which is obligatory.

I realize that these requirements mean a certain amount of effort. but the effort we have had in the field since our last meeting is simply not affordable and certainly not by @ and / or me. Furthermore, these features will have a significant impact on whether such a system is usable or just a finger exercise remains.

cheers Chris

Implement a rsync-like sensor to push files from a moon to its planet.

The lift does not move at a good quality at the moment, multiple stalls happen (see also #43)

proxy log don't include information about the reason for a measuring failure. (eg. I|O Error)

The real time clock fails sometimes, and thus should be sanity-checked