[eBUS 2.0] Configuration support/contribution

Hello @csowada
template file for vaillant and configuration file for VRC700 are done. There is more work to do, but here is what have been done so far:
https://drive.google.com/open?id=1_26-NMtESby3t8sFwKz6KVU5bY6r45Ia
Now I need you to help me finish it.

Configuration file is very large .There is 180 command blocks, and it loads more than 10 seconds on my Pi. That’s why I had a problem with the update tool.
Rarely who will use all the commands, so it would not be bad to make one more file for the most commonly used setup (one heating circuit, one zone, hot water and circulation) or split the configuration into multiple files, so can be used in bundle only as needed.If a large file is to be used, maybe it can be better arranged because it has a lot of repetition (9 groups for 7 days of timer, 2 zones, 2 heating circuits).
Which would be the best choice? And is bundle limited by number of files?

My Vaillant template file contains only the templates that were needed to complete the vrc700 configuration. When everything is done, I will be happy to add the rest.

Around this things I need help:

For channels that use templates b5.hfrom and b5.hto the telegram is resolved and the method is found, but an error occurred. The example below is an error when the date is 30.04.17

12:05:28.970 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700:8e673baf:vrc700_gen_holiday-start#value" with "FF 15 B5 24 06 02 00 00 00 71 00 58" ...
12:05:29.027 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Send: FF 15 B5 24 06 02 00 00 00 71 00 58 @ 0. attempt
12:05:29.168 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Succesful send: FF 15 B5 24 06 02 00 00 00 71 00 58 00 07 03 00 71 00 1E 04 11 41 00
12:05:29.172 [ERROR] [de.csdev.ebus.core.EBusControllerBase] - Error while firing onTelegramReceived events!
java.lang.ArrayIndexOutOfBoundsException: 3
        at de.csdev.ebus.command.datatypes.ext.EBusTypeDate.decodeInt(EBusTypeDate.java:110) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.datatypes.ext.EBusTypeDate.decodeInt(EBusTypeDate.java:1) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.datatypes.EBusAbstractType.decode(EBusAbstractType.java:100) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.EBusCommandUtils.decodeValueList(EBusCommandUtils.java:374) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.EBusCommandUtils.decodeTelegram(EBusCommandUtils.java:426) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:94) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:102) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        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) [?:?]

And telegram for 01.05.17. also fires same error:

FF 15 B5 24 06 02 00 00 00 71 00 58 00 07 03 00 71 00 01 05 11 F3 00

Next error I get using b5.from and to (TTM). In case the time slot for timer is not set, vrc700 sends a value of 90 90 90 90 representing the next midnight. Binding does not want to use this value or I am missing something. Here is example:

12:49:17.299 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700:8e673baf:vrc700_hwc_timer-mon#from2" with "FF 15 B5 24 05 03 01 00 01 00 4E" ...
12:49:17.370 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Send: FF 15 B5 24 05 03 01 00 01 00 4E @ 0. attempt
12:49:17.526 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Succesful send: FF 15 B5 24 05 03 01 00 01 00 4E 00 07 01 21 8A 90 90 90 90 13 00
12:49:17.532 [ERROR] [ebus.service.parser.EBusParserService] - error!
de.csdev.ebus.command.datatypes.EBusTypeException: Value 'minutes since midnight' to large!
        at de.csdev.ebus.command.datatypes.ext.EBusTypeTime.decodeInt(EBusTypeTime.java:111) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.datatypes.ext.EBusTypeTime.decodeInt(EBusTypeTime.java:1) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.datatypes.EBusAbstractType.decode(EBusAbstractType.java:100) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.EBusCommandUtils.decodeValueList(EBusCommandUtils.java:374) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.EBusCommandUtils.decodeTelegram(EBusCommandUtils.java:426) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:94) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:102) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        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) [?:?]

The next thing to look at is that the binding always do polling of all the channels, regardless of whether they are linked or not and so clog the bus. Channels used for “dummy” values are being polled also. Can “_unknown” poll and unlinked poll be omitted? Here is example: two identical telegrams to retrieve one value

00:45:45.795 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700:8e673baf:vrc700_gen_time#-unknown" with "FF 15 B5 24 06 02 00 00 00 35 00 51" ...
00:45:45.801 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700:8e673baf:vrc700_gen_time#value" with "FF 15 B5 24 06 02 00 00 00 35 00 51" ...

Next, please look at hwc.timer_mon for example. Currently, the command creates 6 channels with the same label. Is it possible for each of the channels to get a value name from the template in their label ?

It’s all for now. I will continue after the response. Thank you.

1 Like

Wow, great work. That is awsome that you have translated the commands.

I’m busy on saturday, but I will try to check you issues in the evening.

Hello @mikulaos,

I’ve checked the sources and fixed two issues, see list below. I thing you should split the configuration into heating, aircondition, solar etc. I will also add a new flag to mark advanced configurations, so Paper UI would only link non-advanced commands. I hope I find time this weekend to fix your other issue.

Download: https://drive.google.com/open?id=1-jdPlqaesrC7kgSaNmNlWHtnh0RExrKT

Sorry, no more time this evening!


Should be fixed with this version.

Should be fixed with this version. Please use variantminutes_short for ebusd TTM, TTH and TTQ datatype.

@mikulaos,

the new time variant minutes_short is not working with 0x90 values at the moment! So many special cases for vaillant!

No more errors on TTM, that’s progress :slight_smile:

For this telegram, representing 05:30-23:00 and two empty slots

FF 15 B5 24 05 03 01 00 01 00 4E 00 07 01 21 8A 90 90 90 90 13 00

this is output in my paperui (without formatting)

01.01.1970 00:33:00

31.12.1969 22:02:00

31.12.1969 22:08:00
31.12.1969 22:08:00
31.12.1969 22:08:00
31.12.1969 22:08:00

using this kind of templates

{"name": "from1", "type": "time", "variant": "minutes_short", "minuteMultiplier": "10"}

Changing multiplier also don’t change value!

On the other hand, b5.hfrom and b5.hto (HDA:3) is now working fine.

I’m currently working on separating configuration files and waiting for your update. I hope you will soon find time to review other issues. Most disturbing is polling of unlinked channels. Thank you

The configuration is now split into parts. It may need refining and formatting some commands once the issues are resolved.
https://drive.google.com/open?id=1UAJwNANhGf1fst_jOxsfgCLJB4o8HsuL
Bundle works nicely. I personally use general, hwc, hc1, and zone1 and my system works much faster than with all the commands.

Only one new issue appeared in a meantime and is not tied to the separation of files.
A problem occurs when polling a sensor that is not connected to the system if its datatype is EXP (float). In this case, VRC 700 returns FF FF FF 7F, a value that can not be converted into float due to excessive exponent (according IEEE 754). Another Vaillant special case :frowning: . On the other hand, this should be the last one for this configuration. :slight_smile:

00:13:24.811 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Succesful send: FF 15 B5 24 06 02 00 00 00 9D 00 27 00 08 00 00 9D 00 FF FF FF 7F 54 00
00:13:24.817 [ERROR] [de.csdev.ebus.core.EBusControllerBase] - Error while firing onTelegramReceived events!
java.lang.NumberFormatException: null
        at java.math.BigDecimal.<init>(BigDecimal.java:494) [?:?]
        at java.math.BigDecimal.<init>(BigDecimal.java:383) [?:?]
        at java.math.BigDecimal.<init>(BigDecimal.java:806) [?:?]
        at java.math.BigDecimal.valueOf(BigDecimal.java:1274) [?:?]
        at de.csdev.ebus.command.datatypes.std.EBusTypeFloat.decodeInt(EBusTypeFloat.java:43) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.datatypes.std.EBusTypeFloat.decodeInt(EBusTypeFloat.java:1) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.datatypes.EBusAbstractType.decode(EBusAbstractType.java:100) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.EBusCommandUtils.decodeValueList(EBusCommandUtils.java:374) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.EBusCommandUtils.decodeTelegram(EBusCommandUtils.java:426) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:94) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:102) [213:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        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) [?:?]

Hello,
I have a VRC470f, but since the latest updated there seems to be an issue with a few channels:

The following works (both get and set):
ebus:vrc430:e1f63288:15:vrc430_heating_program-heating-circuit#program

These 2 get updates, but when I set a value, they do nothing and on the next poll the items switch back
ebus:vrc430:e1f63288:15:vrc430_heating_program-heating-circuit-special#program
ebus:vrc430:e1f63288:15:vrc430_dhw_program-dhw-circuit#program

This used to work on OH1 and I believe it also worked in the first OH2 versions.

Today I have noticed the same problem as @nikoraes . In my two cases it is uchar and uint datatypes. After a bit of digging it can be seen that regardless of value, binding always sends FF.
In the first example I change the value from 3 (veto) to 0 (auto), FF is sent.
In the second example the value was changed from 3 (night) to 2 (day), FF FF was sent.

First example:

 smarthome:ebus resolve "FF 15 B5 24 07 02 01 03 00 0E 00 FF BB 00 02 00 03 2F 00"


Check and unescape telegram
***************************

Original data : FF 15 B5 24 07 02 01 03 00 0E 00 FF BB 00 02 00 03 2F 00
Unescaped data: FF 15 B5 24 07 02 01 03 00 0E 00 FF BB 00 02 00 03 2F 00

Analyse the telegram
********************

FF 15 B5 24 07 02 01 03 00 0E 00 FF BB 00 02 00 03 2F 00
^^------------------------------------------------------ Source address       | Type: Master         | FF
   ^^--------------------------------------------------- Destination address  | Type: Slave          | 15
      ^^ ^^--------------------------------------------- Command              |                      | B5 24
            ^^------------------------------------------ Master Data Length   | Length: 7            | 07
               ^^ ^^ ^^ ^^ ^^ ^^ ^^--------------------- Master Data          |                      | 02 01 03 00 0E 00 FF
                                    ^^------------------ Master CRC           |                      | BB
                                       ^^--------------- Slave ACK            |                      | 00
                                          ^^------------ Slave Data Length    | Length: 2            | 02
                                             ^^ ^^------ Slave Data           |                      | 00 03
                                                   ^^--- Slave CRC            |                      | 2F
                                                      ^^ Master ACK           |                      | 00

Resolve the telegram
********************

Found 1 command method(s) for this telegram.

Values from command 'z1.sf_mode' with method 'SET' from collection 'vrc700_zone1'

Second example:

 smarthome:ebus resolve "FF 15 B5 24 08 02 01 03 00 06 00 FF FF 1C 00 02 02 03 82 00"


Check and unescape telegram
***************************

Original data : FF 15 B5 24 08 02 01 03 00 06 00 FF FF 1C 00 02 02 03 82 00
Unescaped data: FF 15 B5 24 08 02 01 03 00 06 00 FF FF 1C 00 02 02 03 82 00

Analyse the telegram
********************

FF 15 B5 24 08 02 01 03 00 06 00 FF FF 1C 00 02 02 03 82 00
^^--------------------------------------------------------- Source address       | Type: Master         | FF
   ^^------------------------------------------------------ Destination address  | Type: Slave          | 15
      ^^ ^^------------------------------------------------ Command              |                      | B5 24
            ^^--------------------------------------------- Master Data Length   | Length: 8            | 08
               ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^--------------------- Master Data          |                      | 02 01 03 00 06 00 FF FF
                                       ^^------------------ Master CRC           |                      | 1C
                                          ^^--------------- Slave ACK            |                      | 00
                                             ^^------------ Slave Data Length    | Length: 2            | 02
                                                ^^ ^^------ Slave Data           |                      | 02 03
                                                      ^^--- Slave CRC            |                      | 82
                                                         ^^ Master ACK           |                      | 00

Resolve the telegram
********************

Found 1 command method(s) for this telegram.

Values from command 'z1.op_mode' with method 'SET' from collection 'vrc700_zone1'

Hello,

I’ve created a new version with some fixes. Here a small list

  • Polling for all channels in a thing, only on polling per command. Ignore underscore values
  • Fix issue that Setter Commands always set replace value like 0xFF
  • Fix parameter “minuteMultiplier” ignored
  • Fix minutes_short

https://drive.google.com/open?id=1IGTKpvd0fhr1KOLk4Ws3pf0YjNt3m_7f

But there are still problems with Vaillant datatypes. Maybe new datatypes are required.

  1. Now there is no polling for unlinked channels, but there is still polling of _unknown channels. I do not know where and how you ignored underscore values, but maybe it matters that there is hyphen-minus in the channel id, not an underscore? (eg. ebus:vrc700_zone1:22fe170c:vrc700_zone1_z1_actual-setpoint#-unknown)
    To show you the point, I unlinked all channels. There should be no polling at all after that.
    This is log file after changing polling interval to 55 seconds.
19:51:43.121 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Initialize eBUS pollings for ebus:vrc700_zone1:22fe170c ...
19:51:43.124 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.sf_mode" every 55 sec. (initil delay 1 sec.)
19:51:43.127 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.sf_mode" !
19:51:43.130 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.holiday_setpoint" every 55 sec. (initil delay 23 sec.)
19:51:43.132 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.holiday_setpoint" !
19:51:43.134 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1h.timer_wed" every 55 sec. (initil delay 4 sec.)
19:51:43.137 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_wed" !
19:51:43.140 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_wed" !
19:51:43.142 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_wed" !
19:51:43.145 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_wed" !
19:51:43.147 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_wed" !
19:51:43.150 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'ebus:vrc700_zone1:22fe170c' has been updated.
19:51:43.150 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_wed" !
19:51:43.153 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.room_temp" every 55 sec. (initil delay 1 sec.)
19:51:43.157 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.room_temp" !
19:51:43.160 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.actual_setpoint" every 55 sec. (initil delay 12 sec.)
19:51:43.162 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.actual_setpoint" !
19:51:43.165 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.op_mode" every 55 sec. (initil delay 5 sec.)
19:51:43.169 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.op_mode" !
19:51:43.173 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.room_map" every 55 sec. (initil delay 11 sec.)
19:51:43.177 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.room_map" !
19:51:43.180 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.bank_holiday_end" every 55 sec. (initil delay 20 sec.)
19:51:43.185 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.bank_holiday_end" !
19:51:43.189 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.holiday_end" every 55 sec. (initil delay 6 sec.)
19:51:43.193 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.holiday_end" !
19:51:43.197 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.bank_holiday_start" every 55 sec. (initil delay 7 sec.)
19:51:43.203 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.bank_holiday_start" !
19:51:43.207 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.name2" every 55 sec. (initil delay 16 sec.)
19:51:43.230 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.name2" !
19:51:43.235 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1h.timer_mon" every 55 sec. (initil delay 3 sec.)
19:51:43.239 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_mon" !
19:51:43.248 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_mon" !
19:51:43.252 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_mon" !
19:51:43.257 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_mon" !
19:51:43.261 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_mon" !
19:51:43.266 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_mon" !
19:51:43.271 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1h.timer_sun" every 55 sec. (initil delay 1 sec.)
19:51:43.275 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sun" !
19:51:43.280 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sun" !
19:51:43.284 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sun" !
19:51:43.289 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sun" !
19:51:43.293 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sun" !
19:51:43.298 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sun" !
19:51:43.303 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_zone1:22fe170c:vrc700_zone1_z1_day-setpoint#-unknown" with "FF 15 B5 24 06 02 00 03 00 07 00 48" ...
19:51:43.307 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.day_setpoint" every 55 sec. (initil delay 0 sec.)
19:51:43.312 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.day_setpoint" !
19:51:43.316 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.valve_status" every 55 sec. (initil delay 21 sec.)
19:51:43.320 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.valve_status" !
19:51:43.325 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1h.timer_sat" every 55 sec. (initil delay 10 sec.)
19:51:43.330 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sat" !
19:51:43.334 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sat" !
19:51:43.339 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sat" !
19:51:43.343 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sat" !
19:51:43.348 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sat" !
19:51:43.353 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_sat" !
19:51:43.357 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1h.timer_tue" every 55 sec. (initil delay 19 sec.)
19:51:43.360 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Send: FF 15 B5 24 06 02 00 03 00 07 00 48 @ 0. attempt
19:51:43.362 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_tue" !
19:51:43.367 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_tue" !
19:51:43.371 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_tue" !
19:51:43.376 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_tue" !
19:51:43.380 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_tue" !
19:51:43.385 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_tue" !
19:51:43.390 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.name1" every 55 sec. (initil delay 2 sec.)
19:51:43.394 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.name1" !
19:51:43.399 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1h.timer_thu" every 55 sec. (initil delay 18 sec.)
19:51:43.403 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_thu" !
19:51:43.408 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_thu" !
19:51:43.412 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_thu" !
19:51:43.417 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_thu" !
19:51:43.421 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_thu" !
19:51:43.426 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_thu" !
19:51:43.431 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_zone1:22fe170c:vrc700_zone1_z1_short-name#-unknown" with "FF 15 B5 24 06 02 00 03 00 16 00 E1" ...
19:51:43.430 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.short_name" every 55 sec. (initil delay 0 sec.)
19:51:43.435 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.short_name" !
19:51:43.439 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1h.timer_fri" every 55 sec. (initil delay 5 sec.)
19:51:43.444 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_fri" !
19:51:43.448 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_fri" !
19:51:43.453 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_fri" !
19:51:43.457 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_fri" !
19:51:43.462 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_fri" !
19:51:43.467 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1h.timer_fri" !
19:51:43.471 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.holiday_start" every 55 sec. (initil delay 11 sec.)
19:51:43.476 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.holiday_start" !
19:51:43.481 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.quick_veto" every 55 sec. (initil delay 2 sec.)
19:51:43.485 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.quick_veto" !
19:51:43.490 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Register polling for "z1.night_setpoint" every 55 sec. (initil delay 15 sec.)
19:51:43.493 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Unable to create raw polling telegram for "z1.night_setpoint" !
19:51:43.501 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Succesful send: FF 15 B5 24 06 02 00 03 00 07 00 48 00 08 03 03 07 00 00 00 B0 41 5E 00
19:51:44.587 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_zone1:22fe170c:vrc700_zone1_z1_room-temp#-unknown" with "FF 15 B5 24 06 02 00 02 01 0F 00 19" ...
19:51:44.587 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_zone1:22fe170c:vrc700_zone1_z1h_timer-sun#-unknown1" with "FF 15 B5 24 05 03 03 00 02 06 C2" ...
19:51:44.589 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_zone1:22fe170c:vrc700_zone1_z1_sf-mode#-unknown" with "FF 15 B5 24 06 02 00 03 00 0E 00 CA" ...
19:51:44.600 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Send: FF 15 B5 24 06 02 00 03 00 16 00 E1 @ 0. attempt
19:51:44.602 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - Received telegram from address FF to 15 with command z1.day_setpoint
19:51:44.643 [INFO ] [smarthome.event.ItemStateChangedEvent] - Down_Bath_Humid changed from 60 to 65
19:51:44.652 [INFO ] [smarthome.event.ItemStateChangedEvent] - Down_Bath_Light changed from 182 to 150
19:51:44.742 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Succesful send: FF 15 B5 24 06 02 00 03 00 16 00 E1 00 0B 03 03 16 00 5A 4F 4E 45 20 31 00 5F 00
19:51:44.746 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Send: FF 15 B5 24 06 02 00 02 01 0F 00 19 @ 0. attempt
19:51:44.754 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - Received telegram from address FF to 15 with command z1.short_name
19:51:44.933 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Succesful send: FF 15 B5 24 06 02 00 02 01 0F 00 19 00 08 02 02 0F 00 9A 99 99 3F 91 00
19:51:44.936 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Send: FF 15 B5 24 05 03 03 00 02 06 C2 @ 0. attempt
19:51:44.945 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - Received telegram from address FF to 15 with command z2.room_temp
19:51:44.948 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - No handler has accepted the command z2.room_temp from FF to 15 ...
19:51:44.952 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - Received telegram from address FF to 15 with command z1.room_temp
19:51:44.960 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - Received telegram from address FF to 15 with command hc2.heating_curve
19:51:44.963 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - No handler has accepted the command hc2.heating_curve from FF to 15 ...
19:51:45.133 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Succesful send: FF 15 B5 24 05 03 03 00 02 06 C2 00 07 01 2D 84 90 90 90 90 C3 00
19:51:45.135 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Send: FF 15 B5 24 06 02 00 03 00 0E 00 CA @ 0. attempt
19:51:45.145 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - Received telegram from address FF to 15 with command z1h.timer_sun
19:51:45.330 [DEBUG] [de.csdev.ebus.core.EBusController    ] - Succesful send: FF 15 B5 24 06 02 00 03 00 0E 00 CA 00 05 03 03 0E 00 00 6B 00
19:51:45.342 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - Received telegram from address FF to 15 with command z1.sf_mode
19:51:45.392 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_zone1:22fe170c:vrc700_zone1_z1_name1#-unknown" with "FF 15 B5 24 06 02 00 03 00 17 00 7A
  1. Setter commands does work for me now! :slight_smile:

  2. and 4.
    Regarding minutes_short and minuteMultiplier I did not get any progress. It may be a problem in a template or configuration. Maybe I need special formatting? Even when I change my multiplier I get the same result. An example is 5 posts above.

Mh, I must create a virtual Vaillant test environment first. I also must think about all the Vaillant special data types.
But you configuration files are a great improvement for the binding. But you should change the values for lengthand minutesMultiplier from String with “…” to Integer. But I think minutesMultiplieris still not working.

So,

I worked the last days to hopefully fix all issues. Please check this version.
This version contains the new VRC700, VR90 and PMW configuration files - thx to @mikulaos and @dkuschmierz .

I’m still working on the template system, so I modified the configuration files a bit. You can see the latest version here

The template system allows to use templates within templates, so you can create dummy ebusd datatypes. I hope I can create a new Alpha 16 at the weekend include more documentation.


And here the download to the latest version, extract the zip file to your addon folder

https://drive.google.com/open?id=1alET9RsdQMldOOF-pD8DQ5AimpmGFpfW

@csowada, thank you for great work!
Compared to the previous version, we now have a reverse situation with polling :slight_smile: No more polling _unknown, but there is polling of all channels again. Only linked channels should be in polling order.

I have changed configuration files and corrected some errors and added more mapping and formatting.
There is pull request for this.

In my setup the formatting of vaillant.from and vaillant…to does not work. Can you look if I have written a good formatting string?

Ups, was never implemented. Maybe now it is visible due to the other changes.

You should wait with more changes until this evening. I will update all configuration files in the repository. I have modified you configuration files a bit to use the template system optimal.

Your work is so amazing, much work I know that :smiley:
Thank you!

So this version only contains the small bugfix to poll only linked channels and the refactored new configurations. I have currently no good overview of open issues. If someone find now or old issues please write it down. If it is a known issue a small reminder is enough.

Latest snapshot: https://drive.google.com/open?id=1cCB7G_X4Rj8oMvNNsYBQIBoulAIdne4Z

It seems that all of the issues I’ve reported resolved with the latest version. (though it may not work for someone else). My setup is now ready for production :slight_smile: I will be happy to continue to assist.

  • new datatype needed for vaillant.tempv - fixed (float)

  • HDA: 3 problem - fixed

  • some setter commands allways sending FF - fixed

  • polling _unknown channels - fixed

  • polling unlinked channels - fixed

  • minutes_short variant 0x90 values for empty time slots - fixed

  • minuteMultiplier not working - fixed

  • formatting of vaillant.from and vaillant.to - fixed

Other issues are not issues, but it would be good to solve them:

  • polling of sensor not connected to system returns FF FF FF 7F - can not be converted - raises error

  • vaillant time slot labels - include the value name in the label if possible for a better overview at the paperui

How are parameters handled which have different adresses for read and write. Here the ebusd csv:

r9,,LuftmengeStufe0,,,,4050,21,aktuell,,UIR,,m³/h,,minimum,,UIR,,m³/h,,maximum,,UIR,,m³/h,,Schrittgroesse,,UIR,,m³/h,,Werkseinstellung,,UIR,,m³/h
w,,LuftmengeStufe0,408001,,,4080,21,,,UIR,,m³/h

Do I have to define two entries in the json?

e.g.

        {
            "label":    "Fan Step 0",
            "id":       "ac.fan_step_0",
            "command":  "40 50",

            "get": {
                "master": [
                    {"type": "static", "default": "21"}
                ],
                "slave": [
                    {"name": "cur", "type": "word", "label":"Fan Step 0", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "min", "type": "word", "label":"Fan Step 0", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "max", "type": "word", "label":"Fan Step 0", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "stp", "type": "word", "label":"Fan Step 0", "reverseByteOrder": true, "format":"%.1fm³/h"},   
                    {"name": "fac", "type": "word", "label":"Fan Step 0", "reverseByteOrder": true, "format":"%.1fm³/h"}   
                ]
            },
            "command":  "40 80",

            "set": {
                "master": [
                    {"type": "static", "default": "21"}
                ],
                "slave": [
                    {"name": "fan_step_0", "type": "word", "label":"Fan Step 0", "reverseByteOrder": true, "min": 0, "max": 50, "step":50, "format":"%.1fm³/h"}   
                ]
            }
        },

I have another challenge and I am not sure how to solve.

Here the csv:

w,,Ventilatorbetrieb,,,,40a1,,,,ULR,0x0=Feuchteschutz;0x00010001=Reduziert;0x00020002=Normal;0x00030003=Intensiv,,,,,IGN:1
r1,,Ventilatorbetrieb,40220101,,,4022,01,,,UIR,0=Feuchteschutz;1=Reduziert;2=Normal;3=Intensiv,,FanMode

Need a hint how the json shoulk look like

Hey folks,
Great job with eBus binding!
I’m still quite new to openhab, but should be able to test VRC470 to help move things forward on this front.
I managed to got some data from eBus1 http://take.ms/UzRNRx
But struggle to make the eBus2 working properly. Unfortunately, most of the items doesn’t return anything http://take.ms/ZjktB when using latest 0.9.16 version.

Hi,

for my Vaillant fresh water station i need an other identifier, perhaps someone also need that.

vaillant-pmw-configuration.json (11.1 KB)