this did the trick, the values have now a proper format (Single fraction). Thanks for fixing it !
d.
2019-11-27 21:08:09.494 [.ItemChannelLinkAddedEvent] - Link 'HeatSources_ActualSupplyTemperature-km200:heatSource:817210159:heatSources:actualSupplyTemperature' has been added.
2019-11-27 21:11:36.165 [vent.ItemStateChangedEvent] - km200_appliance_817210159_appliance_actualSupplyTemperature changed from NULL to 53.1
2019-11-27 21:12:08.924 [vent.ItemStateChangedEvent] - km200_appliance_817210159_appliance_actualSupplyTemperature changed from 53.1 to 57.4
2019-11-27 21:12:41.704 [vent.ItemStateChangedEvent] - km200_appliance_817210159_appliance_actualSupplyTemperature changed from 57.4 to 59.5
2019-11-27 21:13:14.494 [vent.ItemStateChangedEvent] - km200_appliance_817210159_appliance_actualSupplyTemperature changed from 59.5 to 60.4
2019-11-27 21:14:20.054 [vent.ItemStateChangedEvent] - km200_appliance_817210159_appliance_actualSupplyTemperature changed from 60.4 to 59.9
2019-11-27 21:14:52.825 [vent.ItemStateChangedEvent] - km200_appliance_817210159_appliance_actualSupplyTemperature changed from 59.9 to 58.4
What I see now are some exceptions during the startup phase of the binding:
2019-11-27 21:09:50.530 [hingStatusInfoChangedEvent] - 'km200:kmdevice:817210159' changed from ONLINE to UNINITIALIZED
==> /var/log/openhab2/openhab.log <==
2019-11-27 21:09:50.532 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.dispose()' on 'org.openhab.binding.km200.internal.handler.KM200GatewayHandler@de616d': hexString needs to have an even length:
java.lang.IllegalArgumentException: hexString needs to have an even length:
at org.eclipse.smarthome.core.util.HexUtils.hexToBytes(HexUtils.java:105) ~[bundleFile:?]
at org.eclipse.smarthome.core.util.HexUtils.hexToBytes(HexUtils.java:119) ~[bundleFile:?]
at org.openhab.binding.km200.internal.KM200Device.setCryptKeyPriv(KM200Device.java:151) ~[?:?]
at org.openhab.binding.km200.internal.handler.KM200GatewayHandler.dispose(KM200GatewayHandler.java:145) ~[?:?]
at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_232]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_232]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
2019-11-27 21:09:50.536 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while disposing handler of thing 'km200:kmdevice:817210159': hexString needs to have an even length:
java.lang.IllegalArgumentException: hexString needs to have an even length:
at org.eclipse.smarthome.core.util.HexUtils.hexToBytes(HexUtils.java:105) ~[bundleFile:?]
at org.eclipse.smarthome.core.util.HexUtils.hexToBytes(HexUtils.java:119) ~[bundleFile:?]
at org.openhab.binding.km200.internal.KM200Device.setCryptKeyPriv(KM200Device.java:151) ~[?:?]
at org.openhab.binding.km200.internal.handler.KM200GatewayHandler.dispose(KM200GatewayHandler.java:145) ~[?:?]
at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_232]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_232]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
After some time these do vanish and the binding is running fine.
I remember someone having the same message with the hex String, might be a formatting- or trimming-related issue.
But again: Thanks for fixing the precision topic !
Regards
Thomas
I today migrated my OpenHAB docker environment from OH 2.5.0 - Milestone 3 to OH 2.5.0 - Release Candidate 1. During this change I experienced the first time that the my Buderus web gateway KM200 has been frozen by the binding. I read through this thread and found the “russian method” of powering off and on the gateway to re-establish the communication!
I just wanted to let you know that your 2.5.0-RC1 version of the binding is still so unstable to freeze the gateway.
After rebooting the gateway the communication currently works and I have the workaround now when the gateway freezes again.
You may let me know if you want some logs for making the binding more stable and I will let you know if I experience further issues with the latest binding level.
Logging in as openhab
Password:
__ _____ ____
____ ____ ___ ____ / / / / | / __ )
/ __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __ |
/ /_/ / /_/ / __/ / / / __ / ___ |/ /_/ /
\____/ .___/\___/_/ /_/_/ /_/_/ |_/_____/
/_/ 2.5.0.RC1
Milestone Build
Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown openHAB.
I have now issues changing any parameters … I am collecting the data but you need not looking into that today …
Dear community, i installed the KM Binding today. Works like describe.
I miss two things, I set the heating temp and also the hot water temp direct on the display of the heating appliance. Now I try to access this value and also to change them.
I set heating temp to 31 and heating temp for hot water to 55.
A closer look to all parameters shows the value /system/sensors/temperatures/supply_t1_setpoint = 31. Unfortunaetly this item is not writeable.
I do not find any item with the 55 in it. I think it should be /system/sensors/temperatures/hotWater_t2_setpoint, but it is not there.
For information: there is a
/system/sensors/temperatures/supply_t1 with the current temp value, so I think the /system/sensors/temperatures/supply_t1_setpoint is the set entry
and there is also the /system/sensors/temperatures/hotWater_t2 as the current hot water temp, setpoint is missing.
welcome to the community. Buderus does not expose all parameters to the gateway. I have an list of the old version of the binding which shows all the parameters that can be retreived by the binding:
In the output below you see the confirmation that the parameters that you found are not writeable (“0” in the second column)
To manipulate the values of the hot water circuit you would need to look at the parameters in the dhwCircuits appliance (see also above in the output. To set the temperature you may want to try the setTemperature parameter which is writeable as you can see at the “1” in the second column …
The parameters for the hot water circuit are organized in a separate appliance … Hope this gives you a new perspective for searching the right parameters for your plans …
Hi, thanks for the fast reply. Unfortunately it doesn’t help. Yes for sure, there is a hot water circuit in the system - but that is not the one I want to set. Reason behind that, I have the heating system, this runs completely decoupled from the hot water circuit. The heating systems heats up a big buffer water tank. The tank is separated in two zones, one for heating the rooms and one for the hot water. Both are separated and set on the front panel of the system. The temperatures are measure supply_t1 (for the heating) and hotWater_t2 for the hot water.
That’s the reason, why I talked about the supply_t1_setpoint at the system branch not at the hotwater circuit. So I need to manipulate these values.
Hi Markus, thanks for the reply. I don’t see any of the temperatures, which I have set on the front panel of the heating system on the Buderus App, this is not nice.
With the new binding it should be temperatureLevels_night instead of temperatureLevels/night
and respectively temperatureLevels_day instead of temperatureLevels/day
I have also not setpoint parameter for the second hotwater sensor _t2_
You have also to distinguish between hotWater and supply !!!
As you can see in the syntax of the old binding list all sensor parameters are not writeable: 1;0;1:0; … (the second “0” indicates writeable = 0 => means not writeable)
You can collect the same full list for the current binding when setting the output level of the binding to DEBUG
> log: set DEBUG org.openhab.binding.km200
when you now run log:display in the karaf console you will see all the parameters and their attributes …
did you see my question in post #444 of this topic. Why my binding is loading the defaults even though I specified different values in the things file?
Hi Justus, thanks for the fast reply. There isn’t as “setTemperature” in my services. I add a txt file here which shows all services. Maybe there is a new version of the gateway with different parameters?
It seems that the list of available services is depending on the heating type and probably the remote control and the type of the gateway. Your list looks different to mine.
Btw. how did you collect that list? I got mine from the previous binding which log it to the console in DEFAULT log level when the binding started. I don’t see that with the new binding even when setting the log level of the binding to DEBUG? Thanks for sharing
But what is still true is that the second column of the first four marks the ability to change the parameter … writeable = 1, not writeable = 0 but I guess you know that
I think only @Markinus as the binding owner is able to tell if the list you have provided is complete and if he is able to squeeze the missing parameters out of your configuration.
I think it would be helpful to know what heating you have (GB ###), which remote control (RC##) and which web gateway (KM###). You may not want to share it openly in the community hence I would suggest to wait for Markinus comment on that and share this information with him via a private message …
Hi,
the 2.x binding is always generating this list if DEBUG is set. So you should see it, too. @helmutS this binding is dynamicaly detecting what the device is supporting and what not. Perhaps some of the parameters are not accessible with this interface. You could create a full start logfile in DEBUG and send it to me. I could take a look whether there is something what is not supported out of the box. (But take a look to the parameters like password and user and remove it from the logfile).
Greetings
Hello Justus, yes, can be that all parameters are aligned to the devices in the system. I will answer to that in the other post.
How I got the list: I enabled the debug mode (Openhab console) for the binding, disable and enable it in the WEB Frontend and all the entries where logged to the openhab logfile. Afterwards I delete a few info lines. I copied all lines with the services in the text file.
Hi Markus,
thanks, I’ll do that. In addition a few more insights to the rest of the colleagues here. Configuration/Devices of my heating system.
Heating system itself with 2 heating possibilities 1 Line goes normal to the rooms and 2nd line to the so called Hotwaterstation (Frischwasserstation). In addition there is a solar system, the KM200 Gateway and the Logamatic RC310.
We build the system in a special: Both pipes (Hotwater and Heating) are connected to buffer tanks and not the hole house or to the hotwaterstation. With that configuration I’m able to use my own programs to bring the consumption of the energy down to the lowest point. Because I"m able to steer now against the weather forecast and the difference between the target room temperature and the temperature in the pipes.
The only thing I need to do, is to steer these two values in the Buderus System from external.