Inconsistent actions and logging

🛎️ Get Help
1

This issue is regarding physical events not being logged/acted on consistently.
At the time of this report, my hub is at 1.0.8.711 although I've seen this on earlier versions as well.

My initial example dives into a lock that I have, but isn't narrowed in scope to just the lock. I'm seeing this with all sorts of devices (switches, locks, etc).

Since my posts were flagged and hidden in another thread, I'll just move here for a broader topic/discussion on this type of issue.

Post 1:
Switches, locks, motions that worked fine earlier today are super delayed or not working at all now. Z-Wave Information page shows many things dead, unknown or initializing. I tried rebooting the hub and many things still show initializing, Unknown, or Dead. I went all in this weekend, I spent my entire Saturday and into Sunday morning excluding everything from ST (carrying hub in hand on a long ethernet and power cable) using the ST app because 1) it gives feedback that something was excluded and 2) I couldn't get things to include in Hubitat using it's exclude and then discover methods. Now I've finally included everything into Hubitat (carrying hub in hand on a long ethernet and power cable) and it worked somewhat successful for a day but now stuff is just falling offline/dead/initializing/delayed. This is round 3 or 4 for me trying to get this working with the same results each time. I'm walking down a hallway that has a motion sensor that was instant earlier today but now get all the way down the hallway and into a room and sometimes I'm in the room for several seconds before the hallway light even turns on (if it does). It's like I can get things included into the system but can't keep them working. I haven't even been home to change anything for most of the day today, perhaps our absence and lack of physical activity in the home exposed the issue? I come in and walk through the house and everything stays dark, then seconds to minutes later lights start coming on. I don't get it.

Post 2:
Here's an example using a lock that worked perfectly earlier today. I could use Hubitat to lock/unlock it. I received reports of it unlocking/locking but suddenly I am not anymore and I have no clue why it's not. I've been gone most of the day and came home to it working (a rule triggered on unlock that changed the home mode and did some other things) but then it quit. (For those curious, this is a Kwikset 910)

Post 3:
I tried my lock again and was able to immediately unlock and lock it but Hubitat didn't show an update to the Last Activity timestamp and it didn't show an update on the devices Events page although it caused the lock to unlock and then lock back on command. When I made this second video it didn't work immediately again which is what I was trying to capture. It seems that when I clicked refresh on the page after issuing a command the lock reacted to that page refresh, but again the last activity timestamp and device events page didn't reflect the change.. Also when the lock unlocked on command from Hubitat, the page didn't reflect that the lock state was unlocked (you can see it as I scroll past and forgot to mention that). There's definitely some voodoo going on in Hubitat land.

1 Like
2

As I sit here in my home office, my light turns off (10:17pm) so I go check the device events page. It shows the light was last turned off at 10:03(digital) and on at 10:08(physical). It doesn't show it was turned off at 10:17pm. I go to the office motion device events page and it shows that it received battery, temp, humidity, and lux at 10:07pm. I clicked through the events and the last motion active event recorded by Hubitat was at 11:31am.

3

I have a light that was listed on the Z-Wave Information page as dead. I clicked Re-initialize and rebooted the device. It then showed up as Alive and the switch status was ON (the light was ON as well), so to see if it truly was alive and working I went to the device page and clicked to turn the light Off. The Current States showed "switch: off" but alas the physical light was actually still on. The "Device Events" page shows the device switch was turned off at the time I sent the Off command. It shows it was a digital off. The device/light is actually still physically on.

I have a Rule Machine refresh running every minute which also doesn't seem to be helping with these actual state status updates.

4

i used to have a bunch of similar issues though mine were mostly with zigbee devices. yours seem to be mostly zwave devices but if you have zigbee devices, changing wifi and zigbee channel setting helped me a lot. might be worth checking those if you have any zigbee devices.

1 Like
5

Darn. I am sorry to hear about your woes. Smart things quit controlling my lock today so I started in on the all in thing. I have nearly everything switched now except for the lock. Here's hoping everything remains solid.

1 Like
6

I've had similar (but less frequent) issues with my Schlage Connect z-wave locks. I have two installed, and once in a while one of them would stop responding to lock or unlock commands. They would still send physical locking and unlocking events.

I check the z-wave settings page and it would show as FAILED or INITIALIZING. Sometimes if I wait a long time it recovers on its own, but sometimes I have to power cycle the lock and Re-add the lock (without deleting it).

I suspect it is an issue with sending secured commands or whatever it is called. One of the hubitat developers mentioned it as a possibility and are looking at it.

I haven't ruled out z-wave being flaky in my house. I'm trying to find a cheap z-wave repeater but no luck so far for me heh.

2 Likes
7

I am also noticing that at some point events are not being fired, but devices still seem to work. A reboot always temporarily fixes the problem. I submitted a ticket to support a week or so ago (when the hub was really getting locked up) and was told it might be due to an issue with secure devices that they are looking into. I didn't see anything about that mentioned in the latest release. The support person did tell me that my back door lock was rejecting secure connection, so I put the hub on a long ethernet cable and set the lock up again, which took care of that problem.

I need to spend some time actually seeing how long it takes for events to quit being triggered so I can better explain the issue to support, if I decide to submit another ticket.

Is there a way to know which devices are secure? Apparently there should be something on the device page where it lists the in and out clusters, about secure pairing being complete. But not knowing which devices are secure, not sure if I still have some that aren't properly set up.

1 Like
8

Just got home and checked the hub, I only checked the front door sensor and it hadn't reported any events (on the device event page) since the 5th. I went to work through the front door and came home through the front door, so there should have been something. I also didn't see any logging, but the logging for the sensor gets turned off automatically after a while and I have a lot of trouble remembering to leave the log tab alone :persevere:.

I rebooted the hub and then opened/closed the door, still nothing. Finally I did Configure and then tested again, and boom! Events are showing up on the device event page and logging is working (I turned it on before I did configure). I checked the other two door sensors and they have no events since yesterday, but they have been opened and closed today too. Now they are working after repeating the steps I did with the front door sensor.

I don't want to open another ticket if this is somehow connected with the "secure devices" problem that support mentioned about my last ticket. Any advice?

All my door/windows sensors are Aeotec by Aeon Labs ZW120 Door / Window Sensor and I'm using the Generic Z-Wave Contact Sensor driver.

One other thing: the log shows this for the front door sensor:

NotificationReport cmd:NotificationReport(v1AlarmType:0, v1AlarmLevel:0, reserved:0, notificationStatus:255, notificationType:6, event:22, sequence:false, eventParametersLength:0, eventParameter:[])

What does this mean? I set up all the sensors right by the hub and none of them show that they are securely connected. Maybe I need to retry, if they are supposed to be securely connected?

9

in this case it means the contact sensor is open.
Those are the debug logs btw, really only for us to make sense of.
devices that have been paired securily should have something similar to following in the data section of the driver details:

  • zwaveSecurePairingComplete: true
10

Glad that is just an event and not a problem :slight_smile:

Is there a way to determine what devices SHOULD be securely connected but have failed? My back door lock failed secure connecting and I had no idea, because I could still control it and see events for it. When support pulled logs from my hub they told me that the back door lock was rejecting secure connection requests. Then I took the hub to the lock and set it up again with success. There was nothing on the device page to show that secure connecting was even attempted.

11

My whole system has pretty much just gone crazy now. Lights aren't turning on with motion. Physical switches that toggle other switches aren't toggling the other switches. If it does work it's severely delayed (by several minutes). I've been walking into rooms then out and I'll be out for 5 or 10 minutes and then lights come on. Sometimes they turn off when I enter the room (assuming it's just being delayed from the last time the off command was sent). There's no rhyme or reason to it. I've had to unplug the hub so we can have consistent lights.

12

Just a couple of general points.

You can always determine which devices have the option of secure pairing by checking their conformance statement on the official zwave alliance products site:

https://products.z-wavealliance.org

Then check the user manual to see how you accomplish secure pairing for any specific device. note that some devices will only pair securely if they are very close to the hub, sometimes called "whisper distance." This is true of many locks, and means that it will need to be paired within a foot or a foot and a half of the hub.

Zwave locks in general, and Schlage in particular

Z wave locks are a special case, separate from all the other secure pairing issues for zwave.

In addition to secure pairing, most of these locks use a feature called "beaming" to improve battery life. This usually means that if your lock is more than one hop from the hub, you need to make sure that the repeater closest to that lock supports "beaming." For example, some Z wave light switches do and some do not.

Again, you can check any specific device by looking at the conformance statement at the official Z wave alliance products side. ( you are checking the repeater, not the lock.)

If there isn't a beaming repeater close to the lock, some messages will get lost. This is the most common reason for a zwave lock's status to be incorrect. It can also mean that you can lose the ability to control the lock.

And add number six to my reasons for hating polling: excessive polling could mean that the repeater that should be handling messages to/from the lock gets busy with polling messages coming through the network and then you lose control of the lock from time to time. :disappointed_relieved:

Schlage Locks

When you add a Z wave lock to a zwave network, a security key has to be exchanged.

For almost all brands, if the security key fails to exchange correctly, the lock will indicate that it did not pair. That's not great, but at least you know what you have to do.

For whatever reason, Schlage made the decision that the device could pair to the network even though it couldn't be used because it didn't have the security key.

This will drive you crazy. The lock will show up on your device list, it will pass a zwave repair, but lock and unlock commands will be ignored because the lock doesn't have the correct security key stored.

The only way to fix it is to exclude the lock and start all over again.

In addition, Schlage locks have a physical calibration step which means that you have to have the lock installed in its final location before completing pairing. Again, this is not necessary for most other brands.

You put all of that together, and even though the schlage locks are good locks, they have hands-down the most frustrating pairing process of all the major brands and are the most likely to look like they paired but still fail to heed network commands.

If you are doing a partial move of devices from another system, make sure that when you bring your locks over you also bring over beaming repeaters as needed.

And if you have Schlage locks, just be prepared for some trial and error during the pairing process.

4 Likes
13

I powered my hub back up to do more testing. It's been offline since lunchtime today. It's been online now since 9:41 CST, It's now 10:30 CST. Using the Hubitat web interface, I instructed a switch to turn on at 10:18. It still hasn't turned on. The logs show a "digital" on at 10:18, but the light did not physically turn on. At 10:25, it shows that it was turned off, physically although it wasn't even phsyically on at 10:25 to be turned off.
The (GE/Jasco) switch in question is 3 ft from the Hubitat hub, so it shouldn't be a repeater / range issue.
This is just one example of many. I'm seeing this all over. I have no clue where to go. These (lights/motions) worked fine on ST so there has to be something going on with them being in Hubitat now
(again everything was excluded from ST 3 times using ST general exclude before I included/discovered them in Hubitat. I used a sweep method, all devices excluded, ST offline and then Hubitat brought online and all devices discovered/included).

image
image.png759×328 13 KB

14

Can you post a screen shot of your zwave information page?

15

image
image.png1474×942 42.4 KB

There is much more than this, but this includes the example mentioned (Under loft lights).

16

I'm sure that's very frustrating. :disappointed_relieved: OK, at this point I would look for local interference. How far away is the SmartThings hub from the hubitat hub? Or it could be a defective zwave radio. You have put in a ticket with hubitat support, right?

17

@JDRoberts

I went all in with Hubitat on this round. I really want that local execution. The SmartThings hub is unplugged, everything excluded (3 times to be sure).

I included everything in Hubitat carrying it around on a long extension cord and ethernet cable to make sure everything was included within inches of the hub.

I started around 10am Saturday and finished around 1am Sunday morning (yep, long tedious process, but I did write a few rule machine rules along the way). Things were working well, rapid response, etc. Then went to Church Sunday morning, a picnic Sunday afternoon and by late evening when we arrived back home everything was falling apart. Lights were no longer turning on when we entered rooms, sometimes after being manually turned on when we returned they turned off, etc.. It's just a mess. I don't even know where to go with this. It takes so long to switch platforms and rebuild rules!

18

Ok, firstly for this specific driver and device combination, physical/digital is going to be a crap shoot, we try.
The debug lines (parse description) here are easy to understand, these are the data packets sent from the device.
Command 2003 is a basic report if I recall, payload 00 is the device reporting off, FF would be on.
I see the device taking 20 or more seconds to respond to the refresh command, that's not right.
In the zwave details I see a number of incomplete pairings, and several dead devices.
These can be indicitave of interference issues as @JDRoberts has suggested.

1 Like
19

And now based on my auto-mode rule to change the home to night mode based on no motion in the common area's of the house between specific night and morning times, my home changed to Night mode which only monitors my doors (contact sensors) and at the same time it activated the alarm sequence (texts, pushover, sirens). I look at the dashboard and it shows my "back door" is open which I guess is what triggered the alarm, but my back door is physically closed. I had logging open at the time and my back door wasn't in the logs anywhere so it doesn't seem that it sent an open or close event.

20

Until we figure why your zwave network is clogged up, commands just aren't going to be delivered timely.
I take it you have run a zwave repair?