Rfid and timer #167
Rfid and timer #167
Conversation
Voltage is used by divert mode, as well as sent along to the OpenEVSE module for power calculations. Setting this to zero could result in a lot of issues. The divert code would see divide by zero happen, and the energy montoring code on the OpenEVSE module would result in the recorded energy usage being incorrect. While this shouldn't happen reguarly, I found myself in this situation by sending a null/zero-length message to the relevant topic that the ESP32 was listening on. Because there is no error checking in the float parsing code, a null value parsed to zero, which resulted in the voltage value being set to zero. An alternative here would be to reset the voltage to `DEFAULT_VOLTAGE` if a zero or invalid value was received. As written, this will simply do nothing and ignore the invalid/zero value.
A value between 60 and 300 volts, while being a generous range, should prevent issues where the value read from MQTT is read as a `0` or erroneously specified in millivolts.
Jeremypoulter/issue5
Voltage is used by divert mode, as well as sent along to the OpenEVSE module for power calculations. Setting this to zero could result in a lot of issues. The divert code would see divide by zero happen, and the energy montoring code on the OpenEVSE module would result in the recorded energy usage being incorrect. While this shouldn't happen reguarly, I found myself in this situation by sending a null/zero-length message to the relevant topic that the ESP32 was listening on. Because there is no error checking in the float parsing code, a null value parsed to zero, which resulted in the voltage value being set to zero. An alternative here would be to reset the voltage to `DEFAULT_VOLTAGE` if a zero or invalid value was received. As written, this will simply do nothing and ignore the invalid/zero value.
A value between 60 and 300 volts, while being a generous range, should prevent issues where the value read from MQTT is read as a `0` or erroneously specified in millivolts.
Presenting a tag will enter an authenticated state that can be cancelled by presenting the same tag again
|
We are currently developing this feature for firmware version 3.3.2 and applying the changes we make to this PR every once in a while. It is however very difficult to test the code and confirm that it is working for the reasons stated in #169. |
|
Thanks, really appreciate it, maybe we can get it merged in to the v3 branch as a first step, but may very well have to break comparability when merged to v4 |
|
May I ask what's the status of this? Would really appreciate this functionality, but it seems rather quiet around here. |
|
@TonD83 The focus of the development team has been on OCPP functionality. RFID development is basically complete, unfortunately it was done on older 3.x firmware, there is some work integrating it with the current 4.x code. We will likely get back to this soon. |
|
@Olverine v4 is getting more mature now, are you interested in continuing with this PR? |
|
@jeremypoulter I just spoke with @matth-x, he is going to work on this PR and integrate RFID with standalone functionality and OCPP. |
|
Superseded by #325 |
Merge Request for RFID into Master