I noticed that after I applied the latest hotfix to 1.1.5.115 that I am no longer getting any motion detection on Aeotec multisensors. They had been working fine up until the latest point fix (1.1.5.xx was fine). I can pick one up and the acceleration is being detected, so it looks like just the motion is broken.
Any thoughts/or has anyone else experienced a similar issue and have found a fix/workaround?
I have 12 of the Aeon Multisensor6 devices and I just tested them all... I found 2 needed new batteries, but other than those two, they all worked for Motion.
OK, I changed the batteries in the two.. they work fine now also.. all 12 are working with the latest 1.1.5.115 image.
Hmm strange. I have a couple that both are exhibiting the same behavior (they're USB-hardwired, so power isn't an issue). If I watch the logs, no motion is being logged, but the acceleration is when I move one. I noticed it this morning (I had upgraded last night) when my lights didn't turn on.
I'll poke around a bit more.
As far as I know all the miriad of drivers handle motion. Most of their differences are in the "options" area. I happen to be using the Aeotec Multisensor 6 driver I found and "improved."
I "improved it" by renaming it to be distinguishable from all the other "aeon multisensor 6" drivers out there AND by adding Cobra's version checking method.
@csteele Thanks for the reply. I believe I pinpointed the issue to what may be zwave switch flakiness vs. lack of motion detection. The motion wasn't triggering in the log because it was constantly in an active state, so believe that explains why I wasn't getting a logged action for motion when I expected it, and the lights were not triggering due to what I believe was a zwave/or switch related issue. I also could not control the switch by sending a manual on/off from the device control on the hub. I bounced both the circuit the switch was on, as well as the hub and it's working properly now. I recall having a similar issue with the same model (Leviton ds15z) of switch on STs about a year ago where the hub was sending on/off commands but the switch seemed wedged in a state where it ignored everything but appeared to be reachable/working to the hub.
I've enabled debug logging on it and will watch it for the next few hours/days to see if the issue crops up again.
Hubitat's ZWave Repair is a bit incomplete at this moment. It may not finish, may stall. However, if you have only a few devices, a Repair might be a good thing for you. Actually, other than it takes about a minute per device, you've got nothing to lose.
It's one of the problems we face as we migrate from a working Home Automation system to Hubitat (or any other) in that we "break" the paths distant devices had back to the hub.
Imagine you have only a few devices... Hub, and node 2, 3 and 5. All can talk directly to the Hub. Migrate any and both mesh networks are just fine. But then imagine device node 6... it talks to node 3 to get back to the hub. If you migrate node 3, node 6 has no path back and it can take a really long time for "self heal" to kick in, if ever. Remember, it's the HUB that manages routing. Devices get a Hub invented routing table, exclusively for them. if the hub doesn't notice, a replacement route table never gets sent
@csteele Yeah, good point. I have been migrating things over for the last few weeks and this is mostly likely the factor here. I thought I had been migrating on a path with adjoining devices pretty close to each other, however I could see how building interference may be playing a part in this particular scenario.
I'll kick off a repair and should really move faster on migrating off of ST 
Download the Hubitat app
