Implement VWZ Live Monitor readings & Test Menu #316
Conversation
kjoglum
force-pushed
the
master
branch
2 times, most recently
from
12b98bb to
31aa5a7
Compare
|
Made some adjustments, and additions for VWZ test menu, believe the PR is ready for evaluation/merge. |
|
Tried your PR and I can tell that I receive some additional and valid values for my setup, thx |
|
Does one need to do something to trigger the live monitor? I've applied this PR and see new fields appear, but none of them appear to be updating? Examples from Since there's no heating/cooling demand nor domestic hot water demand, I suspect many values are expected to not update. But the yield should be updated? |
|
@wimleers |
|
Thanks for the incredibly fast response! 🤯
So this PR does not decode any additional messages already being transmitted on the bus? Your comment at #160 (comment) suggests I should do Is that right? The tricky thing is that I'm running |
|
I got a great hint from somebody in a Dutch forum (you know who you are!): to use That worked! Output: As you can see, lots of decoding errors. But also some actually working values! 😊 What additional information do you need from me? What next steps do you want me to take? |
|
@wimleers E.g.: Alternatively: |
|
Sorry — I didn't mean to mix things up. I just saw a bunch of "yield"-mentioning lines changed in your PR. So I jumped to that one first. Apologies for the distraction. Let me try to get this back on track 😊 I'm especially interested in 7–13 and 30–51. So that's ✅ 7–13
Clearly these work fine! 🥳 ❌ 30–51
What can I be doing wrong to get I'm using the latest version of That string originates from https://github.com/john30/ebusd/blob/23.1/src/lib/ebus/result.cpp#L39.
I see 4 possible explanations — maybe you can think of more:
I personally suspect the root cause is … no mention of "VWZ" ☝️ … but I do see a mention of "VWZ" under http://mist.local:8080/data/scan.76: Any chance we need a new How to know which one it is? I'm very eager to help you land this! 😊 |
|
@wimleers |
|
Doesn't that mean that lines 30–51 should be moved out of |
|
08 is the only device reporting these values om the bus. And in fact, 08 already contains some uniTower values which give the same error (invalid position) for VWZ AI. So I believe these need to co-exist in 08. |
To me that suggests that those values are also misplaced. I wish I understood enough already about the architecture to make an informed suggestion where that should be placed 😅 |
|
I am neither familiar with the architecture behind, just been able to decode messages on the bus. The issue must be that VWZ AI and uniTower both are types of HMU, using 08 as slave address, even though they appear to have different functionality/data. Possible also related to values of interest being replicas of actual button presses on the HMU’s, whereas VWZ AI and uniTower have different menu setup. On the other hand, I do not see why this should be an issue? Why can we not have a 08 csv file covering both, even though some values would be unavailable across VWZ AI/uniTower..? |
"unavailable" would be fine, but EDIT: based on this output, I think we should be able to distinguish and |
|
See my in-progress review at #330 (comment) — that PR works far better for my system. @kjoglum Could you please test that PR so we can start the work to EDIT: at #330 (comment) I posted an initial proposal for how to combine the two PRs. |
|
@wimleers Example 1:
Note: Example 2:
Note: Also see missing values for PBSB 503. So maybe existing PRs (316 and 330) can be merged without conflicts, as they are using different IDs? Covering different use case / equipment setup. Although, to allow both systems to "live" within same file, without "killing" similar equipment setups as mine, PR #330 would be required to subdivide IDs below main categories. E.g.: Having the main category |
kjoglum
force-pushed
the
master
branch
3 times, most recently
from
0d12e4c to
69a6db2
Compare
|
I have a Vaillant VWL75/5AS heat pump with VWZ AI. When I used this configuration file to read parameters while heating domestic hot water, the pump behaved strangely. It turns off every now and then, and then restarts in hot water heating mode. I am using MQTT to read parameters. |
Signed-off-by: kjoglum <[email protected]>
|
@kjoglum Thanks...yes I am using central config files, seems these files were automatically updated about 2 days ago, after which I am missing the CurrentConsumedPower and CurrentYieldPower. I did suspect thes were moved to LiveMonitorPowerConsumption and LiveMonitorPowerGenerated, but during the last 2 days these values were near 0, which could not have been true. But I have rebooted and upgraded ebusd today and it seems they now show more realistic values. So let me observe for the next couple of days... |
|
@kjoglum unfortunately no success yet, and I dont think waiting any longer will change the outcome. It showed me a more or less realistic reading once today (dont know why), and afterwards it only shows a consumption of max 0,1KW. See the screenshots below for a comparison of a normal day with old and new config file (both days with similar outside temperature and heating requirements) Everytime I checked with "ebusd ebusctl find -v" I get a reading between 0.0 and 0.1, so its definitely not a homeassistant or MQTT issue:
|
|
@copacetic82 Do you have a MQTT config for requesting/retrieving Pretty sure if you run |
|
@kjoglum I am using the automatic homeassistant discovery, so homeassistant is using the following MQTT LiveMonitor topics: { In comparison to Current*Power: I did read the LiveMOnitor Values directly from ebusd while the heatpump was actually runnig. So in my opinion ebusd is not getting the correct values, or is not updating the values frequently enough. Strangely enough I got another "spike" shortly after midnight, so the MQTT config seems to be working:
I will try the commands you mentioned when I have more time. |
|
@kjoglum Thank you for your help. Executing "ebusctl write -c hmu ReadLiveMonitor FF3224" repeatedly does indeed show realistic values. How is the new implementation intended to work? Do I manually have to trigger a read? Wont be a problem, I could write an automation for this, but dont know if this this is the way it is supposed to work.
|
|
@copacetic82 |
|
@kjoglum In the past I never had to trigger updates of CurrentConsumedPower. However the value always seemed to be a bit off. e.g I could hear the heatpump running outside, but the value was 0. I tested with an automation, triggering a LiveMonirot update every 20-30sec...the readings now seem to be more accurate than ever, thank you! ;) The only issue I am having now is that the "LiveMonitorPowerGenerated" sometimes has spikes of very high values (600-800KW), which I cant believe are true, and which mess up the whole graph. The usual values shown are 5-9KW as expected. Do you also observe this?
|
|
@copacetic82 Haven´t been using the |
|
@copacetic82
|
|
@kjoglum Thanks for checking! If you have the same issue it must be a Vaillant thing. I can possibly do something about this in homeassistant by using filters. But consumption is most important for me, so I might just live with this. Thanks again for your help! :) |
|
@kjoglum Why did this PR remove "EnergyIntegral", accident? |
|
@dfeist |
|
I have a aroTHERM plus VWL 105/6A fw: 9.01 heat pump. When I used this configuration file to read parameters the pump behaved strangely. The pump turned off for no reason and turned on again after a while. |
|
@MiroBehrik Also, are you sending frequent MQTT write requests to retrieve data? No changes made to the config files which would turn off the pump. |
|
Yes, the compressor will turn off. The MQTT reading frequency is once every 2 min new 08.hmu.csv odl 08.hmu.csv |
|
@MiroBehrik Seen john30/ebusd#1205 ? Looks like same issue. |
|
@MiroBehrik @dfeist This is not an issue for openHAB integration, running "manual" MQTT topics to write/trigger read values. Although unfamiliar about how the hassio config/integration works, and why this issue occurs. |
|
I've managed to see what went on in my HP, when the ebus started sending the request for values. The CalculatedFlowTemp, dropped from 60 to 20 for a fraction of a minute, witch caused the HP, to shutdown due to no heating needs, a little while after, the Calculated value returned to 60, and the compressor started, then this kept happening for ever. 
Maybe this will help someone. Let me know if I can be of assistance with testing. |
|
there was quite some mess around this PR and it is now reverted. better extract the changes to a separate file for inclusion for those interested in it @kjoglum |
|
An update from john30/ebusd/issues/1205: We found the culprit. All Home Assistant integrations (MQTT and ebusdpy) actively poll read values. Either the HMU or the controller doesn't take kindly if one of the introduced read values in the updated 08.hmu.csv (we still don't know which) is actively polled by another master, which then leads to a full stop of the heat pump. An issue was opened at ebuspy CrazYoshi/ebusdpy#10 (for the core integration) and a pull request was opened john30/ebusd#1213 to prevent MQTT from actively polling. After these issues have been addressed, I think the configuration could be merged into master, again. |
|
an extension to message definitions is not supposed to break thousands of running integrations, so clearly changing the polling mechanims on either ebusd or another integration (like ebusdpy) is definitely not the right approach. |
|
looking at this again more closely due to merge activities, I'm pretty sure that the new messages categorized as read but actually starting the live monitoring caused the trouble earlier this year. |
|
please check the next generated csvs with ebusd 24.1 (or current source) as described there or by using a local clone of https://github.com/eBUS/ebus.github.io and using the "next" folder in there |
Following up on PR #160 to implement values from VWZ (heat pump controller).