KM200 binding: more than 1 heatingCircuit

Add-ons Bindings
1

Hi there,

I am using the latest KM200 binding with textual configuration. Everything is working fine, except the definition of multiple heatingCircuits.

As I’ve got more than one (physical) heating circuit, the binding throws “duplicate channels” exceptions when I put the definition into my .things file (even if it’s only one).

What works is to add them via PaperUI.

So my question is what the correct approach would look like to have them defined textual, too.

KR,
CSI

EDIT: will add log-entries and excerpt of textual configuration later!

2

You can only create the Thing in either PaperUI or files but not in both locations. Most recommend using PaperUI for Things and files for item to help with syntax errors.

If you have duplicates that will not go away let me know and I can help with removing them but after deleting the file and cleaning the cache it should remove the extra Thing.

3

Hi there,

thanks - I’m aware of that. Even with nothing defined in PaperUI the log fills with “duplicate channel” messages.

PaperUI             .things
only 1 HC            no HC          => works
all 3 HCs            no HC          => works
no HC                only 1 HC      => log fills with "duplicate channel" errors
no HC                all 3 HCs      => log fills with "duplicate channel" errors

The “duplicate channel” messages aren’t “persistent” - so if i comment the textual Thing definition out, they’re gone.

Textual config, as per documentation:
.things

heatingCircuit 1 "TestHC1"

.items

Number  budWater  "Water temperature  [%.1f °C]" {channel="km200:dhwCircuit:0815:1:actualTemp"}

Working example from PaperUI

km200:heatingCircuit:KM200:hc1

So I’m not sure if the binding is able to handle more than 1 heatingCircuit via textual configuration. Don’t get me wrong - it’s not a big deal, just wanted to share that here.

KR,
Chris

1 Like
4

Do you have simple mode turned on in PaperUI? If so, turn it off and you can configure in item files without duplicates.

5

uh, is there meant to be a bit more than that?

6

Thanks for the tip - will do!

Unfortunately not - at least in documentation.

7

It can’t work with just
heatingCircuit 1 "TestHC1"
in a xxx.things file. It doesn’t even know what binding that is supposed to go with, never mind what Thing.
It’s a things file,for defining things,not stand alone channels.

8

Hi buddy,

it’s neither my documentation, nor my approach :wink: … just posting what’s there and defined as “Full Examples”.

If you take a closer look into bridge definition…;

Bridge km200:kmdevice:0815 "testKMDevice" @ "Room" [ privateKey= "1234567890abcdef1234567890abcdef", maxnbrrepeats=10.0, readDelay=100, refreshInterval=30, maxNbrRepeats=10, ip4Address="192.168.1.111", refreshinterval=30.0, readdelay=100.0 ] {
	heatingCircuit 1 "TestHC1"
	sensor 1 "TestSensors"
}

…you’ll also notice multiple duplicate definitions of parameters.

1 Like
9

Okay, so you didn’t have just the one line that you claimed in your xxx.things file? It’s really still not clear.

I am suspicious of the example in docs, both of the validity of “1” as a UID (I thought they must start with alpha) and the re-use of “1” for two channels.
Bindings vary in this area, but I’d be inclined to try with h1 , s1 etc.

Did you notice the UIDs and/or channel names when you had it working via PaperUI ?

10

Hi @rossko57,

(working) PaperUI’s thing configuration (via auto-detect) - I only added the heatingCircuits;

km200:heatingCircuit:KM200:hc1:*
km200:heatingCircuit:KM200:hc2:*
km200:heatingCircuit:KM200:hc3:*

(working) km200.items

[...]
String KM200_HC1_status "OG/Status [%s]" <floorheating> (gKM200) { channel="km200:heatingCircuit:KM200:hc1:status" }
[...]

(working) km200.things (for things != heatingCircuit)

Bridge km200:kmdevice:KM200 "KM200" @ "Heiztechnik" [ privateKey= "<MD5-SALT>", maxnbrrepeats=10.0, readDelay=100, refreshInterval=30, maxNbrRepeats=10, ip4Address="<IP>", refreshinterval=30.0, readdelay=100.0 ] {
    appliance       1   "Appliance Info"                    // ok
    dhwCircuit      1   "Hot Water Circuit"                 // ok
    gateway         1   "Gateway"                           // ok
    // heatingCircuit   1   "Heating Circuit 1 (OG)"        // paper ui-configured
    // heatingCircuit   2   "Heating Circuit 2 (KG)"        // paper ui-configured
    // heatingCircuit   3   "Heating Circuit 3 (EG)"        // paper ui-configured
    heatSource      1   "Heat Source"                       // empty
    holidayMode     1   "Holiday Mode"                      // empty
    sensor          1   "Sensors"                           // ok
    solarCircuit    1   "Solar Circuit"                     // empty
    system          1   "System"                            // empty
    notification    1   "Notification"                      // empty
    systemStates    1   "System States"                     // ok
}
11

That’s nice. Are you going to try anything else, like giving your channels unique names that do not start with a number? (Like PaperUI does)

Be careful if you have your “parent” Thing configured in PaperUI and try to configure the same Thing from file at the same time.

12

To be honest, I’m not that “never change a running system guy”, but in that case - with that little information giving in the official docs, I think I’ll keep it for now.

Thanks for the hint, everything is working fine at the moment, thus I’m getting log-entries like;

2020-01-31 15:50:29.436 [ERROR] [00.internal.handler.KM200DataHandler] - Communication is not possible!

I don’t understand that message, because I can pull & push data to the physical device without any troubles.

13

I also get these “Communication is not possible!” quite a lot on my system. I had set the log level to debug at some time, and it seems that this is rather a bug on the side of Buderus. My impression, when I investigated this, was, that it “forgets” some of its channels after some time, if it receives too many requests in a too short time frame. I haven’t invested more time in investigating this further, for now I simply put up with those annoying messages. It think they relate to channels I’m not really interested in.

I recently switched from FHEM. The module for a Buderus heating there has the possibility to restrict requested values to a subset, whereas the km200 binding always seems to request all values it found upon the initial discovery process. This would probably be a good extension for the km200 binding as well.

14

So my suggestions for the further development of this binding are;

  • an “official statement” in the docs regarding the multiple usage of heatingCircuits (if it’s only possible via PaperUI then I think it should be mentioned there)
  • thinking about @ardmore’s statement:

@ardmore - just a quick question; do you know if it’s somehow possible to read data like “T10 Solekreis ein” or “T11 Solekreis aus”?

Thanks & KR
CSI

15

@csi_oh: I’m not sure, what you are referring to regarding “T10 Solekreis ein”, but I assume, that you want to read back the status of one of these channels. Regarding the heating I currently only implemented some graphs to show the temperatures and power consumption of my heating. But I saw that some of the settings appeared in PaperUI as well and were settable. By now, some of these settings have disappeared; I assume that this is due to the communication failures.

Regards,

Ardmore

16

Hi, so on the display on the heating pump there are infos like the mentioned above, but I don’t know how to retrieve them. Guess it’s canbus-related and the KM200 doesn’t provide that data?

17

@csi_oh: This is what that I experienced as well. There are some values, which are visible on the display, but which I did not find in the data transferred by the Buderus gateway. I think, this is simply a restriction of the interface. There are some obscure values, which I saw in FHEM, which looked like service personnel could use to request additional data, but I did not dare fiddle with them :slight_smile:

18

Whether you create a Thing via PaperUI or via xxx.things files, the end product is an identical Thing.
This is an issue about the settings the user is making.
There might well be deficiencies in the docs about this.
When you use Discovery, many settings are completed for you.

If you want to explore further,use REST API to examine your Things, and compare and contrast their properties.

19

csi_oh - did you get this working? I also stuck on the problem, that I can’t use the heating-circuits