Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ankündigung
Einklappen
Keine Ankündigung bisher.
MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054
cd /var/lib/mysql/edomiLive/
rm mqtt_insert_trigger.TRN
rm mqtt_update_trigger.TRN
Genau das war mein Problem, hatte bisher keine Lösung gefunden. Vielen Dank für die Info hier. Damit ist zumindest das Problem mit dem "Trigger already exists" verschwunden.
Ich werde heute Abend versuchen ob der Publish Baustein damit wieder geht.
Verzögerungen hatte ich bisher keine nennenswerten. Habe auch alles ohne Filter per mqtt veröffentlicht.
Nanosonde
Frag mich später nochmal. Grundsätzlich würde ich wohl einen Zentralen Baustein nehmen.
Das ich jetzt so massive Probleme mit dem Edomi/MQTT Kombi hatte/habe ist das deaktivieren einer Logikseite sehr händisch
Ich hatte ja zwischendurch auch einmal den Effekt, dass Edomi nicht mehr richtig funktionierte, nachdem der Broker mal kurz von mir beendet wurde.
Aus diesem Grund habe ich die beiden MQTT Server LBS auch erstmal komplett wieder rausgeschmissen.
Das ist mir im Produktivsystem zu heikel. Auch wenn das mit den SQL Triggern ja sehr überschaubar ist.
Schön wäre es, wenn Edomi einfach eine Mini-API für solche besonderen LBS zur Verfügung stellen könnte, so dass man an der DB selbst nicht rumfummeln muss:
wie lange dauert es denn bis ein publish im Log des Brokers auftaucht?
Ist es bei allen Topics so langsam. Müsste ja im Mosquitto Log zu sehen sein.
Da müsste ja dann einiges los sein, wenn du alles publishst. Jede Sekunde sollte da z.B. die Zeit ankommen.
cd /var/lib/mysql/edomiLive/
rm mqtt_insert_trigger.TRN
rm mqtt_update_trigger.TRN
und in mysql:
Code:
mysql> USE edomiLive;
[I]Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed[/I]
mysql> DROP TRIGGER IF EXISTS mqtt_insert_trigger;
[I]Query OK, 0 rows affected, 1 warning (0.00 sec)[/I]
mysql> DROP TRIGGER IF EXISTS mqtt_update_trigger;
[I]Query OK, 0 rows affected, 1 warning (0.00 sec)[/I]
mysql> CREATE TRIGGER mqtt_insert_trigger AFTER INSERT ON RAMko FOR EACH ROW CALL mqtt_publish(NEW.gatyp, NEW.ga, NEW.name, NEW.value);
[I]Query OK, 0 rows affected (0.04 sec)[/I]
mysql> CREATE TRIGGER mqtt_update_trigger AFTER UPDATE ON RAMko FOR EACH ROW CALL mqtt_publish(NEW.gatyp, NEW.ga, NEW.name, NEW.value);
[I]Query OK, 0 rows affected (0.01 sec)[/I]
Leider ist jetzt das Timing Problem wieder da.
Ich habe mal auf folgenden Topic Subscribed
edomi/status/internal/26
Das ist der minuten Trigger von Edomi.
Es dauert ca. 7 sek bis der Topic bei MQTT.fx ankommt.
Auch wenn ich, wie oben schon beschrieben, ein Licht via edomi GA schalte dauert es ca. 4 sek bis das Licht an ist.
Ich glaube irgendwas im LBS oder in der SQL Datenbank zieht die verarbeitung runter.
CPU ist bei 8% Ram bei 50%
Auch treten seitdem der mySQL trigger wieder da ist wieder die "RW Err" auf.
Keine Ahnung womit die zusammenhängen.
Gibt es irgendeinen Weg herauszusfinden was diese RW Err sind? oder irgendeine andere Idee?
Das ist wohl exakt dasselbe Problem, dass weiter oben auch schon erwähnt wurde. Es ist leider nie eine Lösung hier dokumentiert worden.
Aber es ist definitiv die Ursache für das Problem. Ohne Trigger wird kein MQTT publish getriggert.
Leider weiß ich auch nicht woran das liegt und wie man mysql da wieder auf die Sprünge helfen kann.
Mach mal das was in #64 beschrieben ist. Und das mal posten.
Dann sieht man ob procedure und trigger angelegt werden.
OK.
Code:
mysql> USE edomiLive;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
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-07-26 00:09:04 | 2017-07-26 00:09:04 | DEFINER | | latin1 | latin1_swedish_ci | latin1_swedish_ci |
+-----------+--------------+-----------+----------------+---------------------+---------------------+---------------+---------+----------------------+----------------------+--------------------+
1 row in set (0.00 sec)
Empty set (0.00 sec)
Sieht aufjedenfall anders aus als vor meinem Backup restore (siehe Beitrag #91)
Im Beitrag #91 hatte ich noch triggers?!
Habe jetzt nochmal versucht
Code:
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;
auszuführen.
Bei
Code:
mysql> DROP TRIGGER IF EXISTS mqtt_insert_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
Wenn der Publish Server läuft und du keine Filter angelegt hast, dann sollte im Mosquitto Broker Log die Post abgehen.
Passiert das?
Hier mal ein Ausschnitt aus dem LOG
Code:
/var/log/mosquitto/
cat mosquitto.log
Code:
1501086288: Received PINGREQ from EDOMI MQTT Subscribe Server (180)
1501086288: Sending PINGRESP to EDOMI MQTT Subscribe Server (180)
1501086291: Received PINGREQ from mqtt_ae676026.5198a
1501086291: Sending PINGRESP to mqtt_ae676026.5198a
1501086348: Received PINGREQ from EDOMI MQTT Subscribe Server (180)
1501086348: Sending PINGRESP to EDOMI MQTT Subscribe Server (180)
1501086351: Received PINGREQ from mqtt_ae676026.5198a
1501086351: Sending PINGRESP to mqtt_ae676026.5198a
1501086408: Received PINGREQ from EDOMI MQTT Subscribe Server (180)
1501086408: Sending PINGRESP to EDOMI MQTT Subscribe Server (180)
1501086411: Received PINGREQ from mqtt_ae676026.5198a
1501086411: Sending PINGRESP to mqtt_ae676026.5198a
1501086468: Received PINGREQ from EDOMI MQTT Subscribe Server (180)
1501086468: Sending PINGRESP to EDOMI MQTT Subscribe Server (180)
1501086471: Received PINGREQ from mqtt_ae676026.5198a
1501086471: Sending PINGRESP to mqtt_ae676026.5198a
1501086528: Received PINGREQ from EDOMI MQTT Subscribe Server (180)
1501086528: Sending PINGRESP to EDOMI MQTT Subscribe Server (180)
1501086531: Received PINGREQ from mqtt_ae676026.5198a
1501086531: Sending PINGRESP to mqtt_ae676026.5198a
1501086541: New connection from 192.168.10.2 on port 1883.
1501086541: New client connected from 192.168.10.2 as 2f41287809dd43d5ac5a9da818fa673d (c1, k60, u'edomi').
1501086541: Sending CONNACK to 2f41287809dd43d5ac5a9da818fa673d (0, 0)
1501086588: Received PINGREQ from EDOMI MQTT Subscribe Server (180)
1501086588: Sending PINGRESP to EDOMI MQTT Subscribe Server (180)
1501086591: Received PINGREQ from mqtt_ae676026.5198a
1501086591: Sending PINGRESP to mqtt_ae676026.5198a
1501086611: Received PINGREQ from 2f41287809dd43d5ac5a9da818fa673d
1501086611: Sending PINGRESP to 2f41287809dd43d5ac5a9da818fa673d
1501086648: Received PINGREQ from EDOMI MQTT Subscribe Server (180)
1501086648: Sending PINGRESP to EDOMI MQTT Subscribe Server (180)
1501086651: Received PINGREQ from mqtt_ae676026.5198a
1501086651: Sending PINGRESP to mqtt_ae676026.5198a
1501086700: Client 2f41287809dd43d5ac5a9da818fa673d has exceeded timeout, disconnecting.
1501086700: Socket error on client 2f41287809dd43d5ac5a9da818fa673d, disconnecting.
1501086708: Received PINGREQ from EDOMI MQTT Subscribe Server (180)
1501086708: Sending PINGRESP to EDOMI MQTT Subscribe Server (180)
1501086711: Received PINGREQ from mqtt_ae676026.5198a
Ich sehe hier nichts vom Publish Client (zumindest taucht der Name nicht auf)
Der "neue Client" ist sicher MQTT.fx auf dem Macbook
Komisch das MQTT.fx (http://www.mqttfx.org/) allerdings Publish Topics sieht.
Dies könnte natürlich auch ein "Echo" aus Zeiten sein wo der LBS lief aber nicht genutzt worden ist.
Jetzt aboniere ich folgendes Topic ( z.B mit mqttfx) :
edomi/status/knx/0-1-1
Müsste dann nicht bei änderung dieser GA eine neue Message/payload generiert und gepublished werden?
Bei mir klappt das nicht!!
Wenn ich mit mqttfx dieses Topic aboniere bekomme ich einen Payload.
Dieser ändert sich aber nie ..egal was ich innerhalb Edomi oder im Bus mit dieser GA anstelle.
Frag mich später nochmal. Grundsätzlich würde ich wohl einen Zentralen Baustein nehmen.
Das ich jetzt so massive Probleme mit dem Edomi/MQTT Kombi hatte/habe ist das deaktivieren einer Logikseite sehr händisch
Mal eine Frage in die Runde: wie nutzt Ihr die MQTT CLIENT LBS denn so im Detail?
Nutzt Ihr nur eine Instanz und abonniert dann alle möglichen Topics, die dann später durch einen anderen LBS zerpflückt werden?
Oder nutzt Ihr pro Topic jeweils eine eigene Instanz?
Ich hadere aktuell noch damit, wie ich die vielen Topic am besten verarbeiten soll. Zum Beispiel möchte ich einige MQTT Clients nutzen, die dieser Spez. folgen: https://github.com/mqtt-smarthome/mqtt-smarthome
Zu nennen wäre da hm2mqtt.js, bravia2mqtt, etc.
Ich überlege, ob es evtl. sinnvoll ist, jeweils eigene LBS zu bauen, die dann ein Topic/Payload wieder zu einem HM-Gerät, etc. abbilden und auch dann die entsprechenden Ein-/Ausgänge zur Verfügung stellen sollen. Das würde aber zum Beispiel bei Homematic ziemlich viele neue LBS bedeuten.
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;
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: