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”.
.