Porting Nest Binding for Openhab2


Nest Binding is available for Openhab1. I am porting it according to the new concepts of Openhab2 (or Eclipse Smarthome). I have implemented everything from constructing thing, mapping Java objects to JSON, updating state and status of channel and handling commands.

Now, I am stuck at creating new items. Number of devices is not a constant number, so I need to create new channels according to the devices and sensor data coming. There’s no issue with that. Problem is when I need to create new items. I need to dynamically generate new items and link them to channels. I could not find any documentation on creating new items. I am thinking of directly updating the items file. What is the best approach to do so or is there some alternative?
I do not want to hard code anything.

I am not familiar with the Nest binding, but in general, no binding should ever create items by itself - you will hence also find no documentation about that :smile:

In general, I would suggest to go to https://www.eclipse.org/forums/index.php/f/271/ for discussing Eclipse SmartHome binding architecture and APIs.

I knew you would answer. :smile:

Yes, Sorry for mixing up things. :sweat_smile:

Thanks. Now I have understood that I should create new items and link them to channels using Rest APIs and that should not be the part of binding.

Once I done with the binding, I will share it with the community.

:thumbsup: for really smart project.

Why do you need to create new items and link to channel? From the work I’ve done items are linked to channels automatically when the thing is created.

I was really looking forward to porting this binding to OH2 (since I wrote it :smile: ), but I may have to resign myself to reviewing it instead.

I need to create new items because there can be any number of devices.

Items are not linked to channels automatically. In OH1, you have to mention the link in .items file and in OH2, you can add the link by calling REST APIs.

PUT /items/{itemname} for adding new item
PUT /links/{itemName}/{channelUID} for linking item and channel


I would really want to discuss the approach with you. :innocent:

In OH2, you can still link it in the .items file. But this is something the user does, it is not done by the binding.


But I think they are not shown in ItemRegistry. We need to add them to registry if we want handleCommand to work like for any other item created. Am I right?

What are “they”? All items that the user declares in the items-file are certainly in the item registry. And all items that are linked to a channel of the Nest-Thing, will make the handleCommand called.

This post was flagged by the community and is temporarily hidden.

‘They’ means the items declared in items-file.

But I cannot query them using Rest API. GET /rest/items is only giving me items which I added using api only but not from items-file. Additionally, when I try to change the value of item (defined in items-file) using Classical UI, handleCommand is not called and console gave me error that item is not in registry.

So I thought that items in items-file are not in item registry because dynamically generated items (from Rest API) did not give me such error. Where did I do wrong if it is not the case?

I would assume that you have some syntax error in your item file so that it is not correctly parsed.
I have just tried the latest OH2 demo build and I see all items from demo.items on the REST API:

If your binding requires that items are defined, you’ve taken a wrong turn in reaching that point. Also, HVAC mode is not an OnOffType, so it makes no sense to try to toggle it.

I would be so happy if I had the opportunity to port this binding. I’m actually quite proud of it (I know, pride is a sin).

Oh yes, it is showing up. That error came because of syntax error.
:sweat_smile: Sorry

I’ve learned so much today. :smile:

No, the binding does not require items to be defined. It is just that it will be dynamically created from the front-end of the application.

I was just testing so temporarily changed the type of HVAC. :smile:

Maybe I’m misunderstanding the ESH/OH2 framework but I, at least in my head, equate ESH channels with OH1 items.

Your binding can create many things of different thing-types and each thing has it’s own instance of the channels as described by it’s thing-type.

When you handle the command for the given channel in handleCommand I think it should propagate to the underlying linked item.