Firmware enhancements for ventilation/heat recovery

[TomoKRK]

Hi Schelte, I would like to ask for considering the enhancements in firmware for ventilation/heat recovery I think particularly important
from stand-alone operation perspective.
I have been enjoying integration of OTWG with my Brink/Renovent heat recovery, and have been able to get this working
with some basic/core integration. I mean setting the ventilation speed through VS command or reading the temperatures etc.
However I am lacking some additional data to be read and/or write from/to my Brink device and that's mainly connected with TSPs.
I have pulled together some analysis (attached in the PDF file) it's based on pieces of information, code found on the Internet
as well as cross-referencing those with the readouts from my Brink.

1) Read TSPs by specific index
Currently, you can get the number of TSPs by sending PM=88 and then following this immediately (I think) firmware is pulling
the values for each of them subsequently. This process is lengthy and takes roughly 2,5-3 mins. So it's not practical to get actual
readouts of the current ventilation speed, volume, pressures in ducts etc that way as it's lengthy. It would be great to have possibility
to issue for example command PM=89,12 and get the value of TSP[12] - currently PM=89 always returns TSP[0].
That way it would be possible to readout those values in more robust and efficient way in various integrations.

2) Write/change TSP value by specific index
It would be great also to have ability to write data for the specific TSP. That would enable remote control, setup and configuration
of the device without a need to go to it physically, what in my case would be great advantage as I have it installed in the attic so access
there is not easy. That would be applicable to first 50 TSPs as they seem to hold the configuration of the device, while higher ones
are keeping more operational data/indicators.
For example command PM=89,12,4 would write at 12-th TSP value 4.

A couple of considerations/comments:
- In the absence of the OT specification I am not clear to what extent this TSP list is standard for all the vendors or it's rather dynamic
and changes from vendor to vendor. When I was compiling it I used also some info available for Vitovent device and they seemed
same/similar - however I do realise my unit and Vitovent could be same hardware just different branding
- For some values to make them meaningful there is a need to read/write 2 bytes from subsequent TSPs as they hold whole value.
i.e. TSPs 4 & 5 hold value for the HIGH (3) level of ventilation
- I also think that for the actual processing of the TSPs might be responsible thermostat which controls setup and configuration too,
however I don't have it and plan to operate OTGW in stand-alone mode
- I also saw some similar request on github for NodeMCU Nodo firmware regarding the heating devices to process TSPs too and I think
those two asks for enhancement could be bundled together

Additionally I am not clear or sure, why some of the operational data are not available directly through PM entry I mean the fan/ventilation speed,
could it be connected with the configuration or my setup. When you look at the response of PM=86 it says:
- Nominal ventilation value transfer: disabled (0)
- Nominal ventilation value: read-only (0)

Maybe there should be some other message sent I mean PM=86 with some value to enable those readouts, just thinking at loud here.
I have also attached the list of the MsgIDs which are supported by my Brink.

Let me know your thoughts on this topic.
Regards
Tomek.

[hvxl]

While these are interesting suggestions, there are two problems:

1. There is not much space left in the PIC for new features.
2. I don't have access to a device that supports TSP, making it difficult for me to test features in that realm (I was actually surprised that TSP readout worked at all for V/H).

I will keep this in consideration, but don't expect something along these lines any time soon.

Some additional comments on remarks in your post:
It surprises me that some TSPs contain status information. The term "parameter" implies to me that they are intended for reasonably static settings.

The TSP list is completely non-standardized. Every vendor can define TSPs as they like.

The NodeMCU firmware cannot do anything that the PIC firmware doesn't support. Of course there's the option to load the interface firmware in the PIC. Then the NodeMCU has pretty much total control.

The "Nominal ventilation value" represents the mid position of a 3-speed ventilation system. ID74:HB2 shows that your system has variable speed control rather than 3-speed. So it makes sense that ID86 indicates that you cannot transfer information about a 3-speed related value. This is also consistent with ID87 returning Unk-DataId.

[TomoKRK]

Schelte - thank you for clarification on a couple of points - now it's clear to me that TSPs is quite difficult topic.
I fully understand the limitations of PIC however if you consider adding at least accessing TSP by index - I think that
would be great as I believe it is the most important/critical from my point of view as to my surprise too it holds
some key operational data and not only configuration. And perhaps just this change would not be that big of an issue .
Additionally, I fully get that you don't have access to the device but I will be more than happy to test it,
I know remotely is not that efficient and effective, but I can support you here accordingly.

Regards,
Tomek