[Cbus] Fails to reflect CBUS item status after upgrading CGATE to 3.4.0

[glenm-nz]

Expected Behaviour

Upon starting up OpenHAB, the C-Bus binding should Synchronise all configured C-Bus networks, and reflect their current state.

Current Behaviour

The C-Bus sync command is issued by OpenHAB, and the command can be seen in the C-Gate logs to execute, however the status of the Items linked to the C-Bus Things never update to their current status.

This issue has been observed when Running OpenHAB with C-Gate 3.4.0 however looks to have been introduced earlier than this, as I skipped a few versions during a recent C-Gate upgrade, and also until recently, ran a config file generated by an older-version of C-Gate.

Investigation

When running under C-Gate 3.4.0, the 'get state' command issued by OpenHAB returns the following (Just one device for brevity below):

20241224-211157.893 701 //HMNW/252/56/1 b37de240-c0e8-103c-aa3b-880c0572ce7e state=ok
20241224-211157.893 701 //HMNW/252/56/1 b37de240-c0e8-103c-aa3b-880c0572ce7e level=0

Under an earlier CGATE version (2.11.11_334) , the same response can be seen as follows:

20241224-213805 701 //HMNW/252/56/1 b37de240-c0e8-103c-aa3b-880c0572ce7e state=ok
20241224-213805 701 //HMNW/252/56/1 b37de240-c0e8-103c-aa3b-880c0572ce7e level=0

The responses on the event port therefore now include additional millisecond timestamps, which obviously prevent OpenHAB from interpreting the responses from C-Gate.

Putting the OpenHAB C-Bus binding into 'Trace' Mode, did not show any unexpected messages (that changed between running different versions of C-Gate). I would therefore assume that the C-Bus binding silently ignores anything which does not match the pattern it is looking for.

Looking at the C-Gate configuration file C-GateConfig.txt there is an Option to enable the display of ms on responses. This is enabled by default now:

#### event-millis:
# Show milliseconds in event outout displayed as .xxx after time
# Default Value: yes
# Scope:         global
# Effective on:  restart
###
event-millis=yes

I cannot say exactly which C-Gate version introduced this change in the default value, but for this C-Gate upgrade I let it generate a new config file, and merged my site-specific changes back into the config, mostly to ensure that I am not running a decade-old config file schema.

I tried installing (available) c-gate versions from the Schneider site, and ended-up back at C-Gate 2.11.11_334 as the first where it generated the config, with the default set to 'no', so was introduced at some point > Version 2.11.11_334

Possible Solution

Update C-Bus binding to be able to handle both variants of the timestamp returned by C-Gate, either with or without the ms

Workaround

1. Update C-Gate config file C-GateConfig.txt to now have event-millis=no

This works for OpenHAB, however my primary concern is I have no idea why they changed this default, and if anything else in the C-Bus Ecosystem will depend on this new setting, or will in future. Basic usage of C-Bus toolkit seems happy enough anyway, with it set to 'no'.

Steps to Reproduce (for Bugs)

1. Startup OpenHAB
2. Wait for sync to comment (refer OpenHAB log for confirmation)
3. View status of C-Bus devices - Will remain 'blank'

Your Environment

• Version used: OpenHAB 4.3.0 Release
• C-Bus Binding Version: 4.3.0
• Clipsal C-Gate Version: 3.4.0_2001
• Java Version: Zulu openjdk 17.0.12 2024-07-16 LTS
• Operating System and version: Ubuntu 24.10

[lsiepel]

The underlying dependency (cgateinterface maintained by @jpharvey) seems to be abandoned. A fix for this issue should be made in that library. Unfortunately we can't fix it in openHAB without a full rewrite of the binding.

As you have found a workaround, we could update the documentation that this event-millis=no should be set?

[glenm-nz]

The underlying dependency (cgateinterface maintained by @jpharvey) seems to be abandoned. A fix for this issue should be made in that library. Unfortunately we can't fix it in openHAB without a full rewrite of the binding.

As you have found a workaround, we could update the documentation that this event-millis=no should be set?

Definitely worth having the workaround documented, and agree that #17975 addresses the workaround aspect. May just need to change the version in your note to state that it was introduced somewhere after 2.11.11_334. (I did more research overnight, and updated the ticket)

But if it's OK, I would prefer that the workaround documentation change does not close this ticket. I have just edited the Bug description slightly - One concern that I have is that the default may have changed for a reason (yet unknown) in the Clipsal C-Bus EcoSystem, and whilst the workaround may allow OpenHAB to continue working, it may introduce issues elsewhere for C-Bus users (Something else leveraging C-Gate). In my environment, looks OK, as the only other thing which uses C-Gate (occasionally) is C-Bus Toolkit. But I don't want to make that assumption for other users.

I have a huge learning curve ahead of me, but am keen to try and see if I can start getting my head around the OpenHAB C-Bus Binding this winter (I'm Southern Hemisphere, so won't start until June 2025), and get to the point I can address some minor fixes, including this one, to try and contribute to keeping this binding operational/current. No promises, but will give it a go.
Cheers

[lsiepel]

2.11.11_334 as the first where it generated the config, with the default set to 'yes', so was introduced at some point > Version 2.11.11_334

If 2.11.11_334 has the default set to yes and when set to yes it causes this issue, the problem is introduced before 2.11.11_334 (not after)

To update the docs we need to be sure, it has to be set to no to fix the problem and when the default to yes was introduced

[glenm-nz]

2.11.11_334 as the first where it generated the config, with the default set to 'yes', so was introduced at some point > Version 2.11.11_334

If 2.11.11_334 has the default set to yes and when set to yes it causes this issue, the problem is introduced before 2.11.11_334 (not after)

To update the docs we need to be sure, it has to be set to no to fix the problem and when the default to yes was introduced

Sorry - Was a typo. Have corrected now.

• For C-Gate version 2.11.11_334 the config file was auto-generated with the default set to 'no', and works fine with OpenHAB
• Only reason I cannot be certain of exactly which version introduced the issue, is that I only tested the packages that are now available on the Schneider download site, which may not be a complete set. I worked my way back from 3.4.0 and all created the config with that defaulted to 'yes' and finally when I got to 2.11.11_334 it finally was created with the default of 'no'.
• Their release notes are not that detailed, so no help in pinning it to a particular release.
• I can certainly confirm that it resolves the problem by changing it to 'no', and editing the config back to 'yes' re-introduces the issue, regardless of the version of C-Gate.

I'm not sure what else I can do for diagnostics beyond what was provided above in the ticket, which was based on the following process:

• I spent a lot of time chasing/looking at TLS related issues as that was the major change in C-Gate version 3.4.0, until I realised that with OpenHAB and C-Gate on the same server, they were just using plain communications ('telnet' like), so that was an unrelated issue.
• As nothing was in the OpenHAB trace logs, I started looking in the C-Gate logs, on maximum logging level, I could see the commands issued by OpenHAB, and the responses sent back to the event port used by OpenHAB.
• You can even replay the above commands from the log by making a telnet connection to the C-Gate command port, and seeing the responses in other session(s) connected to the event & change ports.
• Trying this, and then repeating it with the old config file, I discovered the change in the responses (specifically the time-stamp) from C-Gate to OpenHAB, which are posted in the original ticket
• This lead to the trying the config change workaround which resolved the problem for OpenHAB
• Then I performed some basic 'regression' testing of C-Bus toolkit (the only other application I have which also uses C-Gate.). At a basic level, this seems to work ok
• Lastly went back and tested auto-generation of config files from prior C-Gate versions, working back until I found the version which the default was correct, and worked with OpenHAB without intervention

Hope that helps confirm the findings. Thanks.