I have an unsupported home automation system based on RS-485 (Minido from AnB), and I would like to integrate it with OH2. I need help to take a decision between the 2 choices that seems available to me:
Develop a new binding in Java of OpenHab 2
Develop an interface via MQTT
Minido from AnB is extremely basic, and requires permanent recording and interpretation of the messages on the bus to get state of the relays. So I need very low level interaction with the bus, and a persistance layer with history. I’m confortable with it as I wrote a Python back-end, and a MeteorJS one, around ZMQ to handle the different systems on the same RS485 bus adapter.
Here are the pro & cons I see by choosing the 2 solutions.
Develop a new binding in Java of OpenHab 2: Pro:
Auto Discovery possible
Much easier setup for other Minido owners Cons:
I’m occasional developer and I did not develop in Java for ages.
I do not have much time to learn Eclipse and experience Java
Develop an interface via MQTT Pro
No coding in OH2 nor Java.
I’m far more comfortable in Python with list comprehensions, shell and flexibility on strings. Much more accessible. No need of complex IDE, and local workstation setup. Vim on the Server is perfect.
MQTT could be used for other integrations. Cons
I might face new limitations on top of the discovery.
Requires external persistance layer such as Mongo or SQL db.
More complex architecture setup (especially for new users)
Do you have any tip, or do I miss some options?
Can we develop an OpenHab 2 binding with Jython?
Sorry of, but it’s reach to users would be roughly the same as your MQTT solution. The JSR223 Rules let’s you write rules in Jython which means you can implement something as complex as a binding as rules implemented in Jython, JavaScript or Groovy. But it won’t show up in the list of bindings in PaperUI and it really won’t have access to the core apis of OH that are available to a binding. Eventually you will be able to make something like this available through the IoT Marketplace add-on but I don’t think it supports JSR223 libraries yet.
What do you need an external DB like Mongo for? You wouldn’t have that as a binding anyway, though embedded databases are possible.
Personally, I would say implementing it as a new binding would be most useful to OH users over all, but many if not most of us use MQTT already so making it a separate program is not that huge of an imposition.
You confirm that writing Bindings must be done in Java.
Bindings does not provide an integrated & easy persistence access. I’ll have anyway to build mine.
using MQTT is not uncommon.
What do you need an external DB like Mongo for?
To answer the question, I’ll try to describe shortly AnB Minido:
Minido is so simple/limited that there’s no way to query relays states. It works as such:
The RS485 bus is limited to the electrical distribution board, where several EXI (32 buttons inputs each) talks to up to 16 EXO (8 relays outputs / dimmers):
The EXOs relays modules do not support query, and only accept 1 packet that will redefine all 8 outputs.
All the EXIs permanently sniff the RS485 bus activity from other EXIs to record the 8 states data blocks for the 16x8 relays. As when EXI is asked to change 1 relay state on 1 EXO, it must have recorded previous activity to know the state of the 7 others relays, in order to build the packet that will redefine the 8 output states on the EXO, and only change the desired one.
As you see, Minido from AnB is as simple as cost effective, and won’t suffer much of any obsolescence even if AnB would disappear. But this also requires a persistance layer to record all activities and maintain a picture of the current states. I already made 2 implementations, one with Mongo, one with MySQL, and a document oriented DB is an excellent choice for the use case.
I’m still testing on how to create OH2 binding. But struggle a bit. Without result in the next 1-2h, I’ll switch to MQTT. Thanks,
Typically this is only needed if the binding needs to make decisions. In a typical configuration it’s OH that makes such decisions and all the bindings needs to do is report updates and changes to states. The bindings usually don’t have to care about history or anything like that because that isn’t their job. OH itself provides persistence to it’s users for those who need it so the bindings leave this job to the persistence part of oh.
The above is true whether you will it as an external app or as a binding. You want OH to be making t the decisions and have access to the history because OH has more information (i.e. all the other bindings information).
Auto discovery should be possible with an external MQTT application, too. Just publish your messages with “retain=true”.
You should implement one of the MQTT conventions like Homie though. This way you will get autodiscovery and a native binding feeling for OH2 as soon as the Homie Binding is merged.
You don’t need a DB for some boolean relay states in your python app, do you? Keep a list in memory. If really necessary, write a simple bit list to disk, and read it again on program start.
Thanks David, I’ll investigate this direction that seems finally the best one (for me).
In the meantime, I’ve been able to replicate the Java examples to create bindings, but still not clear how to receive updates.
The bindings usually don’t have to care about history or anything like that because that isn’t their job.
I totally agree. The history is not required to do any decision, it’s required to know the last state of the 8 relays on a board. Let’s say I want to switch the Relay 7 from OFF on ON. I cannot do this with Minido, I have to create a packet that overwrite all other relay states as well. So, I’ll not send something like:
XX XX XX XX XX XX FF XX
But I MUST know what to put in place of the XX, it’s important for me to know the last packet sent to his EXO, otherwise I risk to change status of other relays.
That’s a bus with multi senders, and multi receivers. So, an other Sender might have sent:
00 FF 00 FF 00 FF 00 FF on the bus before me. If I want to turn the relay 7 from OFF on ON, I’ll take the last sniffed packet, and will modify it accordingly:
00 FF 00 FF 00 FF FF FF
. I cannot act on only one output, but all 8 at a time. That’s a limitation of Minido RS485 Bus implementation.
If all you care about is the last packet sent, then a separate DB is WAY overkill, even for your separate application. I highly recommend David’s suggestion to solve this.
I wonder if you have made any progress on development of binding for Minido.
I am facing the same challenge, and I am also happy to help in development,
since I am software engineer.
