Status feedback slower than in earlier versions?

[sven337]

I have not bisected this but, I seem to recall that when I sent CMD +ON to start the stove, I would get immediate status feedback over MQTT. This was with the firmware in a device you shipped me recently, which I upgraded to 2.1.1/3.0.0.

Now, it seems I have to wait for the next publishTick. Is this a known consequence of the refactoring?

I would very much appreciate to see the status reflected as soon as it changes, and I think it used to work like that. Thanks

[Domochip]

thanks for your feedback. It was a missing return in Palazzetti Lib (switchOff/On functions). I've implemented it and use it now in WPalaControl. The current repo version should solve the problem. I will release it shortly but feel free to compile and use it now if you need ;-)

[sven337]

Seems like it's stuck in a reboot loop with that version. I need to investigate.

janv. 02 10:16:52 controlepoele/connected 0
janv. 02 10:17:15 controlepoele/connected 1
janv. 02 10:17:40 controlepoele/connected 0
janv. 02 10:18:28 controlepoele/connected 0
janv. 02 10:19:16 controlepoele/connected 0
janv. 02 10:20:04 controlepoele/connected 0
janv. 02 10:20:25 controlepoele/connected 1
janv. 02 10:20:52 controlepoele/connected 0
janv. 02 10:21:46 controlepoele/connected 1
janv. 02 10:21:46 controlepoele/cmd (null)
janv. 02 10:22:10 controlepoele/connected 0
janv. 02 10:22:30 controlepoele/connected 1
janv. 02 10:22:58 controlepoele/connected 0
janv. 02 10:23:27 controlepoele/connected 1
janv. 02 10:23:27 controlepoele/cmd (null)
janv. 02 10:23:52 controlepoele/connected 0

Is there any way to flash over serial? It's probably the only way I can recover

[Domochip]

Arg, sorry. Yes, you can connect it using a micro-usb cable and flash it using VSCode/PlatformIO. I'll have a look shortly

[sven337]

Indeed, I just did so (esptool.py write_flash 0x0 /tmp/WirelessPalaControl.v2.1.1-3.0.0.bin), and it's back to normal. So it seems there's something wrong with your change, but it's not obvious to me what it could be.

By the way, I am new to platformio, but it seems that you could do the following for your spec file:

-   https://github.com/Domochip/Palazzetti.git@2.5.0
+   https://github.com/Domochip/Palazzetti.git#v2.5.0

This checks out the tag v2.5.0 and allows you to build older versions easily, whereas the syntax you used doesn't let me build older versions, complaining as follows:

PackageException: Package version 2.6.0+sha.2d1a10b doesn't satisfy requirements 2.5.0 based on PackageMetadata <type=library name=Palazzetti version=2.6.0+sha.2d1a10b spec={'owner': None, 'id': None, 'name': 'Palazzetti', 'requirements': '2.5.0', 'uri': 'git+https://github.com/Domochip/Palazzetti.git'}

[Domochip]

thanks, I just fixed it :-)

[Domochip]

I'm back regarding the Status feedback. I was able to compile and run it without any particular issue. Does libraries are up to date on your side? Which OS are you using? Anyway, the test is "failing" because Palazzetti lib is now going too fast :-D and returned STATUS is not the "final" one. I mean when I power ON the stove and temperature is bellow the threshold, it should end up to STATUS 9. But I'm receiving STATUS 3, which is a transient step to 9... I'll add a delay before reading of Status to return.

[sven337]

I am pretty sure that before v2.1.1/3.0.0 the status would update more or less right away. I would click "ON" in home assistant (which I've hooked up to send CMD+ON), and receive a MQTT status update to HEATUP = 9 within 1-2 seconds.

I build on Linux, libraries are up-to-date as far as I know (platformio handles that, right?).

My suggestion, don't add a delay, instead reset the next publishTick so it happens earlier?

[Domochip]

PlatformIO doesn't update libraries because I didn't specified version for ArduinoJson and PubSubClient. Another point to improve... (maybe also for ESP8266 Arduino version).

The delay will be applied only to CMD+ON/OFF commands. The whole publishTick is not required for powering on/off the stove. And anyway, lib Palazzetti is now so fast that I'm not sure this will solve the problem :-D I'm currently testing it.

[Domochip]

A delay of 500ms is working on my side, but I will do a test session to measure it more precisely. Then I'll be able to apply a "safety" margin

[Domochip]

OK, I did some tests yesterday on my stove.

Stove ON (send switchOff command):

• not heating nor fan : STATUS 9->0 took 89ms (3rd getStatus)
• no fire but FAN is cooling : STATUS 9->10 took 37ms (1st getStatus)
• heating : STATUS 6->10 took 63ms (2nd getStatus)

Sove OFF (send switchON command):

• SETP is 2°C under the T1 (no need to heat) : STATUS 0->3 took 37ms (1st getStatus) THEN 3->9 took 305ms (10th getStatus)
• SETP is above T1 (will heat) : STATUS 0->3 took 37ms AND after 1.2s STATUS is still equals to 3. Stove switch to 4 later after some check etc.

Conclusion :

• for switchOff, a delay of 200ms should be OK (max measured is 89ms)
• for switchOn, a delay of 500ms should be OK (max is 305ms) (regarding the case where the stove need to heat, a STATUS=3 will then be returned and is a correct return value)

[Domochip]

OK, the issue should be solved now using the latest release : https://github.com/Domochip/WirelessPalaControl/releases/tag/v2.1.2-3.0.2

Regarding compilation on your env : which distro do you use?

[sven337]

Thank you, I confirm your latest changes fix the problem I was reporting, I now get immediate status updates again.

I build on Archlinux, but I don't think that should cause any problem. In fact I've just produced my own build with your latest change and it works. I don't know what happened but let's ignore it.

Thank you again for your support. By the way, my stove is a Casatelli Carlo.