Protocol agent for ORv3

Designer 2.5
1

Hi Guys,

I like to write protocol support for ModBus, I thought of writing a stand-alone deamon and integrate it with OR over socket mechanism (could work for both 2.6 and 3), though building a direct protocol service for ORv3 looks also attractive. Especially, as I find the idea of web components in ORv3 giving freedom of building user interface quite interesting.

I have couple of questions which if answered would help me to go further.

  1. Do you call protocol agent fuctions synchronously or asynchronously? If the latter then how many commands do you post before getting responses - Do you enforce any limit? If synchronous call is only supported then building stand-alone service is a must due to ModBus response time in the range of miliseconds.

  2. Do you have example implementation of client agents? Like Socket or TCP Client. In the ORv3 repository I found only server-like agents.

  3. Can I use 3-rd party web components and in their back-end Java fuctions communicate with OR core functions (read sensors & post commands)?

  4. When do you plan to release beta of ORv3.

Best regards,

Michal

2

Hi Michal,

ORv3 is the definitely the way to go but the docs and JS APIs for the UI web components is still on the TODO list unfortunately.

The backend (aka. the manager) is becoming quite mature though and this is where a protocol implementation would live.

I don’t know Modbus (still have some hardware sitting on my desk that I’ve been meaning to play with but not had time)…yes you could write a generic Modbus to TCP/IP server/gateway daemon but I have a modbus TCP/IP module here so sounds like re-creating something in software that exists in hardware. There are a few java modbus libs around jmodbus and jamod are the ones I’ve come across (another community member did some work creating a 2.x Modbus protocol a few years ago using jmodbus which can be shared I’m sure).

ORv3 is working and usable now, you can follow the readme/wiki and get it running in docker containers (the images on docker hub are out of date though so will need to build images from source but all explained in docs).

Regards,

Rich

3

Hi Rich,

I do have Ethernet to Modbus box on my desk as well. I also do know the library proving ModBus protocol handling tunnelled from PC to this box and further ModBus device.

It is matter of building a wrapper around this library to have nice interface for asset handling in OR.

Best regards,

Michal

W dniu sobota, 7 kwietnia 2018 23:05:20 UTC+2 użytkownik Richard Turner napisał:

4
  1. Do you call protocol agent fuctions synchronously or asynchronously? If the latter then how many commands do you post before getting responses - Do you enforce any limit? If synchronous call is only supported then building stand-alone service is a must due to ModBus response time in the range of miliseconds.

For a protocol implementation, the SPI is Protocol.java and you would most likely want to extend https://github.com/openremote/openremote/blob/master/agent/src/main/java/org/openremote/agent/protocol/AbstractProtocol.java which helps you with a thread-safe implementation. See the Javadoc of both for more details. Your protocol implementation can schedule tasks for asynchronous, repeated execution or manage its own sockets.

  1. Do you have example implementation of client agents? Like Socket or TCP Client. In the ORv3 repository I found only server-like agents.

Richard did a lot of protocol work recently and maybe can pick a good example for modbus, maybe have a look at extending HttpClientProtocol.

  1. Can I use 3-rd party web components and in their back-end Java fuctions communicate with OR core functions (read sensors & post commands)?

In OR3 you should always try to use the Asset model and API. With the API you can create/read/update/delete assets and their attributes, however most of the time you dispatch AttributeEvent(s) that read/write the state of a single asset attribute. On the backend you can write rules code in Groovy which reacts to AttributeEvent(s) and may also dispatch AttributeEvent(s).

An instance of a protocol (and you can have several in larger installations) is linked to potentially many asset attributes. The job of a protocol is to receive and dispatch AttributeEvent read/writes, translating them from/into sensor updates and actuator commands. Protocols may also merge/delete whole assets if they can auto-discover their attached asset network.

The or-* web components use the Asset model and API, have a look at https://github.com/openremote/openremote/blob/master/deployment/manager/consoles/master/examples.html

If you write your own web components, you can extend and mix with the OR components: https://github.com/openremote/openremote/tree/master/deployment/manager/consoles/customerA

There is another way integrating 3rd party web components which need their own backend API, or any other service for which you need a custom HTTP endpoint: Extend AbstractHttpServerProtocol, write a custom endpoint, and translate GET, POST, etc. requests into asset operations, merging/deleting assets, dispatching AttributeEvent. Imagine you have a simple HTML form on the frontend and when the user submits form-encoded data, your Protocol implementation’s HTTP endpoint will get the POST and you can then turn the message into an AttributeEvent.

5

Thanks Christian,

I took a look at the AbstractProtocol.java file, and I think that some examples from Rich would definitely help to better understand how to write and configure protocol agent.

Best regards,

Michal

W dniu sobota, 7 kwietnia 2018 21:53:16 UTC+2 użytkownik Michał J napisał: