frederikheld / treecam Goto Github PK

Turns your RasPi into a webcam that tweets pictures at configurable times of the day.

License: GNU General Public License v3.0

Shell 2.90% PHP 0.16% HTML 1.05% Dockerfile 0.63% Python 95.26%

python twitter-api balenaos raspberry-pi iot

treecam's Introduction

TreeCam

Right in front of my window there's this wonderful tree which accompanies me through the seasons of the year. Year after year I think how great it would be to follow this noble tree through the year by taking pictures of it's day by day transformation.

So I developed TreeCam, which takes pictures of the tree in regular intervals and posts them on Twitter as well as uploads them to a FTP server.

This repository contains the software that you can use to set up your own TreeCam. It also comes with a reference implementation that shows how a TreeCam hardware can look like.

Reference Implementation

You can see the latest picture that my TreeCam device has taken at treecam.frederikheld.de.

~~My TreeCam device is posting pictures to twitter.com/fhdevlab automatically four times a day. I will also tweet timelapses and background information from time to time.~~ Unfortunately not anymore.

If you are interested in the hardware I'm running, please have a look into the ./birdhouse directory.

Outline of the TreeCam services

TreeCam is designed to run on a balenaOS powered Raspberry Pi, which makes it resilient against sudden power outages and also allows to run updates remotely via balenaCloud. TreeCam consists of different services that can be found in the subdirectories of ./src.

Camera

The camera service is the main service of TreeCam. It takes pictures and posts them to Twitter and/or an FTP server and therefore requires a RasPi camera module.

Additional services are integrated via Git submodules:

Heating and Ventilation

balena-hvac is useful if you operate your camera outdoors and want to prevent damages through over-heating or condensation. It requires additional hardware!

Convenient WiFi setup

wifi-connect and balena-reset can be used to manage the WiFi connection between the TreeCam and your home wifi via a captive portal and reset button. You don't need those services if you provide your WiFi credentials when downloading the image in balenaCloud or if you only want to use wired networking.

Configuration

The configuration of the whole installment is done (as usual for balena multi-container apps) in the ./docker-compose.yml file in the root level of this repository. The individual configuration of each services works slightly different. Please read the README.md files of each service to learn about it. Each service also comes with their own exemplary docker-compose.yml that you can use as templates.

Robust and user-friendly

TreeCam was designed with robustness and usability in mind, which led to the following design decisions:

The operating system is balenaOS which runs the different modules in Docker containers. It is very resilient against unexpected power loss and can be updated and maintained via balenaCloud.
This makes it easy to operate the device in places that are difficult to access. As long as there's a WiFi connection available, you're fine
The WiFi connection can be set up via a captive portal
The services can easily be configured via a central docker-compose file and the balenaCloud
New features and services can be added with moderate Python skills

Setup

See src/README.md for instructions how to setup your TreeCam device.

Known Issues

The RasPi Zero W would be the perfect device for this project because of it's low price and power consumption. Unfortunately downloading the containers from the balenaCloud will most likely fail on a low-spec device like the Zero due an issue with the balenaOS watchdog. See the related support thread here: https://forums.balena.io/t/persistent-failed-to-download-image-due-to-connect-econnrefused-var-run-balena-engine-sock-error/114001/14

Contribute

I'd be happy to receive pull requests that add new features and services to TreeCam. For example features that upload pictures to other social media platforms or services that implement new use cases.

Please have a look into the issues on GitHub to see what else is planned that you could support with your skills and time.

treecam's People

Contributors

Stargazers

Watchers

Forkers

l30n1d4

treecam's Issues

RasPi uses wrong time zone

Problem:

Run the code locally --> FTPS uploaded files will have timestamp filenames according to the local time (= system time) --> this is expected behavior
Run the code on RasPi --> FTPS uploaded files will have timestamp filenames -1 h from the local time (which suggests the conclusion that the RasPi is running in UTC+0 timezone). Tweets will also be posted one hour to early. --> this is not expected behavior

Expected behavior:

RasPi uses local timezone to name files and to trigger events.

Possible solutions:

configure timezone in config.json?

Additional considerations:

does the RasPi get the time from a time server? If not --> configure one!

Add balena-reset service

Right now the wifi connection can be setup exactly once via the captive portal.
If the user mistypes the credentials or needs to configure a different wifi, they have no other option than flashing a new image to the sd card.

Adding the balena-reset service would allow a much easier way of re-setting the wifi credentials.

This also requires a hardwar button on GPIO!

Add balena-reset service

Add balena-reset service to allow the user to reset the wifi connection if it was misconfigured or needs to be re-configured.

This also needs a button on GPIO!

Add overlay to picture before upload

This would be an image processing service!

The user can choose a picture from their computer that will added to taken pictures as an overlay.
This can be used to add watermarks, additional information or to conceal parts of the picture.

Arrange Twitter posts in threads per day

This config value already exists but is not implemented yet!

It would be great to have one Tweet per day that starts a thread and all other tweets of that day are answers on that thread. This would make it easier to navigate the Twitter account.

Possible downside is, that the first pictures people see are all taken at the same time of the day.

Should be an optional feature! If set to False, tweets will not be threaded.

Logging in a format that is compatible to tools like ElasticSearch

Not the highest priority for TreeCam. Would be more interesting if I use logger for other projects.

Idea:

Logger can already log to console or a file, but the format is more designed to be consumed by humans
add the option to output logs as JSON or similar to be consumed by log databases like ElasticSearch

Needs investigation to figure out what tools and standards exist that we can/should use.

Ghost image in camera setup

The user can select a previous picture that serves as a template for the desired angle of view
The picture can be loaded into the web portal and is displayed as a see-through overlay of the actual camera picture.

This would require to store pictures on the device or allow to upload one (that was obtained from the FTPS server or user's computer)

GPIO trigger

It would be great if the user could trigger the camera via a button attached to the GPIO interface.
This would help to setup the camera.

Make timer_cam execute at the same time every day

Currently timer_cam intervals are the pause between the end of a shot and the start of the next shot. This does not account for the time taking the shot and uploading it takes. This is why shots are shifting in time from day to day. To make time lapse videos it would be better to have them taken at the same time every day (e.g. to see how sunrise and sunset are shifting).

Desired: Add config key that allows to configure a time from the full hour/minute at which the shot will be taken. Follow same approach as cron!

Setup camera via web portal

To achieve the same angle of view for each photo (which is needed for timelapse animations), the setup of the camera needs to be simplified.

This requires the following additional features: #16, #9

SIGINT/SIGTERM will not interrupt pause between serviceRunner runs

If the serviceRunner receives a SIGINT/SIGTERM signal it will wait for the current run to be finished. This is on purpose to gracefully shut down all services.

What's not intended is that it waits until the pause at the end of the run has ended, because this pause can be very long if the user configures long iteration times (default is 60s).

--> if services are running when SIGINT/SIGTERM is received, the serviceRunner should stop after all services are run (like it is right now).
--> If the serviceRunner is currently pausing, the pause should be ended immediately.

Web portal for configuration instead of `config.json`

Right now the configuration has to be done via config.json. This only works well for software oriented users. It would be nice to have a web portal that allows interactive configuration of the camera module.

The information could still be stored in config.json, but the values are loaded into a web form where they can interactively be changed. They are then saved back to the json file.

First MVP could be to load the entire config.json into a textarea.

Optimal implementation would be an form that auto-generates itself according to the types in the json file (this would require additional meta information in config.json though).

Make triggers an abstract feature

Right now triggers are evaluated in the services' run() function. Modularization could be improved if triggers would be a feature that could be re-used across services.