Not able to build using the recommended build method & Installed extension via Gnome Shell Extensions is not functioning
Closed this issue · 13 comments
Hi,
I am not able to build the extension using the recommended method.
Here is the log received:
./build.sh: Downloading extension for version 42.4...
./build.sh: Error: You either don't have 'wget' installed or the version 42.4 is invalid.
./build.sh: Check the available versions from the releases page on github:
https://github.com/geoph9/hass-gshell-extension/releases
Trying to install on Ubuntu 22.04 & GNOME Shell 42.4
Gnome Shell Extensions Web Install Issue:
I tried installing via Gnome Shell Extensions & it got installed but not functional & keeps crashing after saving long lived token.
Any help is appreciated.
Cheers
Gnome 42 is not yet supported as a reelase, but I plan to add it this week (you can still use the script as ./build.sh --latest in order to install straight from github). If you have any logs on what error occurs when you use the web version, please post them here. It should theoretically work (see #30 ), so I am not sure what's the issue.
If using Xorg, could you run journalctl -f -o cat /usr/bin/gnome-shell, then restart the shell (Alt+F2 and press r), and then post the hass-gshell-extension entries in the logs?
I uploaded a new release for Gnome 42, so build.sh shouldn't give an error now. I am going to try and test for any other issues now, but I am not using Home Assistant during this time period so I am not sure whether I will fix them.
I am leaving this open in case someone wants to chip in and solve this.
Hi @geoph9
I followed your instructions & built it from latest.
The app is now not crashing. Thanks :)
But, no entities are discovered:
GNOME logs are ok. Nothing problematic is being reported.
Let me know if I can share logs which will help you.
Cheers.
Did you log out and re-login after submitting the long-live token?
The entity discovery function is stable and shouldn't be dependent on the Gnome version. So the issue must be with either gnome-keyring the validation of the long-live token from the server side.
Yes! I did log-out & re-login after submitting the long-lived token.
Any logs that I can share which might help you?
Could you run the following commands on two terminal tabs and report your findings when
- Opening the preferences menu
- Adding the token and pressing add.
- If you are using Xorg, could you also do
Alt-F2+r(and Enter) and see the logs after restarting the session?
The commands are:
journalctl -o cat -f /usr/bin/gjs # logs for the preferences
journalctl -f -o cat /usr/bin/gnome-shell # logs for gnome-shell
I'm on Ubuntu 22.04 and installed from extension.gnome.org and the extension is not working.
There are no logs for gnome-shell but for the preferences, I get this:
JS LOG: initializing Home Assistant Extension Preferences
Some code accessed the property 'TOKEN_SCHEMA' on the module 'utils'. That property was defined with 'let' or 'const' inside the module. This was previously supported, but is not correct according to the ES6 standard. Any symbols to be exported from a module must be defined with 'var'. The property access will work as previously for the time being, but please fix your code anyway.
JS ERROR: Error: Expected an object of type SecretSchema for argument 'schema' but got type undefined
_makeGtkEntryButton/<@/home/felipe/.local/share/gnome-shell/extensions/hass-gshell@geoph9-on-github/prefs.js:526:24
run@resource:///org/gnome/Shell/Extensions/js/dbusService.js:186:20
main@resource:///org/gnome/Shell/Extensions/js/main.js:22:13
run@resource:///org/gnome/gjs/modules/script/package.js:206:19
start@resource:///org/gnome/gjs/modules/script/package.js:190:8
@/usr/share/gnome-shell/org.gnome.Shell.Extensions:1:17
I don't see any other errors anywhere, not even failed log attempts on Home Assistant
Thanks for pointing this out. The fact that TOKEN_SCHEMA was exported as a const was a bug. But, I don't know whether that's the main issue here.
Could you maybe change the declaration from const to var in the utils.js and report what happens (e.g. by running the following replacement):
utils_filepath="$HOME"/.local/share/gnome-shell/extensions/hass-gshell@geoph9-on-github/utils.js
sed -i "s%const TOKEN_SCHEMA%var TOKEN_SCHEMA%g" $utils_filepathAfter changing from const to var, there are no more errors on the preferences and there's no mention of this extension on the gnome-shell logs.
Still, the extension doesn't work at all. There are no sensors listed, the temperature and humidity sensors show false, and there's no login errors on Home Assistant
Are you seeing the Success! message in the Access Token field after adding your token and pressing Add?
Yes, I see Success! when I copy/paste the Access Token. I've also turned on debugging on my Home Assistant and I'm getting some info (IPs were redacted):
2023-01-05 09:58:39.166 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated *.*.*.* for /api/error_log using bearer token
2023-01-05 09:58:39.167 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/error_log to *.*.*.* (auth: True)
2023-01-05 09:58:52.325 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated *.*.*.* for /api/states using bearer token
2023-01-05 09:58:52.326 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/states to *.*.*.* (auth: True)
2023-01-05 09:58:52.355 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated *.*.*.* for /api/states using bearer token
2023-01-05 09:58:52.356 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/states to *.*.*.* (auth: True)
2023-01-05 09:58:58.763 DEBUG (MainThread) [homeassistant.components.http.auth] Authenticated *.*.*.* for /api/error_log using bearer token
2023-01-05 09:58:58.764 DEBUG (MainThread) [homeassistant.components.http.view] Serving /api/error_log to *.*.*.* (auth: True)
When running curl -X GET "http://[my_server_ip]/api/states" -H 'Authorization: Bearer [MyLongToken]' from a terminal, I get a nice JSON object with all entities, same goes for the /api/error_log path.
This is very weird. I tried to replicate this issue locally but I couldn't. Are you sure the access token is still valid? Have you tried creating a new one and updating the value in the extension's settings?
I am closing this due to inactivity. I assume the problem is solved.