Do not store duplicate charging sessions and connector status

[goRaspy]

In certains circonstances, charging station will send OCPP message twice.

For example, with a GPRS data connection, we can have a best connectivity for Cell to chargepoint way and a less good connectivity for the chargepoint to cell canal.

So in this case, it may happen that the chargepoint will send ( for exemple ) :
CP -> STEVE ( good connectivity ) : Start transaction
Steve-> CP ( bad connectivity ) : accepted

But the CP never received the acknowledge by Steve and try to send it again ( sometimes many times ).

It should be useful to not store "duplicate" transactions in database. It is the same for connector status.

[goekay]

thanks for the report. let's address the connector status issue first. what's the problem with it? the database table is constructed in a way that duplicate status values should not be a problem. do you see multiple identical entries on the web ui for one connector?

[goRaspy]

Hi Goekay, many thanks for your (very) fast answer.
Unfortunately I do not speak about GUI ( but you are right sometimes we can see double connectors status.

But my problem is about SQL database "pollution" especially for duplicates transactions whose need to be "cleaned" before used for statistic purpose.

Cheers

[goekay]

the GUI problem should be fixed with my referenced commit.

actually, the connector_status table by design is to be polluted. we treat it as an "append-only" data structure without any constraints or checks. therefore, every status message is just inserted into the table. but you are right, this simple "write approach" causes a more complicated and delicate "read approach", as can be seen here. i will look into this to improve this situation.

[goRaspy]

THanks you for working on connector status.
Concerning transactions, there any possibilities to "do not write" in database "clones" (same data, different transaction PK) ?

My need is to have a reliable view of chargepoint statistics without post treatment of data

[goekay]

my referenced commit 9e836fc does exactly that. it looks at the database for a transaction with identical information as in the message (chargebox, connector, idtag, timestamp, start value) and writes into database only if it is a new one. otherwise it returns the transaction pk of the existing database row.

[goRaspy]

My Bad :( I did not understood that. I'll try your commit. Many thanks Le dim. 22 juil. 2018 à 23:39, Sevket Gökay <notifications@github.com> a écrit :

…

my referenced commit 9e836fc <9e836fc> does exactly that. it looks at the database for a transaction with identical information as in the message (chargebox, connector, idtag, timestamp, start value) and writes into database only if it is a new one. otherwise it returns the transaction pk of the existing database row. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#81 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJnQzCdpB15BAD_Z_AZQIooHhM1N6ZeSks5uJPEcgaJpZM4VV_2c> .

[goekay]

hey @goRaspy, did you test my commits? do they solve your problem? if the answer is yes, i want to close this issue.

[goRaspy]

Hi, yes it works with Steve 1.6. But we are also triing to merge it on steve-plugsurfing. I think you can close the issue. I'll keep you in touch. Le mer. 25 juil. 2018 à 14:21, Sevket Gökay <notifications@github.com> a écrit :

…

hey @goRaspy <https://github.com/goRaspy>, did you test my commits? does it solve your problem? if the answer is yes, i want to close this issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#81 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJnQzBMd3o2cWukri0qR15o7IleiCnHuks5uKGKqgaJpZM4VV_2c> .