Added support for long-lived JWT access tokens (Issue #118)
The last change is the most important one. Thanks to this you can create a long-lived access token and replace the previously used apr_password with it. So in case you only had the api_password enabled to keep the configurator working you now can disable that option in your Home Assistant configuration.
The maintainer of the Docker release has been notified as well. The hassio add-on will come along soon (PR).
Version 0.3.4 has been released (standalone, Docker and in my external hassio-addons repository). The PR for the hassio variant from the official repo is being worked on.
Changelog:
Spelling fix
Added env_var tag exception (configurations using !env_var where incorrectly displayed as being invalid)
Event observer: support access tokens and disconnect on modal close
Added editor option (gear symbol in the upper right, then Editor Settings) to hide file / directory stats (this hides the filesize, modification date; only the filename is displayed)
Added HASS_WS_API option to correctly prefill the websocket URL (event observer)
Open common image formats directly in new tabs (so you don’t have to download them to see them)
Update dependencies (including Ace Editor, which could fix some usability issues on mobile devices)
Hi, I’ve been working on this for ages and I can’t for the life of me figure out what is wrong. It started I believe after I updated to the newest update of this plugin but I can’t be sure. What I am experiencing is that when I open configurator, it doesn’t show any of my files. I checked both the configurator log and homeassistant log and can’t find anything relevant to explain what is going on. I believe that everything is connected properly because configurator shows my automations and entities just fine. It is also reporting the correct directory structure. I can even create files that show up when I view the directory from the command line. The only issue is that no matter what I do no files are actually shown in the directory navigation within configurator. I have also tried setting the basepath to enforcing and not enforcing with no change. I have also looked at the permissions of my files and everything looks ok there. Everything is owned by the home assistant user and I am running configurator as a service. I even tried running it by logging in as the home assistant user with no luck. Any ideas?
If you see the created files via commandline the configurator generally seems to operate in the correct directory.
Do you see various different icons in the filebrowser and just the filenames are missing? In that case your browser might be set to a zoom-level other than 100%. The UI of the configurator is designed to work at 100%, and at some other levels the text next to the icons disappear.
If you don’t even see the icons, then there must be some sort or permission problem. I don’t know of any other reason why the configurator shouldn’t be able to display the files.
In any case, please open the developer tools of your browser (which one are you using by the way?) and see if the console shows any errors.
The configurator itself also has a log. How you access it depends on how exactly you have set it up. When using systemd you should be able to see the log with journalctl -u your_chosen_unit.
Im using chrome. Im not seeing anything with configurator. No filenames or icons. And the strange thing is it has worked with the same settings in the past. I have looked at both the home assistant log set to info and also the configurator log through its service log (sudo seevice homeassistant-configurator status). Nothing in either seems to indicate any issue. I will try on another browser when i get home.
Did you introduce some sort of DNS blocking like PiHole? The configurator fetches necessary libraries from CDN. It could be, that such an ad-blocking service is blocking access to those libraries.
And please post the logs. Especially what you get in the Chrome console. Without that info I can’t help you.
Just did some testing. It is definitely chrome. I tried it on edge and it worked fine. I do have an ad blocker running but I turned it off for testing and still no luck. I even tried incognito mode which has no extensions running. I am running Chrome Version 72.0.3626.109 (Official Build) (64-bit) In terms of logs this seems to be the relevant portion:
(index):3216 Uncaught DOMException: Failed to read the ‘localStorage’ property from ‘Window’: Access is denied for this document.
(anonymous) @ (index):3216
(index):2248 Uncaught DOMException: Failed to read the ‘localStorage’ property from ‘Window’: Access is denied for this document.
at HTMLDocument. ()
(anonymous) @ (index):2248
jquery-3.3.1.min.js:2 Uncaught DOMException: Failed to read the ‘localStorage’ property from ‘Window’: Access is denied for this document.
(anonymous) @ jquery-3.3.1.min.js:2
setTimeout (async)
w.readyException @ jquery-3.3.1.min.js:2
(anonymous) @ jquery-3.3.1.min.js:2
l @ jquery-3.3.1.min.js:2
c @ jquery-3.3.1.min.js:2
setTimeout (async)
(anonymous) @ jquery-3.3.1.min.js:2
u @ jquery-3.3.1.min.js:2
fireWith @ jquery-3.3.1.min.js:2
fire @ jquery-3.3.1.min.js:2
u @ jquery-3.3.1.min.js:2
fireWith @ jquery-3.3.1.min.js:2
c @ jquery-3.3.1.min.js:2
setTimeout (async)
(anonymous) @ jquery-3.3.1.min.js:2
u @ jquery-3.3.1.min.js:2
fireWith @ jquery-3.3.1.min.js:2
fire @ jquery-3.3.1.min.js:2
u @ jquery-3.3.1.min.js:2
fireWith @ jquery-3.3.1.min.js:2
ready @ jquery-3.3.1.min.js:2
_ @ jquery-3.3.1.min.js:2
(index):3254 Uncaught DOMException: Failed to read the ‘localStorage’ property from ‘Window’: Access is denied for this document.
at Object.fireWith [as resolveWith] (https://code.jquery.com/jquery-3.3.1.min.js:2:28202)
at k (https://code.jquery.com/jquery-3.3.1.min.js:2:77651)
at XMLHttpRequest. (https://code.jquery.com/jquery-3.3.1.min.js:2:79907)
get_hide_filedetails @ (index):3254
renderitem @ (index):2440
renderpath @ (index):2558
(anonymous) @ (index):2366
u @ jquery-3.3.1.min.js:2
fireWith @ jquery-3.3.1.min.js:2
k @ jquery-3.3.1.min.js:2
(anonymous) @ jquery-3.3.1.min.js:2
load (async)
send @ jquery-3.3.1.min.js:2
ajax @ jquery-3.3.1.min.js:2
w.(anonymous function) @ jquery-3.3.1.min.js:2
listdir @ (index):2364
(anonymous) @ (index):2212
l @ jquery-3.3.1.min.js:2
c @ jquery-3.3.1.min.js:2
setTimeout (async)
(anonymous) @ jquery-3.3.1.min.js:2
u @ jquery-3.3.1.min.js:2
fireWith @ jquery-3.3.1.min.js:2
fire @ jquery-3.3.1.min.js:2
u @ jquery-3.3.1.min.js:2
fireWith @ jquery-3.3.1.min.js:2
ready @ jquery-3.3.1.min.js:2
_ @ jquery-3.3.1.min.js:2
Version 0.3.5 has been released (actually already a while ago). In terms of features only the ALLOWED_DOMAINS option is new, but irrelevant for most users.
That being said, there finally has been an update for the hassio addon! However, people are running into trouble because Migrate Add-on to new Ingress doesn’t really tell the users what has happened. Here’s a short video demonstrating what’s possible now: https://twitter.com/pvizeli/status/1114463817994518528
Essentially the ingress feature that’s being rolled out allows you to use the authentication of Home Assistant to log into the configurator. On top of that, it’s kind of a reverse proxy. So you don’t have to expose the configurator anymore. Because of that, most of the previous options become obsolete. You don’t need credentials, you don’t have to whitelist networks, you don’t have to configure SSL etc…
The thing is, that because of this your panel_iframe-links will break. The old URL simply isn’t valid anymore. So to figure out the new link, you’ll have to open the configurator like it’s done in the video above. I myself actually have not tested this, but I assume the URL will be static and can be used for the panel_iframe. And if I’m wrong, I don’t know what the correct solution to this problem would be. But even without the panel_iframe you’ll be able to open the configurator by clicking through the menus like in the video.
So to sum up what has changed for hassio-addon users:
your settings vanish because they are obsolete now
you have to figure out the new URL
you can remove the port forwardings in your router
I believe you can even access the configurator now with Nabu Casas cloud access
Since I don’t use hassio myself and don’t have a cloud subscription I would appreciate anyone who can clarify or correct my statements in case they are inaccurate.
That’s correct. The add-on from my repository is more like the standalone configurator with pretty much all options. The new V3 add-on from the official repository on the other side just needs to be installed and works out of the box. Because of the lack of experience I don’t know if there are cases where the add-on from my repo is superior.
I am using the official one, am currently on version 2.1, says 3.0 is available, but it won’t update - when I look at the Hassio Add On Store, it says “Not Available”. Not sure what to do next…
Edited to add: I’m using HA 0.90.1 on an RPi 3B+. Supervisor is current (155); System=HassOS 2.2, Deployment=development. When I try to install the official add-on, I see this in my system log:
ERROR (MainThread) [hassio.addons.addon] Add-on core_configurator not supported on raspberrypi3 with ['armv7', 'armhf'] architecture
Is the Configurator add-on no longer supported on Raspberry Pi? It worked before. The only thing that has changed recently is that I changed from a Pi 3B to a 3B+, simply by moving my SD card over. This is the first time I’ve tried to update the Configurator since the change.
I don’t have hassio running, so I can’t test it. But as mentioned above, open the configurator UI like in the video. There’s one click in the video where the configurator opens in a new tab. There you can copy and paste the URL to the panel_iframe.
BUT: it might be, that the URL is dynamic. I don’t know how that works internally. So maybe it works for an hour, or as long as the cookie for your Home Assistant session is valid. Or maybe forever. I don’t know that.
I should have googled that. Sorry to put that on you. It’s fixed now. Thank you so much for your help!