Adding S2 Supervision to Inovelli Drivers

Switches General Discussion
,
#1

@Eric_Inovelli @EricM_Inovelli

Hubitat has been working on improving S2 supervision–and that is apparently necessary to catch and re-send when a S2 nonce re-sync happens.

Not sure if that will fix everything–but I do have some issues with LED status and light commands not being properly registered.

Is it possible for someone to work with bcopeland @ Hubitat on putting this into your drivers?

Thanks

1 Like
#2

I’d be curious if the devices actually work when being sent supervision-encapsulated commands. In a driver I wrote for my own use with the LZW30-SN and LZW31-SN, I had to remove this encapsulation for outbound (from hub) commands, otherwise I had problems. (It’s been months and I don’t remember what problems, but I think it was the command just not working — like the switch not turning on off. If any commands should work, those seem like the best candidates…)

This shouldn’t really involve needing to work with Hubitat, though they might be happy to help; they have guides for developers on how to do this (this was supposed to be the first of a series, but so far it’s the only one — but luckily it’s the one on this exact topic :slight_smile: ):

The one thing that should be different from that guide is that you’ll need to account for concurrency, with their new recommendation being ConcurrentHashMap instead of a plain Map (the latter of which they still use in the post above).

But … either I’m missing something or these devices just don’t handle these commands well, so I’d be curious either way!

4 Likes
#3

We’ll definitely take a look at it. We’re pretty tight with Bryan, so if we need help, we’ll reach out :slight_smile:

Just to give a sense of a timeline, Eric’s in the middle of trying to work on this issue: Inovelli Scenes slow to respond from multi-taps of switch - Devices - Hubitat which does seem to have an issue with S2 (at least this is what we’re seeing with a different 700 Series hub).

And also he’s working on a couple other projects, so I’m not sure what his bandwidth is, but I’m sure since he’s tagged here, he’ll add it to the list!

2 Likes
#4

One thing I’ve noticed is that it seems some of the LED commands bottle up the network a bit. I’m hoping that full, proper S2 protocols might help thing work better (although sending a bunch of RGBW commands to 8 devices at once does generate some traffic).

Thoughts on when you might be able to look into this matter? I know Bryan’s been going whole hog on spiffing up the S2 protocols in their drivers to address various issues, with good results.

Thanks!!

#5

Multicast!

2 Likes
#6

My networking self just shuttered.

#7

I’ve had multicast fail to deliver to a couple nodes. I agree it is much faster but it doesn’t guarantee delivery. @harjms I hear you

3 Likes
#8

Everyone hears me (laughs in multicast).

1 Like
#9

If you want everyone to hear you, you should broadcast

#10

Not trying to cause a storm here. Igmp only. :slight_smile:

#11

@Eric_Inovelli @EricM_Inovelli

Tonight, I saw these in my logs:

image
image2406×474 110 KB

#12

Thanks Rob – @EricM_Inovelli – can you take a look at this when you get a chance?

1 Like
#13

Thanks, I saw this mentioned somewhere else as well. I will fix it ASAP.

1 Like
#14

This has been fixed. Latest drivers are in github.

2 Likes
#15

What about updates to incorporate fully compliant S2 Supervision support? That seems to have been beneficial in the behavior of other S2 devices (better handling of “ack” matters, nonce issues, etc.). Granted, not an entirely trivial protocol change.

Hopefully, you’ll be able to slip this in the drivers. :slight_smile:

#16

For sure, I plan on adding it. Do you see a lot of commands missed from S2 Nonce getting out of sync on our devices? I haven’t seen this too much on Hubitat, but it might just be my setup. Our latest beta firmware for the dimmer reduces extra packets and should help out on this issue if it is there.

1 Like
#17

I’ve not gotten into the packet weeds.

However, I’ve got a gut feeling setting the LED strip colors on about 10 devices at once really gums things up.

From what I’ve heard mentioned, ack handling is far better for S2 devices that use S2 protocols. And, nonce issues reek havoc without it.

So. I sense/see network issues with color changes. And I have hearsay information (Brian Copeland) on others.

:smiley:

Thanks!! Looking forward to it!!

#18

@EricM_Inovelli To elaborate slightly.

I had to really adjust how I was doing my LED Color Strip setting to reduce traffic–and the hub, in general, doesn’t seem to do well with a lot of traffic. So, setting 11 LED Color Strips at once has proven to be “impactful”.

I’m hoping that the S2 supervision will make that less so.

And, I’m interested in your latest firmware update. :slight_smile:

#19

Multicast works for this stuff guys, just saying :smiley:. I assume Hubitat does that?

#20

It does not. :slight_smile: I’m hoping they can add it some day, but last I saw, they said that the Silicon Labs Z-Wave SDK that they’re using does not provide an API to do this that they are aware of (a little odd for the official SDK if you ask me, but lots of things are odd with it…).

This is handled at the driver level, and if anything will just make more traffic, given that it will resend the command a few seconds later if it doesn’t hear back. It might ultimately increase reliability — and is supposed to — for that reason, but since multicast isn’t an option, putting a few hundreds of milliseconds or more of delay between each of these commands in your Rule, app, or whatever you’re using to do this is probably the best way to avoid that in the meantime.

1 Like