MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054

[jonofe]

Funktionieren die anderen MQTT LBS denn korrekt? D.h. siehst du von diesen Connects im Mosquitto Broker Log?
Kannst du mal einen Screenshot vom MQTT Publish Server LBS machen (Logikseite)?

[NurMa]

Habe eben den Subscribe Server eingefügt, der Verbindet sich ganz normal mit dem Broker und es wird auch ein LOG in der Verwaltung erzeugt.

Screenshot der Logikseite
logikmqtt.jpg
Der rechte LBS verbindet sich, von dem linken gibt's weder ein LOG, noch nen Connect

Ich habe den Publish Server eben auch einmal gelöscht, neu heruntergeladen und frisch eingelesen. Leider keine Änderung.

[jonofe]

Dass es beim Publish-Server kein Log gibt, das kann schon sein. Denn es ist kein echter Daemon, d.h. im EXEC Bereich gibt es gar kein Logging und im LBS Teil werden nur Fehler geloggt. Also ist es eigentlich ein gutes Zeichen, dass kein Logfile da ist.

Du könntest mal schauen was im File /tmp/mqtt-config.php drinsteht wenn der LBS aktiviert ist.

cat /tmp/mqtt-config.php

Da sollten die Werte deiner LBS Eingänge als PHP Code auftauchen.

[jonofe]

Außerdem in mysql mal folgendes ausführen:

mysql
USE edomiLive;
SHOW PROCEDURE STATUS; show triggers;

Und dann mal den Output hier posten.

Zusätzlich ein

ls -la /usr/local/edomi/www/data/liveproject/lbs/*1051.php

und auch den Output hier posten.

[NurMa]

Moin,

also in der mqtt-config.php stehen die Eingangswerte drin.

mysql:

mysql> SHOW PROCEDURE STATUS; show triggers;
+-----------+--------------+-----------+----------------+---------------------+---------------------+---------------+---------+----------------------+----------------------+--------------------+
| Db        | Name         | Type      | Definer        | Modified            | Created             | Security_type | Comment | character_set_client | collation_connection | Database Collation |
+-----------+--------------+-----------+----------------+---------------------+---------------------+---------------+---------+----------------------+----------------------+--------------------+
| edomiLive | mqtt_publish | PROCEDURE | root@localhost | 2017-06-23 23:43:56 | 2017-06-23 23:43:56 | DEFINER       |         | latin1               | latin1_swedish_ci    | latin1_swedish_ci  |
+-----------+--------------+-----------+----------------+---------------------+---------------------+---------------+---------+----------------------+----------------------+--------------------+
1 row in set (0.00 sec)

Empty set (0.01 sec)

ls -la /usr/local/edomi/www/data/liveproject/lbs/*1051.php

-rw-r--r-- 1 root root 3293 23. Jun 23:43 /usr/local/edomi/www/data/liveproject/lbs/EXE19001051.php -rw-r--r-- 1 root root 4844 23. Jun 23:43 /usr/local/edomi/www/data/liveproject/lbs/LBS19001051.php

[jonofe]

Der mySQL Trigger fehlt. Daher passiert auch nichts. Frage ist nur woran das liegt, denn eigentlich legt der LBS sowohl die Procedure als auch den Trigger an. Und zwar bei jedem EDOMI Start.

Die Platte ist nicht zufällig voll gelaufen?

Mach doch mal per Hand folgendes:

mysql
USE edomiLive;
DROP TRIGGER IF EXISTS mqtt_insert_trigger;
DROP TRIGGER IF EXISTS mqtt_update_trigger;
CREATE TRIGGER mqtt_insert_trigger AFTER INSERT ON RAMko FOR EACH ROW CALL mqtt_publish(NEW.gatyp, NEW.ga, NEW.name, NEW.value);
CREATE TRIGGER mqtt_update_trigger AFTER UPDATE ON RAMko FOR EACH ROW CALL mqtt_publish(NEW.gatyp, NEW.ga, NEW.name, NEW.value);
SHOW TRIGGERS;

[NurMa]

Ok, soweit verstanden. Das ist aber eigenartig:

mysql> DROP TRIGGER IF EXISTS mqtt_insert_trigger;
ERROR 1360 (HY000): Trigger does not exist
mysql> DROP TRIGGER IF EXISTS mqtt_update_trigger;
ERROR 1360 (HY000): Trigger does not exist
mysql> CREATE TRIGGER mqtt_insert_trigger AFTER INSERT ON RAMko FOR EACH ROW CALL mqtt_publish(NEW.gatyp, NEW.ga, NEW.name, NEW.value);
ERROR 1359 (HY000): Trigger already exists
mysql> CREATE TRIGGER mqtt_update_trigger AFTER UPDATE ON RAMko FOR EACH ROW CALL mqtt_publish(NEW.gatyp, NEW.ga, NEW.name, NEW.value);
ERROR 1359 (HY000): Trigger already exists
mysql> SHOW TRIGGERS;
Empty set (0.00 sec)

Wenn ich das richtig interpretiere findet er die Trigger beim löschen nicht, wenn ich versuche sie anzulegen, behauptet er aber, es gäbe sie schon?

[NurMa]

Werden die Trigger in der Tabelle gespeichert oder irgendwo "zentral" in der DB?

Falls in der Tabelle gaert: lässt sich die db RAMko löschen, so dass sie neu aufgebaut wird im Live-Projekt?

[jonofe]

PROCEDURES und TRIGGERS werden m.W. zentral gespeichert. Im Trigger wird ja die Tabelle angegeben, auf die sich der Trigger bezieht.
Hast du mal ein älteres Backup eingespielt?

[NurMa]

Das Backup welches ich eingespielt habe ist das letzte vor dem Stromausfall. Ich sehe auch genau, dass es bis dahin noch funktioniert hat, weil die iKOs Persistent beim MQTT-Broker gespeichert sind und die Uhrzeit genau der Ausfall-Zeit entspricht.

[jonofe]

vermutlich ist irgendetwas an der MYSLQ DB kaputt gegangen, was mit den Triggers zusammenhängt und was eben nicht Teil des Backups ist.
Wie man das wieder repariert, da bin ich im Moment echt überfragt.

[NurMa]

Kein Thema, danke für Deine Hilfe. Ich werde mal recherchieren ob ich dazu was finde.

[jonofe]

Was du noch testen könntest: Eine Vanilla EDOMI VM aufsetzen, z.B. via VirtualBox und dann das Backup einspielen und prüfen, ob es funktioniert.

[NurMa]

Genau das mache ich jetzt mal. EDOMI läuft sowieso auf nem ESXi. Ich werde berichten...

[NurMa]

Aktueller Stand:
Komplette Neuinstallation EDOMI 1.50, Backup einspielen, IPs anpassen, setup Script der MQTT-Bausteine ausgeführt.

Leider keine Änderung. Das "Problem" wird offensichtlich mitgesichert.

Werde mich mal mit den Triggern beschäftigen und schauen ob ich da irgendwas "von Hand" bereinigen kann.