TACMI / Technische Alternative / TA C.M.I. Binding Upgrade to 1.xx -> 2.xx

Hi Community,

A friend asked me if I could help him to connect his TA C.M.I. system with OpenHAB. As we had some issues with the v1 plugin and he intended to do most things via GUI instead via the text files I started porting the legacy 1.xx binding to OpenHAB 2.xx binding standards.

A pre-build version is available here: https://github.com/marvkis/openhab-addons-dist/raw/master/org.openhab.binding.tacmi-2.5.8-SNAPSHOT.jar

This binding should provide the same functionality as we had in the 1.xx binding. Please also read the updated binding readme from here: https://github.com/marvkis/openhab-addons/tree/addon/TA-CMI/bundles/org.openhab.binding.tacmi

Never the less after studying the TA System’s possibilities I have some more ideas instead only building a bridge for transferring the CAN-Bus values - It might be possible to give access to far more data readings and also changes configuration values via the TA’s Designer application. If somebody is interested in working out details of the idea please drop a message. Also just testing the current version and providing feedback would be nice.
I currently don’t own a own TA Setup, but i’ve remote access to a demo setup provided by my friend’s employee, never the less I also thinking of buying one for ourself…

Never the less, discussion is open :wink:


Hi Christian,

that sounds great.
My special interest is to send data from OH to TA devices, e.g. room temperatures acquired by non-TA thermostats.
Furthermore linking a PV battery to the TA system via Modbus would be great.

Will do some test on your build the next days.



Hi Bernd,

sending values from OH to TA should be possible with the current features of the binding. I had a ‘remote’ UVR16x2 to play with and I’ve prepared the programming for my TA (which i installed last weekend) by sending all sensor readings from my old heating controller to the UVR via OH. So the UVR was running by the ‘CAN Inputs’ instead of real sensors and it worked quite well.

So sending the room temperatures to the TA should be possible. But regarding the TA Modbus possibilites I have no glue… I never had a look into it. Do you have the battery in OH?
What do you expect from connecting the battery to TA?


Hi Christian,

regarding the integration of the PV battery I was successful meanwhile. By accident the battery’s Modbus (Slave) is talking with the CMI (Master).

On the other hand I was encoutering problems with the new binding, but it seems to be a problem with the latest firware (1.37.1) of the CMI, as the old binding stopped working, too.

Nevertheless I have some questions about the confuguration of the new things file:
As noted in the CoE documentation you need to define a node for an external device for the CAN output (OH -> CMI) in the CMI settings. How do I handle this in your new binding? And how is an item (for example the temperature value given by a thermostat) being defined in the items file?
The Output-Ids are according to the numbers of the CMI-Input list, if I am right?
And for better understanding, for outputs the node on the TA side is the one of the desired device (in my case CAN1 for the UVR16x2), not the one of the CMI, isn’t it?

Maybe the easiest way would be a full working example, then I would figure out the rest by myself.

Overall I am extremely grateful about your work, since the OH1 bindings will face end of lifetime with OH3 release most likely.


Hey @marvkis, you made your work in perfect moment :+1: , as @BKatBruck pointed - to save CMI integration get lost when OH3 is out! Turns out that OH is one of very few available systems which used to interface with this gateway.

The first part is definitely an interest of mine - to get the first class handling of CAN frames without making it dependent on specific gateway device. CAN is yet another format for transporting data with plenty of flavors. From what I understand CMI frame format is in line with CAN over Ethernet (or CANopen?) hence CMI functions as one of available hardware plugs to get it on the openhab side.

I’m working on getting access to CMI gateway as well as CAN infrastructure so I could test your stuff. Its gonna take a bit, but once it is in place you can count on our test. I’ve found cheap CAN/USB adapter which I would like also to test while working on transport layer.

I planned to use PLC4X to describe frames and create basic client which could parse and serialize messages. I saw that old binding uses quite basic parser to get I/O done. While it works it locks support for making further improvements.

WRT CMI device itself - I saw they have JSON api, their system is also equipped in web server. Its possible to fetch inputs and outputs via json, not sure of configuration. Anyhow we could figure out if there is a way to push CAN settings for data points requested by OH (this is just an idea). It would require OH user to know CMI user and password, yet this function alone simplifies setup for less skilled users.

Anyhow, looking forward to support you on CAN side, CMI binding as well as testing. :slight_smile:

Hi Bernd,

good to hear this :wink:

I’ve just double checked with my system and CMI 1.37.1 and it seems to be working. I see analog measurements from my UVR in OH and also can send OH-Values to the UVR - so maybe it’s a configuration issue?

Okay. Let’s take your questions and samples to improve my documentation :wink:

I’ve given some (OH)-Samples in the plugin’s readme.md in my PR , visible here https://github.com/marvkis/openhab-addons/blob/addon/TA-CMI/bundles/org.openhab.binding.tacmi/README.md

In my sample, I have the C.M.I. With ID 1 (somebody told me it’s a good idea because ID 1 is used as time source and the C.M.I. does a good job there) and my UVR is ID 4.

When sending Data from OH to the UVR I do this by sending the data to / from a ‘virtual’ UVR device and using it’s address as Input on my UVR.
In our exemple lets use the ID 54 for virtual OH-UVR.

To define it in OH we create the thing:

Bridge tacmi:coe-bridge:coe-bridge "TA C.M.I. Bridge"

    Thing cmi cmiTest "Test-CMI"@"lab" [ host="", node=54 ] {
        Type coe-analog-out : analogOutput1 "Analog output 1" [ output=1, type=1 ]

And the Item:

Number TACMI_Analog_Out_1    "TA output value 1 [%.1f]" <temperature> {channel="tacmi:cmi:coe-bridge:cmiTest:analogOutput1"}

Values sent to the OH item TACMI_Analog_Out_1 are sent (via the C.M.I.) to Node 54 Output 1 on the CAN bus. Currently there is no device there, but any other device on the CAN bus can define an CAN-input listening on our ‘Virtual OH’ Node 54 / Ouput 1 in Tapps2:


You can also see the current values on the CMI by accessing http://<your-cmi-ip>/#status_coe.cgi

The way UVR -> OH is a bit more complicated as we have to define a ‘relay’ for the value on the C.M.I.

Lets start with the Output in the UVR - Just create the CAN-Output via Tapps2:

Now, we have to define a listener on the CMI:

And configure the forwarding as COE value to OH. I Noticed this doesn’t work when the C.M.I. is set to english, this is why I’m posting a german screenshot here. When the C.M.I. is set to english no COE items are listed… Seems to be a bug.

This sample assumes is our OH IP.

Now we can define the CAN-Input on OH in our thing:

        Type coe-analog-in : analogInput1 "Analog input 1" [ output=1 ]

Define our Item:

Number TACMI_Analog_In_1     "TA input value 1 [%.1f]"  <temperature> {channel="tacmi:cmi:coe-bridge:cmiTest:analogInput1"}

And we have the CAN-Reading in OH.

I hope this sample explains all configuration steps required.

When you have suggestions how to improve the readme for improved understanding just post them or better send me the suggested changes so i can put it in the readme :wink:


Hi Łukasz,

Okay, you are talking about an interesting option, but currently I wasn’t talking about directly attaching to the CAN bus. The C.M.I. has an UI where graphical interfaces can be designed and there are quite more options to interact with the devices than just sending some measurement values. I’ve discovered these pages are quite systematic so they could easily be parsed and controlled via an OpenHAB binding - so this is the current goal with my current binding.

Never the less I also have some CAN interfaces and even a CAN monitor where i want to build something allowing me to read some status details from my CAR. I want to know the battery levels so I can plan the charging time / energy needed - but this is a different story and a bit out-of-topic for the this binding :wink:

What I understand is that your goal is to build some kind of a generic CAN interface for OH. Interesting Idea and as you seen I also would have some use cases, but this is a project for later when the TA stuff is done (and also all non-OH things related to the TA project :wink: )

When you have some Threads / Wiki’s collecting Ideas / Concepts just PM me the details and I have an eye on it and jump in later when I have some time left for the CAN stuff :wink:


Hi Chris,

sorry for the late reply. You want to let you know that your explanation helped me a lot - at least for the CMI -> OH direction. It works without issues.
I haven’t done the part OH -> CMI part so far.
Just one more question for a better understanding for the OH->CMI part:
Instead of defining a CAN-INPUT directely in Tapps2 I want to define it in the CMI Input section - just to be more flexible in case of any changes. From there it could be forwarded to any other device in the TA network. Does this work the same way as the way you described?



My access to CMI gateway with OH next to it was granted and I am able to inspect infrastructure. Sadly I have no password to controller behind CMI so I can’t map its IO to CoE yet. I’ve found over JSON api that there are 5 inputs and 4 outputs with no indication how these map to CAN. From walk through over UVR user panel I’ve just found that IO is defined in DL-BUS and not CAN section.

With regard to code - I made my attempt to update binding to openhab 3.0, it seems to start properly.

My point with CAN frame parsing is really to make sure that handling logic is in line with https://en.wikipedia.org/wiki/CAN_bus#Base_frame_format. From what I see in code, especially in Message class constructor identifier and pod number does not take into account bit lengths (CAN node id according to Wikipedia is coded using 11 bits). If that’s the case binding omits some chunks of data in remaining payload. Again, I didn’t touch real payload yet so probably I am wrong.


Hi Bernd,

Thanks for the feedback. That is great :wink:

AFAIK it is not possible to define something like a Network base CAN Input on the C.M.I. The data received via CAN over Ethernet is directly relayed to the CAN bus by the C.M.I… To work with the input data sent from OH -> C.M.I. a CAN-Input has to be defined on a CAN-Bus (UVR / … ) Device directly.


Hi Łukasz,

You’ll need to get the ‘programming data’ of the UVR to import it to the TAPPS2 software to have quite an good overview what is programmed and mapped. I Assume quite everything could be done via the UVR’s display, but its laboriously so you won’t do that this way. More over when you change something manually and the operator of the devices installs a modified version of the programming everything you have changed manually gets lost…

Good to hear. Thanks for the Feedback :wink:

Okay, I also haven’t touched the real CAN bus yet and also haven’t double checked the protocol with the standards. It also seems what we see here in the CoE frames is only some basic things TA is making on it’s CAN bus. When you have full access you’ll see that you could get access on quite everything on the UVR or whatever devices are connected to the CMI via the CMI’s web interface - so it’s assumeable they are sending quite complex information via the CAN bus.
During the implementation of my setup I also came to the conclusion that there are a lots of things I want to map to OH that are not easily controllable via CoE-Inputs. TA offers a software called ‘designer’ on its page (https://www.ta.co.at/en/downloads/software/) which allows you to map quite everything to a html page. And the pages generated with this designer are quite systematic and this way good parsable. Currently I’m working on a new variant of this plugin also allowing to parse these - lets call them API Pages created by the designer. I’ve already made quite good progress with it - the main thing still missing is the documentation…


Hey Mark,
Great hearing you back and thanks for tips. I will need to get my windows virtualbox setup back in order to test CMI software. :slight_smile:

The manual way with UVR is really what I ended up doing this Friday. Irritated by slow (or rather lack of any) response from technician I started looking for default passwords. I ended up clicking through UI and exposing DL-BUS inputs as CAN outputs from UVR, then making these inputs on CMI-CAN and mapping these to CoE outputs. So far I have only outgoing path covered, but that’s all we needed for now.

While looking how the UVR pages looked a like and how values are sent to CMI I presume there is a way to get that covered without CMI, as you said - directly through CAN. HTML pages pass a register number in the URL, so that’s at least starting point. The rest is really mapping designation options to proper byte values. This wouldn’t be that far from most of traditional modbus devices where all you need to know is register number and how to write/read data from it. :slight_smile:
The really interesting part is that CMI somehow is able to deduce I/O configuration from controller so there is an additional part which goes directly via CAN. It is relevant to eventually script eveyrthing over (I wouldn’t really want to setup each and every controller manually).

I suspected that after looking at comments in old code, one indicating that CMI sends only kilowats and temperatures. Yet on Friday I managed to get flow rate which failed to pass parsing logic on binding side. This might be a mark that it could be a bug in earlier versions of CMI firmware. My assumption that it could be caused by data encoding differences turns to be wrong. I will patch binding to support that and also check if time is reported properly. Then will try to get support for QuantityType on OH side to pair incoming data with units of measures.

Sample system I got access to has 2 or 3 circuits including solar one and visualization shows ie. working time of pumps. I deduced it is possible to map these by mapping function to an output and choosing particular chunk of data - not an pump state, but its run time. Yet amount of clicking and hard limit of 64 outputs on controller will quickly block possibility to do anything more.

Looking forward to play more with TA systems as these look really, really nice and flexible.


Yes indeed - they should really offer all their software for other platforms. For TAPPS2 there is a linux variant, but not for the Designer… :frowning:

Okay, so it seems you have reached a goal :wink:
Maybe an other hint: Depending which UVR device is installed - the ‘bigger’ systems have a SD-Card. Maybe you can get the compiled logic (a .dat file) from this SD-Card. It can be imported back into TAPPS2 but you have to sort everything again. I havn’t tried it, but maybe you can read the password from these imported settings (via File / Settings / Device Settings - don’t nail me on the labels, tried to translate my german version into english)
Or maybe the .dat file is just still laying around on the C.M.I. form the last setup upload and downloadable from there :wink:

Yes, but it might be very extensive. As long as you don’t have quite a bunch of same setups, i think it’s a very hard work. Especially when you change things in the programming of the CMI the nodes in TAPPS2 could get renumbered resulting in different addresses on the CAN bus. I played around wit the designer a bit and it seems the designer gets this sorted out. After changing the programming I often have some Old/Non-Matching values on my ‘API Page’ . But after importing the new .dat-file again into the Designer, the designer seems to sort out everything, fixes the CAN-Addresses and as soon as the new pages are uploaded everything works again as expected.
So without the help of the designer it might really be a hard job…

Okay, I haven’t played around with metrics via the CoE-Plugin yet. I’ve also seen the notes.
But for the ‘new’ schema-API-Page variant I’ve already created some metrics for some units. I just did a WIP-Commit with all my local changes. The metrics stuff currently sits here: https://github.com/marvkis/openhab-addons/blob/addon/TA-CMI/bundles/org.openhab.binding.tacmi/src/main/java/org/openhab/binding/tacmi/internal/schema/ApiPageParser.java#L331
There are some discrepancies in the metrics used in OH and by TA, i.e. flow rates are given in liters/hour in TA and liters/min in OH so some calculations have to be done. So maybe it would make sense to create a TA Metric enum mapping all TA types with their ID’s (CoE-Value ID’s) or units (from the Web-UI) to the proper OH types including the required conversions…

I also stumbled on the limit of 64 outputs. This was the next reason why I started with the ‘API Page’ concept.

Yes, especially in terms of controlling Things related to heating they are very flexible and powerful. But they also have some limitations - but these things easily could be done with OH. My Idea is to do something like a ‘Forcast Planning’ in OH on the weather reports and do tings like pre-heating / increasing the floor temp’s when i have a sunny day today and tomorrow not. Also depending on the load levels from the buffer and so on…



I’ve just updated the binding. It now supports a new schema API Page variant. Also the documentation is updated. The links are:
Documentation: https://github.com/marvkis/openhab-addons/blob/addon/TA-CMI/bundles/org.openhab.binding.tacmi/README.md
Download: https://github.com/marvkis/openhab-addons-dist/raw/master/org.openhab.binding.tacmi-2.5.8-SNAPSHOT.jar


I tried this TACMI binding on open HAB 2.5.8. I want to test it and use it like http-binding with a BL-NET.

I can see in log-file that this TACMI can reach the UVR1611:

2020-08-30 15:11:34.603 [INFO ] [.tacmi.internal.schema.ApiPageParser] - Invalid format for setting pos4:14:1 [ReadOnly] :


2020-08-30 15:11:34.604 [INFO ] [.tacmi.internal.schema.ApiPageParser] - Invalid format for setting pos5:16:4 [ReadOnly] :
2020-08-30 15:11:34.604 [INFO ] [.tacmi.internal.schema.ApiPageParser] - Invalid format for setting pos6:18:9 [ReadOnly] :
33,0 °C
2020-08-30 15:11:34.605 [INFO ] [.tacmi.internal.schema.ApiPageParser] - Invalid format for setting pos7:20:9 [ReadOnly] :
33,2 °C
2020-08-30 15:11:34.606 [INFO ] [.tacmi.internal.schema.ApiPageParser] - Invalid format for setting pos8:22:9 [ReadOnly] :
42,3 °C

on other page I read the explanations for UIVR16x2 configuration but here it looks a little bit different to prepare a “Schema API Page” in CMI in TA-Designer. I do not find the correct objects. Maybe you can explain a little more detailed how to create in TA-Designer this objects.


sorry for this stupid questions.

hmm… intresting…
I think we have to dig into it a bit. Would you mind to PM me the Designer config files so I could have a look on it?
Maybe also the output of curl -v -H "Accept-Language: de" -u user:pw http://<cmi-ip>/schematic_files/<page-id>.cgi - so I have an output of the page to analyze…

Do you also use toe CoE or just the schema thing?


yes, I would like to send PM to you. But where to send PM?

you can reach me at gmx.de

Coming back from long journey of CAN hardware adapters I can bring some “light” to the java-can-canopen topic. I’ve spent last couple of days reading about CANopen which is used under the hoods to communicate values. Limitation of “virtual” inputs and outputs likely is inherited from it.

From more positive things - I’ve been checking if navigation over CMI preview of UVR controller makes any traffic on the bus… it does and amount of exchanged data in some cases is significant. Each screen gets drawn from couple of registers exposed by UVR. This means that discovery can go over CANbus.

I did not identify yet any of frames which are exchanged, some of them are described by TA. Will try to share something in coming weeks.

Congratulations for binding merge @marvkis!

Another update from my end… given that I could not get any documentation about how to read input/output configuration from UVR I started digging around.
I’m working now on mapping UVR registers and CMI pages together. If I will ever complete this then it will be possible to read all names of configured input/outputs (ie. “Flow temperature”) directly from the controller.

Not sure if that makes any impact on the binding code, but by proper sequence of calls (can/canopen sdo requests) it is possible to read entire configuration, and not only inputs selected for visualization. If you will be able to configure CoE in CMI then same should be possible via UDP.