Hi Cor. Saw values of e.g. -41% today for the “CurrentCompressorUtil”. Would expect a range of 0…100%. Isn’t it the 3rd byte we are looking for (38 hex) instead of the fourth byte (62 hex) which we looked for initially? If i confugure it like this, i get +56% instead of -41%.
In ebusd i get the negative values as well ??? This lets me doubt. Initially i only checked if i get the same readings in openHAB as in ebusd and this was the case applying your solution.
If the forth byte (62 hex) is right, could it be the data type “data1c” instead of “data1b”? In John’s list D1B is signed integer which is dedicated for -127…+127 while D1C is unsigned integer which is for 0.0…100.0 (would match the desired percent range). If this is the case, John’s 08.hmu.csv would contain a failure for the “CurrentCompressorUtil”?
Hello Willibald. The csv file gives “IGN:3” meaning to ignore the first three bytes of the response. Also, 62 hex equalled 98 when converting it to signed integer (d1b), which was the utilization that you read from ebusd.
You also have the Vaillant app apparently (as you could compare the circulation pump status). The csv file screenshot shows the text “some more statistics from Live Monitor”. Are you able to compare your values with values that are given by a Vaillant controller, app or device?
Understood what IGN:3 is now. Then everything seems to be okay. The myVaillant app doesn’t show such parameters. Will dig into the controller and see what i can get there. “Live Monitor” should be a menu point. In the meantime i observed “CurrentCompressorUtil” values between -105% and +122% while “off” is 0%. Interesting that Veit doesn’t see negative values. What type is your pump? I have an aroTherm VML105/6 heatpump.
Went through the “Live Monitor” of the controller in expert mode. Beside interesting other parameters like “compressor hours” or “compressor starts” i only found “compressor modulation”. While i saw the desired “CurrentCompressorUtil” at -76% the “compressor modulation” value was +27%.
For the moment i conclude that “CurrentCompressorUtil” is likely not a valid parameter of my heatpump type. If i figure out something new, i will let you know.
Will see if i can grab telegrams using “ebusctl grab result decode” while i step through the desired compressor parameters within the Vaillant “Live Monitor”.
Made some progress. Have been able to grab telegrams using “ebusctl grab result decode” while i stepped through the desired compressor parameters within the Vaillant controller. Searched for the appropriate values then. This is at least valid for a Vaillant aroTherm VML105/6 (year 2020).
The value “CurrentCompressorUtil” from John30 is obviously not existing within the controller menu of my heatpump but i left it in the .json file for other users. It worked out at least for Veit (see above). Instead of “compressor utilization” i found “compressor modulation” which makes sense for a modulated inverter heatpump.
Edited on 10.01.2023.
Added the following new parameters to my Vaillant hmu08_config.json and updated the file below:
I’m running Openhab 3.4.1 on Windows 11 with EBUS binding 3.2.14.
After a Windows update at the weekend, Openhab always ended itself after 30-60 minutes without an error message.
Assuming it could be Java, I went to Zulu 17. When that didn’t work either, I’m now on 4.0.0 Snapshot. The system runs with that, but I always get the error message from the Ebus binding.
Exception in thread "ebus-receiver-707" java.lang.NoSuchMethodError: 'void org.openhab.core.library.types.DecimalType.<init>(java.math.BigDecimal)'
The funny thing is that the message only appears in the console and does not appear in the log file.
Does anyone know what I’m doing wrong ?
It will not work because openHAB 4.0-SNAPSHOT started to introduce non-compatible changes which affected all bindings. The ebus binding will require update to work with that release. Please go back and stay a bit with 3.4.
Java 17 is not an issue, issues are caused by changes in OH 4.x codebase itself. The NoSuchMethodError you saw tells that method with which code was compiled can not be found at runtime. You can run probably OH 3.3 with Java 17.
just one thing that was not easy for me to figure out and I’d like to share:
The ebus binding really works like a charm. Great work, really love and appreciate!
I installed the ebus binding via Paper UI and then created all items manually in an item file and added the channel. This is the common way for me cause I’ve a legacy setup with item files since Openhab 1.x and never changed everything. So I remained to use the *.item files for setting up items.
After creating all relevant items and adding the channels, everything seem to be working fine, but I figured out, all items were read only. So i tried lot’s of things but nothing worked to get items to write changes to ebus. Almost drove me nuts
The solution for me was, to delete all manual config via item files and to create all items in PaperUI. That solved EVERYTHING and it worked out of the box without any issues. No weird error messages in the log, everything read and write, everything stable and fun.
Just wanted to let you know, that items via PaperUI solved a lot problems and saved a lot of work for me
And again thanks to @csowada for the really really great plugin.
Hello, I need some help and namely I have a fresh openhab 3.4.1 installation on a Pi4 with an eBUS Adapter 3 HAT (adapter.ebusd.eu). In OH only the eBUS binding and the MQTT binding is installed. In the “/boot/config.txt” I entered “dtoverlay=pi3-miniuart-bt” because serial0 pointed to ttyS0 and now points to ttyAMA0. The eBUS Bridge goes online, but I can’t find my “VAILLANT package 1.331/5 ecoCOMPACT VSC 146/4-5 150 LL with VRC 700/6” in a scan.
What am I doing wrong or have I forgotten?
I have the following information in addition.
pi@openhabian:~ $ dmesg|grep ttyAMA0
[ 1.664016] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 32, base_baud = 0) is a PL011 rev2
2023-01-23 19:02:52.164 [WARN ] [internal.things.EBusTypeProviderImpl] - eBUS command boiler.control.setopdata only contains a setter channel!
2023-01-23 19:02:52.685 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - Use eBUS binding 3.2.14 [eBUS core: 1.1.8, eBUS configuration: 1.1.6]
2023-01-23 19:02:52.689 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS core -> timestamp 202112291704, commit: #768d88c, build-no: #null
2023-01-23 19:02:52.693 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS configuration -> timestamp 202112291722, commit: #7d79e24, build-no: #null
2023-01-23 19:02:52.889 [WARN ] [s.internal.handler.EBusBridgeHandler] - Enable advanced logging for eBUS commands!
2023-01-23 19:02:53.025 [INFO ] [al.EBusSerialBuildInSerialConnection] - Use openhab build-in serial driver .................................................................
==> /var/log/openhab/events.log <==
2023-01-23 19:02:52.867 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'ebus:bridge:5ec478bf3e' changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to INITIALIZING
2023-01-23 19:02:53.002 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'ebus:bridge:5ec478bf3e' changed from INITIALIZING to UNKNOWN: Connecting to eBUS ...
2023-01-23 19:02:53.079 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'ebus:bridge:5ec478bf3e' changed from UNKNOWN: Connecting to eBUS ... to ONLINE
2023-01-23 19:02:53.307 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:broker:mqttbroker' changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to INITIALIZING
2023-01-23 19:02:53.481 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:broker:mqttbroker' changed from INITIALIZING to OFFLINE
==> /var/log/openhab/openhab.log <==
2023-01-23 19:02:55.006 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '172.28.1.2' with clientid piheater
==> /var/log/openhab/events.log <==
2023-01-23 19:02:55.324 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:broker:mqttbroker' changed from OFFLINE to ONLINE
==> /var/log/openhab/openhab.log <==
2023-01-23 19:07:53.074 [WARN ] [dev.ebus.core.EBusLowLevelController] - eBUS Watchdog Timer!