@da_woody Da es sich um Shelly's der 2. Generation handelt, funktionieren die Befehle scheinbar nicht. Deine Anleitung funktioniert nur, wenn ich einen Shelly der 1. Generation schalten will (z.B. Plug S). Ich bräuchte einen RPC-Befehl für die 2. Generation bitte. Komme mit der API-Beschreibung nicht wirklich klar.
Danke trotzdem

@great-sun ist alles nicht wirklich zielführend für mich. Weiß denn niemand die Syntax zum direkten schalten eines anderen Shellys?

So, habs bisher nicht hinbekommen, damit der Shelly i4 über eine Action den Plus 1 direkt schaltet. Ich habs erstmal mit einem Skript gelöst, wo ich das Event von input_0 auswerte und den Switch toggle.
Ist dann halt blöd, wenn der iobroker mal ausfallen sollte oder nicht erreichbar ist. Ausserdem müsste ich für jeden input und jeden einfach-, doppel-, dreifach-, long-push ein eigenes Skript anlegen?? Kann ja nicht die Lösung sein!

Wenn einer ne Lösung hat, wie ich es im i4 direkt hinbekomme, dann her damit

@dieckfr danke für die Antwort.
Ich habe den Link, den ich gepostet habe, schon im Browser probiert und das Relay schaltet auch. Ich weiß nur nicht, wie ich das mit dem i4 auslöse, wenn ich den angeschlossenen Schalter drücke. Ich muß ja für den Input am i4 eine Action hinterlegen. Wenn ich den gleichen Link verwende, der im Browser funktioniert, passiert gar nichts. Spielt die Authentifizierung eine Rolle?

Hallo, ich komme mit einer wahrscheinlich einfachen Sache nicht weiter.
Es geht um einen Shelly Plus i4, an dem zwei 2-fach Wall-Switches angeschlossen sind. Als Einstieg würde ich gerne mit einem Tastendruck (Input_0) einen Shelly Plus 1 schalten, damit ich das Prinzip mit den RPC-Befehlen verstehe. Aber selbst daran scheitere ich.
Ich hab im i4 den Input_0 als Button eingestellt und ein Action angelegt. Execute when: Button push und Then Do: http://IP_ShellyPlus1/rpc/Switch.Toggle?id=0.
Wenn ich nun den Button drücke, passiert nix.

Wie muss ich denn vorgehen? Hat da einer nen Tipp?

Hallo,
wollte nur kurz Rückmeldung geben. Hab ja 9 Warmwasser-Zähler von der Zählerplattform eingebaut und frag diese mit dem IMST iM871A USB-Stick ab. In den Einstellungen hab ich Mode C Typ A mit 57600 Baud gewählt. Das funktioniert wunderbar. Die AES-Schlüssel hab ich nach kurzer Anfrage bei Zählerplattform nach 1-2 Tagen erhalten.
Einzig die Zählerstände kommen wohl als String an, da zB SourceAnalytix keine Berechnung durchführen kann.

Input value for wireless-mbus.0.DWZ-xxxxxxxx.data.2-0-VIF_VOLUME, type = string but should be a number, cannot handle calculation

Vielleicht hat ja einer nen Tipp, wie ich das gelöst bekomme. Eine Anfrage hab ich schon in diesem Thread gestellt.

@manfredh1 kannst du mir bitte kurz erläutern, wie ich das genau mache? Wenn ich unter Objekte beim Zählerstand auf das Zahnrad tippe und die Einstellungen zu SA mache, habe ich schon Pseudonyme/Aliase eingegeben. Das ist wohl aber nicht das Richtige???

Erstmal: Bin mir nicht sicher, ob das ein Problem von SA ist oder vom wM-Bus-Adapter bzw. den Geräten, die ich abfrage.

Ich hab mir 9 neue Wohnungswasserzähler von "Zählerplattform" eingebaut (Hersteller ist wohl Lorenz), die per wM-Bus die Daten an einen USB-Stick IMST iM871A übermitteln. Die Werte kommen alle und ich kann sie im VIS einbinden/anzeigen. Nun möchte ich gerne die Zählerstände monatlich mit SourceAnalytix speichern. Jedoch bekomme ich Fehlermeldungen für jeden Zähler im Protokoll:

Input value for wireless-mbus.0.DWZ-xxxxxxxx.data.2-0-VIF_VOLUME, type = string but should be a number, cannot handle calculation

Gibt es da schon einen sicheren Workaround, wie ich das umgehen/lösen kann? Es gibt ja schon einen Beitrag mit der Fehlermeldung, bin mir aber nicht sicher ob das die Lösung ist bzw wie ich das genau mache.

@lvogt Habe das Log leider nicht wirklich dahingehend verstanden, das ein AES unbedingt benötigt wird. Hätte ich mal übersetzen lassen sollen.
Bei zählerplattform habe ich nachgefragt, die schicken mir einen AES-Key passend zur Seriennummer des Zählers. Wird wohl erst nächste Woche passieren.
Dann bin ich mal guter Dinge, das die Daten im iobroker über den Adapter korrekt ankommen.
Vielen Dank für den Adapter und die großartige Arbeit. Das hilft meinem Vorhaben deutlich.
Schönes WE

Hallo,
ich hab nun den ganzen Thread durchgelesen und mir endlich eine wM-Bus-Stick geholt (WiMOD-iM871A). Einen Wasserzähler von der Zählerplattform kam gestern.
Den USB-Stick hat meine Debian iobroker Installation problemlos erkannt, Adapter-Version ist die letzte von github 0.8.7. Anschluß ist /dev/ttyUSB6 und ein Symlink ist erstellt, funktioniert auch. Der Adapter wird grün, allerdings kommen scheinbar keine Daten vom Zähler bzw. können nicht geparst werden. Der Zähler ist zwar nicht eingebaut, aber die Funkschnittstelle ist wohl eingeschalten. Ich hab keinen AES-Key bekommen und nun bei Zählerplattform angefragt, ob ich einen benötige. Der Zähler funkt nach OMS 3.0.1 C1/T1 (vielleicht auch nach 4.0.2 oder neuer).
Hat jemand diese Konstellation schon am Laufen und kann mir da auf die Sprünge helfen?

Im Log steht folgendes:

2023-01-13 12:10:00.893 - debug: wireless-mbus.0 (4174326) Redis Objects: Use Redis connection: 0.0.0.0:9001
2023-01-13 12:10:00.969 - debug: wireless-mbus.0 (4174326) Objects client ready ... initialize now
2023-01-13 12:10:01.015 - debug: wireless-mbus.0 (4174326) Objects create System PubSub Client
2023-01-13 12:10:01.016 - debug: wireless-mbus.0 (4174326) Objects create User PubSub Client
2023-01-13 12:10:01.148 - debug: wireless-mbus.0 (4174326) Objects client initialize lua scripts
2023-01-13 12:10:01.174 - debug: wireless-mbus.0 (4174326) Objects connected to redis: 0.0.0.0:9001
2023-01-13 12:10:01.253 - debug: wireless-mbus.0 (4174326) Redis States: Use Redis connection: 0.0.0.0:9000
2023-01-13 12:10:01.402 - debug: wireless-mbus.0 (4174326) States create System PubSub Client
2023-01-13 12:10:01.404 - debug: wireless-mbus.0 (4174326) States create User PubSub Client
2023-01-13 12:10:01.537 - debug: wireless-mbus.0 (4174326) States connected to redis: 0.0.0.0:9000
2023-01-13 12:10:02.546 - info: wireless-mbus.0 (4174326) starting. Version 0.8.7 (non-npm: lvogt/ioBroker.wireless-mbus#43caf409549446307f40255c66e1f58a43a9b1a1) in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v16.19.0, js-controller: 4.0.24
2023-01-13 12:10:02.694 - debug: wireless-mbus.0 (4174326) Created device of type: IMST iM871A
2023-01-13 12:10:02.701 - debug: wireless-mbus.0 (4174326) IMST: TX: a581030600030006080005ef
2023-01-13 12:10:02.712 - debug: wireless-mbus.0 (4174326) IMST: RX: a58104009cf7
2023-01-13 12:10:02.715 - info: wireless-mbus.0 (4174326) IMST: Receiver set to CA-MODE
2023-01-13 12:10:02.729 - debug: wireless-mbus.0 (4174326) connected set to true
2023-01-13 12:10:02.775 - debug: wireless-mbus.0 (4174326) connected set to true
2023-01-13 12:10:02.843 - debug: wireless-mbus.0 (4174326) IMST: RX: a582032e44fa125545011900067a3400202595d3503a812e74041b549c1582fcb11c2362d314283194422bd014d0afd1301be802
2023-01-13 12:10:02.844 - debug: wireless-mbus.0 (4174326) IMST: Message received: a582032e44fa125545011900067a3400202595d3503a812e74041b549c1582fcb11c2362d314283194422bd014d0afd1301be802
2023-01-13 12:10:02.846 - debug: wireless-mbus.0 (4174326) 2e44fa125545011900067a3400202595d3503a812e74041b549c1582fcb11c2362d314283194422bd014d0afd1301b
2023-01-13 12:10:02.848 - debug: wireless-mbus.0 (4174326) Short header
2023-01-13 12:10:02.850 - error: wireless-mbus.0 (4174326) encrypted message and no aeskey provided
2023-01-13 12:10:02.851 - debug: wireless-mbus.0 (4174326) Parser failed to parse telegram from device DWZ-19014555

Vielen Dank schon mal im Vorraus