+- Comfort Automation/ Security System Forums (https://www.comfortforums.com)
+-- Forum: Support (https://www.comfortforums.com/forum-2.html)
+--- Forum: Problems & Troubleshooting (https://www.comfortforums.com/forum-36.html)
+---- Forum: Troubles (https://www.comfortforums.com/forum-77.html)
+---- Thread: RS485 communication problem with Slave 3 (/thread-3313.html)
Pages:
1
2
- agenor - 03-13-2013
Greeting,
we are having a RS485 communication problem.
Our system consists of a main board and three slaves (SEM2). The RS485
communication code error is 35, i.e. the main board and the slave 3 board are
not communicating. The other two slave boards are communicating with
the main board correctly. In the Comfigurator SW file the number of
slaves is set correctly.
Firmware versions:
Main board: 6.0.28
Slaves: 6.007
We also have a door station unit installed (1.004), and two keypads
(KP06 - 6.003, KT03 - 2.007).
What could be the problem?
- ident - 03-14-2013
Can you exchange the ID of the SEMs so that the one witj ID=3 is channge to ID=1 and vice versa
Is the comms failure seen by the same SEM or the one with ID=3?
Check tthat the ID shunts have good contact with the headers. Iif the contact is loose then the ID is not set correctly
- agenor - 03-14-2013
We have solved the problem.
We also had a third party GSM unit installed in our system. The SIM card in
the GSM unit was not inserted. After inserting the SIM card, the communication
problem with the slave 3 board was fixed and since has not occurred again.
It seems that the GSM unit was causing interference.
Thank you for your help.
- ident - 03-14-2013
How strange. How close was the GSM to the SEM3?
- agenor - 03-14-2013
Around 50 centimeters.
- Home - 03-16-2013
Have you grounded the SEM\'s? or rather commoned up the 0V !
- agenor - 03-16-2013
The SEMs were not grounded and the 0V-s were not commoned up.
The only reason why we had to use a GSM unit from a different manufacturer was because with the UCM-GSM unit installed the system, for certain events, did not dial out to the central monitoring station (CMS). When we were testing the dial out-s, after a few events, we called the CMS company and they told us they had not received a call from the premise for some events. For example, the CMS received a call for the SECURITY OFF event, but not for a AWAY MODE event and likewise. At the time, we had upgraded the firmware versions to the newest ones. All HW and SW settings were set correctly. Then, we removed the UCM-GSM unit from our system, and the dial out-s to the CMS worked just fine (via landline). We then installed a different GSM unit that was used only for turning the heating/cooling system on and off via SMS, which was the initial request of the home owner.
A couple days ago we switched back to the UCM-GSM unit because the home owner requested a backup dial out system in the case of a telephone line cut event. The old GSM unit was still in the system, we just removed the SIM card and put it in the UCM-GSM unit. Then then communication problem with the SEM3 started. After putting the SIM card back into the old GSM unit, the communication problem went away.
We now have removed the old GSM unit completely from our system and are now
using the UCM-GSM unit. We upgraded the firmware versions of the controller and UCM-GSM unit and tested the dial out-s to the CMS. The dial out-s (via landline and GSM) work fine now.
- slychiu - 03-17-2013
Dialing out to a CMS via GSM may not always work
This is because the GSM network alters the durations of the tones due to network delays. CMS receivers have a tight tolerance on the durations of tones and silences
Comfort tries 5 times to the CMS if the call is not successful
The problem may happen during more busy times of the day for GSM traffic
Using GSM as a backup dialer is OK, but not as the main dialer when there is CMS
- agenor - 03-17-2013
Here in Croatia we never experienced the problems you describe with any of the GSM diallers (been using DSC, Bentel, Sintel and Inim through a period of 10 years). Mostly all CMS in Croatia are SurGard System II or System III. The format is mainly ContactID.
Also, it doesn\'t seem like this (what you describe) is the problem with your unit, either - because some events (like arming to away mode) *never* get reported while most of them *always* get properly reported. If it were something like you describe, then we\'d have a stochastic distribution - any event would sometimes go unreported, isn\'t it?
- ident - 03-17-2013
There should be no differenrce between away mode or other alarms in terms of CMS reporting. There should be another reason for it
Is your System Armed Alarm Type set for reporting to CMS?
If so and it still does not can you send the cclx file to support@cytech.biz