There already exists "kinetic" switches for lights etc whose switch contains some passive electronics that when actuated produces enough energy to emit a radio signal that can be read by a relay module. They're pretty handy as you can basically place the switch anywhere you want without the need for the wires to be there. The relay can live in the light fitting or somewhere else convenient.

There's probably no reason why these kinetic switches can't also be used for detecting other events like doors opening/closing etc. I feel like a radio signal is a bit more reliable and easier to detect than high frequency sound.

I also think calling these a "sensor" is a bit of a stretch. They detect events but have no knowledge of the current state of the thing they're sensing. E.g. the can detect a door opening/closing, but have no idea if the door is open or closed at a given time

Piezo harvesting switches and similar (I think there’s a flywheel design out there too) are quite expensive, not terribly reliable or consistent, and require substantial activation force. Conventional switches and batteries that can last for years in remote push buttons and sensors are extremely inexpensive in volume.

The ones I have in my house [0] were not that expensive and have been quite reliable for years now.

[0] https://www.amazon.com/dp/B09MHL8QTC

Do you know of any where the receiver plugs into an existing outlet and has an inline receptacle for the controlling device already wired up?

No, but the one I linked could be wired up that way with a pigtail plug & receptacle, although it'd be pretty big and unwieldy.

That's not really true. We've used these for years to control our Hue lights, and they're fantastic: https://www.amazon.com/dp/B07MMWH2YB

The Quinetic switches I use are extremely reliable and consistent. I've been mentally making a note of when the switch does not trigger the light, and it actually hasn't happened once yet and I've been using them for about 10 years.

You're right that they're expensive and need a decent activation force. They also are quite large and make a quite loud clicking noise which might be annoying for a sensor application.

Lmao no, my doorbell is one (doesn't have a battery at) and has been going for 7 years strong, as long as I've lived in this place.

Sure you have to press it very slightly harder than a regular switch and the travel is a little more, but not by much.

I think the doorbell cost like £20 in 2020, actually lemme check Amazon...ah in fact it was 15.99£ (now it's £20.99 hmmm) "TECKNET self powered doorbell".

> I also think calling these a "sensor" is a bit of a stretch.

Indeed. At best, they're an "emitter", a "proxy", a "relay", a "transformer", or some combination thereof with "sense" or "marshall" that indicates the transformation of input to output a la "sense proxy emitter" or "marshalling sensor".

I use these kinetic switches all the time (the Quinetic brand is great and reliable; I've tried a Chinese one once and it died after a few months).

They're good but relatively expensive and relatively large. So I can kind of see why this might make sense. On the other hand having to put ultrasonic microphones all through your house is clearly much worse than a radio receiver, so I'd say these are a bit of a gimmick still.

> for detecting other events like doors opening/closing etc.

If any of those doors are important for security, then I'd want something an intruder can't easily jam or spoof.

A big benefit of piezo-powered electronics is that they can do all the usual stuff, such storing state, or cryptography to prevent spoofing, which the ultrasonic approach from the article cannot do.

Interesting to see Spain having such low IPv6 adoption. Perhaps that's exacerbated the issues caused there by blocking IPs during football matches that we've seen mentioned in recent HN posts.

Spain has one of the highest FTTx rollouts in Europe though. My theory is that they just prioritized building fiber and there was no money left for ipv6 transition.

Are you with SFR? I also seem to only have a static IPv4 (I don't pay for it, but it's never changed in the lifetime of the connection). I asked for an IPv6 but they said it was not possible/difficult.

Yep, with "RED by SFR" specifically.

Among all the major French providers, SFR lags far behind its competition unfortunately

I know, but at the time I had to choose an ISP, they were the only ones with an offer with just internet (and a phone line), all others ISP forced a bundle with dozens of TV channels that I don't need along with their internet access subscription. They were also the most competitive price wise, and other than this problem (which is new for me, I had an IPv6 and a static IPv4 until a few weeks ago), I'm satisfied with the service :).

I believe the full docs page does indicate that there are binaries to install via popular package managers [1]

[1]: https://docs.jj-vcs.dev/latest/install-and-setup/

I did check that page, as far as I can tell you still need to run Cargo which I don't want to do because I don't care about Rust.

I'm not complaining for the sake of complaining, I'm saying if they want to play in the Big Boy leagues, they need to do things right.

You do need Cargo to build from source.

If you're on Arch, gentoo, or openSUSE, you can use the package. It is true that Debian has not packaged jj yet.

It'll get there, and it's fine if you'd rather wait until things are more mature.

It's available in Debian sid, although a few versions behind: https://packages.debian.org/search?searchon=names&suite=all&...

You know, I went and searched before I posted. I wonder why it didn’t come up! Thanks.

Thanks! I hope I didn't come off as too dismissive, I'm hearing a lot of good things about Jujutsu. As a developer though, I've never wanted to build from source (probably in the minority on that front).

Nah, you're right that installing a compiler toolchain to build a project is a pain in the butt if you don't already have it. It's a legitimate thing, but it does mean that you won't be adopting more cutting edge tools, which is also just fine! I've done the same with projects built with tools I don't have installed too.

The other replies answer this question, but it’s worth mentioning the public suffix list which contains a list of domain suffixes that have subdomains that are controlled by different people. E.g github.io, wordpress.com

Browser use this list to prevent cookie shared between sites using the suffixes on the list. E.g evil.github.io will not receive cookies from nice.github.io, or any other .github.io origin, regardless of the SameSite attribute

Some of United's own aircraft are over 30 years old [1]. If you can rely on a well-maintained 30+ year-old aircraft to fly you halfway accross the world I think you can rely on a similar-aged car to drive across the country.

[1]: https://www.planespotters.net/airframe/boeing-767-300-n641ua...

No, because unlike a password you never provide the private key for a passkey to the site you’re logging into, which is how many password breaches occur.

Or putting `|> dbg()` at the end and let it print the value at every step of the chain

It's not clear text by default, it's just not end-to-end encrypted. Messages are still encrypted between client and server.

I agree about considering alternatives though.

> Messages are still encrypted between client and server.

This is just a clever way of saying they use TLS, which I would be shocked if any mainstream app is not using.

Don't look under the hood at sms then

SMS is never claiming to be E2E nor is any army of SMS defenders online talking about how some virtue of SMS is almost same as E2E. While I don't like Telegram I will happily admit it is better than SMS, but how is that an argument for anything.

SMS isn't an app, it's a protocol that was created in 1992.

Ok so theyre plaintext on the server, encrypted in transit just means https

Is the server -> FSB connection encrypted?

I wonder if it would be possible to figure out which pins are connected to what on the device's board and just flash the thing completely with ESPHome and write a custom yaml config for it, rather than adapting the existing vendor firmware.

It's certainly possible. Tracing the MCUs IO lines to LEDs/buttons/relays etc on a PCB is usually pretty straightforward.

I have just finished doing this and writing replacement firmware for the Aqara E1 series of Zigbee switches, after getting fed up with them not supporting basic Zigbee binding functionality.

Amazing. I have the Aqara Z1s and it has the SI labs MG24 chip. Ive always wanted to reflash it because I believe it supports thread at a hardware level.

It would be really easy. I'm not sure why the author has gone through so much effort to hide what filter this is, but I'm assuming J2 is the blower power output and J3 is touchpad controls.

I've done exactly this on my own air filter, and it's about 200 lines of config. The hardest part is mapping binary outputs to a percentage:

    switch:
      - platform: gpio
        pin: GPIO21
        id: fan_low
        interlock_wait_time: 250ms
        interlock: &interlock_group [fan_low, fan_mid, fan_high, fan_turbo]
      - platform: gpio
        pin: GPIO25
        id: fan_mid
        interlock_wait_time: 250ms
        interlock: *interlock_group
      - platform: gpio
        pin: GPIO22
        id: fan_high
        interlock_wait_time: 250ms
        interlock: *interlock_group
      - platform: gpio
        pin: GPIO17
        id: fan_turbo
        interlock_wait_time: 250ms
        interlock: *interlock_group
    output:
      - platform: template
        id: fan_speed_output
        type: float
        write_action:
          - lambda: |-
              id(fan_low).turn_off();
              id(fan_mid).turn_off();
              id(fan_high).turn_off();
              id(fan_turbo).turn_off();
              auto light = ((AddressableLight*)id(status_light).get_output());
              for (int i = 6; i <= 9; i++) {
                light->get(i).set(Color::BLACK);
              }

              if (state < 0.24) {
              } else if (state < 0.26) {
                id(fan_low).turn_on();
                light->get(6).set(Color(255,0,0,0));
              } else if (state < 0.51) {
                id(fan_mid).turn_on();
                light->get(7).set(Color(255,0,0,0));
              } else if (state < 0.76) {
                id(fan_high).turn_on();
                light->get(8).set(Color(255,0,0,0));
              } else {
                id(fan_turbo).turn_on();
                light->get(9).set(Color(255,0,0,0));
              }
              light->schedule_show();

    fan:
      - platform: speed
        name: "Filter Speed"
        output: fan_speed_output
        speed_count: 4
        id: my_fan

On top of that, it looks like it would be relatively easy to spoof the cloud server and make the device believe that there is a firmware update available to then feed it esphome, a bit like the switchbota hack.

That would've been my go-to, and has been with most of the other "smart" devices in my house.