Comfort  Automation/ Security System Forums Home
Home Search search Menu menu Not logged in - Login | Register

Strange counter 128 behaviour.
 Moderated by: admin Page:    1  2  Next Page Last Page  
 New Topic   Reply   Printer Friendly 
 Rate Topic 
AuthorPost
 Posted: Saturday Mar 20th, 2010 10:18 am
   PM  Quote  Reply 
1st Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 562
Status: 
Offline

  back to top

Chiu,

As requested, let's start a new thread regarding this issue. Please move or link the previous couple of posts here if you can.

I looked at the bus monitor and it only works with serial interfaces, I have a UCM/Ethernet so there is no other way I can get logging results at the moment. Let's first see if I can pickup anything out of the ordinary.

Ingo



 Posted: Saturday Mar 20th, 2010 11:43 am
   PM  Quote  Reply 
2nd Post
juwi_uk
Member


Joined: Friday May 25th, 2007
Location: Newbury, United Kingdom
Posts: 1255
Status: 
Offline

  back to top

Ingo

Could you not set up a response that sets the value of this counter in Comfort.

Then you could invoke that response and:

(a) See the results immediately in the monitor log window in Comfigurator 3. 

(b) confirm whether or not my ComfortClient software is capturing on the bus.

Regards

Julian

 



 Posted: Saturday Mar 20th, 2010 02:57 pm
   PM  Quote  Reply 
3rd Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 562
Status: 
Offline

  back to top

Julian,

Triggering this from the CBus side gives me conditions I am supposed to get. Like I said earlier, it doesn't happen every time.

Both ComfortClient and Comfigurator receive the counter changes. It's just under certain conditions that the CT8000 command doesn't get through. This is what is taking so much time to debug. I will catch it eventually.....

Ingo



 Posted: Thursday Apr 1st, 2010 04:14 am
   PM  Quote  Reply 
4th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 562
Status: 
Offline

  back to top

I finally caught it inside the Comfigurator IO Monitor. Below is what I saw...

Cbus Log:
2010/04/01 06:02:35  C-Bus Tx : Set Group 139 - Garage Outside Off (Received from C-Bus/Scene "Perimiter - Off")
2010/04/01 06:02:35  C-Bus Tx : Set Group 207 - Surround Lights Off (Received from C-Bus/Scene "Perimiter - Off")
2010/04/01 06:02:35  C-Bus Tx : Set Group 128 - Open Balcony Off (Received from C-Bus/Scene "Perimiter - Off")
2010/04/01 06:02:35  C-Bus Tx : Set Group 136 - Patio - Garden Off (Received from C-Bus/Scene "Perimiter - Off")

Comfigurator IO Monitor, 1/4/2010.
< CT8B00
< CTCF00
< CT8800

From the above it can be seen that the Cbus side sends four commands. These are all via a Scene to switch my outside lights off at sunrise. From the realtime Comfigurator log there are only three commands that reached the Comfort bus. Strange enough, it's always counter 128 and it's never consistent. It took a whole week since the last 'failure'

Can you guys please check if there is anything that might be causing this? A workaround is to change from counter 128 to 129 but that's not really fixing the problem.

Ingo



 Posted: Friday Apr 2nd, 2010 02:56 am
   PM  Quote  Reply 
5th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 5500
Status: 
Offline

  back to top

This may be difficult to reproduce. Have you tried repeatedly triggering the Cbus group address 80 hex to see if the condition can be seen that way?



 Posted: Friday Apr 2nd, 2010 07:18 am
   PM  Quote  Reply 
6th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 562
Status: 
Offline

  back to top

Yes, I did and it always returns the correct values (well, for as long as I toggled the counter value). I'll try again to see if there is an easier way to simulate the problem but I am not very hopeful.

Ingo



 Posted: Friday Apr 2nd, 2010 07:52 am
   PM  Quote  Reply 
7th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 562
Status: 
Offline

  back to top

Ignore my previous post, I finally found the cause. It bothered me why it takes so long to replicate and sometimes it's so quick. I finally found that if counter 128 is ON and I then run both my ComfortClient and CBus application it then triggers. Below is the complete set of events that occur to reproduce this.

In short, set counter 128 to ON, load ComfortClient, or any other software to monitor the counter. Now toggle counter 128 to OFF from the CBus side and see that the very first command does NOT get through to Comfort. All subsequent commands are sent through.

*I did a complete test and it seems to be counters 128,129,131 and 132 that are affected. I am not using counter 130 so I can't say if that one is affected as well.

[09:32:58] + Comfort Client:1.21.1.5
[09:33:02] + Connected
[09:33:24] > LI****
[09:33:25]  < LU01
[09:33:27] > M?
[09:33:27] > K?
[09:33:27] > C?65
[09:33:27] > C?66
[09:33:27] > C?67
[09:33:27] > C?68
[09:33:27] > C?6A
[09:33:27] > C?6B
[09:33:27] > C?6C
[09:33:27] > C?6E
[09:33:27] > C?71
[09:33:27] > C?72
[09:33:28] > C?74
[09:33:28] > C?75
[09:33:28] > C?76
[09:33:28] > C?77
[09:33:28] > C?78
[09:33:28] > C?79
[09:33:28] > C?7A
[09:33:28] > C?7B
[09:33:28] > C?7C
[09:33:28] > C?7D
[09:33:28] > C?7E
[09:33:28] > C?7F
[09:33:28] > C?81
[09:33:28] > C?83
[09:33:28] > C?84
[09:33:28] > C?86
[09:33:29] > C?87
[09:33:29] > C?8C
[09:33:29] > C?8D
[09:33:29] > C?F4
[09:33:29] > C?F5
[09:33:29] > C?F6
[09:33:29] > C?FC
[09:33:29] > C?0A
[09:33:29] > C?32
[09:33:29] > C?33
[09:33:29] > C?73
[09:33:29] > C?80
[09:33:29] > C?88
[09:33:29] > C?89
[09:33:29] > C?8A
[09:33:29] > C?8B
[09:33:30] > C?A8
[09:33:30] > C?C9
[09:33:30] > C?CA
[09:33:30] > C?CB
[09:33:30] > C?CC
[09:33:30] > C?CD
[09:33:30] > C?CE
[09:33:30] > C?CF
[09:33:30] > C?D0
[09:33:30] > C?D1
[09:33:30] > C?D2
[09:33:30] > C?D4
[09:33:30] > C?D5
[09:33:30] > C?D6
[09:33:30] > C?D7
[09:33:30] > C?D8
[09:33:31] > C?D9
[09:33:31] > C?DA
[09:33:31] > C?DB
[09:33:31] > C?DD
[09:33:31] > C?DE
[09:33:31] > C?DF
[09:33:31] > C?E0
[09:33:31] > C?F7
[09:33:31] > C?28
[09:33:31] > C?A9
[09:33:31] > Z?
[09:33:31] > z?
[09:33:31] > Y?
[09:33:31] > y?
[09:33:31] > SR01
[09:33:32] > S?
[09:33:32]  < M?0001
[09:33:32]  < KL00010000
[09:33:32]  < C?6500
[09:33:32]  < C?6600
[09:33:32]  < C?6700
[09:33:32]  < C?6800
[09:33:32]  < C?6A00
[09:33:32]  < C?6B00
[09:33:32]  < C?6C00
[09:33:32]  < C?6E00
[09:33:32]  < C?7100
[09:33:32]  < C?7200
[09:33:32]  < C?7400
[09:33:32]  < C?7500
[09:33:32]  < C?7600
[09:33:32]  < C?7700
[09:33:32]  < C?7800
[09:33:32]  < C?7900
[09:33:32]  < C?7A00
[09:33:32]  < C?7B00
[09:33:32]  < C?7C00
[09:33:32]  < C?7D00
[09:33:32]  < C?7E00
[09:33:32]  < C?7F00
[09:33:32]  < C?8100
[09:33:32]  < C?8300
[09:33:32]  < C?8400
[09:33:32]  < C?8600
[09:33:32]  < C?8700
[09:33:32]  < C?8C00
[09:33:32]  < C?8D00
[09:33:32]  < C?F41A
[09:33:32]  < C?F5FF
[09:33:32]  < C?F6FF
[09:33:32]  < C?FC99
[09:33:32]  < C?0AFF
[09:33:32]  < C?3200
[09:33:32]  < C?33FF
[09:33:32]  < C?7300
[09:33:32]  < C?80FF
[09:33:32]  < C?8800
[09:33:32]  < C?8900
[09:33:32]  < C?8A00
[09:33:32]  < C?8B00
[09:33:32]  < C?A800
[09:33:32]  < C?C900
[09:33:32]  < C?CA00
[09:33:32]  < C?CB00
[09:33:32]  < C?CC00
[09:33:32]  < C?CD00
[09:33:32]  < C?CE00
[09:33:32]  < C?CF00
[09:33:32]  < C?D000
[09:33:32]  < C?D100
[09:33:32]  < C?D200
[09:33:32]  < C?D400
[09:33:32]  < C?D500
[09:33:32]  < C?D600
[09:33:32]  < C?D700
[09:33:32]  < C?D800
[09:33:32]  < C?D900
[09:33:32]  < C?DA00
[09:33:32]  < C?DB00
[09:33:32]  < C?DD00
[09:33:32]  < C?DE00
[09:33:32]  < C?DF00
[09:33:32]  < C?E000
[09:33:32]  < C?F700
[09:33:32]  < C?28FF
[09:33:32]  < C?A900
[09:33:32]  < Z?0000000000007600
[09:33:32]  < z?00
[09:33:32]  < OK
[09:33:32]  < Y?0000000000000000
[09:33:32]  < y?00
[09:33:32]  < S?00
[09:33:54]  < CT80FF
[09:33:56]  < CT8000


2010/04/02 09:33:45  C-Bus Tx : Set Group 128 - Open Balcony Off (User Click)   <---- This one does not get sent to the Comfort bus.
2010/04/02 09:33:54  C-Bus Tx : Set Group 128 - Open Balcony On (User Click)
2010/04/02 09:33:56  C-Bus Tx : Set Group 128 - Open Balcony Off (User Click)




 Posted: Friday Apr 2nd, 2010 08:32 am
   PM  Quote  Reply 
8th Post
slychiu
Administrator


Joined: Saturday Apr 29th, 2006
Location: Singapore
Posts: 5500
Status: 
Offline

  back to top

Good work, Ingo. It would have been very difficult for us to duplicate this scnario without this information
What is the firmware for Comfort, UCM and UCM/Cbus that you are using?



 Posted: Friday Apr 2nd, 2010 10:14 am
   PM  Quote  Reply 
9th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 562
Status: 
Offline

  back to top

Comfort II 5.172
UCM/Cbus 5.203
UCM/Ethernet 5.202



 Posted: Tuesday Apr 6th, 2010 02:37 am
   PM  Quote  Reply 
10th Post
ident
Administrator


Joined: Wednesday Aug 9th, 2006
Location: Singapore
Posts: 3493
Status: 
Offline

  back to top

Ingo, we have not been able to duplicate this despite using the same firmware as you mentioned.
We set counter 128 to FF (using Cbus), run Wizcomfort, then use Cbus group address 128 to switch off. This sets CT8000

The only reason that Counter 128 does not get changed to 00 is that it was already 00.

Can you repeat your sequence above but before you turn on balcony group address 128 the first time, do a C?80 to query the counter. Counter 128 must have been changed to 00 prior to that due to some other reason



 Posted: Tuesday Apr 6th, 2010 02:55 am
   PM  Quote  Reply 
11th Post
ident
Administrator


Joined: Wednesday Aug 9th, 2006
Location: Singapore
Posts: 3493
Status: 
Offline

  back to top

If you mean that you changed the state of the counter to FF in Comfort, and the corresponding Cbus counter was in the opposite state (0), then when you toggle the CBus button to switch to FF, then there will be no Counter Response in Comfort because the counter is already at FF

The Counter report and response happens only if there is a change in value
eg
set Counter 128 to FF
> C!80FF  change counter 128 to FF
< CT80FF is the counter report that Counter 128 changed to FF
> C!80FF  change counter 128 to FF again

This time there is no counter report because the counter 128 value was not changed

> CT8000 set counter 128 to 00
< CT8000 report that counter 128 is changed to 00


Does this correspond to what is happening with your setup?



Last edited on Tuesday Apr 6th, 2010 02:58 am by ident



 Posted: Tuesday Apr 6th, 2010 04:40 pm
   PM  Quote  Reply 
12th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 562
Status: 
Offline

  back to top

Ident,

This is what you need to do. I'll explain the tricky part at the end.

1. Set Counter 128 ON from CBus side.
[06:43:18]  < CT80FF

2. Check Counter 128 value on Comfort side.
[06:43:23] > C?80
[06:43:23]  < C?80FF

3. Do the following command:
[06:43:30] > Z?

4. At his point I Switched Counter 128 OFF from the Cbus side, notice NO corresponding CT8000 command back from the UCM.

5. Do a Counter 128 check on the Comfort side.
[06:43:51] > C?80
[06:43:51]  < C?8000

This is the tricky part. Immediately the Counter value changed to what it's supposed to be. Without the receiving CT8000 command my ComfortClient thinks the light is still on. Only a subsequent On/Off toggle will restore the true nature of the light state.

Ingo



 Posted: Wednesday Apr 7th, 2010 03:27 am
   PM  Quote  Reply 
13th Post
hendy
Cytech


Joined: Wednesday Sep 19th, 2007
Location: Singapore
Posts: 221
Status: 
Offline

  back to top

Hi Ingo,

I've tried exactly the 5 steps you mentioned but still managed to get CT8000 received by ComfortClient.

One thing I notice is that the latest ComfortClient version posted by Julian is 1.20.2.35 (http://www.comfortforums.com/forum65/1656.html) but you are using 1.21.1.5.
Is there any major differences for the two versions?
Do you know where I can get the same version as yours so I can try to duplicate your problem here?

I've also tried with our Wizcomfort beta (see: http://www.comfortforums.com/view_topic.php?id=1662&forum_id=21), the CT8000 is sent correctly to Wizcomfort when it is turned off from C-bus.



 Posted: Wednesday Apr 7th, 2010 04:34 am
   PM  Quote  Reply 
14th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 562
Status: 
Offline

  back to top

Hendy,

I am using an Alpha version of ComfortClient which is not yet available to everyone. There is a big feature difference between the two versions so watch this space :-). I've also used Comfigurator and the results are similar. The problem is not with the client software monitoring the bus.

It is VERY strange that I can replicate the problem at will and you guys can't. I'll try a last time on my 'Test' system which has only 8 zones, my production system is fully populated with 64 zones.

Ingo


PS. I replaced my UCM/Ethernet with another one and it still does the same, unfortunately I don't have another UCM/Cbus. Give me some time to setup my Test system and I will post the results soon.

Last edited on Wednesday Apr 7th, 2010 05:10 am by Ingo



 Posted: Wednesday Apr 7th, 2010 07:23 am
   PM  Quote  Reply 
15th Post
hendy
Cytech


Joined: Wednesday Sep 19th, 2007
Location: Singapore
Posts: 221
Status: 
Offline

  back to top

Ingo wrote: Ident,

This is what you need to do. I'll explain the tricky part at the end.

1. Set Counter 128 ON from CBus side.
[06:43:18]  < CT80FF

2. Check Counter 128 value on Comfort side.
[06:43:23] > C?80
[06:43:23]  < C?80FF

3. Do the following command:
[06:43:30] > Z?

4. At his point I Switched Counter 128 OFF from the Cbus side, notice NO corresponding CT8000 command back from the UCM.

5. Do a Counter 128 check on the Comfort side.
[06:43:51] > C?80
[06:43:51]  < C?8000

This is the tricky part. Immediately the Counter value changed to what it's supposed to be. Without the receiving CT8000 command my ComfortClient thinks the light is still on. Only a subsequent On/Off toggle will restore the true nature of the light state.

Ingo


Ingo,

Could it be that in between of those steps above the UCM/Cbus get reset, somehow?



 Posted: Wednesday Apr 7th, 2010 03:04 pm
   PM  Quote  Reply 
16th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 562
Status: 
Offline

  back to top

Nope, not a chance. It's securely mounted inside a panel well hidden from anything.

Ingo



 Posted: Wednesday Apr 7th, 2010 06:11 pm
   PM  Quote  Reply 
17th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 562
Status: 
Offline

  back to top

Hendy,

These are the tests I did to try and localise the problem:

1. Downgrade the UCM/Cbus to 5.200 - Same result.

2. Disconnect my PAC from the network to eliminate any CBus interference - Same result.

3. Clear my Comfort Configuration - Same result.

and just before I went insane....

4. Connect my existing UCM/CBus to my 'Test' system with 8 zones only. Downloaded my original 64 zone configuration - Working perfectly.

It seems that with a system as fully populated as mine, something goes 'missing' when doing the test procedure stated in an earlier post.

I hope this help you guys simulate the problem. Just a note, I used Comfigurator 3.1.3, in Monitor IO mode, to check the bus messages.

Regards,
Ingo

PS. Julian, your Client is working as designed, even an earlier release showed me what Comfigurator showed.



 Posted: Thursday Apr 8th, 2010 01:25 am
   PM  Quote  Reply 
18th Post
ident
Administrator


Joined: Wednesday Aug 9th, 2006
Location: Singapore
Posts: 3493
Status: 
Offline

  back to top

We had better duplicate your full configuration. Can you send your cclx file to support@cytech.biz



 Posted: Tuesday Apr 13th, 2010 12:57 pm
   PM  Quote  Reply 
19th Post
admin
Administrator


Joined: Saturday Mar 3rd, 2007
Location: Singapore
Posts: 1200
Status: 
Offline

  back to top

I can report that we have managed to duplicate your problem now using your cclx file.
The number of slaves must be 3.

Set Cbus group addresses 80H and/or 81H on
do Z? on the UCM

C?80 and C?81 will show that they are ON (FF)

Now switch off group addresses 80H and 81H
There will be no report CT8000 and CT8100
However the counters 80H and 81H have the correcct values 00, but they are not reported by the UCM  for some reason

We are now investigating this curious incident

Last edited on Tuesday Apr 13th, 2010 12:58 pm by admin



 Posted: Tuesday Apr 13th, 2010 03:18 pm
   PM  Quote  Reply 
20th Post
Ingo
UCM Pi Users


Joined: Sunday Jan 21st, 2007
Location: South Africa
Posts: 562
Status: 
Offline

  back to top

This is indeed good news. Remember that counters 128 - 133 exhibit the same symptoms. The rest seems to work fine.

Ingo



 Current time is 10:36 pmPage:    1  2  Next Page Last Page  
Top




UltraBB 1.172 Copyright © 2007-2014 Data 1 Systems