mpvader
commented
3 years ago As implemented now, vedirect-interface puts it on d-bus as com.victronenergy.dcmeter, always.
The new plan is to put on the d-bus as for what its configured to be. There are the lists:
Sources:
- com.victronenergy.solarcharger
- com.victronenergy.alternator
- com.victronenergy.fuelcell (exists already)
- com.victronenergy.dcsource (for all the rest, including shaft generator, watergenerator/hydropower, charger and windcharger and other more rare things, and includes dc dc chargers as well)
Note that dcdc chargers will some day end up being com.victronenergy.dcdc, but lets do that later; it needs more discussion, and its very rare; so better do that once we also have real dcdc chargers with a communication port and data about input and output.
Loads:
- com.victronenergy.motordrive (though not very common, this is an existing profile, see vrmlogger datalist.py for example)
- com.victronenergy.dcsystem (this is intended for measuring the complete dcsystem; with one shunt. Or if customers want to, break it up in a few subsystems. If one or more such services are present, systemcalc is to add htem all up and use their measurements rather than the calculation it does at the moment, which is taking the difference between battery and multi dc current).
- com.victronenergy.dcload (even when the BMV is configured to meter an inverter, put it on the D-Bus as dcload, since the alternative, putting it on as com.victronenergy.inverter, will be very limited).
Ofcourse, customers can give their things custom names, so also dcsource and dcload can be given custom names by them.
Actions for round two (see below comment from me, Matthijs):
Necessary for v2.80
Can be done later:
Original text
As of v4.06 the BMV/SmartShunt supports the Monitor Mode (see https://github.com/victronenergy/victronconnect/issues/372) allowing the BMV/SmartShunt to be configured as a "simple" monitor without charge/battery related functions (such as consumed Ah, SOC, charged cycles etcetc).
Configuration of this monitor mode is done via VE_REG_BMV_MONITOR_MODE. The BMV textframe has a "MON" item indicating which monitor mode the BMV is configured for. Negative values are defined as "sources" and positive values are defined as "loads". The 0 (zero) value, being the default, is defined as the "normal" BMV mode. Possible options/values for the monitor mode are defined in https://github.com/victronenergy/velib/blob/master/data/protocols/vregs.xml under "meanings:vregs:monitoring.mode".
When a non-bmv mode is configured (thus monitor mode is unequal to value 0) the following vregs in the BMV will return the invalid value:
Likewise, the following items in the textframe will get the "---" value:
Furthermore, when the auxiliary input is configured for the MidPoint option and/or the relay mode is configured for the Charger option, then those settings will automatically return to their default value when configuring the monitor mode to a non-bmv option. Both options are conflicting with non-bmv monitoring mode and can therefor not be used anymore.
To prevent losing the history by mistake, the history is not automatically cleared when changing the monitor mode. Clearing the history after changing the monitor mode might be something to propose/suggest to the customer as certain history items will not be updated anymore in a non-bmv mode and for items still updated it might not make sense to mix bmv and non-bmv history.
Impact: Venus OS: support in ve.direct interface driver/stack for VE_REG_BMV_MONITOR_MODE and "MON" Venus OS: VRM logger to support monitor mode VRM: Support for monitor mode to be added