That post has sit on my browser bar for.. well over a decade at this point. I've read it once, found it neat and put it there. Never really looked at it again, but i see the favicon every day since years and years. At this point it's part of the furniture. Anyhow, funny how stuff becomes "home" for sometimes the most random reason...
Pumping water is useful only when coupled with increases in water retention and runoff prevention. Like what is happening in some (arid) places like Northwest India: https://www.youtube.com/watch?v=79VUAFq2rbg
Excercise absolutely makes you age better. Actually, it seems that in order to have a decrease in all-mortality you need to exercise quite a lot (at least 1.5hrs a day.. for the rest of your life).
Aerobic exercise of course means more caloric expenditure, which you should totally compensate, but that's not hard for regular folks who train, only for extreme athletes
If you really like swimming / football / cricket / basketball / hiking / climbing / whatever then it sounds like a great trade-off. More fun in exchange for better health is a deal anyone would take.
That makes kinda sense, a Tesla is mostly batteries anyway.
Jokes aside, how much batteries do you need? A Tesla Model 3 has 60kWh. That's a lot of battery. For my residential needs (I have solar panels) I would be looking at maybe 10kWh.
- What is your energy usage and peak demand during that time?
Peak demand is a big factor: a single Tesla Powerwall 2 for example has 13.5 kWh of capacity but only 5kW of continuous power. A heat pump or AC can exceed that, which is why many people stack multiple batteries to be able to power their homes. (The new Powerwall 3 can supply more power.)
depending on where you live, that's where grid pricing comes from.
I live in Italy and in my solar panels I have a kind of net-metering (not quite, since I need still to pay transports costs for the energy I buy back from the grid). In a year, they will phase out this regime and every person with a solar array will become a "producer". Energy company will pay the gross market price for the energy that you feed to the grid (and this price it's updated hourly if not more often). That will essentially do what you suggest: owners will start caring more about timing, and the grid will benefit. If you still don't care and want to feed the grid at the time when everybody else is also.. well the energy won't be paid much. And viceversa
I prefer the local 1:1 kW banking that my electrical utility company offers: rather than being paid, all my excess generation gets "banked" and I can use it during heating season.
Obviously, if you generate more than 100% of your needs, you're going to want to get paid.
However, despite being convenient for the user, it isn't great for the grid nor scalable if all users were to have solar panels. (Here in Italy solar on rooftops are quite widespread).
You can see that a kWh on a sunny summer noon when all panels the area are working well, isn't worth the same as a kWh in the cold winter night, where non-renewables often supply the grid.
> You can see that a kWh on a sunny summer noon when all panels the area are working well, isn't worth the same as a kWh in the cold winter night
Often by a huge margin. Electricity prices on the spot market can go negative, and that will happen more and more often in the future on sunny, windy days. Net metering at constant $/kWh prices is unsustainable, economically.
> generally when two satellites collide some debris can be shot at a higher orbit which will take forever (or will not) reenter atmosphere.
The lowest point of the new orbit (perigee) is guaranteed to be no higher than the point of collision. Fragments after the collision have no further propulsion, so their new orbit must initially include the point of collision, and can only decay from there. This can also be seen on your scatterplot.
Moreover, the time to decay is most strongly influenced by the perigee, as the atmosphere is the strongest there. If a satellite on an low orbit (decay in decades) explodes, those fragments that "reach a higher orbit" will still (due to the low perigee) decay back to a near-circular orbit in decades.
A collision can increase the lifetime for some of its fragments, but not by multiple orders of magnitude (unlike a circular higher orbit).
Your video link also nicely shows that fragments with a low perigee will decay quickly, no matter how high their apogee is.
Yes, this is true, but for this to not be a problem, it also has to suppose that those higher-flying bits of debris don't subsequently collide with other higher-flying satellites.
The Chinese test also happened around 350km higher then Starlink satellites (850km). The natural deorbit time at that altitude is already over 100 years vs under 5 years at 500km.
Also it was literally the worst possible collision being an intentional head on collision. Satellites accidentally hitting each other on orbit are very unlikely to hit each other head on as it is very uneconomical to put satellites in a reverse orbit that low (there is a reason why we do rocket launches towards east if possible)
I love Home Assistant. I only started using less than a month ago (moved into a new house).
However, the two times i needed to upgrade Core (I use Home Assistant OS, their recommended installation procedure), it broke.
The first time they had changed the spec of the 'correct' way of the YAML config file. Which means I didn't have an integration until i fixed the file manually (they deprecated something not gracefully).
The second time I don't know: I couldn't see anymore my Viessman Heater and check everything related to my hot water / heating so I gave up and rolled back.
I am a Clojure developer where there's almost never breaking changes, so this is a good reminder to not take that for granted. I think this is an aspect they have to improve a lot, if they want to cater to people who don't want a new hobby.
I've been using Home Assistant for several years and I can count on hand the number of times I've had breaking upgrades. These were always pretty clearly explained in the release notes. I think the nature of the broad scope of Home Assistant is such that different users may have very different experiences depending on what integrations they use. But I don't think it's generally as bad as your comment suggests.
> I think the nature of the broad scope of Home Assistant is such that different users may have very different experiences depending on what integrations they use.
I think this is a common problem with "hub" projects that intend to bridge together multiple incompatible technologies. I work in VoIP and have been using Asterisk in one way or another for over 20 years. That project is even named after the wildcard character because originally it was intended to be able to connect any kind of telecom technology from analog to TDM to all sorts of VoIP.
As the world moved on and most everyone has standardized around SIP as the future those of us who run all-SIP systems and/or common analog/TDM interfaces have generally been able to upgrade willy-nilly with little to no trouble, but there's always "that one guy" who has rigged up something where a call comes in over a SIP-GSM gateway, gets sent over an H.323 trunk to another box elsewhere in the world, then rings to a SCCP phone and of course they're always having issues because no one else is doing anything close to that.
HA has that problem to an exponentially larger degree because at least the telecom world theoretically has widely accepted standards that most equipment uses where home automation gear has a few competing standards alongside hundreds of vendor-specific APIs that may or may not be documented or even officially open for use.
Someone who is just using HA to unify their lighting control across a few vendors using well-tested Zigbee and Z-Wave implementations is going to have a much easier time than the people who have rigged up a Rube Goldberg machine of integrations of varying quality.
I've only recently (less than a month ago) started to use HA and I have polar opposite impression from you.
I gave up on updating because the 2 times i updated the HA Core package and the OS most of my integrations broke. The first time i bothered changing the config. The second time I decided to rollback and keep everything as is.
Maybe the issue is that you used the "Core" installation method which isn't a fully managed installation and only really there for "advanced" use cases. It has this warning above the installation steps:
> This is an advanced installation process, and some steps might differ on your system. Considering the nature of this installation type, we assume you can handle subtle differences between this document and the system configuration you are using. When in doubt, please consider one of the other installation methods, as they might be a better fit instead.
I use the container installation method and it's usually as simple as updating the version number in Docker Compose and restarting. I'd imagine the full OS image is even easier and more stable.
I use what they recommend: I installed Home Assistant Operating System on a Raspberry PI 3. Which still means there's an OS and there's HA Core.
> Home Assistant Operating System: Minimal Operating System optimized to power Home Assistant. It comes with Supervisor to manage Home Assistant Core and Add-ons. Recommended installation method.
I tried on purpose to do everything as 'basic' as possible because I don't want to spend time making sure it keeps working.
Ah ok, I misunderstood then. I presumed if you used the OS installation method then the upgrade was done from within the web UI, but I maybe have misunderstood that too.
no idea why it's recommended to install manually; I'd recommend docker every time. currently running on docker and upgrading was indeed just pulling new images (didn't even have to tweak the compose file, just docker compose pull). There's been a few helpful UI messages about outdated integrations in the config (e.g. workday detection moved to UI config, used to be yaml).
I don't think the problem is how to update: it's easy enough in the interface, it just works. The problem is whether after the upgrade you suddenly don't see the heater anymore, or another device stops working.
> I'd imagine the full OS image is even easier and more stable.
It notifies you when there's an upgrade, you just click "Install" in the GUI.
That said, every time I update it the disk image grows by like a full gig. Haven't figured out where that's going so I just don't update it anymore. It's running on a minimal headless computer and doesn't have enough space to keep doing that.
I think it really depends on when you entered the ecosystem and the maturity of the integrations you're using. HA has some contribution standards but you can get plenty of "I made this in my freentime and upstreamed it" integrations that end up going through major renovations. Sometimes vendors take notice and also weigh in.
Additionally, if you got in ~5 years ago when it was pure yaml, it seems a couple times a year there's breaking changes where more yaml is ripped out and manual reconfig is necessary (it'd be nice if it just migrated the config for you)
Yeah like others suggested, maybe it has to do with the installation method. I'm using a Home Assistant Blue. It all came configured, I'm clicking "update" a couple of times a month and never had the slightest issue.
it's simply not published in a peer-reviewed journal, but it is published on arXiv, as per definition of 'publishing', i.e. "the business of making books, magazines, or newspapers available to the public" (https://dictionary.cambridge.org/dictionary/english/publishi...)
True, but in academia and R&D, when researchers talk about "publications" they always refer to peer-reviewed journal publication unless stated otherwise.
