Beiträge von Spartacus99

Moin und danke fürs Feedback! Dann kann ich die Dinger nicht gebrauchen! Schade!

Hallo zusammen,

ich setze mehrere Shelly PRO 1PM für die Hutschiene ein. Diese werden über einen separaten Steuerkreis FI/LS mit Spannung versorgt. Der Lastkreis, an dem der Verbraucher angeschlossen ist, läuft über eine andere Phase und einen anderen FI als der Steuerkreis. Das funktioniert bei dem PRO 1PM auch einwandfrei.

Geht das bei dem Shelly Pro Dimmer 1PM auch, oder müssen Versorgungsspannung und Lastkreis die selbe Phase und den selben Null haben?

Hallo apreick ,

vielen lieben Dank für die Erläuterungen. Jetzt ist alles klar. Dann probiere ich das Dingen mal aus. Mir war nicht ganz klar, ob Du die Shelly Integration dafür nutzt. Der BLU-Sensor: Meldest Du den im Web-Interface des Gateways als Device an, oder reicht die Konfiguration in Homeassistant?

image.png

Die GW-Funktion auf dem shelly hast Du auch aktiv, oder?

image.png

Moin apreick ,

Dein Setup in HA verstehe ich noch nicht so ganz. Du nutzt die Shelly´s als BLU Gateway für die Govee und Ankilo Sensoren, die jeweil über eigene Integrationen laufen?

Was verstehst Du unter "passiv mode" bei den Shelly Gateways? Da kann man das BT-GW doch nur ein/ausschalten.

Wo kann man die Sensoren kaufen bzw. hast Du einen Link, Bei ama... finde ich die nicht!

dewaldo

die BTHome Integration läuft zusammen mit der Shelly Integration in HA. Ursprünglich hatte ich das Shelly BLU GW, da hatte ich in diesem Forum gelesen, dass es bei dem Dingen des Öfteren zu Problemen kommt und BTHome am Besten zusammen mit einem Mini 1 Gen3 als GW läuft. Aber auch das funktioniert leider nicht. Meine BLU H&T haben sich das letzte mal vor 12h gemeldet, Also auch keine Alternative zu dem MQTT-Script. Es sieht so aus, als müsse ich die 6 Sensoren in die Tonne kloppen und auf die Integration von apreick zurückgreifen, aber wie gesagt, das Setup verstehe ich noch nicht ganz.

Hey,

vielen Dank für Deine Erläuterungen! Das mit den Übertragungsabbrüchen bei Temperatur und Luftfeuchte ist halt blöd, da ich daraus absolute Feuchte und Taupunkt berechne. Das sieht in Grafana dann ziemlich blöd aus! Ich habe auch schon sehr ausführlich mit dem Shelly Support diskutiert, aber mehr als "die Entwickler sind dran" kommt seit Monaten nicht. Am Ende haben sie mir das Geld erstattet und wollten die BLU Dinger auch nicht wieder haben. Ich hatte irgendwo gelesen, dass es mit dem Mini1 Gen3 als GW klappen soll, aber per MQTT und dem Script gibt es die selben Probleme. Vielleicht versuche ich es noch mal mit BTHome. Mit dem BLU Gateway ging da gar nichts, nach ein paar Tagen war komplette Funkstille.

Ich kann mich ärgern, dass ich mein funktionierendes 1-Wire aufgegeben habe. Die Integration in Homeassistant war mit meinem Buskoppler(fhem lässt grüßen) nicht möglich und ich wollte da nichts mehr investieren. Egal, ich probiere es noch mal mit BTHome und dem Mini

image.png

Hallo,

danke für die Erläuterungen. Ich nutze HomeAssistant und meine Shellies sind alle per MQTT und TLS über mosquitto angebunden. Ich hatte gedacht, dass das Script nun auch den Shelly als GW nutzt und die Daten damit verschlüsselt übertragen werden. Das scheint dann wohl nicht der Fall zu sein.

Das BLU GW verwende ich nicht mehr und auch das BTHome habe ich abgeschaltet, da dann meine Shelly Aktoren doppelt im HA erscheinen. Einmal über die Shelly Integration und einmal über MQTT. ist Das Script ist da schon super und ich kann im HA schon sehr exakt auf die Sensoren reagieren. Problematisch könne es sein, wenn Mosquitto von mehreren GWs REquests bekommt. Da habe ich zu wenig Erfahrungen, was dann passiert.

Was ich auch festgestellt habe. Ab und zu verlieren die BLU-Sensoren offenbar die Verbindung und HomeAssistant meldet, dass die Sensoren nicht verfügbar sind. Das kommt dann zu Fehlern im UI, da "unavailable" keine Temperatur oder Luftfeuchte ist. So ganz glücklich bin ich noch nicht, aber was ist die Alternative?

Danke und Gruß

ok, das ist ja blöd, dass der alle MAC Adressen in der Umgebung einrichtet, ich hätte es sinnvoller gefunden, dass man nur die konfiguriert, die man auch benutzen will! Was passiert denn, wenn mehrere Gateways ein BLU-Gerät scannen, dann habe ich das Device ja mehrfach im mqtt Broker, oder?

Ich kann ja auch nicht in allen GWs immer alle Blu devices blacklisten, die ich neu hinzukommen, oder macht dem Broker das nichts aus?

Hallo,

ich habe mich nun etwas mit dem Script beschäftigt und ich bin etwas verwirrt.

Ich habe im Mini 1 Gen3 lediglich Bluetooth freigeschaltet und auch keinen H&T am Gen3 angelernt. Das Script übermittelt trotzdem Daten und zwar von allen Geräten, die es in der Umgebung findet, obwohl activeScan= false; steht. Ich habe den einen Sensor, den ich auslesen möchte unter "custom_Names" explizit konfiguriert, doch er findet einfach alle anderen H&Ts. Wie kann ich dies einschränken, da ich mehere H&Ts auf unterschiedlichen GWs nutzen möchte

Moin zusammen,

ich nutze inzwischen das BLU_to_MQTT Scriot auf einem Mini Gen3. Im HA kann ich die Topics auch abfragen, aber ich kriege die Sensoren in AH nicht richtig eingebunden. Kann jemand helfen?

  - unique_id: blu.gh_ht_in
    name: GH Innentemperatur
    object_id: blu.gh_ht_in
    state_topic: "GH-H&T/GH-HT-in/status/temperature"
    unit_of_measurement: "°C"
    icon: mdi:thermometer
    value_template: '{{ value | round(2) }}'
    expire_after: 3600
    availability_topic: "GH-H&T/GH-HT-in/status"
    payload_available: "connected"
    payload_not_available: "disconnected"
    suggested_display_precision: 2
    qos: 1

das Topic im MQTT-Explorer heisst: GH-H&T/GH-HT-in/status/temperature. HA sagt mir aber, dass das Gerät nicht verfügbar sei.

Moin zusammen,

ich habe einen Mini 1 Gen3 und das BT Gateway aktiviert. es ist ein BLU H&T angelernt. Der Mini ist per MQTT in Homeassistant eingebunden. Das Script habe ich auch installiert, aber wie kommen die Sensordaten nun nach Homeassistant. Ich sehe die Sensoren in den Device-Einstellungen nicht. Wo werden die Daten hingeschrieben, bzw. muss ich am Script noch was customizen?

Gesendet werden die Daten offensichtlich auch, aber wie kriege ich diese in HA? Muss ich die zu Fuß konfigurieren, oder werden die automatisiert dem Device zugeordnet, welches ich per "Shellies Discovery Gen2" durchführe?

image.png

Moin zusammen,

vielen Dank für die guten Hinweise. Ich werde mit einen Mini 1 Gen 3 mal bestellen und dann das ganze per MQTT anbinden. Vielleicht klappt es dann zuverlässig. Ich melde mich.

ok. ich kann die Blue H&T wieder koppeln, aber die Option BCN wird mir nicht angezeigt. ist das bei den Blu H&T Devices so?

Moin zusammen,

vielen Dank schon mal für die Antworten. Ich habe lediglich das Shelly GW und das Dingen ist per WLAN angebunden. Wie kann ich denn die Sensoren per MQTT anbinden? Das GW ist mir schon klar, aber die BT Dinger, da kann ich doch nichts konfigurieren, oder geht das alles über die Debug App?

Hier mal die Signalstärke:
image.png

und hier mal der Temperaturverlauf mit den Aussetzern.

image.png

Moin zusammen,

ich muss jetzt mal ein paar doofe Fragen stellen, da ich auch zwei BLU H&T Devices habe, die ich über ein BLU GW und BTHome in Homeassistant betreibe. Die beiden Sensoren steigen auch regelmäßig für mehrere Stunden aus und senden keine Daten, obwohl sich Temperatur und Luftfeuchte ändern. Sprünge von 10 Grad sind keine Seltenheit.

Ich lese hier von FW Update und beacon - Mode. Wo stelle ich das ein? Die Sensoren sind doch nicht erreichbar, Lediglich das GW kann ich per WebInterface erreichen (FW.1.3.3). Ist es zwingend erforderlich die Blu Devices per App zu konfigurieren um ein FW Update zu machen oder mit dem Beacon Mode zu spielen? Sorry, nutze alle anderen shelly Devices ohne die Shelly App und habe keine Probleme. Wäre über eine Info sehr dankbar, weil die Sensoren das Klima in meinem Gartenhaus steuern und das grad absolut nicht richtig funktioniert.

Moin zusammen,

ich habe seit gut einer Woche zwei Shelly BLU H&T Sensoren und lese Temperatur und Feuchte mit einem BTHome in HA aus. Die Devices werden direkt erkannt und liefern Daten. Allerdings scheinen die Daten des Außensensors (Luftfeuchte) nicht wirklich stabil zu sein. Wie man erkennen kann, schwanken die Werte sehr stark und liefert offenbar im Sekundentakt Daten. Das sieht in der Grafik nicht wirklich gut aus!

Im Innenraum schwanken die Werte weniger, wie man sehen kann. Bei geöffneter Tür zeigt sich allerdings ein ähnliches Phänomen, obwohl beide Sensoren geschützt angebracht sind. Offensichtlich vertragen die Geräte keinen Luftzug. Ist das bei den Dingern normal? Ich habe zwei 1-wire Sensoren in direkter Nähe zu den BLU-Dingern und diese zeigen ein solches Verhalten nicht.

Was kann man da tun? FW-Updates können m.E nicht eingespielt werden. Der Temperaturverlauf ist ok.

image.png

image.png

Hallo zusammen,

ich habe heute noch einmal an einem neuen PM1 Pro getestet.:

zuerst habe ich ein Client-Zertifikat erstellt und es mit meiner Ca signiert. Spiele ich nun das Client-Zertifikat und den Key ein, bekomme ich wieder den MQTT Connection Error. Erst wenn ich auch die Ca. einspiele baut er die Verbindung zum MQTT-Server auf. Das heisst:

Man benötigt offenbar alle 3 Dateien:

• ca. crt
• shelly.crt
• shelly.key

Gruß,

Sparatcus

Zitat

Spartacus99 Bitte gib mir mal eine Rückmeldung zu Beitrag #7

Oben wird ein PEM Bundle erwartet. Und das hast Du meiner Meinung nach nicht. Also reichen theoretisch die beiden unteren Uploads. Die .key Datei ist klar, aber noch nicht welche der beiden CRT Dateien.

Hi,

ja, hatte ich schon geschrieben, die Dateien haben einen anderen Inhalt. Aber ich habe es hingekriegt:

Ich habe die Zertifikatsdateien noch einmal vom Mosquitto Server kopiert und genau in dieser Reihenfolge auf beide Shellys installiert.

• ca.crt
• server.crt
• server.key

Beide können sich noch connecten. Offenbar waren die Kopien im OneDrive defekt obwohl sie die gleiche Größe und das Gleiche Datum hatten. Manchmal steckt man nicht drin, hat mich einen ganzen Abend gekostet.

Festzuhalten ist, dass man inzwischen das ganze Bundle benötigt. Wahrscheinlich kann man auch für jeden Client ein eigenes Zertifikat erstellen, aber die Server Zertifikate laufen auf jeden Fall Ob man die ca. auch hochladen muss, weiß ich nicht, kann ich nicht mehr checken, probiere ich bei dem nächsten Shelly mal aus. Der liegt schon im Keller!

Danke für den Support,

Spartacus

Zitat

Ich würde vermuten, dass dort der Hund begraben liegt, kenne mich damit aber auch nicht wirklich aus

wie gesagt, das läuft seit einem Jahr auf 15 Shellys! Ich habe oben beschrieben, wie ich die Certs erstellt habe. Ich vermute, dass die neue FW hier anders damit umgeht!, wenn man das Zertifikat neu installiert. Die FW-Updates haben das installierte Zertifikat offenbar immer richtig übernommen, denn alle meine Shellys sind inzwischen auf 1.1.0. Mein ZigBee2Mqtt-Server nutzt auch SSL und der kommuniziert mit dem selben Mqtt-Server wie die Shellys. Also irgendwas haben die Shelly Entwickler verändert! Die Beta 1.2.0 läuft auch nicht. Wirklich Mist, dass es keine ältere Version mehr aus 2023 gibt. Diese 1PM habe ich im November in Betrieb genommen. Da lief noch alles.

Hier noch einmal das Log:

shos_mqtt_conn.c:601 MQTT0: Connecting to mosquitto.home.domain.de:8883 (172.16.50.4:8883) SSL
21:57:01
ssl_cli.c:2297 0x3ffdc990 server did not confirm our fragment length request, disabling
21:57:01
ssl_tls.c:6213 0x3ffdc990 x509_verify_cert returned -9984
21:57:01
ssl_tls.c:6218 0x3ffdc990 The certificate is not correctly signed by the trusted CA

ne, das ist anders.

Die Frage ist tatsächlich, was man benötigt. Fangen wir mal ganz von vorne an:

Unter TLS Configuration hat man nun 3 Upload Felder:

• Custom certificate authority (CA)
• Custom client certificate
• Custom client key

pasted-from-clipboard.png

und dann ist es ja so, dass man das Client Zertifikat normalerweise auf den Hostnamen des Client zertifizieren muss. Und da ist der Frage, was das für ein Hostname sein soll. Der Shelly meldet sich ja im DHCP-Server mit einem krypischen Hostnomen: (z.B. shellyplusuni-<MACADRESSE>)

In meiner Anleitung mache ich die Erstellung sder Zertifikate so:

# Step 1
# Zuerst muss ein Schlüsselpaar für die CA
# Kennwort für die CA vergeben, ohne läuft es später nicht.
#
openssl genrsa -des3 -out ca.key 4096


# Step2:
# CA Zertifikat erstellen:
openssl req -new -x509 -days 7300 -key ca.key -out ca.crt


# Step 3:
# Server Key erstellen:
openssl genrsa -out server.key 4096


# Step 4:
# Zertifikat-Request csr erstellen.
openssl req -new -out server.csr -key server.key


# Step 5:
# Zertifikat signieren:
# Gültigkeit 7300 Tage ca. 20 Jahre
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 7300


# Step 6:
# die Zertifikate in die Zielverzeichnisse des mqtt-Servers kopieren.

auf dem shelly musste man lediglich die ca.crt importieren und das war es.

ich nehme an, jetzt braucht man zusätzlich das Client-Zertifikat, was auf jedem shelly anders sein muss:

################################
# Client ZErtifikate erstellen
#
#
# Step 1:
# Private Key erstellen:
openssl genrsa -out shelly.key 2048


# Step 2:
Zertifikatsdatei erstellen und private Key benutzen:
openssl req -new -out shelly.csr -key shelly.key


# Step 3:
# Zertifikat signieren:
# Gültigkeit 7300 Tage ca. 20 Jahre


openssl x509 -req -in shelly.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out shelly.crt -days 7300

und jetzt ist die Frage, was der FQDN vom Shelly ist!

Was exakt muss man nun tun mit FW 1.1.0?

eigentlich habe ich alle Dateien:

ca.crt

server.crt

server.key

trotzdem kriege ich den Fehler, dass es falsch signiert sei.

The certificate is not correctly signed by the trusted CA
ssl_tls.c:6213 0x3ffdca54 x509_verify_cert returned -9984

Das ist doch echt Murks, was Shelly da macht.

Die Frage ist, wie man die validation des Zertifikitas abschaltet.

Custom CA PEM Bundle

A CA bundle which covers many of the widely-used SSL providers is already available for Gen2+. In cases where the built-in bundle doesn't include a needed certificate, or cases in which self-signed server certificates are used, a second CA bundle can be added by the user. For outgoing TCP connections with TLS support, the CA bundle can be chosen by:

• "*" - use SSL but disable certificate validation
• "ca.pem" - use the default CA bundle
• "user_ca.pem" - use a bundle uploaded by Shelly.PutUserCA