openhab - best approach
i try to use openhab with my neuron 203.
so far there seems to be only the possibility to use the openhab modbus binding. and if i read correctly one would get not the full functionality of the neuron ...
- did someone do the modbus binding ? did it work ?
- with modbus, what features are useable, which are missing ?
- is there another possibility ? a binding for evok f.e. ?
- if not - has somebody sample code that would help developing such a evok binding ? preferable in java/groovy ...
We are now in the process of developing our own binding for Neuron, though it may take some time before it is ready.
If you cannot wait any longer you have a couple of options (besides Modbus) - writing a SYSFS binding (look at the GPIO binding for inspiration), basing the binding on WebSocket (look at Loxone for inspiration) or using MQTT (can be used out of the box, but requires using a third-party MQTT-EVOK plugin, which you can find somewhere on the EVOK forum).
For the Modbus binding I would recommend looking at the Wago binding implementation, which is based on Modbus and should provide a good starting point for development.
Is there any news on the Openhab binding so far?
Alternatively, say I want to have Openhab running on a unipi neuron module, can I use Modbus TCP to communicate between the Unipi and openhab?
- both are on the same device and use the same IP adress, is this a problem for the modbus TCP?
- if not, does there need to be a router connected to the device for the modbus TCP or can the device run on itself?
Hello @thenoobiniser and welcome to our forum!
Unfortunately there are no news about the openHAB binding, but it is definitely on our todo list.
In the mean time, you can use the openHAB's Modbus binding together with our Modbus TCP server. But that requires deeper knowledge of how the Modbus works in order to not get lost in the implementation. Now to your questions:
- No, openHAB can directly run on UniPi, but the response may be slow, because it is a quite complex Java application.
- UniPi doesn't have to be connected to router and can run completely without network connection.
@martin-kudláček I have several implementations of Openhab on Unipi and it works pretty fast regardless of Java (Zulu or Oracle) and number of bindings. I use simultaneously i.e.HTTP, Zwave, Astro, MAX! and other bindings. CPU is at 2-5%. In next few weeks we will play with Modbus binding in order to manage some air-conditioners. Now we are just waiting for delivery of Modbus serial gateway. So I will let you know then.
could you share more information how you use the UniPi with openHAB? What protocol do you use for communication? How does it look with response speed?
Thanks for the answers in advance!
@martin-kudláček I use Evok and Openhab HTTP binding in order to querying data from Unipi and sending commands. Below is an example of response times from Openhab log in case of sending request for 2 relays.
2018-09-26 22:00:00.202 [ome.event.ItemCommandEvent] - Item 'UnipiRelay1' received command OFF
2018-09-26 22:00:00.243 [ome.event.ItemCommandEvent] - Item 'UnipiRelay5' received command OFF
2018-09-26 22:00:00.354 [vent.ItemStateChangedEvent] - UnipiRelay1 changed from ON to OFF
2018-09-26 22:00:00.368 [vent.ItemStateChangedEvent] - UnipiRelay5 changed from ON to OFF
So the response is within 1-2 tenths of second. The same with querying of digital outputs.
There are also many additional services running on Unipi at the same moment like Apache2, DynDNS agent, Raspbian desktop, VNC server, SSH server...
from the log you have sent I can see the difference between sending command to turn off the relay and the actual turn off is approx. 130ms. Is that correct?
@martin-kudláček yes, correct.
@tja regarding Openhab Modbus binding...not easy to setup but fully functional.
Hi....On the off chance that you need to depend on a steady framework and find support in a crisis case the main route is to ask the network and ideally they will support you, if not. you can help yourself are the issue won't fixed.
In my ealry days I attempted to not depend on these open source frameworks because of the missing profound help as referenced in the first post.
Be that as it may, OH is so cool and from my perspective truly steady and relyable. Very day a great deal of new stuff is comming and a ton of more gadgets and capacities are actualized.
Indeed, we as a whole are simply working here in this network for nothing and attempt to support every others and the is no genuine countable assistance.