Simplistic configuration UI

Thanks for the kind words. Much appreciated. :slight_smile:

Looking forward to your testresults.

Update:
There was a bug where authentication did not work with SSL. Silly me. It’s fixed now.

Additionally 3 nifty features have been added:

  1. Allowed networks feature (like in HASS)
  2. Banned IPs (don’t know if HASS has that as well)
  3. Ban IPs after n failed login attempts

Have a look at the README in the repo for more details.

Great - looking interesting!

BTW, HASS does have HTTP black/whitelists and bans … see https://home-assistant.io/components/http/

Not sure if you can leverage or want to remain standalone.

Also - have you thought about generating yaml in a new, temporary file rather than the live file, which then could be validated before committing it to “prod”.

I guess that would require a change to the hass script to check config … or you would make a backup of the yaml that you could rollback if you don’t like your changes from the tool.

Yes, that HASS internal security features would indeed take care of such security features (and also some other settings like SSL for that matter). But I have no experience with HASS frontend development, so making this a stadalone service was the way to go to get this done quickly. After a while I came to the conclusion: not being directly integrated into HASS is a good thing, since this service will keep running even if HASS fials to start because of a faulty config.

And yes, I’ve thought of some HASS API improvements before myself. However, those improvements only have value with a specific use case. So as long as this isn’t popular enough or alternatives are available, nobody would take time to implement it.

What I’ve thought of so far:

  • Voluptuous API to validate config snippets for platforms / components
  • check_config API (like you suggested as well)
  • Fail-safe mode for HASS where it woudn’t restart if check_config fails
  • Components / platforms should register their possible events + events.yaml (like services.yaml), since currently the list of availble events does not include every event that can happen

All those would be obsolete without something leveraging those API calls. So here I’m creating something that would use them. :slight_smile:

1 Like

Being implemented in Check config before restarting by andrey-git · Pull Request #5609 · home-assistant/core · GitHub

True. For that I’ve even opend up a feature request here a few days ago, but nobody’s voting. Which is why I came to believe the configurator needs more popularity before it makes sense to implement the more useful features.
Admittedly, the way I proposed it is a little different from the implementation in the PR though.

Voting isn’t working on that post for some reason. I tried reclassifying it to another category, saving it and then setting it back to Feature Request but it still isn’t allowing for voting.

Not sure what the issue is.

Edit: It appears that I was able to fix it and I gave it a vote. So maybe you can instruct folks to try again.

Thanks for your effort. But since it’s being implemented already, I kind of see it already as accepted, and will mark it as solved as soon as it makes its way into a stable HASS build. :slight_smile:

1 Like

Really like what your doing !
A bit off-topic:
I do use the github approach for updating my config. So for me it is not a solution. But the idea is great and I’ve been thinking about your approach to be implemented as a plugin in one of the currently popular text editors (Atom, Brackets, VS code)… Just an idea I’d like to share…

1 Like

To keep you guys updated:
I’ve kept working on this. There were issues when combining SSL setups with running this as a service (or from annother path). Those now should be resolved.
Besides that I have replaced two of the toggle buttons in the toolbar. One is linking to the keyboard shortcuts of the editor, and the other one allows you to change pretty much any setting of the editor. You can even switch to a vim or emacs emulation (sublime doesn’t work). How cool is that? :slight_smile:
Oh, and now you’re asked to confirm before the file is being saved. Just to be safe.

5 Likes

Nice work man! Shoot; I’m going to have to read back a few and get back up to speed so I can run this again.

This is really becoming a super add on to HA!!

Absolutely amazing work @danielperna84! I gave it a fresh coat of paint to blend with HA as well as made it a little more responsive for mobile editing (everything collapses into a side nav). However I have somewhat broken the new Ace editor menu :disappointed:

Thanks for sharing this!

6 Likes

WOAH! That’s looking fantastic! :slight_smile:

Opening the Ace options is done in JavaScript with editor.execCommand('showSettingsMenu'). All I really do is calling that with the onclick event.

I hope you’ll do a pull request as soon as your done with your modifications. I definitely want to include your effort. :slight_smile:

Edit: Mentioning for completeness: The items in the file tree are a little offset. But I’m sure you’re already working on that.
Edit 2: Regarding the Ace Menu: Could be, that the material design stuff is breaking it. The default menu included with Ace is more of a demo, as applications using Ace would usually build their own menus to blend in to the rest of the design. I’ve used the toggle buttons for whitespace etc. before, but stripped them away because of the new menu. It would however be great if we had our custom menu.

And one note, as I’m seeing your dev.html is unchanged: As you work you can put your code in there. If you then set the DEV variable in configurator to True, the HTML the dev.html will be used with every refresh. That way you don’t have to paste the html into the py-file. At least for me that’s a lot less pain.

4 Likes

Oh wow, shoot I actually never even noticed that offset, good eye!

I’ll keep plugging at this and try to get it 100%

As far as the Ace editor menu goes, I can find where the call is, but I’m not seeing where the style is controlled. The Material Design CSS is definitely breaking it. Ah and as I’m typing this I see your new edit about creating a new menu. That would be the way to go for sure. We could add a second side nav from the right that would contain all the Ace stuff

Awesome tip about the dev.html, I wasn’t sure how that worked, I’ll play with it

I keep going to reinstall this but then it gets improved again…LOL

I guess I’ll wait until @jmart518’s changes get merged as I really like the aesthetics of this!

I have implemented persistent settings. So updating is just a matter of a single copy an paste + restart. :wink:

2 Likes

I really like the look of @jmart518’s version though so I want to wait for that.

I’m really impressed with how far this project has come in such a short time. I am so happy that you continued improving it!

Another thing I have noticed:
You took out two statements from the load-function:

  1. editor.selection.selectFileStart();
  2. editor.focus();

Because of that the whole text is selected after loading. I have disabled that because it’s kind of odd behaving that way. Is there any reason you have left that out? Does that somehow conflict with the material design?

Fixed :wink:

On a side note, enabling DEV has made this a million times easier, thanks for that

Been testing your dev.html. Some feedback (here, because issues aren’t activated in your repo):

  1. At least in the version in your repo you’ve nested your html into the existing one. So I’m seeing a mix of your work and mine.
  2. It’s strange, that the menu on the right already opens when the mouse is hovering. Usually such menus open when clicking / tapping them.
  3. When saving a file a modal was show that saving was succesful, or that an error occured when it fails. This is missing now, so there’s no feedback for the user. Not saying that saving worked kind of seems ok. But errors should be presented. So the return value from saving should be displayed in a modal like the about dialog.
  4. The link to the repo in the about dialog is broken. It’s not an <a> anymore.
  5. The header above the file-tree (with John Doe in it) should be removed as it doesn’t really serve a purpose.
  6. Maybe personal taste, but I’d like the menu on the left (with the lists) to be a little wider. The current narrowness makes it hard to read the names of the entities.