Homeseer. Someone helped with set parameter 13 in a different post. Turns out the manual says it is a 1-byte value, but it is a 2-byte. After changing it to 2-bytes then setting parameter 13 worked for me. That gets me around this persistent notification issue for now. Thanks.
1 Like
Exactly my experience as well. Following this thread waiting for a solution.
1 Like
@EricM_Inovelli @EricM_Inovelli Any firmware update on the way to fix this bug for persistent notifications? I see it’s been about 4 months now since it was first reported. I too am using it to show armed or disarmed state of security system, which is very cool, so looking forward to this working as it’s intended.
I updated to the latest firmware and it solved the problem of losing notifications when interacting with the switch, but it didn’t solve the other problem with stacked notifications. When the switch gets two notifications, and the second one is canceled, instead of going back to the first notification it returns to its default color.
I’m running SmartThings, did anyone figure out a fix for this in WebCore?
@ffingers If you’re still willing to build your idea in WebCore I’d be happy to test it out
@LA_MATT.T yeah I’ll give it shot… So the goal is if there was a notification that existed before the current notification… Revert to the previous one correct?
A few questions… Is there a possibility a notification could clear itself? I.e. something closes or something and it clears a notification is it only from a manual clear…may not make a difference when making the code but just curious.
Last question…how many potential notifications do you think could stack…more than 2, 3…the more we have the more complex it gets…but if you think we could get beyond 2…I’ll take a look
You’ll.have to test for me as my ST hub is all wonky with my red series at the moment and am waiting to move to a hubitat but I should be able to write it up.
Give me a few days and I’ll get you an example
Tony
Thanks Tony.
The setup I have is two notifications for different lights. If light A and B are turned on in that order, it displays the notification for light B (turning on light B overrides the notification for light A). If I then turn off light B, it clears both notifications instead of reverting back to the notification for light A.
I think stacking 2 notifications should be enough, I don’t have a use case for more than that yet.
Hopefully that answers your questions.
Matt
@LA_MATT.T Yeah I think that should work. That’s a pretty straight forward use case. Let me take a stab at it and I’ll let you know when I have something to test!
Tony
1 Like
@LA_MATT.T Just a quick update…i’m making SOME progress in that I was able to toggle the status of the notification based on variables and some conditions…I’m trying to error trap all the possible scenarios to make sure it works. Issue here…ST has been horrible lately with my Inovelli stuff so it’s making it very hard for me to tell what is working, what isn’t, and what is delay.
I’ll let you know. Good news is…I think for two stacked notifications, this should be doable…just have to figure out the right process in webcore to do it.
Tony
@LA_MATT.T Just sent you a PM with a possible solution…let me know if you have any questions.
If it works, we can explain the solution for everyone else.
Tony
UPDATE
Final update here…I worked with @LA_MATT.T and we came up with a solution for “persistent notifications.” Now this isn’t the “best” solution, but barring adding memory to the switches themselves and actually trying to manage a queue, this I think is the next best solution. Matt can post his piston in webcore if that will help.
I will describe the logic here and hope that anyone else can figure it out. If you need direct help, please PM me and I’ll walk you through the setup.
Assumptions:
- This will work for multiple conditions, however in this instance we will limit it to two for clarity
- You may or may not have a rule to turn on “notification light” on the switch already - if you do, you can leave it but it will end up being redundant
- You WILL still need to have conditions to turn OFF the notification lights - it will be partly redundant but allows us to not have to trap for extra conditions in the notification light statement
That being said…here’s how it works. The problem statement is (as an example)
Switch 1 is a Red series switch, i.e., can have notifications - Notifications are essentially just lights that are either on or off so Notification light 1, Notification light 2, so on and so forth. If you have a condition that turns on Notification light 1, great it turns on. If condition 2 turns on Notification light 2, it will override notification light 1 as the switch can only display one notification at a time. This is not inherently bad, BUT if condition 2 is false and turns of notification light 2 and condition 1 is still true, the preferred behavior is that notification light 1 would then be on once notification light 2 went out. Unfortunately, because there is no memory on the switches, this doesn’t happen. So how do we fix this. The answer is very simple and basic webcore piston (or any other rule based system). I will describe the logic in my version of pseudo code below 
-
monitor the status change of the conditions that trigger a notification light
On events from any of (device that triggers a notification light) or (device #2)
What this does is any time a device that cause a notification light has a status change, we are going to do something -
if an event happens, then we do a quick pass through our conditions (in this case if a switch is on)
so in the DO block of the “on events from” we create IF statements for as many notification lights or conditions we are using
If switch 1 is on then turn on notification light 1
then a second if statement
If switch 2 is on then turn on notification light 2
If either of the conditions above are true, then notification light will turn on
NOTE: You’ll notice here, in this scenario whichever the LAST true statement is within the DO block will win. As a result, if you have multiple notifications, you can effectively create the priority order by adjusting where they fall in the DO block
That’s pretty much it. I’ll briefly explain the logic.
Anytime a device that cause a notification has a state change, we want to go ahead and update the notification light. So on any change, we go through this simple notification piston turn on the notification light for any TRUE events with the last true statement being the visible notification light. If something isn’t true, it just won’t turn on the light. This works well because effectively we don’t have to remember the previous state of the notification light. Any time a status change happens, we just re-trigger the check.
NOTE#2: This does NOT turn off notification lights. By nature of the script, it will “turn off” a light if a later condition wins but if only one condition is true and that condition turns false, THIS piston will not turn off the notification light, so you still should have a statement for all conditions to turn OFF the notification light if the condition changes to false. This allows us to not have to figure out when to turn off the notification lights within this piston which would just require extra lines of code
This could be extended to as many conditions as necessary. If this was to persist across multiple switches, you could make a group of the “notification lights” and turn that group on or off. This would function essentially as a single piston for turning on notification lights according to conditions. It’s clean and you can have it separated out.
DISCLAIMER: I’m sure there are other ways to do this. Some that likely could be much more involved and maybe more efficient by not subscribing to all events of the triggering devices, but this does not add much overhead and should be pretty reliable as it doesn’t require tons of variables or difficult logic so should execute cleanly.
I hope this helps anyone looking for something like this and as always, if you need some help feel free to reach out.
Tony
1 Like
I’m not sure whether this issue has been addressed, but I found a solid, reliable way to keep my notifications up to date. First, you have to set yourself a priority order. My first priority was my garage door open notification.
Priority:
1 - Garage Door Open (Fast blink yellow)
2 - Doors Unlocked (Slow blink Cyan)
3 - Alarm System Armed (Pulse Red)
Then, Ive created a code that checks each item on the list every 60 seconds. If garage is closed, but doors are unlocked, I get 2. If garage and doors are locked and Alarm is armed, I get red. I’ll post a small screenshot example below. As you can see, I’m running the notifications allover the house. I’ve been running this for a couple of months now and it’s working flawlessly.
3 Likes
I have done a similar thing in RM for Hubitat. Additionally, in locations where I have multiple switches together, I have created second and third rules (for 3 ganged switches) that shifts the priorities 1 (i.e. Priority 2 becomes 1, 3 becomes 2, and so on…) so that I can show multiple prioritized alerts at one location. If only I had 5 ganged switches throughout the house LOL!
I have just recently started using startnotifications and stopnotifications commands (not the child switches) for transitional changes. Like fast flashing red to indicate the garage door opening and fast flashing green for the garage door is closing statuses…
1 Like
Can you elaborate on that statement?
Yes I can
So here is the current rule that sets the notifications for the garage door opener:
The first two “If statements” deal with the garage door as it is opening or closing (transitional). The first “starNotification” command line (used as the door is opening) sets various dimmers to Flash Red-Fast, the second two lines set my fan/light switch indicators to do likewise. The second “If” statement tells these same notifications to Flash Green-Fast as the door is closing.
The last two “If” statements are used if the door is “Open” or “Closed” (Static). Here I set a Variable based on the state. This variable is used in my “Prioritized Notifications” rule (using Inovelli Child Notifications)…
I am sure there are a million ways to do what I am here. These rules evolved as various capabilities were released… At some point, I’ll probably rewrite them…
This is a really cool idea. I wish I had 3 or 4 gang switches around the house. I only have 2, and one is a fan switch unfortunately. Hopefully, Innovelli will make a Fan-only switch with notifications.
@Ma2J thanks for the example, I didn’t realize you were on Hubitat (I’m on ST), hence why I was asking about the startNotification …
@Eric_Inovelli My friend modified the driver and was able to save 5 notifications in the order they happened and turn on the previous one once the current notification is turned off. We are currently testing it on ST and Hubitat.
2 Likes
I’d love to see this too! @n_adam my fault, I must not have seen this one. Excited to see what you came up with!