Unable to send SetPoint temperature and undefined stove status

[TruantRiccardo]

if I try to send the request for a Temperature Setpoint, the stove will answer saying that the setpoint is 0. (read from the bottom up)

If I ask what the temperature setpoint is, the response is in fact zero.

I have even tried sending via MQTT every 15 minutes the room temperature. I don't know if it matters.

Another thing that I notice is that the stove status goes to an undefined condition periodically when the stove is on.

Here you can see the history, maybe it's the "modulation" status. If so, maybe the messages are a little different from model to model?

[DuchkPy]

Hello @TruantRiccardo

Looking at your StoveStatus reply, I can see different values that I have already seen. It's possible I haven't seen all cases. On your reply,

• the stove status is 13, and I have only seen up to 11. So this one need to be investigated.
• the alarm state is 10, and I have only seen up to 8. So this one need to be investigated.

For SetpointTemp, I can see that the command send have a value of 15, but the stove reply he received an order of 0... (see message n°13 and 14).

Looking at that, I start to think that all stove haven't the same hexa frame for the same order... Which (to be honest) looks stupid, because the remote need to understand what is the stove plug to it. Having the same frame ease the development by doing it only once...

[TruantRiccardo]

Hi @DuchkPy

For StoveStatus I can confirm that the stove status 0x13 is H2O modulation, while the alarm status 0x10 I believe is a kind of "in operation". Using debug messages I found new status codes up to 0x1a. I will send a new commit with the new codes shortly.

Regarding SetpointTemp, I too find it very strange that they change the messages. One thing that got me thinking is that the stove accepts the exact frame and responds with the expected frame (except those 8 bits). If I want to use different messages for different stoves, it would be silly to use the same frame for different actions for different stoves. At least the stoves would have to respond with a different frame.... I don't know if I explained myself. What I was thinking is that the message is correct but there is some "protection" or some setting in the remote control that does not allow me to read/write that register.

I was thinking of borrowing an oscilloscope from my workplace so that I can read the commands. So probably i will update you soon.

For the moment I am using a workaround to control the setpoint temperature, maybe it may be useful to others: -TheSetPointTemperature of the stove, since I cannot set it from the serial, is the last one I set from the remote control [e.g. 20°C]. The same goes for the H2O setpoint [e.g. 70°C] although it does not matter for this workaround. -I can send the room temperature via serial and the stove uses this temperature as a reference for its setpoint. -From Home Assistant, I create an Input_Number entity where I enter my setpoint.

• From HA, I create a new sensor entity that takes the temperature from a real-time temperature sensor and corrects it by adding/subtracting the difference between the desired setpoint [e.g. 22°C] and the last remote control setpoint [e.g. 20°C].

[DuchkPy]

I don't know if I explained myself

You explained it correctly, and I have the same point of view. My dealer told me there is only 1 reference of remote control. So from my point of view the remote control have only 1 software whatever the stove model.

I was thinking of borrowing an oscilloscope from my workplace so that I can read the commands.

This is exactly how I did. It could be interesting if you are able to do it. We could understand a bit better / faster what are the difference. And confirm the 0x13 you saw. I could have miss it, like some others.

But, if you do it, be aware that the remote control is spamming the stove. It's almost a constant discussion between both (all discussions are initiated by the remote control, sending a request or a status and waiting for the answer from the stove). As you look more familiar with electronic that I am, maybe you will be able to build a proto board that can read the message to record them on a computer. Could be more confortable than on an oscilloscope. I tried, but when I plugged my electronic in parallel the remote control put it itself as unconnected. Like the remote detected the parallel electronic and stopped interacting with the stove (without damaging it at all, just need to unplug the electronic and the remote act again normally).

[TruantRiccardo]

Yes, I am more comfortable with electronics while, as you have seen, my software skills do not shine as much :) Hmm... Yes, with an oscilloscope it would be long to detect all the messages I am looking for if the remote is spamming frame as you say.... Maybe it is more useful if I get the picoscope. That way I can connect it to my PC to see the graph. Thanks for the tip, I will update you as soon as I get news.

I tried, but when I plugged my electronic in parallel the remote control put it itself as unconnected. Like the remote detected the parallel electronic and stopped interacting with the stove (without damaging it at all, just need to unplug the electronic and the remote act again normally).

Perhaps your circuit placed a low impedance between the signal and ground. I haven't tried, but by keeping ESP_OUT low, the circuit we are using to talk to the stove can also be used to "sniff" the communication between the remote and the stove, without having to modify the circuit. Instead, the software will have to continuously sniff the serial communication and then send it via MQTT. I know that the ESP8266 can handle WebSerial, but I do not know if it is possible to configure WebSerial and wired serial at the same time. This could be an alternative to MQTT, if possible.

Do you think it is a feasible thing?

[DuchkPy]

From the first example I found here : https://randomnerdtutorials.com/esp8266-nodemcu-webserial-library/ They are using WebSerial.println() and Serial.println() so seems possible to do both at the same time yes.

So something very simple like this should work:

void loop() {
  if (Serial.available()>0) {
    WebSerial.println(String(Serial.read(), HEX));
  }
}

[TruantRiccardo]

Yes, that's what I was thinking about. Tomorrow or this weekend I will make the harness for testing.