@toggledbits

cover.state=true
position.step=0.1
position.value=1
x_hass.domain="cover"
x_hass.entity_id="cover.living_room_right_blind"
x_hass.services=["cover","switchbot_cloud"]
x_hass.source="switchbot_cloud"
x_hass.state="open"
x_hass_attr.current_position=100
x_hass_attr.current_tilt_position=100
x_hass_attr.device_class="blind"
x_hass_attr.friendly_name="Living Room Right Blind"
x_hass_attr.supported_features=176

And there's absolutely no rush on this specific item. The blind is opening and closing, just opposite of what I want it to and I'm fighting with learning HA templates to try and achieve this. Switchbot approaches tilting in a unique way.

@Fanan Ok, I'm gonna jump in here now. I just added a Switchbot Tilt Blind to my system and it is giving me the same

[object Object]

response when I go to Entities > Perform to test position.set.

Wasn't gonna say anything as @toggledbits is focused on the above items and it seemed a distraction.

I am on HA 2025.9.4 but installed the Switchbot just in the last 48 hours so didn't draw the line between them connecting the dots.

@toggledbits now I'm feeling hypocritical as I'm the guy at work chastising the Support folks for giving me screenshots for the exact reasons you noted.

Change deployed.

Got this upon restart of MSR:

    at _ClientAPI._commandTimeout (http://192.168.1.100:8111/client/ClientAPI.js:594:125)

Cleared it and refreshed the tab and all seems fine. Removing logging snippet.

Thank you, sir!

@toggledbits kicker is: this has been working for a long while. Dead iblind nodes (far too common, btw) get caught and pinged and I get the alerts on my phone.

I don't see a Global Expression called dead and, yes, I believe when I wrote this I was looking for either a status of 3 or status_text of dead.

@toggledbits whoops... guess this is one time having the system auto-update containers with new images is bad....

So I'm on the test version. Found this:

This is a Dynamic Group I'd created forever ago:

My ruleset:

I added the snippet as noted into my logging.yaml file:

When it didn't work I checked my yaml and found a spacing issue. That's been corrected, I now have a proper logger* log. Will upload to our pre-x Dropbox in folder 25248 logs along with the rule JSON file.

@toggledbits I'm watching all of this play out for now. "Leading edge vs bleeding edge" atm.

I'm very encouraged to see this doing as well in testing as it is. Anything to get me able to move off of non-privacy/non-cloud Echo devices is def getting my attention.

@toggledbits appreciate the quick turnaround on this. It def caught me off-guard.

@toggledbits Yahtzee! That did it.

So I... wasn't... crazy?

@toggledbits missed this last night - will do so this afternoon and advise.

@toggledbits hosting in Portainer. Says

@toggledbits I see the "Placing widget at"

UI TIME CHECK: Browser 2025-07-20T22:50:33.935Z offset -240 ; host 2025-07-20T22:50:33.933Z offset(mins) -240 ; diff(ms) 2
reactor-ui-status.js:226 Placing widget-adder at 8
reactor-ui-status.js:913 saveGridLayout()
reactor-ui-status.js:924 SAVE DATA Array(4)
reactor-ui-status.js:928 Fixup widget widget3 at x/y 0 0 w/h 8 2
reactor-ui-status.js:928 Fixup widget widget0 at x/y 8 0 w/h 3 2
reactor-ui-status.js:928 Fixup widget widget1 at x/y 0 2 w/h 6 2
reactor-ui-status.js:928 Fixup widget widget2 at x/y 6 2 w/h 6 2

Would a .har contain all of this?

Just to show I'm not entirely crazy here...

@toggledbits the only thing it calls out is:

No label associated with a form field
A <label> isn't associated with a form field.

To fix this issue, nest the <input> in the <label> or provide a for attribute on the <label> that matches a form field id.

1 resource
Violating node

Clicking the "Affected resource/violating node" nets me:

<label id="ep-filter-label" class="form-label mt-1 pe-1">Filters:</label>

@toggledbits I'd just now finished doing first a hard refresh and then just killing the browser completely and restarting.

Nada.

Did the "Clear Local Storage" and hard refresh and saw the one change I'd made was gone. The issue, however, persists.

I know Brave just updated in the last day or two...

Interestingly, this is still fine on my Intel Mac (though I've not cleared the cookies there and won't at this point).

I foolishly let my system wipe all cookies this morning and with it my settings for my MSR home page.

Once logged back in I can no longer remove errant panes nor is the + available to add new ones.

Brave Browser v1.80.122 (Jul 16, 2025)

What have I done?!

Will check other browsers on my M1.
UPDATE: Safari exhibits same behaviour.
I've tried both sans last-four public key entry and with - no change.

@CatmanV2 not yet - I'm letting other kinds go in the pool first.

@vezinpi mine is as such:

Here's the rule's Set Reaction that pulls this in.

I also have another group under this same rule's Set Reaction for Evenings.

Everything I've seen shows this as working as intended. Only rises to 30% in the mornings, 80% at night. Only the mornings get the slow roll ramp up.

@vezinpi can you share screenshots of the rules?

I implemented this and it appears to be working fine (though I want to do some fine tuning).

@Tom_D I've implemented this as it's much slicker than what I'd been previously doing. Of course, now with longer days and Daylight Saving Time in full effect it doesn't get called on very much so I can't confirm success lol

@tbully thanks for putting a smile on my face today. Much needed. Much appreciated.