ioBroker support.

[GermanBluefox]

Can you imagine the support of ioBroker additionally to openhab?

[peuter]

If someone is willing to implement, maintain and support that feature, we will be happy to accept any contribution to support new backends.
But the usual way to go including new backends is by augmenting them to support the CometVisu protocol (that how it has been done with openhab: the changes where made on openhab's side and not on the CometVisu side). So actually you should ask on the iobroker side if someone is willing to add CometVisu support.

[GermanBluefox]

I could find some information about transport. http://cometvisu.org/CometVisu/de/latest/manual/devel/index.html#grundlagen-der-software

But I cant see any commands. How the read/write command looks like ?
May be you can show code for communication?

[peuter]

There exist a protocol definition where the communication details are explained:
https://github.com/CometVisu/CometVisu/wiki/Protocol

[Apollon77]

I checked the docs and they are partially a bit cryptic. Is there any way to get some example messages for e.g. KNX or also OpenHab without installing one of thos systems?

[peuter]

Well the examples are part of the docs (Hint to improve the docs are always welcome).
Here is a simple example:

1. After initial loading in the browser the ComerVisu sends a login request (HTTP GET) as described here https://github.com/CometVisu/CometVisu/wiki/Protocol#Login. All parameters are optional. The backend URL of the "login-page" is either hard-coded in the cometvisu (for known backends) or can be send via HTTP-Header, when the config file is requested.
   -> The backend responds with a JSON message containing a session id a the used protocol version (currently 0.0.1):

{
  "v":"0.0.1",
  "s":"SESSION_ID"
}

The backend can add some configuration options to the response like the URLS for the upcoming READ and WRITE requests, but I will leave this out for now and stick to the basics.

2. If the login request has beed answered successfully, the client send a read request (HTTP GET: https://github.com/CometVisu/CometVisu/wiki/Protocol#read) telling the backend which items its interested in (those are either item names if its the openhab backend or KNX-GA's if its the default backend). The addresses are appended to the querystring e.g. /r?s=SESSION&a=ADDRESS1&a=ADDRESS2&a=...&t=TIMEOUT&i=INDEX

Currently there are two different ways of transport layers used for these read requests:

1. Long-Polling: used by the default backend. The read request gets closed after the backend did send an answer and re-opened immediatly to wait for the next answer.

2. Server-sent-events: used by the openhab backend. The read request stays open and the backend can continue to send updates

3. Write requests (HTTP GET: https://github.com/CometVisu/CometVisu/wiki/Protocol#write). The client send a value to at least one address e.g. when the user hits a button:
   /w?s=SESSION&a=ADDRESS1&a=...&v=VALUE. The backend responds with a HTTP status code to tell the client if the request has been successfully processed.

Thats it, the other stuff like filters is optional and currently not implemented by any of the existing backends.

If you need more details our gitter chat might be the better place to talk: https://gitter.im/CometVisu/CometVisu_DE

[Apollon77]

Thank you very much for these additional information!

One last question: From where do CometVisu gets the list of all available addresses to let the user chooose what he wants to have? or do the user need to enter the correct IDs before?

Server send events are interesting. How does they work? Don't found protocol for this so far (or too blind) :-)

[peuter]

Searching for server sent events should give you plenty of information as all modern browsers implement that feature: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

The user has to create a config file, which describes his UI. Thats where the addresses are in. Creating this (XML-based) config file can be done either with any XML-Editor (with schema support to prevent syntax errors) or with the build-in editor. This editor uses dome data-providers to get a list of available addresses (thats something the backend also should provide to fully support the cometvisu).

[ChristianMayer]

@GermanBluefox and @Apollon77 would a MQTT support help?
The new version 0.12 comes with MQTT support

[Apollon77]

I think basically yes, but in fact each user would need to configure and build that himself, but yes iobroker can offer an MQTT server or client and can publish all available data