Good to know, but you should keep your workaround for the fake FTDI in mind. Maybe you will get problems in future. For a 24/7 I would buy a genuine FTDI adapter.
Now I can focus on your other subjects. I will check your previous logs for that.
@csowada,
definitely I have and will have it in mind.
I’d immediately buy the proper one but I it seems different sources on the internet still sell some batches which are not working. People seemed to complain about really different vendors.
Moreover, I found some tutorial how to recognize fake based on chip and how it presents itself to ‘lsusb’ and it seems that according to it, mine isn’t fake. I personally believe it is fake (due to the error I’m getting), and that tutorial is not complete. So all in all, it’s about hearing from other people where to buy trusted one.
Writing this here as maybe it will help others with similar issue as mine. In the meantime will be looking for really good quality FTDI to buy.
regarding my logs - they may contain mostly things for stability (as I disabled all items with zero values or BAI00 ones) therefore most likely you won’t find much there. Will produce a new one for you today and will send it
Thanks you for your new log file with pointing to the BAI issue. The Formatter for nearly all temperature value are wrong, a copy/past issue. It is easy to fix and will be released in the next version this evening.
Could you send me a log when you switch the DHW Op Mode please? I’m interested in the generated telegram and the response of the slave.
And for the displayed temperature the telegram looks good so far, I think it is not support by your device or depends on the firmware version. Maybe there is another command available. You can check the ebusd configuration files (my source for the vaillant configurations)
@csowada,
I the setting of DWH is in the file already. I’m not expert but I believe it’s in there (first 2, then change to 1 from binding then back to 2 again from VRC):
2017-09-29 10:40:46.436 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! 50 [ERROR: INVALID_SOURCE_ADDRESS, DATA: ]
2017-09-29 10:40:46.437 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! B5 [ERROR: INVALID_SOURCE_ADDRESS, DATA: ]
2017-09-29 10:40:46.486 [DEBUG] [de.csdev.ebus.core.EBusController ] - Send: FF 15 B5 09 03 0D 2F 00 03 @ 1. attempt
2017-09-29 10:40:46.564 [DEBUG] [de.csdev.ebus.core.EBusController ] - Succesful send: FF 15 B5 09 03 0D 2F 00 03 00 01 02 99 00
2017-09-29 10:40:46.568 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from master address FF with command heating.program_heating_circuit
2017-09-29 10:40:46.570 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Handle received command by thing Vaillant VRC 430/470 15 with id ebus::vrc430_15 …
2017-09-29 10:40:46.572 [DEBUG] [hab.binding.ebus.handler.EBusHandler] - Value program 2
2017-09-29 10:40:46.580 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]
2017-09-29 10:41:00.303 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 1 …
2017-09-29 10:41:00.374 [DEBUG] [de.csdev.ebus.core.EBusController ] - Send: FF 15 B5 09 04 0E 42 00 01 07 @ 0. attempt
2017-09-29 10:41:00.455 [DEBUG] [de.csdev.ebus.core.EBusController ] - Succesful send: FF 15 B5 09 04 0E 42 00 01 07 00 00 00
2017-09-29 10:41:00.460 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from master address FF with command dhw.program_dhw_circuit
2017-09-29 10:41:00.462 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Handle received command by thing Vaillant VRC 430/470 15 with id ebus::vrc430_15 …
2017-09-29 10:41:00.463 [DEBUG] [hab.binding.ebus.handler.EBusHandler] - Value program 1
2017-09-29 10:41:00.471 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 00 AA]
2017-09-29 10:41:06.346 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command “ebus::vrc430_15:vrc430_controller_temp-room#temp-room” with “FF 15 B5 09 03 0D 00 00 89” …
2017-09-29 10:41:06.648 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 1 …
2017-09-29 10:41:06.704 [DEBUG] [de.csdev.ebus.core.EBusController ] - Send: FF 15 B5 09 03 0D 00 00 89 @ 0. attempt
2017-09-29 10:41:06.784 [DEBUG] [de.csdev.ebus.core.EBusController ] - Succesful send: FF 15 B5 09 03 0D 00 00 89 00 03 74 01 00 6D 00
2017-09-29 10:41:06.788 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from master address FF with command controller.temp_room
2017-09-29 10:41:06.792 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Handle received command by thing Vaillant VRC 430/470 15 with id ebus::vrc430_15 …
2017-09-29 10:41:06.795 [DEBUG] [hab.binding.ebus.handler.EBusHandler] - Value temp_room 23.25
2017-09-29 10:41:06.799 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]
2017-09-29 10:41:06.801 [DEBUG] [hab.binding.ebus.handler.EBusHandler] - Value status 0
2017-09-29 10:41:13.377 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command “ebus::vrc430_15:vrc430_dhw_program-dhw-circuit#program” with “FF 15 B5 09 03 0D 42 00 EC” …
2017-09-29 10:41:13.380 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 1 …
2017-09-29 10:41:13.433 [DEBUG] [de.csdev.ebus.core.EBusController ] - Send: FF 15 B5 09 03 0D 42 00 EC @ 0. attempt
2017-09-29 10:41:13.513 [DEBUG] [de.csdev.ebus.core.EBusController ] - Succesful send: FF 15 B5 09 03 0D 42 00 EC 00 01 02 99 00
2017-09-29 10:41:13.518 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from master address FF with command dhw.program_dhw_circuit
2017-09-29 10:41:13.522 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Handle received command by thing Vaillant VRC 430/470 15 with id ebus::vrc430_15 …
2017-09-29 10:41:13.525 [DEBUG] [hab.binding.ebus.handler.EBusHandler] - Value program 2
2017-09-29 10:41:13.529 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]
2017-09-29 10:41:24.016 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 03 64 B5 12 02 02 FE 98]
2017-09-29 10:41:24.574 [WARN ] [.binding.ebus.internal.EBusDiscovery] - EBusDiscovery.onEBusDeviceUpdate()
if it’s not enough then I’m happy to generate a new log (it’s easy for me as I’m still connected).
regarding displayed temp I won’t be suprised it this specific param is not supported but there must a parameter for it definitely anyways as what I see on the display is much less than what comes from eBUS (about 2 deg C difference). Since VRC displays with accuracy of 0.5 degrees the actual difference is sometimes more sometimes less, I observed so far it’s more less like: displayed_temp = round_to_nearest_0.5[temp_from_ebus - 2degrees]. and comparing to other termometers, it seems displayed temp is correct so the one from ebus is apparently something else…
Hello @witek_1308,
I’ve released a new version with the BAI fix and a Mini VR81 configuration. The binding should discover all your devices automatically.
I also checked your DHW Op Mode, it was correctly set by the binding. I think it is the behavior of the hardware that is not accepting this value. I searched the internet and found other people with the same issue on ebusd. At this point I can’t help. Maybe other Vaillant owners can help.
hey @csowada,
I can’t create things in the new binding. Bridge was created (but doesn’t initialize), then when adding things I get error:
2017-09-29 23:14:10.999 [ERROR] [org.openhab.binding.ebus ] - [org.openhab.binding.ebus.internal.EBusHandlerFactory(198)] The activate method has thrown an exception
java.lang.NullPointerException
at de.csdev.ebus.client.EBusClientConfiguration.loadInternalConfigurations(EBusClientConfiguration.java:116)
at org.openhab.binding.ebus.internal.EBusHandlerFactory.updateConfiguration(EBusHandlerFactory.java:204)
at org.openhab.binding.ebus.internal.EBusHandlerFactory.activate(EBusHandlerFactory.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_144]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_144]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_144]
at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_144]
at org.apache.felix.scr.impl.inject.BaseMethod.invokeMethod(BaseMethod.java:224)
at org.apache.felix.scr.impl.inject.BaseMethod.access$500(BaseMethod.java:39)
at org.apache.felix.scr.impl.inject.BaseMethod$Resolved.invoke(BaseMethod.java:617)
at org.apache.felix.scr.impl.inject.BaseMethod.invoke(BaseMethod.java:501)
at org.apache.felix.scr.impl.inject.ActivateMethod.invoke(ActivateMethod.java:302)
at org.apache.felix.scr.impl.inject.ActivateMethod.invoke(ActivateMethod.java:294)
at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:297)[31:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:108)[31:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:906)[31:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:879)[31:org.apache.felix.scr:2.0.6]
at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:823)[31:org.apache.felix.scr:2.0.6]
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_144]
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:210)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:496)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:619)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.apache.felix.cm.impl.helper.BaseTracker.getRealService(BaseTracker.java:205)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:102)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1772)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)[3:org.apache.felix.configadmin:1.8.12]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_144]
2017-09-29 23:14:11.055 [WARN ] [org.openhab.binding.ebus ] - FrameworkEvent WARNING - org.openhab.binding.ebus
org.osgi.framework.ServiceException: org.apache.felix.scr.impl.manager.SingleComponentManager.getService() returned a null service object
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.factoryGetService(ServiceFactoryUse.java:232)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse.getService(ServiceFactoryUse.java:111)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceConsumer$2.getService(ServiceConsumer.java:45)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:496)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.getService(ServiceRegistry.java:461)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.BundleContextImpl.getService(BundleContextImpl.java:619)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.apache.felix.cm.impl.helper.BaseTracker.getRealService(BaseTracker.java:205)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:102)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1772)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:141)[3:org.apache.felix.configadmin:1.8.12]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:109)[3:org.apache.felix.configadmin:1.8.12]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_144]
2017-09-29 23:14:33.916 [WARN ] [ore.thing.internal.ThingRegistryImpl] - Cannot create thing. No binding found that supports creating a thing of type ebus:bridge.
2017-09-29 23:16:47.346 [ERROR] [ome.io.rest.core.thing.ThingResource] - Exception during HTTP PUT request for update config at ‘things/ebus:bridge:433336e9/config’ for thing ‘ebus:bridge:433336e9’: Thing with UID ebus:bridge:433336e9 has no handler attached.
Oh, there was a an issue with the build. After a clean rebuild everything is fine now. I have replaced the broken version with a new build version.
Hey @csowada,
as expected binding works - good stuff!
VR81 - nice thing to have, and interestingly, displayed temperature works and is equal to displayed temperature 
would love to have it on VRC470 but apparently it’s some more work needed
BAI00 items (I tested some only at the moment) are displayed properly, I do have however problem which I don’t know if it’s environmental or bug:
2017-09-30 12:16:39.898 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate update ‘25.0625’ for item ‘VaillantBAI00_Bai_boiler_tempReturn_ReturnTemperature’ to handler for channel ‘ebus:bai:66070754:bai_boiler_temp-return#temp-return’, because no thing with the UID ‘ebus:bai:66070754’ could be found.
it looks like environmental (99.99% sure) but I obviously re-created all things (for changed IDs), even recreated items to make sure linking is completely new. I restarted OH2 as well as server. No idea where to change it. It seems to be an issue only for items which existed before in the previous binding (looks like some cache didn’t clear or so). New ones don’t experience it. Maybe you can give me a hint. What is interesting - proper values can be seen in PaperUI->Control panel, but not in manually created sitemap (it displays empty)
Probably at this stage we need to give it some time for observations/stability, I will also configure more items (didn’t want to overload binding with querying too many). Will be updating this thread accordingly.
I have an ambition to create my own jsons for additional parameters (mostly related to HC2).
One ‘Change Request’ - would be good to read in the binding the date/time (I guess it sits somewhere in the standard eBUS). This would be really useful as I observed that after losing power my heating unit doesn’t keep it (not sure if battery is dead or there is no battery; unit is new so I guess no battery). This in turn causes the clock to start from 0 and therefore mix up programs: it happened to me couple of times that in the morning there was no warm water as HU thought it’s night. Having this parameter would be possible to add rule in OH2 to raise alarm (or ideally set it from the NTP)
You can use the “eBUS Standard” thing, it contains the date/time. You can use “eBUS Standard” for all slave addresses and check the results.
Heyu
I was thinking about it (away from pc today) but i was confused by the fact that ebus standard is same address (08) as BAI00 so I thought that it is same as BAI00 not standard
You can add more different things to the same slave address. Auto Discovery should show you all known devices after a short while.
unfortunately date/time doesn’t work from ebus standard. No track of it in events.log and not much in openhab.log
@csowada,
I have one question - I want to add my own parsers to decode something more from ebus based on john30’s ebusd config.
Where would I put this config? I seen 2 places which are my suspects:
- ebus bridge -> parserUrl (this alread has something in there)
- ebus bridge -> configurationUrl (all empty)
Binding is very stable until now (as well as the FTDI adapter with this additional setting).
Use the second variant. The first is obsolete.
@csowada,
I was just looking at your commands in git hub (for the date and time) and I think there is a copy paste problem as it contains reference to temperature too:
“label”: “Date/Time of an eBUS Master”,
“id”: “common.time”,
“command”: “07 00”,
"broadcast": {
"master": [
{"name": "temp_outside", "type": "data2b", "label": "Outside temperature", "format":"%.1f°C"},
{"name": "time", "type": "datetime", "label": "Date/Time"}
]
}
},
then, I was not sure which bytes do date/time in standard ebus but when looked at john30’s decoding it seems the for VRC430/470 date is under 6100 and time 6000 and it should be r/w. I couldn’t find date/time under BAI00, found something in his broadcast files (together with temperature) which seems what you tried to decode above (but this seem to be under different address) and this looks like something else (like temp+date when it was collected) than actual setting of date/time possible in VRC (apologies if I’m saying rubbish as I’m still learning all this).
Hello @witek_1308,
you are on the wrong track. This command is from the official eBUS Standard Specification and works vendor independent. In this case the command 07 00 is correct, all Vaillant commands use static B5 09 as command and use a sub command like your xx 61 00. You can see that in the vrc/bai configuration files.
ok, thanks for clarification. What mislead me is that I didn’t see updates for this item for some reason so thought it may be vendor dependent.
I tried to create my own parsers for vrc time but they don’t get loaded, some java errors are thrown. More reading required on my side to understand the data types, ids etc. Are you going to release any high level doc for it?
I will check the custom readers, longer not tested. Have you seen the documentation in the first post? It’s a first version including some information about the configuration format.
no, I missed it 
was too focused on downloading the jars
will read it then. John30 nicely decoded all possible ebus components which provide hell lot of information, I want to use some of it.
interestingly I already optimized some of my settings thanks to your binding as finally I can draw charts and easier capture anomalies.
I read the doc, but probably some coaching is needed too. Can someone help me with the example of time extract?
{
“id”: “vrc470”,
“vendor”: “Vaillant”,
“label”: “Vaillant VRC 470”,
“description”: “Vaillant VRC 470”,
"authors": ["Name, mail@mail"],
"identification": ["34 33 30 30 30", "34 37 30 30 30"],
"commands":
[
{
"label": "Time of VRC",
"id": "vrc.time",
"command": "B5 09",
"get": {
"master": [
{"type": "datetime", "default": "0D 60 00"}
],
"slave": [
{"name": "vrc_time", "type": "datetime", "label": "Time"}
]
}
}
]
}
this gets read properly by binding, the thing is created and nicely detects the config above, I can create item for it, it get nicely polled but then value is empty. I’m pretty sure it’s because of some data types issue (for the moment I focused on read only, not setting it). No error in the file