Access Keys:
Skip to content (Access Key - 0)
 

Minido - Which protocol do you recommend to link with OpenRemote ?

François Delpierre

On Jan 22, 2012 13:24

Hi,

I'm the happy owner of this very cheap Minido home automation and Alarm system from AnB S.A. in Belgium.
I wrote the decoding part of the Minido using the excellent Twisted network event based Python framework, and a STOMP message broker (Currently orbited) used to communicate between software pieces to transfer data (JSON encoded). This software is called Minido-Unleashed.

I did not yet write any web interface for the latest release (twisted based), and I am really interested in plugging OpenRemote on Minido-Unleashed.

Which protocol should I implement in Minido-Unleashed to allow OpenRemote to connect to it ?

TCP/IP or Telnet ? Where can I find docs for tcp/ip ?
Or maybe is there any message server already in OpenRemote ?

P.S. : It's not possible to think about plugging OpenRemote directly on the RS485 Bus because Minido is extremely simple. For instance there is no way to change a relay state without redefining the 7 others on a 8 relays module, and it's not possible to query the states, so Minido-Unleashed software permanently sniff the bus to build & keep internal state tables.

Regards,

François

 
Labels:
Participants: Eric Bariaux , François Delpierre
  1. Jan 22

    Eric Bariaux says:

    Hello François, The TCP or UDP/IP commands are pretty simple. They take an IP a...

    Hello François,

    The TCP or UDP/IP commands are pretty simple.
    They take an IP address, a port and a string to send.
    They are stateless, each time a command is executed, the connection is established to the given IP/port, the given string is sent and any string returned back by the server you're talking to is the return value from your command.

    So in Minido-Unleashed you could implement something like when you receive

    RELAY-1=ON
    you turn that relay on.
    In OR, you would simply send that string and ignore the return value.

    You could also have a command such as

    RELAY-1-STATUS
    that returns
    ON
    and in OR create a command to use with a switch sensor to have the feedback from a relay.

    Hope this already helps.

    PS: I suppose you're from Belgium, where I'm also located. I'm thinking about doing kind of a "user group" meeting in February. I'll post the details on the forums when I know more.

    1. Jan 22

      François Delpierre says:

      Thanks Eric for your quick reply. The reason why I moved to Twisted is that I r...

      Thanks Eric for your quick reply.

      The reason why I moved to Twisted is that I really want no delay in the update of an event, so no polling.

      I would prefer to avoid reconnecting and/or polling, and have one connection that keeps open, and that also received the updates from Minido-Unleased in realtime.

      That's fun. I in fact discovered the project by looking in the Fosdem Lightening talks. Is it you that make the presentation ? I will certainly join, except if I go for some skiing

      1. Jan 22

        Eric Bariaux says:

        OK, then the best is to implement a custom protocol in OpenRemote. You can leave...

        OK, then the best is to implement a custom protocol in OpenRemote. You can leave the connection open and start a thread to listen to messages from Mindo-Unleashed and update the status cache asynchronously.
        There is not a ton of doc on how to do this but if you're a Java programmer, it's not too difficult, you can look at implementation of existing modules and we can guide you via the forum.

        Yes, I'll be doing the FOSDEM presentation, so maybe we'll meet there.

        1. Jan 22

          François Delpierre says:

          And regarding the telnet protocol, will it work for asynchronous updates ? I do...

          And regarding the telnet protocol, will it work for asynchronous updates ?

          I do not consider myself as a Java developer, but if I have good samples this should not be a problem. Where should I start ?

          I'm looking forward to meeting you in FOSDEM.

          Regards,

          1. Jan 23

            Eric Bariaux says:

            The Telnet protocol implementation in OR will not provide asynchronous support o...

            The Telnet protocol implementation in OR will not provide asynchronous support or stay connected, works the same as UDP or TCP.
            If you implement a custom protocol, you could use telnet, keep the connection open and have a thread listen for incoming messages.

            But if you're implementing the server, I don't see added benefit to telnet (over plain TCP/IP), unless it's easier to implement on the server side.
            (OK, there might be a small advantage to testing the server side manually when using telnet).

            I think the Samsung protocol implementation that Marcus did might be the closest to what you'll be doing when integrating with a TCP/IP protocol. I'll talk to him tomorrow or he might chime in for more information.

            1. Jan 23

              François Delpierre says:

              Ok, Too bad that the telnet protocol do not keep the connection open waiting fo...

              Ok,

              Too bad that the telnet protocol do not keep the connection open waiting for asynchronous updates.

              Well, telnet is just easier to test, and so might be easier to implement with other protocols or systems.

              If I have to start from nothing, I would prefer Openremote to talk JSON over STOMP; this is really made for asynchronous updates, and also easy to debug as you can connect as many clients as you want.

              But all of this really makes sense if the openremote webinterface is using Ajax Server Push/COMET and/or Websockets to asynchronously update the client.

              Is it well the case ?

              1. Jan 24

                Eric Bariaux says:

                As you're implementing a custom protocol, you can easily use JSON over STOMP if ...

                As you're implementing a custom protocol, you can easily use JSON over STOMP if that's the best choice from the server side. There are Java libraries to support both easily.

                I'm pretty sure the OR web console uses server push (and if it's not the case, it should use this or something similar). The iOS and Android consoles do use that.

                Also, just want to stress that the communication with the consoles (UI) and the communications with the devices (Minido in this case) are totally decoupled. So polling on one side does not imply/influence polling on the other side.
                This is particularly important because OR is not only a control system but also an automation system. So for instance rules can be triggered based on status change from a device without any UI being involved.

                1. Jan 24

                  François Delpierre says:

                  Thanks Eric for all these details. So OR is exactly what I need. I'll set up a...

                  Thanks Eric for all these details.

                  So OR is exactly what I need.

                  I'll set up a development environment, and find the right doc. I'hope that I'll find the time next week-end.

                  Regards,

                  1. Jan 25

                    François Delpierre says:

                    Sorry Eric, but I still can't imagine that a modern home automation software is ...

                    Sorry Eric, but I still can't imagine that a modern home automation software is mainly based on polling to get status updates from the home automation system.

                    I have more than 100 devices that might generate events, including presence sensors in the rooms, and window/door opening detector on 3 floors.

                    If I want my light to switch on less than 0.1s after triggering a presence sensor, or get my web page status updated with near to no delay when I switch on a light or open a door, I would have to poll more than 1000 times per seconds permanently ???

                    1. Jan 25

                      Eric Bariaux says:

                      Not sure why you say it's mainly based on polling. If the protocol supports it, ...

                      Not sure why you say it's mainly based on polling. If the protocol supports it, OR will receive async notifications. That's what we do for instance with KNX or Lutron.

                      If you implement the server to push status update as soon as they happen on the physical bus, you can implement the client in OR to receive those without any polling.

                      1. Feb 06

                        François Delpierre says:

                        Hi Eric, Many thanks for your nice presentation yesterday in FOSDEM. As you ex...

                        Hi Eric,

                        Many thanks for your nice presentation yesterday in FOSDEM.

                        As you explained that KNX protocol can sync asynchronous updates to OpenRemote, I'm just wondering if instead of adding a protocol to OpenRemote, couldn't I just build a tcp/ip compatibility module so Minido (in this case) is behaving like a KNX system?

                        The pros are that the new module makes Minido compatible not only with OpenRemote, but with any automation system KNX compatible.

                        The cons ? Is there any cons ?

                        Do you have in OpenRemote other protocols than KNX that currently support asynchronous updates ? X10 maybe ?

                        Regards,

                        1. Feb 06

                          Eric Bariaux says:

                          Hello François, Thanks, go to see you there. KNX is quite a complex protocol, ...

                          Hello François,

                          Thanks, go to see you there.

                          KNX is quite a complex protocol, so implementing a KNX IP stack as a "simulation" layer on top of Minido would be quite a complex undertaking I think.
                          Plus you'll need access to the KNX spec if you want to implement this, which you can only get by becoming a KNX member. You can always take a look at existing source code for KNX clients but still complex.

                          I'm not sure about the way the X10 support is implemented. I think it's older code and will use polling but I might be wrong.
                          The Lutron HomeWorks code uses async listening on the bus.

                          I'm still convinced that a native Minido implementation in OR is the best way to go.
                          Have you already got a server side implemented using JSON/STOMP ?

                          1. Feb 06

                            François Delpierre says:

                            Thanks Eric for this clear answer that definitely close the KNX protocol proposa...

                            Thanks Eric for this clear answer that definitely close the KNX protocol proposal. So KNX is not open as they say, they're in fact closed.

                            The reasons why I'm so shy in adding my protocol to the OR are :

                            • If I add a new protocol to OR this will be a quite high level protocol to link to the minido protocol driver in python, it means that I must reinvent a protocol that certainly already exists. I'm really not fan of reinventing the wheel.
                            • As I'm not a professional developer, digging into the OR code can eat a lot of time, and I would prefer to not invest too much time in the OR code, especially if the main interfaces that I need (web & android) are still in heavy development.

                            Answer :
                            Yes, I have a STOMP server onto which it's easy for me to implements commands such as set / get / or send async updates. As I made some tests to send bigger data sets, including full access to the RS485 bus, I encode the messages with JSON. It's not mandatory to use JSON, but I think it's better, even for simple setter/getters.

                            Remark : I want to keep simple into the protocol, remove everything related to naming & location from the current implementation to only keep the naming conventions used by AnB and our Electrician such as "EXO 5.8" to address the 8th output of the EXO module at the address 5.

                            I see 2 options :

                            • Implement a "mid level" home automation protocol into OR (and minido python adapter called MU), with at least 2 commands for setting and getting status + a third update command that can be received asynchronously, when changes are detected. In this case, I should maybe first try to find an "home automation open communication protocol" before inventing one (even if it's trivial I admit).
                            • Forget about python implementation, and reimplement the protocol driver into OR, in java.

                            The advantage of the first solutions in my point of view are :

                            • Possible Independance from OR (if an other home automation software already implemented "home automation open protocol".
                            • Faster & easier to develop.
                            • Faster to test and debug.
                            • Clear separation between driver and OR, this also ease new setup and testing on new Minido infrastructures.
                            • OR can be shutdown/restarted without the risk of loosing updates from the Minido Bus (as long as the python driver runs).
                            • Free to run many home automation software on the same Minido infrastructure, including OR and current Minido Unleashed release.

                            The disadvantage of the second option, is that it would add a dependency for persistence on the controller such a DB, that's not good.

Adaptavist Theme Builder Powered by Atlassian Confluence
Free theme builder license