It would be awesome if we could choose which camera to use stream and which to exclude
Do you have another script or custom component running on your local host? You probably allow those script access HA without authentication before via Trusted Networks config. Now since you removed them, the unauthorized access being denied.
Just guessing, if you add back trusted networks now, you will still get warning message said the trusted network access will be removed at 0.96
Anyone else using Node Red with the samsung buttons? I received two more today and paired them using the new zha pairing and it looks like they are not firing the ZHA_Event that I have node red configured to monitor for. My existing one I paired a few days ago on .89 is working just fine still.
I dont have my samsung smartthings hub anymore but ordered a shield link so I can verify that they are up to date in case that may be whats causing the issue. Just wanted to post in case its something that changed in the pairing process that could potentially be causing it. Ill update again once I get the link and have verified they are up to date.
Update: Well I downgraded my Hassio (.90) and re paired it with this version. Does not seem to make a difference so it appears that the new buttons could just be running either newer or older firmware.
Anyone else see any issues with automations after the upgrade to 0.91? My system was working great on Friday under 0.90 but an upgrade over the weekend to test the new stream functions has rendered all of my automations useless for some reason.
I can’t see anything obvious in the breaking changes and the log is not spelling out in any errors in regards automations either.
How the heck do I debug that before the wife gets home?
Odroid C2 with Hassio supervisor 152, HassOS 2.11
@xbmcnut
Are your automations on? This used to happen to me every once in awhile before I realized the importance of reading about initial_state
in automations.
Thanks! Just noticed that. All automations are off as I have never had initial_state: true
set as HA supposed to remember the state when restarted but obviously during this upgrade they all got turned off! Something so simply. I’ll amend all my automations now which should stop a mental breakdown?
I really do think initial_state: true
should be default behavior
“Please note that if for some reason Home Assistant cannot restore the previous state, e.g., because of an interrupted or failed startup, it will result in the automation being disabled on the next Home Assistant startup.” https://www.home-assistant.io/docs/automation/
My problem was, I have a lot of my automations set with hide_entity: true
so some automations had stopped earlier and I did not realise.
but for some reason it’s the other way round.
and in the light of this
it’s even more unpredictable imho.
I personally experienced an issue with only 2 of my automations falling into disabled state after updating to 0.91. They both had initial_state: true for ages, but for some reason I found them disabled straight after upgrade. Very annoying as they are responsible for key options of my setup and it was a bad surprise to learn they can silently become disabled with no log errors etc.
Perhaps will make a feature request about it.
it’s even worse in Lovelace as you can see only what’s included in your views.
fortunately, there is Unused entities section which includes all automations with their states.
Agreed. I have 70% of my automations hidden so this is a real trap for young players. I have previously not configured anything with initial_state: true
as that is the default behaviour. I’ve set up dozens of automations that are hidden and they just work, even after hundreds of restarts and numerous upgrades. This might just be related to the ‘big migration’ but it was damn frustrating as I’ve got lots of key automations enabled that improve my home security. Was beyond happy this afternoon when I released that they were only turned off.
[quote=“system, post:1, topic:109274”]
Notable breaking change
We finished the great migration. All built-in platforms are now in their own folder. This means that if you had a custom component or platform that had the same name as a built-in one, you have to rename it. If you still have platforms in your custom_components/
directory in the old file format, sensor/my_platform.py
, rename it to my_platform/sensor.py
. It still works but it will not be supported in a future release.[/quote]
Does this mean, its no longer possible to override existing components unless you go ahead and give your custom components a new name?
I had it set up the new way and it stopped loading after 0.91:
custom_components/concord232/__init__.py
custom_components/concord232/binary_sensor.py
custom_components/concord232/alarm_control_panel.py
Is that a correct assumption and if so, why was that changed.
I found it really convenient that you could override the existing components without having to give them a different name. If that is the case I’m sad to see this not being an option anymore.
Hi,
I installed the 0.91.2 update, but my Foascam C1 camera still doesn’t work in streaming.
I set the parameter rtsp_port: 88.
can you help me?
I now see the Release Notes do not show what was fixed in the patched versions, even though the 0.91.2 announcement link points to just 0.91.0.
Bug or feature??
EDIT: Browser cache bug. Sorry.
Not sure what you mean, if you scroll a little bit down the page there’s a section titled “Release 0.91.2 - April 8” that contains the changelog.
Grumble, Grumble Stupid browser cache!!
HI, Just to give feedback.
- Fix tado turn on off (@wmalgadey - #22291) (tado docs)
I can confirm it is working again. Thank you for fixing it.
Interested too, how to override a excisting component, you figured this out?
No, I had to rename it.