Basic vs Binary report

Is a "broadcast packet" the same thing as a "hail"? If not, disregard the rest of this post. :slight_smile:

It looks like the Hubitat CommandClass stuff supports 0x82/HailV1 .
https://docs.hubitat.com/index.php?title=ZWave_Classes

Weird that it wouldn't get kicked up to the parser()...but now that a clearer picture of the issue has emerged, searching the forums is becoming easier. It appears that others have had this issue with the C7 and Leviton DZ15S.

Also, in each of those posts, it actually appears that the hail does actually make it up to the driver. Since I'm not seeing the hail, I wonder what's different.

@mike.maxwell wrote that something regarding the hail would be fixed in 2.2.3, but I'm on 2.2.4.158:

One of the posts mentioned looking at the "Data" section of the device details. I do note that they had 0x82 in their outClusters, but I do not. Could this be the difference? How do the inClusters and outClusters lists get populated? I believe they are CommandClass mappings?

  • zwaveSecurePairingComplete: true
  • S2: 3
  • deviceId: 12597
  • deviceType: 18770
  • manufacturer: 99
  • inClusters: 0x5E,0x55,0x6C,0x9F,0x22
  • secureInClusters: 0x25,0x85,0x59,0x86,0x72,0x5A,0x73,0x5B,0x70,0x2C,0x2B,0x7A
  • zwNodeInfo: D3 9C 03 04 10 01 5E 55 6C 9F 22 68 23 F1 00 25 85 5C 59 86 72 5A 73 5B 70 2C 2B 7A

What packet is it?

Some devices send a NIF as soon as there's user initiated activity (such as pressing a switch).

A common trick in the pre-instant status days was for the controller to respond to that NIF packet and send a poll (basic get, binary get, etc).

It was used a lot on Vera and I used it on SmartThings for some odd battery temperature sensors that don't send a wake up packet when they are manually woken up and the default wake up is 28 days! Instead of a wake up packet they send a NIF when they are manually woken up. That made them difficult to configure. By responding to the NIF packet in a driver they were configurable.

When I moved those devices to HE on a C4 running 2.1.something a few years back I believe this trick still worked (else I never would have got the devices working how I needed them to).

A few months back I moved them to a C7 running the latest firmware and that trick no longer worked, the hubitat.zwave.commands.zwavecmdclassv1.NodeInfo that I was previously using couldn't be saved in the C7 editor.

I asked @mike.maxwell if that was a recent change on HE and as far as he could recall NIF's never made it into parse() on HE so that would never have worked ..... I didn't have time to investigate further and moved on (now I configure them based on any report received e.g. the first temperature reading).

No idea if that trick still works on SmartThings, a quick look through the SmartThings source on github doesn't throw up any use of that CC nowadays so perhaps it was removed.

The OP would need a sniffer to see what's different on SmartThings, but I wonder if they moved that CC to something that's handled at the platform level directly i.e. as soon as a NIF is received (outside of Inclusion / Exclusion) they do a poll for basic get.

That could explain why there's a quick basic report on SmartThings following the switch press ....

1 Like

I didn't look real hard at what the broadcast was, but could look again later.

I do know you get exactly nothing via parse on the driver in my C7 when the broadcast is sent. So not sure how anyone would do anything with it on the driver side? But I'll defer to the real developers in that. :slight_smile:

Again, I spent all of 5 minutes on this, so maybe I missed something.

Did you have a chance to look at this?

No, the device is not sending a Hail. I trap Hail in my driver so would have seen it in the logs.

2 Likes

Another thread seems relevant:

So, I'm guessing the Node Information Frame is the broadcast message, as @martyn suggested above. He mentioned that he believed there was some change related to NIF processing between C-4 and C-7 or perhaps different revisions of the platform firmware.

Could someone from Hubitat please confirm/deny if there was a change to NIF processing? If there was, could it be reverted in a future platform firmware update? If there wasn't, could NIF's get passed to the driver-level for processing in a future platform firmware update?

I can certainly understand Hubitat's position that these devices should operate differently and that it is their responsibility to send timely reports, but it feels like this is not some isolated issue related to a specific model or even manufacturer. And, since I have not seen widespread usage of OTA updates, I think the devices are what they are.

As I mentioned, this is something that makes Hubitat unsuitable for this use-case (no-load/remote switch), with this device. Admittedly, this is probably not a common use-case.

Thanks to all who have helped hunt down what is going on here and apologies for the lengthy thread. I've learned a lot.

To my knowledge the NIF/broadcast frames have never been available to use in drivers in Hubitat. I don't remember them ever triggering anything in parse() on any version of the hub or platform software (?). So even if there was "a change" I'm not sure it matters in this context?

@bcopeland or @mike.maxwell can correct me if I'm wrong there.

If we can trigger things in a driver off the NIF, I would love to know how as I would likely go back and add a manual report request triggered off of it for these devices. But I don't think we can.

Would be cool if we could though... Maybe it should be a feature request?

@JasonJoel what are you looking for .. Most of the NIF is stored in zwNodeInfo

@JasonJoel, I guess the feasibility depends if the SiLabs platform stuff makes the act of receiving an NIF available to the higher-up level. My guess is that this information is available.

@bcopeland, It's not really the information contained in the NIF so much as the act of receiving an NIF, which apparently (in this device's case) indicates a change in device status. Upon reception of the NIF, we could manually query device status/request a basic report. In this device's case (and others), this is faster than waiting for the device-generated updates (binary report/basic set/centralscene report).

Doesn't happen in 700 series controller SDK.. NIF is stored in a database and you query the cached node information.

This was extremely non-standard to begin with.. But 700 series controller SDK makes this impossible.

I think that answers the question.

I probably phrased it poorly originally. The question really was whether there was a way to use the initial broadcast packet the devices send out on single taps in a driver, similar to what some hubs did with zwave non-plus devices back in the day. The reason is that the initial broadcast packet proceeds the normal multilevel report by 1-2s - so could be used as a trigger for a manual report request to update status faster than waiting for the normal report the device sends.

I assumed the answer was no, as I haven't seen any evidence that the broadcast packet is available to drivers in any way.

Thanks, as always, for answering our weird questions. :slight_smile:

And I assume that this isn’t going to change in the next 700 series update, in March, I believe?

Correct.. This has not changed in the next SDK

1 Like

How does one read / interpret the info. in zwNodeInfo. I had assumed it was a list of neighboring nodes or something --is that correct or is there something else there?

NIF doesn't contain node neighbors

NifCached3

So, for the example from a few posts above, zwNodeInfo is basically iClusters, but with an extra 6 bytes in the front and it looks like an extra few classes (68, 23) at the tail.

The first bit is a good one for devices that can be listening or sleepy.. If the first bit is on you can send commands anytime.. If it is off, you must wait for wakeup

1 Like

Having access to that "listening" bit seems useful (particularly for sensor devices that can run on either battery or USB so they may or may not be sleepy). Is there a system call or way to get this into a class structure, or do I have to parse it myself? Thanks.

I don't think that is currently exposed to the drivers at all, is it?