[eBUS 2.0] New binding - Release Candidate 3

csowada · 2018-11-26 18:25:59 UTC

Hello,

I’m happy to announce a first working version of the new eBUS 2.0 binding.

For more details see change logs for core lib and openHAB binding:

csowada/ebus/blob/develop/CHANGELOG.md

## Alpha 0.9.19 (2018-11-03)

Features:

  - add JSerialComm as additional serial driver
  - add send/receive roundtrip time to controller
  - Update DTO objects
  - add divider property to DTO
  - change java level to 1.8
  
Bugfixes:

  - fix "indirectly referenced" issue on extern bundles

## Alpha 0.9.18 (2018-06-10)

Features:

  - add bruteforce analyzer to decode data with all data types (internal only)
  - add watchdog timer to all eBus connections, default is 5mins at the moment

This file has been truncated. show original

github.com

csowada/openhab2-addons/blob/ebus2x/addons/binding/org.openhab.binding.ebus/CHANGELOG.md

## Release Candidate 3 (2018-11-20)

Changes:

  - Use openHAB builder pattern
  - Cleanup code, use more constants
  - Lower log level for some debug messages
  - Use openHAB QuantityType
  
Bugfixes:

  - Fix issue if "°C" is used in configuration label
  
## Release Candidate 2 (2018-11-03)

Features:

  - Add additional serial port driver JSerialComm
  - New option in bridge configuration to choose serial port driver
  - Update eBUS library to version 0.9.19

This file has been truncated. show original

Download

org.openhab.binding.ebus-2.2.0-20170823.zip (alpha 1)
org.openhab.binding.ebus-2.2.0-20170904.jar (alpha 2)
org.openhab.binding.ebus-2.2.0-20170912.jar (alpha 3)
org.openhab.binding.ebus-2.2.0-20170917.jar (alpha 4)
org.openhab.binding.ebus-2.2.0-20170919.jar (alpha 5)
org.openhab.binding.ebus-2.2.0-20170924.jar (alpha 6)
org.openhab.binding.ebus-2.2.0-20170927.jar (alpha 8)
org.openhab.binding.ebus-2.2.0-20170929.jar (alpha 9)
org.openhab.binding.ebus-2.2.0-20171007.jar (alpha 10)
org.openhab.binding.ebus-2.2.0-20171015.jar (alpha 11)
org.openhab.binding.ebus-2.2.0-20171022.jar (alpha 12)
org.openhab.binding.ebus-2.2.0-20171102.jar (alpha 13)
org.openhab.binding.ebus-2.2.0-20171120.jar (alpha 14)
org.openhab.binding.ebus-2.2.0-20171204.jar (alpha 15)
eBUS binding 2.3.0-07052018 ZIP / KAR (alpha 18)
eBUS binding 2.3.0-230518 ZIP / KAR (alpha 19) openHAB 2.3 only!
eBUS binding 2.4.0-230618 ZIP / KAR (alpha 20) openHAB 2.3 only!
eBUS binding 2.4.0-21 KAR (alpha 21) openHAB 2.3 only!
eBUS binding 2.4.0-22 KAR (alpha 22) openHAB 2.3 only!
eBUS binding 2.4.0-23 KAR (alpha 23) >= openHAB 2.3 - not running!
eBUS binding 2.4.0-RC1 KAR (RC1) >= openHAB 2.4
eBUS binding 2.4.0-RC2 KAR (RC2) >= openHAB 2.4
eBUS binding 2.4.0-RC3 KAR (RC3) >= openHAB 2.4
eBUS binding 2.4.0-RC3-fix1 KAR (RC3) (latest) >= openHAB 2.4

Documentation

github.com

csowada/openhab2-addons/blob/ebus_public/addons/binding/org.openhab.binding.ebus/README.md

# eBUS Binding

The eBUS binding allows you to control your heating system. The eBUS protocol is
used by heating system vendors like Wolf, Vaillant, Kromschröder etc. You can
read temperatures, pump performance, gas consumption etc.

     ┌────────┐                       serial/usb (rs232) ┌──────┐
     │        │  serial (eBUS)  ┌───┐ or ethernet        │ ──── │
     │        │<--------------->│ X │<------------------>│ :    │
     │  ◊◊◊◊  │                 └───┘                    └──────┘
     └────────┘
    Heating Unit             eBUS Adapter              openHAB Server

## Supported Bridge

The bridge connects openHAB to an eBUS interface via serial interface or
Ethernet. You can buy a ready interface or solder your own circuit
(examples: [eBUS Wiki *german*](http://ebus-wiki.org/doku.php/ebus/ebuskonverter)).
A simple read-only interface can be build with an Arduino device.

This file has been truncated. show original

Screenshots

Sources

The binding contains

eBUS Core library

eBUS configuration library

openHab2 Binding

witek_1308 · 2017-09-02 13:55:29 UTC

@csowada, thanks for the great contribution. Question - can we expect vaillant config in the beta release (if so when?).
what lack of config means in practice to vaillant users? if I used jsons from 1.0 binding would this be good to go?

csowada · 2017-09-04 19:16:00 UTC

Hello All,

I’ve release a new version including discover service. This binding is still alpha, but it already works fine.
I also have converted the large BAI00 configuration to the new format. The format is not to different, but not compatible. I hope it’s enough for a test.

csowada · 2017-09-14 10:39:59 UTC

Hello @witek_1308,

the newest version contains the vaillant configuration files for bai00 and vrc devices.
The latest version should work, but I’m not able to test this version because I’m not at home.

witek_1308 · 2017-09-16 13:02:19 UTC

Hey @csowada, thanks. I’ve just downloaded it and giving it a try. A small hint needed - what are master and slave HEX addresses? Is it any value (as long as free, which I need to guess) or must be specific to Vaillant (mine is vc246)?
I tried with examples you gave for Wolf 71/76 and so far binding doesn’t see values from ebus:

(not yet in debug, as probably I have some major configuration problem which you can spot without debug)

2017-09-16 14:50:22.876 [ERROR] [de.csdev.ebus.core.EBusController ] - error!
de.csdev.ebus.core.EBusDataException: No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: FF 76 07 04 00 43]
at de.csdev.ebus.core.EBusReceiveStateMachine.update(EBusReceiveStateMachine.java:334)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.send(EBusController.java:349)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.onEBusDataReceived(EBusController.java:90)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.run(EBusController.java:190)[213:org.openhab.binding.ebus:2.2.0.201709121853]
2017-09-16 14:50:22.881 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Skip telegram FF 76 07 04 00 43 after 10 attempts …
2017-09-16 14:50:23.252 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from master address FF with command common.identification
2017-09-16 14:50:23.489 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from master address FF with command common.identification
2017-09-16 14:55:20.990 [ERROR] [.ebus.service.device.EBusDeviceTable] - ups, no master address!
2017-09-16 14:55:20.991 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from master address 10 with command common.identification

2017-09-16 14:59:44.533 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command ebus:vaillant-vrc:3ba1a240:dhw-program_dhw_circuit#program with FF 76 B5 09 03 0D 42 00 F4 …
2017-09-16 14:59:44.531 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command ebus:vaillant-vrc:3ba1a240:controller-temp_room#temp_room with FF 76 B5 09 03 0D 00 00 91 …
2017-09-16 14:59:46.666 [ERROR] [de.csdev.ebus.core.EBusController ] - error!
de.csdev.ebus.core.EBusDataException: No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: FF 76 B5 09 03 0D 42 00 F4]
at de.csdev.ebus.core.EBusReceiveStateMachine.update(EBusReceiveStateMachine.java:334)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.send(EBusController.java:349)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.onEBusDataReceived(EBusController.java:90)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.run(EBusController.java:190)[213:org.openhab.binding.ebus:2.2.0.201709121853]
2017-09-16 14:59:46.745 [ERROR] [de.csdev.ebus.core.EBusController ] - error!
de.csdev.ebus.core.EBusDataException: Telegram starts with an invalid source address! 08 [ERROR: INVALID_SOURCE_ADDRESS, DATA: ]
at de.csdev.ebus.core.EBusReceiveStateMachine.update(EBusReceiveStateMachine.java:184)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.send(EBusController.java:286)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.onEBusDataReceived(EBusController.java:90)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.run(EBusController.java:190)[213:org.openhab.binding.ebus:2.2.0.201709121853]
2017-09-16 14:59:46.803 [ERROR] [de.csdev.ebus.core.EBusController ] - error!
de.csdev.ebus.core.EBusDataException: Master CRC invalid! IS:7F SHOULD:00 [ERROR: MASTER_CRC_INVALID, DATA: FF FF 01 00 00 00]
at de.csdev.ebus.core.EBusReceiveStateMachine.update(EBusReceiveStateMachine.java:313)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.send(EBusController.java:336)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.onEBusDataReceived(EBusController.java:90)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.run(EBusController.java:190)[213:org.openhab.binding.ebus:2.2.0.201709121853]
2017-09-16 14:59:46.835 [ERROR] [de.csdev.ebus.core.EBusController ] - error!
de.csdev.ebus.core.EBusDataException: Telegram starts with an invalid source address! 0A [ERROR: INVALID_SOURCE_ADDRESS, DATA: ]
at de.csdev.ebus.core.EBusReceiveStateMachine.update(EBusReceiveStateMachine.java:184)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.send(EBusController.java:286)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.onEBusDataReceived(EBusController.java:90)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.run(EBusController.java:190)[213:org.openhab.binding.ebus:2.2.0.201709121853]
2017-09-16 14:59:46.899 [ERROR] [de.csdev.ebus.core.EBusController ] - error!
de.csdev.ebus.core.EBusDataException: Telegram starts with an invalid source address! F4 [ERROR: INVALID_SOURCE_ADDRESS, DATA: ]
at de.csdev.ebus.core.EBusReceiveStateMachine.update(EBusReceiveStateMachine.java:184)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.send(EBusController.java:286)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.onEBusDataReceived(EBusController.java:90)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.run(EBusController.java:190)[213:org.openhab.binding.ebus:2.2.0.201709121853]
2017-09-16 14:59:47.457 [ERROR] [de.csdev.ebus.core.EBusController ] - error!
de.csdev.ebus.core.EBusDataException: No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: FF 76 B5 09 03 0D 42 00 F4]
at de.csdev.ebus.core.EBusReceiveStateMachine.update(EBusReceiveStateMachine.java:334)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.send(EBusController.java:349)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.onEBusDataReceived(EBusController.java:90)[213:org.openhab.binding.ebus:2.2.0.201709121853]
at de.csdev.ebus.core.EBusController.run(EBusController.java:190)[213:org.openhab.binding.ebus:2.2.0.201709121853]

I didn’t change FF address (set by default) in eBUS Bridge config. I configured all through PaperUI as suggested (nothing in files)

csowada · 2017-09-17 06:55:11 UTC

For VRC devices the address is usually “10” for master and “15” for slave.

csowada · 2017-09-17 08:06:48 UTC

And for BAI00 it is “03” and “07”. The node discovery should be done by the discovery service, but the service is currently in an early stage.

witek_1308 · 2017-09-17 08:15:07 UTC

Thanks, 10 and 15 started to give me READ ONLY results. I can nicely see what’s on ebus but I can’t change anything like in v1.x
whatever I change it automatically gets immediately overriden back to the original value, eg.
2017-09-17 10:09:12.801 [ItemStateChangedEvent ] - VRCCommonDHWSetpoint changed from 47 to 48
2017-09-17 10:09:30.264 [ItemStateChangedEvent ] - VRCCommonDHWSetpoint changed from 48 to 47

no idea why. I have VRC470v4, there can’t be any magic, I guess people must have same issue and resolved it somehow.
I remember from debug on v1.x that (as per my little understanding of ebus) I could see acknowledgments of my parameters but never set on VRC. Is it possible that there is a flag which firstly need to be set to allow setting VRC values??? I doubt I’m just the only one with this issue…

csowada · 2017-09-17 08:28:34 UTC

Hello @witek_1308,

thank you for your fast response. In this Version there is a bug that breaks setting values. But getting values and polling should work? I hope I can fix this issue this evening.

witek_1308 · 2017-09-17 11:18:58 UTC

@csowada,
oh yes , it works like a charm comparing to what I experienced before [update] I was not specific enough - yes, both getting values and polling work good and take immediate effects after adding items.
Maybe I’m getting my comments too early and too optimitstic but before after +/- 10-15mins binding used to stop working and reconnect of usb was the only resolution. Now it is stable so far for half an hour, fingers crossed! Great news about the fix for setting value, this is very much needed.

I am experiencing however problem with BAI00 thing definition - when trying to add it via PaperUI I’m getting 500 Internal Server Error (no input in openhab.log), I tried different browsers and I restarted openhab. Error is immediate after pressing save/OK.
at the same time playing with VRC Common settings in paperUI (and adding channels/items) works correct. Any idea what could be wrong?

---- additional observation -----------

after some time I started getting this:
2017-09-17 11:12:10.915 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.

from the moment when the error appeared I didn’t see my values from ebus to be updated even though I can still see in log files the polling every n seconds (most meaningful is outside temperature which is still changing even by a small value)

Heating curve precision is 1 digit, should be 2. Maybe it’s my problem (I know how to set it when items configured in file but I’m still learning PaperUI). Temperature however is proper precision so maybe it makes sense to do the same with HC?

csowada · 2017-09-17 12:16:57 UTC

I already fixed the issue with BAI00, HC precision is also easy to fix.
Sorry for the short answers, I am currently on vacation with my family. So I can only spend time in the evening, if the weather is bad.

witek_1308 · 2017-09-17 12:28:17 UTC

no worries, enjoy your time. As I understand binding is your hobby (like using it is mine :)) therefore I’m not surprised you touch it during time off

karwak · 2017-09-17 13:18:07 UTC

Hi csowada,

hope you have a´great time enjoying your vacation!

I also have a Vaillant heating unit (ehp VWS171/2) and would love to support you with your new binding. However I have a general question first.

What is the binding intended to connect to?

I know that I can directly plug in my esera USB/ebus adapter to my openhab2’s Pi3B USB port, then configuring the serial port eg. /dev/ttyUSB0 in the ebus:bridge.
However I have a Pi2B close to my heating unit and an ebusd daemon running on it. Would the binding be able to connect to the ebusd daemons TCP or HTTP listener?
If no, what is the difference to the listener of the esera Network/ebus interface? Any idea?

Hope you can give me a hint …

Best regards! Take care…
Karsten

csowada · 2017-09-17 14:21:01 UTC

You can buy a Ethernet eBus Adapter or you can use a Linux tool like ser2net to Route the raw serial data to Ethernet. The binding doesn’t support ebusd over Ethernet.

csowada · 2017-09-17 20:46:29 UTC

So, a new version is available. Now the it should work with setting value.
But I can’t test this version with a real system, because I’m still on vacation.

csowada · 2017-09-17 21:17:46 UTC

It is important to remove the old things and bridge!

witek_1308 · 2017-09-18 19:43:36 UTC

hey @csowada,
thanks for the new release. I tested it tonight (followed your suggestions to remove things etc).
It doesn’t work for me however.
Binding can’t poll data from eBUS, I’m getting plenty of errors in the log which I havent’s seen before, sample below:
2017-09-18 21:31:07.334 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Received telegram from master address FF with command heating.temp_hcurve
2017-09-18 21:31:07.349 [ERROR] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]
2017-09-18 21:31:07.557 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Received telegram from master address FF with command dhw.program_dhw_circuit
2017-09-18 21:31:07.572 [ERROR] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]
2017-09-18 21:31:07.844 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Received telegram from master address FF with command dhw.temp_d_dhw
2017-09-18 21:31:07.848 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Received telegram from master address FF with command boiler.state_pump
2017-09-18 21:31:07.859 [ERROR] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]
2017-09-18 21:31:08.083 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Received telegram from master address FF with command controller.temp_outside
2017-09-18 21:31:08.097 [ERROR] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]
2017-09-18 21:31:36.979 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command ebus:vaillant-vrc:e7d6a1cf:vaillant-vrc-controller-temp_room#temp_room with FF 15 B5 09 03 0D 00 00 89 …
2017-09-18 21:31:36.979 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command ebus:vaillant-vrc:e7d6a1cf:vaillant-vrc-dhw-temp_d_dhw#temp_d_dhw with FF 15 B5 09 03 0D 44 00 80 …
2017-09-18 21:31:36.979 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command ebus:vaillant-vrc:e7d6a1cf:vaillant-vrc-dhw-program_dhw_circuit#program with FF 15 B5 09 03 0D 42 00 EC …
2017-09-18 21:31:36.982 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command ebus:vaillant-vrc:e7d6a1cf:vaillant-vrc-controller-temp_outside#temp_outside with FF 15 B5 09 03 0D 62 00 88 …
2017-09-18 21:31:37.154 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Received telegram from master address FF with command controller.temp_room
2017-09-18 21:31:37.166 [ERROR] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]
2017-09-18 21:31:37.376 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Received telegram from master address FF with command dhw.temp_d_dhw
2017-09-18 21:31:37.380 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Received telegram from master address FF with command boiler.state_pump
2017-09-18 21:31:37.389 [ERROR] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]
2017-09-18 21:31:37.599 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Received telegram from master address FF with command dhw.program_dhw_circuit
2017-09-18 21:31:37.614 [ERROR] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]
2017-09-18 21:31:37.839 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Received telegram from master address FF with command controller.temp_outside
2017-09-18 21:31:37.852 [ERROR] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]

I set addresses to 10 and 15. I see you prepared slave address config visible and optionally master address with option to supress telegrams for master. I tested my bidning with both settings (master telegrams suppressed and received). BTW - what is it for? Is it to read/write (with master) vs read-only config (just slave)?

I see that you fixed HC precision and BAI00 installs correctly (but can’t see anything under it, same issue as for VRC).

csowada · 2017-09-19 18:56:57 UTC

Hello @witek_1308,

this version should work now. I have a bad internet connection, more information tomorrow.

witek_1308 · 2017-09-19 19:52:04 UTC

hi @csowada,
it doesn’t work. Log file is pretty clean now,
2017-09-19 21:44:07.271 [WARN ] [.binding.ebus.internal.EBusDiscovery] - EBusDiscovery.onEBusDeviceUpdate()
2017-09-19 21:44:07.285 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘ebus::common_10_15’ to inbox.
2017-09-19 21:44:07.501 [WARN ] [.binding.ebus.internal.EBusDiscovery] - EBusDiscovery.onEBusDeviceUpdate()
2017-09-19 21:44:08.520 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘ebus::common_10_15’ to inbox.
2017-09-19 21:44:08.522 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from master address FF with command common.identification
2017-09-19 21:44:12.404 [WARN ] [.binding.ebus.internal.EBusDiscovery] - EBusDiscovery.onEBusDeviceUpdate()
2017-09-19 21:44:13.587 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘ebus::common_70_75’ to inbox.

I see you added autodiscovery option (and I tested both - VRC as well as eBUS Standard 10 15 things). What is different from the previous that I don’t see polling requests in the log initiated from the binding. Also, I see zero information about telegrams whereas before there were plenty of those (and I can see diode on the HW blinking like in normal operation when it gets communication from eBUS) and the observation is from more than 5-10 mins. Before from the comparable time the log was full of different events. Not sure if you supressed logging or maybe this part of code is not executed. Values from eBUS are not read/refreshed. I’m happy to share more logs/debug if you want.

csowada · 2017-09-20 06:33:56 UTC

I forgot to say, that you must remove all things and the bridge. The internal ids has changed again.
And yes, I have cleaned the log output to relevant information. But you can enable logging to debug for this binding.