The config is supposed to be stored in .storage now and not need unique filenames like prior releases.
I have 2 WebOS TV’s working…
Do you see the files in config - those should not exist any more. Mine do not.
Playstation Integration is still broken - it says it couldn’t be found on the network even when it’s clearly discovered by autodiscovery, is switched on and has no issues to be accessed from LAN and WAN. Previously added PS4 continue to kind of work but very unreliably.
@jwelter The webostv.conf file is recreated just like it always has been, but with only the details of the last paired tv. There’s no mention anywhere of it using .storage that I can see (and having looked I can’t see anything in the files there).
However the following link (and the link within in it) seems to suggest that use of the .conf file is still expected and likely fixed in 104.1 when released:-
So I guess a few days should see me fixed - thanks for the reply.
When creating Zigbee groups, I’m getting the details for the last group I created (with the devices I added to the new group added to the previous group) without a new group created. There are no errors in the log and I’ve cleared cookies/browser.
These are the groups I’ve been able to create.
Creating a new group:
After clicking on “Create Group”, I get this with lights I added to my Carport Lights group (and no group created):
Stats:
My update from 0.103.6 failed and I had to power off the Rpi. Is there some update log etc where I could try to find the reason?
I was able to get this working by copying the token created by the pairing request, then putting them together manually in the webos.conf file like this: {“192.168.1.xxx”: “a1007cea8ad4be8axxxxxxxxx”, “192.168.1.xxx”: “8011c444f8376143xxxxxxxxxxxx”}
I’m not sure if this is actually doing anything, it may be totally wrong, but it seems to be working for now, as I no longer get the pairing request notification on startup, and the TVs work fine in hass.
Mine is running and no webostv.conf in the configuration folder… So it is somewhere else.
Question:
- What to do with the “newly discovered” Philips Hue bridges? Note they are already discovered…
Almost a flawless upgrade! 
1 Like
This works for me too…and I’d even tried putting commas at the end of each line - I just hadn’t removed the {} around each line individually.
Thanks!
@Vasco @WhistleMaster @KennethLavrsen I think this issue is the result of me normalising bridge id, which groups unique id are based on. I didn’t reflect on this affecting entity unique ids, this should have been a breaking change or done in a different way. I haven’t verified this though
3 Likes
Same here, two new hue bridges discovered. But only one already discovered one is active in my network. Any advices or workarounds? Should I just press “IGNORE” then? 
Read the google assistant docs for how to setup the service account. It also talks about what services it provides.
I have a few https://www.home-assistant.io/integrations/light.group/ type light groups also. And mixed with non-Deconz lights. I did not get any duplications of those.
I swear that section wasn’t there a few hours ago when I last looked! Thanks!
That section was there for a few releases actually. Ever since report state was added 
It is just easy to miss as it is part of the install steps.
The HEOS integration doesn’t work anymore. My devices were unavailable → I removed the integration and wanted to re-add it via Lovelace, but HEOS is not available as an option…
Hi, i have the same problem since the update
How would you do the delete? There is no delete button for single entities in the integrations page.
After updating from 103.5 to 104.0 Home assistant entities cannot connect to mqtt service. It is starting and therefore clients are able to connect that are external clients to HASSIO. Am using HassOS 3.8 with the Mosquitto broker addon.
I get the following in the logs
Mosquitto log:
1579204435: New client connected XXX.XXX.XXX.XXX
HA log:
2020-01-16 19:42:20 ERROR (MainThread) [homeassistant.components.mqtt] Failed to connect due to exception: [Errno 110] Operation timed out
2020-01-16 19:42:20 DEBUG (MainThread) [homeassistant.components.mqtt] Subscribing to owntracks/#
2020-01-16 19:42:20 ERROR (MainThread) [homeassistant.setup] Error handling when_setup callback for mqtt
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 307, in when_setup
await when_setup_cb(hass, component)
File "/usr/src/homeassistant/homeassistant/components/owntracks/__init__.py", line 144, in async_connect_mqtt
context.mqtt_topic, async_handle_mqtt_message, 1
File "/usr/src/homeassistant/homeassistant/components/mqtt/__init__.py", line 442, in async_subscribe
encoding,
File "/usr/src/homeassistant/homeassistant/components/mqtt/__init__.py", line 842, in async_subscribe
await self._async_perform_subscription(topic, qos)
File "/usr/src/homeassistant/homeassistant/components/mqtt/__init__.py", line 878, in _async_perform_subscription
_raise_on_error(result)
File "/usr/src/homeassistant/homeassistant/components/mqtt/__init__.py", line 985, in _raise_on_error
"Error talking to MQTT: {}".format(mqtt.error_string(result_code))
homeassistant.exceptions.HomeAssistantError: Error talking to MQTT: The client is not currently connected.
I get the same in the logs after commenting out:
configuration.yaml
#owntracks:
# max_gps_accuracy: 200
# waypoints: true
# mqtt_topic: "owntracks/#"
# events_only: false
# waypoint_whitelist:
# region_mapping:
# shed: home
# office: work
In Developer tools > MQTT I try to publish a topic but get the following
unable to call service mqtt/publish. Service not found
was working before upgrade.
Thanks!
Same here. Did you find a fix?
I am also seeing an issue with MQTT after the upgrade. I have tried to adjust settings (TLS on/off, using FQDN/IP/localhost) but have not been able to find a workaround.