Home Automation Domotica Forum Europe, Bwired Forum

Hi all,

I've recently installed a Visonic MCT100 with two magnetic door contacts (one for a door and one for the mailbox). I'm using an RFXCOM Visonic receiver and the RFXCOM Homeseer plugin to see the status of these devices in Homeseer.

The mailbox sensor works well. The door sensor, however, gives communication failures, according to Homeseer, after some time of inactivity. As both devices use the same transmitter, it doesn't seem to be a communication problem.

Looking at the manual of the MCT100, I see that the MCT100 only transmits alive packets for one of the two contacts (i.e. using only one of the two device addresses). In my case using the mailbox contact address and not the door contact address. This would explain the communication failure due to the lack of alive packets for this contact.

My question: is there any way I can prevent the communication failure in Homeseer? And why doesn't the auxiliary contact on a Visonic MCT302 suffer from the same problem (it seems to be basically the same thing, just in another box and using a reed contact)?

I've read something in the RFXCOM Visonic receiver manual (section 8.3: Alive from auxilary contact) which I guess is related to this issue, but I don't think that I totally understand it and/or how it relates to the MCT100.

Any ideas?

Thanks!

Lennart

Lennart,

The heart-beat for the auxiliary contact is created by the receiver. When the receiver has received an auxiliary contact (contact switch or tamper) the address of that contact is stored in EEPROM. The receiver will then simulate a heart-beat for the aux contact when the primiary contact transmits the heart-beat.

The receiver will send the heart-beat if you can set the switches in the MCT100 to a position that the packets have the same contents as the MCT302. Check this with RFreceiver in Visonic mode.

Another option is to use an event and update the last change date/time of the aux contact when the primairy contact is updated. I hope there is an event trigger for this. Or run every 15min an event that updates the last change date/time for this aux contact. The comm failure will be detected on the primairy contact so it is valid to do it this way.

Bert

Hi Bert,

Thanks! Now I understand how to interpret section 8.3 of the RFXCOM manual . I will look into the exact contents of the MCT100 and MCT302 aux contact packets in RFreceiver to see if and how they differ. It would be nice if it could be solved on the level of the receivers EEPROM by setting the MCT100 dip switches in such a way that it behaves the same as the MCT302. I'll look into this. And otherwise, I'll try to fix it within Homeseer, using one of your suggestions.

Just to prevent reinventing the wheel: did anybody else already try this and solve it in some way?

Lennart

Hi Bert,

To follow-up on this topic: here are the packets of 4 magnetic contacts. The first two are from an MCT302, both primary and secondary contacts. The second two are from the MCT100, again both primary and secondary contacts. The switches are in the same position for both devices.

MCT302:

A44A26614C50 PowerCode Addr:4A2661 No Tamper,Alert,Battery-OK ,Event,Restore reported ,Primary contact

A4CA26614890 PowerCode Addr:CA2661 No Tamper,Alert,Battery-OK ,Event,Restore reported ,Second. contact


MCT 100:

A40392964CF0 PowerCode Addr:039296 No Tamper,Alert,Battery-OK ,Event,Restore reported ,Primary contact

A48392964830 PowerCode Addr:839296 No Tamper,Alert,Battery-OK ,Event,Restore reported ,Second. contact


Looking at the packets, the receiver is correctly identifying the MCT100 secondary contact. Shouldn't the receiver store the secondary contact address of the MCT100 in EEPROM and generate heartbeat packets for it then?

Could it maybe be that EEPROM memory is full due to other devices (neighbors?) being stored in there? The receiver has been running for some time without sending an F042 command to clear the aux contacts. Just to be sure, I just cleared the contacts and generated alerts from both auxiliary contacts to freshly store them in EEPROM memory; let's see if that works...

Lennart

Hi Bert,

Hmmm, this is getting more and more interesting...

First, clearing the EEPROM memory by issuing an F042 command (using the Clear Visonic Aux contacts button in RFreceiver), gives the following:

Init cmd to receiver => F042
53 ACK
8B Buffer flushed due to timeout

Is the timeout normal behavior?

Furthermore, after clearing the EEPROM I now get a communication failure for *both* aux contacts (i.e. both the MCT100 and the MCT302). So clearing seems to have worked, but the receiver doesn't seem to be re-learning the aux contacts. An Alert followed by a Normal packet from an aux contact should be enought, right?

Any ideas?

Thanks,

Lennart

Lennart,

any command from the aux contact will save that address in the receivers EEPROM.

For an aux contact that can't be switched you can open the sensor to force a tamper which will xmit a primairy and an aux packet.

Bert

Hi Bert,

After the communication failures, I gave the LAN receiver a power cycle, retried clearing the contacts & generated Alert packets. Both aux contacts are now behaving normally, so it seems the problem is gone. Thanks for clearing up how aux contacts are being handled in the receiver! Just being curious: the timeout message I had before, was that normal?

Lennart

The older versions of the receiver don't respond with an Acknowledge.
This is changed in the new receiver versions.