{"id":20479393,"url":"https://github.com/paxswill/r-u-still-there","last_synced_at":"2025-10-20T10:08:16.091Z","repository":{"id":138510273,"uuid":"362638697","full_name":"paxswill/r-u-still-there","owner":"paxswill","description":"Occupancy sensors for home automation using thermal cameras. ","archived":false,"fork":false,"pushed_at":"2021-12-14T20:54:55.000Z","size":18850,"stargazers_count":8,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"main","last_synced_at":"2025-03-27T04:33:27.383Z","etag":null,"topics":["home-assistant","home-automation","mqtt","raspberry-pi","thermopile"],"latest_commit_sha":null,"homepage":"","language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/paxswill.png","metadata":{"files":{"readme":"ReadMe.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-04-29T00:01:46.000Z","updated_at":"2023-12-22T14:31:09.000Z","dependencies_parsed_at":"2023-03-18T09:32:19.718Z","dependency_job_id":null,"html_url":"https://github.com/paxswill/r-u-still-there","commit_stats":null,"previous_names":[],"tags_count":4,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/paxswill%2Fr-u-still-there","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/paxswill%2Fr-u-still-there/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/paxswill%2Fr-u-still-there/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/paxswill%2Fr-u-still-there/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/paxswill","download_url":"https://codeload.github.com/paxswill/r-u-still-there/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248721109,"owners_count":21151048,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["home-assistant","home-automation","mqtt","raspberry-pi","thermopile"],"created_at":"2024-11-15T15:43:44.499Z","updated_at":"2025-10-20T10:08:15.975Z","avatar_url":"https://github.com/paxswill.png","language":"Rust","funding_links":[],"categories":[],"sub_categories":[],"readme":"# r-u-still-there\n\nA home automation sensor for human presence using thermal cameras.\n\nThe most common way to detect if a space is occupied or not is with a \n[PIR sensor][wiki-pir], but this comes with the downside that it doesn't detect\nstationary people. r-u-still-there is an application that can be installed on\nan embedded Linux system along with a [thermal camera](#cameras).\nr-u-still-there will then notify your home automation system when it detects a\nperson, and when that person leaves its view. In other words, you can use it to\nsense if a room is occupied, even if the people in that room are keeping still\n(like when they're watching a movie).\n\n[wiki-pir]: https://en.wikipedia.org/wiki/Passive_infrared_sensor\n\n## Features\n\n* Efficient usage of CPU and network.\n* Messages sent through an [MQTT][wiki-mqtt] broker, allowing use by multiple\n  different home automation systems.\n* Easy integration with [Home Assistant][hass].\n* MJPEG stream available so you can feel like the Predator.\n\n[wiki-mqtt]: https://en.wikipedia.org/wiki/MQTT\n[hass]: https://www.home-assistant.io/\n\n## Hardware\n\nr-u-still-there has been tested and used on a variety of Raspberry Pis from the\nlow-cost 0 and low-speed 1B+ up through an 8GB 4B. I also use it on BeagleBone\nGreens, and it should run on any Linux device that you can connect an\n[I²C][wiki-i2c] peripheral to.\n\n[wiki-i2c]: https://en.wikipedia.org/wiki/I%C2%B2C\n\nPerformance wise, I recommend using something with at least an ARMv7 CPU if you\ncan. The ARMv6 CPU on the Raspberry Pi 0 and 1 works, but it can struggle to\nrender the image stream at higher frame rates and larger sizes. The SIMD\ninstructions and faster speeds on newer processors makes a noticable difference.\n\n### Cameras\n\nCurrently (as of v0.2.0) three models of thermal camera are supported:\n\n| Camera | Resolution | Frame Rate | Field of View |\n|:---:|:---:|:---:|:---:|\n| Panasonic GridEYE | 8×8 | 1 or 10 FPS | 60°×60° |\n| Melexis MLX90640 | 32×24 | 0.5, 1, 2, 4, 8, 16, or 32 FPS | 55°×35° *or* 110°×75° |\n| Melexis MLX90641 | 16×12 | 0.5, 1, 2, 4, 8, 16, 32 or 64 FPS | 55°×35° *or* 110°×75° |\n\nA more powerful CPU is recommended for the Melexis cameras, especially if you\nintent on running them at one of the higher refresh rates. Also note that\nrunning the high refresh rates for those cameras requires a 400kHz I²C bus speed\n(and possibly other configuration changes). See the documentation from the\n[camera driver][mlx9064x-frame-rate] for more details.\npattern.\n\n[mlx9064x-frame-rate]: https://docs.rs/mlx9064x/latest/mlx9064x/register/enum.FrameRate.html\n\n## Installation\n\nYou can install just the program from cargo (crate name 'r-u-still-there'). The\npreferred process though is to use the .deb packages, either manually downloaded\nfrom the releases on GitHub or from my package repo. In any case, I would\nrecommend using the version that matches your hardware closest, as each jump in\nARM instruction sets makes a noticeable improvement in performance (even on the\nexact same hardware).\n\n### Debian-based Distributions (including Ubuntu, Raspberry Pi OS)\n\nSee the RaspberryPi.md file for a walkthrough of installing it on a Raspberry\nPi. Installation on other Debian-based systems will be mostly the same, with the\nbiggest difference in how the I²C bus is enabled on different devices.\n\n## FAQ\n#### Why is the CPU usage is really high?\nDrawing the text of the temperatures is fairly CPU intensive at the moment. If\nyou can disable that (by commenting out the `render.units` value in the config\nfile), CPU usage will go down. Another option is to limit the frame rate of the\nvideo stream with the `frame_rate_limit` setting. And finally, nudging the\n`render.grid_size` setting lower can help a little bit.\n\nRendering the video stream is the most \"expensive\" part of r-u-still-there at\nthe moment as it's all being done on the CPU. If there is no client\nconnected to the MJPEG stream though, no rendering is done and CPU usage\nshould drop back down.\n\n#### How do I configure it?\nFor the Debian packages, the configuration file is located at\n`/etc/r-u-still-there/config.toml`. That is also the default location if no\nconfig file is given as a command line argument.\n\n#### How do you connect the camera to the computer?\nYou need to connect the camera to your device's I²C bus. This varies between\ndifferent devices, but here are a few examples for some devices:\n\n* [Raspberry Pi](https://pinout.xyz/pinout/i2c)\n* [BeagleBone Black](https://beagleboard.org/Support/bone101/#headers)\n* [BeagleBone Green](https://wiki.seeedstudio.com/BeagleBone_Green/#hardware-overview)\n  \n#### How do I get more detailed logs?\nLogging can be configured using the `RUST_LOG` environment variable. Setting\n`RUST_LOG=debug` will give pretty verbose logs, but if you want even more,\n`trace` is also available.\n\n#### What MQTT brokers can I use?\nI use [mosquitto](https://mosquitto.org/), but any MQTT 3 compatible broker that\nsupports retained messages should work.\n\n#### How far away can the sensor detect a person?\nThis depends the resolution and field of view of the camera you're using. Higher\nresolution and a narrower field of view will result in a the camera being able\nto detect a person from farther away. In my experience, a GridEYE can usually\ndetect me (a moderately tall, average build man) from about 4m (13 ft) away.\n\n#### There's a lot of noise (rapidly changing, but not by much) in the temperatures. How can I get rid of that?\nOn the GridEYE, setting the camera to 1 FPS will internally de-noise the image.\nI'm also planning on adding other methods in the future.\n\n#### How can I view the camera image?\n\nThere's an MJPEG stream available (if enabled) over HTTP on port 9000 at\n`/mjpeg` (so `http://\u003cIP address\u003e:9000/mjpeg`). If you want to have it available\nin Home Assistant, you'll need to [configure it manually][hass-mjpeg].\n\n[hass-mjpeg]: https://www.home-assistant.io/integrations/mjpeg/\n\n#### This sounds a lot like what [room-assistant][room-assistant] does.\n\nIt does! I used room-assistant for a while, and think it's a really cool piece\nof software. If you want presence detection using Bluetooth, it's still what\nfirst comes to mind. Over time I encountered a few pain points that I feel\nr-u-still-there better addresses:\n\n* room-assistant can be pretty taxing on the CPU, as it's rendering the image\n  for every frame, regardless of if there's someone watching it. r-u-still-there\n  only renders the image if there's an active client. This results in CPU usage\n  of around 2% on a Raspberry Pi Model 1B+, while room-assistant would normally\n  be around 50-60% on older versions, and be maxed out on newer versions\n  ([v2.12.0][r-a_v2.12] changed to using Javascript libraries for image\n  rendering). Even when streaming video though, r-u-still-there is generally\n  more performant, with a 1 FPS stream taking roughly 15% CPU usage, and 5 FPS\n  taking around 60% CPU.\n\n* r-u-still-there has a few more configuration knobs, such as the size of the\n  generated thermal image, the color scheme used in that image, camera frame\n  rate, and the units used for generated data.\n\n* Some of my devices have poor WiFi reception, so they slow down the other\n  devices on the network when they need to communicate. room-assistant generates\n  a lot of network traffic, with a full image being sent over MQTT every second\n  in addition to a fair bit of multicast traffic (which can be turned off, but\n  is enabled by default). r-u-still-there does not send images over MQTT (there\n  may be an option to enable this in the future, but not currently).\n\n* Some cameras offer extra capabilites that room-assistant doesn't expose. For\n  example, the GridEYE can be run at 10 FPS at the cost of increased noise in\n  the image. Most thermal cameras also have an ambient temperature sensor, which\n  is also exposed by r-u-still-there.\n\n[room-assistant]: https://www.room-assistant.io/\n[r-a_v2.12]: https://github.com/mKeRix/room-assistant/releases/tag/v2.12.0\n\nAll that being said, I'm still very thankful to room-assistant for inspiring me\nto create r-u-still-there.\n\n#### What are the warning messages about a measurement sink lagging about?\n\nThis usually happens if the CPU can't keep up with the frames coming off of the\ncamera. Try some of the suggestions above for reducing CPU usage.\n\n#### How can I stop r-u-still-there from crashing after a few minutes when using a Melexis Camera on a Raspberry Pi?\n\nThe Raspberry Pi's I2C clocks are based off of the core clock, and the core\nclock will (by default) vary based on the overall system's CPU usage. To stop\nthis, you need to set `core_freq=250`. It is also possible to set\n`force_turbo=1`, but be aware that if you have *any* of the `over_voltage_*`\nvalues set the warranty bit will be permanently set. See the documentation on\n[overlocking options][rpi-oc] for more details.\n\n[rpi-oc]: https://www.raspberrypi.org/documentation/computers/config_txt.html#overclocking-options\n\nIf you have `enable_uart` set, `core_freq=250` is implicitly set, so you don;t\nneed to make any changes *unless you have also disabled Bluetooth*.\n\nIf you hook a logic analyzer up to your I2C bus, this issue will manifest as the\nfirst few frames being transferred at full speed (default is 100kHz, but 400kHz\nis the recommended setting for r-u-still-there), then dropping to either 62.5%\n(older Pis) or 40% (Pi 4) of the normal speed.\n\n## Development\n\nThis repository should just build with `cargo` once checked out from git:\n\n```shell\ngit clone https://github.com/paxswill/r-u-still-there.git\ncd r-u-still-there\ncargo build\n```\nDevelopment builds turn the optimizations up, as it's unusably slow without\nthem.\n\n### Cross-compiling\nBuilding on the target device itself can be very slow, and the device may not\neven have enough memory. Thankfully cross compilation is pretty easy with Rust.\n\nWhichever way you end up building the package, if you're compiling the a 32-bit\nARM arhitecture you'll need to pass some extra flags through to the C compiler\n(replacing `cargo` with `cross` as needed):\n```shell\n# ARMv6, for Raspberry Pi 0 and 1\nTARGET_CFLAGS=\"-march=armv6+fp\" cargo build --release --target arm-unknown-linux-musleabihf\n# ARMv7, for earlier version of the Raspberry Pi 2 and BeagleBones\nTARGET_CFLAGS=\"-march=armv7-a+simd\" cargo build --release --target armv7-unknown-linux-musleabihf\n# 64-bit ARMv8, for Raspberry Pi Model 4\ncargo build --release --target aarch64-unknown-linux-musl\n```\n\n#### glibc\n\nThe easiest way to cross-build for glibc targets I've found is with\n[`cross`][cross]. It just works, and is also how the provided packages are built\n(along with [`cargo-deb`][cargo-deb]).\n\n[cross]: https://github.com/rust-embedded/cross\n#### musl static builds\nI use the musl targets for most of my development as they're easier to get\nworking when cross-building from a FreeBSD-based system. The musl-based targets\nare also a bit slower in my experience, so by using them for development I get a\nnice little \"performance boost\" for free when using glibc for the packages.\nI've found [musl-cross-make][musl-cross-make] the easiest way to get a native\ncross-toolchain set up. Once they're installed and available in `$PATH`, you'll\nneed to create `.cargo/config.toml` with contents similar to this:\n\n```toml\n[target.arm-unknown-linux-musleabihf]\nlinker = \"arm-linux-musleabihf-gcc\"\n\n[target.armv7-unknown-linux-musleabihf]\nlinker = \"armv7-linux-musleabihf-gcc\"\n\n[target.aarch64-unknown-linux-musl]\nlinker = \"aarch64-linux-musl-gcc\"\n```\n[musl-cross-make]: https://github.com/richfelker/musl-cross-make\n\n#### Packaging\n\nBuilding the Debian package is done using [`cargo-deb`][cargo-deb]. `build.sh`\nwill build each architecture using `cross`, then package it up, leaving the\n`.deb` file in the project directory.\n\n[cargo-deb]: https://github.com/mmstick/cargo-deb\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpaxswill%2Fr-u-still-there","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpaxswill%2Fr-u-still-there","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpaxswill%2Fr-u-still-there/lists"}