Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[mickym]

@mike-hellracer sagte in iobroker, MQTT und Shelly - Was geht wie?:

shelly WallDisplay

Ok ich habe zu dem Gerät nichts direkt gefunden, der RPC Aufruf - da muss man die Methode und die Parameter wissen.

Im Allgemeinen schreibst Du in den RPC Datenpunkt folgendes Objekt:

{"id":123, "src":"user_1", "method":"Switch.Set", "params":{"id":0,"on":true}}

Die id und src - kannst Du frei wählen, ob Switch.Set richtig ist, weiß ich nicht als parameter kannst dann das Objekt {"target_C":20} schreiben.

Unter user_1 solltest Du dann ggf. einen RPC Antwort bekommen.

[Mike Hellracer]

@mickym
Hi, leider funktioniert das nicht.
Habe jetzt auch mal die Method Switch.SetConfig versucht aber das hat auch nicht funktioniert.
Vlt hast du noch eine. Idee?
Die 3 folgenden habe ich versucht.

Spoiler

{"id":123, "src":"user_1", "method":"Switch.Set", "params":{"id":0,"target_C":20}}

{"id":123, "src":"user_1", "method":"Switch.SetConfig", "params":{"id":0,"target_C":20}}

{"id":123, "src":"user_1", "method":"Switch.SetConfig", "params":{"id":0, "config": {"target_C":20}}}

[mickym]

@mike-hellracer Also ich denke eher die 1. Methode - einmal mit und ohne Id versuchen und wirklich den rpc Datenpunkt direkt unter dem Shelly anlegen - das ist das Wichtigste.
Wenn du keine topic user_1 hast, dann hat er gar nichts bekommen. Zeig mal den mqtt Baum unter dem Shelly.

[Mike Hellracer]

@mickym
hi,
ich habe jetzt eine Antwort vom Shelly Support, damit bekomme ich es zwar direkt im DP rpc mit String und JSON hin

als String

Spoiler

{'id':123, 'src':'user_1', 'method': 'Thermostat.SetConfig','params': {'id': 0, 'config': {'enable':true, 'target_C': 15}}}

als JSON

Spoiler

{
  "id": 123,
  "src": "user_1",
  "method": "Thermostat.SetConfig",
  "params": {
    "id": 0,
    "config": {
      "enable": true,
      "target_C": 15
    }
  }
}

, aber nicht mit write aus dem Alias

Spoiler

"write": "JSON.stringify({'id':123, 'src':'user_1','method': 'Thermostat.SetConfig', 'params': {'id': 0, 'config': {'enable':true, 'target_C': 15}}})"

[mickym]

@mike-hellracer lass das write Zeug weg. Du kannst das doch direkt in die Konvertierungsfunktion der Schreibfunktion schreiben,

Da kopierst dann das rein:

JSON.stringify({"id":123, "src":"user_1", "method": "Thermostat.SetConfig","params": {"id": 0, "config": {"enable":true, "target_C": val}}})

Das musst Du in den RPC topic direkt unter dem Gerät reinschreiben.

[Mike Hellracer]

@mickym
Du hattest recht mit der Konventierungsfunktion hat es funktioniert.
Die hat die " mit \ entwertet und damit ging es dann. Das ' funktioniert scheinbar nicht durchgängig. Danke für den Tip. Im Laufe der Jahre wird man blind für die neuen Erleichterungen.
Eine Frage noch. Habe überlegt alle Sonoff und shelly ca 150 und 60 BLE in den mqtt zu überführen. Gibt es da eine Beschrenkung? Und laufen die BLE überhaupt mit dem MQTT Adapter?
Und wenn ja muss ich irgendwas machen oder melden die sich einfach wie im Shelly Adapter?

[mickym]

@mike-hellracer Ich mache alles was mqtt spricht, direkt mit mqtt und meide alle Adapter, die hier nur mqtt Nachrichten interpretieren. BLE weiß ich nicht, aber grundsätzlich geht alles was mqtt spricht. Soweit ich weiß kommunizieren die BLE Geräte aber über ein Gateway, dass dann die WLAN Kommunikation übernimmt.

Jedenfalls solltes es gehen: https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/BLE
Ich nutze persönlich aber keine Gen2 Geräte, sondern habe nur Shellys der Gen1. Man muss ja nicht alles umziehen.

Man braucht halt auch bei reinem mqtt nicht jedesmal einen eigenen Netzwerkport.

Ich nutze allerdings mosquitto als mqtt Broker und betreibe den mqtt Server/Client Adapter als Client, da es einige Komplikationen mit dem mqtt Adapter gab.

Du musst ja nicht alles umziehen, Du kannst ja über unterschiedliche Ports Zug um Zug umstellen, wenn Du willst.

[Mike Hellracer]

@mickym
Hi,eine Frage zu Konvertierung habe ich noch.
Gibt es irgendwie die Möglichkeit die für einzelne Zeichen zu deaktivieren?
Ich möchte gerne \n für einen Zeilenumbruch haben. Das wird dann natürlich nach \n konvertiert.

[mickym]

Ehrlich gesagt, weiss ich nicht was Du meinst und ich kann Dir auch nicht sagen, ob was geht. Grundsätzlich kannst Du alles JS Funktionen nutzen. Und ein JSON ist ein Objekt, da fummelt man nicht mit Stringfunktionen rum.

[mickym]

@mickym sagte in iobroker, MQTT und Shelly - Was geht wie?:

Ehrlich gesagt, weiss ich nicht was Du meinst und ich kann Dir auch nicht sagen, ob was geht. Grundsätzlich kannst Du alles JS Funktionen nutzen. Und ein JSON ist ein Objekt, da fummelt man nicht mit Stringfunktionen rum.

Für komplexere Formatierungen, solltest Du lieber Deine Logikmaschine verwenden.

[Mike Hellracer]

@mickym
Sorry, vlt ist es nicht ganz klar geworden.
Die Konvertierungsfunktion übernimmt die Syntax in JSON für das Telegram.
In den DP übergebe ich dann den Text / String der gesendet werden soll.
Die Formatierung für telegram sieht für eine neue Zeile ein \n im Text vor.
Also "Zeile 1 \n Zeile 2"
Wenn ich das als Val so übergebe macht die Konvertierung "Zeile 1 \n Zeile 2" daraus und versendet das.

[mickym]

@mike-hellracer Damit müsste es gehen:

val.replaceAll("\n","\\n")

Das macht aus einem mehrzeiligen Text

in dem Alias

[Laser]

Habe einen Shelly 2.5. mqtt eingerichtet. Jetzt möchte ich in einem Alias mittels Konvertierungsfunktion den Zustand des Relais beschreiben. Ich finde aber nichts, wo ich da extrahieren könnte.
JSON.parse(val).ip funktioniert beispielsweise, nützt mir natürlich wenig.

[mickym]

@laser Wenn Du einen 2.5 Shelly mit Standard mqtt hast, dann hast Du für jedes Relais einen Unterordner unter relay.

Dort erstellst Du einen Datenpunkt oder topic command und beschreibst diesen mit on oder off.

Der Ordner 1 oder 0 gibt den Zustand wieder, der command Datenpunkt darunter schaltet.

Also GRÜN - Status lesen
ROT - Relais schalten/schreiben

[Laser]

@mickym also komplett ohne Alias und Konvertierungsfunktion. Direkt in den mqtt Datenpunkten. Der DP "command" war schon vorhanden. "on" und "off" heißen die Kommandos also. Es funktioniert! Danke!

[mickym]

@laser Klar geht das direkt ohne Alias - man kann aber auch einen Alias erstellen und das dann in einen Datenpunkt verpacken und dann mit "true" oder "false" schalten, wenn man das unbedingt will. Dann hat man keine 2 Datenpunkte.

So kannst Du das dann verbergen:

[Laser]

@mickym ich hatte versucht, im Alias irgendein "JSON" zu extrahieren und zu beschreiben. Konnte aber kein JSON finden, wo ich etwas extrahieren könnte.
hat sich jetzt überschnitten, probiere ich auch aus!

[mickym]

@laser sagte in iobroker, MQTT und Shelly - Was geht wie?:

@mickym ich hatte versucht, im Alias irgendein "JSON" zu extrahieren und zu beschreiben. Konnte aber kein JSON finden, wo ich etwas extrahieren könnte.

Das hat auch nichts mit JSON zu tun. - Ich habe Dir unten einen Screenshot gemacht wie Du mit einem Alias, sowohl den Ordnerstatus liest, also auch mit dem command Datenpunkt schreibst . Das ganze dann auch noch mit einem Boolean auf "true" = "on" und "false"= "off" gedreht.

Beim Lesen gehst dann auf den Ordner (bei Dir halt entsprechender Pfad):
Alias read state

mqtt.1.shellies.schalter.bad.licht_abzug.relay.1

Beim Schreiben dann auf den command Datenpunkt:
Alias write state

mqtt.1.shellies.schalter.bad.licht_abzug.relay.1.command

Als Konvertierungsfunktion zum Übersetzen von "on" und "off" nach "true" und "false" nimmst Du zum Lesen:

val === 'on' ? true : false

und zum Schreiben:

val ? 'on' : 'off'

Dann kannst Du in dem Alias mit einem Schalter lesen und scheiben:

(immer unbestätigt! - also nie den Haken rein machen)

Im Standard-Mqtt müssen Kommando und Status immer 2 verschiedene Datenpunkte sein, da mqtt kein ACK-Flag kennt und es ja sonst eine Endlosschleife geben würde.

[Laser]

@mickym Das muß ich durchprobieren. (funktioniert bei mir noch nicht). Es geht dann praktisch über einen Alias auf die schon bestehenden mqtt Datenpunkte. Nicht über ein zu extrahierendes Protokoll.

[mickym]

@laser Ja ein Alias ist immer ein Datenpunkt, der auf bestehende von Adaptern erstellten Datenpunkten aufsetzt, damit Du quasi ein einheitliches Schema für Dich erstellen kannst. So hat ein Shelly andere Datenpunkte, als wenn Du über Tasmota schaltest.
Damit Du aber später in deiner Logikmaschine nicht dauernd unterschiedliche Syntax verwenden musst, kann man die Datenpunkte vereinheitlichen.

Nein hat mit einem Protokoll nichts zu tun.

Aber nehmen wir mal an Du hättest einen Shelly Dimmer (ich hab nur 1. Generation Shellies), so kannst Du mit einem Objekt bzw. JSON String gleichzeitig einschalten und einen Dimmwert einstellen (schreiben):

hier in diesem Beispiel auf 15%.

Zum Lesen extrahierst Du dir aus dem Objekt status im mqtt die brightness Eigenschaft zum Lesen

Diese JSONs sind halt super praktisch, weil Du quasi über Systemgrenzen in einen String durch Objekte verschiedene Eigenschaften und Datentypen übertragen kannst.

Deswegen bin ich auch kein Befürworter alles auseinanderzufieseln was zusammengehört, sondern nur bei Bedarf.