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

I wanted to let you know on progress using direct CAN access. I am able to discover inputs/outputs and their names without CMI. There is also a possibility to discover functions, based on what I found in a very handy can-uvr project.

See attached screenshot:

You can look for sources here https://github.com/splatch/canopen-cmi-uvr-playground (reader project). As promised I also made an CMI crawler which you can find in above repository. Crawler is console program which simulates web browser, collects, formats HTML output on one end and taps CAN traffic on other. It can be easily modified to work without later just to collect all information from system.
For my test setup there are ~400 html pages.

I haven’t got enough of time to look closer on UDP traffic coming from CMI. After checking device configuration options it seems that each and every input/output must be mapped from UVR to to CoE.

Update 5th December 2020:
I am re-activating topic since I got “raw” CAN access sorted. Thanks to repository mentioned above I was able to build complete binding (see connectorio-addons) which rely on canopen to interact with TA devices.

The python client I used as reference listed below units:

At least for flow rate (index=3) and kWh (index=11). I can confirm it is mapped properly in my test installation. For now I am running both my binding and cmi next to each other to compare results.

If anyone is interesting in giving a try I will publish binary build. Binding currently detects only outputs.
To get started you need to connect your installation via CAN/USB adapter with socketcan compatible driver.
I used dongle from here: https://ucandevices.github.io/uccb.html, but any of adapters listed here should work: https://github.com/candle-usb/candleLight_fw.
If you can pick one with galvanic insulation and terminator switch.

Hi Johannes,
could you solve the problem with your BL-NET?
I have a BL-NET too, but can not find the example Schema file.

Hi @Barnecke ,

i’ve digged into the BL-NET files from @Johannes912. The ‘Problem’ was that the files have been ‘handcrafted’, but the plugin relies on the format generated by TA’s schema designer. Maybe the easyest approach would be to create a file with TA’s schema designer and use the .CGI as template for the BL-NET. When I remember correctly this solved the issue.

Bye,
Chris

Hi Chris,
thx for quick response, but I’m a little bit confused. To the BL-NET I can only upload a .html file, but no .cgi file.
I create a new layout from scratch with TA-Designer as described. When create a page for “BL-NET” the TA-Designer only creates a .html file. When I create a page for “C.M.I.” the TA-Designer creates .html and .cgi file, but with memory manager I can only upload .html to my BL-NET.

Any additional hint?
best regards
Björn

Hi Björn,

I reviewed the communication with Johannes, and it seems I mixed some things up in my mind. I tried to reconstruct it and it seems the story was he migrated from BL-NET to C.M.I… When I got it right the trouble was caused by trying to migrate the BL-NET files to C.M.I…

I don’t have access to a BL-NET, but I had a quick look on the documentation and it seems BL-NET is completly different compared to the C.M.I… I fear the binding will not be able to work with the BL-NET…

Sorry,
Chris

Hi Chris,

thx for analysis. I did the same and it looks like, that http-binding is the only way to extract data.

I started testing http-binding with regex profile.

regards
Björn

I need a tip from you on how to program UVR. I would like to have possibility to receive and also set room setpoint. Trouble I have is that the setpoint is controlled via room control unit (one with sliding switch and regulator) which is distinct from CAN input controlled by openHAB.

The end result is that I have two inputs which should be linked to
“set room temp.” argument for “individual room ctrl” function. Any suggestions from UVR masters? :slight_smile:

I just made a test with “logic function” to show what I have on the drawing.

Best,
Łukasz

Hi Łukasz,

the ‘complicated’ thing with the RAS-DL Sensors is: they add temperature offsets to the temperature depending on the selected mode by the hardware switch (there is no extra connector for this).

From the guide:

The signal reported at the controller corresponds to the room temperature changed using the rotary knob. The following signals are forwarded to the controller according to the switch set- ting:
• Automatic mode = Room temperature +/- inverse rotary knob
• Normal mode = Room temperature + 50°C +/- inverse rotary knob
• Lowering mode = Room temperature + 100°C +/- inverse rotary knob
• Standby mode = Room temperature + 150°C +/- inverse rotary knob

So doing things with the values is not easy… I don’t own one of these sensors, so I have no experience with it and how to manipulate the values.

Never the less: two ideas:

  • The single room controller has additional inputs for offsets that can be enabled. maybe you can use these to get things solved?
  • The other idea: The Analouge function has a Multiplexer mode. With this multiplexer mode you can switch between the inputs - i.e. input 1 is the RAS-Sensor, input 2 is the CAN value. (Don’t forget to enable the Multiplexer selection input pin). You could just use something like a comparision function to check if the value of your can is > 5 and when this is true the multiplexer switches to the CAN input and when it’s 0 it uses the room sensor…

Maybe one of these idea brings you further…

Cheers,
Chris

@marvkis thanks for suggestions, I will check with tapps simulator how it goes. So far my main concern is “overriding” of value - meaning deciding which value to use. In worst case change of value (either from DL-Input or CAN level) will take precedence of present setting.

For decoding of the reported value I got basic recipe from TA, so at least I can read reported value and mode:

Bit[0]-Bit[8] :  Temperture Value
Bit[9]-Bit[10]: Slidingswitch (Mode)
Bit[15] Sign
Bit[14] inverse Sign

Your ideas definitely move things forward, appreciate your help!

Hi @splatch ,

I hope you found a solution for your challenge.

Quite interesting detail:

When studying the doc’s I already thought this looks like some kind of ‘bit-banging’. This makes quite a lot sense on the DL-Bus, but they also had it for the ‘old’ RAS-PT’s that have been connected to the analoge input’s. And i was not sure how relieable it could work to trigger the right bits on the ADC for an analoge signal. Fascinatig :wink: But it’s hard to do bit-banging with the TA system as there is nothing like a scripted programming available - this is one point why I decided to link it with OH :wink:

Maybe it’s worth to inverst some :moneybag: and buy one of these sensors as i’m thinking of replacting my old ‘non-smart’ floor heating distribution controller with some AO4-DL and PWM-Drive the 24V valve’s with them… :thinking:

RAS parsing looks fine. If did cause some complications cause one PLC channel creates two channels on OH side.
I am about to reorganize native CAN binding I made cause I want to better cover scenarios when there is input and output which can be written/read from the binding.

I don’t have any of TA hardware at my disposal, but looking at functionality I am thinking about using their controller instead of Vaillant which does not support hardware I bought from them. Any emergency there will force me to buy controller and mixer module. If I will do any updates there I will also add controlling of all 16 heating circuits I have.

Hi Christian,

first thanks for implementing this Binding.
It helps me getting values out of my two heading controls from TA.
Mainly I use it for storing values persistent in influx.db by means of the Schema approach.

By exploring my values there I discoverd that I don’t get negative values into the database.
Instead I have a 0 there. The strange thing is, that in the openhab logfile the right (negative) value is visible. In Paper UI I get a “- NaN” instead of the negative value, positive values are shown right.

Any idea what I’m doing wrong here ?

Number TACMI_Temp_Aussen “TA Temperatur Aussen [%.1f °C]” {channel=“tacmi:cmiSchema:api82:TACMI_Temp_Aussen”}

Can we see an example of that?

I will try to post some screenshot in the evening when it gets below 0 degree

Hi Klaus,

Right now - Not really… it works for me :wink:

But i have some suspects: What controller’s do you have? I only own x2-Controllers. In the past we already have seen the older UVR 16xx-devices have different number formats on the CMI schema output. Besides the Info’s requested by rossko57 - can you also capture the output of the schema file when the temperature passes below 0? Maybe we can see if there is something on it the parser might stumble on. The command is:

curl -v -H "Accept-Language: de" -u user:pw http://<cmi-ip>/schematic_files/<page-id>.cgi

What devices and firmware versions do you have? And which OH version / binding version do you have in use?

Cheers,
Chris

Hi Chris,

At the moment my schema looks like :
TACMI_Temp_Aussen Temp Aussen: - 4,3 °C
Log output
2021-03-06 21:17:38.432 [thome.event.ItemStateEvent] - TACMI_Temp_Aussen updated to - 4,3 °C
Paper UI and influx.db
TA Temperatur Aussen 0.0 °C / no idea why I got - NaN this morning

I*m running Openhab Version 2.5.9 and Binding also 2.5.9 in a docker container on a synology NAS
On the TA side I have a CMI running firmware V1.37.1
Connected to this via CAN are two UVR1611 controllers with A3.30DE firmware

On what CLI should I use the curl command ?

Thanks for helping
Klaus

Got it
curl result.txt (1.9 KB)

Hi,

Okay, it seems we have found an additional 1611<>16x2 discrepance…
This is the measurement for your file with the UVR1611:

TACMI_Temp_Aussen Temp Aussen:
- 4,5 °C</div>

whereas this is from my UVR16x2

tempExternal T.Aussen:
-4.3 °C</div>

I’ve already done some adoptions for the parser to cope with the komma, but it seems there is an additional space between the minus and the number. It could be the parser stumbles over it… Maybe I find some time to have a closer look into it later today.

Cheers,
Chris

OK, good we found a possible reason
Will wait till you checked it.

Well spotted!