@masterkenobi Thank you
I dont have api password anywhere in my config except for the following:
http:
# Uncomment this to add a password (recommended!)
api_password: XXXXXX
Are you saying to replace the above api_password line to long lived access token?
and obviously I have specified to use the old legacy system i.e.
homeassistant:
auth_providers:
- type: homeassistant
- type: legacy_api_passwordAlso @masterkenobi
When you created long lived token, in your config did you put the name of your token or the long token code?
Like:
Authorization: 'Bearer tokenname'
or
Authorization: 'Bearer hsodjilknlknsdsAAAxbh'
I don’t see how? It’s all JSON files in the /config/.storage directory? Including for some reason - no security whatsoever on any password/API key you use for integrations. (eg my MQTT broker password is there in plain text for the world to see inside /config/.storage/core.config_entries)
Am I the only one having Schlage Z Wave lock issues? They work OK in 0.83.x, but don’t report status correctly if operated from Hass. For example, if the door is locked and I click Unlock, it actually unlocks, but never reports that its unlocked (which affects the front end actions available). I can still manually call lock.lock though and it will lock. The opposite is true if the door is unlocked, showing unlock, and I click Lock.
If I manually operate the lock (code, key, or bolt operator), status updates just fine.
I did open a GitHub issue, but it seems as if no one else is having the issue. The only steps I have not taken is to unpair/repair, but that is a major pain since I would have to take the locks off the doors to get them within a few feet for a good secure pairing. They have worked flawlessly for well over a year now so I don’t think its a hardware issue, especially since I have two separate locks with this issue (Schlage BE468 and BE469).
I did see there is a PR for this release that affects lock status and I believe that may be the issue, but don’t know how to confirm that.
Github link for reference:
https://github.com/home-assistant/home-assistant/issues/18812
homeassistant:
auth_providers:
- type: homeassistant
- type: legacy_api_password
i don’t believe these are required anymore
FYI, Google TTS was/is broken in 0.83.1 but is working again in 0.83.2.
What do the new ASUSWRT sensors report?
I get what the new sensor.asuswrt_download_speed does, but I can’t align the new sensor.asuswrt_download to anything the router is reporting. Any ideas??
Yep, first place I looked. What I can’t figure out is what that download total relates to. It doesn’t align with real-time, daily, or last 24 hours reported by either the web interface or ASUS app.
Is anyone noticing a serious lag when using the new Google home Bluetooth trackers? I went from 0.5s response time to over 7s with the Google home tracker. I had to comment it out for now. Any thoughts?
Ah, undocumented files in the file format known for it’s human readability and ability to comment stuff out as required.
Wouldn’t be so bad if they were split by service (e.g. mqtt.json) - makes it really easy to disable (rename to mqtt.disabled) when stuff goes wrong.
UH OH. Major problems on my C2 with 0.83.2. All my lights turned off at once at 2325 this evening and cannot be turned back on. Shelly, Xiaomi, Z-wave etc. All affected. I can turn them on now but they go straight off again. New light platform maybe? Have restarted HA to no avail. Never ever had this happen. Luckily wife gone to bed and no home auto in there!
Having to shut down HA now and use wall switches (yay) until I can resolve tomorrow or roll back to 0.82.1.
EDIT: Mt bad! My old NUC with 0.82.1 had turned itself back on last night. Should have unplugged it. I had two HA instances talking to the same broker. Ouch. Back again with 0.83.2 working fine on Odroid C2.
I’ve been getting these payload-errors since .82. What cover do you have? Mine is from dafang camera, and I think because it’s not sending any kind of status for where the “cover” is right now.
Upgraded from 0.82.1 to 0.83.2 and home-assistant won’t start anymore.
On the first startup it upgraded the recorder db as expected (took 2min) and after that it just waits forever.
It waits forever after this line in the log:
INFO (SyncWorker_1) [pychromecast] Querying device status
or after this line:
INFO (MainThread) [homeassistant.components.switch] Setting up switch.neato
No error at all in the logs.
A downgrade to 0.82.1 make it functional again.
EDIT:
This comment made it work again with 0.83.2: 0.83: Fibaro Home Center Hubs, locks via voice, Traccar
Authorization: ‘Bearer hsodjilknlknsdsAAAxbh’
True. I guess if there was the ability to disable integrations instead of delete them, that would be a huge help. There is no real reason why this shouldn’t be possible.
Please repair the non-responsive Lovelace cards, when accessing HA from Windows 10… In 0.82.1 everything worked well, now some cards does not toggle devices…
https://community.home-assistant.io/t/tap-action-on-glance-card-no-longer-working-after-upgrade-to-0-83-1/81862
Hi
I am having a problem using the new switch platform.
It works perfectly with a xiaomi plug that is represented as a switch.
It does not work with a zwave fibaro dual relay switch.
This device is a single zwave node that exposes a couple of switches under it.
Is there anybody else experiencing the same?
Anyone with a Sony LF-S50G speaker with Google Home (or any other Google Home enabled speaker)? I’m trying to use it for BLE tracking but it’s throwing a bunch of errors.
Hi everyone! After updating to 0.83.2 I get an 404 error when trying to access HA. The log reads like this:
2018-12-02 11:32:28 ERROR (MainThread) [homeassistant.setup] Error during setup of component frontend
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/setup.py", line 145, in _async_setup_component
hass, processed_config)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/frontend/__init__.py", line 219, in async_setup
hass_frontend_path = hass_frontend.where()
AttributeError: module 'hass_frontend' has no attribute 'where'
2018-12-02 11:32:30 WARNING (MainThread) [homeassistant.loader] You are using a custom component for sensor.hue which has not been tested by Home Assistant.$2018-12-02 11:32:34 WARNING (MainThread) [homeassistant.loader] You are using a custom component for switch.gmusic which has not been tested by Home Assista$2018-12-02 11:32:35 ERROR (MainThread) [homeassistant.setup] Unable to set up dependencies of logbook. Setup failed for dependencies: frontend
2018-12-02 11:32:35 ERROR (MainThread) [homeassistant.setup] Setup failed for logbook: Could not set up all dependencies.
2018-12-02 11:32:51 WARNING (MainThread) [homeassistant.core] Unable to find service frontend/set_theme
2018-12-02 11:32:57 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.1411190320] Error handling message: {'type': 'frontend/get_th$Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/websocket_api/connection.py", line 65, in async_handle
handler(self.hass, self, schema(msg))
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/frontend/__init__.py", line 502, in websocket_get_themes
'themes': hass.data[DATA_THEMES],
KeyError: 'frontend_themes'
From what I can make of this it sounds like perhaps my frontend didn’t update? Is there a way to force HA to update the frontend dependecies?