Fibaro Universal Binary Sensor

Other Devices & Integrations Door Locks & Sensors
#1

Hi, has anybody managed to get binary inputs configured? I’ve tried to get my CO-detector to “trip” binary input, but I really don’t know what settings should be changed in vera lite to get proper information from detector.

I assume only way to get any info from binary inputs is to use triggers to do something? Am I right? There are plenty parameters listed in manual, but manual doesn’t tell where or how to change or activate those parameters. Can somebody help me out?

So, binary sensor is allways tripped, when I connect Line1 to GND it set’s “tripped 0”. How to I tell that damn thing that it is not tripped normally, when I connect Line1 to GND, then it shoud be tripped and execute a scene?

#2

You can configure if the two inputs should be NC(Normally closed) or NO(Normally open). It can be a bit hard to set the acutal configuration. You have to “wake up” the universal sensor by triggering inputs or pressing the button on the chip.

#3

Yes I know that I can configure many things, but how do I do it? For example Cut&Paste from manual:

Parameter no. 3
Type of input no. 1:
Default value: 1 ? INPUT_NC (Normal Close) Possible parameter
settings:
0 ? INPUT_NO (Normal Open)
1 ? INPUT_NC (Normal Close)
2 ? INPUT_MONOSTABLE
3 ? INPUT_BISTABLE

How to tell Vera Lite that I want to monitor line1 when “normal open” state changes? And how to I tell Vera that device is not tripped normally and it is tripped when line1 closes? ???

#4

Go into “Device options” tab of your universal sensor.
Click “Add configuration”. Set parameter 3 to 0 (1 byte). Save and reload.

If you still have problem go to “Settings” tab of the device and and click “Configure node right now” while trying to wake your device up (Click small button on device).

#5

Hi harkonen,

I’m also installing the fibaro Universal Binary Sensor, and experienced the same issue on Input 2. besides that I experienced another issue; one my input 1 once tripped it never reverted back to “not tripped”. In the end I decided to reset the fibaro, exclude it from vera and include it again.

After this the issue you had was solved (it’s tripped when closed), but still experiencing issues on input 1 (it won’t detect anything) and also my variables on the advanced tab are different for both motion sensor’s (?).

#6

I have am issue with my fibaro binary input sensor.
It is linked to my house alarm so that if the alarm is activated it triggers the sensor which in turn commands vera.
As you may be aware, the vera system does a refresh or summat at around 2am in the morning when it briefly goes offline.
This “refresh” is giving me a false trigger of the fibaro sensor input.
Is there a fix for this, anyone know?

thansk

#7

Sorted now. In case its of any use to anyone in the future the unit comes set with both inputs as N.C. by default.
I had to reconfigure, as shown, to make the inputs both N.O. which resolved the false triggering update every 2am

#8

@UKSub - I guess you only have trigger when the sensor is “untripped”. Don’t you get false triggers on the other state now. I am getting false triggers no matter what parameter 3-4 is set to. It triggers the same trigger severel times in a row, how can it trigger “tripped” if it never triggers “untripped” in between.

I am also using the sensor as an indicator of the state of my home alarm.

I realize I can do a workaround and using scenes and have the triggers change another “virtual” switch, hence false triggers of the current state is not a problem, but should that really be necessary?

Has anyone solved this “false trigger” problem with Fibaro Universal Sensor?

#9

i think its a case of every 24 hours the unit does some kind of “refresh” and updates the state of inputs. If the input was OFF (ie not triggered) then there is no change or the system update remains null. If the input was in a triggered state it seemed that upon refreshing this state was renewed, giving the false trigger. I guess the NC contacts are good if you are watching say a closed door/where the contact will be held in an open state until opened then triggered. As i only wanted trigger upon “alarm” conditions i reconfigured. There might be a workaround but for now i am happy.

I did wonder if my system was getting interference as it was connected to another wireless system or perhaps the supply voltage was not consistent. Perhaps you could check this too. Maybe set up a counter or log to watch the state of the sensor and see if its triggering is related to some other event.
Being a newbie to most of this i can tell you it was a headache to figure out.

#10

Well, us two newbies think exactly the same. ;D . I was also suspecting interference from the alarm system’s GSM-transmitter or inconsistent voltage. I do have logged the behaviour, in my previous post you can see the log of false triggers and they just start coming any time of the day.

Now I am starting to suspect bad HW or FW. I want to trigger on both “tripped” AND “not tripped” so I really want to get rid of all false triggers that come in one direction.

I will also try an exclude and reset and then include again. But that doesn’t feel right… Why should it not work from the beginning?

#11

What is it with Vera and security sensors? It seems they all give false triggers. I am beginning to suspect that the problem may be in Vera’s implementation rather than the hardware…

I have just discovered that I have the same issue reported by @UKsub and @filifjonkan: One of the channels on my Fibaro Universal Binary Sensor gets re-triggered without being un-tripped. This channel reflects the Armed state of my house alarm system and is used to trigger scenes to set an Away/Home virtual switch - except when the alarm is armed at bedtime. When it falsely triggers in the middle of the night, it sets Away and causes all sorts of havoc! :o

After perusal of the log I discovered an interesting thing: The state of the sensor does not change but Vera rewrites the Tripped variable (…was: 1, now: 1…) which triggers the scene. It does this just after it has polled the sensor! >:(

I have a work-around. I add a variable to the device to indicate the last-known state so I know to ignore the false re-triggers. This variable is set by Lua in the two scenes that set and clear the Away virtual switch.

This scene is triggered by the sensor being tripped and sets Away. This is the Lua for the trigger:

local dID = 122 local state = luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1","LastState",dID) if (state ~= nil) and (state == "1") then luup.log("Alarm: Repeated Arm - Away not set.") return false else luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","LastState","1",dID) end local dtT = os.date("*t") if (dtT.hour >= 22) or (dtT.hour <= 3) then luup.log("Alarm: Armed - Away not set.") return false else luup.log("Alarm: Armed - Away set.") return true end

This scene is triggered by the sensor being un-tripped and clears Away. This is the Lua for the trigger:

local dID = 122 luup.variable_set("urn:micasaverde-com:serviceId:SecuritySensor1","LastState","0",dID) luup.log("Alarm: Disarmed.") return true

It solves my problem - at least until I figure-out another way to stop it happening. I suppose one option is to stop Vera polling it at all…

Turn on fountain if wind speed below 1MPH for more than ten minutes
#12

I have a problem with the sensor. I can not change the logical state of input.

I have a 2 wire door sensor, one is normal open and one is normal close

I have read the post carefully but don’t have a field for cange a state.

Thank

#13

I hope you’ve managed to conquer this given how old the post is! If not, configure the device options for both the child devices in the device options for the parent device (in your case _Motion Sensor).

#14

Rex,
Interested to know if you ever found a better solution to the false trigger problem experienced with the Universal binary sensor? I have the same issue with my alarm interface which is driving my family (and me!) insane ::slight_smile:

Once false triggered, I find that they only return to correct operation if they are cycled through a valid input state change.
Thanks,
Andrew

#15

I’m also having trouble using one of these in the same situation. I’m even getting false triggers when the Fibaro inputs are completely disconnected…

[url=http://forum.micasaverde.com/index.php/topic,38050.0.html]http://forum.micasaverde.com/index.php/topic,38050.0.html[/url]

#16

Yes, this problem is really frustrating. I use a lot of these devices in my system. I have 5 located in my alarm control panel to monitor PIR activity around the house for intelligent lighting control and also watch for alarm activation. Another device signals to Vera when the alarm is armed. All of these inputs are controlled by an open collector transistor - the transistor pulls the input low when active. Occasionally, perhaps once every two days, I see false triggers on the alarm activation. This triggers the shut down of lighting and various sockets around the house…not good when you’re actually IN and watching the TV :slight_smile:
I have some other sensors which use relays instead of transistors to pull the inputs to ground to monitor for power failure on mains circuits. These too suffer occasional false triggers. I’ve tried to look for all possible h/w reasons for the false triggers…noise spikes, correct input levels etc, but found nothing that would indicate a problem. It looks like a ‘soft’ problem to me. It’s a pity because apart from this, the system is reasonably robust. But with this element being so mission critical, it really destroys the value and experience of the system. One a false trigger occurs, I have to cycle the sensor through a ‘true’ level change and back to clear the triggered state. It’s behaving as if it is edge triggered and not looking at the actual state of the input.

#17

so the next question is: is this a fibaro sensor issue or a Vera issue…

#18

That is the big question!..I’d put money on it being a Vera issue. This sensor seems to have been a real problem for them. When I first installed my system (over a year ago), the sensor seemed to work ok. Then, after a Vera update, the sensor inputs stopped working (temperature polling continued fine). We had to wait about 8 months for Vera to release firmware (3 revision later) to fix this issue…or maybe only partially judging by the problems people still seem to be having!

#19

I’m amazed how old this topic is and that even now, I’m also still seeing this happen.

Binary sensor is connected to an IR Beam unit - the type you often see in shop-doors. It works without fault when I wave my hand across it. It comes up as triggered and then resets. No problem.

However, at random times it will just go off. First I blamed the IR beam thinking it’s that but hooking up a physical light to the same relay shows it DOESN’T go when the Fibaro Binary sensor gets a trigger.

I also noticed the state just stays on in Vera (little red running man). This is absolutely bizarre. It’s as if it consistently misses the “off” packet getting sent through the air. This is assuming it is actually getting triggered. I can’t see it being interference as surely this packets are digital so getting random “hey, the sensor just triggered” packets flying through the air can’t seem possible either.

Just utterly strange and crazy that this has been going on for 4 years without a solid solution. Especially seeing it’s not like there’s 20 different binary sensor devices that need to work with Vera.