Changing temperature not working reliably and may affect other settings

[Profil404]

Hi,

All work except this: when I change the temperature, immediately after that the change take effect, the bubbles turn on. What I have to do to disable this comportement ?

Thank

[jnsbyr]

The ESP application works more or less like web screen scraper - it interprets the output and presses buttons for you. So especially changing the temperature is quite a bit more difficult than turning bubbles on/off because reading and writing must be combined in a certain manner.

The ESP CPU by itself could do this easily but the ESP firmware regularly stops the application to service the WiFi client, otherwise the WiFi connection to the AP would be lost. This makes keeping the required microseconds timing for the pulses very difficult and takes the ESP to its upper limits. If the pulse timing is wrong something unintended can be affected.

Please check if you have build the project with the required CPU settings of 160 MHz. It this is already the case please report if it makes a difference if you change the temperature by only 1 degree.

[Profil404]

C'est bien configuré à 160 MHz.

J'ai remarqué que ça arrive à chaque changement de température (même d'un seul degrés) mais également lorsque je met sous tension le module et le spa (par exemple après un reset électrique).

Via le moniteur série, à chaque fois que ça arrive je vois (de mémoire):

Dans bubbleOn Testtest (plusieurs fois) Fini

[RealByron]

You should undefined Serial_debug. It can't be usable with blocking serial debug in interrupts. I'm investigating to robustify this interrupt. With my sb h20, this is the temperature setpoint that can't be send on mqtt. I think that it we will nicer to deal with frame with spi interrupt and press button timers.

Le ven. 17 juin 2022 à 08:34, Profil404 @.***> a écrit :

C'est bien configuré à 160 MHz.

J'ai remarqué que ça arrive à chaque changement de température (même d'un seul degrés) mais également lorsque je met sous tension le module et le spa (par exemple après un reset électrique).

Via le moniteur série, à chaque fois que ça arrive je vois (de mémoire):

Dans bubbleOn Testtest (plusieurs fois) Fini

— Reply to this email directly, view it on GitHub https://github.com/jnsbyr/esp8266-intexsbh20/issues/15#issuecomment-1158541282, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANLBSDPMWPYR4V4ZFA6KYDVPQL5VANCNFSM5Y7LYNHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[jnsbyr]

@RealByron

Undefining Serial_debug can help, especially if you commented in the additional debug outputs in the source that log the received frames.

As I mentioned above, the temperature setpoint is the only critical/problematic thing I know of. If you plan to optimize you could start with SBH20IO::setDesiredWaterTempCelsius() and SBH20IO::changeWaterTemp. E.g. there are several hardcoded parameters that affect the timing. Also take into consideration that the ISR and effectively SBH20IO::decodeButton closes the control loop for changing the temperature setpoint and that the user request methods and the ISR influence each other and may run at the same time.

[jybi89]

i have a same problem :'( Publish to topic pool/command/water/tempSet with mqtt explorer, so all functions start (bubble, on, off ect...)

[jnsbyr]

@jybi89 Sorry to hear, but I see no way to "just" fix this problem, because there are too many variables. I optimized the original solution for my own SB-H20 and ESP8266. It does not work perfectly, but good enough for me, and it does not activate other functions. A small difference in you own ESP8266 hardware or in the pool firmware from Intex might be the cause, as not all users of this project seem to have this problem. There is also the possibility that the problem might be caused by the type or configuration of the MQTT server.

Only solution I see is that one of you with this problem tries to make changes to the ESP8266 firmware and see what happens. You can start with my hints to @RealByron above and I am willing to assist if there are questions.

I also suggest that before you change anything you should check what the MQTT server really sends to the ESP8266 when the MQTT server reconnects. You can use serial debugging for this on the ESP8266. As described in the Readme, the MQTT TCP connection gets interrupted when the water temperature is changed because the WiFi modem is put to sleep. Might be that your MQTT server sends the last set commands again.

[piitaya]

Hi 🙂

The problem about the bubble is due to the retain: true flag you probably set to the command. You need to remove them and delete all the command topics using mqtt explorer or another tool.

When you set the temperature, the connection with mqtt server is lost because the wifi is off when setDesiredWaterTempCelsius is called. When the mqtt server is reconnected, and the command are executed again because of the retain: true flag in your mqtt configuration. retain: true flag should only be used for state topics, not command topics.

The issue is not a firmware issue but a configuration issue in your mqtt consumer (HA, openhab, jeedom).

[Profil404]

Hi 🙂

The problem about the bubble is due to the retain: true flag you probably set to the command. You need to remove them and delete all the command topics using mqtt explorer or another tool.

When you set the temperature, the connection with mqtt server is lost because the wifi is off when setDesiredWaterTempCelsius is called. When the mqtt server is reconnected, and the command are executed again because of the retain: true flag in your mqtt configuration. retain: true flag should only be used for state topics, not command topics.

The issue is not a firmware issue but a configuration issue in your mqtt consumer (HA, openhab, jeedom).

Hi,

I don't have any retain: true when I send a command. And according to the HA documentation, by default retain is set to false. So yes, it's seem a firmware issue.

[piitaya]

Or a wiring issue. I use it with HA for one month et zero issue on my side.

[jnsbyr]

@Profil404 To make some headway, please try serial debugging:

• comment in "#define SERIAL_DEBUG" in common.h:33 and rebuild your firmware
• after firmware upload, start a terminal application (e.g. PuTTY) at 74880 baud
• look for output starting with "set ..." when sending a MQTT command (see MQTTClient.cpp:35ff)

[RealByron]

I finally get all of this working. I will publish that on my fork project

Le mar. 21 juin 2022 à 22:46, Jens B. @.***> a écrit :

@Profil404 https://github.com/Profil404 To make some headway, please try serial debugging:

• comment in "#define SERIAL_DEBUG" in common.h:33 and rebuild your firmware
• after firmware upload, start a terminal application (e.g. PuTTY) at 74880 baud
• look for output starting with "set ..." when sending a MQTT command (see MQTTClient.cpp:35ff)

— Reply to this email directly, view it on GitHub https://github.com/jnsbyr/esp8266-intexsbh20/issues/15#issuecomment-1162334942, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANLBSCZIYWAC6XR5KCMMWDVQIS25ANCNFSM5Y7LYNHA . You are receiving this because you were mentioned.Message ID: @.***>

[RealByron]

Feel free to test my current investigation. test branch

Press button more robust Temperature setpoint read fixed publication on temps changes

[jybi89]

Hi 🙂 The problem about the bubble is due to the retain: true flag you probably set to the command. You need to remove them and delete all the command topics using mqtt explorer or another tool. When you set the temperature, the connection with mqtt server is lost because the wifi is off when setDesiredWaterTempCelsius is called. When the mqtt server is reconnected, and the command are executed again because of the retain: true flag in your mqtt configuration. retain: true flag should only be used for state topics, not command topics. The issue is not a firmware issue but a configuration issue in your mqtt consumer (HA, openhab, jeedom).

Hi,

I don't have any retain: true when I send a command. And according to the HA documentation, by default retain is set to false. So yes, it's seem a firmware issue.

use mqtt explorer, may be a retain is here, delete the retain in mqtt explorer and test. I have solved my problem.

[Profil404]

Hi 🙂 The problem about the bubble is due to the retain: true flag you probably set to the command. You need to remove them and delete all the command topics using mqtt explorer or another tool. When you set the temperature, the connection with mqtt server is lost because the wifi is off when setDesiredWaterTempCelsius is called. When the mqtt server is reconnected, and the command are executed again because of the retain: true flag in your mqtt configuration. retain: true flag should only be used for state topics, not command topics. The issue is not a firmware issue but a configuration issue in your mqtt consumer (HA, openhab, jeedom).

Hi, I don't have any retain: true when I send a command. And according to the HA documentation, by default retain is set to false. So yes, it's seem a firmware issue.

use mqtt explorer, may be a retain is here, delete the retain in mqtt explorer and test. I have solved my problem.

Already done, but I don't find any retain...

[Profil404]

Feel free to test my current investigation. test branch

Press button more robust Temperature setpoint read fixed publication on temps changes

Thank, I will try that tomorow

[Profil404]

@Profil404 To make some headway, please try serial debugging:

• comment in "#define SERIAL_DEBUG" in common.h:33 and rebuild your firmware
• after firmware upload, start a terminal application (e.g. PuTTY) at 74880 baud
• look for output starting with "set ..." when sending a MQTT command (see MQTTClient.cpp:35ff)

Also try this tomorow, thank for your help

[Profil404]

@RealByron Don't work with your fork, do the same.

@jnsbyr With PuTTY, when I change the temperature, I see:

Dans la boucle pressButton Attend buzzer off Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Fini trying to connect to MQTT server ... success Dans la boucle BubbleBubble a bien été activé à ONDans la boucle pressButton Attend buzzer off Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Testtest Fini

[RealByron]

@Profil404 Did you checkout the "optimizing" branch ?

[jnsbyr]

@Profil404 The output you posted looks quite unexpected. The "trying to connect to MQTT server ..." is from the default firmware but the rest must be from your own code because the firmware does output anything in French. It seems to me you did not activate the serial debugging successfully because the "set ..." output is missing that will be shown whenever a MQTT command is received. So please check line 33 in common.h again: it must start directly with "#define", not with "//#define". It the line looks good, the flashing probably did not work. Change the version in line 38 of common.h to another value and check via MQTT to be sure.