Got CAN? How to fix this?

In my on going quest to improve the performance of my Vera, I’ve now arrived at this long standing issue…

Whenever Vera controls any of my Aeotec Z-Wave switches, dimmers or plugs (I have a lot of them, both new and old), I usually see this “got CAN” error in the log:

01 05/31/19 10:03:49.482 got CAN <0x7631e520>
02 05/31/19 10:03:49.482 ZWaveSerial::Send m_iFrameID 264 got a CAN – Dongle is in a bad state. Wait 1 second before continuing to let it try to recover.

No idea what it means but it’s never looked good to me. It never really waits 1 second before retrying either (despite what the the error message says). The switches respond instantly.

The only way I know of suppressing the error is by setting parameter 80 to 0. Param 80 is common on nearly all Aeotec switches for controlling instant status notifications. It has the following settings:

80-Notification Sent to associated devices on Group 1 (0=nothing 1=hail CC 2=basic CC report)

The problem with making this change though, is that if the switch is ever operated manually, Vera’s status doesn’t get updated. Only setting 80 to 1 or 2 resolves this but then, of course, I’m back to the got CAN problem.

I’d really love it if anyone has a solution for this or has any more info on the real implications of this error.


Actually, on closer inspection, I get this error in the log for pretty much any device, not just the Aeotec ones. It seems to have some notable impact to performance when I’m controlling multiple devices at once - like, in a scene. I get a flurry of these errors in the log.

I should point out also that I’ve had numerous Vera’s over the years and I’ve seen this on all of them.

I am indeed seeing this in my logs as well. Thanks for bringing this up. I am not sure what the root cause of it is yet at this point.

Edit: Indeed found out that I am able to trigger this error whenever I am turning on a dimmable light device to 100%. In my case, my HVAC vents.

Still looking and can’t find a way to access what zwave commands. Not sure if @Sorin can ask the devs.

Thanks for checking, @rafale77.

I decided to open another ticket on it last week and for the first time (and to my surprise), the issue has finally been acknowledged. I was told that my “fix” (to disable instant device status notifications) was the only known solution at this time and that it has now been reported to the development team (with no ETA for a fix though).

I really hope this gets addressed once and for all in the next firmware update.

So, in case anyone is interested, I’ve now pretty much given up on chasing a real fix for this.

Sorin was kind enough to pass a trace I made of the error onto the devs for analysis but sadly, it’s unlikely to ever get resolved due to the fact that this kind of condition is basically “handled by the z-wave chip itself”.

As far as what this error actually means: A CAN frame indicates that the receiving end discarded an otherwise valid Data frame and it’s used to resolve race conditions where both ends send a Data frame and both expect an ACK from the other end. Apparently, if a Z-Wave chip expects to receive an ACK frame but receives a Data frame from the host, the Z-Wave chip SHOULD return a CAN frame.

This might be valid but the fact of the matter is, the behaviour introduces some serious performance implications as the host must wait for a period before re-transmitting the Data frame - creating unnecessary delays and additional network traffic.

The good news is, after disabling instant status notifications on most of my devices, it has virtually eliminated the error now, and it has vastly improved the performance of my entire system as well. I can now switch many, many devices at once (in a scene) without any significant delay - something I was never able to do previously.

The bad news is, it these devices are ever operated manually, I need to resort to polling to get status updates reported back to Vera, but I don’t have many cases where this is all that necessary.

1 Like

Thanks for sharing this. I might need to go look for devices to disable instant status on.

I am however doubting that nothing can be done about it because other controllers don’t appear to have this problem with zwave. The vera apparently paused itself for 0.1s when it gets a CAN. This might not be needed. I am looking for how other platforms are doing this.

Very old but interesting read related to this topic as I am trying to figure out how to eliminate this. It’s definitely not all that common as I am not seeing this on other zwave controllers I tested. It seems very unique to Vera to me.

Any luck? Does the 7.30 beta handle this better or not?

No unfortunately it is one of the 2-3 leftover bugs which will not have been fixed in 7.0.30 though I still standby the fact that it is a major leap forward in stability. The latency/tardiness/got CAN are all connected and have not been addressed.

© 2019 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy