search

Nature40 / pysensorproxy

A python tool to schedule, execute and log environmental measurements.
MIT License
0 stars 0 forks source link

real world feature request #45

Open gisma opened 5 years ago

gisma commented 5 years ago

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

jonashoechst commented 5 years ago

I mostly agree with what you're saying. Especially better usability and debug ability is really needed here, and also envisioned by me. We had a students project that delivered somewhat usable results (Web UI for debug and configuration): https://github.com/Nature40/pysensorproxy-ui

Concerning the updatability, there are ways to do better. I would certainly be happy to provide an update mechanism for pysensorproxy itself. Regarding the other configurations (mesh network, Wireguard, sensor / GPIO configuration) I think we still need the flashing process. My intention for this process was, to have clean and reproducible installations on every box and still think, that I have a point here. Also I would like to clarify, that a box can be configured, without reflashing the image (~ 5 sec.), maybe I should have elaborated a bit more on this.

gisma commented 5 years ago

hat a box can be configured, without reflashing the image (~ 5 sec.), maybe I should have elaborated a bit more on this

would be nice to have a script and a working protokol ;-) because we are doing this by hand pulling the SD card out of the raspi into the laptop editing it and vice versa

Friessn commented 5 years ago

Would it be possible to implement the good old SSH connection instead of the mesh network at least in debug mode? This way we could connect via SSH to the lift or the planet and change the yaml files directly. If this would also include some kind of verbose mode for live debugging, this would be great. Do you think that is possible? @jonashoechst

Friessn commented 5 years ago

with https://github.com/Nature40/pysensorproxy/commit/9c392e186311e2c376f1622fe5d32d987c39f999 and https://github.com/Nature40/pysensorproxy/commit/0dfa0cf2836fafc680978b0d3fcc276911eb91c2 I added some more debug output for the hall sensors. Additional I added the height to logs every time we move the lift. So the last height value in the logs have to be the current height. It's untested because of the attending of the LCN conference and not having hardware here. But it is only some output and I think it should work. Finger crossed. For Wifi and system state we want to store systemd logs for our services and the wpa_supplicant logs. Additional I added a wifi scan every time we switch from or to the ap mode. So we get a wifi scan result before and after every lift movement.

The verbose mode for live debugging I wished for would of course include @lampep 's debug output as mentioned as Originally posted by @lampep in https://github.com/Nature40/pysensorproxy/issues/44#issuecomment-543052615

jonashoechst commented 5 years ago

Would it be possible to implement the good old SSH connection instead of the mesh network at least in debug mode? This way we could connect via SSH to the lift or the planet and change the yaml files directly. If this would also include some kind of verbose mode for live debugging, this would be great. Do you think that is possible? @jonashoechst

That's one central design problem. As we use Wi-Fi for controlling the lift, no other Wi-Fi connection will be possible. Neither through mesh, nor through the Wi-Fi AP mode.

This also is an argument, why I wanted the lift to switch to BLE (or some other wireless communications protocol), it enables much better debugability.

Friessn commented 5 years ago

In general I do not have a problem with BLE, given that the WiFi protocol is designed with another use-case in mind, it might generally be a good idea to have another wireless lift/motor communication and BLE is definitively a good candidate. I think in previous discussions I wasn't fully aware of the WiFi framework and the inherent problems for debugging, so switching to BLE might after all be a good idea as @jonashoechst said in the first place. The other problem is of course that we do not have any experience concerning the range of BLE so any test results on the Platane doesn't guarantee success in the forest which means longer development cycles as we need to run tests on a "real tree". I'm just worried that it currently binds resources we need to get the whole thing into the forest. Or is a BLE framework/code ready for lift off (badum-tss)? Nevertheless we should discuss BLE and the overall prioritization on monday.