Is it allowed or is it wise to program logic into binding. For instance I want to collect data from devices over time, perform some analysis on them to make decisions in the binding.
And is it possible to use tools such as WEKA in bindings.
A binding should be dedicated to updating items’ state and forwarding openHAB commands to underlying devices. But the use case you mentioned sounds like the intended uses of persistence services and rules in openHAB. Weka seems like a tool that could be integrated in various ways in openHAB, but having it tied into a single binding may not be the best choice, since it would be more interested in receiving live or historical states from multiple sources.
Oh okay, So what do you suggest I do.
You could start by writing down use cases for problems this will solve, and then creating a logical diagram of how you need data to flow in order to achieve your goals, keeping in mind the openHAB architecture. Then learn about the ways Weka can get data, and how openHAB’s persistence bundles can get it to Weka, possibly by directly addressing the database. I can’t be more specific than that, but I wish you the best luck, and please publish your creation when you’re ready!
If I got you right, do you mean I need another binding.
Most likely not, but I don’t know or understanding what end goal(s) you are interested in reaching. I am not able to delve into it with you, but perhaps others here could assist with pointers and ideas. All the best!
I want to apply machine learning to data acquired from devices.
1 Like
Looked into Weka briefly and completely agree with watou, this isn’t something you want to include in an existing binding. Far better to either interact with it through an existing binding or create a separate Weka binding. OH works by providing an abstraction layer between specific technologies so one can create rules and store data the works seamlessly across them all. If you embed Weka into a single binding it violates that design principle.
I’m of the firm opinion that if a binding already exists that is suitable, it is by far preferable to use us that then write a new binding. In this case it looks like Weka is primarily a library, not a stand alone service with an API. That makes things a little more challenging.
I don’t know if this sort of capability fits into the architecture very well, at least for OH1. OH1 is designed around the rules engine being the thing that makes decisions based on the state of Items (or time) and it causes actions to occur through the Items. If I understand what Weka does, it doesn’t really fit into this architecture. I really don’t see how one would bind Items to the library in such a way that it can learn and drive behavior in the ways it would need to.
What others have done which does fit this architecture better would be to create a separate Weka server that either has data pushed to it from OH (e.g MQTT messages) or reads the data from OH’s persistence (MySQL or find an ODBC driver for one of the other supported OH persistence approaches), does its thing, then publishes commands back to OH (MQTT, REST API, etc).
Search this forum for “machine learning” and I think you will find at least one thread where people are discussing their approach. You might also search for “voice” and there are several threads that discuss adding voice commands to OH which feels like a similar problem.
You could also create an action addon which could expose some high level Weka functionalities as actions within the OH rules engine. Then you would be able to compose these together from your rules.
See: