search

steve-community / steve-plugsurfing

SteVe with PlugSurfing (https://www.plugsurfing.com) integration using their interface OIOI (http://docs.plugsurfing.com/)
GNU General Public License v3.0
8 stars 6 forks source link

PS Tag stay blocked #4

Closed goRaspy closed 8 years ago

goRaspy commented 8 years ago

When an PlugSurfing Tag is retun once at BLOCKED by plugsurfing verify method it stay locked even if the verify result change and become verified as TRUE.

goekay commented 8 years ago

cannot test it now, but looking at the code, i can acknowledge the problem. however, with one difference: because of the bug, in this case, steve should not make any verifyRfid calls to ps. what you are saying is the call is being made, but the database is not updated.

the code block in https://github.com/RWTH-i5-IDSG/steve-plugsurfing/blob/61dd0b2e3e1f88fb3d7c0d66020e104ba56a6378/src/main/java/de/rwth/idsg/steve/extensions/plugsurfing/service/PlugSurfingService.java#L96-L100 makes the changes in both cases. so this should not be the outcome.

i think the problem lies in https://github.com/RWTH-i5-IDSG/steve-plugsurfing/blob/61dd0b2e3e1f88fb3d7c0d66020e104ba56a6378/src/main/java/de/rwth/idsg/steve/extensions/plugsurfing/service/PlugSurfingService.java#L92 and we falsely decide not to ask ps.

are you sure that the verify call is being made when tag was blocked?

goRaspy commented 8 years ago

Hi, you are right. I checked again logs. When the tags was previously locked, this no call to Plugsurfing. So it will be never be able again.

Sent from my mobile device, please excuse the brevity

Le 3 août 2016 5:32 PM, "Sevket Gökay" notifications@github.com a écrit :

cannot test it now, but looking at the code, i can acknowledge the problem. however, with one difference: because of the bug, in this case, steve should not make any verifyRfid calls to ps. what you are saying is the call is being made, but the database is not updated.

the code block in https://github.com/RWTH-i5-IDSG/steve-plugsurfing/blob/61dd0b2e3e1f88fb3d7c0d66020e104ba56a6378/src/main/java/de/rwth/idsg/steve/extensions/plugsurfing/service/PlugSurfingService.java#L96-L100 makes the changes in both cases. so this should not be the outcome.

i think the problem lies in https://github.com/RWTH-i5-IDSG/steve-plugsurfing/blob/61dd0b2e3e1f88fb3d7c0d66020e104ba56a6378/src/main/java/de/rwth/idsg/steve/extensions/plugsurfing/service/PlugSurfingService.java#L92 and we falsely decide not to ask ps.

are you sure that the verify call is being made when tag was blocked?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/RWTH-i5-IDSG/steve-plugsurfing/issues/4#issuecomment-237251517, or mute the thread https://github.com/notifications/unsubscribe-auth/AJnQzBDdNbPqGeUXBl4nUwYSBNoDnNQMks5qcK5PgaJpZM4JbglW .

goekay commented 8 years ago

fixed by commit 42c8370

correction: the referenced issue was a typo. it should have been #4

goRaspy commented 8 years ago

Hi, since this fix. We lost the information about plugsurfing check in the "additional note" field of the OCPP tag for remote start (works fine for plugsurfing RFID tag).

goekay commented 8 years ago

can you elaborate on this please?

goRaspy commented 8 years ago

Hi,

Image are often better than words ^^

Plugsurfing tags : (everything ok) image

Plugsurfing remote start tag : (no additional comments since commit 42c8370)

image

goekay commented 8 years ago

what's the difference between "Plugsurfing tag" and "Plugsurfing remote start tag"? what do you mean?

goRaspy commented 8 years ago

You right it is not clear !

Plugsurfing tag : RFID tag from Plugsurfing

Plugsurfing remote start tag : Start launched from smartphone app (the tag is hashed and generated by Steve)

goekay commented 8 years ago

oh ok. if you think about it, it's not really a bug, actually. this "verified by ..." note is only intended for the use case when the user goes to a charging station with an rfid card and wants to charge a vehicle. she can be a ps user (according to our database) but this information might be old. so just to be sure, we verify it by ps. keep in mind, the interaction starts with the user doing something without the knowledge of ps.

in case of remote start sent by the mobile app, we assume that ps backend already checks and verifies the user, because the communication chain should be: mobile app -> ps backend -> steve. so the request should not even arrive at steve if the user is blocked/deleted/whatever. and therefore, such a check is not necessary. on the other hand, it is not even an rfid which is sent to us, but an evco-id (which is just an id for the user). we map the evco-id to rfid just for our internal logic. no one else uses this rfid. the world does not know about this rfid. and therefore there is also not the danger of some user going to a charging station try to start charging with this rfid.