[HN Gopher] THC: Tight Home Control, automation framework in Tcl
___________________________________________________________________
THC: Tight Home Control, automation framework in Tcl
Author : blacksqr
Score : 60 points
Date : 2021-07-27 14:24 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| celeduc wrote:
| Side effects may include dry mouth, red eyes, and core dumps.
| asdff wrote:
| In all seriousness, naming your product after something
| established and in existence ensures I am going to never be
| able to find it again thanks to modern SEO practices. I
| remember in the 90s and early 2000s everyone named their
| product after a non English word as a rule to make it easy to
| trademark your product and for customers to search it out
| against common words. Today, everything is just some random
| clever English word. There is even a restaurant in my
| neighborhood called "Milk" now, the madness is overwhelming.
| BizarroLand wrote:
| There's a pretty good Danish music group who called
| themselves "The White Album", which sounds like a decent band
| name.
|
| They've been operating since 2011.
| https://en.wikipedia.org/wiki/The_White_Album_(band)
|
| They are incredibly difficult to find online because when you
| search for them the first who knows how many results are for,
| you guessed it, The Beatles' White Album.
| capableweb wrote:
| I'd agree with you, but searching for "thc github" right now
| on Google at least shows me this project on 7th place in the
| search results, even if the repository is relatively young.
|
| I'm sure you can do something similar by adding "Milk +
| $city" or "Milk + $street-name" to your other example.
| eurasiantiger wrote:
| Why not perl?
| zdw wrote:
| Any Tcl experts here that have opinions about CI tools,
| specifically code formatters (like `go fmt` or python's `black`)
| and other testing tools for use with Tcl?
| blacksqr wrote:
| The testing tool DejaGNU is Tcl-based. It's used for e.g. gcc
| and llvm.
| jvanderbot wrote:
| I can't find documentation on how to add a TCL wrapper for an
| interface to the sensors. Is this abstracted somehow?
| ajsnigrutin wrote:
| Just curious, why this instead of eg. home assistant?
| rkeene2 wrote:
| I have not used this (yet), but there are a lot of problems
| with Home Assistant, with the main advantage being that it has
| all the integrations already written and it works for most
| things almost all the time.
|
| Issues with Home Assistant as a developer of integrations:
|
| - internal inconsistent politics slow adding new developers
|
| - documentation is in sparse in many cases
|
| Issues with Home Assistant as an administrator:
|
| - The JSON database periodically corrupts itself
|
| - The two "core" and App Daemon components can't live in the
| same system, must use Python venvs
|
| Issues with Home Assistant as a user:
|
| - There are two ways to configure integrations: via config file
| and via DB, which is really obtuse and difficult to version
| control, also sometimes the same integration is configured
| twice, once in each method, and sometimes parts of the
| integration are split
|
| - Scripts in Home Assistant are linear steps, no branching.
| This is useful only in basic scenarios. There are three main
| ways of dealing with this with various trade-offs, and two of
| them are just moving the logic out of Home Assistant (python
| scripts, which run in a "safe" environment, and App Daemon
| which is unconstrained, but much heavier), with the third being
| using the templating system that's bolted onto the
| configuration system to generate dynamic conditional
| resolutions.
|
| - If there is an error in your script (because, e.g., a device
| is offline temporarily) the script will abort instead of
| continuing, which means for example if your air purifier stops
| working due to the cloud, your local A/C stops getting set -
| this is not resilient
|
| - The dashboard config (Lovelace) can be configured by the UI
| or config file (see above about integrations), but again it
| cannot be very dynamic in either scenario since the templating
| system cannot produce all possible configuration results, so
| for Lovelace's UI to be dynamic you need to write another tool
| to read the Home Assistant config and generate the resulting
| config (App Daemon can't directly do it)
|
| - Upgrading between versions of Home Assistant generally breaks
| things and you have to spend time fixing them
|
| That's most of the big issues that I can think of right now.
| madjam002 wrote:
| I've been running HA for 4 years and I've never had it
| corrupt, it's been the same install as well. That said, I
| agree the integration configuration is a bit messy, although
| recent updates have made this better.
|
| For automations and scripts, I use the built in automations
| for simple tasks (turn X off after Y minutes), and Javascript
| + Home Assistant JS + Generators for more complex
| automations.
| jjeaff wrote:
| I had corruption problems until I bought a high quality SD
| card for my raspberry pi. Then, I switched to an Intel NUC
| with an SSD and have never had any corruption in the 2
| years I have used it heavily.
| rkeene2 wrote:
| The issue appears to be that it updates that JSON file
| isn't re-written in atomic way
| throwaway1777 wrote:
| Niiiice, thc.
| na85 wrote:
| Wow, I have always been dubious of the claim that Tcl continues
| to be used in "behind the scenes" applications today. For a long
| time it was just (for me, anyways) That Thing You Have To Learn
| To Script Your Eggdrop Bot but it's a neat albeit quirky little
| language and evidently is used in at least this project!
|
| Kudos!
| AceJohnny2 wrote:
| Another anecdote: the MacPorts package definition files [1] are
| actually TCL programs. MacPorts itself is built on TCL [2]
|
| [1] Example portfile: https://github.com/macports/macports-
| ports/blob/master/shell...
|
| [2] Macports source: https://github.com/macports/macports-
| base/tree/release-2.7/s...
| flopp wrote:
| It's still highly used in the EDA industry - almost every EDA
| tool is scriptable with Tcl. There are even IEEE formats that
| are actually Tcl dialects, e.g. UPF (Unified Power Format) for
| describing power related features of circuits.
| [deleted]
| dexterhaslem wrote:
| once you recognize it, you may start to catch it in use in
| applications all over the place. if you ever use xilinx tools,
| ECAD, etc, you will see reams of tcl handling builds and
| project definitions
| kjs3 wrote:
| Also, Cisco IOS scripting.
| Brian_K_White wrote:
| This is a blast from the past. All the SCO Open Server 5 sys
| admin tools are tcl, both the curses and gui front ends. I
| haven't touched it since then. I had no strong opinion about
| it either way at the time.
| na85 wrote:
| My impression was that Tcl _used to be_ very popular for that
| sort of thing, but that it was supplanted by Lua, Python, and
| JavaScript.
|
| What makes Tcl compelling for those applications?
| buescher wrote:
| Network effects. John Ousterhout invented tcl in part to
| script/implement the Magic VLSI layout tool. So it's not
| surprising it's spread to other EDA applications.
| dexterhaslem wrote:
| that I couldn't tell you. I'd personally pick lua (or damn
| near anything else) first. maybe just entrenched
| knowledge/tooling in certain industries monster codebases.
| RHSeeger wrote:
| Personally, I'd pick Tcl long before Lua... but I'd pick
| almost anything before Lua; which I find frustrating to
| work with. There's a _lot_ of personal preference and
| "feeling" that goes into what each person likes in a
| language.
| SwSwinger wrote:
| TCL is quasi-religious. You either appreciate the simplicity
| and elegance of the 12 clearly ordered rules, or you think the
| nutbag scruffie programmer is talking to a burning bush.
|
| I learned TCL for adding an embedded scripting language to a
| company's command line in 2005. I originally cast derision, but
| have learned to appreciate its beauty after a wrote a couple
| API frameworks in it. I think it has a little less magic now
| that lambdas and other shorthand notations are commonplace.
___________________________________________________________________
(page generated 2021-07-27 23:02 UTC)