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 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.
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.
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.
I understand that the “got CAN” error is a serious situation and that it might be one of the main reasons for the huge slowdown I see in my system.
It is becoming obvious that when I am adding more devices, or adding new scenes in the Reactor the situation is getting worse.
Reading the messages above I see that there is no solution, is this true? Is the solution to go to another platform and abandon Vera? I would have tried this if there is the Reactor on another platform, but since there isn’t, I keep insisting on the Vera.
My approach to minimizing Vera craziness has always been to remove unneeded plug-ins and otherwise offload as much of my controller’s daily activity as possible. For starters, the moment Multi-System Reactor (MSR) became available for beta testing, I hopped on board.
This one move allowed me to abandon: GCal3, SiteSensor, Reactor (ironically). It also permitted me to transfer every Scene over to MSR where things run infinitely faster and more reliably. More and more, users are relegating their Vera units to be “radio only” in the Z-Wave chain, asking less and less of her computational power, since (as the GOT-CAN problem illustrates) she has severe limitations when responding to multiple actions in a row.
In MSR, I reviewed all entries under “Entities” to discover any lurking “Hidden” devices, so I could go un-hide them and delete. I also used WinSCP to visit my Vera’s internal file storage and (CAREFULLY!) remove any remaining unused files (mostly plug-ins that I’d deleted years ago).
Lastly, make sure you’ve updated to the latest (7.31, 7.32 beta or, as of yesterday, 7.32 official) firmware, which all do an admirable job of eliminating former bloatware, such as the ERGY plug-in and related files. The new partitioning scheme they employ is superior to anything Vera shipped with, and seems to ward off unexpected reboots more than ever before.
Thanks for the great comments, and I will try to perform each of the steps you recommend.
The first was the Reactor update for 3.9, I found another post with a step-by-step explanation from you, and I already did it. Thank you very much so being extremely didactic. I have a lack of technical knowledge and need this kind of information.
Can you tell me about downloading or the URL of version 7.32? I can’t find the link to download it.
After that, I go to the MSR, I can’t live without the Reactor anymore, so its evolution is fundamental, and I will test the recommendation. It may be that there really are some ghosts to discover.
Take it easy my friend. No need for the wise cracks. If the team said they were on it, they’re on it. Thankfully that type of wise crack has disappeared from the forum for a good reason.
Best Home Automation shopping experience. Shop at Ezlo!