Recommendable debug settings to identify wrong datatypes written in Things of the KNX Binding

Dear community,

My OpenHAB2 setup includes the binding-knx - 2.5.6.SNAPSHOT. As long as I add things with common datapoint types like 1.001 and 9.001, everything works fine. However, when I add the HVAC mode with datapoint type 20.102, I receive the following error message in openhab.log:

2020-06-23 19:19:16.499 [INFO ] [g.knx.internal.dpt.KNXCoreTypeMapper] - Translator couldn’t parse data for datapoint type ‘20.102’ (KNXIllegalArgumentException).
2020-06-23 19:19:16.516 [WARN ] [.internal.handler.DeviceThingHandler] - Ignoring KNX bus data: couldn’t transform to any Type (destination=‘9/4/5’, datapoint=‘command DP 9/4/5 ‘knx:device:bridge:HA’, DPT id 20.102, low priority’, data=‘0x21’)
2020-06-23 19:19:16.498 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
tuwien.auto.calimero.KNXIllegalArgumentException: 20.102 HvacMode has no element 33 specified
at tuwien.auto.calimero.dptxlator.DPTXlator8BitEnum$EnumDpt.textOf(DPTXlator8BitEnum.java:890) ~[?:?]
at tuwien.auto.calimero.dptxlator.DPTXlator8BitEnum$EnumDpt.access$100(DPTXlator8BitEnum.java:845) ~[?:?]
at tuwien.auto.calimero.dptxlator.DPTXlator8BitEnum.makeString(DPTXlator8BitEnum.java:1124) ~[?:?]
at tuwien.auto.calimero.dptxlator.DPTXlator8BitEnum.getValue(DPTXlator8BitEnum.java:1051) ~[?:?]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.read(ProcessCommunicatorImpl.java:346) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.readNextQueuedDatapoint(AbstractKNXClient.java:287) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.lambda$1(AbstractKNXClient.java:199) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_252]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]

Does anybody have a hint why this datapoint type is not supported? According to my understanding, the current KNXCoreTypeMapper should be capable of supporting 20.102.

I use MDT Heating Actuators. They implement a “HVAC mode status” (status read) with a different bit addressing scheme then the “HVAC mode” (for write). Up to now, I have put both the HVAC mode and the HVAC mode status onto the same channel with write and read.

DPT 20.102 HVAC mode:
Value 1: Comfort
Value 2: Standby
Value 3: Night
Value 4: Frost / Heat Protection

HVAC mode status:
Bit 0: Comfort (1)
Bit 1: Standby (1)
Bit 2: Night (1)
Bit 3: Frost or Heat Protection (1)
Bit 4: -
Bit 5: Heating (1) / Cooling (0)
Bit 6: -
Bit 7: Frost Alert (1)

Two questions arise:

  1. Do I need to distinguish two different lines in my thing setup of the heating actuator where a first line addresses the HVAC mode for write and the secondline addresses the HVAC mode status for read due to different layout of the values?

  2. How to add a “new” datapoint type to handle the HVAC mode status?

Thank you very much for your support.

Best regards,
Peter

You can’t.

Dear Peter,

I also use the MDT heating actors and had the same questions. Regarding your first question, I tried to configure the HVAC status as the second (read) GA of the channel, but because of the different value codings, it will not work.

So I decided to use two items. One for the HVAC mode and one for the HVAC status. I also decided to use them both as string items in openHAB with the distinct values Comfort, Standby, Economy and Building Protection. These strings are already mapped by the knx binding, when you use the DPT 20.102 with the channel type String.

Regarding your second question how to handle the HVAC status, this is quite a bit of a pain. The suggested DPT for this is mentioned in the official DPT specification of the KNX Association in the Annex A. It’s official name is DPT_HVACStatus and is a non standard DPT that is used by an HVAC room controller to report the currently set HVAC Mode by means of a status/diagnostic datapoint. Therefore in the current specification the DPT has no assigned DPT ID, but the content is specified.

My decision here is to use the generic DPT 5.006 as a number and use a transformation to bring it into the corresponding string representation.

As you indicated in your topic title, you still use openHAB 2.5, which means, you use the textual configuration of the knx addon, right?

The file is then OPENHAB/conf/things/knx.things. Where OEPNHAB is the root directory of your openhab installation.

This is a draft from my config, I used in OH 2.5 and still works with OH3:

Bridge knx:ip:bridge [
    type="ROUTER",
    autoReconnectPeriod=60
] {
    Thing device 01e52303 "Heizungsaktor D3.1" @ "Technikraum" [
        address="1.0.14"
    ] {

        Type string : A10 "Betriebsart Heizung Schlafzimmer" [
            // channel A, communication object #10
            ga="20.102:6/2/3"
        ]

        Type number : A11 "Betriebsart Status Heizung Schlafzimmer" [
            // channel A, communication object #11
            ga="5.006:<6/2/4"
        ]
    }
}

And this is the tranformation I use on the communication object #11:

(function(hvacStatus) {
    var logger = Java.type("org.slf4j.LoggerFactory").getLogger("org.openhab.core.model.transform.DPTHVACStatus");

    if(isNaN(hvacStatus)) {
        logger.warn("HVAC status is not a number");
        return "Undefined";
    }

    var havacMode = hvacStatus & 0x0F;
    logger.debug("HVAC status is: {}", havacMode);

    switch (havacMode) {
        case 1:
            return "Comfort";

        case 2:
            return "Standby";

        case 4:
            return "Economy";

        case 8:
            return "Building Protection";
    }

    return "Invalid";
})(input)

According the the MDT handbook for the heating actor, you can also configure the HVAC mode to send the status on the same communication object #10. I didn’t try that, but it should work like this:

Bridge knx:ip:bridge [
    type="ROUTER",
    autoReconnectPeriod=60
] {
    Thing device 01e52303 "Heizungsaktor D3.1" @ "Technikraum" [
        address="1.0.14"
    ] {

        Type string : A10 "Betriebsart Heizung Schlafzimmer" [
			// channel A, communication object #10, also sending status
            ga="20.102:<6/2/3"
        ]
	}
}

The difference is the ‘<’ for the HVAC mode GA, that tells the knx binding that this GA can also be read.

I hope the answer is not to late and can be still useful to you.

1 Like

Dear Frank,

Thank you very much for your detailed answer. As I only have general programming languages experience, but not particularly in Java/JaveScript and also not in OpenHAB, it is the best to see a working example to learn and adopt to the own situation. I am sorry for not responding earlier, as our renovation project was in its final phase.

At present, I cope with more fundamental problems as I have implemented a network setup with different VLANs and since then I have issues in properly addressing KNX devices from OpenHAB. Once this is resolved, I will implement HVAC according to your suggestion.

Thanks a lot for your help!

Best regards,
Peter

Dear Frank,

in the mean time, I could resolve my general issues with the KNX bus communication, and I can read and write values via OpenHAB. However, I have some trouble to correctly implement your transformation rule.

This is the corresponding part in my heating actor KNX thing:

Type number : APPEG_Zimmer_Betriebsartstatus_HVAC "APPEG Zimmer Betriebsartstatus HVAC" [ ga="5.006:<13/5/5" ]

This is my KNX item:

Number APPEG_Zimmer_Betriebsartstatus_HVAC "APPEG Zimmer Betriebsartstatus [MAP(hvac-status.js):%s]" { channel="knx:device:APPEG_IP:APPEG_HA01:APPEG_Zimmer_Betriebsartstatus_HVAC" }

I have stored the transformation rule according to your post above in the config file ./transformation/hvac-status.js.

The correct HVAC status is received, it is 34 dec, I see it in the log file. This is 32 for Heating plus 2 for Standby. Consequently, there should be a match for Standby. Unfortunately, nothing is mapped. The log file says:

2021-03-16 23:30:42.125 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '34' with the file 'hvac-status.js' : Target value not found in map for '34'

Probably I have something fundamentally misunderstood as how to correctly implement a transformation.

Best regards,
Peter

Maybe. Could you show us what you did? It’s not in the settings you showed.

This is a bit suspicious. This message is generated by the MAP transformation service.
For javascript, you would want to use the javascript transformation service, JS.

Dear Rossko57,

Thank you very much for your hint with regard to the MAP transformation service. I was not aware of using JS instead of MAP. After having installed the JS transformation service and replacing MAP by JS, everything worked like a charm.

Best regards,
Peter

Dear Community,

While I can now read the HVAC status from the KNX bus, convert the result to a HVAC mode, and present the value in clear text in my sitemap, I now fail to change the HVAC mode and write the result to the KNX bus.

I try to send value 3 to APPEG_Zimmer_Betriebsartvorwahl_HVAC as shown below.

knx.things:

Type number : APPEG_Zimmer_Betriebsartvorwahl_HVAC "APPEG Zimmer Betriebsartvorwahl HVAC" [ ga="20.102:13/5/4" ]
Type number : APPEG_Zimmer_Betriebsartstatus_HVAC "APPEG Zimmer Betriebsartstatus HVAC" [ ga="5.006:<13/5/5" ]

knx.items:

Number APPEG_Zimmer_Betriebsartvorwahl_HVAC "APPEG Zimmer Betriebsartvorwahl [%d]" { channel="knx:device:APPEG_IP:APPEG_HA01:APPEG_Zimmer_Betriebsartvorwahl_HVAC" }
Number APPEG_Zimmer_Betriebsartstatus_HVAC "APPEG Zimmer Betriebsartstatus [JS(hvac-status.js):%d]" { channel="knx:device:APPEG_IP:APPEG_HA01:APPEG_Zimmer_Betriebsartstatus_HVAC" }

knx.sitemap:

Selection item=APPEG_Zimmer_Betriebsartvorwahl_HVAC mappings=[1="Komfort", 2="Standby", 3="Nacht", 4="Frost"]

This is the result:

2021-03-18 19:32:47.402 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'APPEG_Zimmer_Betriebsartvorwahl_HVAC' received command 3

==> /var/log/openhab/openhab.log <==

2021-03-18 19:32:47.407 [TRACE] [.internal.handler.DeviceThingHandler] - Handling command '3' for channel 'knx:device:APPEG_IP:APPEG_HA01:APPEG_Zimmer_Betriebsartvorwahl_HVAC'

==> /var/log/openhab/events.log <==

2021-03-18 19:32:47.407 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'APPEG_Zimmer_Betriebsartvorwahl_HVAC' predicted to become 3

==> /var/log/openhab/openhab.log <==

2021-03-18 19:32:47.410 [TRACE] [.knx.internal.channel.KNXChannelType] - getCommandSpec testing Keys '[ga]' for command '3'

2021-03-18 19:32:47.410 [TRACE] [.knx.internal.channel.KNXChannelType] - getCommandSpec no Spec found!

2021-03-18 19:32:47.412 [DEBUG] [.internal.handler.DeviceThingHandler] - None of the configured GAs on channel 'knx:device:APPEG_IP:APPEG_HA01:APPEG_Zimmer_Betriebsartvorwahl_HVAC' could handle the command '3' of type 'DecimalType'

It appears that there is a kind of type conversion problem. Does anybody has a hint as how to cope with this?

Best regards,
Peter

Dear Peter

This is the right setting for the the HVAC mode object.

There is the problem. The item must be of type string. As I explained in my text above, the KNX bridge does map the DPT 20.102 to a string. So this should work for your installation:

String APPEG_Zimmer_Betriebsartvorwahl_HVAC "APPEG Zimmer Betriebsartvorwahl []" { channel="knx:device:APPEG_IP:APPEG_HA01:APPEG_Zimmer_Betriebsartvorwahl_HVAC" }

And for the sitemap it should be something like that:

Switch item=APPEG_Zimmer_Betriebsartvorwahl_HVAC icon="heating" mappings=["Comfort"="An", "Standby"="Mittel", "Economy"="Klein", "Building Protection"="Aus"]

The switch values (strings in english) must be exactly like that. They are defined in the official KNX specification.

Hope this helps

1 Like

Dear Frank,

Thank you very much for pointing me into the right direction. Unfortunately, my approach of using Number instead of String caused a problem in connection with InfluxDB. InfluxDB seems to be aware of my previous float definition of the HVAC mode selector, although I have setup only InfluxDB without defining which parameters to be stored in the database so far. I receive the following error message once I have changed the setup according to your suggestion:

2021-03-19 11:56:12.965 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'APPEG_Bad_Betriebsartvorwahl_HVAC' received command Comfort

2021-03-19 11:56:12.968 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'APPEG_Bad_Betriebsartvorwahl_HVAC' predicted to become Comfort

2021-03-19 11:56:12.969 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'APPEG_Bad_Betriebsartvorwahl_HVAC' changed from Building Protection to Comfort

==> /var/log/openhab/openhab.log <==

2021-03-19 11:56:13.013 [ERROR] [org.influxdb.impl.BatchProcessor    ] - Batch could not be sent. Data will be lost

org.influxdb.InfluxDBException$FieldTypeConflictException: partial write: field type conflict: input field "value" on measurement "APPEG_Bad_Betriebsartvorwahl_HVAC" is type string, already exists as type float dropped=1

	at org.influxdb.InfluxDBException.buildExceptionFromErrorMessage(InfluxDBException.java:144) ~[bundleFile:?]

What I understand from the log file is that the processing of the altered HVAC mode is terminated. At least, I cannot find any KNX messages related to the GA of the HVAC mode selection after the reported exception.

Do you have any suggestions as how to overcome this issue?

Furthermore, I know mappings from items and to retrieve them from a centralized map file. Is there a similar way for mappings in the sitemap?

knx.items:

String APPEG_Zimmer_Betriebsartvorwahl_HVAC "APPEG Zimmer Betriebsartvorwahl [MAP(de.map):HVACMODE-%s]" { channel="knx:device:APPEG_IP:APPEG_HA01:APPEG_Zimmer_Betriebsartvorwahl_HVAC" }

de.map:

HVACMODE--=Unbekannt
HVACMODE-NULL=Unbekannt
HVACMODE-Comfort=Komfort
HVACMODE-Standby=Standby
HVACMODE-Economy=Nacht
HVACMODE-Building Protection=Frostschutz

I understand that this mapping works fine to present mapped text values in the sitemap. But I got lost when I want to enable the user to select from the above-specified mapped values in the sitemap by using a Switch or Selection element. Therefore, I left my sitemap unchanged:

knx.sitemap:

Switch item=APPEG_Zimmer_Betriebsartvorwahl_HVAC mappings=["Comfort"="Komfort", "Standby"="Standby", "Economy"="Nacht", "Building Protection"="Frostschutz"]

After restarting the OpenHAB service, I see the following error messages during startup:

2021-03-19 12:34:48.817 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'knx.things'

2021-03-19 12:34:51.701 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007

2021-03-19 12:34:54.842 [INFO ] [org.openhab.ui.internal.UIService   ] - Started UI on port 8080

2021-03-19 12:34:54.945 [ERROR] [org.openhab.core.items.GenericItem  ] - Tried to set invalid state 3.0 (DecimalType) on item APPEG_Zimmer_Betriebsartvorwahl_HVAC of type StringItem, ignoring it

2021-03-19 12:34:55.017 [ERROR] [org.openhab.core.items.GenericItem  ] - Tried to set invalid state 1.0 (DecimalType) on item APPEG_Bad_Betriebsartvorwahl_HVAC of type StringItem, ignoring it

2021-03-19 12:34:56.029 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel

2021-03-19 12:34:58.458 [ERROR] [org.openhab.core.items.GenericItem  ] - Tried to set invalid state 3.0 (DecimalType) on item APPEG_Zimmer_Betriebsartvorwahl_HVAC of type StringItem, ignoring it

2021-03-19 12:34:58.684 [ERROR] [org.openhab.core.items.GenericItem  ] - Tried to set invalid state 1.0 (DecimalType) on item APPEG_Bad_Betriebsartvorwahl_HVAC of type StringItem, ignoring it

2021-03-19 12:34:59.694 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.

Do you have a hint how to centrally store the mapping for the HVAC mode and to re-use this in the sitemap/items file? I checked the OpenHab Sitemap Docs but I was not able to identify a way.

Best regards,
Peter

You’ve got that exactly right. Changing an Item type does not, and cannot, change existing database records to what is now suitable. So it can’t store the new type in the old pigeonhole type either.

There are ways to delete the old records altogether, and so make it create new ones for your new type.
Maybe easier if you are not confident about doing that is instead just to change your Item name a little bit, so that persistence treats it as something new.

That’s your persistence service(s) trying to restore a previously stored numeric state to your now-String Item. Obviously, that fails.

You can’t, in that way.
You can use the MAP transform to change the way the Item’s state is displayed.
But the button mappings= are something quite separate from that.

You could use them together to display a long current state name, and put abbreviations in your buttons.

Switch item=APPEG_Zimmer_Betriebsartvorwahl_HVAC label="Mode [MAP(yourmap.map):%s] mappings=["Comfort"="K", "Standby"="S", "Economy"="N", "Building Protection"="F"]

which should show something like

[icon] Mode            Frostschutz [K] [S] [N] [F]

Dear Rossko57,

Thank you very much for explaining the interrelation between MAP (for mapping displayed status values = output) and mappings (for providing selections = input).

Your response was also very helpful with regard to the persistency of OpenHAB items in the InfluxDB. So I read a little bit about it and performed the following actions in the InfluxDB shell:

use openhab
show field keys
drop measurement APPEG_Zimmer_Betriebsartvorwahl_HVAC
exit

After restarting OpenHAB again, APPEG_Zimmer_Betriebsartvorwahl_HVAC was re-created in InfluxDB with datatype string. But there is still an issue, although the parameter is stored as string in InfluxDB:

2021-03-19 13:46:42.470 [ERROR] [org.openhab.core.items.GenericItem  ] - Tried to set invalid state 3.0 (DecimalType) on item APPEG_Zimmer_Betriebsartvorwahl_HVAC of type StringItem, ignoring it

knx.things:

Type number : APPEG_Zimmer_Betriebsartvorwahl_HVAC "APPEG Zimmer Betriebsartvorwahl HVAC" [ ga="20.102:13/5/4" ]

knx.items:

String APPEG_Zimmer_Betriebsartvorwahl_HVAC "Betriebsart [MAP(de.map):HVACMODE-%s]" { channel="knx:device:APPEG_IP:APPEG_HA01:APPEG_Zimmer_Betriebsartvorwahl_HVAC" }

knx.sitemap:

Switch item=APPEG_Zimmer_Betriebsartvorwahl_HVAC mappings=["Comfort"="K", "Standby"="S", "Economy"="N", "Building Protection"="F"]

I am lost again…

Best regards,
Peter

I did say this with (s) for a reason.

OH3 installs rrd4j by default, persists and restores everything. You might give that the same per-item treatment, or consider rationalising your persistence services.

Dear Rossko57,

Thanks again for your hint. I was not aware of rrd4j. To get rid of the wrong datatype in the rrd4j service, I deleted the wrong entry also in the rrd4j database:

sudo systemctl stop openhab
rm /var/lib/openhab/persistence/rrd4/APPEG_Zimmer_Betriebsartvorwahl_HVAC.rrd
sudo systemctl start openhab

Now the error in the log file is gone when starting OpenHAB. However, the underlying problem is still not solved: Once I change the HVAC mode, the BasicUI shows the successful change, and also the logfile, but the updated value is not sent to the bus. Although I activated debugging of KNX messages (which I receive for other things), the logfile remains silent on changing the HVAC mode at the KNX side:

2021-03-19 16:20:44.068 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'APPEG_Bad_Betriebsartvorwahl_HVAC' received command Building Protection

2021-03-19 16:20:44.082 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'APPEG_Bad_Betriebsartvorwahl_HVAC' predicted to become Building Protection

2021-03-19 16:20:44.089 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'APPEG_Bad_Betriebsartvorwahl_HVAC' changed from Economy to Building Protection

Do you have any hint?

Best regards,
Peter

Did you ever fix this? Type string, as @franks said.

You may need to restart the binding bundle to pick up Thing edits like that.

Dear Rossko57,

Thank you again for your hint. Indeed, I had a wrong understanding of where the mapping between the HVAC mode value and the string takes place. So I had still the number type in the thing, and the string type in the item. Now I can change the mode after correcting the type.

However, I wonder which debug settings I need to apply to get some information in the log? The issue here is that I did not get any feedback in the log file. This makes it difficult to identify a way forward.

Best regards,
Peter