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.
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.
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: homematic_HG_HM_Sec_SC_2_default_MEQ1593634_1_STATE
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:
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.
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.
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"
{
Channels:
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!
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"
{
Channels:
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.
I´m currently trying to get friends with the Paper UI
Thing HG-HM-Sec-SC-2 SERIALNUMBER "Türschloss" @ "Flur"
{
Channels:
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.
@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…
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.
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.
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.
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.
