Thanks for the link. That’s about as obtuse as you can get, buried with an obscure description. The fact that Bluetooth Tracker no longer works and, based on that link, looks like it’s not coming back any time soon should be a listed prominently in the Breaking Changes. [Sigh]
I have the same issue. Tried many times with different notations. Not sure how to do this.
Sounds very interesting what you’ve done. Do you mind sharing your automation? Thanks in advance!
I managed to figure out the issue on my side when trying to connect to my synology nas. I was giving it the name of “Synology”, but this clashed with the existing Synology integration. I changed the name to something else. Still couldn’t get CIFS to work, but NFS did (after providing permissions from the NAS). path for me was like this: /volume1/HA_backup
It would require completely refactoring, but I think you may be able to use input_text
and counter
helpers for storing persistent notification text and counting the number of notifications.
You can find an explanation here
I am not getting a logics for the new “command_line” structure (some other users here complained too).
According to the Docs, it is expected as:
Compare with a “template” platform:
Any special reason for this difference?
When I started to rewrite my command_line sensors, I first did this - believed this is LOGICAL:
But I was wrong:
Invalid config for [command_line]: expected a dictionary for dictionary value @ data['command_line'][0]['sensor'].
yaml patterns
template:
- sensor:
- name: ...
value_template: ...
- name: ...
value_template: ...
- binary_sensor:
- name: ...
value_template: ...
- name: ...
value_template: ...
command_line:
- sensor:
- name: ...
command: ...
- name: ...
command: ...
- binary_sensor:
- name: ...
command: ...
- name: ...
command: ...
command_line:
- sensor:
name: ...
command: ...
- sensor:
name: ...
command: ...
- binary_sensor:
name: ...
command: ...
- binary_sensor:
name: ...
command: ...
If you are using docker you can just set this up outside of HA entirely. There is no way for a docker container to mount NFS or similar, you should mount this in the host system, and then bind the folder to the ha container via a volume.
Well, ALL command_line sensors are broken.
They are disappearing after reloading:
and cannot be updated manually
It still follow the allowed pattern, but yes, IMO, it should allow a list at the sensor: level.
I’m having this issue too.
So, impossibility to update a a command_line sensor made this change really BREAKING.
Looking forward for a fix.
I find the current implementation very hasty and untested…
you mean the blurred 65% transparant background?
Its
.mdc-dialog__surface::after {
content: '';
backdrop-filter: blur(15px);
background-color: #0000ff00;
z-index: -1;
position: absolute;
inset: 0px;
width: 100%;
height: 100%;
}
But think i did some more changes to get it nice… also on smartphone. Here complete yaml:
card-mod-more-info-yaml: |
$: |
::-webkit-scrollbar { width: 8px !important; height: 8px !important; }
::-webkit-scrollbar-track { background: rgba(255, 255, 255, 0.0) !important; }
::-webkit-scrollbar-thumb { background: #00000045 !important; border-radius: 25px !important; }
::-webkit-scrollbar-thumb:hover { background: #77777735 !important; }
@media screen and (max-width: 599px) {
.mdc-dialog .mdc-dialog__container { flex-direction: column !important; flex: initial; }
.mdc-dialog__surface { --mdc-theme-surface: #00000000 !important; background-color: #7c7c7c0f !important; }
}
@media screen and (min-width: 599px) {
.mdc-dialog .mdc-dialog__container { flex-direction: column !important; }
.mdc-dialog .mdc-dialog__surface { border-radius: 10px !important; }
.mdc-dialog .mdc-dialog__scrim { background: radial-gradient(circle, #ffffff35, #3535351f, #00000000, #00000000) !important; }
.mdc-dialog__surface { box-shadow: 0px 0px 15px #00000000, 0px 0px 15px #000000, 0px 0px 100px #000000 !important; }
.mdc-dialog__surface {
--mdc-theme-surface: #00000000 !important;
background: linear-gradient(0deg, #00000000, #ffffff05 35%) !important;
border-radius: 10px !important;
position: relative !important;
min-height: 0px !important;
}
}
.mdc-dialog__surface::after {
content: '';
backdrop-filter: blur(15px);
background-color: #0000ff00;
z-index: -1;
position: absolute;
inset: 0px;
width: 100%;
height: 100%;
}
ha-more-info-info:
$: |
:host {
--mdc-theme-surface: #111 !important;
}
div[data-domain="climate"] > .content > more-info-content { --mdc-theme-surface: #111 !important; }
div[data-domain="climate"] > .content > state-card-content { margin-left: -12px; }
@media screen and (max-width: 599px) {
.container { min-height:0px !important; }
ha-more-info-settings, more-info-content[full-height] {
flex: initial !important;
}
more-info-camera::before {
content: "";
position: absolute;
width: 100%;
height: 100%;
background: linear-gradient(180deg, #00000033 0px, transparent 3px);
}
}
@media screen and (min-width: 599px) {
more-info-camera::before {
content: "";
position: absolute;
width: 100%;
height: 100%;
box-shadow: inset 0px 0px 0px 0.5px rgb(0 0 0);
}
}
div[data-domain="device_tracker"] > .content,
div[data-domain="binary_sensor"] > .content,
div[data-domain="media_player"] > .content,
div[data-domain="weather"] > .content,
div[data-domain="climate"] > .content,
div[data-domain="script"] > .content,
div[data-domain="sensor"] > .content,
ha-more-info-history-and-logbook,
ha-related-items,
more-info-light {
padding-top: 16px !important;
}
.: |
mwc-list { background: #111 !important; }
ha-more-info-history-and-logbook,
ha-related-items {
padding-top: 16px !important;
}
@media screen and (max-width: 599px) {
ha-dialog mwc-tab-bar { }
ha-dialog-header {
background: var(--app-header-background-color) !important;
}
}
@media screen and (min-width: 599px) {
:host([large]) ha-dialog {
--mdc-dialog-min-width: 50vw !important;
--mdc-dialog-max-width: 65vw !important;
}
:host ha-dialog:has(span[title="Juwel SmartCam"]),
:host ha-dialog:has(span[title="Hikvision"]),
:host ha-dialog:has(span[title="Ezviz C2C 1"]),
:host ha-dialog:has(span[title="Ezviz C2C 2"]) {
--mdc-dialog-min-width: 50vw !important;
--mdc-dialog-max-width: 65vw !important;
}
ha-dialog { }
ha-dialog > .content {
position: relative;
}
ha-dialog-header:has(span[title="Juwel SmartCam"]),
ha-dialog-header:has(span[title="Hikvision"]),
ha-dialog-header:has(span[title="Ezviz C2C 1"]),
ha-dialog-header:has(span[title="Ezviz C2C 2"]) {
display: none !important;
}
}
ha-dialog-header$: |
* { --mdc-theme-surface: #111 !important; }
.header-title {
font-size: 20px !important;
white-space: nowrap !important;
}
ha-more-info-info$more-info-light$: |
:host { --mdc-theme-surface: #111 !important; }
ha-more-info-info$ha-more-info-history$: |
state-history-charts,
statistics-chart {
filter: saturate(1) hue-rotate(0deg);
}
… you coulda tried this in beta. Sorry, I never reloaded command line sensors during beta.
Unfortunately, cannot participate in beta-testing (((
Yep its still confusing… did you managed to get it fixed?
I got it fixed yesterday for binary_sensors and switches that uses command line (that can also be ping senors and those shouldnt be converted… that was also my part of confusion. And same for template sensor)
I agree that the name of the backup has always been “whatever”.tar … but it would have been good if the backup list of the backup page would have had a reference to where the backup is actually located.
I understand that after moving the save location to a different place everything will be there… but… i.e. right now I have a mix and I find it confusing
Alright, then things like this might go missed in the future. Sorry that no-one in beta found this issue before release.