Local Docker builds and modernized DHT access #21
Conversation
|
@ivadim most definitely. I can handle the rebasing after the other PRs are merged. I am also trying a bit of hardware innovation on my FruitNanny: replacing the TIP120 with an appropriately sized PNP transistor and photoresistor combination for a "night light" feature for the IR LEDs. PNP is "normally on" and the photoresistor has less resistance the more light there is, so the photoresistor in the presence of light will let current through to the base pin of the transistor to turn it off instead of a RasPi control pin. This is a great project all around. One caveat: I think I "broke" Express JS in my PR. I am not as sharp with JS as with Python or Docker (or circuits for that matter). It may just be a question of a wrong post-reorg path at https://github.com/ivadim/fruitnanny/pull/21/files#diff-c2e59500bc1443903f7908b6b5888975R8. Wondering if you could shed any light on that. Looking forward to merging the changes! |
|
@rayrrr I've merged other PRs... I can try to fix express part If you can rebase from master. Does it work for you? Additionally, I would prefer to use images from docker-hub and don't rebuild them before run. |
|
@ivadim yes on all counts. I can rebase from master lunchtime so you can look into it. Can you do the |
* remove Docker directory * always build Docker images locally * move bin dir to fruitnanny dir * get Dockerfiles working * put bin dir back where it was * update relative paths for reorg * fix paths for config * move all JS stuff to fruitnanny dir * stop using volume import for config file * dht sensor working with libgpiod2 etc * bump npm package versions and add pm2 deps
discovered during setup
|
@ivadim lunchtime turned into bedtime, but rebased from master and all conflicts resolved. I also made some changes to the new notification service to match the reorg structure. Please kick the tires (especially Express-wise) and let me know how you'd like to proceed in terms of a separate docker-compose local file. |
|
Olá @diogopms, I think the best way to get this PR merged is to have someone actually test it on FruitNanny hardware. Can you? |
When trying to build on my Pi I needed to add setuptools, and I've also included my fix for the audio system constantly re-initialising.
|
I've been using this PR as the basis for what I'm running on my Pi Zero W. For the Zero I needed to make some more changes (not using rpi-3 images, and I use slightly different audio and temperature hw). But this works well, non-Zero changes: https://github.com/AJDurant/fruitnanny/tree/pr-21 Zero changes: https://github.com/AJDurant/fruitnanny/tree/pi-zero Using the local docker build also mitigates #39 where OS updates stop the docker images running properly. |
|
Is there any work still going on with this? Love to see a polished and updated version available. |
This is a tested-with-Docker solution that does not rely on Docker Hub images. I believe it solves the 502 error #8 in the underlying code as well. This all started because I wanted to use a DHT11 instead of DHT22. It turned into a full organizational overhaul. Now each dockerized service has a directory at the root level of the repo, containing its Dockerfile and any files needed for its build. AFAIK this is a best practice; I see this pattern in most docker-compose projects I use.
This PR also replaces the deprecated https://github.com/adafruit/Adafruit_Python_DHT lib with the recommended CircuitPython-based libs and eliminates the need for Python 2. So now we only install Python 3 in the fruitnanny service. This also removes the need to custom compile any libs, meaning a leaner Dockerfile and quicker build.
It makes local development easier and adds transparency to the project. This "just works" following the existing Docker install instructions. I put a few nights' effort into this, so I hope you consider merging it. Thanks!
libgpiod2etcpm2depsThe bumping of npm packages to remove security vulnerabilities and adding of a built-in
pm2lib caused the large number of LoC changes...quite a bit of this PR is just reorganizing stuff as described above.The one thing I can't figure out is how to get the Azure pipeline to pass. It is passing for the gstreamer and janus services which is a good sign, but not the fruitnanny service itself. @ivadim can you help get this sorted out? I hope you like this approach overall. I also think it would be easy to use in combination with a Docker Hub image-based deployment option but would need to add that back in.