It is not possible. The group titles are not directly customizable.
The script also updates itself, so if you were to edit it - you would lose that functionality.
Can’t you put it into the config dir, i.e. \HASSIO\config\?
ok thanks for the swift reply.
seems to be no reason not to do that.
would this shell_command suffice for running the update script?
shell_command:
sc_update_custom_ui: >
/config/update.sh
I’ll do that.
-
Can I rename the file “update.sh” to “Custom_UI_update.sh”, without corrupting the functionality?
-
Do I have to run the shell command “$ chmod u+x update.sh” every time before I run “update.sh”? (I installed Custom UI manually by copy the files/folders)
UPDATE:
Running the shell commands:
update_custom_ui1: $ chmod u+x update.sh
update_custom_ui2: $ ./HASSIO/config/update.sh
Gives error:
Error running command: $ ./HASSIO/config/update.sh, return code: 127
10:27 /usr/local/lib/python3.6/site-packages/homeassistant/components/shell_command.py (ERROR)
Error running command: $ chmod u+x update.sh, return code: 127
10:27 /usr/local/lib/python3.6/site-packages/homeassistant/components/shell_command.py (ERROR)
- “confirm_controls_show_lock: true” does not work with scripts(?) Wold be a nice feature!
Running the commands with errors. Any idea what I am doing wrong (HassOS 1.7/0.75.2)?
simply type
./update.sh
after the prompt and hit enter
(leave out the ‘$’)
Don’t type the $.
You need to run
chmod u+x update.sh
from the same directory where you downloaded update.sh
Hass.io supervisor 125/HassOS 1.7/Home Assistant 0.75.3
I cant get the Local install-Automatic install to work.
I deleted all my previous manually installed Custom UI. Cleared browser cache. Retarted HA. Then followed the instructions for Local install-Automatic install.
After running the Linux commands, no files where created in HA. Restared HA. Still no new Custom UI files. What am I missing?
As the script warned you - you need to run this from your config dir.
Life is hard to be a N00B (not event able to read and understanding simple instructions). Life must be harder for those helping N00bs out.
Works like a charm!
Thanks for your patience!
HI @andrey
been wanting to ask for a while, but never got around, maybe not important, but still:
why are the quotes necessary in
"*.*":
custom_ui_state_card: state-card-custom-ui
all other customizations i use there are like this:
device_tracker.*_bt:
templates:
icon: >
if (state === 'home') return 'mdi:bluetooth';
return 'mdi:bluetooth-off';
or
sensor.*_motion_sensor_temperature:
templates:
icon_color: >
if (state < -5) return 'rgb(30, 255, 255)';
if (state < 0) return 'rgb(30, 144, 255)';
if (state < 10) return 'rgb(255, 255, 0)';
if (state < 15) return 'rgb(255, 211, 30)';
if (state < 20) return 'rgb(0, 128, 0)';
if (state < 25) return 'rgb(255, 165, 0)';
if (state < 30) return 'rgb(255, 0, 0)';
if (state < 35) return 'rgb(85, 0, 0)';
return 'rgb(47, 0, 0)';
is
*.*:
custom_ui_state_card: state-card-custom-ui
not possible (could try but fear i might mess things up…) so rather ask before going astray.
YAML keys can’t start with an asterisk - *, so in that case quotes are requires.
However in the middle or end of the key an asterisk is allowed.
I just released version 2018-08-31 that fixes CustomUI for HA 0.77
Note that this version won’t work on previous HA (0.76 and earlier)
This release also includes icon_color fix by Jérôme
2 Likes
thanks for taking the time to answer me, appreciated!
@andrey
Is it possible to make a sensor that checks the Custom UI version number in GitHub?
And if so, how do I pick up the current installed version number?
Changes to the code happens, so having a sensor checking the latest version number, would be helpful following the version changes/upgrade.
Similar to this, I notice that updates are cached on the client side. I must force a browser refresh to pick up the changes. Anyway to force a refresh? I note that HA somehow detects this and forces browser to reload.
@Tomahawk try this for a binary sensor that shows an upgrade icon if there is one available. Hard coding the current version is fine as you’ll need to restart HA anyway after a custom ui upgrade. It is also error-proof so if your Internet is down it will still report correctly.
binary_sensor:
- platform: command_line
name: CustomUI Version
command: '(curl -s https://github.com/andrey-git/home-assistant-custom-ui/releases/latest > /tmp/customui) && cp /tmp/customui ~/.customui; grep -P "(?<=tag\/)20180831" < ~/.customui | wc -l'
scan_interval: 60
payload_off: 1
payload_on: 0
Add this to your customize.yaml so it behaves like HA upgrade icon
binary_sensor.customui_version:
friendly_name: CustomUI Upgrade
icon: mdi:download
icon_color: '#bf1b00'
templates:
hidden: if (state === 'on') return false; else return true;
theme: cui_theme
Lastly add this to your front-end so that the sensor themes red:
frontend:
themes:
cui_theme:
primary-text-color: '#DF4C1E'
label-badge-blue: '#DF4C1E'
I’ve tested this and it works. It won’t show the sensor if there is no upgrade, but when one is available it will show. What an awesome idea and I took you up on the challenge 
Note that this will only work on Pi or other Unix systems. Won’t work in Windows unless you install *NIX compatible binaries.
Enjoy.
1 Like
I have the latest CustomUI version 20180831 installed. Copied your code. And did find the following:
-
The update icon was displayed when there was no new update. Had to change the binary sensor code, so when finding no new version, set the sensor to 0, “off”:
payload_on: 1
payload_off: 0 -
When the first upcoming upgrade of CustomUI, is released, the sensor logic will work, being different from “20180831”. Showing the upgrade sensor icon (payload_on: 1)
But after that the upgrade sensor icon will always be displayed, since “20180831” will always be different from the last version.
The command url, have to have your system CustomUI version, in the string.
I think…
Yes you need to change the text each time you upgrade. Since you need to restart HA anyhow it shouldn’t be a big deal.
The only way to avoid this is to store the current version. Possible but would take a bit more scripting effort, either by creating a script for the sensor or modifying @andrey’s download script to store the latest version so that the sensor could then compare.
Don’t know where I am going wrong. I copied your code. So now it is exactly as your post.
Then I tested the code where the 20180831 was changed to 20180701. The sensor displayed, saying upgrade is available. Then changed back to 20180831, restarted HA (on a RPi3), and the sensor displayed saying upgrade is still available. The binary_sensor.customui_version state is “on”. Your code doesn’t seem to work at my end.
@andrey Individually changing “update.py” as far as I understand, can be over written, by an upgrade.
If your code works, then a sensor with the installed version, created by the update.py, would make your code perfect.
I don’t think the sensors will update on restart. Since the configuration is to check 2x a day the test requires waiting 12 hours in order to see the update get picked up. You can try changing the update of the sensor to 60 seconds for a quicker test and to verify the sensor disappears.
The only sure fire to make this work is to copy @andrey’s update code and do a file check every time. However the update script takes about 30 seconds so too slow IMHO. If @andrey can direct us to a particular file that will always change or agree to inject the current version in one file then we can implement a more reliable update sensor.