My device is not on the list Vaillant.
Can i try a different protocol if it doesn’t match or can i damage my system if i try it?
if I understand it right, it is possible to create parsers easier? I have an own parser for my vaillant 620 and 560. But only some items. I would create a full parser. But with the tool it seems easier. Should I wait?
Hello @Cernon,
with converter I’m able to convert 99% of all configuration files automatically. The quality of automatic converted files are not good enough to add it directly to the binding. Maybe as marked as Experimental or as separate configuration package.
I’m not able to check the the configuration files with a Vaillant device, so I can only compare the generated configurations with the ones already included in this binding.
But it create an editional parserfile? So I can work on it and finetune and test it? But you open an own topic for this.
New topic for the Vaillant ebusd-configuration converter …
Hey @csowada
Thank you very much for your great work. I’m really enjoying your binding and switched from my ebsud/MQTT selfmade binding to your binding.
I too have the stability problem @witek_1308 has reported in this thread.
I have 11 Items configured with a polling interval of 180s. After a while the binding stops updating the values although the polling seems to continue. The log debug shows:
09:27:04.241 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:ebusbridge:vrc700_general:vrc700_general_gen_pressure#value" with "FF 15 B5 24 06 02 00 00 00 39 00 89" ... 09:27:04.297 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_sf-mode#value" with "FF 15 B5 24 06 02 00 01 00 0D 00 40" ... 09:27:05.266 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_holiday-end#value" with "FF 15 B5 24 06 02 00 01 00 0A 00 B7" ... 09:27:05.303 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_op-mode#value" with "FF 15 B5 24 06 02 00 01 00 03 00 35" ... 09:27:05.313 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:bai:ebusbridge:bai:bai_boiler_temp-return#temp-return" with "FF 08 B5 09 03 0D 98 00 B7" ... 09:27:07.233 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:ebusbridge:vrc700_general:vrc700_general_gen_display-outside#value" with "FF 15 B5 24 06 02 00 00 00 73 00 F5" ... 09:27:07.278 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_holiday-start#value" with "FF 15 B5 24 06 02 00 01 00 09 00 81" ... 09:27:08.249 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:ebusbridge:vrc700_general:vrc700_general_gen_operation-mode#value" with "FF 15 B5 24 06 02 00 00 00 7B 00 EC" ... 09:27:09.266 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_holiday-end#value" with "FF 15 B5 24 06 02 00 01 00 0A 00 B7" ... 09:27:09.306 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation. 09:27:09.312 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:bai:ebusbridge:bai:bai_boiler_temp-return#temp-return" with "FF 08 B5 09 03 0D 98 00 B7" ... 09:27:11.300 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_storage-temp#value" with "FF 15 B5 24 06 02 00 01 00 05 00 59" ... 09:27:13.245 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:ebusbridge:vrc700_general:vrc700_general_gen_maintenance-due#value" with "FF 15 B5 24 06 02 00 00 00 96 00 08" ... 09:27:16.318 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:bai:ebusbridge:bai:bai_boiler_temp-flow#temp-flow" with "FF 08 B5 09 03 0D 18 00 BC" ... 09:27:19.277 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_holiday-start#value" with "FF 15 B5 24 06 02 00 01 00 09 00 81" ... 09:27:19.313 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:bai:ebusbridge:bai:bai_boiler_temp-flow#temp-flow" with "FF 08 B5 09 03 0D 18 00 BC" ...
bundle:list
204 │ Active │ 80 │ 2.4.0.201807101913 │ eBUS Binding
OH2 Version 2.3
If I stop OH2, clear the cache (openhab-cli clean-cache) and start OH2 again everything works great for a few days, till it stops updating again. Ebusd was running about a year (with restarts in between of course) but without a similar issue. All other bindings continue to work fine, this only happens with the ebus binding.
Do you have an Idea how to solve this problem?
On diffentence to ebusd is that I must use a serial library to communicate with the device. SO I can’t control the serial device.
You could check this topic on lo latency, maybe it can help.
I’ve added an alternative serial library in the past for the 1.x binding, maybe it is useful for the 2.x binding too.
I’ll give it a try, thanks!
But if this is a latency issue, why does cleaning the cache helps, but restarting OH2 or the complete system issn’t helping?
Mh, yes a good point, the send queue etc. are not stored, it only exists in memory. Could send me a log (via PM) when the binding is not working anymore and and a part of the log before the binding fails? Maybe the serial connection stops and the queue doesn’t recognize it.
Hi, @csowada!
Tell me, please, what is the best way to switch from the first version of binding to second? In the first version, I used a custom json. As I understand it, in OpenHAB version 2.4 the first version will be replaced by the second?
Second question - I have not found this command in your files, can you help convert it into a new format?
{
"comment": "Get circuit parameters",
"id": "getParameters",
"class": "circuits",
"command": "B5 04",
"data": "09",
"values": {
"dayTemp": {"type": "uchar", "pos": 10, "label": "Circuit desired temp/day temp for fixed value circuit"},
"nightTemp": {"type": "uchar", "pos": 11, "label": "Circuit night temp"},
"heatingCurve": {"type": "uint", "pos": 12, "label": "Circuit heating curve", "factor": 0.01, "min": 0.1, "max": 4.0},
"circuitType": {"type": "uchar", "pos": 14, "label": "Circuit type", "mapping": {"128": "Disabled", "129": "Mixing circuit", "130": "Fixed value", "131": "Cylinder circuit", "132": "Increase in return flow", "133": "Direct circuit"}},
"otShutdownLimit": {"type": "uchar", "pos": 15, "label": "Max limit outs. temp"},
"pumpDelay": {"type": "uchar", "pos": 16, "label": "Pump delay time"},
"minTemp": {"type": "uchar", "pos": 17, "label": "Minimum temp"},
"maxTemp": {"type": "uchar", "pos": 18, "label": "Maximum temp"}
}
}
Hello,
I use the Binding since one year. Now I update to the newest Milestone 2.4.0 or the newest snapshot. In both cases the RC1 don’t work. The binding not appears in papierUI. OH 2.3.0 and Version 21 of the binding works so far.
This Version is only for 2.4 milestones, not for 2.3. could you check the log or console.
I try a clean setup of 2.4 Milestone. Then I put the kar file of RC1 in the Addons folder. Under PapierUI the binding don’t appears. In Eventlog and openhablog is nothing. What should I look in the console?
Hello, I tried to do the same, on a fresh new 2.4 Milestone as well, putting the RC1 in the addons folder. I’m not familiar with the .kar files, is this the right process ?
Same problem here,
I stopped Openhab, deleted the RC1 file, cleaned up te cache, restarted openhab, stopped openhab, copied te the RC1 file back, started openhab, and yes there it was again.
Until the next openhab update…
It still needs som tweeking:grinning:
MH, all of you on latest milestone or nightly? Maybe new changes to openhab…
I try both, milestone and snapshot 1406/1407. Same effect.
So, I’ve updated my development environment and I can’t see any compilation issues. So we need more details from the console. Could you try some commands.
bundle:list .*ebus.*
Output should look like:
START LEVEL 100 , List Threshold: 50
ID │ State │ Lvl │ Version │ Name
────┼────────┼─────┼────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
259 │ Active │ 80 │ 0.9.18.SNAPSHOT │ eBUS library configuration
260 │ Active │ 80 │ 0.9.18.SNAPSHOT │ eBUS core library
261 │ Active │ 80 │ 2.4.0.201807101913 │ eBUS Binding
feature:info ebus-binding
Output should look like:
Feature ebus-binding 2.4.0.22
Description:
eBUS 2.0 binding incl. eBUS core libs
Feature has no configuration
Feature has no configuration files
Feature has no dependencies.
Feature contains followed bundles:
mvn:org.openhab.binding/org.openhab.binding.ebus/2.4.0-SNAPSHOT start-level=80
mvn:de.cs-dev.ebus/ebus-core/0.9.18-SNAPSHOT
mvn:de.cs-dev.ebus/ebus-configuration/0.9.18-SNAPSHOT
Feature has no conditionals.
So if the bindings are not active, I need some diagnostic information from the bindings. In that case use IDs from the first command and try this…
bundle:diag 259 260 261
You can also try to unistall the old feature with this command and then re-add the kar file.
feature:uninstall ebus-bindingMy system was just fully reinstalled from scratch, based on last Miles Stone
Here is the result of the console info:
I think my very first issue is to install the kar file, as the list is empty:
openhab> bundle:list .*ebus.*
START LEVEL 100 , List Threshold: 50
ID │ State │ Lvl │ Version │ Name
───┼───────┼─────┼─────────┼─────────────────────────────────────────────────────────────────────────────────────────
but the feature info let me think it see the content of the kar file:
openhab> feature:info ebus-binding
Feature ebus-binding 2.4.0.RC1
Description:
eBUS 2.0 binding incl. eBUS core libs
Feature has no configuration
Feature has no configuration files
Feature has no dependencies.
Feature contains followed bundles:
mvn:org.openhab.binding/org.openhab.binding.ebus/2.4.0-SNAPSHOT start-level=80
mvn:de.cs-dev.ebus/ebus-core/0.9.18-SNAPSHOT
mvn:de.cs-dev.ebus/ebus-configuration/0.9.18-SNAPSHOT
Feature has no conditionals.
The bundle command return:
openhab> bundle:diag 259 260 261
Bundle 259 is invalid
Bundle 260 is invalid
Bundle 261 is invalid
Error executing command: No matching bundles
The binding is not listed in PaperUI. However, if I try to manually install the feature, I get the error:
openhab> feature:install ebus-binding
org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=ebus-binding; type=karaf.feature; version="[2.4.0.RC1,2.4.0.RC1]"; filter:="(&(osgi.identity=ebus-binding)(type=karaf.feature)(version>=2.4.0.RC1)(version<=2.4.0.RC1))" [caused by: Unable to resolve ebus-binding/2.4.0.RC1: missing requirement [ebus-binding/2.4.0.RC1] osgi.identity; osgi.identity=de.cs-dev.ebus.ebus-core; type=osgi.bundle; version="[0.9.18.SNAPSHOT,0.9.18.SNAPSHOT]"; resolution:=mandatory [caused by: Unable to resolve de.cs-dev.ebus.ebus-core/0.9.18.SNAPSHOT: missing requirement [de.cs-dev.ebus.ebus-core/0.9.18.SNAPSHOT] osgi.wiring.package; filter:="(&(osgi.wiring.package=gnu.io)(version>=3.12.0))"]]
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
at org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:392)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve ebus-binding/2.4.0.RC1: missing requirement [ebus-binding/2.4.0.RC1] osgi.identity; osgi.identity=de.cs-dev.ebus.ebus-core; type=osgi.bundle; version="[0.9.18.SNAPSHOT,0.9.18.SNAPSHOT]"; resolution:=mandatory [caused by: Unable to resolve de.cs-dev.ebus.ebus-core/0.9.18.SNAPSHOT: missing requirement [de.cs-dev.ebus.ebus-core/0.9.18.SNAPSHOT] osgi.wiring.package; filter:="(&(osgi.wiring.package=gnu.io)(version>=3.12.0))"]
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
… 12 more
Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to resolve de.cs-dev.ebus.ebus-core/0.9.18.SNAPSHOT: missing requirement [de.cs-dev.ebus.ebus-core/0.9.18.SNAPSHOT] osgi.wiring.package; filter:="(&(osgi.wiring.package=gnu.io)(version>=3.12.0))"
at org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
… 13 more
Error executing command: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=ebus-binding; type=karaf.feature; version="[2.4.0.RC1,2.4.0.RC1]"; filter:="(&(osgi.identity=ebus-binding)(type=karaf.feature)(version>=2.4.0.RC1)(version<=2.4.0.RC1))" [caused by: Unable to resolve ebus-binding/2.4.0.RC1: missing requirement [ebus-binding/2.4.0.RC1] osgi.identity; osgi.identity=de.cs-dev.ebus.ebus-core; type=osgi.bundle; version="[0.9.18.SNAPSHOT,0.9.18.SNAPSHOT]"; resolution:=mandatory [caused by: Unable to resolve de.cs-dev.ebus.ebus-core/0.9.18.SNAPSHOT: missing requirement [de.cs-dev.ebus.ebus-core/0.9.18.SNAPSHOT] osgi.wiring.package; filter:="(&(osgi.wiring.package=gnu.io)(version>=3.12.0))"]]