Create binding for Eclipse SmartHome/OpenHAB

sfeilmeier commented 7 years ago

Bug Report or Feature Request (mark with an `x`)

- [ ] bug report -> please search issues before submitting
- [x] feature request

Bug description or desired functionality.

There should be a binding for OpenHAB that enables a user to easily integrate OpenEMS in his smart home system.

martingruening commented 4 years ago

There is already a (not straight) way how to get OpenEMS data into OpenHAB. Configure InfluxDB in OpenEMS-edge, setup Telegraf as Influx Listener for OpenEMS (input), configure Telegraf to send data to a MQTT broker (output), subscribe OpenHAB to the MQTT topics.

I believe bringing native MQTT publishing to openems-edge would be a more versatile approach than doing an OpenHAB-specific integration. This way you could integrate with basically any home automation / IOT service.

sfeilmeier commented 4 years ago

Wow, this is an interesting and creative way of sharing data with OpenHAB. I had not thought of that.

I had been working more intensively with OpenHAB in the past and I was hoping to find some time to develop a more advanced integration between OpenHAB and OpenEMS that allows autodiscovery and advanced sharing of channel- and meta-information.

Nevertheless the MQTT publishing is interesting. I am not an MQTT expert, but it is obviously a technology that I read about frequently. There has been some discussion about MQTT in the Community Forum in the past (https://community.openems.io/t/mqtt-implementation/133/12, https://community.openems.io/t/proposal-connect-openems-to-openems/231/8). Can you describe how you would need OpenEMS to publish data via MQTT? I assume OpenEMS Channel-Addresses would have to be mapped to MQTT topics, right?

martingruening commented 4 years ago

MQTT has a hierachical, directory-tree like topic structure. Looking at the fields fed into InfluxDB this would be simple to adapt to a MQTT topic structure: /openems/edge/#uniqueid/sum/ProductionActiveEnergy /openems/edge/#uniqueid/meta/version /openems/edge/#uniqueid/pvInverter0/ActiveConsumption (and so forth) My software development skills are dusted. But I would think that abstracting the code that dumps the data into InfluxDB, replace the methods for connecting, submitting the actual data and error handling with the Paho MQTT client and it should be done. If @clehne would write the code as proposed in the thread above I would be happy to test it and write a short tutorial how to integrate that in OpenHAB (and publish that in the OpenHAB community forum).

The integration in OpenHAB would be straight forward - this is the OpenHAB 'thing' that would do it:

Bridge mqtt:broker:mosquitto [ host="localhost", secure=false ]
{
    Thing mqtt:topic:openems {
    Channels:
        Type string : Version "OpenEMS Version" [ stateTopic="/openems/edge/c471b282d/meta/version" ]
    }
}

The good thing is: that would work in a similar way with the majority of the Smarthome systems.

ljonka commented 4 years ago

Hey guys we (Felix@Consolinno Energy) are currently working on mqtt publishing feature in openems, its already sending data so its maybe of interest here before somebody start implementing it.

sfeilmeier commented 4 years ago

@ljonka Thanks, good to know. Is this development public, so that we could have a look and contribute?

ljonka commented 4 years ago

Yes, it will be published.

Am 23. Oktober 2020 12:58:18 MESZ schrieb Stefan Feilmeier notifications@github.com:

@ljonka Thanks, good to know. Is this development public, so that we could have a look and contribute?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/OpenEMS/openems/issues/33#issuecomment-715269364

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

DerStoecki commented 3 years ago

@sfeilmeier Hey Stefan, Took me a while to address this situation (had a lot of things to do) The Code can be looked up right here

https://github.com/ConsolinnoEnergy/openems/tree/feature/MQTT/io.openems.edge.bridge.mqtt

Please note, that the Version of OpenEMS itself is a bit old...

The moment I have more time, I'll get the current dev branch and will integrate the MQTT Code there (will be an extra Pull request)

sfeilmeier commented 3 years ago

FYI: I am also working on an MQTT implementation - but with a different purpose #1395

DerStoecki commented 3 years ago

yes i've just received an email :) I ll update the Branch soon. I reworked my implementation quite a lot and it's just in our gitlab repo yet. I'm not available next Week due to personal reasons but I take a note and I hope to find the time to start a PullRequest with an updated MQTT branch the following Week. I'm sorry i takes so much time. But stay tuned we are planning to do some more pullrequests in the future; there's still a lot going on but we'll see. Thank you for your patience.

martingruening commented 3 years ago

Awesome. I would be fan of the edge component publishing channel updates to MQTT topics. That would make integration into Home Automation system extremely simple compared to JSON-RPC over Websocket. I am volunteering to test drive a first build here in my setup. I started an OpenHAB binding, but stalled due to a lack of time. MQTT publishing would remove the need for that extra effort.

Please consider publishing the edge configuration (especially the list of available channels) to a special topic, so that the MQTT topics can be 'auto-discovered' by a little bit of extra logic on the subscriber side.

sfeilmeier commented 3 years ago

@DerStoecki: Ok, thanks for your reply. The quality of your branch looked very good at first sight and I am curious if we could share/reuse some common code. Some interesting additions in my code are:

use MQTT v5 (had to wrap the Paho bundle for that, because some Manifest headers were missing)
with MQTT v5 I am able to set an expiry interval for Channel data (set it to 60 seconds now for first try) (as I am publishing values only on changes I will have to write all values once within these 60 seconds)
implement an MqttConnector in io.openems.common, that makes sure a connection is opened even if it fails on first try (i.e. because the broker is not yet available)

@martingruening: Thanks for your feedback. I am still rather new to MQTT and happy to implement some useful features and best practices. My initial purpose was to replace Edge to Backend communication with first priority - i.e. use publish/subscribe where feasbile (i.e. individual channel values, EdgeConfig data (as one big JSON-blob), System-Log when activated,...) and a request/response mechanism for wrapping the remaining existing JSON-RPC requests (like create or reconfigure component,...).

What's working already in the branch is, that all channel values are published on each update to: edge/{Client-ID}/channel/{Component-ID}/{Channel-ID} Additionally the current timestamp is published in each Cycle: edge/{Client-ID}/channel/lastUpdate

Is this ok? Should I add e.g. "openems" as a prefix to be compatible with such home-automation brokers that collect data from multiple devices? What is best practice there? With this setup you can already subscribe to edge/{Client-ID}/channel/# to get all channel values.

For 'auto-discovery' in a sense similar to what OpenEMS UI is doing, i.e. knowing "meter1 and meter2 are production meters, meter3 is a consumption meter" the EdgeConfig channel can be used. I am planning edge/{Client-ID}/edgeConfig for that. It has all the information, but is maybe rather heavy to process. Would you need anything else?

martingruening commented 3 years ago

@sfeilmeier Stefan, I think your approach is spot on. Publishing the JSON config to a ../edgeConfig topic is a good way to publish it for consumers. The way you are laying it out it would make it very easy to use it with OpenHAB and other home automation frameworks and the Telegraf/InfluxDB ecosystem. MQTT v5 is also a good choice. Please make quality of service setting for message delivery configurable.

Will you buffer messages to be published if the MQTT broker connection becomes unavailable? That would help to not lose any data if for instance the MQTT broker service needs to be restarted. From my experience it would be good to do that and buffer 5 Minutes worth of data as a default (should be configurable). If the broker connections then becomes available again, the buffer should be flushed.

sfeilmeier commented 8 months ago

We are moving all discussions to the OpenEMS Community (https://community.openems.io/), to have them in one central place. Please feel free to open a thread there.

The topic discussed here is still on my ever growing ToDo-list.

OpenEMS / openems