I tried it out myself but I got stuck in finding out the value in the telegrams.
As you wrote I first executed “ebusctl grab” and it told me “grab continued”.
Than I executed the command “ebusctl grab result decode > Test_9.txt” to decode the commands.
Before this I did set the value to 9 °C on the controller.
I did the same with 11 °C to be sure to get the correct value.
Now I cant find the value in the saved files.
It looks like I cant find any command from or to the VRC720 which has the slave adress 15.
Do I have to do something in addition like starting the heatpump?
Or is it because I dont have the ethernet module, so no device is reading out the values?
Here are the files I did save (too large to upload here):
Assume that its z1CoolingTemp which you are looking for, right?
What happens if you type ebusctl read z1CoolingTemp?
It has nothing to do with missing internet unit. The indoor controller doesn’t provide all values on ebus. But the values which are treated through the outdoor’s HMU should be available on ebus.
Examples for indoor devices which are not treated through ebus are the additional heater or the 3-way hot water circuit valve. Both are indoor.
If i can figure something out, i will come back to you.
z1CoolingTemp is the temperature for cooling zone1.
But I do not have a Vaillant device in my rooms so this value is completely ignored by the controller.
It does only react to the minimum cooling temperature setting like I descibed.
It should be located in this part of configuration but is missing yet:
Okay. Please type “ebusctl grab result all” and search for “Hc1MinCoolingTemperature”. Let me know the answer (ebus telegram code).
The result should look like this:
ff15b52406020002001000 / 080302100000005c42 = 4: 720 Hc1MaxFlowTempDesired
ff15b52406020002001200 / 08030212000000e041 = 4: 720 Hc1MinFlowTempDesired
I don’t have the cooling feature. Its at least not contained within John30’s configuration for the VRC720.
Looks like 7 degrees and seems to work. The “no data stored” then means that the grab was not long enough
3115b52406020002001100 is the transmit ebus telegram and 08030211000000e040 is the received ebus telegram. The “= 6” means that 6 received telegrams have been monitored.
You can search now within the .txt-files you provided for theese telegram code. I will do so here now.
I am not able to find the transmitted code with both of the files you provided for 9 and 11 degrees. Then, the grab was probably not long enough to detect the desired ebus telegrams.
Probably I will need you help again.
I did try a lot in the last days but was not successful creating a .json file for the cooling.
Worst part is that I do not get the command into the grab result decode.
Starting garb, waiting some time, saving to file and searching for some matches and all of this multible times.
I tried to read and write the value while grab is running.
Is there another way to implement it?
I mean ebusd already knows the command.
I can read and write from the console.
Really thought the last part could not be this hard …
This helps but its a bit tricky. We have the answer 080302110000001041 and the temperature is 9 degrees. Acc. to John30 the datatype is EXP (signed float number with low byte first).
08 is the adress byte
03021100 are the 4 bytes to be ignored (IGN:4)
00001041 are the 4 bytes which contain the required data
Low byte first means that we are looking for 41100000.
A online floating point to hex converter results in 9 degrees:
The next problem is now that the data types of the openhab ebus binding are different to John30’s ebusd. For the json-file we need “reversebyteorder”: true and i guess that EXP (ebusd) is equal to “number” in openhab with “length”: 4 (4 bytes).
Now to the .json. Please replace the header data and let me know the outcome:
Wow this is really great work from you.
I tried different datatypes myself but never expected a reversed byte order.
Sadly right now it does not work.
I have changed the “id” to “HMU02_Cooling” because the yield file already has this id.
Also I did try it without the “reverseByteOrder” because it looks like the “true” does not fit to the .json style.
The channel item remains in “NULL” and there is no error message in the log.
Per the docs of the binding ebusd EXP data type is ebus binding data type “float”, not “number”. It does not mention a reversebyteorder for that data type, but you can try with and without it, just see what works.
