Running on my C8 pro. In my logs for my blind (generic driver) I'm getting a bunch of commands that seem to be unnecessarily repeated. Command retry is ON, but it seems to me that once the hub is told that the blind is closed it still continuing with additional commands.
The blind is closing. But why all the additional commands? In addition the last status ended on "closing", but it had already been closed. I hit refresh in the device and it immediately updated to closed. Is command retry messed up?
I understand that I CAN turn it off, but I'd rather not. As I understand it, if a command is missed it should only get resent if it isn't acknowledged by the device. That's doesn't seem to be what is happening here. Commands are being resent regardless of their acknowledgement. Furthermore the status ended up showing "closing"... After it had already recognized it's status as being closed. Something is wrong.
It may still be worth turning off command retry for that device to see if it is actually causing causing the issue. With the info provided it could be an automation or even the driver. If you turn off command retry and the behavior stays the same then you know 1 thing it’s not.
It may help to goto the device itself and review the events. it should show you what is the trigger is too.
Also command retry should be producing logs like this if it’s involved, so there is a strong possibility it’s not command retry. Turning it off and the log entries remaing the same would confirm it. This is starting to feel more like a driver or device issue to me. Enabling debug logs would help narrow down device or driver issues and knowing what the device is.
I've had to turn Command Retry off for several devices so far. I continually am getting warnings that things have failed after 5 retries, when in fact, the device responded to the initial command just fine. Perhaps not fast enough for the command retry to notice it, The first two devices that I noticed with this issue were my Radio Thermostat CT-100 and my Yale YRL216 Z-Wave Lock. Both of these are Z-Wave, and they are both very slow to respond.
With locks in particular the initial delay for retry is 5 seconds and it backs off with another 5 seconds with each subsequent retry, so it should have caught the first one well before the five expired. Are all your locks doing this?, or just one
If it matters, I'm a beta tester, and I believe I started experiencing an issue with the lock and repeated attempts about a week ago. I only noticed the issue because the lock makes a tone when it locks or unlocks. As an example, when the lock tried to lock via the webCoRE piston, I got locking tones every few seconds. However, the piston said there was only one attempt and it was successfully completed. I went to look at the lock, and it was indeed locked. When I went into look at the device and event logs, there were no 'odd' log entries for the lock.
While I was looking for log errors or warnings, I found that the thermostat was showing up to five failures - even though the expected temperature changes had already been made. According to my webCoRe logs, it had made the change on the first attempt. Before 7-10 days ago, there was no issue with the lock or the thermostat.
Edit:I thought it might be important to say that my webCoRE pistons for the lock and thermostat, were written using 'repeat until' logic to ensure that the commands are received and executed properly. The wait time for each loop for the lock is 15 seconds, while the loop wait time for the thermostat is a full 30 seconds. If I shorten those times, the pistons start notifying me that it's taking more than one try to complete the commands and do a confirmation check. By turning command retry off for the devices, I very rarely have issues with retries by the pistons.
OP here. For those of you keeping score at home, as punishment I decided to make some changes to see if it made any difference. In yesterday's experiment I changed all my blinds (16 of them) to LR and to disable Command Retry. Excluded them and re-added them. Fun. Here's the log from last night when the same Rule Machine rule was executed (close blinds at sunset):
For the record I made no changes to the rule that closes the blind. Maybe this makes sense to someone out there. Maybe not.
So it looks like you are seeing the same behavior w/o Command Retry. So we have eliminated 1 possibility. To see if this is simply the driver, i’d enable debug logging and open and close the blinds manually, no RM. Just 1 is fine no need to do this for 16 blinds.
Also what is the make and model of the blind and what driver are you using?
When adding the device, it defaulted the driver to a multilevel switch. I changed it to the Generic Z-Wave DT window covering. Seems logical, but probably a wrench in the works.
You see those parse entries? they are the driver responding to updates sent by the device. They seam to match the info entries in the log. In this case everything looks to be working as expected. I see no errors or indications of an issue.
Unless there are additional symptoms that have not been mentioned, i wouldn’t be concerned. the logs look fine and expected behavior. You are welcome to change driver to see if others are less verbose, but less verbose doesn’t necessarily make it better.
Thanks @sidjohn1
Ultimately the blinds work and that's all I really care about. The thing that sent me down this hole originally was (quoting my original manuscript):
"...the last status ended on "closing", but it had already been closed. I hit refresh in the device and it immediately updated to closed."
Does it matter? Not really, probably just an anomaly. But the boss saw the status was stuck on a dashboard. She wears the pants. Thinking my life can go on now. Thanks again appreciate the help.
Depending on what the driver supports, sending a refresh or config command a few seconds after movement has stoped should force the status to display the expected value consistently.
Should you choose to add this to your automations adding enough delay to ensure movement has stoped with some wiggle room will help ensure success or um WAF .
.
