MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054

[jonofe]

Hallo @janofe

Keine Ahnung wer das ist

kannst Du noch einen prefix in den Subscribe Server einbauen?

aber mit der Version 0.7 deas Subscribe Server LBS sollte dies nun möglich sein.

[hartwigm]

Sorry André für den Namenssalat! und danke für das Prefix.

Irgendwie geht das aber nicht!

Ich hatte denen 0.5 mal mit den notwendigen Werten hardcodiert und dann sieht mein Logfile etwas anders aus.

LBS19001052 [v0.7]: ================ ARRAY/OBJECT START ================
2019-10-21 09:30:41	964924	47425	debug	LBS19001052 [v0.7]: {"start":{"ip":"192.168.133.49","port":"1883","use r":null,"pwd":null,"plain":null,"regexp":null,"qos ":"1","retain":"0","sub":["AS43\/from_io\/edomi\/set\/#","AS43\/from_io\/edomi\/get\/#"],"tls":"0","caPath":"\/etc\/ssl\/certs\/ca-bundle.crt","prefix":"AS43\/from_io\/"}}
2019-10-21 09:30:41	965132	47425	debug	LBS19001052 [v0.7]: ================ ARRAY/OBJECT END ================
2019-10-21 09:30:41	967534	47425	debug	LBS19001052 [v0.7]: MSGQID used: 723541680 (17256)
2019-10-21 09:30:41	969173	47425	debug	LBS19001052 [v0.7]: LBS MQTT Subscribe Server ended (17256)
2019-10-21 09:30:42	017738	50306	debug	EXE19001052 [v0.7]: MSGQID: 723541680 (17256)
2019-10-21 09:30:42	019660	50306	debug	EXE19001052 [v0.7]: Command received by daemon: start (17256)
2019-10-21 09:30:42	020579	50306	debug	EXE19001052 [v0.7]: Starting MQTT Subscribe Server daemon (17256)
2019-10-21 09:30:42	025993	50306	debug	EXE19001052 [v0.7]: Setting LWT: (17256)
2019-10-21 09:30:42	026146	50306	debug	EXE19001052 [v0.7]: ================ ARRAY/OBJECT START ================
2019-10-21 09:30:42	026243	50306	debug	EXE19001052 [v0.7]: ["AS43\/from_io\/edomi\/offline","192.168.135.42|2019-10-21_09:30:42",2,0]
2019-10-21 09:30:42	026328	50306	debug	EXE19001052 [v0.7]: ================ ARRAY/OBJECT END ================
2019-10-21 09:30:42	027100	50306	debug	EXE19001052 [v0.7]: Resubscribing topics (17256)
2019-10-21 09:30:42	027199	50306	debug	EXE19001052 [v0.7]: ================ ARRAY/OBJECT START ================
2019-10-21 09:30:42	027270	50306	debug	EXE19001052 [v0.7]: {"AS43\/from_io\/edomi\/set\/#":"1","AS43\/from_io\/edomi\/get\/#":"1"}
2019-10-21 09:30:42	027332	50306	debug	EXE19001052 [v0.7]: ================ ARRAY/OBJECT END ================
2019-10-21 09:30:42	028043	50306	debug	EXE19001052 [v0.7]: Resubscribing topic: AS43/from_io/edomi/set/# with QoS: 1 (17256)
2019-10-21 09:30:42	028768	50306	debug	EXE19001052 [v0.7]: Resubscribing topic: AS43/from_io/edomi/get/# with QoS: 1 (17256)

und die funktionierende

LBS19001052 [v0.5]: ================ ARRAY/OBJECT START ================
2019-10-21 09:24:51	217309	47425	debug	LBS19001052 [v0.5]: {"start":{"ip":"192.168.133.49","port":"1883","use r":null,"pwd":null,"plain":null,"regexp":null,"qos ":"1","retain":"0","sub":["\/AS43\/from_io\/edomi\/set\/#","\/AS43\/from_io\/edomi\/get\/#"],"tls":"0","caPath":"\/etc\/ssl\/certs\/ca-bundle.crt"}}
2019-10-21 09:24:51	217436	47425	debug	LBS19001052 [v0.5]: ================ ARRAY/OBJECT END ================
2019-10-21 09:24:51	219096	47425	debug	LBS19001052 [v0.5]: MSGQID used: 1439295845 (17337)
2019-10-21 09:24:51	220309	47425	debug	LBS19001052 [v0.5]: LBS MQTT Subscribe Server ended (17337)
2019-10-21 09:24:51	287543	47646	debug	LBS19001052 [v0.5]: MSGQID: 1439295845 (17337)
2019-10-21 09:24:51	289391	47646	debug	LBS19001052 [v0.5]: Command received by daemon: start (17337)
2019-10-21 09:24:51	291547	47646	debug	LBS19001052 [v0.5]: Starting MQTT Subscribe Server daemon (17337)
2019-10-21 09:24:51	298158	47646	debug	LBS19001052 [v0.5]: Setting LWT: (17337)
2019-10-21 09:24:51	298300	47646	debug	LBS19001052 [v0.5]: ================ ARRAY/OBJECT START ================
2019-10-21 09:24:51	298382	47646	debug	LBS19001052 [v0.5]: ["edomi\/offline","192.168.135.42|2019-10-21_09:24:51",2,0]
2019-10-21 09:24:51	298439	47646	debug	LBS19001052 [v0.5]: ================ ARRAY/OBJECT END ================
2019-10-21 09:24:51	300211	47646	debug	LBS19001052 [v0.5]: Resubscribing topics (17337)
2019-10-21 09:24:51	300298	47646	debug	LBS19001052 [v0.5]: ================ ARRAY/OBJECT START ================
2019-10-21 09:24:51	300359	47646	debug	LBS19001052 [v0.5]: {"\/AS43\/from_io\/edomi\/set\/#":"1","\/AS43\/from_io\/edomi\/get\/#":"1"}

[jonofe]

Was genau funktioniert nicht?
Benutzt du einen Leading Slash '/'?
das sollte man bei MQTT nicht tun, daher wird der auch entfernt.
Ich habe das bei mir getestet mit "house1' und dann auf house1/edomi/set/knx/1-1-30 gesendet. Funktioniert problemlos.

[hartwigm]

Du hast recht

ohne den leading slash geht es.

Ich kann diesen allerdings nicht so ohne weiteres wegnehmen, da der mqtt Server auch andere Subsysteme versorgt und das dann einen Rattenschwanz nach sich zieht.

[jonofe]

Dann füge mal folgende Zeile zwischen 195 und 196 ein:

$prefix = trim($prefix, "\\");

Danach solltest du mit einem Backslash den Slash escapen können, so dass nur der Backslash entfernt wird, und somit das Prefix mit Slash beginnt. E13 beginnt also so:

\/AS43/from_io/....

Ist allerdings ungetestet. Wenn es funktioniert, dann lade ich das Update hoch.

Und hier noch mal ein paar Best Practices für die, die noch nicht ihre Struktur definiert haben: (Quelle: https://www.hivemq.com/blog/mqtt-ess...est-practices/)

Best practices

Never use a leading forward slash
A leading forward slash is permitted in MQTT. For example, /myhome/groundfloor/livingroom. However, the leading forward slash introduces an unnecessary topic level with a zero character at the front. The zero does not provide any benefit and often leads to confusion.

Never use spaces in a topic
A space is the natural enemy of every programmer. When things are not going the way they should, spaces make it much harder to read and debug topics. As with leading forward slashes, just because something is allowed, doesn’t mean it should be used. UTF-8 has many different white space types, such uncommon characters should be avoided.

Keep the topic short and concise
Each topic is included in every message in which it is used. Make your topics as short and concise as possible. When it comes to small devices, every byte counts and topic length has a big impact.

Use only ASCII characters, avoid non printable characters
Because non-ASCII UTF-8 characters often display incorrectly, it is very difficult to find typos or issues related to the character set. Unless it is absolutely necessary, we recommend avoiding the use of non-ASCII characters in a topic.

Embed a unique identifier or the Client Id into the topic
It can be very helpful to include the unique identifier of the publishing client in the topic. The unique identifier in the topic helps you identify who sent the message. The embedded ID can be used to enforce authorization. Only a client that has the same client ID as the ID in the topic is allowed to publish to that topic. For example, a client with the _client1 ID is allowed to publish to _client1/status, but not permitted to publish to _client2/status.

Don’t subscribe to #
Sometimes, it is necessary to subscribe to all messages that are transferred over the broker. For example, to persist all messages into a database. Do not subscribe to all messages on a broker by using an MQTT client and subscribing to a multi-level wildcard. Frequently, the subscribing client is not able to process the load of messages that results from this method (especially if you have a massive throughput). Our recommendation is to implement an extension in the MQTT broker. For example, with the plugin system of HiveMQ you can hook into the behavior of HiveMQ and add an asynchronous routine to process each incoming message and persist it to a database.

Don’t forget extensibility
Topics are a flexible concept and there is no need to preallocate them in any way. However, both the publisher and the subscriber need to be aware of the topic. It is important to think about how topics can be extended to allow for new features or products. For example, if your smart-home solution adds new sensors, it should be possible to add these to your topic tree without changing the whole topic hierarchy.

Use specific topics, not general ones
When you name topics, don’t use them in the same way as in a queue. Be as specific topics as possible. For example, if you have three sensors in your living room, create topics for _myhome/livingroom/temperature, _myhome/livingroom/brightness and _myhome/livingroom/humidity. Do not send all values over _myhome/livingroom. Use of a single topic for all messages is a anti pattern. Specific naming also makes it possible for you to use other MQTT features such as retained messages. For more on retained messages, see part 8 of the Essentials series.

[Janncsi]

Ich habe mal eine generelle Frage, wie ihr das handhabt in Bezug auf die Sicherheit....

Grundsätzlich empfinde ich die Anbindung von edomi über einen Broker als sehr sicher, da kein direkter Zugriff auf das edomi genommen wird, sondern edomi im Broker mitliest. Wenn der Broker auf einer externen Ressource außerhalb des eigenen Netzwerks liegt und eine gesicherte Verbindung besteht, geht man damit ein besonderes Risiko ein?

Alternativ könnte man ja einen Broker intern aufziehen, dieser verbindet sich mit dem externen Broker und edomi verbindet sich ausschließlich mit dem Internen.

Ich hoffe ihr versteht was ich meine. Mir ist für den Moment noch unklar ob Variante 1 ausreichend sicher ist oder ob lieber ein zweiter Broker aktiviert werden sollte um edomi komplett anonym agieren zu lassen?!

[jonofe]

Wenn ich interne MQTT Quellen habe, die ich in EDOMI verwenden möchte, dann würde ich auf jeden Fall einen internen Broker verwenden, da man ja ansonsten interne Daten zunächst nach extern senden müsste, damit der interne EDOMI Server diese dann wieder bekommt. Externe Broker sollte man nur mit Authentifizierung und TLS Verschlüsselung nutzen.

Grundsätzlich gibt es drei Ebenen der Security bei MQTT:

• Netzwerk/Protokoll => TLS
• Authentifizierung => User/Password | Client-ID | IP-Adressen | Zertifikate
• Autorisierung => wird i.d.R. durch den Broker/Applikation gemacht (für Mosquitto siehe: https://github.com/jpmens/mosquitto-auth-plug)

Zwischen zwei Brokern kan man auch ein Bridge konfigurieren, was dann verhindert, dass EDOMI beispielsweise auf einen externen Broker zugreifen muss. Das kann dann durch einen eigenen Broker (z.B. Mosquitto) passieren, welcher in der DMZ läuft. Habe ich so schon mit Amazon IoT gemacht.

Es ist natürlich immer eine Frage, wie kritisch die Daten sind, welche man per MQTT empfängt. Wenn ich z.B. ein Topic subscribe, welches meine Haustür öffnet, würde ich es nicht von einem externen Broker subscriben wollen. Beim Publish stellt sich dieselbe Frage, nämlich wie kritisch sind die Daten, die ich per MQTT veröffentliche und werden sie eigentlich nur intern benötigt.

Hier noch zwei gute Artikel zum Thema Sicherheit Kommunikation mit MQTT:

Teil1: https://www.heise.de/developer/artik...html?seite=all
Teil 2: https://www.heise.de/developer/artik...html?seite=all

[givemeone]

Hallo Jonofe,
habe heute begonnen, deinen Baustein 19001052 zu nutzen.
Habe dazu auch die neue Version 0.7 installiert.

Prinzipiell scheint es zu funktionieren, jedoch ist mir aufgefallen, dass interne Werte nicht aktualisiert werden.
tmp.jpg

Nach längerer Suche habe ich im Log dieses gefunden:

EXE19001052 [v0.7]: ERROR: Database connection failed (8403)
EXE19001052 [v0.7]: Topic: edomi/set/internal/885 - Payload: 21.60 °C (8403)
EXE19001052 [v0.7]: Stripped topic: edomi/set/internal/885 (8403)

Erst ein Ersetzen im LBS von localhost zu 127.0.0.1 hat dann funktioniert. Im Dockerimage
scheint die Host-Namensauflösung deaktiviert zu sein.
Wäre das durch eine art globales IKO übersteuerbar? Ich denke da zB an ein iKO mit dem namen "globalMySQL"?

sG Joe

[Lapheus]

Hallo Jonofe,
...
Erst ein Ersetzen im LBS von localhost zu 127.0.0.1 hat dann funktioniert. Im Dockerimage
scheint die Host-Namensauflösung deaktiviert zu sein.

Probleme mit localhost (IPv6) und 127.0.0.1 (IPv4) liegen oft mit der Konfiguration von entsprechenden Netzen zusammen.
Ist bei Dir da irgendetwas "wegkonfiguriert"?

[givemeone]

Nein, nicht von mir. Ich nutze das Edomi-Docker, und habe die konfiguration dort nicht extra untersucht, da bisher alles funktioniert hat.
Ich vermute, dass hier in den (mysql-?)Einstellungen auf die Namensauflösung verzichtet wird/wurde (aus performance-gründen?).
Ein Ping auf Localhost hat jedenfalls funktioniert, also kann das system selbst prinzipiell den namen auflösen.

[jonofe]

Wäre das durch eine art globales IKO übersteuerbar?

Ja. Die entsprechende Kostanten gibt es ja bereits in der edomi.ini:

• global_sqlHost
• global_sqlUser
• global_sqlPass

In der Version 0.8 werden diese jetzt auch genutzt.

[givemeone]

Danke, damit gehts perfekt.
Kannst Du das ggf. demnächst auch noch in 19000649 nachziehen?

sG
Joe

[jonofe]

Kannst Du das ggf. demnächst auch noch in 19000649 nachziehen?

Done.

[hartwigm]

jonofe
Nochmals einen Wunsch!

Ich nutze deinen genialen Baustein zur Anbindung von IObroker.

Damit erschließt der Baustein auf einfache Weise die Adapter des iobrokers.

Wenn ich im IObroker z.b. bei einer Prüfung auf Verfügbarkeit eines Geräts edomi/set/internal/ko-id mache, dann kommt auf der Edomi-Seite true oder false an.

Super wäre, wenn ich nun im Baustein noch eine Ersetzung machen könnte.

Also z.B. einen Eingang für 1 mit dem Inhalt true|wahr|an|auf...
und einen Eingang für 0 mit dem Inhalt false|falsch,aus,ab....

Damit könnte der Baustein direkt eine Edomi Logic triggern ohne dass ich das vorher noch durch einen Baustein jagen muss.

[Brick]

Bausteine kosten doch nix.. (außer Platz.. und auch der is gratis)

Gruß Martin