are you aware about any binding possibility for BBQKees EMS Gateway which connects in parallel of your thermostats and allows to control of your boiler and home thermostat for various vendors like Buderus, Junkers, etc.?
Interesting.
From what I read you can use mqtt to interface with openHab.
Should not be to complicated - but I have not used this device, so I´m not able to help you further.
Yes, that is my idea that I will check in existing Domoticz plugin for available messages and commands, but just wanted to check if something already didn’t exist for openhab as well as I think that Buderus and Junkers boilers are very common…
Connecting the device was straight forward, you can simple plug in the cable into the service connector
Connecting to the WiFi is easy, it spans a hotspot where you can configure the SID etc.
My boiler was unknown to the firmware, it showed up as unknown. Developer fixed this within 30 minutes and provided a build for it. Very impressive!
Configuring MQTT and connecting to mosquitto worked as expected
Connecting to openHAB is easily been done:
configure the gateway to support the HA auto discovery
In openHAB create an MQTT thing based on Home Assistant MQTT Component
openHAB then auto-discovers the gateway with its things (e.g. the boiler).
Where I currently struggle is that certain Number channels deliver a blank space as a value and OH complains that this is not valid.
But that is likely to be a misconfiguration from my side as I did not have the time to dig deeper into it.
Before connecting to OH a think you should let the device run for some hours so that it captures all available channels (At least for me not everyting was shown immediately).
Then start with some channels first, do not link then all at once, as this makes it hard to figure out what might be wrong (see above).
As soon as I find some time I’ll write an how-to describing the steps in detail.
So overall my impression is quite positive, it works as promised and it does not rely on calculating the secret keys as required for the KM200 solution, making it more stable against firmware changes because it connects directly to the bus. In addition it does not require a special binding, MQTT can be used.
Shifting from KM200 to EMS-ESP is a bit work as you have to recreate many things. But you can run the km200 in parallel which makes it easy to do it step by step.
Guess I found the reason for the errors shown:
According to the mqtt binding documentation the “climate” component is not yet supported.
This causes some exceptions showing up in the log:
2021-01-11 16:34:55.916 [WARN ] [mqtt.homeassistant.internal.CFactory] - Not supported
java.lang.UnsupportedOperationException: Component:Climate not supported yet
at org.openhab.binding.mqtt.homeassistant.internal.ComponentClimate.<init>(ComponentClimate.java:38) ~[bundleFile:?]
at org.openhab.binding.mqtt.homeassistant.internal.CFactory.createComponent(CFactory.java:69) [bundleFile:?]
at org.openhab.binding.mqtt.homeassistant.internal.DiscoverComponents.processMessage(DiscoverComponents.java:99) [bundleFile:?]
at org.openhab.core.io.transport.mqtt.internal.Subscription.processMessage(Subscription.java:85) [bundleFile:?]
at org.openhab.core.io.transport.mqtt.internal.Subscription.lambda$1(Subscription.java:81) [bundleFile:?]
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) [?:?]
at java.util.concurrent.ConcurrentHashMap$KeySpliterator.forEachRemaining(ConcurrentHashMap.java:3566) [?:?]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) [?:?]
at java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290) [?:?]
at java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746) [?:?]
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) [?:?]
at java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:408) [?:?]
at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:736) [?:?]
at java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159) [?:?]
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173) [?:?]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233) [?:?]
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) [?:?]
at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:661) [?:?]
at org.openhab.core.io.transport.mqtt.internal.Subscription.messageArrived(Subscription.java:81) [bundleFile:?]
at org.openhab.core.io.transport.mqtt.internal.Subscription.messageArrived(Subscription.java:66) [bundleFile:?]
at com.hivemq.client.internal.mqtt.mqtt3.Mqtt3AsyncClientView.lambda$callbackView$1(Mqtt3AsyncClientView.java:73) [bundleFile:?]
at com.hivemq.client.internal.mqtt.MqttAsyncClient$CallbackSubscriber.onNext(MqttAsyncClient.java:227) [bundleFile:?]
at com.hivemq.client.internal.mqtt.MqttAsyncClient$CallbackSubscriber.onNext(MqttAsyncClient.java:212) [bundleFile:?]
at com.hivemq.client.rx.FlowableWithSingle$SingleFutureSubscriber.onNext(FlowableWithSingle.java:377) [bundleFile:?]
at com.hivemq.client.internal.rx.operators.FlowableWithSingleCombine$SplitSubscriber$Default.tryOnNextActual(FlowableWithSingleCombine.java:206) [bundleFile:?]
at com.hivemq.client.internal.rx.operators.FlowableWithSingleCombine$SplitSubscriber.tryOnNext(FlowableWithSingleCombine.java:171) [bundleFile:?]
at io.reactivex.internal.operators.flowable.FlowableObserveOn$ObserveOnConditionalSubscriber.runAsync(FlowableObserveOn.java:649) [bundleFile:?]
at io.reactivex.internal.operators.flowable.FlowableObserveOn$BaseObserveOnSubscriber.run(FlowableObserveOn.java:176) [bundleFile:?]
at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:66) [bundleFile:?]
at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:57) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
So I´d say that the related things / channels need to be configured manually. What a pitty.
Does anybody know if there are plans / ongoing developments to support the component ?
## Limitations
* The HomeAssistant Fan Components only support ON/OFF.
* The HomeAssistant Cover Components only support OPEN/CLOSE/STOP.
* The HomeAssistant Light Component only supports RGB color changes.
* The HomeAssistant Climate Components is not yet supported.
Maybe opening an issue in openhab-addons and asking for adding then climate component could be an idea?
First install a MQTT Broker (E.g. mosquito), then enable MQTT in the ems-esp and do not use. the HA format for it.
Then install the MQTT binding and connect it to the broker.
If not already active install the JSONPath transformation (Settings -> Transformations -> “Plus”-Sign).
After this you can start configuring your mqtt things in OH.
Here something I set up for the boiler. Everything read-only except “burnMaxPower” which is not working yet.
Your channels will differ as they depend on the boiler installed, so take this as an example.
I do not claim this to be error free.
It’s a hell of a typing and clicking to get this up and running…
But more important:
With the current firmware I see periodical breakdowns in the mqtt publishing from the ems-esp to the broker. Disabling the mqtt on the device and reenabling it solves it. Might be a memory issue, but I’m not familiar with the firmware code.
Firmware version is 2.2.2-dev(38a443e) - but that an intermediate development build with added support for my Cerapur Aero which was not recognised before.
Will have to monitor this and check on the forum if this is well known and being worked on - otherwise we need to file a bug report in the ems-esp GIT repository.
Hi Thomas, thank you so much for your help. I am novice in this matter, my mqtt system is working. I’ve never done JSONPath transformation before. I would appreciate it if you could tell me step by step what to do. I am thankful to you.
Me too ;-). I figured out by reading the docs and scanning the forum.
The basic thing is that in you channels you define the mqtt-topic you want to link to.
In case the topic holds a JSON value, you use the transformation service to access only the single attribute within the JSON that is of interest.
The ems-esp publishes (depending on the settings in the MQTT section of the device) under the top level topic “ems-esp”. Below you find the devices it is providing data for (e.g. "boiler_data) in a JSON String.
In this example is was interested in the “heatingActive” attribute value within the JSON.
In the UI you find this in Thing-Channels->Configure Channel. You have to tick the “Show Advanced” box.
More details and (textual)examples can be found in the documentation and in various posts in the forum.
Sorry for replying somehow short, but I’m a bit busy at the moment.
The long example above is a textual definition of a thing and it’s channels in OH3.
You can create a mqtt thing, switch to the code tab and paste it over the code there (but ensure to keep the ID of your thing).
I’d suggest you make yourself more familiar with OH3 and how to manage things based on a more simple scenarios before setting up more complex things.
This is where the transformation kicks in, you create the thing, the channel is linked to the topic and the transformation selects the detail information you want.
Some screenshot of the channel from my mobile as I’m not at home.