Comfort Automation/ Security System Forums > Support > Problems & Troubleshooting > Troubles > scs and keypad comms failures |
Comfort Automation/ Security System Forums > Support > Problems & Troubleshooting > Troubles > scs and keypad comms failures |
| Moderated by: slychiu | ||
| Author | Post | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
wexfordman UCM Pi Users
|
Hi, The last few days I have had a few instances of coms failure alarms on my comfort system. I have 2 keypads, 4 scs's a ucm etch and a ucm velbus. I have completed no work or upgrades on comfort over the last few months, so nothing has been done to introduce this as far as I can tell. It started as a keypad failure, and another time as an scs failure, and this evening everything started failing. I also dont seem to be able to log in via ethernet either, although my velbus is working fine via comfort. Any help in a bit of troubleshooting would be much appreciated. Regards,Eamon |
|||||||||
|
wexfordman UCM Pi Users
|
ok, looking a bit bizzare now. I started to disconnect all my scs switches to see if one was causing he problem, and started to notice a pattern. It seems I get comms failure when a specific velbus relay is activated!! I have one channel on a vmb4ry for turinin on the central heating, an without fail, whenever I turn it on, the comms failures come on, and clear when i turn it off again... Doesnt happen with any other velbu channel, just this one. |
|||||||||
|
wexfordman UCM Pi Users
|
Have just upgraded comfort firmware to latest. UCM velbus is at 5.2.3 thouh as I hadnt upgraded this due to not being able to do it via comfigurator. Will look at upgrading it towards end of week, but I cant see how that would be the problem, considering that it had been working fine for years and I have not touched it for months, and the last firmware upgrade I did on comfort was early this year. Its very odd that the activation of the velbus channel causes the problem (when activated either via comfort, or via velbus pb input) |
|||||||||
|
CytechMartin Cytech 
|
When you activate a velbus relay, you get communication failure. I think you can check the wiring of that part. It does not look like programming problem, just in case, you may send your cclx file to support@cytech.biz . I will help you check the programming. |
|||||||||
|
wexfordman UCM Pi Users
|
Hi Martin, Thanks for update, I will forward on my logfile shortly. While not ruling out a wiring problem, there are a few things that make me think it is not. I will refer to the velbus relay which triggers the comms failure as the water heating relay 1) I have a number of vmb4ry modules, each of them has one connection to the comfort ucm, but controls 4 relays. The water heating relay in question is one of 4 relays on this module, all communicating to comfort via the exact same bus, and the same physical wiring, yet it is only this relay which causes the problem.2) Everything is working fine now this morning, even when the water heating relay is activated. So, the topology, and the wiring of the suspect relay, just doesnt make sense to be due to a wiring problem, as you would expect the same thing to happen on all relays on that module which communicate out the same physical wiring to comfort. Regards,Eamon |
|||||||||
|
slychiu Administrator 
|
I think it is not so much a wiring error in Comfort , but what the velbus relay is connected to For example the relay may be disconnecting the comfort bus or it may be switching some load that causes comfort to be switched off. Communications failure is due to loss of connection on the bus or loss of voltage to the module Test by switching on the relay, then investigate what causes the communications failures. |
|||||||||
|
wexfordman UCM Pi Users
|
Hi slychiu,[size= ]Last night when the problem was occurring, I disconnected the wiring on the velbus relay side so the relay was not switching any power, just in case it was leaking something in to the bus. It made no difference.[size= ]I'm confused even with that at how even a problem on the velbus out affect the comma bus in comfort, as they are effectively isolated are they not ? |
|||||||||
|
slychiu Administrator
|
There certainly appears to be some interference. It depends on how the wirings between the 2 systems are connected. when the communications trouble happens, check the voltages on the UCM modules |
|||||||||
|
wexfordman UCM Pi Users
|
OKay, been away for a few days so not had a chance to do much on this, but been at home all day and everything has been working perfectly. Since 505pm every time i turn on the velbus relay related o the water heating, I get a comms failure, and then when I turn it off, it clears. This has been happening consistently over the last few days, in that during the day time, everyhitng is fine, even when using the velbus relay, but in the evening, problems start. |
|||||||||
|
slychiu Administrator
|
If it happens consistently at a certain time hen it should not be too difficult to fnd the cause It is not possible for the cause to be anything related to programming or the behaviour of comfort because this cannot cause loss of communications. It has to be a physical cause, either loss of voltage on the modules or disconnection |
|||||||||
|
wexfordman UCM Pi Users
|
Ok Thanks I will measure voltage on the ucm modules today and check again when the problem occurs this evening. Regards Eamon |
|||||||||
|
wexfordman UCM Pi Users
|
Right, Did a bit of work on it today, upgraded my velbus ucm to latest firmware. Everything was working fine again until again, about 5 o'clock things started to go awry. Communications failure again. When it started again, It was again only when the velbus heating relay was activated, and I could clear it by un activating it. Measured the voltage for comfort 12v, and was getting about 13.8v, with about 0.1v drop when i truned on the velbus relay, and about the same with any other relay too, so nothing jumping out at that. Things started to get very weird after a bit more testing and measuring, in that the comms filure was permanent, and the keypads un responsive, so i did the follwing 1) Disconnected all scs switches, (by disconnecting the common 12v feed to them) No change.2) Disconnected both keypads (and tried to log in via app), unable to log in via app.3) Disconnected velbus ucm, no change, reconnected and disconnected just the velbus bus, no change, still unable to log in via app. Reconneced everything, restarted comfort, kepyapds bleep, announce tamper alarm, as expected, start screaming and then lock out, no access to anything. Stumped now. I am exepcting it to clear again in a few hours. Regards,Eamon |
|||||||||
|
slychiu Administrator
|
Can you measure if there is a short circuit on the KA/KB wires? try removing the KA/KB and connect just the ucm by the short 4 way cable to Comfort PCB and log in by UCM? Its better to solve this while the fault is manifested and before it recovers Last edited on Sunday Dec 7th, 2014 06:28 am by slychiu |
|||||||||
|
wexfordman UCM Pi Users
|
Hi slychui Will try that, all is working again now, since 8am everything started working again. I did notice a tamper alarm slave 12 in the keypad, I have no slave units |
|||||||||
|
wexfordman UCM Pi Users
|
Hi Slychiu, OKay, as expected, around about 6 this evening things started going awry again, so here is what I did 1) Removed KA and KB wiring from the main board so that only ucms were connected to ka kb via the ribbon cables2) Tested to make sure no short on the ka/kb inputs that I had just removed, all okay. So, at this point, all keypads and scs's had no ka/kb connectin to comfort. I then logged in to comfort successfully via the app and did the following tests. 1) Turned on the velbus heating channel....the app failed to report the status, and also failed to respond to any other velbus commands to any other channels.2) Turned off the velbus heating channel....the app immediately began to successfully report back velbus commands from any other channel. I could repeat the above over and over again with 100% the same results each time. So, it appears that when this velbus channel is activated, it pulls down the ka/kb bus ? Just to clarify also, this particular velbus channel is 1 of 4 on that vmb4ry module, and all communicate on the same velbus bus, but only this one causes the problem. The removal of the ka/kb for all the scs/keypads etc would confirm that the wiring of these are not the problem ? Regards, Eamon Comfort firmare is 100% up to date, including ucms. My setup includes 4 scs switches 1 kp01, 1 kp04, 1 ucm eth01, 1 ucm velbus 7 vmb4ry and 1 vmbdmi Last edited on Sunday Dec 7th, 2014 11:21 pm by wexfordman |
|||||||||
|
slychiu Administrator
|
So when the velbus channel 1 of VMB4RY is switched on, it causes rs485 bus to lose communications But then how are you able to switch off the velbus channel 1? I suspect there may be a fault with the isolation of the Comfort RS485 bus from Velbus RS485 bus Can you send a photo of thye UCM/Velbus and the connections to it? |
|||||||||
|
wexfordman UCM Pi Users
|
Hi slychiu, I turn off the velbus relay manually from the wall switch wired to the pb input. Will send photo shortly, thanks |
|||||||||
|
wexfordman UCM Pi Users
|
Hi,[size= ]Just to update, the comms failure seemed to have come on permanently just before we headed to bed last night. Couldn't activate it control anything. Disconnected the ka and kb and could not connect to comfort via the app.[size= ][size= ]Plugged ka and kb back in and went to bed. At 8am this morning, everything restore and working perfectly.[size= ][size= ]I don't understand the regularity of this, it's so predictable. |
|||||||||
|
wexfordman UCM Pi Users
|
Update today. Again, all seemed to be okay during the day, I did a few minor things, I downloaded latest firmware to my local drive and updated all my modules locally just to be force a firmware update. All went okay, and everything seemed to be working, but the evening gremlins were not due to call till another few hours. Bang on que, at about 5pmish problems started again. Here is what I did to troubleshoot 1) I rewired the comfort velbus (l and h) onto a new direct cable from the velbus ucm to the nearest vmb4ry. No change, comms woud fail when heating was turned on, and clear when it was turned off. 2) When comms is down, I can still see commands goin to the ucmvelbus from the vmb4ry modules when i manually activate the relays. 3) I also rewired so that the only velbus mdule connected was the one vmb4ry with the heatng control relay on it. This meant that the only wiring for L and H was a short 2ft cable between the ucm velbus and the vmb4ry. I was still able to replicate the failure of the comms by turning on an off the heating relay. 4) I started to require the heating relay from chan 1 of the vmb4ry to chan 4, to see if I could move the problem with it. As I was doing this, I then noticed that i had completely lost comms, and could no longer communicate with comfort via keypads, scs, or app (can ping the ucm eth no problem). To try and isloate the probelm with the comms failure, I started to disconnect different modules on the ka/kb bus as follows 1) Disconnected ka/kb connection to main board, effectively removing all kepyads and scs units. Unable to log on to ucm eth 2) Disconnected ucmvelbus also, leavin just the mainn bard and ucm eth connected, and still unable to connect via app. 3) Disconnected ucmeth, and reconnectd just main board ka/kb to reconnect all scs and kepyapds, unable to get keypads or scs switches working, It seems I am now completel locked out of the system, I suspect it will remain so until tomrrow at approx 8am. Regards, Eamon Edit:- When I refer to not being able to connnect via app, the login screen appears in the "connected" staate, but when I enter the code, I get a continious "logging in" message. Last edited on Tuesday Dec 9th, 2014 01:04 am by wexfordman |
|||||||||
|
wexfordman UCM Pi Users
|
Hi, Photo is here What you are looking at is the ucm velbus with the new cable I ran yesterday connected. The new cable is about 3ft long and connects direct to the use board housing my velbus modules. You can also see the old cable with the connectors haning just besie it, this cable was abbrox 40ft run between comfort to a patch panel and back to the fuse board housing the velbus modules. Again, at one point, I had the new short cable running to just one vmb4ry module last night, nothing else, and still no change. As of 7am this morning, the velbus connection to comfort has started working again (comfort is performing velbbus commands based on pir responses), but the scs, keypads and ucm eth are still not contactable. I am expecting these to come back at about 8am.    Last edited on Tuesday Dec 9th, 2014 11:42 am by wexfordman |
|||||||||
|
wexfordman UCM Pi Users
|
Hi, As expected, everything now working 100% from approx 8:30am ish. |
|||||||||
|
slychiu Administrator
|
When this happens again, can you pull out the velbus rs485 submodule from the UCM/Velbus. It may be the velbus rs485 bus interfering with the comfort RS485 bus |
|||||||||
|
wexfordman UCM Pi Users
|
Okay, 5Pm, and it appears to be down again, symptoms are 1) All keypads and scs switches are down2) No access to comfort app (can ping eth, but unable to log in) I will now disconnect the rs485 submodule from the ucm velbus. Completed! I also restarted main board and both ucm boards after removing the submodule Still no access to keypads, scs or ucm eth (can ping it fine, but unable to log in). I will now, disconnect the ucm velbus completely, and all tha ka/kb inputs to the main board, leaving just the ucm eth connected to the main board. I will restart ucm eth and main board and then try to log in via cum eth No access to ucm eth. It seems to me, with just ucm and main board, I should be able to connect, everything else is completely removed from the system, its the most basic setup almost, just main board, ucmeth and lem. Slychui, Is there any possibility at all that the predictible times of failure point to some form of software or programming issue ? I can nearly set my clock by this. In fact a few days ago, I even offset the time on comfort to see if the schedule of the fault would move with it...and it didnt, which surprised me. Regards,Eamon Last edited on Tuesday Dec 9th, 2014 09:16 pm by wexfordman |
|||||||||
|
wexfordman UCM Pi Users
|
Further update I have a spare main board, althouh an older firmware version, so I upgraded the firmware and replaced the existing board for this one. I reconnected everything and tested again, with no improvement, still locked out. One thing to note, is that when this is happening, the one and only way I seem to be able to get any connectivity to the main board is via firmware upgrade with the two way uprade connected to the main board. Any other method, I just cant connect. D9 and D10 are however flashing furiously on the ucm even when there is low/no activity, so it looks like the main board is sending a lot of info out the bus, even when there is little actual activity, unless this is it attempting to communicate with the other modules. |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: When this happens again, can you pull out the velbus rs485 submodule from the UCM/Velbus. Hi slychiu, Please see post number 24 for results Thanks for help so far, struggling at this point to see where to go next. |
|||||||||
|
slychiu Administrator
|
Its very puzzling. Can you confirm a few things? Please answer the following
|
|||||||||
|
wexfordman UCM Pi Users
|
double post. Last edited on Wednesday Dec 10th, 2014 01:31 pm by wexfordman |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: Its very puzzling. Can you confirm a few things? Please answer the following Hi, 1. Yep, around 5pm it starts, but I will double check this evening if the comms failure starts even without the velbus relay being activated (I disabled comms alarm a few days back as kept announcing on keypad). 2. Yes, when it starts first, I can get it to recover with almost 100% reliability. However, after a while, I do lose all comms and cannot get back in no matter what I do, but this is after I have done an amount of troubleshooting, so I am not sure if left alone what would happen. 3. I have been mostly turning the relay on manually, if when it is happening, i turn it on via app, or scs, I lose comms straight afterwards, and cant turn it off unless manually. 4. Yep, when I lose comms completely (which happens after a while and the velbus status makes no difference) I am completely unable to restore it no matter what I disconnect. I can bring the hardware config down to a bare miniumum, with just main board and ucm eth, and am unable to access comfort via phone or comfigurator. The phone sees the system, but is unable to login after I type the password, and comfigurator gives an unable to conenct to ucm message. I am then completely locked out until the following morning at about 9ish, when everything works 100% again. ps:- Ignore the fact that I changed the time on comfort,I may have overwritten this when I downloaded a config file to it. Its worth noting though, that comfort sunrise and sunset times for today are 08:29 and 16:05 Last edited on Wednesday Dec 10th, 2014 01:38 pm by wexfordman |
|||||||||
|
wexfordman UCM Pi Users
|
Everything came back in tis morning at about 8:30, the only difference was that the scs and keypads did not, but this was because they were not added as modules to the new board. Once I got comms back at 8:30ish, I scanned mor modules and added them, everyhting now working again. I will leave all alone now, and see what happens over this evening. If things fail, I will not touch the config, or change anything, and leave the system work through. I will only try to log on to the system and use keypads etc. Comfort time is also correct. |
|||||||||
|
Ingo UCM Pi Users 
|
This is indeed interesting... Have you tried to remove the heater and just put a lightbulb on there? If you disconnect the connection between the heater and Comfort, and switch the heater on manually, does it still do that? I am thinking maybe the heater itself is generating some mains interference which is somehow fed via mains into Comfort. Ingo |
|||||||||
|
wexfordman UCM Pi Users
|
Ingo wrote: This is indeed interesting... Have you tried to remove the heater and just put a lightbulb on there? If you disconnect the connection between the heater and Comfort, and switch the heater on manually, does it still do that? I am thinking maybe the heater itself is generating some mains interference which is somehow fed via mains into Comfort. Hi Ingo, Yes, I have removed the ac input to the relay, so the relay is in effect switching nothing, and the effect is the same. (there is an isolation switch which feeds the velbus relay for the boiler, and I simply turn this off). Its an oil burner, so the load itself isnt particularly high in any case. |
|||||||||
|
Ingo UCM Pi Users
|
Hmm... I was thinking maybe a marginal power connection on the boiler might be causing interference somehow but if you disconnected the relay and it switches 'open air' and still does it then the problem is closer to Comfort. Any chance you have another velbus relay? |
|||||||||
|
wexfordman UCM Pi Users
|
Ingo wrote: Hmm... I was thinking maybe a marginal power connection on the boiler might be causing interference somehow but if you disconnected the relay and it switches 'open air' and still does it then the problem is closer to Comfort. Any chance you have another velbus relay? The velbus relay is one of 4 on that module, its a vmb4ry, which has 4 relays. There is one "bus" from this, so all relays communicate to comfort on the same bus also. The fourth relay was unused, I moved the heating over on to that yesterday to see if any change/impact, but too early to tell yet. The only thing is, that the fourth relay did not cause any problems on comfort, neither did the 2nd and third. Personally, I am starting to think sometthing with the programming, the timing is too regular and consistent for it to be anything else, and as mentioned, I have now swapped out the entire main board, upgraded all firmare etc. |
|||||||||
|
slychiu Administrator
|
3 I have been mostly turning the relay on manually, if when it is happening, i turn it on via app, or scs, I lose comms straight afterwards, and cant turn it off unless manually. It happens when you turn on the relay by Comfort, but if you start by turning it on manually, does it still cause a problem? can you read the event log ? |
|||||||||
|
Ingo UCM Pi Users
|
So relays 2 and 3 work fine? Let's see if 4 works. Perhaps there is a spot of solder bridging the bus and one of the relay 1 contacts or perhaps the relay coil. Last edited on Wednesday Dec 10th, 2014 05:20 pm by Ingo |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: 3 I have been mostly turning the relay on manually, if when it is happening, i turn it on via app, or scs, I lose comms straight afterwards, and cant turn it off unless manually. Hi, I can check that. It doesn't cause a problem right now though, all is working perfectly now. |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: 3 I have been mostly turning the relay on manually, if when it is happening, i turn it on via app, or scs, I lose comms straight afterwards, and cant turn it off unless manually. Hi Slychui, Update this evening, is that all works fine all evening until the heating relay is activated. Activation of heating relay manually knocks out comms, and restores once the relay is turned off again, manually, Note, the relay in question is now relay 4 on this vmb4ry, as I moved it the other day, so the problem seems to move with the load connected to it. This relay is not programmed in comfort either, so not mapped to a counter, so is "invisible" to comfort. Relay 1 with no load, now has no impact when turned on or off manuall or via comfort. Behaviour is certainly better though this evening, as I am able to restore comms simply by turning off the relay, which over the last few nights, did not always happen. So, it would appear that the problem is related to the velbus relay, but it is very hard to understand why this is still only a problem between certain hours of the day, i.e I am gauranteed not to have a problem during daylight hours. I should note, that today also, I disabled the sunset and sunrise responses in the miscelaneous comfort responses. Not sure if this has a direct impact or not. |
|||||||||
|
wexfordman UCM Pi Users
|
Slychui, Enclosed is a copy of the monitor taken when I manualy activated relay 4 (heating relay) that caused the comms to knock out. Again, this relay 4 is not mapped to comfort, comfort cannot see it, and cannot control it. It was a spare relay up until I moved the heating from relay1 to relay 4 of this board. Thanks Eamon Attachment: comfort_log_vmb4ry_relay_4_comms_issue.txt (Downloaded 5 times) Last edited on Thursday Dec 11th, 2014 03:09 am by wexfordman |
|||||||||
|
slychiu Administrator
|
I was actually wanting the event log, not the Monitor IO as that tells when the communications failures happens and restore. Perhaps you can turn on the affected relay before the due time and see if it happens on exactly the same time each day Have you tried resetting comfort while it is in this state? |
|||||||||
|
wexfordman UCM Pi Users
|
Oops, sorry Didn't reset comfort last night as all I needed to do to restore was turn off the relay. On previous evenings I reset comfort when I was completely locked out and it made no difference. Will try the suggestion about turning it on before the expected time to see if it is an exact time that the problem occurs. |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: I was actually wanting the event log, not the Monitor IO as that tells when the communications failures happens and restore. Hi ,Event log enclosed. Note that this is the event log from the new board, so anything pre dec 2014 is from its former life in my sisters house:-) The comms failures, in particularly the ones from this morning at 8am are immediately following me turnin on the velbus heating relay manually. Again, this relay is not mapped to comfort, so you will not see it as an event. At the time of writing this,, 11am, the velbus relay 4 was still turned on, but you will note, no further comms failures after the 8am ones Sunrise time in comfort is 08:29 Regards,Eamon Attachment: log_file_11_dec_11am.clg (Downloaded 4 times) Last edited on Thursday Dec 11th, 2014 03:05 pm by wexfordman |
|||||||||
|
Vangelis Member
|
Have you tried disabling the mains feed into Comfort so it kicks over to Battery Backup just before the 5pm switch-on? This will rule out any mains interference (understand you have removed the load on the relay - however is comfort powering the relay module?) It would appear something is crashing the Comfort Bus - enough for it to be irrecoverable sometimes (ferrite beads maybe??) Have you pulled the Velbus bus feed into the relay module - so Comfort 'thinks' it is issuing a cmd, but nothings listening (might not work if Comfort 'know's' the BUS is not there) A final connectivity test is to log into Comfort locally (i.e not via ADSL router) - Piece of Cat5 straight from PC to UCM/Eth - Try a telnet to IP on Port 1001 (think that is what Comfort uses) from CMD prompt - should get a blank window - if not then the daemon is not listening - which could be a result of Comfort being in a weird state. Vangelis |
|||||||||
|
wexfordman UCM Pi Users
|
Okay, I turned the heating relay on MANUALLY at about 4pm, at 16:45 comms failure came in,so we have two definate times. Comms failure this morning with heating relay on, cleared at 8:09 am and did not re appear all day despite relay being left on. Comms failure again this afternoon at 4:45pm when relay was turned on at 4pm. I manually turned the Relay off at 17:05pm and comms failure cleared. event log attatched Attachment: log_file_11_dec_530pm.clg (Downloaded 2 times) Last edited on Thursday Dec 11th, 2014 10:18 pm by wexfordman |
|||||||||
|
wexfordman UCM Pi Users
|
All good up till about twenty minutes ago when I went to turn on the heating again...comms failure. Here is what I did Manually turned on heating relay comms failure returned.Turned off heating relay, comms failure cleared.Disconnected ac in to the relay and turned it on again....comms failed returned.Turned off relay, comms fail cleared but returned again after about twenty seconds. That was odd, so I connected the ac back into the relay, turned it on, and turned it off again.....comms failure cleared. Will repeat it again later to see if I can do the exact same with the same results. Odd that I needed to reconnect the ac to the relay to get it to clear the alarm again. Last edited on Friday Dec 12th, 2014 05:48 am by wexfordman |
|||||||||
|
slychiu Administrator
|
During the comms failure when nothing is able to communicate, are the D9 (Red) and D10 (green) leds on the UCMs blinking? D10 Green blinking fast means incoming polls from comfort. The blinking is very fast so it appears to be steady on. It should flicker occasionally. D9 Red blink means reply from UCM Another idea is to run the Bus Monitor from Tools press Bus Analyse button  The screenshot shows a typical Bus monitor screen |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: During the comms failure when nothing is able to communicate, are the D9 (Red) and D10 (green) leds on the UCMs blinking? Hi, The green led is either solid or fast flashing and the red led is pulsing. Same in both ucm modules. The monitor won't work, as when it fails I have no access Last edited on Sunday Dec 14th, 2014 06:11 am by slychiu |
|||||||||
|
Ingo UCM Pi Users
|
So just to confirm, D10 (Green LED) goes haywire when the system locks up? What is the D10 LED state like when it's in a normal state? Maybe you can capture the bus data permanently and when it 'dies' then check to see what device sent the most data - it should be the last lot of entries. If I remember correctly the second entry indicates the ID of the module in Hex EG. xx 11 xx xx xx xx would be first UCM, ID1. See Chiu's example in previous post. If you know the module then you can try and identify what it's trying to do. |
|||||||||
|
slychiu Administrator
|
It does not mean the D10 green is hayware In the normal state it blinks fast so it appears to be steady D9 red blinking means the UCM is replying so why is there a communications failure? |
|||||||||
|
Ingo UCM Pi Users
|
Sure. I meant if it is so fast that it is steady On (or 'solid' as mentioned earlier) it might indicate a flood problem. Fast blinking can still be seen though. Last edited on Friday Dec 12th, 2014 04:20 pm by Ingo |
|||||||||
|
wexfordman UCM Pi Users
|
Ingo wrote: So just to confirm, D10 (Green LED) goes haywire when the system locks up? What is the D10 LED state like when it's in a normal state? Hi Ingo, the d10 led atually looks ok according to what slychui says. I see it a either full green/flickering or pulsing rapidly. How do I capture the bus data permanently ? My thinking is, if i need to be connected to comfort, then I will loose comms when the issue happens, and so also lose bus monitor ? I have yesterday ordered a spare vmb4ry, which should be here next week, and I will replace hte new one and see if it makes any difference. Have to say, Im scratching my head here and wouldnt rule out anything. The module could well be faulty, its just beggers belief that it is only between specific times. |
|||||||||
|
slychiu Administrator
|
If the red D9 is blinking it means the UCM is replying, which also means that it received the correct message from Comfort, so the UCM must be communicating Start the Bus monitor before the time that it happens. See what it captures when the fault happens |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: If the red D9 is blinking it means the UCM is replying, which also means that it received the correct message from Comfort, so the UCM must be communicating Will do, thanks |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: If the red D9 is blinking it means the UCM is replying, which also means that it received the correct message from Comfort, so the UCM must be communicating Hi Slychui, Ok, velbus heating relay was on from about 3pm this afernoon and left on all the time. First failure came in at 16:54 as you will see from the event log. I also have the enclosed bus monitor file for the same period, but not clear on how to interpret it. There are corresponding error messages in it at the same time. Heating relay was turned off at approx 1823pm. Regards,eamon bus monitor file was too large, drop box location is here https://www.dropbox.com/s/6tc1t5fnnt7ea70/busmonitor2.txt?dl=0 Attachment: log_file_13_dec_1830pm.clg (Downloaded 1 time) Last edited on Saturday Dec 13th, 2014 11:52 pm by wexfordman |
|||||||||
|
slychiu Administrator
|
The problem seems to be the RS485 bus (KA KB) has interference so that the messages are garbled The NAK replies means that the checksum is wrong in the message 16: 52: 28: 056 ----< 03 53 4E 35 43 02 <--->SN5C NAK reply from/to Rio/Scs03 16: 52: 28: 072 ----< 03 53 4E 35 43 02 <--->SN5C NAK reply from/to Rio/Scs03 16: 52: 28: 185 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02 16: 52: 28: 244 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02 16: 52: 28: 306 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02 16: 52: 28: 369 ----< 03 12 4E 39 44 02 <--->N9D NAK reply from/to Ucm 02 16: 52: 28: 533 ----< 03 51 4E 35 45 02 <--->QN5E NAK reply from/to Rio/Scs01 after this time, all the messages are NAKs The switching on of the relay must be causing some sort of interference to the bus |
|||||||||
|
slychiu Administrator
|
Did you press the Start Button or the Bus Analyse button? The Bus analyse button gives the polling and reply information which seems to be missing |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: The problem seems to be the RS485 bus (KA KB) has interference so that the messages are garbled Thanks slychui, It is odd though is it not that this interference issue comes in at specific times during the day. For example, the relay was turned in for a good hour or more without problems, and the naks just started to come in at that time when nothing had changed, and nothing was done to trigger this interference. |
|||||||||
|
slychiu Administrator
|
The intermittent NAKs started at 15:18 in the bus monitor, but became worse until 16:+ when it happens all the time If you have an oscilloscope you can use it to see what the KA/KB signal looks like |
|||||||||
|
wexfordman UCM Pi Users
|
Hi Sychui, No, dont have an oscilloscope unfortunately. I have been wathcin the NAKS over he last 20 mins, and counted 7 of them over that period. That was with the heating relay off. Is the presence of NAK messages unusual or would you expect a number of them to come in even in a good system ? Do you think that the vmb4ry is what is introducing the noise at this stage, and if so, how can it cross the velbus onto the comfort bus ? |
|||||||||
|
slychiu Administrator
|
NAKs can occur occasionally on the Bus, which may be due to noise and interference. Your problem seems to be interfence caused by the load switching on. It may or may not be due to Velbus. Can you disconnect the load and turn it on manually eg using a switch so it is isolated from Velbus. Seee if that causes the same problem |
|||||||||
|
Ingo UCM Pi Users
|
As a test, I ran my network for most of the night without even one NAK. That Keypad02 of yours looks a bit suspect... Confirm that you receive NAKs for this device all the time or just when the boiler is On? If it's giving these errors all day then perhaps just remove this keypad for a while (as close to Comfort as possible to rule out induced noise in the KP02 cabling). I think in the absence of a clear culprit you need to try the process of elimination. |
|||||||||
|
wexfordman UCM Pi Users
|
Thanks Ingo,Slychui General update, I disconnected the suspect vmb4ry module from the velbus system today, and everything g has worked 100% ok so far. It does indeed look like the velbus module was causing the problem, a very weird problem. Anyway, hoping to have a new module by the end of the week to swap out and this should give a final answer, and I will send the faulty one back for repair. Regards Eamon Last edited on Wednesday Dec 17th, 2014 02:15 am by wexfordman |
|||||||||
|
slychiu Administrator
|
I hope they will feedback what the problem was. We would like to know what caused this |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: I hope they will feedback what the problem was. We would like to know what caused this Will definately ask them to provide details. Day two now of full service with no issues and the vmb4ry disconnected Regards Eamon |
|||||||||
|
wexfordman UCM Pi Users
|
ok, Update as follows. Shortly after the post above, I started to have problems again, and it really confused me, as the vmb4ry was completely disconnected from the system, the only thing common was the 12v power whcih was still powering the vmb4ry so I could retain local control. I ignore the issue, as I had a new vmb4ry on the way, and this would eliminate the module as faulty or not. Anyway, christmas eve, the new module arrived, it was in fact a vmb4ryno, which is pretty much the same module, just to local PB inputs. I replaced it for the suspect one, updated comfort and left to see how things panned out. That evening, the problem came in again, comms failure. So, fairly confused now, I am just simply working my way through replacing parts to eliminate as much hardware as possible. Yesterday I swapped the ucm board that my eth was connected to (re-used the daughter board), and the problem still recurred. The event log shows UCM2 (the velbus ucm) as the main/first module to lose comms, so that was next on my list. I have replaced the ucm velbus, but cant upgrde the firmware to ucm velbus, as it is showing as a ucm general. Can anyone advise how I do this it was formerly a ucm usb, so I am simply replacing the daughter boards). Regards, Eamon Last edited on Tuesday Dec 30th, 2014 08:58 pm by wexfordman |
|||||||||
|
slychiu Administrator
|
You cannot change a UCM/USB firmware to a UCM/Velbus. You can only upgrade the firmware to the same type I dont think the fault is with the UCM/Velbus What triggers the fault now? Is it the switching on of the relays? Can you switch on the velbus relay manually and not from Comfort? Does that cause the problem? |
|||||||||
|
HeFeng Cytech 
|
hi, waxfordman I noticed from your post: "from the system, the only thing common was the 12v power whcih was still powering the vmb4ry" so you power the VMB4RY or VMB4RTNO input (12V) by comfort system? if like this, maybe your problem is due to this... just ignore my post if the relay is powered by velbus system... |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: You cannot change a UCM/USB firmware to a UCM/Velbus. You can only upgrade the firmware to the same type Hi slychui, The fault still seems to be trigggered by the heating going on (whether manually or via comfort) but it does not seem to recover if i turn it off again. Last night, the problem occurred and no matter what I did to try and restore comms I could not. I disconnected every keypad and scs switch via removing the ka/kb and 12 power out from the main board. I also disconnected the ucm velbus. At that point the only items connected were the main board lem and ucm eth, and I could not connect to the system even after restart. (By this I mean I could not connect comfigurator to log in to the system, nor connect a phone via the app. All this time, and trhiughout the night however, comfort performed all macros etc so was not frozen. For example there are pir activations which aactivate velbus lights and turnnthen off again after timers expire etc.....all this worked fine, so comfort continued to work this way, which indicates velbus ucm was fine and main board was fine. The system is still down, but I expect it to recover at about 9am Last edited on Wednesday Dec 31st, 2014 12:04 pm by wexfordman |
|||||||||
|
wexfordman UCM Pi Users
|
HeFeng wrote: hi, waxfordman Hi hefeng, The velbus modules are powered by a separate 12v/15v power[size= supply which is independent of comfort (it does power the ucm velbus daughter boardbi think though.)] |
|||||||||
|
slychiu Administrator
|
If you completely disconnect UCM/Velbus from Comfort and turn on the relays with Velbus does it still happen? |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: If you completely disconnect UCM/Velbus from Comfort and turn on the relays with Velbus does it still happen? I can try that this evening, but put it this way. When I completely disconnect the ucm velbus I still cannot get comfort to recover. Comfort will recover now at about 9am. |
|||||||||
|
wexfordman UCM Pi Users
|
Everything now working normally again as expected, from 08:50 ish |
|||||||||
|
wexfordman UCM Pi Users
|
wexfordman wrote: Everything now working normally again as expected, from 08:50 ish Just to put some definate times on this, the event log over the last few days shows 29th: comms failures start at 16:57 with keypad 2, and continue on for all modules until the comms failure stops recurring at 08:37 the following morning (30th) 30th:- Comms failures start, again at 16:57 with scs 01, and continue for all modules until comms failure stops the followign morning (31st) at 08:35 I will now disconnect the ucm velbus from comfort, and remove the ucm from comfigurator. Will leave it in this state until tomorrow am, and report back with any changes etc. Event log is attatched (ignore the mid -day comms failures for the 30th, this was me trying to replace the ucm velbus with a ucm usb main board) and a keypad Regards,Eamon Attachment: log_file_31_dec_1420pm.clg (Downloaded 2 times) Last edited on Wednesday Dec 31st, 2014 08:35 pm by wexfordman |
|||||||||
|
wexfordman UCM Pi Users
|
Okay, update again. With ucm velbus disconnected from comfort AND velbus bus no alarms came in a expected time (around 1:57). The heating relay was off at this stage I then turned on the heating relay manualy (bearing in mind, that comfort now has absolutely no connectivity to the velbus system), and I lost comms! I am absolutely stuck on this, I simply cannot explain it. Bus monitor file enclosed, you can see the issue come in at about 17:07 Regards,Eamon Attachment: busmonitor13.txt (Downloaded 2 times) |
|||||||||
|
slychiu Administrator
|
The NAKs appear around 17:07 and stop at 17:08:21 After that the commuications seem to be fine. The keypad and RIO/SCS are being polled and reply is received. So you should be able to use the system after that time |
|||||||||
|
wexfordman UCM Pi Users
|
I could not connect to eth, I had to restart the system by disconnecting power and battery before I could connect again. I have two more tests to do, I am going to have the vmb4ry on its own 12v power supply independent of the other modules and see what happens. After this, I can only think that perhaps the load side of the heating is introducing interference in the comfort bus somewhere, so I will try and trace the Gnostic to see if I can find a cross over. |
|||||||||
|
wexfordman UCM Pi Users
|
Okay, Latest update, this issue is still happening. Today as expected, the comms failures started once again like clockwork at 5pm. Tonight, I rewired the heating ac supply via a different route, bypassing the mcb that was feeding it and still no change. Whenever the oil burner kicks in, I get comms failure in comfort (between 5pm and 9am). It looks like I am going to have to get an electrician in to see if I can completely rewire the heating, and possibly remove it from comfort altogether...I've run out of ideas...it's been like this and working fine for nearly fifteen years, and the last month has me dumbfounded. |
|||||||||
|
slychiu Administrator
|
It does look like the oil burner is causing interference to the RS485 bus. The bus is normally very robust as it is differential and very noise resistant so it takes a lot of interference to affect it I think it should be looked into as there may be other effects |
|||||||||
|
Ingo UCM Pi Users
|
One leg of the RS485 touching ground somewhere? Check all the places where the RS485(KA/KB) cables route through between ALL the different modules. Check connectors also, one might be loose etc. |
|||||||||
|
wexfordman UCM Pi Users
|
Thanks all, will do a bit more digging. I would be in agreement to the ibterfer nxe issue, but the regularity of it has mendkubting. 5pm start, 9am finish, pretty much gauranteed. |
|||||||||
|
slychiu Administrator
|
wexfordman wrote: Thanks all, will do a bit more digging. I would be in agreement to the ibterfer nxe issue, but the regularity of it has mendkubting. 5pm start, 9am finish, pretty much gauranteed. you seem a bit stressed |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: wexfordman wrote:Thanks all, will do a bit more digging. I would be in agreement to the ibterfer nxe issue, but the regularity of it has mendkubting. 5pm start, 9am finish, pretty much gauranteed. :-) Sorry, bloody phone auto spell. I would agree with the interference issue, I just can't get my head around why it is so regular with a 5pm start and 9am finish. I have no timers or schedules outside of comfort, and no programs or macros in comfort for these times. The regularity has me dumbfounded |
|||||||||
|
Vangelis Member
|
Install a Ferrite Bead on the Comms Bus?? Did you try running Comfort on its backup battery to rule out a mains spike? Vangelis |
|||||||||
|
wexfordman UCM Pi Users
|
Vangelis wrote: Install a Ferrite Bead on the Comms Bus?? Did you try running Comfort on its backup battery to rule out a mains spike? That's interesting, the oil burner and comfort are actually on the same mcb ! Will try and move it later and see what happens. Regards Eamon |
|||||||||
|
wexfordman UCM Pi Users
|
Vangelis, Moved comfort mains onto a different power supply, and I'm almost afraid to say it in case I jinx myself, but all clear so far, I would expect it to have acted up by now. Please God let that be the cause, although will still need to figure out why it became a problem after all these years. The rest of tonight and tomorrow morning will reveal if it has solved the problem. |
|||||||||
|
Ingo UCM Pi Users
|
Check the Bus Monitor again to see if you still get any of those earlier NAK errors you posted. |
|||||||||
|
wexfordman UCM Pi Users
|
Ingo wrote: Check the Bus Monitor again to see if you still get any of those earlier NAK errors you posted. Will do, not home at the moment though. Everything still working, it's looking the most positive yet. If that's what it is, will be mad keen to find out what was the cause of it, and why it was so regular |
|||||||||
|
wexfordman UCM Pi Users
|
All still working, I think you've done it Vangelis |
|||||||||
|
slychiu Administrator
|
another hit by Vangelis |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: another hit by Vangelis Ok, I think all still looks good, this may well have been the problem, thanks again vengalis and all for help with it.[size= ][size= ] Still curious about how it was so consistent. Is it possible that an external source outside of my local supply might be causing spikes or interference in the mains ? I live in a rural area, can't think what it could be. Last edited on Sunday Jan 11th, 2015 11:08 am by wexfordman |
|||||||||
|
juwi_uk Member 
|
And it is not related to your boiler schedule somehow. It is not spiking somehow when the boiler lights? |
|||||||||
|
wexfordman UCM Pi Users
|
juwi_uk wrote: And it is not related to your boiler schedule somehow. It is not spiking somehow when the boiler lights? I have absolutely no timers or schedules outside of comfort, and the heating control within comfort does not run in a schedule, it's simply turned on by scs input and off after a 1 hr timer within comfort. But yes, the comms failure only ever happened when the heating was turned on between the hours of 5pm and 9am. If you turned it on between 9am and 5pm, everything was fine. |
|||||||||
|
slychiu Administrator
|
one of these is hiding in the boiler perhaps |
|||||||||
|
wexfordman UCM Pi Users
|
slychiu wrote: one of these is hiding in the boiler perhaps Hah, I think I have more than one poking about my house at the moment, trouble with my sky box and our cold room too. These things always come in threes |
|||||||||
|
Vangelis Member
|
Glad to help. As for the 'why it happens' do you know what Comfort is running between the hours of 5pm-9am as opposed to 9am-5pm I only say this as we've kind of narrowed in on the cause being related to noise on the mains, but if the load on Comfort is more later on in the day, it might be more susceptible - that is electrical load as opposed to CPU Do you use screened cable between Comfort and the Velbus module? Vangelis |
|||||||||
|
wexfordman UCM Pi Users
|
Vangelis wrote: Glad to help. Comfort just runs lights as well as the heating, nothing if heavy load. As well as that, at one point I disconnected velbus conoltelty from comfort and it still happened, so it was not really vekbus specific. Was thinking that perhaps someone in my area was running some very noisy plant that along with the heating just caused an excess at those hours ? Clutching at straws I know. |
|||||||||
|
Vangelis Member
|
Agree - Like you say, there could be a number of possible causes, most of which would not be identified unless we could put Comfort on 'Life Support Monitoring' for a period of time. Comfort is not at fault in this case, just that it is highlighting a problem unique to it's operational environment. Short of swapping your wallpaper for tin-foil, you could add some main suppression at key points in your house to mitigate? Vangelis |
|||||||||
|
wexfordman UCM Pi Users
|
Vangelis wrote: Agree - Like you say, there could be a number of possible causes, most of which would not be identified unless we could put Comfort on 'Life Support Monitoring' for a period of time. Absolutely, comfort hasnt been the fault at all, although I think t one stage or another I was leaning towards pretty much every part of the system, I even had convinced myself it was a velbus module, and purchased a spare to replace. Gas to think the solution was so quick to find once you pointed towards the mains interference. The life support you speak of, is that a specific mode within comfort or is it more alng a long term bus monitor. |
|||||||||
|
Vangelis Member
|
I hate to say it but I did post on page 3 of this thread, but it must of been missed with all the investigation work going on..... As for Life Support, this would be a combination Oscilloscopes / Logic Probes / Mains Noise Monitoring that would need to be connected to and around the main Comfort system - Something that is just not viable Now that we hopefully understand the cause you can continue to enjoy and evolve your Comfort setup, whilst being mindful you might need additional noise suppression due to the problems seen in this thread Vangelis |
|||||||||
|
Ingo UCM Pi Users
|
If you have the opportunity then switch off all your electrical equipment on your feed. Comfort and the boiler should be the only devices with power. The best place is the distribution board and then individual units that are on the same circuits as Comfort and the boiler. This might indicate if interference comes from something local or external to your house. |
|||||||||
|
wexfordman UCM Pi Users
|
Vangelis wrote: I hate to say it but I did post on page 3 of this thread, but it must of been missed with all the investigation work going on..... Oops, didnt spot that, sorry, would have saved week or two of grief :-) Well, one good thing is, I now have a spare velbus chan relay, so can add a few more bits on the end of that too. Im going to do a general tidyup of the wiring over the summer, Ive ordered some velbus power and data bus connections to easier daisychain the power and bus without having to use cable, it will be more reliable I reckon, although I dont think Ive had any problems within velbus to date. I want to tidy up the ka/kb connections within comfort also, I have 6 devices around the house, within comort Ive used a connecting block to ie them all together, I think I could do this a bit neater as well. Overall, spring clean time on the automation front:-) On a related note, I've noticed a good few weeks ago that my camera system seems to have some noise on it too..... will check that out a bit further (its on the same circuit as the oil heating too) Might get the boiler serviced too :-) Last edited on Monday Jan 12th, 2015 12:56 am by wexfordman |
|||||||||