Add support for 720-based regulators

[burmistrzak]

This PR is a superset of #482, including register definitions for the following regulator models:

• 15.720
• 15.basv
• 15.basv2
• 15.basv3
• 15.ctls2
• 15.ctlv2
• 15.ctlv3
• 15.bass

If you have one of the aforementioned devices, feel free to give this unified configuration a try and report back!
There're still a few unsupported devices at the moment, specifically:

• 15.ctlv*
• 15.ctls*
• 15.ctls3
• 15.bass2
• 15.bass3

*might not exist..?

In case you own one of them, please comment below with your setup details!

I also have incorporated (hopefully) all the recent discoveries made by @stadid, @chrizzzp & @jonesPD. 🤝
A fork of the CDN repo with pre-compiled definitions is available in English and German.

Testing & Validation

1. Clone the CDN fork from https://github.com/burmistrzak/ebus.github.io
2. Checkout dev branch (should be default)
3. Set EBUSD_CONFIGPATH to <MOUNTPOINT>/ebus.github.io/dev/en
4. Set EBUSD_MQTTVAR to e.g.:
   filter-direction=r|u|^w,filter-circuit=^bas*$,filter-non-circuit=^hmu*$,filter-name=^*,filter-non-name=^Z2|^Z3|^Hc2|^Hc3 (adjust to match your system)
5. Restart ebusd container (or service).
6. Check entities in HA and/or MQTT.
7. Look out for errors and report them below.

[chrizzzp]

@john30

2. writing temperature-independent timers (hwc, circulation) did **not** work

hm, did that work with the former csv then? the csv message definition for writing didn't change for cc e.g.

3. the timers for cooling and - more importantly - the noise reduction mode of heat pumps are missing. The latter are routinely used to set the heat pump to lower power levels. Here's the example from the current PR:

these are in the csv as well, so please check again (lines 555 and following of the generated csv).

Ok, then we're not on the same line and talk about different CSVs. I used the 15.ctlv2.csv you linked here. This does not have the definitions for silent and cooling timers.

Could you point me to the CSVs you referred to so I can check all timers again?

[chrizzzp]

@burmistrzak

Regarding timers, current implementation is here

ebusd-configuration/src/vaillant/_templates.tsp

Lines 571 to 581 in 68b4f0f

	/** constant value for writing a slot without target temperature */
	@constValue(0xffff)
	scalar wTimeSlotConst extends U2L;
	/** complete slot for writing without target temperature */
	model wTimeSlotWithoutTemp {
	slotIndex: slotIndex;
	slotCount: slotCount;
	slotTimeFrame: slotTimeFrame;
	wTimeSlotConst: wTimeSlotConst;
	}

I'd agree that having silent mode is essential.

Could you point me to the latest CSVs of this PR? It's a shame I still didn't invest time in figuring out don't know how to compile them myself... 🙈

[burmistrzak]

well in doubt everyone can just use an older version of the firmware that does still have that feature, so even if I'd do something like that, it would still be possible to use the device as before. I really think you're a bit pessimistic here assuming I would intentionally block features just because I could. basically the same is true for a lot of projects I guess and I don't think there is any example for such in any of the work I've done in this context for the past 13 years...

@john30 I'm not pessimistic per se, but there've been enough examples of these stunts (bait & switch, rug-pulls, etc.) in the technology sector to justify at least some caution. Especially in cases where proprietary firmware and FOSS intermingle.

I'm a big advocate for right to own/repair and relying on closed-source firmware anywhere (from servers to dishwashers) is an inherent liability and restricts what folks able to do (repair, improve, etc.) with the things they've paid for.
Now, these are polished products from major manufacturers I'm talking about and not a hardware adapter used together with free software to reverse engineer another proprietary protocol...

IMHO, keeping the eAS firmware closed puts you in an awkward position where people to some extent expect support like they get when buying e.g. a smart lightbulb.
Adopting a FOSS license would again limit your liability to hardware failures and you could simply point to the firmware repo and say: «There's the code, feel free to fix it yourself or pay me to do it for you».

yes, but then I can also just quit doing development there in the first place as a larger company could then just too quickly develop a new device and make a whole lot of money out of that (examples of that exist already, even with expectations to me doing their support).

A corp can always out-spent the average individual, but that's the case regardless of firmware licensing. They either hire a room full of devs or throw a bunch of AI against the problem.
In such a scenario, you're cooked anyways.
Why would anyone pay more for basically the same product but with less QC and no proper support or warranty?

You rely on folks (like myself) who see the value in your work, are sympathetic to the overall cause and decide to buy your hardware (incl. token subscription) instead.

and recent examples of decompiling binaries just fit perfectly to the same scenario btw

Well, how does that saying go? Information wants to be free?
I'd argue that doing something like this in a clean room fashion for non-commercial purposes to empower users it is completely different than a corp doing it for financial gain. But that's just my opinion.

[burmistrzak]

@chrizzzp There's no CSV. You'll have to compile it yourself. 😅

You need to pull the repo, checkout the merge564 branch and run npm install, followed by npm run compile. Make sure you have Git and NodeJS installed.

[john30]

Ok, then we're not on the same line and talk about different CSVs. I used the 15.ctlv2.csv you linked here. This does not have the definitions for silent and cooling timers.

Could you point me to the CSVs you referred to so I can check all timers again?

those were for a different PR and not related to this one.
anyway, here you go:
15.720.csv

[chrizzzp]

Tested the timers from the above 15.720.csv: Confirmed writing works for both

1. the temperature-bound timers (Z1...)

w -c ctlv2 Z1Timer_Friday "0;1;06:10;22:10;21"
empty

r -f Z1Timer_Friday0
06:10;22:10;21.0

2. and the temperature-independent timers (tested with SilentTimer...).

w -c ctlv2 SilentTimer_Friday "0;1;01:00;24:00"
empty

r -f SilentTimer_Friday0
01:00;24:00

BTW

• the current definitions contain only one time slot/frame per day (e.g. Z1Timer_Friday0). This might not be enough for many use cases (esp. DHW circulation), I suggest to define at least three time slots/frame per day for all timers or to use indexed reading (-i option) to reduce the amount of required definitions, as suggested here: VRC 720 configuration: understanding and managing Heating Zone time slots stadid/ebusd-configuration#3 (comment) as up to 11 time slots can be defined per day
• there is a nomenclature discrepancy concerning time slots / time frames (the timer definitions use time slot, other definitions use time frame: e.g. Z1Timer_Timeframes), BTW Vaillant uses the term 'time period" in the regulator

[chrizzzp]

Concerning this PR some HWC-related suggestions:

The following ExtHWC-related definitions should not be bound to the condition hc1exthwcactive=1, since hc1exthwcactive=1 is a dynamic runtime status indicator, that turns on only if the external DHW circuit is currently in operation (i.e. producing hot water).

[hc1exthwcactive=1]r,,,Hc1ExtHwcTempDesired,External hot water desired temperature heating circuit 1,,,b524,020002000900,ign,,IGN:4,,,,value,,EXP,,°C,temperature
[hc1exthwcactive=1]w,,,Hc1ExtHwcTempDesired,External hot water desired temperature heating circuit 1,,,b524,020102000900,value,,EXP,,°C,temperature
...
[hc1exthwcactive=1]r,,,Hc1ExtHwcOpMode,External hot water operation mode heating circuit 1,,,b524,020002001300,ign,,IGN:4,,,,value,,UIN,0=off;1=auto;2=manual,,
[hc1exthwcactive=1]w,,,Hc1ExtHwcOpMode,External hot water operation mode heating circuit 1,,,b524,020102001300,value,,UIN,0=off;1=auto;2=manual,,

Instead these definitions should be bound the condition: [hc1circuittype=3], which is a static configuration setting. The same applies to the corresponding hc2, hc3 settings.

Another issue:
My setup involves such a hc with circuit type 3 (=water=DHW=extHWC) although I don't have an original DHW circuit (i.e. I don't use the circuit to actually produce hot water, but to heat up my buffer cylinder for the heating). This means HwcEnabled = 0 (permanently off), but external DHW circuits can still be defined as active.

However, some of the HWC-related basic settings apply also to the 'external DHW circuit' (e.g. MaxCylinderChargeTime and and HwcLockTime). Unfortunately, these definitions are not available when the condition [HwcEnabled=1] is not met.
So could they be bound also to the condition e.g. [hc1circuittype=3] or just be unconditional?

[burmistrzak]

@chrizzzp Just checked, myVaillant allows max. three time slots per day. 👀

[chrizzzp]

And here are a few additions to the 15.720.csv (basic regulator settings):

*r,,,,,,B524,02000000,,,IGN:4,,,
*w,,,,,,B524,02010000,,,,,,
r;w,,TariffPrimHeaterLow,,,,,1100,,,UIN,,,Primary heater low tariff value
r;w,,TariffPrimHeaterNormal,,,,,1200,,,UIN,, ,Primary heater normal tariff value
r;w,,MultiInputSetting,multifunction input configuration,,,,6A00,,,UIN,0=not connected;1=1x circulation;2=photovoltaics;3=Ext.Cooling,,
r,,EnergyHeatingThisMonthMirror,,,,,C200,,,ULG,,,
r,,EnergyHeatingLastMonthMirror,,,,,C300,,,ULG,,,
r,,EnergyHeatingHWCTotalMirror,,,,,C500,,,ULG,,,
r,,EnergyHeatingHCTotalMirror,,,,,C600,,,ULG,,,

[stadid]

@chrizzzp Just checked, myVaillant allows max. three time slots per day. 👀

For 720 series regulators:
max 12 time slots per day for heating
max 3 time slots per day for DHW
max 3 time slots per day for DHW circulation

[john30]

Tested the timers from the above 15.720.csv: Confirmed writing works for both

thanks for testing!

* the current definitions contain only one time slot/frame per day (e.g. Z1Timer_Friday0). This might not be enough for many use cases (esp. DHW circulation), I suggest to define at least three time slots/frame per day for all timers or to use indexed reading (-i option) to reduce the amount of required definitions, as suggested here: [VRC 720 configuration: understanding and managing Heating Zone time slots stadid/ebusd-configuration#3 (comment)](https://github.com/stadid/ebusd-configuration/pull/3#issue-2169827331) as up to 11 time slots can be defined per day

I recognized that during the review and expected that to be intentional. so if it wasn't then these should get rolled back as well I guess

* there is a nomenclature discrepancy concerning time slots / time frames (the timer definitions use time slot, other definitions use time frame: e.g. Z1Timer_Timeframes), BTW Vaillant uses the term 'time period" in the regulator

wrt the slotCountWeek template usage I only see "*_Timeframes" in the old tsp and the new, so where do you see the discrepancy exactly?

[chrizzzp]

• the current definitions contain only one time slot/frame per day (e.g. Z1Timer_Friday0). This might not be enough for many use cases (esp. DHW circulation), I suggest to define at least three time slots/frame per day for all timers or to use indexed reading (-i option) to reduce the amount of required definitions, as suggested here: VRC 720 configuration: understanding and managing Heating Zone time slots stadid/ebusd-configuration#3 (comment) as up to 11 time slots can be defined per day

I recognized that during the review and expected that to be intentional. so if it wasn't then these should get rolled back as well I guess

Yes, roll back to three time slots or - maybe more efficient - have a single read time slot predefined (e.g. Monday0) and add a definition that allows indexed reading of any number of time slots:

e.g.

[hc1circuittype=1]r,,,Z1Timer_Monday,timer heating monday indexed read 1,,,b555,a5000000,index,m,UCH,,,,htm,,HTM,,,,htm_1,,HTM,,,,slottemp,,UIN,10,°C,desired temperature of a slot

• there is a nomenclature discrepancy concerning time slots / time frames (the timer definitions use time slot, other definitions use time frame: e.g. Z1Timer_Timeframes), BTW Vaillant uses the term 'time period" in the regulator

wrt the slotCountWeek template usage I only see "*_Timeframes" in the old tsp and the new, so where do you see the discrepancy exactly?

This is what I meant, it's rather a naming inconsistency. Therefore I suggest to rename "*_Timeframes" to "*_Timeslots".

[john30]

@chrizzzp ok I've addressed your suggestions in d581175, 0d63db7, 10b51ed, and 74360dd. I've also made TariffAuxHeater writable as it would be unreasonable otherwise (maybe you can confirm that?).

now to your other findings:

r;w,,MultiInputSetting,multifunction input configuration,,,,6A00,,,UIN,0=not connected;1=1x circulation;2=photovoltaics;3=Ext.Cooling,,

does that depend on some setup, so is this specific for yours e.g. or would this be available always?

r,,EnergyHeatingThisMonthMirror,,,,,C200,,,ULG,,,
r,,EnergyHeatingLastMonthMirror,,,,,C300,,,ULG,,,
r,,EnergyHeatingHWCTotalMirror,,,,,C500,,,ULG,,,
r,,EnergyHeatingHCTotalMirror,,,,,C600,,,ULG,,,

if these are "mirrors", where would the non-mirrored value be then? is this related to e.g. PrFuelSumHcThisMonth and which unit do these have (probably kWh)?

[john30]

added the MultiInputSetting as well and merged to master in 4875c46
only thing missing are these mirror energy counters (presumably), therefore kept open

[chrizzzp]

@john30

I investigated more into the Tariff-related definitions. To implement it properly we need a few more definitions, e.g. I just discoverd the tariff timer (for dual tariff operations in trivalence hybrid manager mode, actually quite a neat feature as it considers energy cost and heat demand) and the the register that defines the backup heater type (gas or electrical). I'm currently trying to find the register that specifies single/dual tariff selection, so the tariff timer can be bound to dual tariff as a condition. I will compile my findings here very soon...

[chrizzzp]

OK, here are the updated definitons for the tariff settings. Unfortunately, I could not identify the register for single/dual tariff selection. However, I suggest to make all these definitions conditional to:

[HybridManager=0]
(triVAl mode of hybrid manager, definiton already in the config).

EDIT: The following registers were confirmed to be writable.

*r,,,,,,B524,02000000,,,IGN:4,,,
*w,,,,,,B524,02010000,,,,,,
r;w,,TariffBackupHeater,,,,,1000,,,UIN,, ,Secondary heater tariff value
r;w,,TariffPrimHeaterLow,,,,,1100,,,UIN,,,Primary heater dual tariff low tariff value
r;w,,TariffPrimHeaterHighSingle,,,,,1200,,,UIN,,,Primary heater single tariff value/dual tariff high value
r;w,,BackupHeaterType,,,,,1300,,,UCH,0=Condensing;1=Non-Condensing;2=Electrical,,in hybrid manager trival mode only

According to the VRC720 manual, BackupHeaterType 0 and 1 are specific to gas boilers (Condensing = "Brennwert" in german). The Vaillant manual uses the term "Backup Boiler" instead of "Backup Heater". Not sure if we aim for consistency here with Vaillant nomenclature.

Here are the Tariff timer definitions: should be conditional to the dual tariff, but as mentioned I didn't find this register yet.

(sorry for the mix of old and new CSV definitions)

r,,,TariffTimer_Timeslots,Tariff timer amount,,,b555,a40006,ign,,IGN:1,,,Amount of configured slots per weekday,slotcount,,UCH,,,number of slots on a day,slotcount_1,,UCH,,,number of slots on a day,slotcount_2,,UCH,,,number of slots on a day,slotcount_3,,UCH,,,number of slots on a day,slotcount_4,,UCH,,,number of slots on a day,slotcount_5,,UCH,,,number of slots on a day,slotcount_6,,UCH,,,number of slots on a day,ign_1,,IGN:1,,,
r,,,TariffTimer_Monday0,Tariff timer monday 1,,,b555,a500060000,ign,,IGN:1,,,,htm,,HTM,,,,htm_1,,HTM,,,,ign_1,,IGN:2,,,
w,,,TariffTimer_Monday,Tariff timer monday,,,b555,a6000600,slotindex,,UCH,,,index of a time slot,slotcount,,UCH,,,number of slots on a day,htm,,HTM,,,,htm_1,,HTM,,,,wtimeslotconst,,U2L,=65535,,constant value for writing a slot without target temperature
r,,,TariffTimer_Tuesday0,Tariff timer tuesday 1,,,b555,a500060100,ign,,IGN:1,,,,htm,,HTM,,,,htm_1,,HTM,,,,ign_1,,IGN:2,,,
w,,,TariffTimer_Tuesday,Tariff timer tuesday,,,b555,a6000601,slotindex,,UCH,,,index of a time slot,slotcount,,UCH,,,number of slots on a day,htm,,HTM,,,,htm_1,,HTM,,,,wtimeslotconst,,U2L,=65535,,constant value for writing a slot without target temperature
r,,,TariffTimer_Wednesday0,Tariff timer wednesday 1,,,b555,a500060200,ign,,IGN:1,,,,htm,,HTM,,,,htm_1,,HTM,,,,ign_1,,IGN:2,,,
w,,,TariffTimer_Wednesday,Tariff timer wednesday,,,b555,a6000602,slotindex,,UCH,,,index of a time slot,slotcount,,UCH,,,number of slots on a day,htm,,HTM,,,,htm_1,,HTM,,,,wtimeslotconst,,U2L,=65535,,constant value for writing a slot without target temperature
r,,,TariffTimer_Thursday0,Tariff timer thursday 1,,,b555,a500060300,ign,,IGN:1,,,,htm,,HTM,,,,htm_1,,HTM,,,,ign_1,,IGN:2,,,
w,,,TariffTimer_Thursday,Tariff timer thursday,,,b555,a6000603,slotindex,,UCH,,,index of a time slot,slotcount,,UCH,,,number of slots on a day,htm,,HTM,,,,htm_1,,HTM,,,,wtimeslotconst,,U2L,=65535,,constant value for writing a slot without target temperature
r,,,TariffTimer_Friday0,Tariff timer friday 1,,,b555,a500060400,ign,,IGN:1,,,,htm,,HTM,,,,htm_1,,HTM,,,,ign_1,,IGN:2,,,
w,,,TariffTimer_Friday,Tariff timer friday,,,b555,a6000604,slotindex,,UCH,,,index of a time slot,slotcount,,UCH,,,number of slots on a day,htm,,HTM,,,,htm_1,,HTM,,,,wtimeslotconst,,U2L,=65535,,constant value for writing a slot without target temperature
r,,,TariffTimer_Saturday0,Tariff timer saturday 1,,,b555,a500060500,ign,,IGN:1,,,,htm,,HTM,,,,htm_1,,HTM,,,,ign_1,,IGN:2,,,
w,,,TariffTimer_Saturday,Tariff timer saturday,,,b555,a6000605,slotindex,,UCH,,,index of a time slot,slotcount,,UCH,,,number of slots on a day,htm,,HTM,,,,htm_1,,HTM,,,,wtimeslotconst,,U2L,=65535,,constant value for writing a slot without target temperature
r,,,TariffTimer_Sunday0,Tariff timer sunday 1,,,b555,a500060600,ign,,IGN:1,,,,htm,,HTM,,,,htm_1,,HTM,,,,ign_1,,IGN:2,,,
w,,,TariffTimer_Sunday,Tariff timer sunday,,,b555,a6000606,slotindex,,UCH,,,index of a time slot,slotcount,,UCH,,,number of slots on a day,htm,,HTM,,,,htm_1,,HTM,,,,wtimeslotconst,,U2L,=65535,,constant value for writing a slot without target temperature

The manual states up to 12 tariff time slots can be defined, so I suggest to add indexed reading also for this timer (sorry not done yet for the above snippet).

[chrizzzp]

@john30

... only thing missing are these mirror energy counters (presumably), therefore kept open

OK, I had to revise the b524 mirrored energy statistics a little. Some were not assigned correctly (which I hadn't checked before) and I found more.

All values are in kWh.

They are mirrored/collected once per day (I think at midnight) from - I assume - the b516 energy statistics (and converted from Wh to kWh). That's why I suggest a new naming with reference to the b516 Stat* energy values.

*r,,,,,,B524,02000000,,,IGN:4,,,
*w,,,,,,B524,02010000,,,,,,
r,,StatMirrorElectricEnergyHcLastYear,,,,,C000,,,ULG,,kWh,
r,,StatMirrorElectricEnergyHcThisYear,,,,,C100,,,ULG,,kWh,
r,,StatMirrorElectricEnergySumThisMonth,,,,,C200,,,ULG,,kWh,
r,,StatMirrorElectricEnergySumLastMonth,,,,,C300,,,ULG,,kWh,
r,,StatMirrorElectricEnergySumThisYear,,,,,C400,,,ULG,,kWh,
r,,StatMirrorElectricEnergySumLastYear,,,,,C500,,,ULG,,kWh,
r,,StatMirrorElectricEnergySumTotal,,,,,C600,,,ULG,,kWh,

I haven't checked yet if they are writable, but I assume yes.

These values correspond to the energy values that can be queried from the VRC720 regulator UI. There must be more values (including HWC and more HC and probably solar, environmental and fuel stats).

[chrizzzp]

Here are the general Tariff definitions in the current CSV format:

r,,install,HybridManager,hybrid manager,,,b524,020000000f00,ign,,IGN:4,,,,value,,UCH,0=trivalence;1=bivalence,,hybrid manager mode
w,,install,HybridManager,hybrid manager,,,b524,020100000f00,value,,UCH,0=trivalence;1=bivalence,,hybrid manager mode
r,,,TariffBackupHeater,tariff backup heater,,,b524,020000001000,ign,,IGN:4,,,,value,,UIN,,,backup heater tariff
w,,,TariffBackupHeater,tariff backup heater,,,b524,020100001000,value,,UIN,,,backup heater tariff
r,,,TariffPrimHeaterLow,low tariff main heater,,,b524,020000001100,ign,,IGN:4,,,,value,,UIN,,,Primary heater dual tariff low tariff value
w,,,TariffPrimHeaterLow,low tariff main heater,,,b524,020100001100,value,,UIN,,,Primary heater dual tariff low tariff value
r,,,TariffPrimHeaterHighSingle,high tariff single main heater,,,b524,020000001200,ign,,IGN:4,,,,value,,UIN,,,Primary heater single tariff value dual tariff high value
w,,,TariffPrimHeaterHighSingle,high tariff single main heater,,,b524,020100001200,value,,UIN,,,Primary heater single tariff value dual tariff high value
r,,install,BackupHeaterType,backup heater type,,,b524,020000001300,ign,,IGN:4,,,,value,,UCH,0=condensing;1=non-condensing;2=electric,,backup heater type
w,,install,BackupHeaterType,backup heater type,,,b524,020100001300,value,,UCH,0=condensing;1=non-condensing;2=electric,,backup heater type

IMO the tariff cost definitions should be left out of the installer access level, as tariffs for gas/electricity could change from time to time and this is how it is done also in the VRC720 regulator UI.

I also noticed all time slots of the tariff timer will be reset to 00:00;00:00 as soon as the HybridManager register is set to 1(bivalence). The tariff timer slots will default to 11:00;13:00 if HybridManager is set to 0(trivalence).

[legacycode]

I tested the current 720-based config on a live Vaillant setup and wanted to share one more data point.

Device detected on ebus:

• MF=Vaillant;ID=CTLV0;SW=0312;HW=9103
• real device: Vaillant sensoHOME VRT 380

For local testing, I mapped 15.ctlv0 to 15.ctlv2 and generated the CSV alias vaillant/15.ctlv0.csv -> 15.ctlv2.csv.

Result:

• the device is recognized and loaded successfully
• basic operation works
• the new 720-based definition is a clear improvement over the older config

Remaining issues I still see with this device:

• FM5Config: ERR: invalid position
• Hc3CircuitType: ERR: invalid position

So at least for this CTLV0 variant, ctlv2 looks like a good baseline, but a few fields still seem not to match the actual payload layout.

[chrizzzp]

• FM5Config: ERR: invalid position

• Hc3CircuitType: ERR: invalid position

Isn't this expected for the VRT380 not being able to control more than a single heating circuit? Is the VR71 (FM5) an option at all for this regulator? If not, this would explain the error messages.

IMO the VRT380 is not a full 720-based regulator (that this PR addesses). However, good to see that many of the definitions work.

[stadid]

@d3vi1
If you are interested, you could reach @legacycode for full id string of his VRT380 and ask him to perform full scan using your solution.

Actually, such behavior of CTLV2 config is expected on VRT380 due to the reasons described above by @chrizzzp.
In simple words VRT380 (at least identified as CTLV0) is a VRC720 limited to one zone/circuit only.

[burmistrzak]

@john30 FYI, the micro-ebusd service still doesn't like this definition:

> bunx -p @ebusd/ebus-typespec tsp2ebusd -m <REDACTED> -i src/vaillant/15.ctlv2.tsp
connecting micro-ebusd...
preparing for micro-ebusd <REDACTED>
Error: compilation failed:
error invalid-schema: Schema violation: must match pattern "^ *[a-zA-Z][a-zA-Z0-9]* *(, *[a-zA-Z][a-zA-Z0-9]+ *)*$" (/withAttrs)
  pattern: ^ *[a-zA-Z][a-zA-Z0-9]* *(, *[a-zA-Z][a-zA-Z0-9]+ *)*$
    at run (file://<REDACTED>/ebusd-configuration/node_modules/@ebusd/ebus-typespec/dist/src/tsp2ebusd.js:199:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)

Local fork is at cdc11e18124e49b6638bb743110219f95e5d405f for testing.

[john30]

@john30 FYI, the micro-ebusd service still doesn't like this definition:

you need to update to the latest https://github.com/john30/ebus-typespec version

[stgm]

@burmistrzak and probably @john30 Would you consider using the "Noise Reduction" terminology as used in the control module user interface + the Vaillant manuals? Consistency with the official documentation is my reason to argue for Noise Reduction instead of Silent Operation here.