I use it with synology in this exact way. This is only resolved by my own dns running on my unifi. I have local entries in my laptop to resolve to my static ip. Even https/was are ok.

Here we go. Sorry for the delay, crazy days at work:

{
    "entity_id": "fan.kitchen_seashell_hood_ventilation_fan",
    "state": "off",
    "attributes": {
        "preset_modes": [],
        "percentage": 50,
        "percentage_step": 25,
        "preset_mode": "",
        "friendly_name": "Seashell Hood Ventilation Fan",
        "supported_features": 49
    },
    "last_changed": "2026-09-19T04:06:16.582977+00:00",
    "last_reported": "2026-09-19T04:06:16.582977+00:00",
    "last_updated": "2026-09-19T04:06:16.582977+00:00",
    "context": {
        "id": "01M2VXFV869XHBDKVKPFSSCC21",
        "parent_id": null,
        "user_id": null
    },
    "source": {
        "domain": "esphome"
    }
}

Thanks.

Nothing more to add. I see we have hvac_blower, but, anyway, maybe a native fan on the same assumptions of the fan from HASS could be reasonable.
I have a couple of them. ie, this is from ESPHome via HASS.

x_hass.domain="fan"
x_hass.entity_id="fan.kitchen_seashell_hood_ventilation_fan"
x_hass.floor_id=null
x_hass.services=["fan","esphome"]
x_hass.source="esphome"
x_hass.state="off"
x_hass_attr.friendly_name="Seashell Hood Ventilation Fan"
x_hass_attr.percentage=50
x_hass_attr.percentage_step=25
x_hass_attr.preset_mode=""
x_hass_attr.preset_modes=[]
x_hass_attr.supported_features=49

Thanks.

done. I'll test, but your logic makes sense, of course.

anyway, part of the problem with complex rules is that I have a huge system and sometimes it's very, very difficult for me to find the right rule after a while. what could help me is a way to see all the rules a device is used into (triggers, constraints, actions, variables), and an advanced search, maybe,

one can dream

Thanks, make sense. I realized from a backup that I had previously solar into the triggers. So I don’t know, maybe I was tired. Thanks for your help, I’ll try to rework this and create two rules!

I have this rule that stopped working recently, I think with the latest update:

As you can see, all is true, but the rule stays reset. Resetting the rule does the work and the A/C starts. I think it's because the trigger window is true, while a specific constraint (power_solar >= 1800) is not true when the triggers are true. But I don't want to put this into triggers, since I want the A/C to stay ON after it started, even if we have rain or similar, because of the inertia to start it. Any hint is appreciated here @toggledbits. Thanks.

This sounds really complete. I’ll give it a try when available.

Number 2 seems more logical. Right now all we have are empty values.

Maybe some way to do easy things like

• avg/min/max of values
• if any matches a value (ie cool), the value is cool
• and/or/xor for binary values

Similar to other options, to avoid code for simpler scenarios. Thanks.

Oh, wow. Is ; universally accepted in code blocks too?

Thanks for considering the request!

Hey @toggledbits I'm back to trying to optimize a couple of things based on dynamic group.

First of all, I think I found a typo in the doc:

          primary_attribute: "binary_sensor.state"
          primary_attribute_value: |
            d = false;
            each id in members: d = getEntity(id)?.attributes?.power_switch?.state or d,
            d

I think the correct code snippet is d = false,

All that said, my use case for dynamic groups is to group 3 different climate devices, so I could easily command them at the same time. Commands are good, but sometimes I want to check if any of the devices are on, and that's easily done with a similar snippet as the one you have in the docs. But this is limited to the primary attribute, while I want to have any of the attributes in the group to be driven by a similar logic (while all are null in the group). ie, access hvac_control.mode and see if any of the unit is set to cool, or heat. Is that possible, without re-defining an expression in each of my rules? Thanks!

I agree with @tunnus.
It's not that difficult and for (almost) critical systems I really appreciate the fact that each system is separate from the others, for maximum stability.

@toggledbits thanks for the new features, I love them!

What about support for right click on items? We could definitely move some stuff there. I see some potential in an advanced UI, since we're all power users, after all. Thanks for the consideration!

@toggledbits I know. But with 200+ rules and no search box, it's very difficult to find the current set actions I'm working on and I have to save it first to get the current status. Header is not sticky and saving means multiple scrolls and lost of focus. Plus, I'm speaking about copy/pasting the single action/group here.

Imagine this. I want to copy an action doing an mqtt message, and paste to another rule (or in the reset). So, real copy/paste like in normal apps. This should be doable with some local storage and a couple of buttons.

Hey @toggledbits

One thing that bothers me while doing work on new systems/new features, is that I cannot copy&paste actions, and I cannot drag&drop between set and resets.

#1 is for when I want to copy an action between different rules opened in two separate browser windows, while #2 is when I just need to flip a bunch of actions in the reset, or move some logic back and forth.

Both will be appreciated, but I understand the technical challenges. Thanks!

Oh boy. They even sent some invoices, as "courtesy previews". People are entertained in the old place...

If you need a way to quickly migrate from Vera to Home Assistant Zwave key, read here:
https://smarthome.community/topic/1590/how-to-migrate-from-vera-to-zwave-me-and-then-zwavejs-in-2024

I used Zwave.me as an intermediate step, but I think anything on Zwave series 500 should work.

I don’t know if setting to null it’s better for reactor. @toggledbits here is the best source of truth.

I think you may just filter for unknown and return null. Tell that to my friend Claude

It may. I have similar behavior with other Template sensors being 0/null/off at boot.

As a defensive measure, I always make the condition to be sustained for at least 10 secs and/or avoid them being evaluated when ha has been restarted for the last 20 secs.

I rarely use ha templates, so my experience is anecdotal.

@gwp1 I never had any doubt about @toggledbits