Shelly Blu in FHEM einbinden

[Neeein]

Guten Abend liebe Foristen,


Ich möchte gerne die neuen Shelly Blu Fenster/Türkontakte in FHEM einbinden, aber meine Suche war bis jetzt nicht von Erfolg gekrönt.

Kann mir evtl. Jemand auf die Sprünge helfen?
Vielleicht gibt es das ja bereits als Modul in FHEM. Oder ein Script für die Plus/Pro Shelly's (Gatewayfunktion) die das übernehmen und an FHEM (In einen Dummy) übergeben... das selbst zu programmieren bin ich leider nicht fähig.

Freue mich auf eure konstruktiven Vorschläge und Ideen 😊

LG

[JoWiemann]

Hallo,

da Du Dich ja kundig gemacht hast, das richtige Forum gefunden hast und auch gesucht hast, frage ich mich warum Du das Shelly Modul: https://forum.fhem.de/index.php?topic=118446.0 oder die Shelly MQTT Integration: https://forum.fhem.de/index.php?topic=94060.0 nicht gefunden hast.

Grüße Jörg

[marvin78]

Ich weiß nicht, ob die Bluetooth-Geräte über die genannten Wege eingebunden werden können. Ich gehe nicht davon aus.

[Neeein]

@jowiemann damit bekomme ich, meinem Verständnis nach, die Blu nicht eingebunden.

Wenn man sich das aktuelle Video zu den Shelly Blu Geräten von Haus-automation auf YouTube anschaut(keine Ahnung ob ich den Link posten darf, deshalb lasse ich es) dann verweist er darauf dass es die fw mit MQTT nicht gibt und er ein Script auf den pro/plus Geräten laufen lassen muss, damit die Werte weitergegeben werden.

Da das aber für HA und nicht für Fhem geeignet ist, bringt mich das nicht weiter und so gut coden kann ich nicht um mir das anzupassen 🙂
Grüße

[marvin78]

Ich verstehe auch den Sinn hinter solchen Bluetoothgeräten nicht (es sei denn man will sie NICHT in HA Systeme einbinden). Mein Rat: Autauschen gegen HM, ZWave, Zigbee....

[isy]

Ich denke, neeein hat das Problem korrekt beschrieben.
Nach etwas Lesen bei Shelly kann mal die "Blu" wohl mit der pro/plus Serie über BT koppeln. Oder über einen Bluetooth Gateway Stick.
Darüber werden vermutlich mqtt Messages generiert.

VG Helmut

[Beta-User]

OpenMQTTGateway kennt die wohl...

[Neeein]

Ich habe eine Lösung für mich gefunden. Bestimmt nicht schön, vor allem sehr "einfach", da keine wirklichen Programmierkenntnisse habe, also fühlt euch bitte frei mir eure Vorschläge, Erleichterungen, unnötige Schritte etc. mitzuteilen und das Ding zu optimieren.
Gerne dürft ihr meine Anleitung und meinen Code benutzen und abändern. Ich übernehme dafür keine Haftung.


Ich habe ein 99Utils auf die passenden Werte von der ShellyBlu: Door/Window, Motion und Button geschrieben, die ich aus dem eigentlichen MQTTdevice herauskopiert habe. Diese Werden mit jedem ShellyBlu-Event und für jedes ShellyBlu Device in einen eigenen Dummy geschrieben, der dann für Aktionen etc. weiterverwendet werden kann.


Schritt 1 (einen MQTT Server auf der FHEM Instanz starten (falls noch nicht vorhanden):

Code Auswählen Erweitern

define DEINWUNSCHNAMEFUERDEINENSERVER MQTT2_SERVER 1883 global

Schritt 2:
Ein beliebiges deiner Plus und Pro Devices aussuchen, welches als Gateway für die ShellyBlu arbeiten soll. Die Shelly App öffnen oder die direkte IP im Browser aufrufen.
In den Scriptbereich gehen und das Script aus Github einfügen:
Hier die URL: Code für das Shelly Script
Ich habe das Script ab Zeile 79 genutzt, wo die Versionsnummer zu finden war. "// v.02" war es bei mir.
Bei "});" ist Schluss, die ´´´ gehören nicht auf den Shelly

Jetzt beim gleichen Device im Bereich Netzwerke MQTT aktivieren, Art der Verbindung bei RPC... den Haken machen. Im zweiten Feld weiter unten dann die IP und den MQTT Port deiner FHEM-Instanz eingeben, bei mir war es 192.168.0.2:1883 Passwort und Benutzername habe ich nicht vergeben. Wird bei dir vielleicht anders sein.

-> Schritt 2 wiederholen, bis alle deine Shelly Pros und Plus eingebunden sind die du einbinden möchtest.
Jetzt werden die ShellyBludaten, die die Shellys via Bluetooth empfangen an euren FHEM gesendet und in den (normalerweise automatisch) angelegten MQTT-Devices im Raum MQTT2_Device gespeichert. Der Payload aller ShellyBlu wird jedoch immer im entsprechenden Plus/Pro Device mit abgelegt und mit jeder Aktualisierung irgend eines ShellyBlu sofort mit dessen Werten überschrieben. Deshalb Schritt 3 da ich den aktuellen Stand der ShellyBlu behalten will und später nach den Dummywerten Aktionen auslösen möchte.

Das ist nicht von mir, ich habe keine Rechte daran, also auf eigene Gefahr benutzen!


Schritt 3
In deinem Fhem auf "edit files" gehen und eine "99_Utils" öffnen, welche ist egal.

Dann den alten Code löschen und den neuen Code einfügen und unter anderem Namen speichern. In meinem Fall 99_UtilsShellyBlu.pm

Code Auswählen Erweitern

##############################################
# $Id: 99_UtilsShellyBlu.pm 1932 $
package main;

######## doShellyBlu ###############
#
# Aufruf: doShellyBlu("<device>")

sub doShellyBlu($) {
my ($device) = @_;
my $payload_BTHome_version = ReadingsVal("$device","payload_BTHome_version", 0);
my $payload_address = ReadingsVal("$device","payload_address", 0);
my $payload_battery = ReadingsVal("$device","payload_battery", 0);
my $payload_encryption = ReadingsVal("$device","payload_encryption", 0);
my $payload_illuminance = ReadingsVal("$device","payload_illuminance", 0);
my $payload_pid = ReadingsVal("$device","payload_pid", 0);
my $payload_rotation = ReadingsVal("$device","payload_rotation", 0);
my $payload_rssi = ReadingsVal("$device","payload_rssi", 0);
my $payload_window = ReadingsVal("$device","payload_window", 0);
my$payload_motion = ReadingsVal("$device","payload_motion", 0);
my $payload_temperature = ReadingsVal("$device","payload_temperature", 0);
my $name = ReadingsVal("$device","payload_address",0); $name =~ s/:$//; $name =~ s/://g;
my $deviceDummy = "ShellyBlu".$name;
my $notifyname = "N_doShellyBlu".$device;

    fhem "defmod $deviceDummy dummy;attr $deviceDummy room Shelly;attr $deviceDummy event-on-change-reading .*;";
    fhem "define $notifyname notify $device:payload_.* {doShellyBlu('$device')};attr $notifyname event-on-change-reading .*;";
    fhem "setreading $deviceDummy BTHome_version $payload_BTHome_version";
    fhem "setreading $deviceDummy BTaddress $payload_address";
    fhem "setreading $deviceDummy battery $payload_battery";
    fhem "setreading $deviceDummy encryption $payload_encryption";
    fhem "setreading $deviceDummy illuminance $payload_illuminance";
    fhem "setreading $deviceDummy pid $payload_pid";
    fhem "setreading $deviceDummy rotation $payload_rotation";
    fhem "setreading $deviceDummy rssi $payload_rssi";
    fhem "setreading $deviceDummy WindowDoor $payload_window";
    fhem "setreading $deviceDummy temperature $payload_temperature";
    fhem "setreading $deviceDummy motion $payload_motion";
   
}
Da ich keine "richtigen Shelly Devices" anlegen kann ist es ein Dummy geworden, in den ich die Werte aus dem MQTT Payload der Door/Window ShellyBlu schreibe.

Der Code legt auch ein Notify an, der auf MQTT befehle reagiert und die 99_Utils aufruft um die aktuellen Daten in den Dummy zu schreiben.


Schritt 4:
Den Code einmal initial mit jedem Shelly Plus/Pro Device ausführen.

Code Auswählen Erweitern

{doShellyBlu('MQTT2_shellyXXX')}XXX ist hierbei der Name unter dem das Device im MQTT2_Deviceraum abgelegt ist. Das Scipt legt jetzt alle erforderlichen Dummys etc. insbesondere aber den Notify an, sobald neue ShellyBlu-Werte geliefert werden an.

-> Schritt 4 wiederholen, bis alle Plus und Pro-Devices die du in Schritt zwei ausgewählt hast einmal ausgeführt wurden.


Schritt 5:
Mit dem Dummy arbeiten;

Ich habe mir Beispielsweise eine "Notöffnung für die Terrasse gebaut um das zu testen.

Code Auswählen Erweitern

define doif_Notausgang doif ([ShellyBlub00112233:WindowDoor] eq "1" and [EG.RLWohnzimmerRechts] ne "Hoch") (set EG.RLWohnzimmerRechts on)00112233 steht hierbei für deinen Dummy dessen Werte du nutzen willst, der im Raum Shelly angelegt wurde.
Letzten Endes soll der Rollladen direkt mit Öffnung der entsprechenden Tür aufgehen, wenn er nicht oben ist.
Warum ich hier DOIF und nicht Notify verwendet habe... Ich wollte das auch mal testen...



Wunschliste:
- Eine Pushmitteilung mit pushover, wenn ich das Haus verlasse, aber noch ein oder mehrere Fester/Tür(en) offen steht/stehen. Am besten sollen hier auch gesammelt die jeweiligen Fenster/Türen drin stehen, damit man nicht suchen muss.
- Eine Pushmitteilung, wenn irgendein ShellyBlu einen Batteriestand von unter 10 hat.
- Rollladen "schlitzen" wenn das Fenster auf Kipp gesetzt wird, soll ja Luft rein.


Noch nicht getestet, weil nicht genug hardware:
- Ich habe noch nicht testen können, wie es sich verhält, wenn mehrere Shellys die ShellyBlu Werte empfangen und an FHEM anliefern. Evtl. müsste dann ein Timeout im Dummy gesetzt werden um das zu "entprellen" und Mehrfachauslösungen zu vermeiden.


LG N3331N

[Neeein]

Ich verstehe auch den Sinn hinter solchen Bluetoothgeräten nicht (es sei denn man will sie NICHT in HA Systeme einbinden). Mein Rat: Autauschen gegen HM, ZWave, Zigbee....

Dann kann ich dir für meinen Fall leicht begründen
- Weil ich gerne mit Technik bastel,
- Shelly genial finde
- die Blu-Serie verdammt klein und unaufällig ist
und damit zum Hauptpunkt:

- Muss auch der Regierung gefallen... und das geht nur bei nicht auffallen     <--- dies ist Spaß

[marvin78]

Ja. Sowas, wie eine Regierung habe ich nicht, wir sind gleichberechtigte Partner mit rationalem und differenziertem Denken. Deshalb kann ich es auch nicht nachvollziehen. Ich würde hier keine Kompromisse machen.

[Neeein]

Ja. Sowas, wie eine Regierung habe ich nicht, wir sind gleichberechtigte Partner mit rationalem und differenziertem Denken. Deshalb kann ich es auch nicht nachvollziehen. Ich würde hier keine Kompromisse machen.

Das war auch eher im Spaß gemeint ich finde einfach die Größe richtig gut und habe nichts passenderes für meinen Anwendungsfall gefunden. Das schöne an FHEM ist ja, das irgendwie alles mit irgendwie allem geht.

[DasQ]

Ich verstehe auch den Sinn hinter solchen Bluetoothgeräten nicht (es sei denn man will sie NICHT in HA Systeme einbinden). Mein Rat: Autauschen gegen HM, ZWave, Zigbee....

Für mich der entscheidende Grund ist, Laut Hersteller bis zu 5jahre mit einer CR2032 Batterie

[majestro84]

Hallo,

ich habe es nun wie folgt gelöst.
Schritt 1 und 2 bleiben wie bei Neeein seinem Beitrag.
In Schritt2 habe ich das Script beim MQTT Publish etwas angepasst so das im Topic nun auch die BtMac steht.
Zeile 161

Code Auswählen Erweitern

MQTT.publish(SHELLY_ID + '/' + result.addr + '/events/ble', JSON.stringify(message));

In dem in FHEM dann vorhanden MQTT2_Device habe ich das attr brigderegex gesetzt.

Code Auswählen Erweitern

bridgeRegexp .*mac":"([A-Za-z0-9:]+)?.*:.* "shelly_$1"

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        shellyplus2pm_c049ef856700
   DEF        shellyplus2pm_c049ef856700
   FUUID      65f16e58-f33f-3405-593d-27228845401f8aa1
   IODev      MQTT_Server
   LASTInputDev MQTT_Server
   MQTT_Server_CONN MQTT_Server_192.1.170.44_61934
   MQTT_Server_MSGCNT 622
   MQTT_Server_TIME 2024-03-13 13:05:00
   MSGCNT     622
   NAME       MQTT2_shellyplus2pm_c049ef856788
   NR         937
   STATE      ???
   TYPE       MQTT2_DEVICE
Attributes:
   bridgeRegexp .*mac":"([A-Za-z0-9:]+)?.*:.* "shelly_$1"
   readingList shellyplus2pm_c049ef856788:shellyplus2pm-c049ef856788/events/rpc:.* { json2nameValue($EVENT) }
shellyplus2pm_c049ef856788:shellyplus2pm-c049ef856788/online:.* online
   room       MQTT2_DEVICE
So wird nun auf Grund der unterschiedlichen Mac Adresse der BLU Devices jeweils ein neunes Gerät unter MQTT2_Device angelegt.
Diese habe ich dann wie folgt konfiguriert.

Code Auswählen Erweitern

defmod Shelly_BLU_DoorWindow MQTT2_DEVICE shelly_38:39:8f:f8:88:40
attr Shelly_BLU_DoorWindow devStateIcon open:fts_window_1w_open@red tilted:fts_window_1w_tilt@yellow closed:fts_window_1w@green
attr Shelly_BLU_DoorWindow icon fts_window_1w
attr Shelly_BLU_DoorWindow jsonMap payload_BTHome_version:BTHome_version\
payload_address:mac\
payload_button:button\
payload_battery:battery\
payload_encryption:encryption\
payload_illuminance:illuminance\
payload_pid:pid\
payload_rotation:rotation\
payload_rssi:rssi\
payload_window:window
attr Shelly_BLU_DoorWindow model shellybludw
attr Shelly_BLU_DoorWindow readingList shellyplus2pm-c049ef856700/38_39_8f_f8_88_40/events/ble:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr Shelly_BLU_DoorWindow room MQTT2_DEVICE
attr Shelly_BLU_DoorWindow userReadings state:(window|rotation).* { ReadingsVal($name,"window","") eq "0" ? 'closed' : ReadingsNum($name,"rotation",1) > 0 ? 'tilted' :'open' }

So bekommt man im state open|closed|tilted angezeigt und kann den Sensor zum Beispiel in ASC verwenden.

Für Anpassungen an dem Konstrukt um es evtl zu vereinfachen bzw. sauberer zu haben schreibt gerne.
@Beta-User evtl. kann das Device Shelly_BLU_DoorWindow dann auch so in die attrTemplates übernommen werden.

Viele Grüße
Alex

[Beta-User]

Hmmm, spontane Meinung: Das mit den scripts auf dem Shelly ist schon sehr speziell, und dann noch Änderungen daran vorzunehmen, macht es noch spezieller (und ist eine Sache, die man bei updates etc. ggf. leicht vergißt).

Ginge es nicht einfacher, wenn man

a) im "Hauptdevice" (optional!) den (unveränderten) events/ble-Topic auswertet und da erst mal per regex, (suchen-ersetzen für die Doppelpunkte) einen prefix extrahiert für jedes Device und dann nur den "payload"-JSON (also einen Auszug aus dem ganzen?) durch json2nameValue() auspacken läßt? Dann braucht es uU. hier kein $JSONMAP, also im Ergebnis dann 'json2nameValue($innerPayload,"${prefix}_")' als Rückgabeanweisung;

b) für die "Sub-Devices " könnte man das mit der "suche die richtige MAC-Adresse" auch in der readingList (hinter dem Doppelpunkt) filtern und dann wieder direkt nur den payload-JSON auspacken? (Rückgabeanweisung: 'json2nameValue($innerPayload)')?

Mir ist klar, dass das sehr abstrakt klingt, aber zumindest das Extrahieren des "inneren JSON" macht z.B. "tasmota_zigbee2tasmota_light_dimmer"...

Aber: Wenn jemand was funktionierendes liefert, checke ich gerne ein, was halt da ist. Es sollte dann bitte eine Anleitung mit rein, wie es gedacht ist, damit wir nicht irgendwann Rückfragen haben, die zumindest ich nicht beantworten kann. Von daher neige ich eben eher dazu, die "Intelligenz" lieber direkt im Code zu plazieren.

[DasQ]

OpenMQTTGateway kennt die wohl...

Hab ich jetzt spartanisch genau so umgesetzt. Hatte dieses Wochenende leider was anderes zu erledigen, ansonsten wäre es schon fertig.
Aber es erspart den dämlichen Umweg über die shelly mit original Firmware (App und Cloud) die Software Konfiguration.

Die shelly blu door kann man über die Debug App aktualisieren und Grund konfigurieren. Den Rest erledigt OMG (OpenMQTTGateway). Den muß ich aber erst noch grundlegend konfigurieren, weil der im Augenblick Zeug empfängt, das glaubt man nicht.

Ach ja @Beta-User ich hab in dem Mqtt Thread schon halbherzig angefangen den ein oder anderen Verbesserungsvorschlag zu verfassen bzgl OMG Template. Könntest du mal auf deren Homepage schauen, da hat sich etliches getan was man konfigurieren kann. Ich schreib das gerade zusammen, allerdings kämpf ich mit den Set.

BTW. Arbeite ich gerade auch noch daran das ganze in tasmota zum laufen zu bekommen.