LUA-Scripting und MySQL (Filterung)

Hallo Forum,

ich bin mir eigentlich sicher, dass wir einen solchen Thread schon einmal hatten. Ich finde ihn aber trotz intensiver Suche nicht mehr wieder. Es geht um LUA-Scripting und Einträge in die MySQL Datenbank. Ich möchte mit dem LUA-Scripting filtern nach doppelten RICs bzw. einige RICs ganz aus der DB heraus lassen.
Kann einmal jemand, der vielleicht genau das schon mit LUA realisiert hat, seine pluginfilter.lua posten?
Ansonsten, könnte jemand mal erklären, wie die pluginfilter.lua generell auszusehen hat und wie sie funktioniert? Ich kenne mich mit LUA nicht aus und komme nach der Erklärung für die socketfilter.lua auf www.monitord.de nicht so recht in das Thema rein.

Danke für Eure Hilfe.
Gruß,
Funkwart

Hallo,

das Filtern doppelter Einträge bei doppelter Auslösung geht meines Wissens nach nicht, da der monitord den vorher ausgewerteten Code nicht mehr kennt (das LUA-Skript wird für jede EINZELNE RIC oder ZVEI-Tonfolge einzeln, getrennt voneinander aufgerufen). Der Filter erschlägt also nur die Eintragung aktuell ausgewerteter aber nicht gewünschter RICs/ZVEI-Folgen.

Wie das geht, sollte eigentlich aus der Anleitung hervor gehen: Du gibst an, welche Tonfolgen/RICs Du in der DB haben magst und alle anderen werden verworfen. Hierzu entsprechend bei "Fund" die Eintragung mit "return 0" erlauben oder halt die Eintragung mit "return 1" verwerfen. Zugegeben, das Beispiel auf monitord.de ist recht umfangreich.

Das Beispiel unten zeigt einen einfachen Filter, bei dem nur die unter "toShowXXX" angegebenen RICs/ZVEI-Tonfolgen/FMS-Kennungen in der Datenbank landen (ungetestet, eben nur zusammen gesammelt).

Viele Grüße
Martin

Code:

---

-- PluginFilter.lua
--
-- Filter für die Plugins - wird pro aktivem Plugin aufgerufen
--
-- Globales Array "arg" enthält die Daten vom Auswertermodul
--
-- Zusätzliche Werte im Array:
--
-- client_authenticated:        0/1  (1=angemeldet)
-- client_ip:                        IP-Adresse des Clients
-- client_loginname:                Anmeldename
-- client_type:                        fms32, crusader, monitord
--
-- Rückgabewert:
-- 0 = an Client senden,
-- 1 = nicht an Client senden,
-- alle anderen = an Client senden
--

local toShowFMS = {"11111111", "22222222"} ;
local toShowPOCSAG = {"1111111", "2222222"} ;
local toShowZVEI = {"99000", "99001"} ;

function filter()

        local dummyValue=1 ;

        -- DEBUG-Info: Alles ausgeben
        for index,testwert in pairs(arg) do
                print(index)
                print(testwert)
        end       

        -- ZVEI
        if(arg["typ"] == "zvei") then
                for index,testwert in pairs(toShowZVEI) do
                        if(testwert == arg["zvei"]) then
                                return 0
                        end
                end
        end

        -- FMS
        if(arg["typ"] == "fms") then
                for index,testwert in pairs(toShowFMS) do
                        if(testwert == arg["fmskennung"]) then
                                return 0
                        end
                end
        end

        -- POCSAG
        if(arg["typ"] == "pocsag") then
                for index,testwert in pairs(toShowPOCSAG) do
                        if(testwert == arg["ric"]) then
                                return 0
                        end
                end
        end
       
        -- default: anzeige unterdruecken
        return 1;

end

---

Ich hatte irgendwann mal den Workaround vorgeschlagen, daß das LUA-Skript am Ende der Verarbeitung die aktuelle RIC/Schleife in eine Datei schreibt. Diese Datei könnte man dann beim nächsten Mal auslesen und das Skript würde sich an die letzte(n) RICs/ZVEIs quasi erinnern.

Könnte man ja auf ne RAMDisk bzw. tmpfs legen damit der Disk I/O nicht zu sehr bremst. Müßte eigentlich klappen.

@mdi: Danke, da blicke ich jetzt besser durch.

@Buebchen: Die Idee kam mir auch spontan in den Sinn. Dürfte ja gar nicht so schwierig zu implementieren sein. Falls ich das Script zum Laufen kriege, probiere ich mal rum.

Muss man denn jetzt beim configure noch speziell auf etwas achten, um das Scripting nutzen zu können?

Danke und Gruß,
Funkwart

Im Log müßte er schon etwas zum Scripting schreiben, wenn er es ausführt. Das configure hat Optionen für LUA:

(aus ./m4/lua.m4):

Code:

---

#    --with-lua-prefix=DIR    Lua files are in DIR.
#    --with-lua-suffix=ARG    Lua binaries and library files are
#                              suffixed with ARG.
#    --with-lua-includes=DIR  Lua include files are in DIR.
#    --with-lua-libraries=DIR  Lua library files are in DIR.

---

Sollte er die libs / includes nicht finden kannst Du dem configure damit auf die Sprünge helfen. Das configure gibt dann ja auch aus, ob es den lua-support gefunden hat.

Mit
--with-lua-includes=DIR Lua include files are in DIR.
--with-lua-libraries=DIR Lua library files are in DIR.

solltest es klappen.

[Edit]
Im einfachsten Fall sonst mal mit --with-lua den generellen LUA Check starten. Ich weiß gerade nicht, ob der Standard mit lua oder ohne war :)

Hallo Forum,

inzwischen habe ich lua-Unterstützung mit im monitord. Leider funktioniert das Scripting nicht. Ich habe lediglich ein pluginfilter.lua eingebunden.
Dieses ist gemäß Forumeintrag entstanden:

Code:

---

-- pluginfilter.lua

--
-- Filter für den SocketServer - wird pro aktiven Client aufgerufen
--
-- Globales Array "arg" enthält die Daten vom Auswertermodul
--
-- Zusätzliche Werte im Array:
--
-- plugin_name:                z.B. mysql (aus monitord.xml)
--
-- Rückgabewert: 0 = an Client senden, 1= nicht an Client senden, alle anderen = an Client senden
--

local sperrliste = {"1680000", "1680004"} ;

function pluginFilter()
        if (arg["plugin_name"]=="mysql") then
                for index,testwert in pairs(sperrliste) do
                        if (testwert==arg["ric"]) then
                                return 1
                        end
                end
        end
        return 0 ;
end

---

Ich bekomme beim Start von monitord folgende Fehlermeldung:

Code:

---

16:27:48.814 ERROR: monitord/PluginThread.cpp(342) Fehler beim Aufruf lua dispatcher POST script:attempt to call a nil value
 16:27:48.814 ERROR: monitord/PluginThread.cpp(349) nicht-numerische Antwort vom lua dispatcher script

---

Diese taucht immer auf, wenn eine Auswertung erfolgt. In die Datenbank wird immer eingetragen, egal ob das Script hätte wegfiltern sollen oder nicht.
Hat jemand das Problem auch schon gehabt und behoben? Wenn ja, wie?

Danke und Gruß,
Funkwart

Es wird noch eine zweite LUA Funktion aufgerufen

"pluginFilterPost" - Das sind die Fehlermeldungen, daß ein NIL Wert aufgerufen wurde (weil es nicht da ist) und kein numerischer Wert zurückgegeben wurde (weil es immer noch nicht da ist :) )

Ich könnte mich spontan nicht dran erinnern, daß ich die damals schon vorgesehen hatte. Aber ist schon lange her. Auf jeden Fall wird die Funktion nachdem pluginFilter aufgerufen. Unabhängig, ob die lua Funktion "pluginFilter" entscheidet das Datenpaket an die Dispatcher zu geben oder nicht.

Im einfachsten Fall also eine zweite Funktion "pluginFilterPost" in die gleiche LUA-Datei packen. Rückgabewert des lua filters wird zwei erwartet (numerisch) - also "return 0". Der Wert wird eh nicht verarbeitet.

Als ersten Test bitte mal die Prüfung auf "arg[plugin_name]==mysql" rausnehmen. Ggf. stimmt hier etwas nicht. Gibt eh nur das eine Plugin.

Prima, es klappt. Ich habe

Code:

---

function pluginFilterPost()
        return 0 ;
end

---

in der pluginfilter.lua ergänzt. Keine Fehlermeldungen mehr!

Danke für Eure Hilfe.

Gruß,
Funkwart