Hey guys, thanks for being patient with us. All of the workaround that have been suggested have been great and hopefully many of them can use them. As for the underlying reason for the notifications not being persistent, it is something that we are addressing in the firmware.
2 Likes
I’m seeing two different persistence problems being reported:
-
Changing the light level resets the LED, which makes the notification disappear. I ran into this problem myself. I see this being 100% a firmware issue.
-
If the switch got notification A and then notification B, and notification B is cancelled, then the switch returns to its default color, and notification A is lost. I’m a bit puzzled about how this would be a firmware issue… unless the firmware is going to be radically revamped. Let me explain…
I’m using Home Assistant to control my ZWave network. In HA when we access a ZWave device, we get the device directly as it exposes itself to the ZWave network. Looking at what the LZW31-SN exposes to the ZWave network, I don’t see any notion of “notification”. What we do get is parameter 16 which allows setting the LED to a different color, intensity, add an effect, etc. So looking just at what I see exposed to the ZWave network, I’m not seeing evidence that the firmware knows what a “notification” is.
From what I can tell, the people who have been reporting the 2nd issue use Hubitat or SmartThings. I’m not familiar with these platforms but I did take a look at the files Inovelli provides for these platforms and it seems to me that the notion of “notification” is an abstraction that is created in the Groovy files for those platforms. The code there converts the notification to an operation on parameter 16. Again, the switch has no notion of notification. Some logic in Hubitat or SmartThings would have to be implemented to keep track of active notifications.
Kind of, but this is separate from the parameters, these are inbuilt notifications in the preferences, and there are up to 5, each with 4 settings (type, color, persistence, etc.).
My expected behavior is that if Notification 1 is indefinite (garage door open) and the front door opens and I have a 10 second notification to Notification 2, then the Notification 2 would override Notification 1 for the 10 seconds, but then it would return to Notification 1 (assuming garage is still open). Right now the switch returns to “normal” operation (blue bar) while notifications are still active. That is what behavior is NOT expected.
Last example:
Notification 1 - Indefinite
Notification 2 - 30 seconds
Notification 3 - 10 seconds
Notification 4 - 5 seconds
If Notification 1 is already triggered, then Notification 2 is triggered, and while N2 is going N3 goes off, and while N3 is going N4 goes off, I would expect:
N4 for 5 seconds
N3 for remainder of 10s duration
N2 for remainder of 30s duration
N1 indefinitely until cleared and/or notification turned off.
Confusing perhaps, but I believe intended behavior.
1 Like
I am having this same problem as well in SmartThings. I use Webcore to turn my notification bar to green when my Smart Home Monitor is set to Disarmed and Red to when my Smart Home Monitor is Armed to Away. The problem is that when I interact with the switch, my notification bar color is wiped out and goes to blue (the default). In my case, I don’t even care for the color of the notification bar to change while I am turning on and turning off the light involved. I really just care for the notification bar to show the status of my alarm (green or red).
1 Like
Hey @mmarques – no, not yet. We are collecting bugs/enhancements and will hopefully have an updated firmware file soon to share.
We’re at CES this week where we’ll talk to the manufacturer about these issues and hopefully get some sort of ETA on when they’re team can help tweak the files for us.
I’ve added this to the LZW31-SN thread here and once we’re back, settled, organized and have trained the new CS reps, I can start providing better updates as I’ll have more time to be in the community.
Did this firmware come out yet? I am having the same issue with the persistent notifications where interacting with the switch clears it.
I suppose it wouldn’t be that bad, but for some reason on the LZW31-SN I cannot get parameter 13 to work to set the normal LED color either. I can set other parameters over zwave, but it won’t take setting parameter 13 to anything for me. Specifically I tried values of 1 and 80 (red and a green) using 1 byte as specified and no go. Stays blue.
I’m waiting for the firmware update before buying any more.
Which hub are you using?
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