So, I’m back at home. I will check the binding tomorrow with my heating unit.
I’m back from holiday and I’ve found time to check the latest updates. If found some different bugs and add more details logging. This version runs really well on my device.
The Auto-Discovery works for my heating unit and I hope it also works for Vaillant devices. But this feature is the last puzzle piece for these binding.
The next steps are now to stabilize the code and create a documentation. Also the code deploy to github is on my todo list.
Hi @csowada
For some reason I haven’t got any notification about new posts and didn’t know about new release. Today I’m in business trip but hopefully will test it tomorrow and will let you know.
Hi @witek_1308,
thank you for your support. I hope I get “good news”.
I’m working on a new Alpha 7, but only with smaller changes. Today I started with clean-up work and documentation. I will update the first post to add additional information.
The new Alpha 8 has been released. The market place and both github projects has been updated too.
For me the library is now stable and can be switched to an beta branch next time.
The internal ids has changed again. So please replace all things. You can try the discovery feature to re-add the devices.
hey @csowada,
I was going to write you an update for v6 whereas I see you already released v8 
my observations from v6 are - it is finally working! 
but not only reading parameters, I can eventually set them and all seem to work apart from DWH operating mode, which stays unchanged (even HC1 operating mode which is similar can be changed immediately). Can you have a look at this?
Then Displayed room temperature is always 0 for me (maybe it’s 0 but maybe it’s decoding problem?)
I was going to check stability of alpha6 but now probably it makes sense to move to v8 and continue with that but will leave this version for the night anyways to see whether it survives till morning
edit:
I forgot to write - there is a behavior for some items which I don’t understand (most from BAI00 but not only) - I can see the values being changed in the event log or openhab.log e.g.
2017-09-27 22:30:01.933 [ItemStateChangedEvent ] - VaillantBAI00_VaillantBai00_boiler_tempCylinder_MeasuredValueOfHotWaterSensor changed from 43.1875 to 43.0625
2017-09-27 22:30:24.532 [ItemStateChangedEvent ] - VaillantVRCCommon_VaillantVrc_controller_tempRoom_RoomTemperature changed from 23.4375 to 23.375
2017-09-27 22:31:02.377 [ItemStateChangedEvent ] - VaillantBAI00_VaillantBai00_boiler_tempCylinder_MeasuredValueOfHotWaterSensor changed from 43.0625 to 42.9375
2017-09-27 22:32:01.913 [ItemStateChangedEvent ] - VaillantBAI00_VaillantBai00_boiler_tempCylinder_MeasuredValueOfHotWaterSensor changed from 42.9375 to 42.8125
2017-09-27 22:32:24.581 [ItemStateChangedEvent ] - VaillantVRCCommon_VaillantVrc_controller_tempRoom_RoomTemperature changed from 23.375 to 23.3125
but it’s like not storing the values in the items (neither in PaperUI->COntrol can see them nor if manually created sitemap and added values there). they are empty or displayed like Err (in sitemap I simply use: Text item=<item_name>). Any idea why is that?
edit 2:
STABILITY: I left binding for the night. I is still running but it stopped working i.e. not reading values from eBUS after pretty quick time (+/- 30min) and logging:
2017-09-28 07:42:54.355 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
(this was happening to me with v1.x).
Restart of the USB/serial connection helps so I read it as software problem. I’m going to give a try to Rel8 now, but I have a feeling this stability issue may persist as I’ve been seeing it in all versions.
Outcome from Alpha8 testing. I created new items for this binding (from automatic menu for item creation)
In general I experience same issues as above i.e.:
- can’t change value of DWH operation mode (whereas similar settings for e.g. HC1 operating mode get set immediately and can be seen on my VRC470). I guess it’s a bug
- displayed room temp is always 0 (not sure if not set in eBUS or not decoded properly)
- values from BAI00 seem to be read from eBUS (can see them in the log) but don’t get written to items (or at least this is how I see this; I don’t understand this mechanism but there is no way to display it). for v6 I tested most of them, for v8 just tried 2 but result is the same (also they can’t be seen in paperUI under Control menu). What makes it even more dodgy and complex to me to understand is that I have persistence of items in MySQL and I can see these values written to the DB but can’t display them. Completely don’t have a clue about this mechanism…
I like the logging level now. It doesn’t put too much but good enough to understand what is going on. Maturity of the binding in GUI is really good. It can be configured really quickly due to pre-existing config and autodiscovery (which I didn’t use this time).
I will leave it for some time now to check stability, I have good hope but bad feeling as always I ended up in this ‘Send queue is full!’ error resulting in binding to get stale…
regardless of the above it’s a huge piece of great work which deserves high appreciation! Thanks
Hello @witek_1308,
you feedback is really helpful to me. I will check your issues this evening. But I’ve some questions.
-
Can you tell me the name of your heating unit, maybe there are different BAI commands available
-
Which eBUS interface do you use? USB or Ethernet?
-
Do you have
Configuration>System>Item Linking→ “Simple Mode” enabled ? -
What do you mean with
automatic menu?
-
Do you have many collisions/traffic etc. on your bus?
-
Can you run the binding with only one “Polling” channel that works. Maybe the “DHW op” or “Display Room temp” channel causes an issue and blocks the send queue. But another bug is that the queue reset is not working properly.
-
Was the Discovery able to find some devices?
-
Could you set the logging to DEBUG for this binding? The debug should also show the send queue counter.
log:set DEBUG org.openhab.binding.ebusto reset to normal use
log:set INFO org.openhab.binding.ebus
I’ve created a version with another serial communication library for the 1.x binding, maybe this could help ?!
The binding works well with my Wolf heating system connected to a USB interface. I currently have 6-10 pollings (every 60sec) enabled. Works for hours/days.
I’ve got a Vaillant VRC calormatic MF. Do you know if that’s supposed to work ?
hey @csowada,
- my unit is Vaillant ecoTEC plus VC PL 206/5-5 R4 with VRC470v4
- I’m using interface assembled by someone from this forum but using this design: https://wiki.fhem.de/wiki/EBUS. I obviosly connect it through serial adapter to the USB port
- No, I have it disabled (seems to be default setting). I guess I need to enable it? strangely VRC items worked …
- I was unclear, sorry. By automatic menu I meant I didn’t use items precreated manually which I linked but used CreateNew item from the menu when enabling different channels under specific thing (eg. VRC). By my comment I meant I have no visibility on the actual item definition other than what happens automatically
- I don’t know if they are logged or not by default in the current release (I don’t use debug now). If they should be logged then I think I don’t have many as my log file is full of Polling requests. Simply how it looks - it suddenly stops logging information about received telegrams and just logs polling requests like below:
2017-09-28 09:02:02.634 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from master address FF with command heating.program_heating_circuit
2017-09-28 09:02:02.639 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Handle received command by thing Vaillant VRC 430/470 15 with id ebus::vrc430_15 …
2017-09-28 09:02:09.464 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command “ebus::vrc430_15:vrc430_controller_temp-outside#temp-outside” with “FF 15 B5 09 03 0D 62 00 88” …
2017-09-28 09:02:11.463 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command “ebus::vrc430_15:vrc430_dhw_temp-d-dhw#temp-d-dhw” with “FF 15 B5 09 03 0D 44 00 80” …
2017-09-28 09:02:14.026 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command “ebus:bai:11203950:bai_boiler_temp-return#temp-return” with “FF 08 B5 09 03 0D 98 00 B7” …
2017-09-28 09:02:17.024 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command “ebus:bai:11203950:bai_boiler_temp-d-flow#temp-d-flow” with “FF 08 B5 09 03 0D 39 00 43” …
then after some time raises alarm about “Send queue full” - Yes, I will do it during the day as I’m working from home today. Does polling interval have any meaning for the test here (maybe more often is better?). For the test purposes I poll either every 30s or60s depending on which item (later this will be changed obviously to some reasonable values as polling Curve every 1m doesn’t make sense…)
- Yes, discovery found 3 devices: ebus standard 08, ebus standard 15 and - suprisingly - ebus standard 75 which I understood from your previous posts should be Wolf, not Vaillant…
- Yes, sure. Will do this during my tests.
I could switch to the other binary but maybe let’s see what Debug brings for this one. At the moment I’m really happy about functionality, if only stability could be fixed.
Off topic - is it difficult to add HC2 to the debug (or do it myself)? I have 2 circuits (standard setup of vaillant scenario 1 where HC1 are radiators and HC2 is floor heating with own curve, temperature setpoints etc).
Short answer to point 7,
the master/slave address are not bound to a vendor. My list only contains usually used addresses.
Most devices have the possibility to change the default address to prevent conflicts. In some cases one device uses more than one address. I have five or six different slave addresses used within my heating unit but only three/four real devices connected to the bus.
@csowada,
I collected output in DEBUG and reached the point where queue got full and stopped working.
I did the test only with items which have values as you suggested above. I also at early moment of my tests removed BAI00 (even if there were no active items) to make sure it doesn’t interfere. I collected this into the clean file from startup. File will be too big to paste it here, is there a way to attach it somehow or maybe send you via email? This time I see Debug contains less information that it used to in 1.x but hopefully it’s enough for you to find out the issue.
My tests don’t contain scenario of changing DHW operating mode (which is what I can’t change value of), I just focused on filling queue and stability.
You can send the log directly to “openhab (at @@ ) cs-dev.de” or send me a PM.
Another question to your serial usb converter. Is this a cheap converter. I had trouble with cheap adapters and also with fake FTDI adapters in the past. My interface uses an original FTDI converter without any trouble.
yes, sure I’m aware of the fact that it may not be the best (pricewise it’s much lower but I explained it with the fact of productization i.e. lack of it, no cover etc). But you may be completely right. I was however afraid to invest much before checking whether the binding will be fulfilling my expectations. I sent log to the email you posted above
So,
I’ve quickly checked you log. And it looks like the binding simply stop receiving data from the bus. Without receiving data we can’t receive the required SYN symbols that we need for sending telegrams.
Is your hardware working with another software like ebusd?
Could also set the debug level for de.csdev.ebus, I expect a message like eBUS read timeout occured, no data on bus ... in the log.
You could also try to create a VRC 430/470 thing with the slave address 75, maybe this is your second circuit.
hey,
no, I have no other software in between, just OH2 and your binding. Will set addiitional Debug as suggested.
You are right about 3rd element - I forgot to say - I have a remote control vr81 which I use for controlling the temperature for the 2nd circuit. Because I use it simply as remote termostat (never change settings there) I forgot it exists but defnitely HC2 is working based on this element. I will try to use it after my current tests not to influence them.
@csowada,
for some reason I can’t paste it here (even subset) so sending you new email again. I think however you need to change/add some more debug as from the current one it simply looks like suddenly stoping receiving data without any reason in the log, then it fills up the queue
edit:
HA! I found the suspect in the system log (syslog):
Sep 28 13:17:07 dom-pi kernel: [57102.217022] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
this appears just before all communication hangs. Now need to smart guy to tell me what this can be but after quick look on the internet it looks like fake FTDI chips…
For me it looks like an issue with your serial usb converter. That is what I guessed before.
You should replace it with a new one.
would you recommend one? I’m afraid of buying another one poor quality c*ap
Regardless the FTDI problem which seems to be pure HW (and will work on fixing it), the issues I found ex.
- regarding the non-setting DWH operating mode
- things with BAI00 not ‘retained’ even if read from eBUS
- lack of displayed temp (important to me as raw seems to be very different from displayed, apparetnly it’s normalised using some delta,for me it’s about 2 degrees)
Do you have enough data to look at the code or rather you want me to perform some other tests?
-edit
regarding second circuit - I don’t this is it as after adding it , it presents multiple channels which are more heating unit specific (very similar to what I can see in BAI). Maybe it is something like ebus standard
It seems I managed to resolve stability issue of the FTDI adapter. I used the solution described here https://github.com/raspberrypi/linux/issues/1187. I didn’t need that much of USB speed, but stability so it was good solution for me. Before applying fix it was running max 1h, now the adapter is being stable for about 17h which suggests this was the issue. I’ll be editing this post with new observations.
Binding looks rock solid during this time, queues not filling up, data being updated. Yet another point for @csowada!
I hope this will last for longer therefore can focus on testing binding further. I still have it in full DEBUG so if any more logs needed I’m happy to produce them.