Beiträge von dewaldo

OK. Ich habe im Hinterkopf, irgendwo gelesen zu haben, dass die offizielle Bluetooth Gateway Schnittstelle per Cloud diese Problematik nicht hat.

Öffner sind es zwar nicht, sondern ein Relais mit Schließer, welches aber Richtung GND schaltet und ansonsten ist der Pegel über Pullup halt auf 12V+. Aber aus Shelly-Sicht könnte man das so deuten, dass es sich verhält wie ein Öffner.

Das mit dem Reversed Input bzw. der Tatsache, dass der Input elektrisch gesehen daher immer auf 12V+ liegt, habe ich auch aktuell im Verdacht. Am Output 1 hängt nämlicih bei mir die physikalische Klingel und die löst z.B. nicht aus, wenn ich die Spannungsversorgung wiederherstelle. Das Klingelsignal ist nämlich NICHT invertiert. Diese Theorie zu testen ist aber nicht so einfach machbar, muss dazu in der RFID Elektronik den Draht ablegen, bedeutet alles abschrauben, aufschrauben ... Aber werde ich bei Gelegenheit machen, müsste ich ja ohnehin, auch wenn es am Ende vielleicht dann ein zeitverzögertes Relais wird, was Abhilfe schafft.

Aber deinen Workaround Hinweis habe ich nicht verstanden. Die Eingänge bei mir sind ja beide bereits detached und ioBroker agiert dann und steuert die Ausgänge. Localhost Actions brauche ich daher eh keine. Aber hatte geschrieben, auch mit Einstellung "Detached" und OHNE Anbindung im ioBroker habe ich dasselbe Verhalten. Deshalb, die Theorie, dass der Shelly erst nach dem Booten die eingestellte Logik auch umsetzt, ist naheliegend, aber wäre echt schade, wenn da so wäre.

Und noch kurze Anmerkung als genereller Nachtrag:

- Ich habe festgestellt, dass der Shelly Adpater unter Verwendung von MQTT den Shelly Uni falsch eingebunden hat. Dort werden alle Topics des Kanal 1 auf den Kanal 2 gespiegelt. Heißt im ioBroker habe ich die Daten zu Kanal 1 und 2 als separate Datenpunkte, diese sind aber immer identisch. Ich habe die Schnittstelle deshalb für den Uni von MQTT auf CoAP umgestellt, da passt dann alles. Habe aber nicht weiter geforscht, ob die MQTT Umsetzung im Shelly falsch ist oder im MQTT--Broker.

So, hab es getestet und muss meine Aussage etwas korrigieren. Wenn ich nur den Shelly neustarte per Web Befehl, dann tut sich nix, Ausgang bleibt inaktiv bzw Relais schaltet nicht. Aber wenn ich die Sicherung ausschalte, also das 12V DC Netzteil, dann schaltet das Relais ein, wenn ich die Sicherung wieder schließe. Was da jetzt die Ursache sein kann, weiß ich nicht. Ich kann nur so viel mit Sicherheit sagen, dass der Strom für die Relaisspule auf jeden Fall über den shelly Output fließen MUSS, anderen Pfad gibt es keinen. Statusabfrage bringt nicht viel, die Zeit für beide Kanäle als Source "Input" an, aber ich habe das Gefühl, dass das der default ist nach einem Neustart. Entsperre ich einmal die Tür korrekt, steht als Source "Timer", da ich einen Auto off Timer eingestellt habe.

Hab den Thread überflogen und gesehen, dass du anfangs 12V+ und final dann doch GND über den Uni Output geschaltet hast. D.h. bei dir wäre es dann quasi 1:1 so, wie ich es auch bei mir umgesetzt habe. Test steht noch aus, melde mich....

Ja, deshalb. Es ist halt in manchen Schemen des Uni so dargestellt, als ob die mittleren beiden Drähte an den Ausgängen irgendwie ein gemeinsames Potential hätten. Wollte nur sicher gehen. Es ist in den Datenblättern immer nur als Open Collector Output bezeichnet, aber nichts näheres. Aber klar, alleine schon die Eignung für Wechselspannung ....

Gut, dann werde ich heute Abend mal schauen, was der Status mir verrät nach einem Reboot.

Mmh, jetzt muss ich selbst nochmal kurz nachlegen. Ich habe mir immer im Hinterkopf gemerkt, dass der Shelly Uni Output "potentialfrei" ist. Daher habe ich entsprechend je 1 Seite des Schalters auf mein gewünschtes Potential gelegt, in meinem Fall beide auf GND.
Jetzt habe ich mir gerade nochmal das Schema des Shelly Uni angeschaut und dort ist es so dargestellt, dass die Last an den äußeren Drähten liegt und das Bezugspotential dann auf den inneren beiden.

Bei mir habe ich es so verdrahtet, dass ich jeweils den 2. Draht der Outputs miteinander verbunden auf GND gelegt habe. Kann das evtl. das Problem sein ?

Vielen Dank fürs Testen. Werde heute Abend zuhause mal wieder testen und mir den Status anschauen. Dann kann ich auch mal noch die Power On Defaults "last state" und "switch" testen. Werde dann hier berichten ...

Eine Frage noch an dich. Du schreibst, Darlington Transistor, d.h. du nutzt den Uni als High-Side Schalter ? Ich schalte über den Uni ja die Masse durch, nicht, dass das auch noch einen Unterschied macht, wobei es das nicht sollte...

In den ersten Inbetriebnahmeschritten hatte ich die Button Types des Uni noch auf Toggle Switch stehen, um den elektrischen Part erstmal sauber zu testen und dachte, dass die Ursache des kurzen Schaltens bei der Türklingelanlage (RFID Zugangselektronik) lag, dass diese beim Neustart nach Sicherung einschalten kurz das Türöffner-Signal rausgibt und hatte gar nicht den Shelly im Verdacht. Dachte da schon für mich, na super, das ist mal "toll" umgesetzt.
Erst nachdem ich dann die Inputs auf Detached gesetzt hatte, habe ich dann gemerkt, dass der Shelly von sich aus den Ausgang schaltet. Zu dem Zeitpunkt war der Shelly noch nicht im ioBroker eingebunden.
Ein Neustart des Shelly per WebInterface, also ohne die RFID Elektronik auch neu zu starten, hat das dann nochmal bestätigt, dass auch dann der Ausgang kurz angesteuert wird.

Die Firmware ist aktuell. ECO Modus ist aktiviert.
Das Verhalten ist 100% reproduzierbar. Sobald ich z.B. per WebInterface den Shelly neu boote oder über die Sicherung im Verteiler einen Neustart herbeiführe, klackt das Relais beim Start kurz.

Der betreffende Output ist der Output 2. Die einzige Besonderheit im Shelly selbst ist, dass der zugehörige Input als "invertiert" parametriert ist, weil das Öffner-Signal der RFID Zugangskontrolle die Masse schaltet und ansonsten über einen Pullup-Widerstand +12V Pegel ausgibt.
Aber wie beschrieben, die Inputs sind beide als "Detached" konfiguriert und da sollte das hoffentlich keine Rolle spielen.
Noch zur Vollständigkeit, auch wenn das keine Rolle spielen wird: Am Input 1 habe ich das Klingel-Signal aufgelegt. Das kommt aber direkt über einen einfachen, potentialfreien Taster, der die+12V auf den Input schaltet.

Vielen Dank Thomas, das wäre schon mal eine Möglichkeit, könnte ich dann zur Not einsetzen, wenn es keine andere Möglichkeit gibt.

Und ja, handelt sich um den alten GEN1 Uni. Den hatte ich lange zuhause rumliegen und nun endlich einen richtig passenden Einsatzzweck gefunden und bin grundsätzlich super zufrieden damit, bis auf diese einzige Sache.
Ich habe in einem anderen Beitrag mal gelesen, dass man die Option POWER ON DEFAULT MODE auf "SWITCH" stellen kann, das wäre zuverlässiger. Das muss ich mal noch ausprobieren, aber da ich ja die Inputs beide auf "Detached" gesetzt habe, weiß ich auch nicht, ob diese Option dann überhaupt greift.

Hallo zusammen,

ich habe ein kleines Problem mit einem Shelly Uni. Ich habe ihn zur Ansteuerung eines Türöffners eingesetzt in Verbindung mit einer Türklingel.
Das ganze System läuft mit 12V DC und wird von einem externen Netzteil versorgt.

Das Türöffner-Signal des Klingel-Systems geht auf einen Shelly Uni Input. Die Inputs sind als detached konfiguriert. Über ioBroker kann ich vorgeben, ob das Öffnen-Signal dann auf den Output des Shelly durchgereicht werden soll, oder nicht.

Am Output des Shelly habe ich lowside dazu ein kleines Hilfsrelais angeschlossen. Also Relais Spule hat Dauerplus 12V und der 2. Pol wird über den Shelly Output gegen GND geschaltet.
Über die Schließerkontakte des Relais wird dann der Türöffner-Magnet angesteuert.

Alles funktioniert auch einwandfrei wie gewünscht. Es gibt nur ein kleines Problem. Und zwar habe ich festgestellt, wenn der Shelly neu bootet, dann wird der Output des Shelly ganz kurz aktiv. Bedeutet bei mir, das Hilfsrelais wird kurz bestromt, sodass auch kurz der Türöffner bestromt wird. Ist es nun z.B. etwas windig, kann das ausreichen, dass der Schnapper der Tür dann nicht mehr richtig zurückfällt und damit die Tür aufgedrückt werden kann.

Das ist natürlich nicht so toll. Sinn des Shelly sollte nämlich genau der sein, dass ich das Öffner-Signal der Türklingel parametrieren kann.
Im Shelly habe ich für den Output konfiguriert, dass der POWER ON DEFAULT MODE = OFF ist. Trotzdem schaltet der Ausgang beim Neustart immer ganz kurz durch.

Ist dieses Verhalten bekannt ? Bzw. kennt jemand eine Möglichkeit, das zu verhindern ? Das Problem ist halt auch ein Stromausfall, Gewitter etc etc. Im Moment ist es so, wenn ich die Sicherung ausschalte und danach wieder einschalte, klackt es nach ein paar Sekunden kurz und ich kann die Haustür öffnen. Das kann so natürlich nicht bleiben.

Ich denke einen Fix konkret zu diesem Thema liefern wird tatsächlich schwierig sein. Schließlich ist das Thema ja auf das Scripting bezogen. Shelly ist halt kein Echtzeitsystem und die API der Firmware hat halt ihre Grenzen.
Keine Ahnung, ob die Shelly Group hier diese Umstände alle kennt. Die haben halt ihr eigenes System auf Cloud-Basis und hier scheint ja die Bluetooth Gateway Funktion einwandfrei zu laufen.

Ich hoffe eher darauf, dass die Shellys irgendwann mal eine native Funktion bekommen, dass sie Blu - Geräte direkt per MQTT weitergeben, ohne dass ein Script dafür notwendig wäre.

Ein erster Versuch könnte sein, dass du die Taster-Prellzeit, die aktuell auf 80ms steht, mal runter stellst, z.B. auf die Hälfte. Vielleicht habt ihr "zu flinke Hände"

D.h. du nutzt den Shelly mit Button type = detached ?

Es müsste doch möglich sein, dass du den Button type auf "Edge switch" stellst, also jeder Tastendruck den Ausgangszustand wieder zurückstellt.
Und dann kannst du einfach den Shelly internen Timer nutzen, diesen mit AUTO OFF = 180s stellen. Dadurch kannst du per Wandtaster das Licht immer an und aus schalten und wenn es an ist, geht es nach 3 Minuten wieder aus.

Und dann machst du 1 einzige Action URL für den Long Press und stellst dort einfach ein "switch=on&timer=7200".

Verhalten:
- Licht ist aus. Du drückst den Taster und hältst ihn gedrückt: -> Licht schaltet sofort beim Drücken ein. Sobald Long pressed Ereignis greift, wird die URL ausgelöst, welche dann den Shelly erneut mit switch=on kommandiert, Licht bleibt also an und setzt dann den Timerwert z.B. auf 7200s = 2 Stunden. Dieses überschreibt dann temporär den internen 180s Timer. Sobald du dann das Licht wieder aus machst und anschließend per kurzem Druck einschaltest, greift wieder der Standardwert.

Das habe ich gar nicht mitbekommen, dass Allterco offiziell jetzt Shelly Group ist. Gut, dann weiß ich das auch mal

Hi. Ja, ist mir heute tatsächlich auch aufgefallen, nachdem über Nacht die Temperaturen ja schlagartig abgestürzt sind und ich dann dachte, mmh, 26°C im Bad, das glaube ich nicht. Habe dann gesehen, dass keine aktualisierten Werte mehr rein kommen.

Tja, ich weiß es auch nicht, warum Alterco hier die ID geändert hat. Es gibt ja die BTHome v2 Zuteilung von IDs. Hier sind für Temperaturen 2 unterschiedliche IDs vorgesehen, nämlich die von dir genannte 0x45, und die bislang aktiv genutzte 0x02.

Hier mal der Link zur Übersicht der IDs:

https://bthome.io/format/

So,

ich konnte am Wochenende jetzt auch mal am "lebenden Objekt" testen und komme bei mir zu folgender Verhaltensbeobachtung:

- Shelly BluMotion: Beacon Modus aktiviert:
---> Shelly sendet alle 30s sauber ein Telegramm, sofern der PIR nicht aktiv ausgelöst ist.
--> Wenn man sich bewusst vorm Motion pausenlos bewegt, sodass der PIR Sensor (der ja ca. alle 2s intern auswertet) durchgehend aktivi st, dann sendet der BluMotion in dieser Zeit auch keine Telegramme, auch nicht im Beacon-Modus.
---> In allen anderen Fällen, also bei normaler Bewegung oder im Standby ohne Bewegungserkennung, werden die Telegramme sauber alle 30s gesendet. (Überprüft mit Shelly Debug App)

Weiter habe ich dann mittels BluToMQTT Script und aktiviertem Shelly Adapter geschaut und kann bestätigen, dass in dieser Konstellation tatsächlich auch mal über 10 Minuten und länger keine Telegramme im ioBroker landen, obwohl die Debug-App sie einwandfrei registriert.

Ich habe dann das Script NICHT verändert und lediglich mal MQTT umgestellt auf einen anderen Broker (nicht Shelly Adapter). Aber auch hier selbes Bild, dass teilweise über lange Zeiträume keine Daten rein kommen. Shelly Adapter aif ioBroker-Seite kann ich damit als Ursache ausschließen.

Zu guter Letzt habe ich dann im Shelly BluToMQTT Script den Parameter "Shelly_adapter" auf false gesetzt aber weiterhin auf den normalen MQTT Broker gesendet. Und siehe da, mit dieser Einstellung deutlich zuverlässiger, fast keine verlorenen Frames. Höchstens mal 1 zwischendurch, aber eben auch hier keine 100% Quote, obwohl der BluMotion nur 1 Meter vom Shelly Plus2PM entfernt montiert ist.

Fazit für mich:
- Da die Beacon Frames ja nur alle 30s abgesetzt werden, schließe ich eine Überlastung des Plus-Shelly bei der Script-Ausführung aus. Seltsam ist, dass ich noch nie den Fall hatte, dass mal das Licht nicht einschaltet, weil ein Telegramm nicht ankam.
- Ich kann die Meinung teilen, dass die Gateway-Funktion mittels Plus-Shelly noch Luft nach oben hat. Für mich aktuell ausreichend, aber da muss 100% das Ziel sein. Vielleicht tut sich ja seitens Alterco hier noch was.

Was du tun kannst ist, sobald mal das Licht wieder von selbst eingeschaltet hat, schnellst möglich, also bevor das Licht nochmal ausgeschaltet wurde etc. wieder diese STATUS-Abfrage machen.

Dort gibt es den Punkt "relays":[{"ison":false ...... "source":"...."}]

Dort müsste dann stehen "ison":true, also dass das Relay gerade eingeschaltet ist, somit das Licht an ist. Und am Ende hinter dem Wort "source":" ... dort siehst du, welches Ereignis dazu geführt hat, dass das Relay jetzt den Zustand hat.

In deinem Beispiel oben siehst du "ison":false und bei "source": steht "input". Das heißt, das Licht war zum Zeitpunkt der Statusabfrage AUS und es wurde ausgeschaltet vom externen Schalter bzw. Taster. Und wenn das Licht nun von selbst an geht, kannst du schauen, was das Einschalten ausgelöst hat. Wenn dort dann auch "input" stünde, würde es auf ein elektrisches Problem hindeuten. Aber falls es was anderes ist, z.B. aus der Cloud, siehst du es dort entsprechend und kannst dem Fehler besser auf den Grund kommen.

Jo_Be: "ihr", die ihr euch angesprochen fühlt und mal ausprobieren wollt... meinte ich damit...

Wie geschrieben, mir fehlt aktuell die Zeit, das mal selbst zu testen. Bei mir kann ich nur soviel sagen, dass ich einen BluMotion + BluButton für die Steuerung des Lichts im Bad nutze und bislang (seit ca. 8 Monaten) hatte ich nie Probleme, kein Ausfall.
Ich bin nachwievor bei dem zugegebenermaßen "Bauchgefühl", dass die Shelly Script-Variante schon tut, aber vielleicht im Beacon Modus nur dann Nutzdaten mitkommen, wenn sich auch Werte (z.B. Helligkeit) zwischen 2 Frames verändert hat. Oder eben, dass die offizielle Art des Bluetooth Gateways Probleme hat, wenn die Telegramme zyklisch kommen.

Ich werde jedenfalls interessiert weiter mitlesen, halte mich aber im Hintergrund, solange ich weiteres nicht selbst testen kann...

Noch eine Anmerkung von mir, aber kann das alles aktuell aus Zeitgründen nicht testen.

Wenn man einen Shelly Plus, resp. ESP32 dazu nutzt, als Bluetooth Gateway zu fungieren, gibt es ja die von Shelly offizielle Variante. Hierfür ist es zwingend notwendig, im jeweiligen Plus-Shelly die Option "Bluetooth Gateway" zu aktivieren.
Aber wenn man die Variante über "Scripting" wählt, um z.B. MQTT - Nachrichten zu generieren, dann gibt es dort wieder 2 Varianten, wie das Script auf die Bluetooth-Schnittstelle des Shelly zugreift, nämlich einmal aktiv oder eben passiv.

Passiv bedeutet, die Shelly API liefert die Bluetooth-Telegramme so, wie der Shelly sie halt verarbeitet und das tut er nur dann, wenn das "Bluetooth Gateway" aktiv gesetzt ist.
Im Script selbst aktiv bedeutet mehr oder weniger, dass das Script direkten Zugriff auf Bluetooth selbst hat und aktiv selbst "lauschen" kann.

Daher falls nicht schon so umgesetzt, wäre mein Vorschlag, dass ihr mal im Shelly in den Optionen die "Gateway" Funktion abschaltet und im Script die aktive Verbindung nutzt, vielleicht hat Shelly hier selbst eine Art Filter drin, der Telegramme einer MAC unterdrückt, wenn sie zu häufig kommen.

Für welchen Zweck benötigt man die beiden Umschaltrelais ?