Gladys Assistant 4.85.0: Photo widget, graph navigation, water heater & HomeKit

Hi everyone!

Here is the 4.85.0: a version rich in dashboard, devices, external integrations, and HomeKit.


Dashboard: Photo Widget

New Photo widget to display images on the dashboard (ideal on a wall-mounted tablet).

  • Photos are not stored in Gladys: URLs are configured
  • Gladys retrieves them locally (proxy), so it also works with a NAS and remotely via Gladys Plus
  • Server-side resizing to keep the dashboard fluid
  • Configurable slideshow, optional captions, fill / contain mode

The next step in this development would be to be able to have external integrations with photo storage systems like Immich to have an automatic source!


Graphics: Time Navigation

On the graph widget, you can finally go back in time to compare a period with previous ones (forum request #8514).

  • Previous / Next buttons according to the chosen interval (1 h, 24 h, 7 days
)
  • “In Progress” indicator in live mode
  • Return to Now link as soon as you are in history


Water Heater: New Device Category

Gladys finally correctly manages water heaters: no need to tinker with switches or heating pilot wires.

Six dedicated types: on/off, mode, target temperature, remaining hot water, heating in progress, boost, with a generic set of modes adapted per device.

Thanks to @cicoub13!


Thermostat: Modes and Operating Status

The thermostat category gains modes (off, heating, air conditioning, auto, eco) and status indicators (inactive / heating / cooling), with icons and labels in FR / EN / DE.

Thanks to @sescandell!


Charging Stations: Connector Status

New Charge Station category for the status of charging stations / connectors (available, occupied, reserved, unavailable, faulty), aligned with the OCPP model, useful for EV charging station integrations.

Thanks to @sescandell!


External Integrations: Weather, Updates & Polish

Several advances on the external integrations side:

  • Weather Providers (B.18): an external integration of type weather can replace OpenWeather. The weather box also displays alerts, UV, sunrise/sunset when available
  • “Updates” View in the catalog + counter in the header when an installed integration has an update
  • Local / Cloud tags, browsable ports, port names for manifest placeholders, dynamic options in select fields, home coordinates exposed via the Host API

HomeKit: More Exposed Sensors

The HomeKit bridge now exposes:

  • Light, CO, CO₂, and air quality sensors (including PM2.5 / PM10)
  • Sirens as Switch

Thanks to @Dreamthy for his first contribution!


Perf & Fixes

  • Device history migration (DuckDB) split into slices: less RAM and more visible progress on large databases (forum feedback on Netatmo)
  • “Jobs” link correctly displayed in the “too many states to delete” alert
  • Container select aligned on the logs page
  • Line breaks preserved in the integration publication text

As usual, Gladys will update automatically within 24 hours if you use Watchtower, otherwise a click in Settings → System.

Full release notes on GitHub

For external integration developers, SDK version v0.11.0 is available with all these new features!

The store and the JS template are up to date :slight_smile:

Ask your Claude to update your integrations :wink:

@pierre-gilles For the weather widget, did you implement what I did or do you want a specific PR?

Otherwise, I’ll test and add the external Meteo France integration this weekend.

No, I just kept the existing one, I’d be happy with a PR where you update the existing widget for us!

Improve the design for everyone, the old widget was too cold and was designed in the pre-AI era, might as well let everyone benefit from the new design :wink:

Thanks for this update :slight_smile:

The line break works perfectly

Same for the updates:

Ok, I’ll take care of it in the coming days.
Have you done the openweather external integration or do you want me to take care of that too?

Yes, already done, and available in the store :wink:

Kudos to everyone for all these new features and improvements :heart_eyes:

I have a comment that bothers me almost every time there’s an update: the scenes that have a Wait in progress.
To make it simple, I start the pool pump for a duration that I define and therefore I have a Wait action for X hours. Unfortunately, when an update occurs, my Wait simply skips and if I’m not careful, the pool can run for 8 hours instead of 3 hours :frowning:
Apart from setting up MQTT variables to track an ongoing scene (which I should do), creating timestamps that I also store, and a script on (re)start of Gladys (by the way, does a boot trigger exist?), wouldn’t there be something (new?) to resume these scenes where they were interrupted?

Thanks for the feedback, and you’re pointing out a real limitation of the current implementation :slight_smile:

Technically, the « Wait » block is just a timer in memory in the Gladys process. Nothing is stored in the database: neither the fact that a scene is running, nor where it is in its list of actions. So, at the slightest restart (update, reboot, power outage), everything after the Wait is lost. It’s not a bug on your side, it’s just how it is today.

And yes, the « Gladys starts » trigger does exist, you’ll find it in the list of triggers.

But I would rather advise you to organize yourself so that you don’t need it.

The smartest thing in your case is to have the timer handled not by Gladys at all, but by the outlet itself. Most hardware can do « turn on and turn off by itself after X seconds ». It depends on what you have:

  • Shelly, with the HTTP Request action: http://<ip>/relay/0?turn=on&timer=10800 (Gen1) or http://<ip>/rpc/Switch.Set?id=0&on=true&toggle_after=10800 (Gen2+)
  • Zigbee2MQTT, with the Zigbee2MQTT action: on zigbee2mqtt/<your_pump>/set, you send {"state":"ON","on_time":10800,"off_wait_time":0}. It works on many Tuya/Moes/Aqara outlets and modules.
  • Tasmota: PulseTime 10900; Power ON (beyond 111, PulseTime equals value − 100 in seconds)

Your scene becomes a single action, no more Wait. And the huge advantage for a pool pump: even if your Gladys is cut off or the mini-PC doesn’t restart, the pump still stops.

If your hardware can’t do that, the second approach is a countdown rather than a wait.

You create a number feature via MQTT, like pool_pump_minutes_remaining. Your startup scene turns on the pump and sets the value to 180. Next to it, you make a monitoring scene with a scheduled trigger in interval mode every 5 minutes, which retrieves the value, continues only if it is > 0, rewrites it with the formula {{0.last_value}} - 5, and if it drops to 0 it turns off the pump. The formula mode works just as well on « Set a value » as in conditions, so everything is done with the mouse.

The interest is that it repairs itself: no need for a boot script or the startup trigger, the next cron run catches up on the situation. At worst, you lose the 5 minutes of the current tick.

And if you can settle for that, the simplest solution is two scheduled scenes, start at 10:00 a.m. and stop at 1:00 p.m. For a pool pump, this is often sufficient and it’s foolproof. If you adjust the duration to the water temperature, you can even have 3 stop scenes (12:00 p.m., 1:00 p.m., 2:00 p.m.) each with a condition on the temperature, it’s a bit brute force but it always works.

The principle to remember: the Wait is for short delays within a sequence, like 2 seconds between two commands or 30 seconds before checking a state. As soon as you exceed a few minutes, and especially when a shutdown action is involved, you need to either offload the timer to the hardware or use a stored state that is read regularly.

That said, your original request remains legitimate: persisting long Waits to reschedule them on startup is doable. If you want to open a feature request about it, don’t hesitate.

Excellent method I hadn’t thought of at all.
I have a NodOn SIN-4-1-21 and it seems possible:

On with timed off

When setting the state to ON, it might be possible to specify an automatic shutoff after a certain amount of time. To do this add an additional property on_time to the payload which is the time in seconds the state should remain on.

Additionally an off_wait_time property can be added to the payload to specify the cooldown time in seconds when the switch will not answer to other on with timed off commands.

Support depends on the switch firmware. Some devices might require both on_time and off_wait_time to work

Examples : {"state" : "ON", "on_time": 300}, {"state" : "ON", "on_time": 300, "off_wait_time": 120}.
And as I send myself a message at the end of the Wait, I will have to create a monitoring scene that checks every minute if the module is on or off.

Thanks for the tip!

The documentation is up to date on the site with all the new features of 4.85 + SDK v0.11:

It doesn’t work for me:

Are you sure an application you installed offers an update?
If the application is not installed, nothing is offered
If none of the installed applications offer an update, nothing is displayed either

Yes, I have at least 2 integrations that need to be updated, including yours « vigieau Â»!

@Pierre-Gilles : vu le nombre croissant d’intĂ©grations, une petite coche pour indiquer celle que l’on a installĂ©e (surtout quand il y a deux versions) me semblerait utile.

Good idea :wink:
For now, I’m bookmarking them to find them more easily

@prohand Problem solved by clearing the cache! But I only have 71 integrations and you have 72?

Yes, because it’s my dev instance and I install it manually :slight_smile:

Super update, I LOVE the navigation in the graphs!!! :heart_eyes: