I basically do the same as the author but use nutshell and its powerful pattern matching [0] as the router
-[0] https://www.nushell.sh/cookbook/pattern_matching.html#patter...
I’ll also echo the sibling commenter re: running it for years with no maintenance besides occasionally installing the updates.
Just to be clear, the one paragraph that indirectly references HA was not intended as "hate". It was intended solely as gentle mockery and a bit of humour. I think it should be very clear from the article that my Mosquitto + Z2M + mqttr + bash + jq solution, while feature-complete for my purposes, is not a competitor to HA, which I have never used or tried.
Why have I never tried HA? To run it, I would need to either create a VM or buy dedicated hardware. First, I don't want any more dedicated hardware in my house. Second, I like to keep the number of hosts I need to secure, manage, and keep running to a minimum. Third, from what I've heard (from people insisting it can't run on cheaper SBCs), it's not light; I was genuinely concerned about the server load on my single, low-power home server which already handles other things.
I imagine that for many people, Home Assistant works great: the UI is what they like, it never breaks, and they never have to troubleshoot it. Or, if it does break, they're satisfied with just backing up their configuration and reinstalling it.
But for me, when it comes to things I set up in my own time for my own use, I like to understand everything I am managing so I can quickly understand any failures. If I am going to use a ZBMINIR2 in detached mode to have my smart lights effectively on 100% of the time with the only method of control being Zigbee + glue, the glue had better be: a. rock-solid, b. trivial to troubleshoot, and c. easy to fix. I am not confident that I could learn, and retain, enough knowledge about HA to be able to achieve those three goals.
Lastly, I have extensive experience of DIYing my own solutions to problems for which working off-the-shelf solutions exist. This is not because I am a contrarian who hates everything that works, although maybe there's a tiny bit of that. The reason I didn't use HA wasn't because I hate it; I didn't use it because I wanted the pleasure of solving that problem myself.
As for Home Assistant, I share your sentiment. I run my own stuff because I want to understand my infrastructure (vs. a black box from Philips) and to minimize the amount of code running around.
I'm sure HA is a better opaque box than the commercial ones for many people, but running it would still leave me with the same feeling of having outsourced critical knowledge - plus the compute costs.
That aside, I'm currently contemplating whether running TrueNAS Scale for web apps is really necessary. I like the fact that I only need to click a few buttons or fill in a few fields, but on the otherhand my setup can be kept inside a docker-compose.yml
We'll never know, since I like the safety of running my apps through something like TrueNAS Scale. It feels professional
Who’s gonna tell him
Rediscover•7mo ago
tecleandor•7mo ago
enriquto•7mo ago
You don't seem to respect the old, venerable, well-tested adage: "once your shell script becomes too complex, switch to a real programming language like python".
Or, the zen version (formally equivalent, but with quite a different tone): "once your program becomes sufficiently simple, turn it into a beautiful shell script".
skydhash•7mo ago
endofreach•7mo ago
one might awk how much logic one can bash into a script before leaving the beloved shell
skydhash•7mo ago
alganet•7mo ago
https://wiki.ubuntu.com/DashAsBinSh#Why_was_this_change_made...
> [bash] is rather large and slow to start up and operate by comparison with dash
For more complex regular expressions, you can use `sed`.
--
It's all a matter of context. Sometimes simple ## and %% param substitutions are the best tool for the job.
I think bash is a fantastic interactive shell and a lousy script runner.
Calzifer•7mo ago
One reason why I personally prefer to use Bashisms like ${x//str/replace} or [[ $value =~ $pattern ]] instead of doing the common x=$(echo $x | sed s/str/replace/) which has to launch two processes just for the sake of avoiding Bashism. (or grep -oP ... which is nice but a BASH_REMATCH is often simpler)
Ferret7446•7mo ago
alganet•7mo ago
Practically all shell interpreters suffer from decades of feature creep since the original bourne shell. They're full of weird arcana, hard to maintain and debug.
Many people tried to replace bash and died on the hill because of these weird features, or ended up creating a replacement that is even slower, or ended up rediscovering what perl is.
alganet•7mo ago
I prefer no fork, no bashism, reusable functions:
Not exactly easy to write, but now that they're functions, it doesn't matter since I can reuse them.Regarding performance, it is slower than bash, but not significantly.
Times for 1000 calls:
Times for 50.000 calls: Also, you can get further performance by inlining replace inside replace_all instead of making one call another.Note that I could have done several replacements inside a single sed pipe, but I decided to count the performance for doing it like you suggested x=$(echo $x | sed s/str/replace/). The same goes for my functions, one invokation per replacement (in fact, they are tuned for that scenario).
sed can absoltely beat the shell in scenarios where you can make one fork do lots and lots of replacements. It depends on the scenario, and how proficient you are in writing sed (which can do branching, keep state, all sorts of things portably).
--
From an architectural point of view, it makes sense to have a simpler `sh` and keep a sort of standard library of functions, instead of feature creeping the interpreter with weird arcana. It makes shells like dash easier to maintain, easier to debug, easier to port and safer.
couscouspie•7mo ago