Mh, you have the ebus core and configuration two times in the list and also the binding is old. It’s from 3. Jan . You should uninstall the feature and/or bundle first. And then re-add the new kar file.
I would use one of the commands below to uninstall the old bundles. I would start on the highest level and try to remove kar and/or feature first. The rest could be uninstalled by bundle. Afteerwards a restart withoud kar file in addons folder should help to start with a clean environment. Could you help me and other users with a short explanation what has helped in your case?!
Initial check list: kar:list has a proper version of 2.5.1-6 feature:list has a proper version of 2.5.1-6
but bundle:list did not
What I did:
disable all related things (with ebusd bridge)
uninstall bundles (bundle:list is empty)
restart openhab without kar file
add kar file
did not helped: kar and feature list still the same, but bundle:list is empty
uninstall kar
uninstall feature
restart openhab without kar file
add kar file
enable all related things (with ebusd bridge)
success!:
openhab> bundle:list|grep -i ebus
266 x Active x 80 x 1.0.6.202002091840 x eBUS library configuration
267 x Active x 80 x 1.0.6.202002091840 x eBUS core library
268 x Active x 80 x 2.5.1.202002091841 x openHAB Add-ons :: Bundles :: eBUS Binding
And the most important thing: setting parameters works!
Do anyone have also a Vaillant VMS (Solarmodule with buffer) ?
I haven’t found any documentation about ebus telegrams and ‘hacked’ some parameters. I have a VMS08. It comes up as ‘vms02’. So I think the telegrams are the same for VMS02 to VMS08.
Have prepared a json file for solar-, buffer-temperature and solar yield.
If someone has knowledge about additional ebus parameter, please let me know. Have found out that there are more special via B5 09 0D/29 - but no clue about the meaning.
If someone has a VMS and not already prepared a json it would be nice to check this file as custom configuration vaillant-vms02-configuration.json (2.6 KB)
Another issue
After fixing the last one I did not change anything in the ebus binding. Just few OH restart regarding MQTT config (other binding).
But I’ve noticed that setting parameters stopped working again. At first partially (I could rise temp but no decrease it), but when I started debugging everything stopped working. In logs, after the Poll command I saw lots of:
Send queue is full! The eBUS service will reset the queue to ensure proper operation.
After restart and changing to Raw mode and jSerialComm driver, setting parameters works, but in TRACE log, after every Poll command I see:
“Unable to send polling command due to a unconnected controller”
Of course, I don’t have any Item updates by polling, only by the messages broadcasts.
Changing back to ebusd is still not working.
OK. Probably there was a problem with serial adapter. And in logs I saw an info about upgrading ebusd 3.3 -> 3.4. So I did that. But then the .deb updater changed /etc/default/ebusd file.
There was missing --enablehex!!
Right now everything works.
However when I do a grab in ebusd :
ebusctl grab result all
ebusd is able to decode this message :
1008b510090000486cffff00ff00 / 0101 = 1: bai SetMode
From my understanding of the ebus protocol, it is the same.
Is there a way to help you to decode them? It is the message from the heating controler in the room which I would like to “replace” or emulate to better control my house temperatures.
On the same principle :
2020-02-19 17:12:31;“10”;“08”;“B5 13”;“02 05 0A C4 00 01 01 9A 00 AA”;
ebusd : 1008b51302050a / 0101 = 3
I think this one is not decode neither but happen less often when the heating controler sends some control values (answer from the SetPoint command) :
1008b5110102 / 050314964c78 = 66: bai Status02
Hi,
I have questions about binding version numbers and planned OH upgrade:
I have OH v2.5.1-1 with binding “for 2.4.0 and beyond”, RC3 manually installed from kar file.
I am planning to upgrade my OH to the latest version which is 2.5.2-1.
Will / should this binding work or it’s already know it won’t?
Is there a way to install something for 2.5.x from the PaperUI instead of kar files? Whereas I have no issues installing it manually, every couple of OH upgrades it happens that manually installed add-ons are causing problems and downgrade + manual intervention is needed to fix it.
It is not maybe a good habit to respond to self but I had time to test it and maybe this will address concerns of other people - the latest release (2.5.1-6) works with OH 2.5.2-1 apart from minor thing - BAI (08) built in element D.041 - Return temperature D.041 seems not being reported (in PaperUI -> Control it is represented as -NaN). Will try to debug further but it worked in previous setup (OH 2.5.1 and binding 2.4.0 RC3)
I think the data you need is in the previous message from me with pasted logs in it (the one before i said i could turn the logging level down but that return temp was still not working). The data returned contains an extra work which in the ebusd config files is labeled as temp_mirror so i have just added that in the slave definition for return temp in vailant-bai00-configuration.json
Thanks @jpharvey , how did you do it? I tried to find it but I couldn’t, is it somehow compiled into the binding? I know I can add my own config file on top of it, but I’d prefer to fix the base one above instead.
creating new json with just one thing (bai08_fix) and one channel in it (return temp 0.041)
none if it worked even though it was detected properly with proper thing id and mapping. I guess this is something about decoding this message in the version I have (it worked for others e.g. @jpharvey) but maybe this isn’t exactly the same version.
What logs to collect to focus on this specific message?
cat /var/log/openhab2/openhab.log | grep pump
2020-03-06 07:51:26.334 [DEBUG] [.csdev.ebus.command.EBusCommandUtils] - Value state_pump with 94 is larger then allowed 1
2020-03-06 07:52:26.347 [DEBUG] [.csdev.ebus.command.EBusCommandUtils] - Value state_pump with 94 is larger then allowed 1
I have activated this parameter also on my system. And yes, there are comming 5 bytes (not 3). Telegram:
2020-03-09 09:05:04;“FF”;“08”;“B5 09”;“03 0D 98 00 B7 00 05 17 03 E8 FC 00 B2 00”;
But I have not activated this on my system. Think equal is on your system?: I have a VRC700 implemented. Here some telegrams are in general active between VRC700 and BAI00. I try to have as less poll sequences as possible on my system to reduce the traffic on the ebus.
Here with the telegram ‘boiler.control.getopdata’ the return temerature can be read along without dedicated separate poll.
Maybe those idea is working also on your system?
