I have several reed contacts to check whether a window is open or closed connected to an Arduino Mega. To do this, I use the Arduino internal pull-up on an input pin (e.g. pinMode(RS_BATHROOM, INPUT_PULLUP)) and connects the reed sensor on the window that is connected to the GND (all connected using a CAT5 cable). When the window is closed, the input reads LOW; when it is opened, the input reads HIGH as expected.
Every change of the state of the pin is written to a syslog server.
Now here is the problem: I noticed that it regularly happens that the pin goes HIGH and LOW for a moment without the window moving.
2017-02-17 09:00:16 Window bathroom closed
2017-02-17 09:00:16 Window bathroom open
What can cause this? The reed sensor? The CAT5? Any suggestion to avoid this?
How long is the cable between the switch and the Arduino?
If you post your code (using code tags please) we might be able to spot a bug that causes the issue.
A workaround could be to set a minimum time the state must be changed for before the notification is sent. You may already be using some debouncing code for the switch that could provide this. Of course it's better to find the actual cause of the issue.
The cable is about 12 meter long.
I already thought about the workaround that you suggest. If it is a cable issue, that might be the best solution to go because replacing the cable is the last thing I want to do.
The principle of the code is really basic. I cannot paste the complete code here because it is quite big and a lot of stuff is happening in there. Furthermore, I use a lot of reed-sensors in the same way and not all of them show this behavior, only those that are physically far from the controller.
So unless you really think that this might be a coding issue I will not put code here this time. But if you want to have a look at it I'll be happy to share it with you.
So do you think it might be a lengthy cable issue?
For a long cable use a stiffer pullup, 4k7, 2k2, that sort of value.
Note that the internal pullups on the chip are very very weak (20k--50k) and not good enough for
off-board signals, they are meant for signals on the same PCB.
Long cables act as an antenna and pick up significant noise, its a fact of life.
Every change of the state of the pin is written to a syslog server.
You'll need to debounce or filter both edges of the signal, not just when the switch is opened. Here's what I would suggest for a hardware filter with about 22ms time constant:
A 20ms time constant is for debouncing a human operated switch, we are talking suppressing EMI
spikes on the cable.
Try 2k2 pull up, 10nF in the first instance.
A 20ms time constant may lead to multiple transistions when the window switch is operated due
to the slowly varying voltage and lack of decent schmitt-trigger following the LPF.
Logic devices expect rapidly swinging voltages, and can misbehave if the input lingers inbetween
defined states of LOW and HIGH.
A 20ms time constant may lead to multiple transistions when the window switch is operated due
to the slowly varying voltage and lack of decent schmitt-trigger following the LPF.
the operate/release time of a reed switch would be 0.5-2ms
a series connected 10K with 2.2µF ceramic cap near the pin should block any spikes/noise/interference
the existing input would already have about 500mV hysteresis, so a slow and smoothed rise/fall time of the signal would not be an issue
deejay808:
I have several reed contacts to check whether a window is open or closed connected to an Arduino Mega. To do this, I use the Arduino internal pull-up on an input pin (e.g. pinMode(RS_BATHROOM, INPUT_PULLUP)) and connects the reed sensor on the window that is connected to the GND (all connected using a CAT5 cable). When the window is closed, the input reads LOW; when it is opened, the input reads HIGH as expected.
Every change of the state of the pin is written to a syslog server.
Now here is the problem: I noticed that it regularly happens that the pin goes HIGH and LOW for a moment without the window moving.
2017-02-17 09:00:16 Window bathroom closed
2017-02-17 09:00:16 Window bathroom open
What can cause this? The reed sensor? The CAT5? Any suggestion to avoid this?
Thanks!
If it does "regularly happens" as you wrote, that should be a clue. What happens there on a regular basis? Wind, temperature change humidity change, what? The problem may be the magnet is weak or too far from the switch. Or the magnet may not be place parallel to the axis of the switch.
deejay808:
The cable is about 12 meter long.
I already thought about the workaround that you suggest. If it is a cable issue, that might be the best solution to go because replacing the cable is the last thing I want to do.
The principle of the code is really basic. I cannot paste the complete code here because it is quite big and a lot of stuff is happening in there. Furthermore, I use a lot of reed-sensors in the same way and not all of them show this behavior, only those that are physically far from the controller.
So unless you really think that this might be a coding issue I will not put code here this time. But if you want to have a look at it I'll be happy to share it with you.
So do you think it might be a lengthy cable issue?
What else do those cables have in common? Are the "bad" runs near mains wires and the "good" runs not? Are the cables UTP, STP, coax, or parallel?
The first step to fixing pain-in-the-ass problems like this is to be as thorough and methodical as humanly possible in collecting and organizing the information that you do have and looking for correlations. If you don't do that and just stab around in the dark based on hunches or guesses you will waste tons of time.
For all of your reed switch cable runs (good and bad), tabulate the following information:
Length of the run
Potential noise sources near the path, such as mains wiring or radio transmitters (like a Wifi router).
Fault frequency, such as phantom transistion per day or even just a rough classification like Never/Rarely/Occasionally/Frequently.
Cable type (if they are different)
Anything else that you can think of related to the cables, whether or not you think it will make a difference at this point. Too much info is better than too little right now, and you never know what might be relevant.
if you are able to be notified of these phantom events as they happen, see if you can notice if certain events are happening concurrently, like the HVAC or refrigerator turning on.
Hi,
The pair of wires that you are using in the cat5 for the switch are a twisted pair?
That is, ORANGE AND ORANGE/WHITE.
Not ORANGE AND BLUE for example.
Paul_KD7HB:
If it does "regularly happens" as you wrote, that should be a clue. What happens there on a regular basis? Wind, temperature change humidity change, what? The problem may be the magnet is weak or too far from the switch. Or the magnet may not be place parallel to the axis of the switch.
Paul
Well, let me give you some additional background on the system. These sensors are an extension of my domotics system (Loxone). The arduino and the loxone system communicate using UDP messages over my local network. Whether that is a good choice may be another discussion. Anyway, it works already for about 3 years. Since the last update of the loxone system, I've seen 'open windows' that are in fact closed pop up almost every day; just 1 or two of them.
What actually happens is, when a read sensor opens, a message is send to the loxone. When it closes, another message is send. I have the impression that the handling of the messages has been changed such that 2 consequent messages in a short time might not be 'seen'. Just a guess ... because that is the only thing that changed in the whole system. Routers and switches have been reset
Of course, the 'sparks' in the circuit from the reed sensors to the arduino were there before. It is only now that they have become a problem.
If the sensors or their placement would be bad, I think I should see a lot more high/low events in my log. So I am quite sure that that is not the problem.
Jiggy-Ninja:
What else do those cables have in common? Are the "bad" runs near mains wires and the "good" runs not? Are the cables UTP, STP, coax, or parallel?
The first step to fixing pain-in-the-ass problems like this is to be as thorough and methodical as humanly possible in collecting and organizing the information that you do have and looking for correlations. If you don't do that and just stab around in the dark based on hunches or guesses you will waste tons of time.
For all of your reed switch cable runs (good and bad), tabulate the following information:
Length of the run
Potential noise sources near the path, such as mains wiring or radio transmitters (like a Wifi router).
Fault frequency, such as phantom transistion per day or even just a rough classification like Never/Rarely/Occasionally/Frequently.
Cable type (if they are different)
Anything else that you can think of related to the cables, whether or not you think it will make a difference at this point. Too much info is better than too little right now, and you never know what might be relevant.
if you are able to be notified of these phantom events as they happen, see if you can notice if certain events are happening concurrently, like the HVAC or refrigerator turning on.
All cables are UTP CAT5E. The bad runs are those with the longest cable and some of them run next to main wires (220V AC) and audio cables (amplified). However, they all run in their own tube but the tubes lay next to / over each other. Everything collects at a central point: mains / audio / utp so there can be a lot of interference. Additionally, the internet cable is also arriving at that point. A wireless AC router is also in place. In fact, I have 4 wireless routers in my house ...
So, all the considerations you have listed apply and may interfere. The only change I can do is moving the wireless router away, but the wifi is everywhere so I don't know whether that makes sense.
So in this case, my first try for a solution will be the hardware filter as it is proposed earlier to avoid the sparks. If that doesn't work, my next try will be to suppress the sparks in the code of the Arduino.
TomGeorge:
Hi,
The pair of wires that you are using in the cat5 for the switch are a twisted pair?
That is, ORANGE AND ORANGE/WHITE.
Not ORANGE AND BLUE for example.
Thanks.. Tom...
This might be a good idea to check out ... although it will require re-soldering the sensors in the windows ... something for summer ....
With the long cable run and wireless RF interference, mains AC interference, etc, it would be good to protect the Arduino's power rails as well as the input pin. I suggest using an opto isolator.
To make things simple, I'm quite sure you could use just the Arduino's supply (which defeats power-rail isolation), but the IRLED current limiting resistor helps protect the GND rail and the IRLED itself protects the 5V rail. The input is isolated and would not see any interference or any issues due to voltage drop through the long cable run. Therefore, no filtering is needed.
