RAPI commands do not use the payload in MQTT

[AymanFadda]

In my application I want to keep the EVSE in sleep mode till I decide differently so I give the command $FS as a retained message so if the power is off then on or if the EVSE is restarted or if the MQTT is unreachable, one it's back online it receives the command and it turns back to sleep mode. If i want to remove the retained message (for different reasons) I send null payload to the same command but what happens is that the EVSE detects a command (even empty) that goes to the $FS command and it executes it and goes to sleep mode. I would suggest to consider for example a true value as a payload to execute the command.
Thank you

[jeremypoulter]

We are in the process of deprecating RAPI so probably not going to work on this, happy to accept a PR in the short term however, in the longer term we will be replicating the HTTP API over MQTT for cases that can not use the HTTP API directly. For this type of use case you should look at the /claims. The main problem is that this is not persistent, we could potentially look at adding this, but another option if you just want the EVSE to sleep by default could be to add a schedule that just puts the EVSE to sleep (disabled) this will be persistent across reboots, the /claims API can then be used to wake as needed.

[jeremypoulter]

MQTT control will be implemented by #358

[pdhoogh]

If people have applications using RAPI over MQTT and the support for this is stopped, you may need to notify users.

Otherwise this may also be helped by having the $xx command as the payload, rather than having single topics for each rapi command.

Any change to current supported functionality would require notification of users who are using the functionality as is right now. Such as myself.

[jeremypoulter]

It is in the docs, https://github.com/OpenEVSE/ESP32_WiFi_V4.x/blob/master/docs/rapi.md, ;-)

The theory is that if people are using RAPI then they probably are just using the OpenEVSE WiFi as a gateway and implementing similar 'smart' functionality to v4 in another system, they should be fine sticking with v3, we have that on a branch and happy to accept PRs to backport bug fixes if needed. But unfortunately to do what we wanted to do with the WiFi module we just can not support multiple entities controlling the OpenEVSE module, it would make it just too complicated, trying to guess why the state of the controller changed when we were not expecting it.

[pdhoogh]

Understood. Makes sense.

My inclination, as an industrial control specialist, is to always use "standard" or "available" functionality. In that sense, I will decommission any patch code provided the standard functions are adequate and working properly. I am currently using MQTT RAPI commands in a patch app only.

So if the next release does not need the patch, I will be very happy. In the hypothetical eventuality the upgrade does not fix the patched issue and the support for allowing the patch code to work is dropped, requiring a rework of the patch, I may be a bit less happy. And if that happens unexpectedly, I would be even less happy :-).

[jeremypoulter]

Fear not, we are not going to drop RAPI just yet, there are still a few key features that need implementing, #358, #225 (Despite the title will include limits in general being moved to the WiFi), #333 and probably a few others.