Ich habe immer wieder endlose Latenzen (teilweise 5 Sekunden und mehr) beim Schalten eines Shelly Aktors. Ich habe z.B. einen Shelly im Lichtschalter, der eine 2. Lampe einschaltet, wenn das Licht angeschaltet wird. Schalte das ganze per IPS über MQTT.
Am nächsten Tag oder ein paar Stunden später geht es dann wieder einwandfrei.
System läuft auf einem Raspberry Pi 3 mit IPS 5.3 vom 16.12.19.
Hi Peter,
hast du irgendwelche gelbe/rote Meldungen im meldungsfenster? Ggf. mal über das Status Widget gucken.
paresy
Ja, aber die kommen alle von einem 1-Wire-Sensor der nicht so will wie ich…
Hallo zusammen,
bei mir laufen Homematic(10.1.1.xxx) und Multicast(10.1.3.xxx) in unterschiedlichen Subnetzen. Damit erreiche ich, dass ich von meinem normalen Hausnetz nicht allzuviele IPs für ESP8266-Steuerungen verbrauche. Das klappt auch einwandfrei, da man beim Multicast-Socket die entsprechende IP angeben kann.
Bei MQTT kann man jedoch nur den Port einstellen, aber keine IP. Hat das einen Grund bzw. könnte man das in IPS erweitern ?
Grüße Frank
Edit: Hab’s hinbekommen …
Hallo zusammen,
Ich spiele mit dem Gedanke mir eine OpenWB Wallbox zu kaufen um meine E-Fahrzeuge zu laden.
Jetzt habe ich mir zum Test die SW auf einen Pi gezogen um die Kommunikation über MQTT mit IPS auszuprobieren.
Leider kann ich die Verschlüsselung nicht abschalten und somit nichts damit anfangen…
Daten bekomme ich aber!
07.01.2020, 20:48:23 | RECEIVED [192.168.1.205:44108] | <SYN><ETX><SOH><SOH>,<SOH><NUL><SOH>(<ETX><ETX>D+Hý) <SOH>`AKW9StÍ߉³Î;ìýnö´t€<DC3><NAK>'ê ɴ„Û?<SO><DEL>ÿ<FF>´>…j»<DC2>D™Ú[bõ‰0’êVqg¿ä)â<NUL>><DC3><STX><DC3><ETX><DC3><SOH>À,À0<NUL>Ÿ̨̩̪À+À/<NUL>žÀ$À(<NUL>kÀ#À'<NUL>gÀ<LF>À<DC4><NUL>9À<HT>À<DC3><NUL>3<NUL><NUL>œ<NUL>=<NUL><<NUL>5<NUL>/<NUL>ÿ<SOH><NUL><NUL>¡<NUL><NUL><NUL><DC2><NUL><DLE><NUL><NUL><CR>192.168.1.200<NUL><VT><NUL><EOT><ETX><NUL><SOH><STX><NUL><LF><NUL><FF><NUL><LF><NUL><GS><NUL><ETB><NUL><RS><NUL><EM><NUL><CAN><NUL>#<NUL><NUL><NUL><SYN><NUL><NUL><NUL><ETB><NUL><NUL><NUL><CR><NUL>*<NUL>(<EOT><ETX><ENQ><ETX><ACK><ETX><BS><BEL><BS><BS><BS><HT><BS><LF><BS><VT><BS><EOT><BS><ENQ><BS><ACK><EOT><SOH><ENQ><SOH><ACK><SOH><ETX><ETX><ETX><SOH><ETX><STX><EOT><STX><ENQ><STX><ACK><STX><NUL>+<NUL><ENQ><EOT><ETX><EOT><ETX><ETX><NUL>-<NUL><STX><SOH><SOH><NUL>3<NUL>&<NUL>$<NUL><GS><NUL> F¸ÿ\<SO>“<SO>²#B²*à´.ÃÍéX8Š0PhÓ?<BS>æLQ
Kann man schon sagen ob und wann TLS möglich sein wird?
Und wenn ja, welche Version 1.2 oder 1.3?
Oder habe ich etwas übersehen?
Ist mein erster Kontakt mit MQTT.
@paresy: In der Doku zu MQTT kommt unter „unterstützte Hardware“ ModBus! Da stimmt der Link nicht.
Gruß Isi
Danke. Werden den Link korrigieren.
ETA für TLS kann ich dir leider nicht geben. Es ist aber auf jeden Fall geplant.
paresy
I habe eine frage.
Im symcon habe ich dese MQTT module laufen. Am PLC habe ich ein MQTT host welcher ein heartbeat (jeder 5 sec) gibt und auf pressen einer input also das via ein nahrichte via MQTT sendet.
Nun entfang ich ein symcon das hearthbeat ohne probleme. Abere andere nahrichten kommen nicht an. Ich weiss das die nicht entfangen werden da im PLC die extra nahrichten gespechert bleiben bis ich mein Mosquitto Broker actievier.
Ich hab es geprobiert via das kofigurator, welcher das heartbeat entfangt. Aber auch via direct via ein MQTT gerate mit das richtige topic aber auch mit # wildcards, sogahr nur das # functioniert nicht.
Hat jemand einen idee was ich flasch mache?
Hi,
der MQTT-Server hat bei mir (vermutlich wegen eines Portscans) gestern Abend die Arbeit verweigert. Ein Client konnte sich nicht mehr mit Port 1024 verbinden. Reaktivieren des Servers hat es behoben. Kann man irgendwie prüfen ob der Server noch Anfragen entgegen nimmt und dann darauf reagieren?
Ralf
Kannst du das Problem nachstellen? Ich würde gerne das „Problem“ lösen - denn keine Anfrage sollte den Server so aus dem Tritt bringen können.
paresy
Hi,
werde ich heute Abend mal versuchen. Ich habe es mehrfach versucht konnte es aber bisher nicht reproduzieren.
Dies:
21.01.2020 19:41:20 | 42039 | MESSAGE | Server Socket | Eingehende Verbindung…
21.01.2020 19:41:20 | 42039 | ERROR | Server Socket | remote_endpoint: Transport endpoint is not connected
habe ich dazu im Symcon-Log gefunden. 42039 ist MQTT Server IO. Bei Zigbee2MQTT 1.8 war die Verbindung schon um 18:42 abgebrochen.
info 2020-01-21 18:40:28: MQTT publish: topic ‚zigbee2mqtt/0x00158d000313ae46‘, payload ‚{„battery“:91,„voltage“:2985,„linkquality“:47,„angle_x“:2,„angle_y“:-1,„angle_z“:87,„angle_x_absolute“:88,„angle_y_absolute“:91,„angle“:65}‘
error 2020-01-21 18:42:34: Not connected to MQTT server!
error 2020-01-21 18:42:44: Not connected to MQTT server!
error 2020-01-21 18:42:54: Not connected to MQTT server!
error 2020-01-21 18:43:02: Not connected to MQTT server!
error 2020-01-21 18:43:02: Cannot send message: topic: ‚zigbee2mqtt/0x00158d00032b7a2e‘, payload: '{„battery“:100,„voltage“:3025,„contact“:true,„linkquality“:23}
Wo kann ich noch schau was es gewesen sein könnte?
Ralf
Moin,
MQTT-Server ist Gestern wieder ausgefallen. Ich habe wieder mein Netzwerk hauptsächlich mit nmap gescant. Natürlich kann man den Fehler nicht auf Zuruf reproduzieren:-( Ich habe es eben wieder mehrfach versucht.
Ralf
Hallo @ipsymcon,
ich habe jetzt diesen Thread zum grössten Teil gelesen und bin froh das MQTT nun nativ unterstützt wird!
Das es nun auch einen integrieren Broker gibt, ist für viele Leute bestimmt eine super Sache, aber ich verstehe nicht, warum es (anscheinend) keine Möglichkeit gibt einen externen Broker zu nutzen? Ist das noch auf der Roadmap?
Gruss, Michael
Hallo Michael,
schau mal im Modul Store, dort habe ich einen MQTT Client veröffentlicht.
Grüße,
Kai
Hallo,
ich habe täglich weit mehr als 100-200 Warnmeldungen im Status
31.01.2020, 18:51:21 | Server Socket | Fehler beim Lesen: Eine vorhandene Verbindung wurde vom Remotehost geschlossen.
Dump vom MQTT Server Socket:
TXT: 31.01.2020, 18:51:20 | RECEIVED [192.168.99.26:21054] | 10<NUL>*shellies/shellyplug-s-7AE692/relay/0/power1.6411<NUL>+shellies/shellyplug-s-7AE692/relay/0/energy17391(<NUL>$shellies/shellyplug-s-7AE692/relay/0on1/<NUL>(shellies/shellyplug-s-7AE692/temperature35.9511<NUL>*shellies/shellyplug-s-7AE692/temperature_f96.711/<NUL>,shellies/shellyplug-s-7AE692/overtemperature0
HEX: 31.01.2020, 18:51:20 | RECEIVED [192.168.99.26:21054] | 31 30 00 2A 73 68 65 6C 6C 69 65 73 2F 73 68 65 6C 6C 79 70 6C 75 67 2D 73 2D 37 41 45 36 39 32 2F 72 65 6C 61 79 2F 30 2F 70 6F 77 65 72 31 2E 36 34 31 31 00 2B 73 68 65 6C 6C 69 65 73 2F 73 68 65 6C 6C 79 70 6C 75 67 2D 73 2D 37 41 45 36 39 32 2F 72 65 6C 61 79 2F 30 2F 65 6E 65 72 67 79 31 37 33 39 31 28 00 24 73 68 65 6C 6C 69 65 73 2F 73 68 65 6C 6C 79 70 6C 75 67 2D 73 2D 37 41 45 36 39 32 2F 72 65 6C 61 79 2F 30 6F 6E 31 2F 00 28 73 68 65 6C 6C 69 65 73 2F 73 68 65 6C 6C 79 70 6C 75 67 2D 73 2D 37 41 45 36 39 32 2F 74 65 6D 70 65 72 61 74 75 72 65 33 35 2E 39 35 31 31 00 2A 73 68 65 6C 6C 69 65 73 2F 73 68 65 6C 6C 79 70 6C 75 67 2D 73 2D 37 41 45 36 39 32 2F 74 65 6D 70 65 72 61 74 75 72 65 5F 66 39 36 2E 37 31 31 2F 00 2C 73 68 65 6C 6C 69 65 73 2F 73 68 65 6C 6C 79 70 6C 75 67 2D 73 2D 37 41 45 36 39 32 2F 6F 76 65 72 74 65 6D 70 65 72 61 74 75 72 65 30
TXT: 31.01.2020, 18:51:21 | RECEIVED [192.168.99.21:6481] | 1$<NUL><US>shellies/shelly1-9419BF/relay/0off1"<NUL><US>shellies/shelly1-9419BF/input/01
HEX: 31.01.2020, 18:51:21 | RECEIVED [192.168.99.21:6481] | 31 24 00 1F 73 68 65 6C 6C 69 65 73 2F 73 68 65 6C 6C 79 31 2D 39 34 31 39 42 46 2F 72 65 6C 61 79 2F 30 6F 66 66 31 22 00 1F 73 68 65 6C 6C 69 65 73 2F 73 68 65 6C 6C 79 31 2D 39 34 31 39 42 46 2F 69 6E 70 75 74 2F 30 31
TXT: 31.01.2020, 18:51:22 | RECEIVED [192.168.99.17:58028] | <DLE>T<NUL><EOT>MQTT<EOT>î<NUL><RS><NUL><VT>DVES_134D32<NUL><FS>tele/sonoff-shelly2-007T/LWT<NUL><BEL>Offline<NUL><HT>DVES_USER<NUL><HT>DVES_PASS
HEX: 31.01.2020, 18:51:22 | RECEIVED [192.168.99.17:58028] | 10 54 00 04 4D 51 54 54 04 EE 00 1E 00 0B 44 56 45 53 5F 31 33 34 44 33 32 00 1C 74 65 6C 65 2F 73 6F 6E 6F 66 66 2D 73 68 65 6C 6C 79 32 2D 30 30 37 54 2F 4C 57 54 00 07 4F 66 66 6C 69 6E 65 00 09 44 56 45 53 5F 55 53 45 52 00 09 44 56 45 53 5F 50 41 53 53
TXT: 31.01.2020, 18:51:22 | TRANSMIT [192.168.99.17:58028] | <STX><NUL><NUL>
HEX: 31.01.2020, 18:51:22 | TRANSMIT [192.168.99.17:58028] | 20 02 00 00
Seiht irgendwie nach einer Meldung vom Shelly aus, kann jemand damit was anfangen?
Gruß
Achim
Hallo,
und es ist in den letzten Stunden wieder passiert. Ich habe wieder diverse Portscans nmap und dem Modul IPS2Lan, auch auf mein IPS-System, gemacht und Zigbee2MQTT meldete keine Verbindung zum MQTT-Server.
Ich habe für die IO-Instanz mal die Debug-Datei aktiviert vielleicht liefert die das nächste Mal mehr Infos.
Ralf
Ich steige mit den Shellys in das Thema MQTT ein.
MQTT auf dem Shelly Plug S aktiviert.
MQTT Server und Configurator in Symcon installiert und konfiguriert. Die Werte kommen im MQTT Server Debug auch an und ich sehe sie im Verzeichnisbaum. Aber wie ich schalten kann, da komme ich nicht hinter.
Die Werte kommen ja default alle als String an. Für die numerischen Werte habe ich nun Float wegen Nachkomma gewählt, aber bei der Schaltvariable will er Boolsche Variablen nicht, weil er die nicht konvertieren kann.
Aber String kann ich ja nicht Richtung Shelly zurück schreiben. Also das macht keinen Sinn auch wenn er das macht. Es passiert zu mindest nichts.
Ich würde mich über Hilfe freuen.
VG
Sven
Viel Spaß alles selber zu realisieren 
Oder nimm gleich das Modul von Kai.
Michael
Danke für die schnelle Antwort.
Das Modul findet mein Shelly Plug S leider nicht. Ich dachte, dass das Modul evtl. nur supported Devices anzeigt.
VG
Sven
Dann liefer dort Kai entsprechende Infos, dann kann er es bestimmt umsetzen.
Michael
