2021.4: For our advanced users ❤️

Sounds like a sqlalchemy cache issue. Try changing your recorder to this:

recorder: 
  db_url: 'sqlite:///:memory:'

Let HA boot up then shut it down gracefully. Then change your recorder back to your original and see if that fixes it.

1 Like

Or just keep it like that, that’s what I do :smiley:

2 Likes

Nope…didn’t do the trick…
@ludeeus Was the for me… ??

Thanks. When the automation has been started for first time after a reboot I get a trace. :slight_smile:

Look in the corner of posts and you can tell who it’s directed at. If the arrow doesn’t exist, its directed at the previous post. which you can confirm by looking at the previous posts replies.

Ah…yes…now I get it…
@ludeeus
Maybe I do that too…leave it as suggested:

1 Like

I’d be remiss to not point that should you leave it like that (which is GREAT for performance in HA), you’ll lose statistics and history if and/or when you restart. I would run it this way only if you either don’t care about history and/or statistics or are using something InfluxDB.

But, like @ludeeus, I run this way as well along with exporting data to an external PerconaDB server and InfluxDB for long term historical data and graphing.

1 Like

I’d restart mysql / mariadb just to make sure there isn’t something stuck - HA doesn’t appear to do much once it’s issued instructions on how to alter the database, it’s the database server doing all the work. It’s probably not happy that you did things to the database it was trying to work on.

Great! Now I didn’t have to write that, I do it because I just don’t care :smiley:

1 Like

The breaking changes for Z-Wave JS are not mentioning the current event name which makes it harder to see if the breaking change is applicable.

So for everyone using event_type: zwave_js_event this has now changed to either
event_type: zwave_js_value_notification
or
event_type: zwave_js_notification.

2 Likes

For those with a GoControl (GC-TBZ48) zwave thermostat, after updating to 201.4 the temperature was stuck/not updating, had to remove the node and add it back to resolve the issue but it’s been working normally thus far.
EDIT:
Nevermind, temperature does not dynamically update.

MySQL runs on my W10 machine and other db’s run fine.
Also very accessible with Navicat, so that is not the problem…and machine has been restarted after the issue (for another reason though)

HA just doesn’t seem to create the database,

And this: “Invalid config” reported by HA is bothering me…
image
Nothing was changed in config, and nor config checker nor logs tell me anything useful :face_with_raised_eyebrow:
I’ll run it with dev core with debugger later and try to figure out what’s going on…

I’m pretty sure it is processed by single process regardless database.

I think the db migration proces should start in parallel to working system. After finished the system could restart using new db this time. It would minimize outage to required minimum.

It’s because that automation hasn’t fired yet

I used to see that often after a reboot. The system assumes a default state of home if one is not specified I learned in the launch video this week so best bet is to set a default.

With that said after Life360 being so intermittent the last year, and it was causing some of my arrive at home automations like HVAC, alarm, and lights to fire soon enough OR I set my geofence larger and then they fire when I am 8 blocks away. I tried traccar as well, but ultimately the mobile app for Home Assistant is actually the best tracking app I found. Might want to check it out.

I’ve upgraded to 2021.4 first and to 2021.4.1 after, but after that upgrade OpenWeatherMap doesn’t work, this is the error:
WARNING (MainThread) [homeassistant.config_entries] Config entry OpenWeatherMap for openweathermap integration not ready yet: unsupported operand type(s) for /: 'NoneType' and 'int'; Retrying in background.
I’ve tried to remove the integration and than add again, but the problem persist.
I’ve HA Core on raspberry PI 3 model B, before this upgrade OpenWeatherMap (2021.4) worked correctly.
Thanks

Thanks, but how are we to set a default on a tracker…? It is supposed to track…
And, it behaved perfectly before so why would they have changed it?

I have the same problem, but didn’t find a solution so far.

Could you answer another (but related) question?

I know that listening for “*” will listen for all events in HA.

But can we use wild cards more generally when listening for events?

such as will listening for “zwave_js_*” listen for both “zwave_js_value_notification” and “zwave_js_notification”?

We have adjusted this tooltip in release 2021.4.1 to make it clearer.

2 Likes