12-11-2014, 04:04 PM (This post was last modified: 12-11-2014, 04:05 PM by wexfordman.)
[user=1]slychiu[/user] wrote:
Quote: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?
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
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.
12-12-2014, 06:42 AM (This post was last modified: 12-12-2014, 06:48 AM by wexfordman.)
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.
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
12-12-2014, 01:59 PM (This post was last modified: 12-14-2014, 07:11 AM by slychiu.)
[user=1]slychiu[/user] wrote:
Quote: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
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
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.
12-12-2014, 05:19 PM (This post was last modified: 12-12-2014, 05:20 PM by Ingo.)
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.
Quote: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.
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.
