Programming ADD-ONS And Contribiution OH

Add-ons Bindings
1

We would like to contribute and add our system eHouse to OH.
Our system is for DIY: eHouse Building Management System and PRO:
controllers are described in eHouse. We have open protocol for communication (binary) however we can write own protocol for OH for text messaging.

Is there any infomation how to start implement communication protocol?

We have several communication variants (LAN, RS-485, CAN, RF, WiFi) and we will supply TCP/IP server for sending commands and receiving statuses and maybe UDP status as we have currently in the system.

We have huge amount of status signals (more than 4000) per common building due to architecture (Large Room Controllers - above 50 each) and security system (256 I/ 256 O) tooks thousends.

We already integrate with OpenRemote and find that querying device very ineffective.
Only update full status to “internal database have some sense”.

Is there a way in OH to update “internal database” directly with all statuses signals from eHouse Server based on RPI to increase performance?

How to start?

2

You should start here paying particular attention to the Binding Tutorial.

I’m not a binding developer but I see nothing in what you have mentioned that sounds impossible in an openHAB binding. For the most part, as long as you follow the defined interfaces you should be fine.

So how I would likely see this working would be that your Binding autodiscovers/creates Things. Things have channels. Your “database” will be this collection of Things and Channels. But this is only one way to do it, you may come up with better approaches.

1 Like
3

Hi,

If you mean updating statuses of the things, then channels, then items, this should be virtually instantaneous with openHAB.At least, this is my experience with openHAB.
What does “eHouse Server” rely on in terms of communication protocols? I mean, what would you like to use between OH and your eHouse Server (telnet, mqtt, etc.)?

Best regards,
George

4

Thank you Rich, George,

I’ll check the links you supply and maybe get some wisdom.

I meant update OpenHab “Internal Status Database” of all channels statuses in as low iterations as possible.
Querying Channels from OH one by one (thousands) via any communication method would be disaster due to performance. Controllers sends regularly statuses (each several seconds or after change). We already tested it with OpenRemote which have similar method (RPI3 90% busy constantly) - with ten times smaller amount of data.

Lets start from the beginning we have eHouse hybrid version integrating controllers:

  • LAN, WiFi (directly receive UDP statuses & send tcp/ip commands) -
  • CAN, RF (via gateway over RS232)
  • RS-485 (full duplex via uart rs232ttl)
  • PRO based on local interfaces (SPI, I2C)

eHouse Hybrid can be run on RPI3 and few other clons and eHouse server software gathering data from all interfaces and pass it further.
So we have:
MAIN THING: HYBRID (All controllers Altogether - thousands of channels combined)
Smaller THINGs:
k*PRO: (more than 2000 channels per controller) outputs (binary) inputs (active, alarm, warning, monitoring, SMS, Silent Alarm, etc)
m*LAN: (about 60 channels each controller) : outpus (binary), dimmers (char), ADCs(int), inputs (binary), IR
n*WIFI: (about 20 channels each controller) outpus (binary), dimmers (char), ADCs(int), inputs (binary), IR
o:RS-485: (about 60 channels each controller) outpus (binary), dimmers (char), ADCs(int), inputs (binary), IR
p*CAN: (about 30 channels each controller) outpus (binary), dimmers (char), ADCs(int), inputs (binary), IR
r*RF: (about 30 channels each controller) outpus (binary), dimmers (char), ADCs(int), inputs (binary), IR

If you mean updating statuses of the things, then channels, then items, this should be virtually instantaneous with openHAB.At least, this is my experience with openHAB.

Best approach would be update all this (combined) statuses in one or few steps to limit communication and increase throughput. Is there a possibility in OH to update complete “thing” status in one iteration (not one channel in single operation) - in any way.

What does “eHouse Server” rely on in terms of communication protocols?

What we already have inside our system:

  • broadcast combined status via UDP to local panels (binary form Android/Java) (in LAN / WiFi architecture)
  • send via tcp/ip (sockets) in local network or internet for our software panels (binary form Android/Java)
  • send combined status as html request to WWW panels (decoded by JS) - data similar as in example below (each line - single room controller)
  • update global status to MySQL databases

I mean, what would you like to use between OH and your eHouse Server (telnet, mqtt, etc.)?

I think the best way for sending statuses from eHouse to OH would be UDP or TCP/IP sockets - as large packets as possible. We are developer of eHouse system so we can write any integration protocol to match already available in OH, or write dedicated one. If there is one efficient method of “global status update” we can write algorithms for that, suitable for OH.

Regarding to sending commands from OH to eHouse it could be TCP/IP sockets. We have opened protocol: eHouse TCP/UDP Communication Protocol and it could be simillar way.

We would like to send combined status of all devices in as smal as possible transfers (queries) due to thousands of (chanels):
Example of status - binary hexcoded - text format: (1 controller each line) - almost one bit is single channel

248025B025C02580261025D0277024D025D024B024B0256024F18080001000000000000000000C000DE006DFEFE0101730000000000000000000000000000000000020002000B00030001000100000001000200020000000000010003000320000000A8010000000000000000000000000000632400E60BFE000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000E
B23701002B025F026103FF03FF03FF03FF03FF5555010000FFFFFFFF0000000000000000000000000000000000000000000000006DFEFE3701730000000000000000000000000000000500020000000500010001000200010002000200030001000200010003000120000000A8010000000000000000000000000000432440E60BFE0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000012
B2370203AE025E025803FE03FF03FF022D01640810000073FFFFFFFF0000000000000000000000000000000000000000000000006DFEFE3702730000000000000000000000000000000200000001000900010002000400010003000300030002000100010004000320000000A8010000000000000000000000000000422400E60BFE0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010
B237030044025F025B039E039803ED03FF036C0000000C00FFFFFFFF0018000000000000000000000000000000000000000000006DFEFE3703730000000000000000000000000000000000020001000500030001000100010003000300030001000200030002000220000000A8010000000000000000000000000000422400E60BFE0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010
FF55FF5500C8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005555555555555555555555555555551500000000000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0000000000000000000000000000000000000000FFFEDFFDFFFFFFFFFFFFFFFF00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000FFFEDFFDFFFFFFFFFFFFFFFFFFFFFFFF00000000000000000000000000000000555555555555555555555555555555150000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Any sugestion how to do it efficiently?

Regards,

Robert

5

I read that as “we don’t want OpenHAB to be polling our system”, that’s fine.

One approach would be as you suggest, send a compacted form of whole system status from your system to OpenHAB, and create an OH binding to unpack that into OpenHAB channels etc.

Another approach commonly seen in home automation is to send only changed status. You might use a new proprietary protocol, or use one of many existing methods. Using some existing method would give your system benefits beyond OpenHAB.
Perhaps it is worth a look at how existing bindings work between similar systems - OpenHAB to Homematic for example

6

thanks rossko57, we will check this.

I read that as “we don’t want OpenHAB to be polling our system”, that’s fine.

It can be pulled by OH but for full status, or large part of it (at least controller - thing) not channel/signal.

Mechanism of sending information from system only about changes via UDP, is not quite sure.
You can loose data, that’s why we send complete status. We don’t wont to relay on network protocol issues.
Other way any connected panel (no limits with UDP) has complete information about state of the system (even, after wakening from sleep, loosing communication, missing packages, without additional communications, etc).

One approach would be as you suggest, send a compacted form of whole system status from your system to OpenHAB, and create an OH binding to unpack that into OpenHAB channels etc.

Is there any example or similar interfacing for doing this?

7

So I’m not a binding developer so take anything I say as an educated guess based on observation of how other bindings work.

Things do not usually individually pull status from the devices on their own. So it isn’t like you will have 4000 OH Things each individually polling your device for a status update. I agree, that would be a disaster.

Your binding will communicate with your device however you decide to implement it. The binding can pull over all the statuses as one message, parse it locally, and then update the status of all the Thing’s Channels as one transaction. There will be some work in parsing the status message and posting the status updates to the Thing’s Channels but you would have that work if you were saving them to some internal status database.

You have full control over how this works and can implement how the Channels get their information however you want/need to.

But there is no separate “internal status database” in OH. The “database” IS the Channels.

Some example approaches that might be helpful:

  • zwave binding I think works much like I describe above
  • the HTTP binding will query a web page then cache the result, the Items then pull from this cache instead of the original web page (NOTE: HTTP binding is a 1.x binding so does not use Things and Channels)
  • I think the Socket binding, also a 1.x binding, implements a similar caching approach

Look at how other bindings that seem to work the same way as described. I’ve provided three potential candidates, rossko57 provided another one.

8

Thanks Rich,

I’m during the installation of prerequisities of development.

If any one else know good example please let us know :grinning:.

Regards Robert,