Furthermore, that group may also just pull weather data directly instead, so may not need something like this.

Originally, this started as a Home Assistant automation for myself. I realized it doesn't actually require any sensors, just a location, so I decided to build something anyone could use.

Originally I built this for myself only as a Home Assistant automation and had been using it for years.

PorchWeather watches one saved location and a set of conditions you pick (temperature range, wind, rain, dew point, air quality) and sends you a notification when conditions become nice, and another when they stop. That's the whole product. It's free, web-native (not an app), and notifications are browser push or email.

Some implementation details HN might find interesting:

Stack: SvelteKit SPA, Rust backend, DynamoDB, Cognito for auth, SES for email, Self-hosted Open-Meteo for weather all on ECS Fargate. The weather layer serves ECMWF global plus NOAA HRRR at 3 km resolution for the US.

Notifications are primarily through web push. I'd love to do SMS through twilio, but it seems prohibitively expensive for a free service unfortunately. iOS devices make this a little harder because you have to "install" the app on the home screen to get push notifications. I may end up creating an app at some point to make this easier if there's demand.

Comments URL: https://news.ycombinator.com/item?id=49484064

Points: 1

# Comments: 3

Tracks temp, humidity, wind speed, and precip chance and you set the parameters.

Notifications are currently email and web push. SMS is too expensive to run as a free service. I think the next direction is probably an app, as web push support in iOS is not great.

Range of temperature is the big one for rules, but you can also require humidity, wind speed. Eventually would be nice to add air quality if there's a sensor nearby.

You don't need any local devices - sensors, motors, etc. You just get an email/text/web push of your choice when the weather is nice and some fresh air is freely available.

I've had a home assistant routine for this running for myself for years, but the 80% version requires nothing more than weather data. Human in the loop automation (I physically open/close the windows).

I think they move from the wind and eventually wear through.

https://www.nbcbayarea.com/investigations/new-images-of-pge-...

Batteries on the other hand feel like they take less space and thus could be colocated near consumption without having to be on consumer property. Warehouse size within the city. Transmission costs would be minimal.

There's also a distributed version, easy with a map reduce.

Or the very simple algorithm: generate a random paired for each item in the stream and keep the top N ordered by that random.

IMO, that's sort of what a standard is, but the words is not strictly defined.

I think you are trying to argue that it's not open. The source is on github, and does accept contributions, but effectively Google controls who can commit to it. Depending on your definition of open, that's a valid argument.

You can load those libraries from other locations, but Google search results won't be able to cache it because of the privacy concerns I mentioned in my top level comment. It's not "valid", but the only consequence of the invalidity is no caching, and that consequence is unavoidable given the privacy constraint. It still shows up in search results.

The Google javascript library URL serves with no cookies, is publicly cacheable, and is an identical file to what you can build from source on github.

> Build an AMP site, and you’d get preferential placement in search results ... The implicit stick, though, was that without an AMP page, your site wouldn’t rank as highly as it may have previously. And

There was an AMP news carousel that would appear at the top news results. The web result order however didn't prefer AMP. Depending on how you looked at it, this was preferential or it wasn't. The "wasn't" perspective is that this carousel was much like showing image or video results - it was a different format and there was a result spot reserved for some docs of that format if the query warranted it.

Interestingly, when Google first started rolling out carousels for images or videos in normal results, website owners protested as well as it was competition for visibility. I don't hear that argument as much any more.

Regardless, the AMP carousel has been gone for a while AFAIK.

> “We are here to make the web great again,” said Google’s vice president of news, Richard Gingras in 2015, only months after Donald Trump brought that phrase into the vernacular

Yeah, that aged poorly.

> [AMP] brought back the dynamics of the mobile versus the desktop web, for one. Instead of the same web for everyone, you now had one page on mobile, another page on desktop

That was a website owner choice. AMP pages could be responsive and work just fine on desktop. Many sites did exactly that, though you often never realized they were AMP pages. The goal of the project was always to optimize mobile performance, but it worked well for desktop too. Search provided a mechanism where you could choose to pair an amp and non-amp page, only showing AMP for mobile. I suspect sites did this because non-amp allowed all of the bespoke javascript they wanted on desktop, including things that were kinda terrible for user experience but improved ROI. Super heavy javascript, ads that were difficult to dismiss, all sorts of jank.

> And, more critically, it lessened your control over your site. ... ad tech and other scripts on your site might be incapable of running on your AMP site

AMP is a subset of HTML plus some javascript libraries. The subset thing means you had a limited API. That was the point though, the limited API was restricted to the set of things that could be forced to be performant. That is "control" in some sense, but it wasn't control in the common sense of limiting content or ad networks or whatnot. Virtually every ad network had a library for running on AMP.

> AMP required allowing any AMP CDN to cache your pages.

You can and always could create amp pages that are not served by AMP CDNs. The tradeoff is that search results couldn't preload the page for the user, as there is a hard privacy constraint that the user can't initiate network traffic to the publisher until they indicate intent with a click. So without the CDN, it wasn't quite as fast, but it was still typically pretty fast.

> As Ray Tomlinson, who implemented and sent the first email from ARPANET in 1971 said about adding formatting to email: “That’s too complicated: we just want to send messages to people.”

This is a valid perspective on what email is or should be. I don't feel strongly that it's the only perspective, but it's certainly valid. The argument however is really against HTML email, not AMP email in particular. I think most of the rest of the arguments apply pretty equally to both.

If you look at HTML email in webmail clients, clients all work on the principle of sanitization. Take arbitrary HTML, modify it to remove anything dangerous, and then render the rest. "anything dangerous" requires removing all javascript, most or all CSS, large swaths of the HTML tag space, rewrite all image URLs, etc.

This would result in pretty garbled results except senders have adapted to only send the subset of HTML that won't be garbled. However, it's not easy to do. Take a look at https://templates.mailchimp.com/resources/email-client-css-s... which shows what each email client accepts. It's much much worse than browser incompatibility, though you also have to handle browser differences too.

In a sense, this limited HTML API is similar conceptually to AMP. AMP just was able to add back some of the interactive functionality stripped away. And AMP had the possibility of becoming a open-source standard compatibility API for webmail clients. One that was open source, had maintained validators that could be tested against, etc.

I think it had the chance to really make HTML email better. Of course, if your perspective is that HTML email is fundamentally bad, then that's not really a win.

> You’d need to authenticate your domain with DKIM, DMARC, and SPF—good ideas, regardless. You’d also need to send a sample email to both Google and Yahoo!, and register your domain with each of them. Then, if you were lucky, within 5 days you’d be approved to start sending AMP emails.

I think the plan was always originally to expand this to a general availability format. However, AMP email launched in 2019 and Google largely shifted away from AMP shortly thereafter, so the project never got enough momentum to get to that state, sadly IMHO.