Beiträge von egb.beck

Hallo zusammen,

ich hab das WallDisplay grad erst in Betrieb genommen und gedacht, ich könnte darauf auch so eine Art "virtuellen Taster" erzeugen, mit dem ich dann z.B. als Action einen HTTP-Befehl abschicken kann.

Ich möchte mit dem Display nicht nur Shellys steuern, sondern auch andere Geräte im Smarthome.

Eine einzelne Action abzuschicken, wenn ich den Taster als Detached verwende, mag wohl funktionieren, aber ich bräuchte eine Möglichkeit, mehere verschiedene Actions (Http-Befehle) abzuschicken. Nicht als Gesamt-Szene, sondern separat.

Oder gibts schon Erfahrungen mit "alternativer Software", die man über das Firmwaremenü aufspielen könnte?

VG

Harry

Zitat

mal das Log aufgeklappt ? eher wohl nicht.

Nix für ungut, aber was in der Log steht ist vielleicht aufschlussreich. Allerdings interessiert mich die Log ehrlich gesagt gar überhaupt nicht in der täglichen "Standard"-Anwendung, denn wenn in der App beim Gerät selbst schon eine Anzeige dafür vorgesehen ist, dann sollte es auch dort stehen ! Das tut es aber definitiv nicht !

Zitat

Was ist das denn bitte. Der Neigungssensor kann natürlich nur bei ordnungsgemäßer Montage funktionieren.

Nachdem in der Anleitung zu den DW2 keine Hinweise enthalten sind, wie die beiden Teile zu montieren sind, habe ich eben verschiedene Varianten ausprobiert.

Normalerweise werden die Magnete am Fenster und die Sensoren am Rahmen montiert. So kenn ich das zumindest von anderen Herstellern. Da diese Konfiguration bezüglich Neigungssensor nicht funktioniert hat, habe ich dann eben den Magnet am Rahmen und den Sensor am Fenster montiert. Und natürlich habe ich die Kalibrierung durchgeführt. Das sagt ja so auch die App wenn man die Funktion aktiviert. Ich wollte mit meinem Satz: "(egal wie man die beiden Teile montiert - am Fenster oder am Rahmen)." eben ausdrücken, dass ich verschiedene Möglichkeiten der Montage ausprobiert hab.

Insgesamt kann ich nur meine Erfahrungen mitteilen.

Allerdings verweise ich hier jetzt auch mal an die sehr vielen Beiträge im Forum zu den Batteriebetriebenen Geräten von Shelly. Zumindest jetzt mal die, die ich selbst getestet habe.

Mehr will ich dazu nicht sagen.

Ich finds nur schade, wenn dann verbal der Zeigefinger gehoben wird, wie oben zu lesen ist: "mal das log aufgeklappt? eher wohl nicht". Und das obwohl erstens schon aus vielen anderen Beiträgen bekannt sein sollte, dass die Geräte durchaus Problembehaftet sind und zweitens hier eine Frage zunächst angebrachter wäre, als gleich davon auszugehen, dass der andere Autor etwas nicht gemacht hat.

Ach übrigens, nur eine Anmerkung zur Log: Selbst wenn mich diese interessieren würde, könnte ich sie nicht nutzen, weil die App beim Aufruf derselben einfach hängen bleibt. Und das schon immer.

So, ich hab jetzt all meine ShellyPlusSmoke2, Shelly TRV-V5, ShellyPlusDoorWindow2 wieder zurückgeschickt.

1) die Smoke sind eigentlich überhaupt nicht smart. Wenn sie im Schlafmode sind, kann sie (evtl.) nur ein Alarm oder Alarm-Test aufwecken. Eine Vernetzung ist so nicht möglich, weil über Funk/WLAN nicht ansprechbar. Außerdem haben alle 14 Stück in 48 Stunden nicht einmal den Batteriewert geschickt. Weder per UDP noch innerhalb der Shelly-App (also in die Cloud). Verlassen will ich mich auf so einen Rauchmelder mit Sicherheit nicht. Was noch auffällt ist, dass sie zwar den Status "1" senden, wenn der Test-Alarm ausgelöst wird, dann aber keinen Status"0", wenn der Test-Alarm wieder beendet ist.

2) Die TRV kann man zwar ansteuern und senden auch Daten, doch zuverlässig funktionieren tun sie nicht. Mal nehmen sie einen Befehl an, mal nicht. Und das bei sehr gutem WLAN-Empfang

Zudem zeigen sie bei Tastendruck zunächst die Raumtemperatur an, dann sollte man 3 Sec. auf einer Taste zum Ändern der Wunschtemperatur drücken. Tut man das, wird die Wunschtemperatur nicht zunächst kurz angezeigt, sondern ändert sich sofort und sehr schnell, ähnlich einem Dimmer bei Langzeitklick.

3) Die Shelly-Fensterkontakte liefern zwar bei jedem Event (auf, zu, kippen) die Sensordaten per UDP, aber der "Neigungssensor", der ja wohl das Kippen des Fensters erkennen sollte, sendet gar nichts (egal wie man die beiden Teile montiert - am Fenster oder am Rahmen). Zudem hatte ich nach 36 Stunden Betrieb mit gelegentlichem Fenster auf und wieder zu nur noch 93% (von Anfänglich 98%) Batterieladung. Bei zwei Batterien á knapp 2,- € ist mir das auf Dauer dann doch zu teuer.

Ich verwende grundsätzlich gerne Shellys, aber mit diesen drei Geräten haben die Erfinder nur Murks fabriziert. = Meine Meinung !!!

Ich hoffe, ich nerve nicht zu arg, aber grad ist mir noch was eingefallen, wie ich ggf. da im Workaround etwas lösen könnte.

Wenn ich den virtuellen UDP-Eingang vom Testalarm, der ja beim Drücken der Testtaste auf EIN geht an einen verzögerten Impuls hänge und der dann nach z.B. 5 Sekunden einen virutellen Ausgang, der einen UDP-Befehl sende, aktiviert, könnte ich doch sozusagen den virtuellen UDP-Eingang wieder zurücksetzen.

Ich hab mir das so gedacht, dass ich den virtuellen Ausgang mit der Adresse /dev/udp/<IP-vom-Miniserver>/<Port-den-ich-für-UDP-Eingang-Verwende> konfiguriere

und dann den Ausgangs-Befehl bei "Befehl bei Ein" dann die Zeichenkette vom Smoke (in diesem Fall dann mit "event":"alarm_test", "state":false sende.

Anstelle des true, das beim aktivieren geschickt wird, füge ich dann false ein.

Doch irgendwie komme ich da mit der Wertekorrektur nicht zurecht. Wie versteht sich das in deinem Template

wird das true als 116 gewandelt und das setzt dann die 1 für aktiviert?

Ich hab den UDP-Befehl mit false und auch mit 102 versucht, beides kommt zwar im MS wieder an, setzt mir aber den virtuellen UDP-Eingang nicht wieder zurück.

Wie müsste in meinem Beispiel die Zeichenkette beim UDP-Senden denn aussehen?

oh...mann... ich hoffe, du verstehst was ich meine. Ist gar nicht so leicht einfach zu erklären.

ich versteh das mit der Werte-Korrektur nicht, weshalb Du 102 und 116 verwendest. Das hängt wohl mit dem \1 in der Befehlserkennung zusammen.

Sorry, aber noch eine Frage obendrauf.

Wie oft sollten die UDP-Daten vom Smoke gesendet werden. Ich hab den Loxone-Monitor seit über einer Stunde am laufen und es kommt - ohne dass ich was drücke - gar nichts mehr an. Ist das normal?

Alles klar, schade ist das schon.

Da kann man nur hoffen, dass die Programmierung noch angepasst wird.

vielen Dank trotzdem

Jep, hat super funktioniert.

Nun wollte ich gerne auch noch den Alarm-Test an Loxone übergeben und hab mir die UDP-Übertragungen mal angesehen.

Bei Alarm-Test kommt folgendes an: "event":"alarm_test", "state":true

Jetzt hab ich das wie beim Alarm übernommen und in der Befehlserkennung "event":"alarm_test", "state":\1 eingetragen

Wenn ich keine Werte-Korrektur in Loxone vornehme kommt 116 an.

Wenn ich die Werte-Korrektur wie beim Alarm (Eingangswert 1: 102, Zielwert 1: 0, Eingangswert 2: 116, Zielwert 2: 1) setze, geht der Virtuelle UDP-Eingangsbefehl beim Alarm-Test auf 1 (aktiv). Allerdings springt er nicht wieder auf 0 (deaktiv) zurück.

Ist das beim "richtigen" Alarm dann auch so? Wenn ja, wie bekomme ich die UDP-Eingänge dann wieder deaktiviert? Gibts da einen Workaround?

Hallo AlexAN vielen Dank für die schnelle Antwort.

zunächst bin ich gescheitert, weil beim Curl-Befehl über die PowerShell die Fehlermeldung kam, dass kein Parameter gefunden wird, der dem Parameternamen X entspricht.

Dann hab ich die Variante mit dem Browserbefehl versucht und siehe da, es funktioniert.

Super, vielen Dank.

Bin gespannt, wann die von Shelly die UDP-Kommunikation standardmäßig in die Firmware bauen.

Hallo AlexAn, zur UDP-Kommunikation an Loxone hätt ich eine Frage.

In Loxone selbst mit UDP-Empfang und Befehlserkennung weiß ich bescheid.

Ich hab mir aktuell den Shelly-Plus-Smoke-2 zugelegt und finde in den Einstellungen keine Möglichkeit UDP zu aktivieren, bzw. den Port für Loxone anzugeben. Beim Shelly-Plug-S ist das ja z.B. RPC over UDP aktivieren und als Destination-Adress trägt man dann - soweit ich weiß - die IP des Miniserver gefolgt von : und dem Miniserver-Empfangs-Port für UDP-Empfang (z.B. 192.168.178.100:9500) ein.

Kannst Du mir hier bitte auf die Sprünge helfen, wie ich beim Smoke-2 UDP zu aktivieren. Die Google-Suche hat mich da jetzt auch nicht wirklich weiter gebracht. Wenn Du einen LINK zu einer Anleitung hast, schau ich natürlich auch gern selbst nach.

Vielen Dank schon mal

Hallo,

einer meiner beiden Shelly 3EM ist über Browser nicht mehr erreichbar. Es wird im Browser nur "Open failed" angezeigt.

Er liefert auch keine Daten mehr über MQTT. Die LED leuchtet grün.

Ein Reset bzw. einmal stromlos machen hat nichts geändert. (der zweite 3EM funktioniert ohne Probleme)

Kann mir jemand sagen, ob ich den 3EM selber wieder zum Laufen bringen kann, oder ob ein Defekt vorliegt?

VG

Harry