OpenGarage-Firmware
nixpkgs
Our great sponsors
OpenGarage-Firmware | nixpkgs | |
---|---|---|
62 | 974 | |
272 | 15,656 | |
0.7% | 5.3% | |
4.2 | 10.0 | |
8 months ago | 3 days ago | |
C++ | Nix | |
GNU General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
OpenGarage-Firmware
- Chamberlain blocks smart garage door opener from working with smart homes
- Home Assistant blocked from integrating with Garage Door opener API
- MyQ's horrible take on open access to their devices
-
How Do We Lobby MyQ to provide a decent API?
Personally I went with OpenGarage https://opengarage.io/. I have been using OpenGarage for 3+ years now. It has been amazing.
- Ask HN: How do I make sure my mom's garage door is closed?
- Q: How does my 2-wire garage door remote know if my garage door currently up or down?
-
My first Arduino project sends me a text if my garage door is open at 9:30 PM each night.
If anyone is lazy, but wants the functionality and insists on open source….check out https://opengarage.io/ ($50) which offers similar functionality. I switched to a MYQ door opener which made the opengarage need obsolete, but I’ve been happy with MYQ - however it does require cloud access.
-
Meross > MyQ garage door opener
I switched to opengarage.io - after trying a few garage door automation devices that utilized door sensors.
-
Matter 1.1 release – Enhancements for developers and devices
I recently got some Matter-capable IoT lightbulbs to try, and I am not impressed. They seemed to have all the same problems I've experienced with previous IoT products (connectivity issues, state de-sync between device and "edge router", firmware updates take ~10 minutes per device).
Then there are problems specific to Apple's IoT stack - like how it's impossible to set an RGB capable light to a ~specific~ white color temperature. Instead you get a shade picker and you have to guess what the color temperature is.
The best IoT experience I've had is with OpenGarage[1] using regular old WiFi, but overall I'd still never rely on IoT products for anything critical.
[1] https://opengarage.io
-
Garage Door openers... can you use a wireless sensor instead of the cabled one?
I got a opengarage thing instead. No door sensor. Uses ultrasonic sensor to see if the door is open or closed. All one piece, hardwired to power. It's been rock solid.
nixpkgs
- Maintainers Leaving
-
Air Force picks Anduril, General Atomics to develop unmanned fighter jets
https://github.com/NixOS/nixpkgs/commits?author=neon-sunset
-
Eelco Dolstra's leadership is corrosive to the Nix project
I see two signers in the top 6 displayed on https://github.com/NixOS/nixpkgs/graphs/contributors
-
3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup
For a single file script, nix can make the package management quite easy: https://github.com/NixOS/nixpkgs/blob/master/doc/languages-f...
For example,
```
- NixOS/nixpkgs: There isn't a clear canonical way to refer to a specific package
-
NixOS Is Not Reproducible
Yes, Nix doesn't actually ensure that the builds are deterministic. In fact it works just fine if they aren't. There are packages in nixpkgs that aren't reproducible: https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aiss...
-
The xz attack shell script
I'm not familiar with Bazel, but Nix in it's current form wouldn't have solved this attack. First of all, the standard mkDerivation function calls the same configure; make; make install process that made this attack possible. Nixpkgs regularly pulls in external resources (fetchUrl and friends) that are equally vulnerable to a poisoned release tarball. Checkout the comment on the current xz entry in nixpkgs https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/comp...
-
Debian Git Monorepo
NixOS uses a monorepo and I think everyone's love it.
I love being able to easily grep through all the packages source code and there's regularly PRs that harmonizes conventions across many packages.
Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing.
https://github.com/NixOS/nixpkgs
-
From xz to ibus: more questionable tarballs
In this specific case, nix uses fetchFromGitHub to download the source archive, which are generated by GitHub for the specified revision[1]. Arch seems to just download the tarball from the releases page[2].
[1]: https://github.com/NixOS/nixpkgs/blob/3c2fdd0a4e6396fc310a6e...
[2]: https://gitlab.archlinux.org/archlinux/packaging/packages/ib...
-
GitHub Disabled the Xz Repo
True, but irrelevant -- _some packages_, _somewhere_, do depend on xz, which, if built, requires pulling the source from GitHub (see the default.nix: https://github.com/NixOS/nixpkgs/blob/nixos-23.11/pkgs/tools...)
It's not the vulnerability that's a problem right now (NixOS was protected by a couple of factors) but rather GitHub's hamfisted response.
That is the problem.
What are some alternatives?
WiFiManager - ESP8266 WiFi Connection manager with web captive portal
asdf - Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
ArduinoJson - 📟 JSON library for Arduino and embedded C++. Simple and efficient.
Home Manager using Nix - Manage a user environment using Nix [maintainer=@rycee]
meross-homeassistant - Custom component that leverages the Meross IoT library to integrate with Homeassistant
git-lfs - Git extension for versioning large files
ratgdo
easyeffects - Limiter, compressor, convolver, equalizer and auto volume and many other plugins for PipeWire applications
SmartThings_MyQ - Integrate SmartThings with MyQ (Obsolete)
spack - A flexible package manager that supports multiple versions, configurations, platforms, and compilers.
blynk-library - Blynk library for IoT boards. Works with Arduino, ESP32, ESP8266, Raspberry Pi, Particle, ARM Mbed, etc.
waydroid - Waydroid uses a container-based approach to boot a full Android system on a regular GNU/Linux system like Ubuntu.