solidgrue

You can use trigger IDs and conditional execution to accomplish this. Not precisely your use case, but I have an automation that manages two ornamental lamps via two smart buttons: one lamp and one button on each nightstand to either side of the bed in our main bedroom.

A single click of either button toggles the lamp on that nightstand. A double click on either button turns off both lamps, and a long press on either button calls a script that turns off all the lights inside and outside the house, by area.

I use trigger IDs to tag the button events, and then use that ID in conditional action logic to toggle the lamps, turn them off, or call the shutdown service.

You can probably use trigger IDs for your upper and lower bounds to conditionally execute your air conditioner functions.

Here's the YAML, if you'd like to see how I use it.

alias: "QoL: Bedroom Smart Button Features"
description: |-
  Short press toggle local ornamental lamp (amethyst, salt)
  Long press turn off both ornamental lamps
  Double press call Shutdown Everything automation
triggers:
  - device_id: b11766b6ab9a7ae6f752e70514562f18
    domain: zha
    type: remote_button_short_press
    subtype: button_1
    trigger: device
    id: bedroom_button_short_press_right
  - device_id: b11766b6ab9a7ae6f752e70514562f18
    domain: zha
    type: remote_button_double_press
    subtype: button_1
    trigger: device
    id: bedroom_button_double_press_right
  - device_id: b11766b6ab9a7ae6f752e70514562f18
    domain: zha
    type: remote_button_long_press
    subtype: button_1
    trigger: device
    id: bedroom_button_long_press
  - device_id: 2a9e9c869c5e611e791232491169da77
    domain: zha
    type: remote_button_short_press
    subtype: button_1
    trigger: device
    id: bedroom_button_short_press_left
  - device_id: 2a9e9c869c5e611e791232491169da77
    domain: zha
    type: remote_button_double_press
    subtype: button_1
    trigger: device
    id: bedroom_button_double_press_left
  - device_id: 2a9e9c869c5e611e791232491169da77
    domain: zha
    type: remote_button_long_press
    subtype: button_1
    trigger: device
    id: bedroom_button_long_press
conditions: []
actions:
  - if:
      - condition: or
        conditions:
          - condition: trigger
            id:
              - bedroom_button_short_press_right
    then:
      - action: light.toggle
        metadata: {}
        data: {}
        target:
          entity_id: light.salt_lamp_switch
  - if:
      - condition: or
        conditions:
          - condition: trigger
            id:
              - bedroom_button_short_press_left
    then:
      - action: light.toggle
        metadata: {}
        data: {}
        target:
          entity_id:
            - light.amethyst_lamp
  - if:
      - condition: or
        conditions:
          - condition: trigger
            id:
              - bedroom_button_long_press
    then:
      - action: light.toggle
        metadata: {}
        data: {}
        target:
          entity_id:
            - light.salt_lamp_switch
            - light.amethyst_lamp
  - if:
      - condition: trigger
        id:
          - bedroom_button_double_press_right
          - bedroom_button_double_press_left
    then:
      - action: light.turn_off
        metadata: {}
        data: {}
        target:
          entity_id:
            - light.amethyst_lamp
            - light.salt_lamp_switch
mode: restart

Another idea, you could use a wait_for action in the turn_on action to wait for a lower bound trigger to execute your turn_off action. I've used that for actions that turn on a light when motion is detected, and then wait for motion to clear before turning off the light.

Really, you could peel.it a bunch of different ways, but these are trucks I've used in my automations.

Don't.

I use /srv/[service] for services by the same logic, and leave /opt for local user apps. It's kind of a coin toss though. On another day I night have decided differently.

As it happens I’m actually looking for a smart lamp switch if anyone knows of any options

I was doing the same myself earlier this year. I'd found a European product that was an inline smart switch, like one of those rocker switches they put on the wire for those decorative canister uplights. The switches were out of stock on all the sites that listed it, and the manufacturer website didn't seem to indicate they'd be producing more any time soon.

Eventually I just settled on using an inexpensive smart button (Tuya TS0041/TZ300 over ZHA) to control a smart bulb or a smart plug on the "dumb" fixtures. It wasn't exactly what I wanted, but nobody seems to make a smart inline switch anymore. As a bonus, the switch supports double-tap and long press gestures so I was able to program the bedside button with a few functions to toggle the bedside lamp on a short press, and turn off all the lights in the house on a double tap.

It uses a coin battery that lasts a few months. I think I've changed it maybe once since I got it.

The HA Ecobee integration requires a developer API key which ecobee no longer distributes, if you already have a key it still works, but they stopped giving out new keys a few years ago.

On the other hand, the HomeKit integration allows new users to control most of the thermostat's features locally over WiFi. I got my thermostat after the Developer program ended, and this is how I control it today. Once you install the HomeKit integration, it will discover the thermostat if its on the same LAN, and then prompt you to add it.

I have an ecobee I mainly control locally through the HomeKit integration on HA. Just about all of the basic features are covered: setpoints, heat/cool/auto/off and fan on/off/auto. Some of the more advanced features like Home/Away/Sleep profiles are not available through the integration, but they tend to be set & forget.

It doesn't need Internet access or the companion app to operate your system, though it will use external access to track local weather and energy rates. (And probably collect usage data.) The companion app gives access to a few more features remotely, but the unit is completely programmable from its front panel.

It's worked out fine for me so far. My local power utility sells them at a steep discount through their online storefront. Check around for rebates.

Can this be done with foil or metal?

Based on a layman's knowledge of these things, I'd guess that's probably a bad idea there since the microwave reflectance off the metal could saturate the receiver on the sensor. Best case, the hot signal confuses the sensor making it unreliable for tracking objects at a distance. Worst case, it could shorten the device lifetime if not outright burn out the receiver.

Rather, you'd want something to absorb the microwave energy like, say, paint with carbon black in it. It'll still covert the absorbed energy to heat (like your microwave oven), but at the power levels we're discussing you could at least dissipate it somehow.

Edit: just realized I didn't address shaping. What I mentioned above, I was thinking of sticking a strip of foil across a portion of the plastic lens. You could probably form a sort foil visor for the sensor, like a ball cap, but you may still run into issue with false positives and ghosting of objects as signals would now be bouncing around in ways the sensor wasn't designed to account for, if they even get picked up.

Federal police are still investigating whether the aircraft was involved in drug trafficking

Um....

And I genuinely hope it stays that way for years more to come. Cheers.

Oracle Cloud will also delete your shit for the price of admission.

Caveat emptor, hey?