Raspberry pi en rfid

En toch is het een "schaalbare" oplossing. Mocht de boel groter worden, dan schaalt het gewoon zonder problemen en zonder veranderingen in de code.

Zoals ook in een ander topic wordt gezegd is het verstandig om problemen bij de bron aan te pakken. De vraag is dus: waarom gaat de verbinding naar de database kapot?

Ik denk dat in deze applicatie het misschien zo is dat je bij het opstarten een verbinding met de database maakt en dat die na zoveel tijd geen queries denkt: Die is in slaap gevallen die knikkeren we er uit.

Dus haal de "maak verbinding met de database" naar de plek waar nu die "1a" staat, en sluit de database na de query weer af. Hopelijk lost dat het probleem op.

Nu we een vermoeden hebben waar het probleem zit: Volgens mij kan mysql behoorlijk verbose loggen (vroeger stond dat standaard aan). Dus dan zie je wat er voor queries gedaan worden en in dit geval dan waarschijnljk ook iets van "no acitivity for 3600 seconds, closing connection". Ik denk dat je dit soort logging tegenwoordig expliciet aan zal moeten zetten.

https://stackoverflow.com/questions/6479107/how-to-enable-mysql-query-…

Ik google even snel naar het sql probleem en vindt dan dit:
https://stackoverflow.com/questions/6516943/lost-connection-to-mysql-s…
Daar wordt ook over een timeout gesproken, en ook over een max_allowed_packet variabele. Dus, even gericht zoeken helpt wel.

Op 27 mei 2019 18:03:26 schreef bordje:
mysql.connector.errors.InterfaceError: 2013: Lost connection to MySQL server during query

Laatste zin is dus belangrijk.
Hoe los ik dit nu op?

Ik denk dat die lost connection geen oorzaak, maar een gevolg is. Bij dit soort dingen die pas na tig keer optreden denk ik eigenlijk altijd aan een memory leak, call overflow of stack overflow.
Je zou eens kunnen beginnen met te kijken of je wel elke keer al je geheugen terugkrijgt. c.q. start gewoon een 'top' en zie wat er gebeurt. Op een Pi kun je, binnen top dus, M drukken om te sorteren op memory usage, anders gebruik je 'top -omem'.

Op 27 mei 2019 23:12:00 schreef Hensz:
Bij dit soort dingen die pas na tig keer optreden denk ik eigenlijk altijd aan een memory leak, call overflow of stack overflow.

Ik denk het niet. Dit programma loopt niet duizenden keren door z'n loop: Als er na 4 uur testen 5 mensen hebben geprobeerd binnen te komen, waarvan er drie toegelaten zijn, dan is de while lus dus 5x uitgevoerd. Tja, in de MFRC library zit wel een loop om het chipje steeds uit te lezen. Als het daarin zit is het waarschijnlijk niet makkelijk op te lossen door jou.

Maar goed. Ondanks dat ik denk dat dit het niet is, is het natuurlijk een hypothese die we kunnen testen en evt. verwerpen of bevestigen.

Op 28 mei 2019 07:57:09 schreef rew:
[...]Ik denk het niet. Dit programma loopt niet duizenden keren door z'n loop:

Volgens mij is reader een instance van class MFRC522 en wordt binnen de loop elke keer weer de functie read() van die class aangeroepen om te kijken of er een badge gepresenteerd is.

Ik weet niet wat de reader aan data ophoest op het moment dat er niets is aangeboden. Het lijkt me beter daarop te testen en pas bij valide data in de database te gaan zoeken en dus niet met potentieel rare data. Nu zit je ook 43000 keer per dag in de database te zoeken terwijl er mss maar 100 badges/dag worden aangeboden.

Zo lees ik de code niet: ik zie de hoofdlus wachten tot er vanuit de lezer een code wordt aangeboden. Precies zoals ook @rew het al aangaf.

[Bericht gewijzigd door big_fat_mama op dinsdag 28 mei 2019 15:19:50 (16%)

Dan moet de beschrijving van MFRC522 uitkomst bieden. Ik krijg die niet zo gauw boven water.
Ik zou het wel vreemd vinden dat die functie pas terugkeert als er een code wordt aangeboden. Op die manier kan het dus best zo zijn dat hij uren aan een stuk in die functie blijft.
In een non-preemptive OS zou dat betekenen dat er, behalve interrupts, niets meer loopt.

Zeer gelijkaardige opmerkingen postte ik reeds dikke 48 uur geleden... Er zou inderdaad een optie moeten zijn om de badgelezer te pollen, om te checken of er geldige data beschikbaar is.

Daarentegen draait op een Raspberry PI gewoonlijk Raspbian wat toch echt een multitasker is (dure kreten zoals "preemptive" zijn aan mij niet besteed); dus zelfs als dat ene proces in lengte van dagen op data staat te wachten wil dat volstrekt niet zeggen dat er niets anders meer loopt. Gelukkig maar. Ook daar is de Raspi, met zijn operating system, duidelijk superieur aan de Arduino die geconcipieerd is om mono-tasking te werken.

[Bericht gewijzigd door big_fat_mama op dinsdag 28 mei 2019 17:45:25 (54%)

Ik zou bijna m'n schoen opeten als die read functie niet gelijk returned, ook al is er geen badge aangeboden. Op zich kan de TS dat snel bevestigen nu al die print()'s in z'n code staan.

[edit] Oh, ehm.... ik ga m'n schoen toch maar niet opeten:

read()
This function takes no parameters and waits for a card to be presented to the reader. It then returns two values: id (the card id) and text (the 48 characters stored in sector 8 of the card)

id, text = reader.read()
print(id)
print(text)

[Bericht gewijzigd door flipflop op dinsdag 28 mei 2019 22:10:35 (47%)

Schoenen eet je niet alleen, die heb je per paar
De vaste uitdrukking was toch "ik eet m'n hoed op"?

Maar buiten dit taalkundige nevenafje ga ik helemaal met je mee; en ook die vorige keer vroeg ik al om een functie "hebt u data voor me, of niet?" Maar daar hebben we dus niks meer van gehoord.

Op 28 mei 2019 17:42:12 schreef big_fat_mama: Daarentegen draait op een Raspberry PI gewoonlijk Raspbian wat toch echt een multitasker is (dure kreten zoals "preemptive" zijn aan mij niet besteed);

Je hebt ook nog cooperative multitasking (ook multitasking dus!), maar daarin geeft een proces zelf de controle terug aan de scheduler i.p.v. andersom. Doet een proces dat niet (zoals in MFRC522) dan hang je.

Op 27 mei 2019 20:57:40 schreef bordje:
Overkill of niet boeit me niet, moet werken.

Kennis van MySQL is weinig, maar daarom niet minder leuk om uit te zoeken.
Al doende leert men.

Log van de databaas eens nalezen? Anders eens achter Hensz' idee aangaan.

Zelf ben ik ook bezig met het zelfde project en krijg ook naar een paar uur dezelfde fout melding.

Ik vroeg mij af of er iemand in tussen al een oplossing gevonden heeft?

Hoi,
Ik heb de openingspost voor je herlezen, maar "dezefde foutmelding" kan ik daar niet in vinden. Sorry, maar ik heb geen zin om voor jou 2 bladzijden te gaan doorworstelen om te kijken welke "foutmelding" jij ook zou kunnen krijgen.

Ik vermoed dat jij wel weet welke foutmelding je krijgt. Meld dat dan!

@rew sorry voor mijn onduidelijkheid.

Maar ik krijg de volgende foutmelding die op treed naar een aantal uren:

Stap 5 cleanup
Traceback (most recent call last):
File "/home/pi/attendancesystem/check_attendance5.py", line 30, in <module>
cursor.execute("Select id, name FROM users WHERE rfid_uid="+str(id))
File "/usr/local/lib/python3.5/dist-packages/mysql/connector/cursor.py", line 569, in execute
self._handle_result(self._connection.cmd_query(stmt))
File "/usr/local/lib/python3.5/dist-packages/mysql/connector/connection.py", line 553, in cmd_query
result = self._handle_result(self._send_cmd(ServerCmd.QUERY, query))
File "/usr/local/lib/python3.5/dist-packages/mysql/connector/connection.py", line 314, in _send_cmd
return self._socket.recv()
File "/usr/local/lib/python3.5/dist-packages/mysql/connector/network.py", line 251, in recv_plain
raise errors.InterfaceError(errno=2013)
mysql.connector.errors.InterfaceError: 2013: Lost connection to MySQL server during query

Ik weet ondertussen dat dit te maken heeft met de mysql database connectie.

nu was ik benieuwd of er hier iemand is dit probleem heeft gevonden en weet hoe dit op te lossen.

wat er gebeurd is dat de (van beneden naar boven) een verbinding wegvalt, waarna er een hoop taken mislukken.

start mysql client vanaf een terminal en speel deze query eens af.

cursor.execute("Select id, name FROM users WHERE rfid_uid="+str(id))

plak de foutcode die dan optreed hier nog eens.

p.s.
ooit gehoord van SQL injection? zoek daar eens op, want je moet nooit een query uitvoeren door gewoon wat (string) argumenten samen te plakken.

handleiding:
https://dev.mysql.com/doc/refman/8.0/en/mysql.html

Zou het kunnen dat mysql vind dat je niet een verbinding uren open moet houden en na zoveel tijd de verbinding verbreekt? Zeker als er een uur niets gebeurt kan ik me voorstellen dat dit vaak wenselijk is.

De mijne staat hier soms wekenlang zonder enige connectie; ik heb hem nog nooit weten uitvallen. Misschien is het een configureerbare "feature"...

@rew hieronder: inderdaad haspel ik hier twee dingen door elkaar.
Er is een verschil tussen "blijven draaien zonder enige connectie" en "een connectie afsluiten na een bepaalde tijdspanne zonder activiteit".

[Bericht gewijzigd door big_fat_mama op dinsdag 10 september 2019 10:34:27 (42%)

Het gaat niet om de mysql server zelf die uitvalt, maar de VERBINDING.

De normale gebruikswijze is dat je een webpagina opvraagt, de PHP code maakt een database verbinding, vraagt de gegevens op en sluit daarna die verbinding weer. Met handmatige dingen, zoals de mysql commandline tool kan een verbinding wat langer blijven hangen.

Maar als je een uur "aan de lijn blijft" zonder commandos in te voeren, dan begint het er op te lijken dat de computer waar die verbinding vandaan komt mogelijk gecrasht is of ineens jou als server niet meer kan bereiken. Als dat ding reboot en weer een verbinding opzet, en weer en weer... voordat je het weet zit je server vol met allerlei processen die met niet (meer) bestaande clients aan de lijn hangen. Dus... gebruikelijk is om dat soort verbindingen na zeg een uur nietsdoen "er uit te mikken".

In een RFID applicatie kan ik me dat voorstellen dat dit gebeurt. Een uurtje komt er niemand met z'n kaartje langs en poef, weg is de verbinding.

Dan kan je OF na iedere gelezen kaart direct de verbinding opzetten, gebruiken, verbreken, of je moet iets maken als: If verbinding verbroken, dan gewoon nog een keer proberen opnieuw op te zetten....

In mysql kan je bepaalde logging aanzetten om te debuggen. Je kan kijken of je dan duidelijk krijgt dat ie zoiets aan het doen is. Of je kan gewoon direct voor een oplossing gaan. (met het risico dat je een niet bestaand probleem oplost).

Ik denk dat het heel simpel is:

MySQL heeft geen zin om 24 uur op een query te wachten. Dat is kromme code. Zoiets als 200 man die in je winkel staan maar nooit komen afrekenen.

Dit gedeelte:

db = mysql.connector.connect(
host="localhost",
user="*****",
passwd="*****",
database="attendancesystem"
)

cursor = db.cursor()

Na de read(); zetten.

Pas als een badge wordt aangeboden wordt de connectie gemaakt, veel netter en stabieler, zo kan je ook eens je database herstarten zonder je reader script te herstarten.

Voor het nette nog een db.close() aan het einde van de lus.

@ K7Jz ik ga jou suggestie vanavond aanpassen en testen.

Ik kom hier op terug met mijn bevindingen.

Bedankt voor het meedenken allemaal.

MySQL system variabele: wait_timeout
"default 28800, The number of seconds the server waits for activity on a noninteractive connection before closing it. "

Dat is 8 uur..

Over efficient en overkill: Ja mijn fiets heeft geen GPS tracker met MySQL nodig, maar, had ik wel een MySQL server op mijn fiets met ritten, afstanden e.d. dan zou ik samen met anderen risicogebieden voor lekke banden kunnen detecteren. Of de maximale levensduur van mijn banden kunnen bijhouden, of eerder een notificatie krijgen dat er werkzaamheden de gangbare routes zijn, of dat bij een bepaalde windrichting een bepaalde route sneller is.

Een hardcoded reader die alleen een lijst van toegestane RFID toelaat is genoeg om een deur te openen. Zo gauw er tijden, profielen, rapporten en 'vriendelijk beheer' bij komen kijken is een database niet echt over de top.

Overigens kan de database natuurlijk ook ergens anders draaien en met een simpele TCP of HTTP verbinding vanaf een Arduino/ESP gepolst worden.

Ik heb het advies van K7Jz om de database connectie na de read(); te zetten en aan het einde van de lus weer af te sluiten met db.close() toegepast, daarna 48uur standby laten draaien en intussen geen badge aangeboden.
Na deze 48uur heb ik een badge aangeboden en het systeem werkt nog steeds zonder foutmelding en de data word netjes gelogd in de database.

Dit is de oplossing voor mijn probleem.

K7Jz bedankt voor deze oplossing.

Uiteraard iedereen bedankt voor de hulp.

K7Jz, bedankt voor de oplossing!

Dit vorige week aangepast in het programma,
en ligt nu al week werkend, zonder 1 fout, op mn buro.

Bedankt iedereen voor de inspanningen

Top! Bedankt voor de terugkoppeling.