CBUS Binding configuration queries

Add-ons Bindings
1

I am looking for some advice please….

A friend has the following hardware/software setup:

RaspPi 3 running OpenHABian

CGate running (ver 2.11.4) & Ser2Sock and is connected via USB to Serial adapter to CBUS serial controller.

OpenHAB 2.5.5 (previously 2.5.4) + CBUS Binding (https://www.openhab.org/addons/bindings/cbus/)

Test Results/Symptoms:

Can use CGate CLI commands on RasPi to turn on/off CBUS lighting

OH CBUS binding doesn’t auto-discover as suggested.

OH static Thing created for “cgatenetwork” bridge & “cbusnetwork” bridge & light are Online

Lights turned on/off at switch affect the OH status for that light

Attempts to switch on Thing via Control menu (or via a channel assigned to an Item both get an OH error saying “Invalid Group” in the OH Log.

CGate Logs don’t seem to suggest that OH sent a request to change the light when it should have (I think !)

Questions:

Is the group number always the same as the light number ? Any thoughts on the error received ?

There appears to be two way to defines lights, which is better ?

Based on the suppled CBUS output how should a light Thing be defined ?

CGate Config/Log:

20200523-155519 761 cmd25 - Command: [56] noop

20200523-155519 766 cmd25 - Response: [56] 200 OK.

20200523-155529 761 cmd25 - Command: [57] net list_all

20200523-155529 766 cmd25 - Response: [57] 135 project=PETER address=//PETER/100 OID=cc234ff0-7ac7-1038-4534-f728a6bad8bf interfaceType=cni interfaceAddress=192.168.1.54:10001 state=ok interfaceState=running

20200523-155529 761 cmd25 - Command: [58] project dir

20200523-155529 766 cmd25 - Response: [58] 123 project=PETER

20200523-155529 761 cmd25 - Command: [59] project dir

20200523-155529 766 cmd25 - Response: [59] 123-project=EXAMPLE

20200523-155529 766 cmd25 - Response: [59] 123 project=PETER

20200523-155529 761 cmd25 - Command: [60] dbget //PETER/100/TagName

20200523-155529 766 cmd25 - Response: [60] 342 100/TagName=n100

20200523-155529 766 cmd25 - Response: [65] 342-100/Address=100

20200523-154409 701 //PETER/100/56 - state=ok

20200523-154409 701 //PETER/100/56/0 - state=ok

20200523-154409 701 //PETER/100/56/0 - level=0

20200523-154409 701 //PETER/100/56/1 - state=ok

20200523-154409 701 //PETER/100/56/1 - level=0

20200523-154409 701 //PETER/100/56/2 - state=ok

20200523-154409 701 //PETER/100/56/2 - level=0

20200523-154409 701 //PETER/100/56/3 - state=ok

20200523-154409 701 //PETER/100/56/3 - level=0

20200523-154409 701 //PETER/100/56/4 - state=ok

20200523-154409 701 //PETER/100/56/4 - level=255

20200523-154409 701 //PETER/100/56/5 - state=ok

20200523-154409 701 //PETER/100/56/5 - level=0

20200523-154409 701 //PETER/100/56/6 - state=ok

20200523-154409 701 //PETER/100/56/6 - level=0

20200523-154409 701 //PETER/100/56/7 - state=ok

20200523-154409 701 //PETER/100/56/7 - level=0

20200523-154409 701 //PETER/100/56/8 - state=ok

20200523-154409 701 //PETER/100/56/8 - level=0

20200523-154409 701 //PETER/100/56/9 - state=ok

20200523-154409 701 //PETER/100/56/9 - level=0

20200523-154409 701 //PETER/100/56/16 - state=ok

20200523-154409 701 //PETER/100/56/16 - level=0

20200523-154409 701 //PETER/100/56/17 - state=ok

20200523-154409 701 //PETER/100/56/17 - level=0

20200523-154409 701 //PETER/100/56/18 - state=ok

20200523-154409 701 //PETER/100/56/18 - level=0

20200523-154409 701 //PETER/100/56/19 - state=ok

20200523-154409 701 //PETER/100/56/19 - level=0

20200523-154409 701 //PETER/100/56/20 - state=ok

20200523-154409 701 //PETER/100/56/20 - level=0

20200523-154409 701 //PETER/100/56/21 - state=ok

20200523-154409 701 //PETER/100/56/21 - level=0

20200523-154409 701 //PETER/100/56/22 - state=ok

20200523-154409 701 //PETER/100/56/22 - level=0

20200523-154409 701 //PETER/100/56/23 - state=ok

20200523-154409 701 //PETER/100/56/23 - level=0

20200523-154409 701 //PETER/100/56/24 - state=ok

20200523-154409 701 //PETER/100/56/24 - level=0

20200523-154409 701 //PETER/100/56/25 - state=ok

20200523-154409 701 //PETER/100/56/25 - level=0

20200523-154409 701 //PETER/100/56/32 - state=ok

20200523-154409 701 //PETER/100/56/32 - level=0

20200523-154409 701 //PETER/100/56/33 - state=ok

20200523-154409 701 //PETER/100/56/33 - level=255

20200523-154409 701 //PETER/100/56/34 - state=ok

20200523-154409 701 //PETER/100/56/34 - level=0

20200523-154409 701 //PETER/100/56/35 - state=ok

20200523-154409 701 //PETER/100/56/35 - level=0

20200523-154409 701 //PETER/100/56/36 - state=ok

20200523-154409 701 //PETER/100/56/36 - level=255

20200523-154409 701 //PETER/100/56/37 - state=ok

20200523-154409 701 //PETER/100/56/37 - level=255

20200523-154409 701 //PETER/100/56/38 - state=ok

20200523-154409 701 //PETER/100/56/38 - level=0

20200523-154409 701 //PETER/100/56/39 - state=ok

20200523-154409 701 //PETER/100/56/39 - level=0

20200523-154409 701 //PETER/100/56/40 - state=ok

20200523-154409 701 //PETER/100/56/40 - level=0

20200523-154409 701 //PETER/100/56/41 - state=ok

20200523-154409 701 //PETER/100/56/41 - level=0

20200523-154409 701 //PETER/100/56/48 - state=ok

20200523-154409 701 //PETER/100/56/48 - level=0

20200523-154409 701 //PETER/100/56/49 - state=ok

20200523-154409 701 //PETER/100/56/49 - level=0

20200523-154409 701 //PETER/100/56/50 - state=ok

20200523-154409 701 //PETER/100/56/50 - level=0

20200523-154409 701 //PETER/100/56/51 - state=ok

20200523-154409 701 //PETER/100/56/51 - level=0

20200523-154409 701 //PETER/100/56/52 - state=ok

20200523-154409 701 //PETER/100/56/52 - level=0

20200523-154409 701 //PETER/100/56/53 - state=ok

20200523-154409 701 //PETER/100/56/53 - level=0

20200523-154409 701 //PETER/100/56/54 - state=ok

20200523-154409 701 //PETER/100/56/54 - level=0

20200523-154409 701 //PETER/100/56/55 - state=ok

20200523-154409 701 //PETER/100/56/55 - level=0

20200523-154409 701 //PETER/100/56/56 - state=ok

20200523-154409 701 //PETER/100/56/56 - level=0

20200523-154409 701 //PETER/100/56/57 - state=ok

20200523-154409 701 //PETER/100/56/57 - level=0

20200523-154409 701 //PETER/100/56/64 - state=ok

20200523-154409 701 //PETER/100/56/64 - level=0

20200523-154409 701 //PETER/100/56/65 - state=ok

20200523-154409 701 //PETER/100/56/65 - level=0

20200523-154409 701 //PETER/100/56/66 - state=ok

20200523-154409 701 //PETER/100/56/66 - level=0

20200523-154409 701 //PETER/100/56/67 - state=ok

20200523-154409 701 //PETER/100/56/67 - level=0

20200523-154409 701 //PETER/100/56/68 - state=ok

20200523-154409 701 //PETER/100/56/68 - level=0

20200523-154409 701 //PETER/100/56/69 - state=ok

20200523-154409 701 //PETER/100/56/69 - level=0

20200523-154409 701 //PETER/100/p/1 - state=ok

20200523-154409 701 //PETER/100/p/2 - state=ok

20200523-154409 701 //PETER/100/p/3 - state=ok

20200523-154409 701 //PETER/100/p/4 - state=ok

20200523-154409 701 //PETER/100/p/5 - state=ok

20200523-154409 701 //PETER/100/p/6 - state=ok

20200523-154409 701 //PETER/100/p/7 - state=ok

20200523-154409 701 //PETER/100/p/8 - state=ok

20200523-154409 701 //PETER/100/p/9 - state=ok

20200523-154409 701 //PETER/100/p/10 - state=ok

20200523-154409 701 //PETER/100/p/11 - state=ok

20200523-154409 701 //PETER/100/p/12 - state=ok

20200523-154409 701 //PETER/100/p/13 - state=ok

20200523-154409 701 //PETER/100/p/14 - state=ok

20200523-154409 701 //PETER/100/p/15 - state=ok

20200523-154409 701 //PETER/100/p/16 - state=ok

20200523-154409 701 //PETER/100/p/17 - state=ok

20200523-154409 701 //PETER/100/p/18 - state=ok

20200523-154409 701 //PETER/100/p/19 - state=ok

20200523-154409 701 //PETER/100/p/20 - state=ok

20200523-154409 701 //PETER/100/p/21 - state=ok

20200523-154409 701 //PETER/100/p/22 - state=ok

20200523-154409 701 //PETER/100/p/23 - state=ok

20200523-154409 701 //PETER/100/p/24 - state=ok

20200523-154409 701 //PETER/100/p/25 - state=ok

20200523-154409 701 //PETER/100/p/26 - state=ok

20200523-154409 701 //PETER/100/p/27 - state=ok

20200523-154409 701 //PETER/100/p/28 - state=ok

20200523-154409 701 //PETER/100/p/29 - state=ok

20200523-154409 701 //PETER/100/p/255 - state=ok

OH CGATE Thing:

/* Need a cgate bridge to connect to cgate and then 1 network bridge for each network on that system */

Bridge cbus:cgate:cgatenetwork “file - cgate” [ ipAddress=“192.168.1.54”] {

Bridge network cbusnetwork “file - network” [ id=100, project=“PETER” ] {

/* Things can be configured within each network bridge */

Thing light light4 “light 4” [group=4]

}

}

/* Things can be configured separately and associated with the network bridge */

Thing cbus:light:cgatenetwork:cbusnetwork:light31 “light 31” (cbus:network:cgatenetwork:cbusnetwork) [ group=31 ]

Thanks
Rod

2

Personally i tend to use the discovery within paper ui rather than defining things manually. But if you prefer manual configuration then you can do it using the things & items files, but its easy to make mistakes that way.

Given that output all the 100/56/* items are lights and should be discovered.

For the error can you copy paste the log file section. I am not sure where the error is coming from but it suggest the group value is wrong somewhere.

For more debugging increase the log level for cbus plugin
in Karaf console
log:set TRACE org.openhab.binding.cbus

3

John,

Thanks for the prompt reply, I will try enabling that extra debug level on the weekend. Discovery via Paper IU is not working (even when forcing a search) which is part of query.

Some more background, this has been a project for some time, long before 2.5.4 supported the CBUS binding natively so we had installed the earlier version of the binding via the AddOns process. Since adding the new binding via Paper, we have had an issue with two versions of the binding being installed even after deleting the file from Addons and uninstalling the Bundle via Karaf. At next reboot the old binding would be installed again. I think (?) we have resolved this by removing from some cached version of the file stored outside of Addons.

It appears the binding is receiving the messages from CBUS OK, but is failing to send the commands back, hopefully the detailed logging will give more insight, and how this relates to the Group number issue.
Can you please confirm on your network that group number is generally the same as the last digit eg //PETER/100/56/4 ?

Noted: I will attach logs as attachments and not include in the post (This was my first forum post)

4

@galileo
Yes clearing shutting down openhab & clearing tmp & cache in the openhab installation would be a good idea and then restarting.

The addresses are of the correct form
//PETER/100/56/4
gives:-

PETER is the project name
00 is the network address of your cbus network
56 is the application which is lighting
4 is the group number

Where possible copy complete sections of log files and complete config files then it is much easier to possibly see something wrong.And where you have log files or content of files pasted in the message use the code fences to separate them, it makes it much easier to read. See How to use code fences

Thanks

John

6

John,

As suggested I increased the logging level on the CBUS binding and repeated a series of tests.

Status Summary:

  • Auto discovery of CBUS things doesn’t work (Any thoughts on why?)
  • cgate & network bridges appear to be online
  • light4 thing shows “Offline - Configuration_Error” - No Group Object available
  • it appears physical CBUS light changes are being sent to OH, Thing/Item status change to reflect this
  • Attempts to use PaperUI Control for the Thing or by using an Item to change the CBUS state all fail.

OH Log & Event log (With Comments) + Thing / Item configs attached

I think the problem appears to be a “Thing” config issue. I am currently trying to use “method 2” for thing configuration, but find the example confusing due to the differences in syntax between the first and 2nd half of the line. This extended thing syntax is not covered in the general OH Thing documentation.

From CBUS Binding Documentation:

/* Things can be configured seperately and associated with the network bridge */
Thing cbus:light:cgatenetwork:cbusnetwork:light31 "light 31" (cbus:network:cgatenetwork:cbusnetwork) [ group=31 ]

P.S. It took longer to get these logs than I expected. Also I am hoping this and any response will help Matt S. who sounds to be having similar issues with the “Thing Syntax”

Thanks
Rod

CBUS_OHLogs.txt (3.7 KB) CBUS_items.txt (276 Bytes) CBUS_OHLogs.txt (3.7 KB) cbus_things.txt (668 Bytes)

7

Thanks for the logs. I dont see any openhab logs for the initialisation part when the network is initialised and the thing created for the light.
I would expect to see some debugging from CBusGroupHandler with things like
Using Configuration …
getGroup() …

Also if autodiscovery isnt working then logs for that would be useful.

That should include logging with
Found group …
or
Failed to discover groups …

Thanks

John

8

John,

As a test I tried adding a static thing using “method 1” nested under the bridge with the same error “No Group object available”

Thing light light6 "light 6" [group=6]

I then tried both a Discovery from the binding in Paper UI, and then restarted OpenHAB service and captured the logfile after booting (see attached).
The common issue seems to be the following:

2020-06-21 16:41:31.443 [DEBUG] [inding.cbus.handler.CBusGroupHandler] - getGroup() Cant get application for id 56
2020-06-21 16:41:31.445 [DEBUG] [inding.cbus.handler.CBusGroupHandler] - Set state to configuration error -no group

Without the extra TRACE debugging on, OpenHAB points to a “Group” config issue, but with the extra debugging it now points to an “application” issue.
Another friend installed CGate and configured the CGate project. Does this indicate a CGate configuration issue for the lighting application 56 ?
If so what should I check ?

Thanks Again
Rod

cbus_log200621.txt (12.9 KB)

9

Matt,

If you see one of my later posts, I attached a CBUS.things file, but the configuration is still not working.

John Harvey has been trying to help me, and is currently trying to confirm why Auto Discover is not working. If you haven’t tried it already I suggest turning up the binding logs in Karaf Console then checking the OpenHAB.log as it give extra useful information.

log:set TRACE org.openhab.binding.cbus

I saw your name on one of the older post, so I suspect you know way more than I do about this already, but I will post something when it finally works.

Regards

Rod

10

@galileo Yes there is a problem getting the application which then means it cant get the group.
There is some debugging we can turn on in the underlying library which talks to cbus which will display the responses the code is getting. Can you turn that on wiht

log:set DEBUG com.daveoxley.cbus

Then send me the logs. If that doesnt show us what is happening then i may get you to try to talk directly to cgate and send it some commands and let me see what it responds with or i will add some more debugging to the binding and let you try with that.
I dont think you have done anything wrong with the configuration.

John

11

John,

Here is a openhab.log logfile containing both cbus debugs after an openHAB service restart.
There was a light manually turned on/off towards the end of the log.

Thanks again for all your help.

Rod

cbus_log200623b.txt (26.4 KB)

12

@galileo
The problem is that your cgate appears to be missing the configuration completely for the network.
So i am guessing that this cgate installation is not the one you would normally use to manage the cbus network (ie when you run c-bus toolkit).
In your case this configuration file is stored in the file tag/PETER.xml within the cgate installation.
If you have a saved copy of the original version of that file somewhere then copying it to replace the current file should work.

If you don’t have the original version there are ways to re-create it. I think connecting to this cgate from c-bus toolkit may do that but i can try to work out the commands for dumping the information from the network.
I hope this makes sense. I suspect in the past that configuration may have been done from another computer.

John

13

John,

Thanks for the advice. The House was purchased with CBUS but without a computer interface of any sort. The interface was added for this Project. I am not sure if CGate toolkit has ever been used, and CGate was installed on the same RasPi as OpenHAB.

A manual config of CBUS Profile “//PETER” was done by another friend using CLI commands from a forum (not known to me).

I have done some manual CBUS commands from CLI and attached a log file to see if that helps. Do you have any recommended CGate CLI references to setup a “standard” profile.

Thanks
Rod

cgate_log200624.txt (6.1 KB)

14

@galileo
Really the best way to do this is to use the cbus toolkit.
It can be downloaded from the cbus software site but it needs to run on a windows pc.
In there create a new project, scan the network. Select all the devices and transfer to the DB and you should be done.
Then everything should work.
I have seen one thread that suggests you can do it by hand but that doesnt do everything and this thread https://www.cbusforums.com/threads/c-gate-and-cni-noob-inside.6150/ strongly recomends not doing it and doesnt list all the commands needed.

15

I agree with John,

Download the cbus toolkit, get everything in order on there and then control it with Openhab and Alexa.

I’m always happy to help

Cheers
Matt

ps i’ve got all the things and items files sorted now, i didn’t realise there was docs on the openhab website.

16

Ps I have cgate and openhab running on the same raspberry pi. Probably a better idea if you want your pc ‘always on’

17

John,

I installed CBUS Toolkit with CGate on a windows laptop connected to the CBUS serial interface, and was able to do what you suggested but I believe the current problem is that the database is now stored on the laptop CGate and not the RasPi CGate install. I was only visiting my friends house so I didn’t have time to organise a known IP that was added to the RasPi CGate Access.txt file. So I guess my next question is which files would I need to transfer from the Laptop CGate installation to the RasPi CGgate installation? just applications.xml ? and cbusunits.xml ? Or is it all too hard and I have to repeat using the actual CGate install involved?

P.S Thanks to Matt too for his thoughts.

Thanks again
Rod

1 Like
18

Within the tags directory of the cgate installation there should be a file project_name.xml. That is the one that needs to move to the pi cgate installation in the same directory.
It does have information about how the project connects to cbus. So if that is different between the PC & the pi then that would need fixing. You could copy the appropriate settings from your existing peter.xml file that would be in the tags directory on the pi if you feel comfortable editing the xml. It is near the top where it defines the network & interface:-

 <Network><TagName>Local Network</TagName><Address>254</Address><NetworkNumber>254</NetworkNumber><Interface><InterfaceType>CNI</InterfaceType><InterfaceAddress>192.168.1.5:10001</InterfaceAddress></Interface>

That should work but if not then connect to the cgate on the pi.

Hope that works ok.

John

1 Like
19

John,

Thanks for the advice again, here is the latest update:

I merged the CGate file with the network statement from the previous file and also changed it from network 100 to 254, and things seemed to really improve.

The discovery appeared to work for the first time and found a “CBUS Group – Lighting Group” for each light OK, see attached: CBUS_DiscoveryLogs_200712.txt (165.1 KB)

There was some data related to network 100 which was later removed.

I then removed the CBUS thing static config from the previous attempt, and then checked the status of the discovered “things” and found they were “uninitialized”.

While checking I also noticed the Paper-UI “Scan” button for CBUS binding was no longer available, which led me to believe there was a problem with the Binding, so I removed the Binding, and cleared the “OpenHAB Cache” and then reinstalled the CBUS binding.

The binding “Scan” button did not re-appear after the re-install, I also removed/re-added the debugging to confirm it was still active. But I am no longer seeing any debug output such as the “com.daveoxley.cbus.Response “ or “inding.cbus.handler.CBusCGateHandler”.

Is it normal for the “Scan” function to work in the Paper UI ? If so why would it not appear ?

I suspected there was another problem with the CGate config, so I did some configs to confirm the network config was correct, see attached: CBUS_Peter200801.txt (5.9 KB)

So I am confused if I have a CBUS config issue or an OpenHAB issue again, any further thoughts are appreciated.

Thanks
Rod

20

Yes. I regularly use the scan functionality in the paper UI ,Not sure what you mean by the Scan button did not appear. It should show up in 2 ways (leading to the same thing). Either go to Inbox and press the + or Configuration->Things and press the +. That should take you to a page title Inbox-Choose Binding and should list all bindings that you can scan. That page should list “C-Bus Binding”.
If it doesnt appear here and nothing shows in the logs then i suspect the binding hasnt been installed properly. Maybe stop openhab. Remove a log file. Clear the cache and tmp directory. Restart openhab and attach the complete log file in case i can spot anything there.

21

I forgot to clarify, that I do see the CBUS binding using either of those two methods, but nether have a Scan option only an add function but this is normal. The a Scan option is normally only available from Paper UI Inbox, then the Scan icon is in the Top RHS.
As an experiment even though I don’t have CBUS at my house I installed the CBUS binding on my own OpenHAB install and I get the same result (no Scan option), so maybe the option only appears if there is some connectivity to CGate. If this is the case how can I do a basic connectivity test to see if OpenHAB/CBUS Binding can still connect to that IP/Port ? (As I no longer see the Ping debug that was there originally)

This is the Network line in the Cgate config:

<Network><TagName>n254</TagName><Address>254</Address><NetworkNumber>254</NetworkNumber><Interface><InterfaceType>cni</InterfaceType><InterfaceAddress>192.168.1.54:10001</InterfaceAddress></Interface>

Thanks
Rod