Conversation
|
Hello rmalbrecht, I appreciate the proposal to fix the table, which would make it better readable. I am not sure whether this is the right spot to ask: I could create a pull request with a few definitions I found out as below. However, I have them in 08.hmu.csv in a local folder. I have tried to set configpath to my forked folder, copying the path at github: --configpath=https://github.com/JGJ156/ebusd-configuration/tree/e68294b3e0cdf393c9b2d52299eca2aba01e43d3/ebusd-2.1.x/en However the ebusd software does not find the files: 22024-12-04 22:18:10.439 [main error] unable to load scan config 15: list files in vaillant ERR: element not found Have you been able to connect ebusd to your forked folders directly? <style> </style>
|
|
Hi,
EbusD can’t access webdav or similar protocols, Only local files. Johns central repo is a special case and has extra code inside the daemon.
I have my files local and just use GitHub to store and share them.
Do you have the complete message definitions your new attributes? I would like to include them.
cu romal
… Am 04.12.2024 um 23:15 schrieb JGJ156 ***@***.***>:
Hello rmalbrecht,
I appreciate the proposal to fix the table, which would make it better readable. I am not sure whether this is the right spot to ask: I could create a pull request with a few definitions I found out as below. However, I have them in 08.hmu.csv in a local folder. I have tried to set configpath to my forked folder, copying the path at github: --configpath=https://github.com/JGJ156/ebusd-configuration/tree/e68294b3e0cdf393c9b2d52299eca2aba01e43d3/ebusd-2.1.x/en However the ebusd software does not find the files: 22024-12-04 22:18:10.439 [main error] unable to load scan config 15: list files in vaillant ERR: element not found
Have you been able to connect ebusd to your forked folders directly?
<style> </style>
540200
0609 JRunDataReturnTemp3digits
4A0D JRunDataFlowTempDesiredCut0.5
7C08 JAlways 13.4
A60E JRunDataFlowTempSetPoint
A70E JRunDataCompressorInletTemp1SecInterval
A90E
AC0E
B608 JRunDataCondensorOutletTemp3digits
BC09 JRunDataDeltaPPump?
BD09 JRunDataWaterThroughPut
E50B Hchours?
—
Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL3HP6CYIGUPMBOIWAEZKZL2D55GLAVCNFSM6AAAAABSZ235NOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJYGY3DSNBSGE>.
You are receiving this because you authored the thread.
|
|
thanks rmalbrecht. codes I have so far: <style> </style>r,,JRunDataReturnTemp3digits,,,,,0609,,,EXP,,,,,,,,,,,,,,,,,,,,,r,,JRunDataFlowTempDesiredCut0.5,,,,,4A0D,,,EXP,,,,,,,,,,,,,,,,,,,,, |
|
the above codes seem to yield some error now. I have done some set up changes and I now need to check few things first. Please ignore the codes till further notice. |
Controller for Recovair 275
Recovair 275
Add passive message definition to update the attributes.
This reverts commit 7a5b423.
|
Hi rmalbrecht, additional 08.hmu.csv codes should be okay now, in my repository. I am using Github now as well for storing the files. Quite cumbersome though, changes need to be put on RPI (I am using Filezilla). Since this does not have sudo access to defsfolder I need to sudo copy it on the RPI using SSH. after having updated the file, I need to sudo reboot RPI after disconnecting the Ebus cable. Leaving the cable connected, makes the EBUS communication go down and I need to restart both arotherm plus and VWZ. Any advice most welcome. I could do a pull request, but maybe build some further experience first. |
|
Hi,
I`m not sure I can follow.
I have two different ebusD installations:
One is native on a Raspberry Pi with RaspiOS, that eBusD is accessing an emus-adapter over wifi that is connected to by Recover. That installation I can access with SSH and push or pull changes to Github via git. Reloading makes eBusD reading the changes csv-files. Quite comfortable.
The other one is running as an add-on on Home Assistant. Here I have the advanced terminal (https://github.com/hassio-addons/addon-ssh) and Visual Studio Code (https://community.home-assistant.io/t/home-assistant-community-add-on-visual-studio-code/107863) installed. VSC then has a CSV-extension for better editing. Git is available in the terminal, so I can pull and push to my or other repos. The eBus-Adapter is connected via USB, restarting the add-on via GUI works mostly fine. With the advanced terminal, you can also run commands inside the eBusD container and edit/test/reload there directly.
Restarting the Arotherm was never necessary is my setup.
cu romal
… Am 11.12.2024 um 23:59 schrieb JGJ156 ***@***.***>:
Hi rmalbrecht, additional 08.hmu.csv codes should be okay now, in my repository. I am using Github now as well for storing the files. Quite cumbersome though, changes need to be put on RPI (I am using Filezilla). Since this does not have sudo access to defsfolder I need to sudo copy it on the RPI using SSH. after having updated the file, I need to sudo reboot RPI after disconnecting the Ebus cable. Leaving the cable connected, makes the EBUS communication go down and I need to restart both arotherm plus and VWZ. Any advice most welcome. I could do a pull request, but maybe build some further experience first.
—
Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL3HP6FYMIQ3ZVN4XZGDA2T2FC7UNAVCNFSM6AAAAABSZ235NOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZXGM3TENBQGM>.
You are receiving this because you authored the thread.
|
|
hi, thanks for this. |
|
@jonesPD I’ve been using your forked csv config files successfully for a few months (with all your caveats understood and accepted!) but I have hit a crossroad. Your fork seemed to add a lot of entities I use now that weren’t available under john30's config files, but updating to HA eBusd addon 24.1.1 and reverting to john30’s config files at https://ebus.github.io/ causes the loss of many of those entities. I’m long time hobbyist but not an experienced dev. Any advice on direction from here appreciated. |
|
Same here. With the latest HA add-on many of the entries stopped working |
|
Have you a local copy of the configuration files? They work perfectly fine for me with the newest eBusD add-on. |
|
Yes I've tried both existing locally saved config files and the current ebus-configuration files and I've lost many working entities with 24.1.1. Rolling back to 23.2.5 with existing local config files and the entities all come back. I'm running a sensoCOMFORT vrc 720 and my local config has three files containing this name 15.basv2 15.ctlv2 and 14.ctlv3 now looking at these files they aren't the same as those in the latest directory perhaps that's the issue. Update: found 12 config files that needed updating to local from latest and 24.1.1 now seems to be working with additional entities discovered. Many thanks for the support and code @rmalbrecht + @jonesPD much appreciated. |
comparison mhz values and RPI values MHZ (VWZ) indicates evaparation temperature and EEV outlet temperature. Evaporation temperature consistent with JRunDataCompressorInletTemp1SecInterval ->name changed into evaporation temperature. EEVoutlet temperatures consistent both on MHZ and RPI. However too high and the sensor does not exist-> still unknown what it is Actual subcooling much lower than target subcooling. MHZ talks about nominal undercooling -> name changed from target to nominal copied from JGJ156
|
version 24 is much stricter in attribute names: more more umlauts, no leading numbers, ... You need to update to files or rename you attributes manually. |
| r,,RunStatsFan2Starts,,,,,DA0B,,,cntstarts2;IGN:2,,,,,,,,,,,,,,,,,,,,,, | ||
| r,,RunStatsFan2Starts,,,,,DA0B,,,cntstarts2;IGN:2,,,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataAirIntakeTemp,,,,,DE08,,,tempv,,,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataHCHours,,,,,E50B,,,UIN;IGN:2,,,,,,,,,,,,,,,,,,,,, |
There was a problem hiding this comment.
For my Arotherm split system this registers corresponds exactly to the half of the value of
RunStatsHcHours
RunningHoursHc
There are more hour counters yet to be assigned...
r,,unknownMB509hE10B,,,,,E10B,,,UIN;IGN:2,,hours,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,
r,,unknownMB509hE20B,,,,,E20B,,,UIN;IGN:2,,hours,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,
r,,unknownMB509hE30B,,,,,E30B,,,UIN;IGN:2,,hours,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,
r,,unknownMB509hE40B,,,,,E40B,,,UIN;IGN:2,,hours,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,
r,,unknownMB509hE60B,,,,,E60B,,,UIN;IGN:2,,hours,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,
r,,unknownMB509hEA0C,,,,,EA0C,,,EXP,,,Unknown from VR921 to HMU,,,,,,,,,,,,,,,,,,
There was a problem hiding this comment.
RundataHC hours now 10 hours difference with HC hours on my system. they were exactly the same before,
There was a problem hiding this comment.
So, they represent different hour counters. How often are these values updated? Maybe more frequent polls give a clue whether JRunDataHcHours e.g. also includes De-Icing, while HcHours does not (just an idea...).
|
Just an comment concerning the RunData/RunStats (b509) values: Depending on the system setup (split or unitower) not all values exist/yield meaningful data from each circuit (hmu/vwz). E.g. in split systems the condensor and the water pump are in the hydraulic station (vwz) and the associated values have to be polled from the Concerncing nomenclature: As most of these values can also be read from other registers (often with lower precision) I used the same name just with the prefixes RunData/RunStats to indicate that these a actually the same values (inspite of different precision). For the prefix I suggest to use: RunData... for current opperational values But, of course, this is just a suggestion... |
| r,,Always13_4,,,,,7C08,,,EXP,,,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataCompressorInletTemp,,,,,9808,,,tempv,,,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataCompressorOutletTemp,,,,,A208,,,tempv,,,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataFlowTemp,,,,,A60E,,,EXP,,,,,,,,,,,,,,,,,,,,, |
There was a problem hiding this comment.
From my analysis this is not the flow temp (supply) but the higher-precision copy of
r,,CondensationTemp,,,,,5603FFFF,,,temps2,10,°C,Condensation temperature (°C),,,,,,,,,,,,,,,,,,
There was a problem hiding this comment.
Have analysed the same again, I think you are right. not sure why I thought Flowtemp before
| r,,RunDataStatuscode,,,,,530D,,,scode;IGN:*,,,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataCurrentConsumedPower,,,,,5B0D,,,powerv,,,current consumed electrical power (Watt),,,,,,,,,,,,,,,,,, | ||
| r,,RunDataHighPressure,,,,,6A09,,,pressv,,,,,,,,,,,,,,,,,,,,, | ||
| r,,Always13_4,,,,,7C08,,,EXP,,,,,,,,,,,,,,,,,,,,, |
| r,,RunDataEEVPositionAbs,(EEV Position in different scale?),,,,280A,,,UIN,,,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataFan1Speed,,,,,470A,,,EXP,,rpm,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataFan2Speed,,,,,490A,,,EXP,,rpm,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataFlowTempDesiredTrunc,,,,,4A0D,,,EXP,,,,,,,,,,,,,,,,,,,,, |
There was a problem hiding this comment.
If the suffix 'Trunc' relates to the precision (1 decimal only): this is the same value sent to the hmu by the regulator (SetMode) which is also only 1 decimal position, so I suggest to omit the 'Trunc' suffix.
There was a problem hiding this comment.
With Trunc, I meant a number like 1.87 becomes 1.8. With rounding off, a number like 1.87 would become 1.9. Here it seemed truncated rather than rounding off. But suffix can be omitted, since other message definitions do not make distinction either
There was a problem hiding this comment.
Yes, this accounts for all "duplicate" values I checked. The "lower precision" value is always truncated (not rounded) and gives only one decimal position.
|
|
||
| ## Polls from VR921 every 10 mins,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, | ||
| *r,,,,,,B509,540200,,,IGN:4,,,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataReturnTemp3digits,,,,,0609,,,EXP,,,,,,,,,,,,,,,,,,,,, |
There was a problem hiding this comment.
On my (split) system this value is delivered by the vwz only.
| r,,RunDataCondensorOutletTemp3digits,,,,,B608,,,EXP,,,,,,,,,,,,,,,,,,,,, | ||
| r,,RunStatsHMUHours,,,,,B80B,,,UIN;IGN:2,,hours,,,,,,,,,,,,,,,,,,, | ||
| r,,RunStatsHcHours,,,,,B90B,,,UIN;IGN:2,,hours,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataDeltaPPump,,,,,BC09,,,EXP,,,DeltaP?,,,,,,,,,,,,,,,,,, |
There was a problem hiding this comment.
For my system this register always returns 0.0 (both from hmu und vwz).
What is meant by 'DeltaP'?
There was a problem hiding this comment.
This is just guessing, no question marks allowed in the name. There seems to be a constant factor of 1.96 between this parameter and waterflow. maybe the waterflow is measured by a difference in pressure (deltaP?) over the pump. max pressure difference is set at 900, this parameter is slightly higher though in my set up with monoblock. see graph. I was probably asking for the 'deltaP?' every minute and for waterflows much less.
There was a problem hiding this comment.
Yes, obviously the water throughput registers are updated less frequent. One could fetch these values more often by MQTT or manual reading (ebusctl). However, this does not explain the ratio between this value and the water throughput.
Other associated parameters are maybe pump power and water pressure.
| r,,RunStatsHcHours,,,,,B90B,,,UIN;IGN:2,,hours,,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataDeltaPPump,,,,,BC09,,,EXP,,,DeltaP?,,,,,,,,,,,,,,,,,, | ||
| r,,RunStatsHwcHours,,,,,BC0B,,,UIN;IGN:2,,hours,total runtime of Hwc mode,,,,,,,,,,,,,,,,,, | ||
| r,,RunDataWaterThroughPut,,,,,BD09,,,EXP,,,,,,,,,,,,,,,,,,,,, |
There was a problem hiding this comment.
My (split) system always returns 0.0 for this value (both from vwz and hmu).
Instead I use:
*r,,,,,,B51A,05,,,IGN:3,,,,,,,,,,,,,,,,,,,,,
r,,WaterThroughput,,,,,FF323C,,,UIN,,l/h,,,,,,,,,,,,,,,,,,,
*r,,,,,,B514,05,,,IGN:2,,,,,,,,,,,,,,,,,,,,,
r,,BuildingCircuitFlow,,,,,2B03FFFF,,,UIN,,l/h,Current heating water flow rate (liter/hour),,,,,,,,,,,,,,,,,,
(both yield the same)
There was a problem hiding this comment.
...could maybe explained by different system setups (e.g. how the water pump is connected).
There was a problem hiding this comment.
probably yes, see graph above.in my case, the waterpump is outside in the monoblock, where the HMU is as well.
|
Folks, I've created a streamlined, and hopefully more reliable definition for modern HMUs. Feels free to give it a try and report back! 🙌 john30#472 |
|
Hi all, I see a lot of messages like this, below 4 within one second: Master part: 26,27,28, 29 and also 32,33,34,35. Slave returns the 26,27,28,29. 71 being vwz and 08 hmu in monoblock heatpump Collecting multiple message over time and grouping them by response:
If I am polling these as read messages, am I then actually writing to the system? |
|
@JGJ156 Well, we don’t really know. However, we can make a somewhat educated guess:
See here: https://github.com/john30/ebusd/wiki/HowTos#creating-new-message-definition-files Regarding these unknown messages, I‘ve seen them myself as well. Were you by chance clicking through the menu at the VWZ? |
|
When 'grep'ing through some logfiles spanning several days I noticed the above Here's an example: So, question is whether these messages contain any useful information and why they are sent over ebus quite often? Different with the |
I had similar experiences, that's why I try to stick to logging ebus traffic for certain unknown registers. Any message - read/write - sends data over the ebus from the master to the slave address and yields a response from the slave. So a wrongly defined read message could also lead to an (unintended) write message. Often, the write messages have relatively short slave responses (1-4 bytes), but this is not necessarily true for all write messages. So IMHO one has to be careful issuing poll commands to unknown register ranges... |
6 participants
No description provided.