2021.6: A little bit of everything

I had the same problem, my logs were flooded with errors about the recorder component. They were permission related (create table statements) by the looks of the logs.
I just stopped Home Assistant in Docker, then restarted the MariaDB container, then started Home Assistant again and all was working.

Hi @farmio. Could you please give an example on how to create a template sensor for brightness values, as those are not available as attributes. Also the same for rain, wind and day/night binary values.

I had the same issue.
Go to

and get version 1.16.1 with the updated manifest.json.
You are using 1.16.0, arenā€™t you?

1 Like

[SOLVED]

Download the last version from GitHub - AlexxIT/SonoffLAN: Control Sonoff Devices with eWeLink (original) firmware over LAN and/or Cloud from Home Assistant, then into the configuration.yaml use this format:

sonoff:
username: [email protected]
password: mypassword
mode: local
reload: always # update device list every time HA starts

The switch work on cloud and on LAN simultaneously.

Good luck!

Donā€™t know how this works. Just create normal knx sensors and youā€™ll be fine.

Upgraded today 2021.6.0 and Iā€™m noticing delay in history graphs being loaded.

I think the way to change things for everyone and then say: If you want to have the direct view back again, you as a user have to build this on your own and provdie a PR, esp. the once, who are technical not able to do so, is not the best way.

It was there, I didnā€™t see many complains for this. No someone, perhaps only a single one, decided, that he want this now collapsed and implemented this nor for everyone, not selectable. Good choice? No.

I have a WSL2 technical question. Are Z-Wave stick supported on Windows? I thought WSL2 did not permit access to USB devices except possibly for SSDs.

General consensus +1
This option also affects the more-info-card. I want to display attributes in the front end, not press a button to display them. Sorry mate, huge step backwards.

template them

If you want the information in attributes, they should probably not be an attribute, but a standalone entity.

If thatā€™s true, just run the zwave js server directly in windows, thatā€™s what I do for my dev box. Never bothered trying it in wsl tbh.

1 Like

and @nibblerrickā€¦

You should update to using the hass-variables integration forked and now maintained by @Wibias.

the original by rogro82 hasnā€™t been updated in over 2 years.

What do you want to express with ā€œā€¦ā€?

sorry, but this is at least arguable. (ok, you said ā€˜probablyā€™ā€¦ I know)

An entity having several attributes is a very nice way of symbolizing/visualizing they are related, and are not separate entities at all. Besides that, eg battery_level/state simply is what it is, an attribute, of that device (motion sensor).

Why the new dogma ā€œif you care for it that much, it must be a separate entity (and create it yourself)ā€

core HA template sensors even added the attribute_template not that long ago, simply to collect related attributes on another entity. Which is heavily appreciated here, and used I must add.

Since Iā€™ve learned to choose my battles, I donā€™t oppose the new attributes box (I like it and donā€™t mind the 1 click at all), but blink my eyes at the chosen selection of displayed/filtered attributes in that box.

Making that an option though would most certainly add to the HA experience in the Frontend. Let the user decide if an certain attribute has value to his/her use case. heck, why not add that to customize on a per attribute base. (include/exclude, like eg in recorder/history/etc)

Having to go all the way to the developer-tools/state to see the true state of affairs bring back memories of ancient times tbh, while it could be, just as you stated above, 1 click away.

1 Like

Did I say to create it yourself?

This should be done in the integration, and battery_level/state is great! examples of attributes that should be separate entities, they would all tie into the same device, but be separate.

When attributes are standalone entities, there are no longer (2 not 1) click(s) to see them, but 0 :tada: they are ā€œjust thereā€

3 Likes

How can i use the new sensor from the BMW Intergation ?

Thanks a lot guys!

nothing. just getting your attention to help answer your question.

1 Like

no that was Adrian and Philip :wink:

I see what you mean, and indeed in the integrations /devices pages we have some good examples of this. Also of the battery attributes that turned into separate sensors. Agree on that wholeheartedly.

The Frontend however is an entirely different matter. For me it makes me wonder, Huh, is that all, where are all the other attributes?, makes me wonder if the entity is even acting correctly, so forcing me to go to the developer-tools/state to check.

Checking the sun.sun to name but another type of entity, we have only a couple of attributes in the front-end, while users could prefer to have them all, or others. Clicking sun in the frontend to see if it is rising now needs a workaround. which, either way is a bit of extra work. I know, nothing too complicated. Having to create extra entities, while the info is readily available, (possibly in the proverbial 1 click) sounds off trying to keep resources down as much as possible?

Iā€™d vote for optional (display of) attributes, let the user decide.
The new attributes-box gives the more-info a clean and organized look, and will do so also with the extra attributes we now have to forgo without a choice.