[SOLVED]-[Homematic] Channel type couldn´t be resolved

Hi there,

i´m currently doing my migration from oH 1.8.3 to the latest oH 2 (openhabian image) release.
I already did the migration of homegear from my old pi to the new and finally have all HM devices connected to the new homegear service.
Currently i´m trying to get the window and door contacts to only show the current state, but there seems to be something wrong with my things file.


Bridge homematic:bridge:default [ gatewayAddress="", callbackHost="" ]
    Thing HG-HM-Sec-SC-2 SERIALNUMBER "Türschloss" @ "Flur"
            Type HG-HM-Sec-SC-2_1_state : 1#STATE
                delay = 0,
                receiveDelay = 0

    Thing HG-HM-Sec-SCo SERIALNUMBER "Wohnungstür" @ "Flur"
            Type HG-HM-Sec-Sco_1_state : 1#STATE
                delay = 0,
                receiveDelay = 0


/* Tüschloss */
Contact itmAlarm "Türschloss [MAP(windowcontact.map):%s]" <alarm> {channel="homematic:HG-HM-Sec-SC-2:default:SERIALNUMBER:1#STATE"}

/* Fenster / Türen */
Contact itmTuer_Flur "Wohnungstür [MAP(windowcontact.map):%s]" <door> (Flur) {channel="homematic:HG-HM-Sec-SCo:default:SERIALNUMBER:1#STATE"}

After every save of the things file i get the following errors in the logviewer:

2018-07-17 12:16:18.869 [ERROR] [.thing.internal.GenericThingProvider] - Channel type homematic:HG-HM-Sec-SC-2_1_state could not be resolved.

2018-07-17 12:16:18.922 [ERROR] [.thing.internal.GenericThingProvider] - Channel type homematic:HG-HM-Sec-Sco_1_state could not be resolved.

If i´m just using the Thing without a Channel information i don´t get anything from the contacts.
It´s not clearly descriped if i really need the Channel config with delay and receiveDelay or if it´s just optional.

Am i missing something?

I checked the homegear log and homegear is getting the changes correctly:

07/17/18 13:03:31.945 Module HomeMatic BidCoS: Info: LOWBAT on channel 1 of HomeMatic BidCoS peer 4 with serial number MEQ1726970 was set to 0x00.
07/17/18 13:03:31.945 Module HomeMatic BidCoS: Info: STATE on channel 1 of HomeMatic BidCoS peer 4 with serial number MEQ1726970 was set to 0x00.
07/17/18 13:03:33.950 Module HomeMatic BidCoS: Info: LOWBAT on channel 1 of HomeMatic BidCoS peer 4 with serial number MEQ1726970 was set to 0x00.
07/17/18 13:03:33.950 Module HomeMatic BidCoS: Info: STATE on channel 1 of HomeMatic BidCoS peer 4 with serial number MEQ1726970 was set to 0xC8.

I tried to define the Channel with HG- and without. Makes no difference.

kind regards

From what I’ve seen of the examples all the device type have either a HG or an HM, not both and the README says

If you are using Homegear, you have to add the prefix HG- for each type.

So if these are Homegear devices replace the HM with an HG. If they are not, only use the HM.

Also, STATE seems an unlikely name for a datapoint name. I don’t know if that is a correct assumption or not, but it is something you should look into.

Honestly, I’d recommend letting the binding automatically discovery the Things for you.

As you quotted the docs, it says add the prefix. So it has to be HG-HM-... and not HG-... or HM-...
Even the examples use HG-HM-...
But i´m not sure where to use this prefix, just in the Things or everywhere (Things, Channels, Items)?

STATE worked fine in oH 1.8.3 and is the correct datapoint in channel 1 for window and door contacts.

The log says that the channel type couldn´t be resolved…
The doc says The Type is the device type, channel number and lowercase channel name separated with a underscore.
So i think that Type HG-HM-Sec-SC-2_1_state : 1#STATE is the correct syntax.

I don’t know this binding so I can’t say definitively. I didn’t see any examples that used both but a quick search does show some. So that clearly isn’t a problem.

As I read it this prefix is used in the Thing definition and becomes the Thing ID. The Thing ID becomes the root of the ID for the Channels so I would expect it to be used there as well.

But I gotta say, these Things seem to be a bit weird (not your Things, the way they look in the docs). So I’m doubting even that. Unlike with other bindings, you link the Item to a Channel using the Channel Number, not it’s ID.

STATE also does look correct.

What I would do is let the binding automatically discover a Thing and accept it from the inbox and then you can look at how the Things are defined in the JSON DB and see if there is anything that stands out.

Homeatic is pretty popular so I know in theory it should work. But I don’t know how many are defining their own Things for it.

As far as I can tell what you are doing looks correct based on the README. It is a little hard because it looks a little different from the way I’ve seen Things defined before.

I had a look in the Paper UI.
The windows contacts (3 of 4) don´t have Channels and the thermostats just have some channels (some are even wrong).
One contact is correct, shows two channels and two datapoints per channel.
The other three contacts are only shown with their firmware version and the battery type.
I double checked my Things and Items, the four contacts have the same configuration.
The thermostats are showing a LOWBAT datapoint but they´re using a BATTERY_STATE.

The channels and datapoint can´t change between oH 1 and 2 because they´re device based and are not defined by oH.

I´ll have a look at the JSON DB and try to find something that´s different in there.


I´ve found something in the jsondb files.
(And a typo in the docs… missing t for jsonlint.com… pull request is already placed)

I´m only able to find the HM_Sec_SC_2 and one of the windows contacts (HM_Sec_SCo).
HG- is used as a prefix everywhere the type is mentioned.

The most interesting part is this:
The Type is all uppercase and not lowercase like described in the docs.

I played around with the type and finally found the one that is working:

    Thing HG-HM-Sec-SC-2 SERIALNUMBER "Türschloss" @ "Flur"
            Type HM-Sec-SC-2_1_STATE : 1#STATE

The Type has to be in UPPERCASE.
Unfortunately this is another typo in the docs.
I´m going to place a pull request…

The Type is the device type, channel number and lowercase channel name separated with a underscore.

And the channel configs delay and receiveDelay are optional.

@rlkoshak thanks for the hint that a look into the jsondb could help.

1 Like

I’m really glad you got it to work.

I’ve been unhappy with the drastic differences in the ways that Things are defined for awhile. Each binding has a lot a leeway in setting their own standards resulting in a lot of inconsistencies. Given I’ve taken the role of support on the forum in my support of the project, these inconsistencies result in more work for me. :frowning:

And I suspect the Homematic binding is not the only one that has typos or inadequate documentation for manually created Things. Early on providing documentation for manually created Things wasn’t required. Some bindings didn’t even support manually created Things (e.g. Zwave unless you used the refactored development version). the Homematic Thing definition does look hastily written, and written under duress.

Thanks for the PRs!

I´m not completely done here.
I don´t get the LOWBAT datapoints working…

While STATE is working fine, i get the same error as before when using LOWBAT.

2018-07-17 20:19:56.991 [ERROR] [.thing.internal.GenericThingProvider] - Channel type homematic:HM-Sec-SC-2_1_LOWBAT could not be resolved.
2018-07-17 20:20:25.010 [ERROR] [.thing.internal.GenericThingProvider] - Channel type homematic:HM-Sec-SC-2_1_lowbat could not be resolved.`

It´s possible to add the following (or first STATE then LOWBAT) and only get the LOWBAT Error.

    Thing HG-HM-Sec-SC-2 SERIALNUMBER "Türschloss" @ "Flur"
            Type HM-Sec-SC-2_1_LOWBAT : 1#LOWBAT
            Type HM-Sec-SC-2_1_STATE : 1#STATE

So it seems like STATE is correct while LOWBAT can´t be used.
But LOWBAT is the correct datapoint!

And even in the jsondb it´s correct…

Do you by chance see anysorts of errors when you save the .things file? A missed typo or something like that?

I’m really at a loss. If STATE works I see no reason why LOWBAT would not.

Oh, I just noticed something. Don’t you need to use a different Channel Number?

Shouldn’t it be something like:

 Thing HG-HM-Sec-SC-2 SERIALNUMBER "Türschloss" @ "Flur"
            Type HM-Sec-SC-2_1_LOWBAT : 1#LOWBAT
            Type HM-Sec-SC-2_1_STATE : 2#STATE

I’m assuming that is what that number before the # is supposed to represent. And I’m guessing that they need to be different numbers since the number needs to be referenced in the link to the Item. Though that could be to handle the case where there is more than one LOWBAT.

That’s all I have for ideas.

I´m currently trying to get friends with the Paper UI :smile:

    Thing HG-HM-Sec-SC-2 SERIALNUMBER "Türschloss" @ "Flur"
            Type HM-Sec-SC-2_1_STATE : 1#STATE
            Type HM-Sec-SC-2_1_LOWBAT : 2#LOWBAT

Same error as before:
2018-07-17 21:29:17.025 [ERROR] [.thing.internal.GenericThingProvider] - Channel type homematic:HM-Sec-SC-2_1_LOWBAT could not be resolved.

I think someone who knows the binding should review this…
I´m now trying to get it work through the Paper UI, but i don´t think this helps other users.

Sometimes it’s hard to like PaperUI I know. But it is getting better with every release.

Sorry I can’t help more with this. I don’t really even know a user to tag to bring this post to their attention. Good luck!

@rlkoshak but maybe you know this:
Where do i add transformations for Items that are only available in the jsondb?
As i don´t have the Items in an .items file i can´t add an transformaton…

Now i have Things in the Paper UI and Items in an .items file and it seems to work.

Still no solution for this issue and maybe a bug in the binding.

Your thing definition is far to complicated. The Homematic binding identifies all the channels via the api.

That’s enough:
Bridge homematic:bridge: “NAME” @ “LOCATION” [ gatewayAddress=“IP”, callbackHost=“IP”, binCallbackPort=9125, xmlCallbackPort=9126 ]
Thing GATEWAY-EXTRAS-HOMEGEAR GWE00000000 “Homegear Extras” @ “LOCATION”


Mainly answering for future readers since it appears you have already found the answer.

When working with OH 2.x bindings the transformations typically go on the Thing, not the Item. I understand why this is the case but it really makes some use cases pretty awkward. Just look at how hard it is to figure out how to use the Exec 2.x binding.

I would pay good money to extract transformations and make them generic rather than something that the individual bindings have to implement. There are cases where even with bindings like Zwave where it sure would be useful to apply a transformation but we can’t because the binding doesn’t support them. :frowning:

It would also be useful to be able to chain transformation, though I can also see the argument that that more correctly belongs in a Rule anyway.

But it is a huge change and would require lots of buy in from a lot of stakeholders. I’m hesitant to create an issue like this that I have no intention/ability to actually implement.

Does this binding support transformations or were you asking about a different binding?

Hmmm. The binding README does not make it clear that this is all that is required.

But let’s assume that Michael wanted to set a delay or receiveDelay on both the STATE and LOWBAT Channels. How would that appropriately look?

I use the homematic binding with about 70 devices, please be assured the channels are not required. I don’t use more information in the things files as i stated above.

Here is my item definition for the magnetic door/window contact:

Switch AKKK_UNREACH "UNREACH AKKK [MAP(UNREACH.map):%s]" (gUNREACH,gRestoreOnStartup) { channel = "homematic:HG-HM-Sec-SC-2:homegear:NEQ0757235:0#UNREACH" }
Contact AKKK_STATE "AKKK [MAP(HM-Sec-SCo.map):%s]" <door> 		(gRestoreOnStartup,gPersist) { channel = "homematic:HG-HM-Sec-SC-2:homegear:NEQ0757235:1#STATE" }
Switch AKKK_LOWBAT "Batterie AKKK [MAP(LOWBAT.map):%s]" <battery> (gBattery,gRestoreOnStartup) { channel = "homematic:HG-HM-Sec-SC-2:homegear:NEQ0757235:0#LOWBAT" }
Number AKKK_RSSI "RSSI AKKK [%d]" <rssi> (gRSSI,gRestoreOnStartup,gPersist,gPersistNumber) { channel = "homematic:HG-HM-Sec-SC-2:homegear:NEQ0757235:0#RSSI" }
Number AKKK_SIGNAL_STRENGTH "Signal AKKK [%d]" <rssi> (gSignalStrength,gRestoreOnStartup) { channel = "homematic:HG-HM-Sec-SC-2:homegear:NEQ0757235:0#SIGNAL_STRENGTH" }

The #LOWBAT datapoint is in the channel 0. (The maintenance channel fi i recall correctly.)

I already tried this minimal design, but it wasn´t working.
So i tried to define the Channels, Types and configs.

Now i have the Things configured by the Paper UI and the Items still in .items files because i can´t choose an transformation in the Paper UI.

Do you mean this?
The values are shown in german in the Things but not on the Paper UI Control tab or in the Basic UI.
So i don´t know where i could add a transformation when completely working with Paper UI.
Now i only have the Things in the Paper UI and the Items back in .items file.
This way i´m able to at the .map files to the value transformation.

This is possible through the PaperUI Things. But not for all datapoints.
For the windowcontacts it´s only possible for the STATE datapoint.
-> This could be the answer why i´m not able to use LOWBAT as a Thing Type.

This may be true.
But it´s mentioned in the docs and some users (like i did today) may come accross, want to configure the Things in .things files instead of the Paper UI and then need to set delay or receiveDelay.
But as i said above, this should be possible for datapoints that support Thing Types like delay and receiveDelay.

LOWBAT is in Channel 0 and 1.

I used the Channel 1 LOWBATin my oH 1.8.3 environment and it worked fine for over three years.

I’m not implying you are wrong. I’m implying the README is wrong, or at least unclear on this point and may need to be corrected or improved.

So the channel numbers is set by the device/binding and is something that needs to be looked up, not set by the user.

Maybe not. Are you transforming the label? E.g.

String MyItem "My label [MAP(mymapfile.map):%s]

If that is the case, you can enter the stuff between the [ ] in the label field for the Item in PaperUI for Items not defined in .items files.

I was thinking of something more along the line of the Exec Binding though:

This is the Thing creation menu where you can define a Transformation on the Thing itself. In OH 1.x and 1.x version binding, this is the same as the transforms that appear between the { } in the Item definition.

I don’t configure anything in PaperUI except for binding level stuff. Bu i also did never need the delay or receiveDelay options.

It works. Then you had a mistake somewhere else.

Sorry, i did misunderstood this.

Yes exactly. eq-3 has a downloadable datapoint specification. But even without that, he datapoints are transferred via the api to the binding creates all the channels.