(01-11-2025, 09:17 AM)slychiu Wrote: oies turning on the velbus light interruot the power supply to the UCM/Velbus?
The command to velbus may be causng tthe UCM/Vlbus to reset. Can you see the RDY led turn off when htis happens?
can you send the cclx file to support@cytech.biz
when did this start to happen was it workin before?
Hi Chui,
Resurecting this one. To answer the question, as to when this happened, to be honest it could have been happening for years wihtout me noticing it, but it became noticable when I integrated comfort to Home Assistant, when the HA alarm panel kept getting set to "triggered" every time a manual light switch was activated.
Now, I did a bit more digging, my initial thought was to just try and get HA to ingore the comms failure alarm, so I asked my good friend chatgpt to help.
Well, we got into great detail, we did reconfigure the HA Alarm panel to ignore ucm comms2 failure, and then set about trying to diagnose the problem itself, ie what was causing the comms failure.
The outcome, and I cannot say that I am 100, or even 90% sure of it, but it is interesting. This may be a messaging issue that just has not been noticed before.
My next post, will be a summary of what and how we tested, hopefully it will make sense to you, and you might be able to add some more to it, or dispell some of the logic etc.
So here we go,
troublehooting the issue with chatgpt
Hi,
I'm revisiting this issue and have now managed to do considerably more detailed testing. I think I have narrowed down the circumstances which cause the UCM/Velbus communications failure quite significantly.
My current equipment is:
Comfort CM9000-ULT, firmware 7.201
UCM/Velbus ID 2, firmware 7.117
VMB4RY modules, build 0818
I have also now connected a VMB1USB to the Velbus and can monitor the bus independently using VelbusLink while Comfort and the UCM/Velbus remain connected.
The important finding is that I can now reproduce the UCM2 communications failure consistently, but only depending on
how the VMB4RY relay is operated.
Physical/local input operation
If I operate a VMB4RY relay from its physical/local pushbutton input, the relay operates normally, but approximately 10 seconds later Comfort reports:
Comm. failure # UCM 2
followed shortly afterwards by:
Comm. restore # UCM 2
The Velbus itself continues operating normally during this.
I can reproduce this using more than one physical/local input, so it does not appear to be a problem with one particular relay channel.
Operating exactly the same relay from Comfort
If I operate the same VMB4RY relay from Comfort, it operates normally and
there is no UCM2 communications failure.
Similarly, operating the relay electronically via Velbus/Home Assistant does not cause the UCM2 communications failure.
This seems to be an important distinction: the problem appears to be associated with the messages generated by the
physical/local VMB4RY inputs, rather than operation of the relay itself.
Velbus packet captures
I have now captured the actual Velbus traffic for both cases.
For example, physically operating local button 1 on VMB4RY address 05 generates the following Button Status packet:
0F F8 05 04 00 10 00 00 E0 04
The UCM/Velbus monitor also sees the corresponding message:
0FF80504001000
This physical operation is followed approximately 10 seconds later by the UCM2 communications failure.
I have also reproduced the failure from another local input where the UCM/Velbus monitor showed:
0FF80504004000
However, when Comfort operates relay channel 1 on the same VMB4RY, the traffic includes:
0F F8 05 02 02 01 EF 04
followed by the normal relay status message and:
0F F8 05 04 00 01 00 00 EF 04
In this case there is
no UCM communications failure.
Therefore it does not appear that the
00
Button Status command itself is the problem.
The difference seems to be the particular status generated by the VMB4RY's local inputs.
It may therefore be worth looking at how UCM/Velbus firmware 7.117 handles the upper-nibble local-input status bits such as
0x10
,
0x20
,
0x40
and
0x80
.
Velbus-to-Comfort mapping test
I also wanted to eliminate the possibility that the failure was related to my Velbus-to-Comfort configuration.
For the test channel I had:
5/1 Office -> Counter Office-Light
I temporarily deleted this mapping completely and wrote the new configuration to the UCM/Velbus EEPROM.
I then operated the same physical/local VMB4RY input.
The UCM2 communications failure occurred exactly as before.
I have since restored the mapping.
This would appear to eliminate the Comfort counter mapping/response configuration as the cause.
CAN error-counter test
I have now also performed what I think is a particularly useful test.
The VMB4RY protocol provides the
D9
Bus Error Counter Request and
DA
Bus Error Counter Status commands.
Before reproducing the fault I requested the error counters directly from VMB4RY address 05.
The response was:
0F FB 05 04 DA 00 00 00 13 04
which gives:
TX error counter:
0
RX error counter:
0
Bus-Off counter:
0
I then physically operated the local input and waited for Comfort to report:
Comm. failure # UCM 2
and subsequently:
Comm. restore # UCM 2
Immediately afterwards I requested the VMB4RY error counters again.
The response was again:
0F FB 05 04 DA 00 00 00 13 04
TX error counter:
0
RX error counter:
0
Bus-Off counter:
0
So the VMB4RY CAN error counters remain
0 / 0 / 0 both before and after reproducing the UCM communications failure.
VelbusLink also continues receiving normal Velbus traffic throughout the event.
This would seem to be fairly strong evidence that the event causing Comfort to lose communications with UCM2 is not accompanied by a CAN transmit error, receive error or Bus-Off condition on the VMB4RY.
Where this seems to leave the investigation
At this point I can consistently demonstrate:
- Physical/local VMB4RY input operation causes the UCM2 communications failure.
- The same relay operated by Comfort does not cause it.
- The same relay operated electronically over Velbus does not cause it.
- More than one VMB4RY local input can reproduce it.
- The relay itself operates correctly.
- Velbus continues communicating normally.
- Removing the corresponding Velbus-to-Comfort mapping does not prevent the failure.
- The VMB4RY CAN TX, RX and Bus-Off error counters remain at zero before and after the failure.
- The failure occurs approximately 10 seconds after the physical operation, which looks more like Comfort subsequently timing out waiting for UCM2 than an immediate loss of the Velbus bus.
Taken together, this seems to point much more towards the
UCM/Velbus processing of the messages generated by the VMB4RY physical/local inputs than towards a relay/load, mapping or Velbus CAN physical-layer problem.
Could you have a look specifically at how UCM/Velbus firmware 7.117 handles
COMMAND_PUSH_BUTTON_STATUS (0x00)
messages from the original VMB4RY, particularly local-input status values such as
0x10
,
0x20
,
0x40
and
0x80
?
It would also be useful to know whether this can be reproduced on another UCM/Velbus 7.117 using a VMB4RY build 0818.
I can provide the full VelbusLink packet captures if useful, and I'm happy to carry out any other targeted packet or configuration tests you would like me to try.
Regards,
Eamon
Adding to the above chatgpt generated summary of the troubleshooting, just to advise, the comms failure is not causing any major issues at the moment, as it does restore almost immediately, and we have reconfigured HA Alarm panel to ignore ucm2 comms failure messages.
Just think this might be of interest in general, and possibly a fix could be applied easily enought ?
