2023.6: Network storage, favorite light colors, new integrations dashboard

Since I updated to 2023.6.1 Node Red is connecting and closing connection to http://supervisor/core in a loop so flows cannot be triggered. Restore to 2023.5 runs fine. Any ideas?

1 Like

Daikin also broken for me. Had downgrade before I had time to get some logs unfortunately but I’ll go again soon

The default Sun integration does not show on the default dashboard anymore. Is that intended?

I’m having a fun one…

I just upgraded to 2023.6.1 from 2023.5.4 and for some reason it keeps forcing my router to reboot. As it’s not up long enough for me to downgrade again (and the backup is no help) I’m a bit stuck.

I’ve not seen what could be causing it. Almost nothing is coming up properly and I’m thinking it’s something in the Supervisor itself which doesn’t like something. I’ve disabled all the add-ons and unplugged both the Zigbee and Z-Wave sticks, but nothing is working.

I’m running a Supervised install on an old thin client. I’ve updated the base OS (Debian Bullseye) and made sure that Python 3.11 is the default version.

Right now I’ve had to disconnect it from the LAN so I can work from home today, but sooner or later I’ll need the lights working. I’m at a dead loss…

You should be able to access SSH if you have that set up. That will allow you to see the supervisor logs to see what’s going on.

As a sidebar, python3.11 doesn’t matter on a supervised install because that’s included in core. When you update HA, the container running core updates with python 3.11. You do not need it on your OS.

Check this https://community.home-assistant.io/t/updated-entire-network-crashing/579664

Do you have the user homeassistant created on the NAS host with the credentials you entered in the dialog? If you can connect to the share from a local PC, you can just use those same credentials in the “add network storage” dialog.

My only complaint with the existing setup is it’s not allowing access as a guest (password is required in the dialog). Other than that, this works fine.

I couldn’t connect to my synology share with cifs also, even though i can connect from PC just fine. NFS works, though. It seems that either we’re missing something or there’s a bug in HA…

Also: password with sign “=“ included is not accepted… WHY???

Not sure what smb version is your nas using, but in hassio is version not possible to specify and therefore nas with smb 1.0 is not working.

Not sure for MrBorg, but if he has default settings like me then minimal version is smb2, max.version is smb3

Just for my pride and reputation.

I do not tinker with the discovery. I am running zigbee2mqtt as recommented for Home Assistant.

But the input field for the home assistant URL (which home assistant uses to link to the z2m site) does not check the format in the UI. So I had put the IP address without http:// in front. That naturally must go wrong if everything expects a full URL.

But Home assistant should not crash the entire MQTT integration because a field does not match the exact expected format. It is normal coding practice to always check all user data (messages from MQTT must be considered user data) and handle errors properly. The code should ignore the data in the url field and issued a warning in the log and not crash the entire integration so mqtt.publish service calls that are unrelated fails.

A crash like this may even be a security issue. It is often untested user data that attackers abuse for arbitrary code execution exploits

1 Like

I’m sorry, I don’t follow your logic here. If you input the wrong url, the integration will not work. That’s the same for all integrations. It’s not “crashing”. And there will be an error in your log.

If you’re not referring to that field, the you should clarify because you may have found a bug. Which btw doesn’t require a “software should or shouldn’t do” dissertation on why you’re upset with functionality. It’s simply a bug that should be reported.

You are trolling. A moderator that trolls.

I posted my experience here not for developers (that is what bug reports are for) but for the users that reported problems with mqtt stability in recent versions.
Maybe they can make things work by checking this exact thing - zigbee2mqtt is popular. Or similar fields.

And now that I am home alone I could make my house without zigbee2mqtt to get the logs for a real bug report for the developers. I posted this earlier today.

2 Likes

SSL access via my DuckDNS hostname also failed after 6.1 update (6.0 is fine). I am using some port redirect on my firewall to allow outside access and I also use the external name (duckdns.org) on the LAN. This worked fine in 2023.6.0 but not in 6.1. I restored from 6.1 to 6.0 and it works again. Access to https://my.lan.ip:8123 still worked.

I’m not using the DuckDNS addon, only LetsEncrypt (I update my external IP to DuckDNS from my Firewall).

Btw HA is run on RPI 4.

I am not trolling I’m replying to posts that I consider trolling. It’s the same every month. You don’t raise issues when you find them and complain about it like it’s being done on purpose to make your life miserable. I’m trying to get you to just create the issues without the unnecessary complaining. That’s it

12 Likes

I realized that “template” platform supports both ways:

And the new “command_line” platform supports only the “bottom way”.
Do not find it consistent.
This issue was closed by developer, said smth like “it was discussed & agreed” (addressed to this topic).

That’s because it is no ‘issue’ (as in ‘bug’)

The fact you (me too) may find it inconsistent doesn’t imply a bug ……

Nobody said this is a bug.
There is difference between “wrong” & “inconsistent”.
As I already said, the issue was created since there is no Discussions in “core” section. Now I think that I should create a Discussion in a “architecture” section. Finally, I was addressed to a dedicated discussion.

2 Likes

Same issue here

Seems that this also broke automations where MQTT is used as a trigger, or at least that is what I can gather from the very vague error message

The mqtt platform for the switch integration does not support platform setup

I’ve already switched over to the new format for all my MQTT devices, but the old format is still used inside of automations. Is this no longer supported either?

this how I have it setup at the moment

automation:
  - id: ai_trigger_person_in_backyard
    alias: AI trigger person in backyard
    trigger:
    - platform: mqtt
      topic: "BlueIris/backyard/Status"
1 Like