ihormelnyk / opentherm_library

Arduino/ESP8266/ESP32 OpenTherm Library for HVAC system control communication
MIT License
210 stars 94 forks source link

Room thermostat values not available #37

Open CurlyMoo opened 2 years ago

CurlyMoo commented 2 years ago

I received the slave shield today, but i noticed the API doesn't support retrieving the following values from my thermostat:

I would like to use my thermostat as a simple temperature GUI to control my domotica.

Additionally, does OpenTherm implement a signal that tells me to start heating or start cooling? I also can find the implementation for that.

ihormelnyk commented 2 years ago

Hi @CurlyMoo , You can send any OT command, like described here (advanced requests) http://ihormelnyk.com/opentherm_library Also there is a link to OT protocol documentation, you should use status command to enable heating or cooling

CurlyMoo commented 2 years ago

This is what i've tried, but the only response i get is:

30000
/*
OpenTherm Slave Example
By: Ihor Melnyk
Date: May 1st, 2019
http://ihormelnyk.com
*/

#include <Arduino.h>
#include <OpenTherm.h>

const int inPin = 12;  //for Arduino, 12 for ESP8266 (D6), 19 for ESP32
const int outPin = 13; //for Arduino, 13 for ESP8266 (D7), 23 for ESP32
OpenTherm ot(inPin, outPin, true);

void ICACHE_RAM_ATTR handleInterrupt() {
    ot.handleInterrupt();
}

void processResponse(unsigned long response, OpenThermResponseStatus status) {
    if (status == OpenThermResponseStatus::SUCCESS) {
        Serial.println(String(response, HEX));
    }
}

void setup()
{
    Serial.begin(9600);
    Serial.println("Start");

    ot.begin(handleInterrupt, processResponse);
}

void loop()
{
    bool isReady = ot.isReady();
    if(isReady) {
      unsigned int data = 0xFFFF;
      unsigned long request = ot.buildRequest(OpenThermRequestType::READ, OpenThermMessageID::Tr, data);
      unsigned long response = ot.sendRequestAync(request);
    }

    ot.process();
}
ihormelnyk commented 2 years ago

Hi @CurlyMoo, If you have SLAVE shield you can't send requests, master device is responsible for sending requests. So if you have thermostat you can listen to requests from thermostat and send responses using slave shield. Try sample sketch https://github.com/ihormelnyk/opentherm_library/blob/master/examples/OpenThermSlave_Demo/OpenThermSlave_Demo.ino

If you are using master shiled probably you have had DATA-INVALID response

Slave-to-Master Messages 100 READ-ACK 101 WRITE-ACK 110 DATA-INVALID 111 UNKNOWN-DATAID

try to send a valid float temperature Also you can't send only one command in a loop, you should send different commands sequentially. Commands support depends on your device implementation (thermostat, boiler)

CurlyMoo commented 2 years ago

If you have SLAVE shield you can't send requests, master device is responsible for sending requests.

I'm using the slave shield trying to listen to the thermostat values, however, not much showing up using the sample sketch.

ihormelnyk commented 2 years ago

recheck headers soldering, connections, slave cketch pins configuration, voltage levels on OT wires

CurlyMoo commented 2 years ago

The thermostat boots fine so powering should not be the issue and i believe that with bad soldering there wouldn't be any response at all. The response i do get is just an endless stream of:

T30000
Bf0030000
T30000
Bf0030000
T30000
Bf0030000
T30000
Bf0030000
T30000
Bf0030000
T30000
Bf0030000
ihormelnyk commented 2 years ago

So thermostat sends status command with CH and DHW flags enabled and sample sketch just respond with UNKNOWN-DATAID. That is why thermostat just repeats the same command. You should build a valid response for commands you want to support. Respond with READ-ACK or WRITE-ACK and valid data bytes for concrete command.

CurlyMoo commented 2 years ago

Respond with READ-ACK or WRITE-ACK and valid data bytes for concrete command.

And where in the documentation of the library can i get a clue how that works?

ihormelnyk commented 2 years ago

Check my first response

CurlyMoo commented 2 years ago

I did, but the example doesn't fully work due to the absence of functions like the: isCentralHeatingEnabled.

I changed the code to:

void processRequest(unsigned long request, OpenThermResponseStatus status) {
    Serial.print(ot.getDataID(request));
    Serial.print(" ");
    Serial.println("T" + String(request, HEX)); //master/thermostat request

    unsigned long response = ot.setBoilerStatus(true, false, true);

    Serial.println("B" + String(response, HEX)); //slave/boiler response
}

Which results in:

3 T30000
B0
3 T30000
B0

If i do this:

void processRequest(unsigned long request, OpenThermResponseStatus status) {
    Serial.print(ot.getDataID(request));
    Serial.print(" ");
    Serial.println("T" + String(request, HEX)); //master/thermostat request

    unsigned long response = ot.buildResponse(OpenThermMessageType::READ_ACK, ot.getDataID(request), 0);

    //send response
    ot.sendResponse(response);
    Serial.println("B" + String(response, HEX)); //slave/boiler response
}

I get this:

Bc0030000
3 T30000
Bc0030000

The f changed to c as the initial byte.

CurlyMoo commented 2 years ago

Looking at the Tasmota implementation i seem to understand that the library expects me to implement a full handshake and communication strategie. Maybe i was too naive, but i expected it to do that for me...

IgorYbema commented 2 years ago

Let me step in. Trying to understand also while learning.

The thermostat requests MsgID3, that is 'slave, give me your config'. So you need to respond with a write_ack (see specifications) and set the bits in the answer for which functions your slave supports.

And yes, the library is only support the basic communications as it seems.

CurlyMoo commented 2 years ago

The thermostat requests MsgID3, that is 'slave, give me your config'

Which should be the command:

unsigned long response = ot.setBoilerStatus(enableCentralHeating, enableHotWater, enableCooling);
IgorYbema commented 2 years ago

So if you change your last config in: unsigned long response = ot.buildResponse(OpenThermMessageType::WRITE_ACK, ot.getDataID(request), 0); You probably will see another request.

CurlyMoo commented 2 years ago

unsigned long response = ot.buildResponse(OpenThermMessageType::WRITE_ACK, ot.getDataID(request), 0);

That gives me: 49 T80310000

ihormelnyk commented 2 years ago

. You just need to send

Looking at the Tasmota implementation i seem to understand that the library expects me to implement a full handshake and communication strategie. Maybe i was too naive, but i expected it to do that for me...

Library allows you to send any OT command, you just need to build response with type, id and data for concrete command. Please read OT protocol documentation, there is link in the mentioned article.

CurlyMoo commented 2 years ago

Library allows you to send any OT command, you just need to build response with type, id and data for concrete command.

That's the issue. For what is simple for you, isn't for developers unknown to OpenTherm. So a basic guideline in the documentation on how a basic handshake + request works (in both slave and master mode) would be much better. The example you're referring to is sadly broken.

As in, just a small heads-up instead of directly referring to the protocol description itself...

IgorYbema commented 2 years ago

unsigned long response = ot.buildResponse(OpenThermMessageType::WRITE_ACK, ot.getDataID(request), 0);

That gives me: 49 T80310000

So you now receive a new READ for msgid 49 I believe. And that should be a request for the boiler/slave to responds the upper and lower bounds for the CHsetpoint. Again, you need to respond with write_ack on this msgid and the proper upper and lower bounds. Yes, this takes a while :)

CurlyMoo commented 2 years ago

So you now receive a new READ for msgid 49 I believe.

As described in chapter 5.2, i would have expected some more handshake items, but nope.

ihormelnyk commented 2 years ago

Library allows you to send any OT command, you just need to build response with type, id and data for concrete command.

That's the issue. For what is simple for you, isn't for developers unknown to OpenTherm. So a basic guideline in the documentation on how a basic handshake + request works (in both slave and master mode) would be much better. The example you're referring to is sadly broken.

As in, just a small heads-up instead of directly referring to the protocol description itself...

There is no handshake, just request - response for the concrete command. The sample sketch is not broken, it is just very basic. And library has only basic commands which alow you to work with OT protocol. Unfortunatelly, I do not have time to add user friendly wrappers for all the OT commands.

CurlyMoo commented 2 years ago

The sample sketch is not broken, it is just very basic.

It is, because the function isCentralHeatingEnabled doesn't exist.

ihormelnyk commented 2 years ago

Sample sketches in the library are valid, the article need to be updated in order to be compatible with latest version of OT library. Mentioned function can be used for slave response only.

ihormelnyk commented 2 years ago

In general, you can use any OT library you find or you are always welcome to join the contributors of this library and improve it.

IgorYbema commented 2 years ago

So after discussing this offline with @CurlyMoo I believe I know what is going wrong. When changing the buildResponse and sendResponse to buildRequest and sendRequest in previous example (https://github.com/ihormelnyk/opentherm_library/issues/37#issuecomment-937096542) it works. However it is a response so the response functions should be used. This is caused probably because sendResponse is not using the isReady flag so the response can be send while master is active on the line, which is wrong. Also another weird thing is that buildRequest is not using the message type (unless it is write-data). As read-data is 000 that is not a problem but invalid-data type will never be used, why is this? Why even use two different routines for buildRequest/sendRequest and buildResponse/sendResponse? They work the same (if these two bugs are removed), except for the reponsetimestamp and openthermstatus set at the end.