GSM-Gerät? Datenbank? Was soll denn das?
Zu dem GSM-Gerät 2 gehört einfach ein Backend, in dem die Daten gesammelt und für den Bediener aufbereitet werden. Und wie das heutzutage so üblich ist, hat dieses Backend darunter eine relationale Datenbank.
Starten wir einfach erst mal mit einem Überblick.
In diesem Diagramm sieht man sehr gut, was da alles so verwaltet wird.
- Users – die Benutzer im System
- Grounds – die Reviere
- Memberships – eine Gast-Zugehörigkeit zu Revieren
Der Inhaber der Reviere gehört natürlich automatisch dazu - Traps – die Fallen
- TrapHistories – die letzten Meldungen der Falle
Die meisten Felder der Tabellen sind vermutlich selbsterklärend. Näher eingehen muss ich vermutlich nur auf die Felder an der Tabelle Traps.
- IMEI – Im GSM-Netz ist das eine Identifikationsnummer für das Gerät.
In diesem System dient das auch dazu, den Melder zu indentifizieren. - ICCID – Hinter dieser ID verbirgt sich die Identifikationsnummer der SIM-Karte.
Für den Benutzer ist das relativ wertlos. Sollten mal Melder „verloren gehen“, kann man mit dieser ID aber die SIM-Karte identifizieren, die gesperrt werden muss. - Voltage – Spannung in Millivolt
- Strength – Eine abstrakte Größe vorgegeben durch das eingesetzte Modul.
Der Bereich bewegt sich von 1, was ungefähr -109 dBm entspricht, bis zu 30, was ungefähr -53 dBm entspricht. - Switch_One_Ok_State – Technisch wollte ich die Option offen halten, dass ggf. auch ein offener Schalter eine scharf gestellte Falle repräsentiert und nicht nur der geschlossene Schalter. Über dieses Feld kann man das beeinflussen.
- Switch_One_Active – Wird der Schalter gerade genutzt.
Darüber kann man z.B. auch den Melder außer Betrieb nehmen.
Ggf. werden diese Felder auch noch erweitert. Aktuell steht noch die Idee im Raum, über das GSM-Netz die grobe Geolocation abzufragen.