Binding Request : Buderus web gateway

Same here. Seems that it installs the OH1.x version.
I started with manually installing the 2.x binding, things where discovered, items linked.
After the update the discovery is no longer working (binding itself starts and communicates with the interface as I see in the log) and the things all now show as “offline” in PaperUI. No control of items possible anymore.

OK, I tried a few things and the results were like this:

  • Uninstalled the binding from the PaperUI
  • Force-Remove of all remaining items using Paper UI(they did not go away when removing the binding)
  • Made sure the unlimited cypher strength for Zulu is installed (Used in openhabian).
  • reboot to make sure things are settled

Now I installed the binding from the Karaf console using:

 bundle:install -s http://www.markinus.de/download/org.openhab.binding.km200-2.1.0-SNAPSHOT.jar

Is there any “official” source that should be used ? That´s the latest version I found in this thread but it seems to be outdated (5.February 2017).
Karaf shows a 2.1-Version, so this should be fine:

206 | Active   |  80 | 2.1.0.201702051357    | KM200 Binding
  • After this it discovers the gateway and I added the private key as required in the gateways thing settings
  • Some time later the things are being discovered

Strange things I see after this:

  1. The Paper UI still shows the “old” binding to be installable in the add-ons section - this I think would kill the configuration. How to get rid of it ?
  2. Snapshot version does not show up in the add-ons section.
  3. Correction: (13:03) : Items now show up in the control section.
  4. Http error 500, causes the binding to mailfunction after a few minutes. Would suggest to have a parameter “polling intervall” as I have the impression data is requeste to often, causing an overload on the gateway device.

My overall impression:

  • I´m doing something wrong :slight_smile:
  • Currently it is a bit unclear how the process to get and install the latest snapshot version of the binding looks like so that it shows up correct in Paper UI.

@Markinus: Could you please give some small set of instructions on how to do this properly ?

Thanks,
Thomas

Any progress on the HTTP error 500 ? For me the binding is not running stable, as I would have to restart the gateway from time to time. Switched to version 1.10 (latest snapshot release), but still no progress.
Did someone figure out a better workaround ?

I recently upgraded my openhabian system and use the km200 version 2.1.0.201702051357

After each upgrade I struggle with the thing generation (deleting all items / things and start with registering the gateway as described somewhere above.
Currently it’s obviously working again.

However, I found a log entry:
[hab.binding.km200.internal.KM200Comm] - Fatal transport error: The server 192.168.178.49 failed to respond
The strange thing is that I configured the gateway on 192.168.178.43.
So I have no idea where the binding gets the .49 from and why it’s trying to contact the km on this IP adress.
Of course it’s not working, because it’s just a PoE switch on the .49

Someone an idea?

EDIT:
After a reboot I had to open the gateway and even if the private key and IP adress have been present, the gateway did not get connected.
After opening the gateway thing and closed it with ok (without changes) it was back online…
Strange or a known issue?

EDIT 2:
system
kmdevice
gateway are online
Nothing else…
Damn it.

I don’t want to delete and create all things after a reboot again and hope there is a (simple) solution for my issue… :frowning:

EDIT 3:
Now all the things are online, but OH is not populated with any data.
In the log it looks ok:

2017-06-09 13:59:16.913 [DEBUG] [KM200GatewayHandler$GetKM200Runnable] - GetKM200Runnable
2017-06-09 13:59:16.918 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:system:system:bus Root: #system#bus
2017-06-09 13:59:16.921 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:system:system:healthStatus Root: #system#healthStatus
2017-06-09 13:59:16.924 [DEBUG] [hab.binding.km200.internal.KM200Comm] - Check state of: /system/healthStatus type: null item: String
2017-06-09 13:59:17.052 [DEBUG] [hab.binding.km200.internal.KM200Comm] - Check state of data: {"id":"/system/healthStatus","type":"stringValue","writeable":0,"recordable":0,"value":"maintenance"}
2017-06-09 13:59:17.054 [DEBUG] [hab.binding.km200.internal.KM200Comm] - parseJSONData service: /system/healthStatus, data: {"id":"/system/healthStatus","type":"stringValue","writeable":0,"recordable":0,"value":"maintenance"}
2017-06-09 13:59:17.057 [DEBUG] [hab.binding.km200.internal.KM200Comm] - parseJSONData type string value: {"id":"/system/healthStatus","type":"stringValue","writeable":0,"recordable":0,"value":"maintenance"} Type: String
2017-06-09 13:59:17.069 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:system:system:systemType Root: #system#systemType
2017-06-09 13:59:17.071 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:system:system:brand Root: #system#brand
2017-06-09 13:59:17.074 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:gateway:gateway:instWriteAccessSwitch Root: #gateway#instWriteAccess
2017-06-09 13:59:17.077 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:gateway:gateway:instWriteAccess Root: #gateway#instWriteAccess
2017-06-09 13:59:17.079 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:gateway:gateway:versionFirmware Root: #gateway#versionFirmware
2017-06-09 13:59:17.082 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:gateway:gateway:instAccessSwitch Root: #gateway#instAccess
2017-06-09 13:59:17.085 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:gateway:gateway:instAccess Root: #gateway#instAccess
2017-06-09 13:59:17.087 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:gateway:gateway:versionHardware Root: #gateway#versionHardware
2017-06-09 13:59:17.089 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:gateway:gateway:uuid Root: #gateway#uuid
2017-06-09 13:59:17.091 [DEBUG] [ng.km200.handler.KM200GatewayHandler] - Checking: km200:gateway:gateway:DateTime Root: #gateway#DateTime

EDIT 4:
After a reboot the binding is not active:
269 | Resolved | 80 | 2.1.0.201702051357 | KM200 Binding | org.openhab.binding.km200

How can I ensure that the binding is loaded during startup?
It’s located in /usr/share/openhab2/addons (like always).
some bindings I have set in addons.cfg like
… harmonyhub,http1,mqtt1 (for those which are from OH1).
So do I need to specify the km200 here even though it is neither OH1 nor included in the addons.kar file?

Hi @NCO ,
my personal opinion is that the binding is far away from being stable in OH2.
Checking the openhab.log I see HTTP500 errors after running the binding for a few minutes requiring a reboot of the KM device (It seems that polling data takes place to often and the device is not capable of handling many requests at the same time) and the Thing / Item creation is not reliable (as you noticed).
Some things may be caused by the fact that OH2.1 is work in progress, where sometimes the new builds have issues that are being fixed again later.

In principle the decoding of the data coming from the KM device is working fine, but it needs fine tuning on the interfacing side as well as on the OH2 part.
I highly appreciate the work done by @Markinus, I seriously doubt if it could have been done by me any better, but I would not use this in a productive environment (yet).

Maybe Markus will find some time to address the open points, currently I assume he´s busy with something else.

Nevertheless if you have the skillset required and the time you could fork and improve it. Guess he would be glad to find someone helping him.
Regards,
Oggerschummer

Hi @Oggerschummer,

thanks for your response.
I am very greateful that Markus is putting so much effort into this binding and I am actually pretty happy with it.

In my previous setup (openhabian with OH2 stable) the same binding file mentioned above was running flawlessly - so I assume it root cause is within OH2 (which is now the snapshot build),
Or it could be, that I still don’t get the point about using addons.cfg properly.

If my problem(s) mentioed above are not a known issue (or my fault of using it incorrectly) than I will probably switch back the the last sd-card image.

After boot up time of nearly 50 min the km200 binding is active in the karaf console.
in PaperUI the things are uninitialized though…

It took me a while to get the “illegal key size” error fixed on OpenHABian distro. If other have the same problems as me, here is what I did to get it fixed (I’m also putting this here for my own future reference :slight_smile: )

The apt-get solution didn’t work for me, I got this error:

Unable to locate package "oracle-java8-unlimited-jce-policy"

So I downloaded the unlimited jce from the Oracle website: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

Copied it to my RPI and unzipped (if you’re a linux noob like me: just use the ‘unzip’ command).

Then I copied the 2 jar files from the zip to:

/usr/lib/jvm/zulu-embedded-8-armhf/jre/bin

(I made a backup first of the old files)

Restarted OpenHAB and then the binding started flawlessly!

Hello,

i have problem with OH2.1. binding found gateway, in console get information from server, but no actualizations data.

Hello @teaserr,
I would not recommend to mix Oracle VM files with Zulu.
Just a few posts above I mentioned there is support for this directly in Zulu, I´d suggest you take those instead of grabbing the Oracle ones.
Regards,
Oggerschummer

Hello,

today i test new openhabian with OH 2.1. Binding not working correctly. Search for things find gateway after configure gateway with IP and privat key find other things. After restart binding not start update. When i go again to Search for things in console show me ,[scovery.KM200GatewayDiscoveryService] - Gateway not configured, scanning postponed.,. Go to things and readd key. But some things show me ,UNINITIALIZED - BRIDGE_UNINITIALIZED,

I try test offline mode:

OH2.0 test ok after restart binding update data
OH2.1 same problem as OH2.1 online install with openhabian

used 178 | Active | 80 | 2.1.0.201702051357 | KM200 Binding for all instance

thanks

Late reply, I know :slight_smile: But thanks for this recommendation.
I actually experienced some issues using the Oracle files. From time to time, my Pi would freeze up, and I couldn’t find anything in the logging to cause this.
After I downloaded the files for Zulu, this problem went away. So I’m pretty sure this was the cause.

Is this binding stable now? I was thinking of buying a KM200 gateway, and I would like OpenHAB can interact with it.

Good question. I have not heard from @Markinus for months, up to now it was not stable enough to rely on it in a productive OH2.x environment. My impression is, that he´s no longer maintaining it, which is really a pity as it is a very good approach. Maybe contact him directly to see what the current status is on his side. Judging from his Github account he is offline since early 2017, no contributions since then. But statistics on github seem to be wrong, last commit to OH2 was September 2017.

Hi!

I’m still working on this binding. The last version is working very nice and it looks like it could be merged in next time. Here is the last version:
–link removed–

1 Like

Great.
Good to hear everything is fine on your side. I will give the new version of the binding a try in the next days.

Would be Great. If someone has problems with this binding then write it here. In my settings it’s running for months without and troubles. Openhab 2.1/Cometvisu and RasPi 2.

Thanks!

Maybe I’m gonna buy this gateway, I only think it’s quite expensive (eg https://www.heizungsdiscount24.de/regelungstechnik/buderus-web-km200-zur-bedienung-der-heizungsanlage-ueber-smartphone.html)

I have setup following item:

Number  HeatRoomManulaSP  	"KM200 Room Manual Setpoint [%.1f ]" 	<temperature> (g_Heating) { channel="km200:heatingCircuit:hc1:manualRoomSetpoint"} 

Inside the sitemap

		Setpoint item=HeatRoomManulaSP minValue=10 maxValue=26 step=1

The set value jumps always to the previouse value.

here the log file

2017-12-05 17:11:44.425 [ItemStateChangedEvent     ] - HeatRoomManulaSP changed from 14.0 to 15
2017-12-05 17:11:45.226 [ItemStateChangedEvent     ] - HeatRoomManulaSP changed from 15 to 14.0
2

no other log file entries
This values should be writable, mode is set to manual (km200:heatingCircuit:hc1:operationMode).

what am I doing wrong?
It seems that manualRoomSetpoint is not writable. Can anybody check that on his installation?