I’ve been thinking of creating a binding that will need access to the channels from another binding. To be concrete:
I’ve set my lights to turn on to a certain level during the day and adjust at 1 percent increments. So at 8AM they’re at 10%, at solar noon they’re at 75% and in the evening they’re back down to 12%. Different rooms are set at different levels based on their usage and how bright the lights are in there.
As of right now I’ve built a web service that I hit via a rule to determine what the appropriate light level is for that time of day based on my locations sunrise/solar-noon/sunset values. I’d like to move that from the separate webservice into an openhab2 binding.
My question: I can’t for the life of me figure out how to access channels from other bindings. In this case, the Astro binding would be perfect as it already has the solar time info.
What are you trying to do? If you want the set or get the state of an Item, you would need to link that item to a thing of the binding. Or did I misinterpret?
I want to create a few Items whose values are based on data from different Item(s).
Concretely:
I want to use the Astro binding to tell me when sunrise is.
I want to create an Item that says turn the light on to 30% at sunrise. At sunrise + 5 minutes it’s 31% and on and on.
While that part sounds easy, there’s a but more to the binding I’d like to do. So I do not want to make rules for this as the logic is something I actually want tested. Unless you can use jars in rules.
That could all be done by a rule with several timers.
Pseudo code:
Trigger is sunrise(astro sets an item to true at sunrise.
The first say command comes immidiatly.
For each time step use a timer with a delays of 5, 10,… minutes which will call the respective say command.
[ERROR] import org.eclipse.smarthome.core.items.ItemRegistry;
[ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ERROR] Access restriction: The type 'ItemRegistry' is not API (restriction on classpath entry '/Users/holmes/.m2/repository/org/eclipse/smarthome/core/org.eclipse.smarthome.core/0.9.0-SNAPSHOT/org.eclipse.smarthome.core-0.9.0-SNAPSHOT.jar')
I still might be on the wrong track. As far as I understand a binding knows the state of each item that link to a channel. In this case the binding only reads the channel. I’ll get deeper knowledge on that in the next days, because I’m going to implement such. So I’ll report back.
@opus What I’d like to do is access data from the astro binding in a completely different binding that I’m creating.
It looks like I can look up items via the ItemRegistry but I was having problems using it. I think I may have fixed those w/ a change in the manifest mile.
I managed to create a channel in my binding that expects a switch item to be linked to. The channel has no setting for “readonly” as opposed to my initial assumption.
The handler for that thing uses the handleCommand routine to treat an incoming command of that channel.
Wouldn’t it be better, to just have an input channel in your binding, which is set to the value of the Astro binding (with a simple rule)? You wouldn’t create an inter-binding dependency with that.
Just for info, the binding knows nothing about items - only channels. This is a change from OH1 where the binding new about items. It means that the binding doesn’t know how a user has configured their items.
Yes, I should have phrased that better. I wanted to point out that there is a way to get the information of another binding to the binding in question. And this way is via channels onto which an item is linked. Astro could set the item via a channel and the other binding could read the same item via its own channel.
…and I was trying to point you in that direction while doing it first time myself.
Have a look onto Github, my PullRequest is still open. (https://github.com/openhab/openhab2-addons/pull/2456).
The hiligthed changes in the code created a channel which reads a switch item if it is linked to the binding. The change to another type should be easy.
Once you have that you can link this item to another binding which is writing/setting the item.
So far I only used the manual setting of the linked item myself.
There should be no difference for “reading binding” if a switch is set manually or by something else.
For this specific problem, I’d prefer the rule (I used that code in the binding, but that was decided against before it got merged).
Went through the setup of caldav using a google-calendar (see here).
Linked the item that was switched by the calendar to the Webservice of the Tankerkoenig binding …and it works as expected!
