Beiträge von chrissiboy

ah, ne, bekomme das Downgrade nicht angeboten

Ich hätte auch erwartet, dass der D/W als zusätzlicher Sensor in der Komponentenansicht erscheint .. das tut er nicht

ich habe die 1.5.1 beta drauf - ich kann es gerne auch nochmal mit der 1.4.4 versuchen

du meinst das :

Hallo,

ich habe zu einem BLU TRV ein D/W verknüpft und bekomme das auch in der Web-Oberfläche angezeigt. Wenn ich nun das Fenster öffne, wäre ich davon ausgegangen, dass dann automatisch auf die temporäre niedrige Temperatur (8 Grad) umgeschaltet wird. So wie es aussieht passiert das aber nicht. Muss das über ein Scipt gemacht werden ? Ich habe versucht, über eine Aktion etwas zu machen, aber das geht nicht, weil als Aktion nur OnChange angeboten wird, aber die Reaktion für Öffnen und Schließen ja unterschiedlich ist ..

Grüße Frank

Leider keine Besserung .... aber wenn man das Ergebnis von "rpc/Shelly.GetComponents" auswertet und mit den ID's von blutrv und bthomedevice und dem Befehl "/rpc/BTHomeDevice.GetKnownObjects" weitersucht, bekommt man die ID's zur jeweiligen Device aufgelistet. Allerdings ist nicht zu erkennen, welcher Sensor was tut .... (zumindest ich habe es noch nicht herausbekommen). Wäre echt gut, wenn das im Ergebnis von "BTHomeSensor.GetConfig" enthalten wäre.

Hallo,

lt. der RPC-Beschreibung sollte der Befehl "rpc/Shelly.GetComponents" alle Komponenten auflisten, die an den Gateway hängen. Ich habe derzeit 2 TRV's verbunden und bekomme als Rückmeldung sowohl blutrv200 als auch blutrv201 und jeweils auch die bthomedevices dazu. Bei den Sensoren ist das Ergebnis schon deutlich sparsamer. Zum einen wird der Sensor "externe Temperatur" nicht gelistet (obwohl die Funktion einwandfrei läuft) als auch die Sensoren der zweite bthomedevice werden nicht zurückgegeben. Liegt hier nicht eine Fehlfunktion vor oder wie bekommnt man die fehlenden Sensoren und deren ID's ? Über MQTT habe ich festgestellt, dass die ID's der Sensoren einfach hochgezählt werden (über alle Devices hinweg - egal ob TRV, DW oder HT) und damit eine Zuordnung zu den Devices nahezu unmöglich ist.

Ist dies ein bekannter Fehler beim rpc oder habe ich etwas übersehen ?

Grüße Frank

Hm - könnte ein Versuch wert sein ... such aber für den Notfall noch die Auslieferungs-FW für den 2PM ... habe bisher nichts gefunden.

m.W. gibt es dafür keine Tasmota-Version

so, ich habe das ganze mal etwas weiterverfolgt und siehe da, es handelt sich um ein altes Problem der Shellies. Es gibt ständig "MQTT0 queue overflow!" obwohl KEIN Script läuft. D.H., die MQTT-Queue der Shellies ist schon mit den in der FW verankerten MQTT-Nachrichten überfordert. Das Problem scheint schon seit langer Zeit zu bestehen. Gibt es hierzu ein Ticket bei Shelly ?

Ich habe seit Jahren Shelly 2.5 als Rollladensteuerung unter TASMOTA laufen, ohne dass solche Problem auftreten - und das, obwohl dort über MQTT während der Bewegung die Position laufend übermittelt wird.

Auf den ersten Blick scheint die 1.5.0 Beta das Problem zu lösen.

Korrektur: Leider doch nicht - immer wieder kommt es zu Verzögerungen bei den MQTT-Meldungen am Ende der Laufzeit des Rollladens. Das passiert bei keinem meiner 2.5 - ein MQTT-Problem kann man da wohl ausschließen. Es sieht so aus, als ob die Statusänderung erst mit den nächsten telemetriedaten übermittelt wird anstatt beim Statuswechsel.

Interessante Nachbetrachtung:

Heute ist es genau umgekehrt. Der Open-Status wird sofort übermittelt und dafür der Unten-Status erst nach 30-60 Sekunden. Das sieht im ersten Blick nach einem FW-Fehler aus. Kann jemand diese Beobachtung bestätigen ?

Hallo zusammen,

ich habe eine 2 PM im Cover-Modus eingebaut und über MQTT an IP Symcon angebunden. Soweit funktioniert das ganze auch, außer, dass die MQTT-Nachricht beim oben ankommen erst nach knapp 30 Sekunden gesendet wird. Das Relais schaltet sauber in der Oben-Position sofort ab und im WebUI wird auch angezeigt, dass er im Status oben ist. Um sicherzustellen, dass es kein Problem von IP Symcon ist, habe ich das ganze auch im MQTT-Explorer verfolgt, doch auch da kommt die Nachricht erst viel später. Beim Runterfahren oder anhalten auf einer Zwischenposition klappt alles einwandfrei.

Bild 1 zeigt den Zustand nach dem Herunterfahren, Bild zwei nach dem Hochfahren. Nach einer Wartezeit von ca. 30-60 Sekunden wird dann auch der close-Status geschickt (Bild 3).

ja, das kenne ich noch

Ich habe jetzt mal eine IP-Adresse fix vorgegeben - das scheint zu funktionieren. Damit habe ich zumindest erreicht, dass er mit der richtigen Adresse im Netz ist. Das ist zwar anders als bei allen anderen Shellies, aber wenn es in dem Fall nur so geht, dann halt so.

Danke für die Unterstützung.

Mit WIFI-Panel meine ich die Web-Oberfläche des Shelly. Die Lease-Reservierung erfolgt über den DHCP eines Windows-Domainserver. Ich habe das bisher bei keinem Shelly gesehen, dass eine führende 0 weggelassen wird. Evtl. kommt der DHCP damit nicht zurecht denn beim Einrichten einer Reservierung meldet er einen Fehler, wenn ich die 0 weglasse.

Hallo zusammen,

nachdem ich erfolglos versucht habe, meinen neuen Shelly PLUS HT (FW 1.08) in mein Netzwerk zu integrieren, ist mir aufgefallen, dass die MAC-Adresse, die mir im WIFI-Reiter angezeigt wird, nur 11 Stellen hat und das vorletzte Zeichen fehlt. Im WLAN-Verzeichnis wird der Shelly als ShellyPlusHT-80:64:6f:c9:b3:04 angezeigt, im WIFI-Panel steht aber nur 80:64:6f:c9:b3:4 und ich bekomme in einfach nicht in mein Netzwerk mit reservierter Lease im DHCP. Trotz Zurücksetzen auf Werkseinstellungen verbessert sich die Situation nicht. Hat jemand eine Ahnung, was man noch versuchen kann ?

Grüße Frank

Ja, gerade nach den Messwerten an den Eingängen kann ich es auch nicht erklären.... aber so ist der Effekt. Das mit den langen Kabeln hatte ich auch schon bei Dimmern, die auch mal geschaltet haben und mal nicht. Ausschalten hat immer funktioniert, aber beim Einschalten war es echt Glücksache. Nun, wenn das für mich die Lösung ist, dann akzeptiere ich es auch ohne es zu verstehen. Zwei Shelly 1 kosten auch nicht mehr als ein 2.5er .

thgoebel : Ich denke, ich habe das Problem gelöst. Bei der Teststellung sind die Kabel zwischen Shelly und BWM maximal 25cm lang. Bei der echten Installation liegen 3-6 Meter dazwischen. Scheinbar schlägt hier die Empfindlichkeit der Shellies bezüglich langen Leitungen wieder zu. Ich habe mal den Shelly in der Installation direkt beim BWM angebracht und siehe da.... alles funktioniert so wie es soll.

Damit wird es zwar aufwändiger und ich benötige mehr Shellies, aber wenn es so funktioniert, ist das halt so.

FI-Problematik kann ich ausschließen - Teststellung an FI funktioniert. Werde weitersuchen.....

ich habe 4 gleiche - 2 in der Teststellung und 2 in der echten Installation. Bei beiden Installation werden die 230 V vom SW gegen den Leiter (an N von Shelly) gemessen wenn die BWM aus sind - wenn sie durchschalten sind die 230 zwischen SW und dem Nullleiter (L an Shelly). Also von den Messwerten her laufen beiden Installationen synchron.

Ja, an beiden Eingängen liegen LX 752 und im Testaufbau funktioniert es mit beiden Shellies. Ausgänge sind unbesetzt.