Posted: Sunday Apr 8th, 2012 07:32 pm |
|
1st Post |
ekarak
Member
Joined: | Wednesday Apr 21st, 2010 |
Location: | Athens, Greece |
Posts: | 51 |
Status: |
Offline
|
back to top
|
I have an odd problem with a Comfort installation and my client is frustrated at this.
A certain KNX group address (a pool pump) is activated every 5 minutes! it is (supposedly) fired by a timer response that is set to fire every day (not every 5 minutes!!!).
The pool pump response is not related to any counter, its just a time program to turn on the pool at certain time of day.
This installation has 5.2xxx firmware (havent updated it to 6.xxx, the installation is some 200km away).
Happy Easter!
EliasLast edited on Sunday Apr 8th, 2012 08:12 pm by ekarak
|
Posted: Monday Apr 9th, 2012 02:31 am |
|
2nd Post |
ident
Administrator
Joined: | Wednesday Aug 9th, 2006 |
Location: | Singapore |
Posts: | 3493 |
Status: |
Offline
|
back to top
|
Comfort will only do something if it is programmed in some way to do it so this should be related to your program. Send the cclx file to support@cytech.biz for us to look at it, and also show what are the relevant responses and time programs or areas affecting it if the program is large
|
Posted: Thursday Aug 16th, 2012 07:12 am |
|
3rd Post |
ekarak
Member
Joined: | Wednesday Apr 21st, 2010 |
Location: | Athens, Greece |
Posts: | 51 |
Status: |
Offline
|
back to top
|
Well, after upgrading to 6.xxx the same problem manifests itself in another address. Take a look at the screenshot attached, every time someone sends a drive command to addr 0/2/4, a spurious "ON" is sent to 0/3/10 ! Attachment: KNX-spurious-packet.png (Downloaded 36 times)
|
Posted: Thursday Aug 16th, 2012 07:18 am |
|
4th Post |
ekarak
Member
Joined: | Wednesday Apr 21st, 2010 |
Location: | Athens, Greece |
Posts: | 51 |
Status: |
Offline
|
back to top
|
Update: the problem is related to the UCM/KNX module. I had mapped the "initiating" group addresses via "KNX to comfort" each one to its own (unused) counter. When I removed the binding, the problem went away.
|
Posted: Thursday Aug 16th, 2012 09:08 am |
|
5th Post |
ident
Administrator
Joined: | Wednesday Aug 9th, 2006 |
Location: | Singapore |
Posts: | 3493 |
Status: |
Offline
|
back to top
|
Can you send your cclx file so we can duplicate?
|
Posted: Thursday Aug 16th, 2012 09:38 am |
|
6th Post |
ekarak
Member
Joined: | Wednesday Apr 21st, 2010 |
Location: | Athens, Greece |
Posts: | 51 |
Status: |
Offline
|
back to top
|
You have it already, its PanormosComfort.cclx from the initial posting.
|
Posted: Thursday Aug 16th, 2012 09:53 am |
|
7th Post |
ident
Administrator
Joined: | Wednesday Aug 9th, 2006 |
Location: | Singapore |
Posts: | 3493 |
Status: |
Offline
|
back to top
|
Yes you are right. we will check again
Anyway it is good that you have upgraded the firmware to version 6 because that would allow future firmware upgrades over the Internet if the site has UCM/Ethernet, provided the UCM/ETH02 and Comfort firmware are also version 6
|
Posted: Friday Aug 17th, 2012 11:59 am |
|
8th Post |
ident
Administrator
Joined: | Wednesday Aug 9th, 2006 |
Location: | Singapore |
Posts: | 3493 |
Status: |
Offline
|
back to top
|
Can you run Bus Monitor from the Tools Menu
This monitors the internal messages between UCM/KNX and Comfort which we would like to examine
Start the Bus Monitor. Then send the KNX message which generates the spurious KNX from Comfort.
Halt the Bus Monitor and Save All then save as a text file and send it to support@cytech.biz
thanks
|
Posted: Friday Aug 17th, 2012 01:08 pm |
|
9th Post |
ident
Administrator
Joined: | Wednesday Aug 9th, 2006 |
Location: | Singapore |
Posts: | 3493 |
Status: |
Offline
|
back to top
|
We may have found the bug but we need to confirm
It may be because a group address is mapped in the KNX to Comfort and is not assigned to any counter.
|
Posted: Friday Aug 17th, 2012 08:19 pm |
|
10th Post |
ekarak
Member
Joined: | Wednesday Apr 21st, 2010 |
Location: | Athens, Greece |
Posts: | 51 |
Status: |
Offline
|
back to top
|
I've just sent to support@cytech.biz the log file from the bus monitor. A drive control command is sent from a KNX touchscreen (GA 0/2/3 is move up/down and GA 0/2/4 is step/stop). A few tens of milliseconds later, a "bogus" KNX packet is sent by Comfort to GA 0/3/10.
I _think_ this problem relates to the floating values overwriting "bug" I mentioned earlier today. Not scientifically proven, but just a strong hinch.
Anyway, thanks for the terrific support!
|
Posted: Saturday Aug 18th, 2012 02:20 am |
|
11th Post |
ident
Administrator
Joined: | Wednesday Aug 9th, 2006 |
Location: | Singapore |
Posts: | 3493 |
Status: |
Offline
|
back to top
|
Thanks but You sent a KNX Monitor log
Last edited on Saturday Aug 18th, 2012 03:02 am by ident
|
Posted: Saturday Aug 18th, 2012 03:03 am |
|
12th Post |
ident
Administrator
Joined: | Wednesday Aug 9th, 2006 |
Location: | Singapore |
Posts: | 3493 |
Status: |
Offline
|
back to top
|
I was mistaken, you did send the correct Bus Monitor Log. I clicked on the wrong file and opened the KNX screenshot instead!
We are looking aty the bus moniror now
|
Posted: Saturday Aug 18th, 2012 08:08 am |
|
13th Post |
ident
Administrator
Joined: | Wednesday Aug 9th, 2006 |
Location: | Singapore |
Posts: | 3493 |
Status: |
Offline
|
back to top
|
We have traced the cause of the problem. It was due to a combination of Comfigurator and UCM/KNX bugs
There was a bug in Comfigurator where the Drive Control telegram Type mapped to Counter was not written correctly to EEPROM. If you Read from EEPROM, you will find that the Drive Control telegram mappings become Blank. Normally you cannot assign Blank Counter or Sensor to a KNX to Comfort entry
This bug has been fixed in the new Comfigurator 3.5.4 (beta) , see http://www.comfortforums.com/view_topic.php?id=3021&forum_id=20&jump_to=12715#p12715
The assignment of Blank Counter in KNX to Comfort causes a bug to be manifested. It sends a Counter 255 change to Comfort, which MAY trigger a spurious and random Response. This is what happened in your case - it caused the Response which sends 0/3/10 to be sent to KNX.
This can be fixed by upgrading to Comfigurator 3.5.4
Then do a Write to KT03 again which will send the correct Drive Control mapping to UCM/KNX and the UCM/KNX will not exhibit the problem.
Let us know if that works.
This may also have an effect on your other temperature problem in the same file, although we have not tested that yet
Thanks for your feedback and information
|
Posted: Saturday Aug 18th, 2012 08:10 am |
|
14th Post |
ident
Administrator
Joined: | Wednesday Aug 9th, 2006 |
Location: | Singapore |
Posts: | 3493 |
Status: |
Offline
|
back to top
|
Of course the UCM/KNX bug will be fixed in the next firmware release but without the Comfigurator bug, it should not cause any problems
|
Posted: Sunday Aug 19th, 2012 10:12 am |
|
15th Post |
ekarak
Member
Joined: | Wednesday Apr 21st, 2010 |
Location: | Athens, Greece |
Posts: | 51 |
Status: |
Offline
|
back to top
|
Confirmed by testing, the drive control does not produce the bogus packets anymore.
All KNX floating-point values still get overwritten though.
|
Posted: Thursday Aug 23rd, 2012 08:12 am |
|
16th Post |
ident
Administrator
Joined: | Wednesday Aug 9th, 2006 |
Location: | Singapore |
Posts: | 3493 |
Status: |
Offline
|
back to top
|
We have confirmed there is another mesage sent for floating point packets assigned to sensor. This will be fixed in the next version of KNX which we are working on
|
Posted: Friday Sep 7th, 2012 03:07 am |
|
17th Post |
|