I have been keeping an eye on a behaviour that perplexes me greatly: I see Velbus’ VMBPIRC sensors producing false-positive motion triggers[1].
Very initially, before I even moved in, I had a bright idea of wiring the motion sensors into the alarm system. This was actually the first velbus configuration I deployed ^^ “More coverage, more security,” I thought, “can’t possibly hurt.” Until the alarms started triggering randomly in the middle of the night, that is. Specifically off the velbus PIRs, so I ended up undoing the setup of the idea quite swiftly.
More recently I would occasionally see the lights in a small 2m*2m wardrobe room adjacent to to my room turn on briefly at seemingly random times. I’ve seen it turn on, for instance while I was working at my computer or when I was trying to fall asleep. In either case I thought that maybe the sensor caught my leg or some other appendage in its line of sight. And it was rare enough to not bother me very much, so besides verifying that this was indeed the motion sensor firing off, I didn’t look into it much further.
Today I found that this very behaviour is happening in another small wardrobeish room. At the time this one was pretty much as airtight as a space shuttle, though, so no accidental movement to trigger the motion sensing. In today’s instance the behaviour was also quite a bit worse – instances of motion were getting detected for an entire hour straight! If nothing else, this gave me some time to experiment with:
setting up the 2nd motion channel to momentary mode, so I can see the triggers;
restarting the module(s);
upgrading the firmware;
fiddling with the motion sensitivity options;
measuring some voltages;
recording velbuslink for this post;
inhibiting the relay channel for the lights in that room;
checking if the floor heating zone for that room was active…
Nothing I did was changing the behaviour in any appreciable way, so my mind wandered to procrastinate a little and then suddenly the false-positives stopped seemingly as abruptly as they had started.
Here’s what it looked like in VBL while it was still happening:
Has anybody seen anything like this? Any thoughts on what this might be caused by?
(FWIW I ended up deciding to write here first rather than going straight for support@ primarily because this seems to affect multiple different PIRCs and I haven’t seen any discussion of this specific issue yet, so I thought it might be worthwhile to have a public description of this behaviour)
To the best of my awareness this is not happening with VMBPIRO or the one VMBPIRM I have. ↩︎
Status update: I’ve been progressively dialing back what OpenHAB integrations I have with Velbus to rule out any problems that may be caused by it’s chatter on the bus. The only things left right now are the passive channel listeners (i.e. I commented out all thermostats, date update mechanism etc.) Lets see how it goes…
EDIT: I definitely have seen the issue recurring, but also by my subjective estimation it is much rarer now?
I’m experiencing the same issue.
Not sure what’s causing this. First I thought it might have been the counter for the following action when triggered. But at some point I saw the signal hopping on and of in “test mode”.
This all happened after my painter taped the sensor.
I couldn’t get to the sensor so tried some restarts
Maybe, just maybe, it was because of the LED-strip is so close to the sensor that it saw the heat of the LED as movement?
For now, I changed the sensitivity to “medium” and it seems to work.
So, not really sure what happened and if it’s fixed or not…
You don’t know how glad I am to hear this problem is not unique to me!
In my case the sensors were installed after the paint job and as far as I am aware they’ve been in the box they’ve shipped in until the moment of installation. I’m hoping that I can rule out any concussion, especially as this behaviour only seems to have begun happening fairly recently (within the past month or two).
It is true that in the two rooms where I’m observing the problem, the sensor is relatively closer to the LED light fixtures compared to the other unaffected sensors. However these fixtures can be off for hours before these sensors decide to start triggering on and off. I doubt there’s any heat left in those things after such a long idle period for it to affect VMBPIRC.
That said your message did make me take another look at the ceiling and there’s one other thing I have in my ceilings that is relatively closer to the PIR sensors compared to other rooms. I have an air extraction diffuser/vent for the ventilation/recuperation system in proximity of the sensor in the two affected rooms.
Could the air motion around this vent trigger the IR motion sensor? Even if it is set at a low sensitivity? Despite the fact that I run a relatively low flow rate for my ventilation? An experiment for the future – block off those two vents specifically…
April is going to be the first anniversary of me living with the system, so it may very well be that this has something with the fact that it is an early spring now (can Velbus modules have allergies?) I don’t recall this being a problem throughout the Summer, Autumn or Winter. And my experiment with the security system was also during the early spring… hmm .
Anyway the issue is recurring after I removed OpenHAB from the equation. I just changed the addresses the modules are at just to rule out any potential interference with the other modules…
Same here.
But not exactly, they were already live and kept on working during the paintwork. (with tape arount).
The electronics were safe in the ceiling.
Same here.
Didn’t thought about it. Good point!
Not exactly the same.
My velbus is about live for 5 years now.
I never noticed the changes in airflow changing the trigger events of the specific sensor.
But as it was after/during the paintjob that this happened I was really confused.
It triggered movement even with tape over it. And after the tape, I had to change to medium sensitivity.
It looks like it works at the moment and will change it somewhere this week again to “High Sensitivity”.
What’s surprising to me is that things were perfectly fine for the entirety of April and for seemingly no reason whatsoever (even the weather outside is the same as it was yesterday) I’m again getting loads of false triggers today starting this morning.
I guess I’m off to support@velbus.eu now that I’ve ruled out everything I could think of.
The idea is to block off any real sources of motion for the sensor to detect – and it does, if I walk around and under the sensor, there are no detections any more – and any further motion detected by the sensor would then be a sensor hallucination.
And indeed, it still hallucinates motion.
Honestly I should’ve tried this from the beginning. It seems like such a simple test and it immediately removes a plethora of different possibilities as plausible causes of the problem…
I saw some dust resting on the inside of the sensor lens, so I disconnected the sensor & did some basic maintenance – largely just blew some compressed air into the enclosure and shaked the sensor a bunch to dislodge and remove pieces of dust and small chunks of gypsum that made their way inside the enclosure of the sensor.
Now the sensor is not hallucinating motion anymore. I don’t know, however, if its because it has been power cycled or due to my shaking it. Here’s to waiting another couple seasons to see if it starts misbehaving again.
The false-positives are back. Seems like it wasn’t the dust, but rather the power cycle that improved the situation, even if for a brief while. Unfortunately a soft-reset does not help, otherwise I would consider setting up an automation to reset the modules at 3 in the morning or something like that…
Support has suggested that I should run this experiment again, except with foil, rather than paper towels in order to block out the line of sight with high confidence.
Unfortunately, the hallucinations persist. While I’m not really looking for patterns anymore, the one in my wardrobe room is much more prone to these hallucinations than the one in the entry room during this experiment. The wardrobe one is also much more annoying in that the light it turns on is quite visible from where I sleep, so I think I may try swapping them if the support does not suggest any other troubleshooting steps.
I just wanted to say that this thread has just caught my eye.
I have not seen this before but I am very interested.
I do have a VMBIRC in my evaluation/spares box, but I DO NOT have any VMPIRC installed.
I DO have 10x VMBPIRM… the smallest VMBIR, mounted in ceilings around my house.
I do not know how similar the VMBPIRC and VMBPIRM are internally.
I do not currently make major use of them (just turning on lights at stairwells) but I have not noticed any spurious activations. They have been active/running for about 1 year now and seem very reliable so far.
I have plans to make more use of them with custom expansions as “occupied” sensors… eg. only enabling hot-water secondary-return when there are clear signs that the building is occupied).
So if there are problems with this I am very keen to know in advance.
If I can help with any diagnosis please let me know.
Thanks for writing here If nothing else this reminds me I need to ping the velbus support again since my last update seems to have failed to reopen the ticket on their side that was temporarily closed.
The one VMBPIRM I have installed has been serving me perfectly. Though the conditions in which it is installed are also quite different, so it is difficult to make a fair comparison between it and VMBPIRC (some of the other VMBPIRCs I have seem very reliable as well, as are the VMBPIROs I have.)
I have plans to make more use of them with custom expansions as “occupied” sensors… eg. only enabling hot-water secondary-return when there are clear signs that the building is occupied).
So if there are problems with this I am very keen to know in advance.
This seems like a nice idea. Most importantly, the risk factors are nil: even if you end up with a spurious activation of a sensor or two, the worst that happens is that your secondary return pump runs for some time and then stops to save power again. Not a huge deal if it happens, right?
.
