Gladys v4.0.7 is available!

News
1

Hello everyone!

It’s Monday, it’s the day of a new Gladys Assistant 4 release: v4.0.7 :partying_face:

This update brings a highly anticipated new feature, as well as numerous performance improvements, especially for instances with many devices (hey @Terdious :p), and Gladys Plus users! :slight_smile: (whom I thank once again for supporting the project!)

1) The ability to inject variables into scenes.

I have updated the documentation, it is now possible to inject a variable into a message in scenes.

Read the documentation: Envoyer un message | Gladys Assistant

Demo:

https://imgur.com/a/dbiQxxV

2) Improvement of performance and stability of sensor data writes

For those who have large installations, I had noticed a bottleneck when inserting new sensor values.

A transaction in the Gladys backend slowed down the entire insertion, and was not very useful because, in the end, given the write rate, it caused more harm than benefit.

After reworking the API route, we achieve really solid performance, and consistent over time. Your Gladys instance can now handle hundreds of writes per second without any difficulty :rocket:

3) Improvement of Gladys Plus performance

You are about fifty to use Gladys Plus, the paid offer that I propose, which offers remote access to Gladys Assistant, end-to-end encrypted, as well as automatic backups.

Recently, we realized with a few members that the Gladys Plus remote access service was slower than usual, with requests taking around 500-600ms whereas we previously saw figures more around 50-60ms.

I spent a full day investigating, and I discovered that some internal function calls of Gladys (local) took a long time due to DB-level LOCKs.

In order to improve these performances, I decided to remove some database calls, and instead, query the RAM cache (much faster!) where we store some frequently accessed data in Gladys.

Since this change, we have returned to ultra-fast and powerful queries :high_voltage:

The complete changelog is available on GitHub.

How to update?

If you installed Gladys with the official Raspbian image, your instances will update automatically in the coming hours. This can take up to 24 hours, no panic.

If you installed Gladys with Docker, check that you are using Watchtower (See the documentation)

Bravo to everyone who participated in this release!

2

For your information, a small bug affects Gladys v4.0.7 on HTTP actions in scenes ([RESOLU] Scène avec action requête HTTP ne fonctionne plus)

I just deployed Gladys v4.0.8 which fixes this issue!

3

Isn’t there a test for this? That’s a shame, it would have been detected earlier.

Anyway, well done :slight_smile:

4

There were tests, but this was a very specific case that slipped through the cracks :slight_smile:

I added additional tests following the incident to prevent the regression from happening again!

5

Good evening!

I reinstalled on another SSD yesterday evening (I needed the old one for something else) but since then, Gladys has remained on version 4.0.4. By the way, shouldn’t the available image be updated to start with?

Is there something to do to get it to version 4.0.8? I know it should happen automatically, but it doesn’t seem to be reacting.

6

Building the Raspbian image is a manual and very time-consuming process, I only do it from time to time. Given that the update is done automatically, it’s less of a problem.

After that, where you are right, is that since the recent changes to the Docker API which rate-limits API calls, we have changed the update frequency to every 24 hours. So if you install Gladys at time t, Gladys will be up to date 24 hours later, which is indeed a bit late.

It’s a bit of a long-standing debate topic, but we haven’t found a perfect solution ^^ We have a solution to automatically build the Raspbian image, but this solution means that the image must initialize on startup, either from the internet (and thus if you have a poor connection or worse no connection, it doesn’t work), or from a local archive that would need to be unzipped, which means that your Pi would take quite a while to start on the first boot.

@VonOx cc :slight_smile: the eternal debate

7

Yes, the PoC was successful, but the first startup experience wasn’t great because the RPIs struggle to unzip, as far as I remember it took about 15 minutes for Gladys to be up and running. On top of that, there was no way to tell the user « wait a bit because the system is not ready yet ».

I should find some time to look at what HA does for HassOS (buildroot) as it’s also Docker.

https://github.com/home-assistant/operating-system

Edit: I couldn’t help but take a look right away --’

They do a pull during the build, apparently buildroot allows it (Docker in Docker)

8

Ok! Indeed, the latency time can be a bit long. If there is no technical solution for the moment, perhaps we should add a note in the tutorial to specify that the update can take up to 24 hours. Otherwise, what would it cost to reduce the update frequency?

I will check when I get home tonight if the update is effective.

9

Another possibility is to offer to launch an update « now » after installation.

2 things:

  • Docker hub has added very low restrictions for unauthenticated accounts, which means we can’t make frequent requests.
  • The fact that instances only check for updates every 24 hours allows for gradual distribution of updates, as everyone checks at the time they launched their instance, and thus if the distribution is more or less homogeneous, in case of a defective update, if we notice it within the first hour, only 1/24 of the instances have been affected (if we notice it after 2 hours, only 2/24, etc..) and we can correct the situation (rollback, push a fix, etc..).

After that, I don’t think reducing this time will solve the problem.

The approach of @VonOx, or offering a « update now » button after installation, seem more promising!

10

Oh great! So they have an image where you boot directly into the latest version of HA, even without internet? And without any waiting?

11 
Home Assistant Operating System uses Docker as Container engine.
It by default deploys the Home Assistant Supervisor as a container.
Home Assistant Supervisor in turn uses the Docker container engine to control Home Assistant Core and Add-Ons in separate containers.

In the readme, by default the supervisor (which is itself a container).

I need to go fishing for information.

12

The script is actually executed at startup.

During the pull etc., a landing page informs the user that the system is being prepared.

So the system is blank at the beginning.

It’s a bit like what I did except that the user has information :sweat_smile:

13

ok! And how do they display the landing page?

14

It’s a Go app that is pulled at startup (28MB image so relatively fast)

https://github.com/home-assistant/landingpage

They do a build per machine - arch

https://hub.docker.com/layers/homeassistant/raspberrypi3-64-homeassistant/landingpage/images/sha256-f87e6a68d5aac53ac28dfd82989904690f24c23d9ef2a7385198ed90288a6ae8?context=explore

So in fact as long as the user is informed it doesn’t matter how long the preparation takes.
No need to build an image (OS) often. The application is always in the latest version.

From what I see, buildroot also allows building for x86 / x64 and specifically by Raspberry Pi model.

https://github.com/home-assistant/operating-system/blob/dev/Documentation/boards/README.md

15

Ok not bad!

We can achieve the same result with an nginx-alpine (9Mo, nginx - Official Image | Docker Hub), and a simple index.html, it will be even lighter :stuck_out_tongue:

Indeed, I prefer this process if the user knows what they are doing!

If in addition, it can allow us to automatically build the image, I’m definitely interested :heart_eyes:

Shall we restart the proof of concept? ^^

16

I’ve updated my repo and prepared the CI

image
image685×372 19.1 KB

Just need to

17

The discussion continues here:

18

I am bringing up the subject to see if there have been any advances.
I would be a bit frustrated when installing Gladys and seeing that I don’t have the latest version (for a new user).
I indeed had to wait 24 hours for Gladys to be up to date.

Would it be possible to have a version history on the website?
V4.0.0
V4.0.1
…
In order to be able to download the latest or the second-to-last version.

19

In itself, the update is not complicated to do manually via SSH (source):

  1. Download the new Docker image:
docker pull gladysassistant/gladys:v4
  1. Stop and remove the current container:
docker stop gladys ; docker rm -f gladys
  1. Restart Gladys with the update:
docker run -d \
--log-opt max-size=10m \
--restart=always \
--privileged \
--network=host \
--name gladys \
-e NODE_ENV=production \
-e SERVER_PORT=80 \
-e TZ=Europe/Paris \
-e SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /var/lib/gladysassistant:/var/lib/gladysassistant \
-v /dev:/dev \
gladysassistant/gladys:v4

But obviously, automating all this from the web interface is clearly more pleasant :slight_smile:
You can create a feature request on the forum!

20

There is already a post for that
https://community.gladysassistant.com/t/build-automatique-de-limage-raspberry-pi-os/6124