Hi,
I know that “CAN bus” come earlier several times hence I would like to announce that as part of activities we made in (connectorio) we ended up having a generic purpose CANopen binding. There were several attempts to get CAN bus working with OH 1.x but all of them didn’t pass to OH 2.x and most importantly 3.x. What I began working on is currently aimed only to OH 3.x.
Given that CANopen is popular in several fields I hope that it will simplify any integrations you have with that protocol. Because CAN has multiple flavors and ways to interact with I must limit supported operating systems and drivers to only one - Linux and SocketCAN. In order to use this binding you must have compatible socketcan dongle/or shield.
If you come here then please speak what kind of device you have and how you currently read its data. If you have any technical documentation (EDS) then we can have a look of what objects are needed to get it working.
As part of activity we developed a generic purpose canopen library which is part of Apache PLC4X. Library supports support SDO/PDO/NMT/TIME communication.
It is so far used by us to interact with some of TA hardware. Sadly TA does not use canonical canopen protocol (it does not publish any SDO/PDO descriptors available through electronic data sheet) making it pretty hard to use generic functionality of canopen binding. So binding is layered in a way which allows to implement custom discovery participants (just like modbus and bluetooth do) to pick most accurate thing handler.
Quick set of requirements:
Linux
openHAB 3.x
socketcan enabled interface
Available binding functionality: Discovery of CAN interfaces (only gs_usb and vcan). Discovery of CAN open nodes based on heartbeat broadcasts. Receive and send PDO handling Polling of SDO indexes SDO write
Binding is an experimental work. Confirmed to work with simulators and real hardware (the communication library). Binding is available on separate download page after registration. Source code is available in connectorio github repository: connectorio-addons.
I downloaded your binding today as it seems exatcly what I need to connect my UVR610 via CAN.
The socket CAN bridge binding and the generic CANopen binding are loading and are identifying my UVR610 as node 32. So far so good.
Sadly the specific TA binding is not loading and complaining about missing dependency once a minute in openhab.log.
Hey @jaghatei,
Binding is not yet ported to openHAB 3.1, thus it works only with openHAB 3. Our production deployments are not yet moved to OH 3.1, hence I did not invest much of time in migration activities.
Reason why CANopen binding works and TA doesn’t is simple - the CANopen part does not do anything with quantities and units which are extensively used within TA controllers.
With regard to KAR. Sure, I will make a new build since there are several stability improvements you noticed. Not sure when, but will let you know as soon as I get it so you can test it further.
Would OH 3.x work for you, or you are already bound to 3.1?
yes with OH 3.0.2 the binding is starting.
Binding Snapshot 3.0.0 does not include UVR610, so I am running the binding as a UVR16x2.
Current status: Its failing in CAN communication due to “login error”.
I need to have a deeper look into for the reason.
There are several reasons why you could get “login error”. TA firmware is very sensitive to parallel requests. If you have a discovery + handler working at the same time it will likely happen. The discovery and initialization of handler read some addresses (via SDO). This makes controller throw an error if both happen near by.
I haven’t solved the trouble yet. The most recent binding version I use do not run TA discovery participant. Anyhow, will do new build for 3.0.x and let you test a new version.
Currently not. J1939 is different flavor of CAN. It uses 29 bit identifier (CAN 2.0b) where CANopen uses 11 bit (2.0a). Physically they’re same, most of nowadays CAN controllers can handle both. Socketcan and Javacan library which I used for binding is capable of handling that, however this is just beginning. It is still necessary to build basic protocol (message exchanges) to make sense out of communication which takes place.
This summer I did prepare some basics for “generic can” binding which allows to receive/send single frame of 8 bytes of data but I could not finalize it yet.
For now you will definitely have better luck with CANopen. You need to map SDO structures or PDO broadcasts based on equipment documentation. Support for object dictionary (EDS files) is non existent hence mapping happens through UI or openhab config files.
I cannot change to CANopen because cars are fixed at J1939. But I understand all about the CAN so
I will try to make a J1939 CAN to MQTT bridge on an Arduino or ESP32 If it works I will post here. Might take a month or two.
I get that. Depending on how well you fill with Java/Scala you can give a try to GitHub - pschichtel/obd4s: OBD library for Scala. This library can utilize socketcan over javacan bridge I mentioned earlier (its the same author), it also has support for “elm” transport. It does implement obd protocol so you can see if standard can 2.0b socketcan compatible dongle will fly.
Coming back to this fairly old topic with an inquiry to all interested parties. There was some work related to dependency updates in this binding. Since I’ve ran into some troubles with OH 4 build I would like you to register ticket “Support canopen for openHAB X”. Other people can vote tickets up in github: Issues · ConnectorIO/connectorio-addons · GitHub.
For X pick openHAB version (3.0.x, 3.1.x, 3.2.x, 3.3.x, 3.4.x, 4.0.x) of your interest.
Discovery of CAN interfaces (only gs_usb and vcan).
SDO write