The problem(s)
I’ll start with my specific use-case then decompose it into features required by my use-case but also valuable on their very own.
I mainly use LaMetric time with my Ikea Tradfri remote. I use it in the following fashion - two buttons on the remote switch it’s mode (between TV, Light and Music currently).
Whenever I switch the mode of my remote - I also send the notification to my LaMetric Time with the name of the current mode. I also send the notification when I change the brightness of my smart bulbs - to see what’s the currently requested value (in percents).
The problem with this approach is that TIME actually waits for at least 1 cycle of the notification (around 2 or 3 seconds, I think) before displaying the next one. So, if you have switched your modes in fast succession you will have to wait for each mode name to be displayed for ~2 secs. completely losing track of your actions.
Currently, we have the “Dismiss current notification” action in the integration. It’s sweet, but it’s not sweet enough to solve my issue completely.
Because there’s just no way to know when to dismiss the current notification, since you only want to do that when you have 2 or more notifications in the queue.
Another option we have is the notification priority (info, alert, critical) - nice feature but it only really allows three consecutive notifications to override each other plus you’d need to dynamically control the priority key.
My suggestion
- What I suggest is to natively implement notification queue sensor, updating after sending each notification and showing the current quantity of messages in the queue.
Unless there’s a more advanced technique (such as custom protocol), I suggest to use the official API for that.
Pretty sure this param can also be used to creatively control and maybe even reorder the notifications (providing it’s not just the number of notifications, but also some meta information for all of them)
- Having 1 already solves my main gripe, but I suggest to also natively implement the ability of “overriding” the notification. E.g. send a notification with the custom “override” key that will dismiss all previous notifications.
I actually managed to get all of this working using the custom sensor and some advanced automation logic, but it’s really tedious to reproduce this logic each time I want to send the “overriding” notification, plus, it may be useful for someone less stubborn to have this feature as well.
My current implementation
Initially I thought I can quickly hack this into what I want by just putting the “dismiss notification” action right before the “notify.time” action.
This didn’t work out too well: it led to the TIME blinking back to the currently used app, before displaying the new notification.
Then I figured out my suggested approached and implemented it like that:
- first the custom sensor in HA’s configuration yaml. I used command_line as the platform as I wanted to interpolate ENV variables in my API request:
command_line:
- sensor:
name: LaMetric Notification Queue
command: >-
curl -s -X GET -k -u "dev:$(echo -n $LAMETRIC_API_KEY)"
-H "Accept: application/json"
https://$(echo -n $LAMETRIC_IP):4343/api/v2/device/notifications |
jq 'length'
scan_interval: 86400
- after verifying the sensor works correctly (and, most importantly, swiftly), I went on with configuring my automation. I will only post the relevant piece of the automation, I’m assuming that anyone interested is familiar enough with the automation’s YAML format:
- action: homeassistant.update_entity
data:
entity_id:
- sensor.lametric_notification_queue
- repeat:
sequence:
- device_id: 0e90375375f20ee84ad41d4193a56a26
domain: button
entity_id: d562da94f4d7956bf7f5e0c6b9b3db05
type: press
- action: homeassistant.update_entity
data:
entity_id:
- sensor.lametric_notification_queue
while:
- condition: numeric_state
entity_id: sensor.lametric_notification_queue
above: 1