Connection from ESP32 to the Alarm is slow and hangs very often

[qntris]

Hi @maragelis,

Thank you for the great work you are doing to make our SP systems smarter than they are. I've decided to make the move from ESP8266 to ESP32 on my SP5500 board.
This is the ESP-32 30PIN that I have bought (3 pieces) from aliexpress:

I have the below setup:

• erased the ESP32 and uploaded your code as it is, only changed the MQTT settings
• the wifi connection is great, ping to the devices is perfect
• the buck converter is passing 3.3v to the ESP32 board, as it should be
• the rx and tx pins from the alarm are connected to the TX2 and RX2 pins (respectively) of the ESP32 board

So far so good. However, I have the following issues:

• When I send a "stay" command for instance (with the proper payload), the Paradox board reacts (makes a sound) 3-4 seconds after that and starts arming_home. That is too big of a delay, compared to the ESP8266 board where each command is instantly sent to the alarm module. Why does it happen?
• I don't see "Pending" status (while the alarm is being armed) in HomeAssistant, compared to what I was seeing on the ESP8266. Is this expected?
• In about 20-30 minutes, the ESP32 device seems to hang (ping is still perfect) but it does not accept any commands, nor does it report zones movement. Is the ESP32 board model not a good one, if yes what is a recommended board model?

I have tried with each of the 3 pieces of ESP32s I have (to rule out faulty board)- the result is absolutely the same. My setup is quite simple I think and really have run out of options.

Let me know if you want some further details from me so that we can find the issue, or if you want to do a join debugging session - my email address is: ipuzunov at gmail dot com

Thank you in advance for your help and really hope that the ESP32 can prove to be the better option.

[maragelis]

@qntris thanks for your kind words, I have seen this as well with my esp32. I am suspecting the PubSubClient on the esp32, its not recovering the mqtt connection ofter a timeout. The thing is I do not have the time to debug this, my day job is too demanding.

[maragelis]

My hunch was correct so the pubsubclient is crashing together with the wifimanager, so I will upload a an update soon, like we say back to basics, I am running this on my installation and so far it looks stable.

[qntris]

@maragelis great news, and I am glad you managed to figure it out. I suppose that's the reason for the "hanging" part, but what's the culprit for the slow response when issuing commands - several seconds for arming_home is definitely not expected. As I said, the WiFi connection is good on my end, ping is perfect, MQTT broker is stable... Do you suspect that the pubsubclient was to blame for that slowness as well?

[Angel0ffDeath]

@maragelis @qntris It is always good idea to add autoreboot in case MQTT cannot relive the connection. I had such problems with ESP266 and ESP32....

I continue to use ESP8266 for my alarm but here are some tips:

`void handleMqttKeepAlive() {

if (!client.connected()) {

long now = millis();

if (now - lastReconnectAttempt > 5000) {

  lastReconnectAttempt = now;

  // Attempt to reconnect

  if (reconnect()) lastReconnectAttempt = 0;

}

if (millis() - lastConnected > reboot_timeout) ESP.reset();

} else {

// Client connected

lastConnected = millis();

client.loop();

}

}`

in reconnect before else delay(5000) add lastConnected=millis();
and somewhere in the beginning set reboot_timeout = 10 * 60 * 1000 (for instance)
This way if there is no connection more than 10 min ESP will self reboot.

Sorry the code is for ESP8266, but you should got the idea and can quickly adapt it for ESP32 :)
I put such code in all my devices and now I never have problems with disconnected devices and the need to reboot them manually.
Hope this will help to solve the issue....

And if you decide to use raspberry pi you can check this
https://pypi.org/project/paradox-alarm-interface/

@maragelis You can check it also - I extracted some useful conversions - now by me panel status instead of giving some not understandable numbers for DC voltage, battery voltage etc. gives readable voltage values... Also there is mistake in your logic for calculating PIN which you send to alarm (thats why you dont prefer zeroes in the PIN code), but I discovered that before seeing this soft. This is the correct way to calc the pin:

`

byte str2byte(String str) {
return strtoul(str.c_str(), nullptr, 16) & 0xFF;
}

byte ReplaceZeroes(byte c) {

byte t1 = c & 0x0F;

byte t2 = (c >> 4) & 0x0F;

if (t1 == 0) t1 = 0x0A;

if (t2 == 0) t2 = 0x0A;

return t2 * 16 + t1;

}

void PanelPassword() {

pass1 = ReplaceZeroes(str2byte(String(PIN).substring(0, 2)));

pass2 = ReplaceZeroes(str2byte(String(PIN).substring(2, 4)));

}`

Btw, the above soft works with EVO also - I see a lot of requests here for EVO (and in the old 8266 thread) - so someone can directly use it or extract the protocol....