I’ll let you be the judge of that yourself off course. I think it is a great tool, probably has commonalities, but in general is a more config-based solution where Ticker has more UI and user-driven approach that allows users themselves decide what they do and don’t want to receive and under which conditions.
Other than that, I think there are some things either tool will do which the other doesn’t, like handling action buttons, which I recently added to Ticker and which is not in Supernotify afaik (sorry: I am a bit biased here probably )
For those that ran into this bug where changing conditions in the admin screen caused an error on save: just pushed a hot-fix v1.3.2 to address this issue.
Either wait for HA to sync and show this as an update, or re-download through HACS manually to activate this code change. A (hard) browser refresh should be all it takes to load the fix! Thanks to xenonaxel for reporting this in Github!
Thanks for this extension and being on top of fixes. You’ve mentioned a road map of features.
Did I miss it? Where can I find it. Just don’t want to bombard you with feature requests if you already have them planned.
The one big one for me is I’d like it to be an opt in rather than opt out. When creating a category there is no option to default to never.
This would go a long way in improving the Home Approval Factor. As of right now I’m just disabling them for my spouse
Thanks for being honest. I agree this needs to be at the top of the post.
Additionally how much code review have you had done with its output? Have you run it through security checks and sanity checks to make sure it’s not being wasteful? That’s one of the biggest issues with AI generated code. It spits out what might work without any overall understanding of the code as a whole. That takes an experienced software engineer to see the big picture and understand what can be made better by proper code review. Without it, it makes me very hesitant to install this generated code into something that runs my house.
appreciate the honesty, and I get the hesitation. I’m confident in the quality but I’m not going to ask anyone to take my word for it. The repo is public on GitHub. Have a look, open issues, judge it on the code itself. That’s what open source is for and I am open to any feedback and scrutiny one may want to impose.
That said, this thread is about Ticker as an integration. The broader discussion about AI in open source development is worth having, but not here. Happy to continue that in a separate topic if you want to start one, because it is very valid and very needed in my opinion. This thing is transformational and can both push this plaform to great heights as well as drown it in garbage and it is here to stay.
That is my question about entirely. About ticker and if it has gone through any code review or security scanning?
AI wrote it which means it should be scanned and reviewed before published. We can’t toss everything over the fence once AI writes it and say “it’s open source, you judge for yourself.” Then we aren’t making things better.
Yes, it is reviewed. The repo is right there. I’ve answered your question and invited you to verify for yourself. That’s all I can do, and it is the exact same response any starting custom component maintainer will be able to give. It is ironic (don’t take that personal, because I mean in general) that AI is triggering that debate.
Release 1.4.0 is ready! A few much anticipated features I think: notifications on your smart tv, speakers and other devices can now be handled through Ticker (including using TTS), as well as persistent notifications and other platform with a notify service exposed.
Also support to set critical notifications (by category or on notification level), some compatibility-features to make sure other integrations also can use Ticker (such as Alarmo), and support for sending rich notifications to all devices (auto-strip html for iOS devices).
Sure using notify.ticker works when calling notify.send_message
action: notify.send_message
target:
entity_id: notify.ticker
data:
message: test message
But not in the same way that other notifiers work. Like your mobile app is notify.mobile_app_phone1
Ideally to make integration with everything work seamlessly it’s be great if ticker registered as a notifier and even created notifier categories. like notify.ticker_general so this could be used for everything. Then we’d be able to use the built-in to send a message to General
action: notify.send_message
target:
entity_id: notify.ticker_general
data:
message: test message
Though I may be completely off and this generates a recursive loop of a notification somewhere.
I did some research on this and, llike you said, it doesn’t quite add up. The Alert integration uses legacy notify. platform calls, which is a different mechanism from the modern notify.send_message action that Ticker registers against. That’s why it works in one context but not the other.
This is an upstream HA issue, not much I can do from my end other than making a suggestion with the HA team to bring the Alert integration in line with the modern notify architecture. Your category-notifier idea is creative, but those would still be Ticker entities under the hood, so the same problem would still cause this not to work.
P.S. In the meantime there is a workaround: you can wrap your notifier in a legacy notify group (YAML-based), which the Alert integration can reach via the old platform path. The HA docs describe this approach here. It was intended for notifiers that need extra parameters, but the same trick gets you around this compatibility gap.
Thanks for checking into that. Of course it’s something silly like that. I did try the yaml notify group and got nowhere with it.
I found this today and it solves the specific case I was working for. So that’s covered.
Now I can work on all the other notifications that Ticker will solve. No longer will I be the only one getting random app notifications when dryers, dishwashers, etc are done. Now I can bring on the wrath of the wife! Until she figures out she can disable them…
The headline feature is AND/OR condition grouping in the subscription conditions builder. You can now mix AND and OR logic — group conditions together with their own operator, up to two levels deep. If your conditions were getting unwieldy, this should help. Existing setups migrate automatically, nothing breaks.
A few other things that have been on the list for a while:
The Automations Manager is a new admin tab that shows you every automation and script using ticker.notify. You can edit the category, title, and message inline — no need to open the automation editor.
Action sets are now managed as a shared library instead of being buried inside each category. Define an action set once, reuse it across categories. This also sets the groundwork for escalation chains further down the road.
Smart notification management adds auto-grouping, auto-tagging, clear_notification, and persistent/sticky status notifications — all injected by Ticker so your automations stay clean.
And there’s a new navigate_to parameter on ticker.notify that deep-links to any HA panel when the notification is tapped. A picker in the admin panel shows your live sidebar panels so you don’t have to guess the path.
Thanks everyone for your feedback and patience — keep it coming.
I’m curious as to where on the Home Assistant GUI the settings/configuration panel (for both the admin and user) are located? In other words, is the panel accessed as a tab at the top of the GUI? I am asking because in my setup the entire tabbed menu is hidden from the user for a small amount of security. I control all user access to which cards they can view independent from the tabs, so I’m curious if this will be an issue for me?
quick note to let you know the new version, v1.6.0, is in beta which did a lot of code polishing and cleanup. Some small bugs that were reported should now be solved and a couple of niece quality-of-life features are added. Try it out if you want by selecting the new beta on HACS.
The added features:
ability to filter, search and clear up logs
expired queued notifications now logged with “expired” outcome and shown faded in user History and admin Logs tabs
ticker.notify category accepts a list of category IDs for fan-out
ticker.notify accepts a clear_when parameter (entity state or event) that auto-dismisses the notification when the trigger fires
Ticker now appears as a virtual device in HA device pickers, making it discoverable to community blueprints (Phase 1 — visibility only; device actions are deferred)
)
Sounds familiar.
