TSP parameters uitlezen

[rvdbreemen]

Hi Schelte,

I am trying to fetch the TSP transparent slave parameter from my Elga Ace. But I have tried the PM=10 command, I read it would fetch the TSP's from the OpenTherm bus. However I have not been able to do that.

Do you know of anyone successfully fetching TSP using the OTGW bus?

Looking forward to hear from you,
Robert

[hvxl]

Log?

Yes, some people have reported that they are successfully reading TSPs (and wanted a way to read a specific TSP, or wanted to write a TSP).

[rvdbreemen]

Hi Schelte,

Well, here we go a log (see attachment) of my PM=10 command. I have tried twice, the otgw is in gateway mode. I never see a Data-ID 10 asking for the number of TSP's. So the whole process of asking for the individual TSP never starts (Data-id 11). So I was thinking, in what scenario's the PM command never gets an opportunity to send out a Data-ID, and what could I do about this.

I noticed that in the documentation you say:

Priority Message - Specify a one-time priority message to be sent to the boiler at the first opportunity.

I interpreted it as, I will send the Data-ID as soon as possible, overruling anything else. But I never see Data-ID 10 go by, so I am thinking it's different. Any suggestions for me here?

So I also looked at the forum here, and I found only one post on the topic. Asked around and other users have successfully used PM=10, and got the TSP's from their boiler. The process of asking all TSP one by one is slow. And when you want one it is slow to ask 67 parameters from the slave. I think it would be useful to have a feature to just ask a single TSP, based on a index. Also writing to the TSP would be very useful in some scenarios, but it could also break boilers (or at least when people don't know what they are doing). Same goes for FHB id's btw. Why lookup all, you could only want to lookup the latest fault in the buffer.

Currently, I am using PIC firmware 5.1 on my production OTGW unit.

Look forward to your idea's what is going on,
Robert

[hvxl]

Your interpretation does not match with the way obtaining additional information is documented.

It is not possible to overrule everything, because the OTGW needs to provide the thermostat with the information it requested. The only feasible option is to replace a request the boiler doesn't support. But in your logs I find no messages from the thermostat that the boiler doesn't support. As a result the OTGW doesn't get a chance to send any alternative message.

To free up some slots for the OTGW to use, you can issue UI commands for some message IDs the boiler shouldn't need. For example 16 (Room setpoint) and 24 (Room temperature).

My original understanding of the TSPs was that these are reasonably static settings. So there should be no need to read them frequently or quickly. Adding the possibility to read or write a specific TSP would provide little benefit in my opinion, while requiring many resources, which are just not available in abundance.

[rvdbreemen]

Hi Schelte

Thank you for clearing that up. So you do need a free slot, and in my case I would need to clear out the existing AA with the UI command. So the PM command uses the slots that AA would use.

That helps a lot to understand this.

Actually it turns out that the parameters are not static. Of course it totally depends on the producer of the boiler. Remeha actually has sensor values as parameters.

Also the individual reading and writing could help the cv tuning community to actually just tune parameters when the boiler is known. Reading relevant parameters would be quickest, when you have a whole bunch of parameters to read. And you are really just interested in one or two.

[hvxl]

No, you don't need to clear out the existing AA messages. That's why it's called a priority message: It takes precedence over the AA messages. (Besides, clearing out AA messages would be done with the DA command, not the UI command.)

But your log showed no AA messages being sent at all. So you would need to use the UI command to sacrifice one or more of the messages your thermostat requests to get a slot for PM and AA messages.

[rvdbreemen]

Schelte

I misunderstood it indeed. So I tell the gateway to ignore a data-id with the UI command. So the AA or PM command get send. So now I figure out what I don’t want. And replace it.

Thanks again
Robert

[hvxl]

So now I figure out what I don’t want.

That's not the right question to ask. When you configure the room temperature or room setpoint as unknown IDs, the OTGW will still receive them from the thermostat. As a result, the data is available to you. It is just not passed on to the boiler. That should be fine, because a properly designed boiler has no use for this information.

However, I have heard rumors that some boilers look at this information anyway. If the room temperature is above the room setpoint, those boilers refuse to start heating, even if the thermostat sends a high control setpoint. This is bad behavior of the slave because the thermostat may have additional information that the slave is missing, like the fact that there is an upcoming schedule change. The thermostat may be trying to get the house up to temperature ahead of that time. A very common feature of clock thermostats. That will not work with these boilers (unless the thermostat sends the future setpoint instead of the current one). I don't know what such misbehaving boilers will do when they don't receive the room temperature and setpoint at all. After all, there is no requirement in the Opentherm specs for the thermostat to send them. But maybe boilers like these are the reason why some wireless thermostats send fake data.