Do you of any way to get this to work with groups of lights? I tried to do so, but didn’t get what I was expecting. Might have to check out the custom_light html to see how to do a similar custom_group
Hmm, thats a shame. I use android myself but I wonder what it looks like on iOS for when other people may visit. If its still just like a normal switch I can live with that but if it doesn’t load at all that would be a no go…
Hi,
I think this would be very useful for a lot of people.
I’m running Home Assistant 0.59.2 and when I use the customize_glob: code offered above, I get the blank light control Bernard describes above.
Is there an add-on repository for this ? Though I would prefer this to be a standard part of the set-up so that it is as integrated ans supported as much of the rest of the kit
Anyone any ideas on the status of this ?
Thanks
Mutt
Riseup,
Thanks for the quick response, I’ve read through the github resources you linked and everything seems to be in place. I’ll give it a go this weekend. Just a couple of questions though.
The required version levels are consistent with hassio (I have just started with hassio, 3 weeks) but then maybe they number hassbian updates the same way to maintain feature parity. Can you confirm that you run this with hassio ? (The script, curl and directory usage don’t look like hassio) .
What happens on updates ? Do you need to run the update bash script again, look for any breaking changes, update those files manually z and than all its good to go ?
Do you know if they are looking to move this into the main core at all, and if so on what timescale ?
Apologies if these are newbie questions but then I am one : - )
Thanks for your time
Mutt
Not sure what do you mean by hassio version. There is hassio supervisor which updates independently and you shouldn’t care which version is it. Otherwise Hassio version is Home Assistant version.
Generally you don’t have to run update.sh when you upgrade Home Assistant. Unless there was a breaking change - then CustomUI will have anew version available a few days in advance. In any case before updating CustomUI you should read the changelog for breaking changes.
Most of the features will never move to core. That said, if some feature is extremely popular - core maintainer might consider it.
andrey,
Sorry, I obviously was not clear.
I assume that the hassbian version of HA is different from the hass.io version merely given the non-synchronicity on the release dates. And although the developers try their best to ensure mirror like duplication of look, feel and functionality, there are elements you can install in parallel on the hassbian version which extend or overlap certain functions. And given the VERY steep learning curve (I started 20171104) I want to get as much functionality for as little effort as I can (hence hass.io). I have only bought a Z-Stick and a light dimmer and plan to solve as many of my perceived issues in advance of spending more (and then maybe giving up). Which would cost a LOT (considering 22 light dimmers, 13 radiator controllers and a override-able boiler switch - so about £1,400) so on fuel/electricity savings, about a 14 year payback -So would HAVE to have significant user benefits. And if those come at departing mainstream development then I prepared to do that, but if that breaks mainstream benefits, I would have to reconsider.
In short, thanks for clarifying.
Mutt
Whenever a new version of CustomUI is released, I read through its changelog for the breaking changes and run the update.sh script again. It’s relatively simple, really. The biggest issue I’ve come across is dealing with Chrome’s cache, but we can cross that bridge if and when we come to it.