Raspberry pi en rfid

Er is een "tradeoff" tussen "overbodig OS" en "veel code zelf moeten schrijven".

Dat heeft niks met een OS te maken, iedere willekeurige compiler met de juiste libraries kan dat.
Misschien iets meer als 50 regels, maar dat boeit niet, je hebt dan wel wat goeds.

(het lijkt wel of de moderne 'programmeur' direct afhaakt als de code niet meer op een A4'tje past... )
Ik erger me vaak groen en geel aan alle apparaten die zonodig Linux moeten draaien, omdat het voor de programmeur makkelijker is...
Mijn satontvanger op Linux doet 3x zo lang over opstarten als een oude buizenradio die ik heb staan...

het lijkt wel of de moderne 'programmeur' direct afhaakt als de code niet meer op een A4'tje past...

Zo heb ik het inderdaad geleerd gekregen, ongeveer: een regel of 100 is het maximum. Twee A4'tjes, zeg maar. En ik beschouw mezelf allesbehalve als een 'moderne' programmeur, eerder integendeel!

Het onderscheid zit hem wellicht eerder in de tegenstelling tussen "MSDOS/Windows"-stijl, waar je alles wat er te doen is in een enkele executable stopt; versus Unix/Linux waar je de taak opsplitst in zoveel mogelijk subtaakjes die je elk apart programmeert en uitvoert.

Om bij het onderwerp te blijven: je kunt natuurlijk alles wat T/S wil doen op Arduino draaien, al zul je er dan wel meerdere nodig hebben misschien (heb je dat lijstje goed bekeken? Het is nogal wat!) Eigenlijk zou ik zelf liefst op een rits Raspi's doen, iets duurder misschien, maar zoveel beter beheersbaar.

En je kunt ook op een driewielertje naar Timboektoe reizen, maar ik gebruik toch liever het gepaste werktuig voor iedere klus. Waar bestanden dienen behandeld te worden, zeker in een multitasking omgeving, daar verkies ik een operating system om het huishouden te regelen. Over webservers nog gezwegen.

[Bericht gewijzigd door big_fat_mama op zondag 26 mei 2019 16:52:21 (15%)

Die rits raspberry's heb ik al.
5 continu online, en 1 waar ik testjes op doe.

De pi met de meeste taken, die domotica regelt, en ook nog berichtjes stuurd en ontvangt via Pushover en Telegram is een Pi2 model B,
draaid tss de 10 en 15% load, rond de 45°C

Pimatic draaid nu al iets meer dan 2jaar op dezelfde pi.

en over boot tijden kan ik niet klagen, binnen de minuut is alles online na een reboot. En een reboot komt ma zelden voor, tis geen windows he

Ook nog leuke extra is dat merendeel van de pi's PoE gevoed worden, 2 via de hat en 2 via PoE to power adapter,
dit alles zit achter een grote UPS, alle andere voedingen voor sensoren ed komt ook van een 24V backup systeem.
Dus over boot tijden maak ik me geen zorgen

Om terug te komen op het topic, nog niet vast gelopen. Zal deze nu zo laten tot morgenavond.

Hallow

bij deze een update, en jawel die doet et nie meer...
Dus inderdaad de sql database.

Stap 1
Plaats badge
Stap 1a: badge576861223913gelezen
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

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

Door zonder database te werken. Zoals ik reeds tweemaal suggereerde.

(het wordt wel eentonig, jawel, maar daar kan ik niks aan doen)

Inderdaad, een complete SQL database voor zoiets simpels is wel wat overdreven...

Misschien wat overkill, maar had wel gewoon stabiel moeten werken natuurlijk. Nou weet ik niet veel van MySQL, dus helaas.
Is het nou zo dat je elke seconde de reader uitleest en, ook als er niks gelezen wordt, toch een sql query gedaan wordt? Gaat dat wel goed? Het lijkt mij logischer om alleen te zoeken als er een kaart gelezen is.

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.

Soms kan men ook leren door iets NIET te doen ... MySql, bv...

SQL is goed (maar niet echt snel) voor complexe databases, niet voor een handvol nummertjes en namen...

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.