Noch eine ganz einfache und banale Möglichkeit wäre, dass du dir in Reihe zum Shelly - Relaiskontakt einfach noch einen mechanischen Schalter installierst.
Kann auch z.B. ein Schlüsselschalter sein. Darüber kannst du dann im Urlaub z.B. den Schaltkontakt des Shelly einfach unterbrechen, sodass auch bei Shelly-Ansteuerung der Torantrieb kein Schaltsignal bekommt und trotzdem hättest du über Cloud dann weiterhin den ZU/AUF Status (falls einer das Tor anderweitig geöffnet bekäme).
Hallo zusammen,
mir ist heute im ioBroker aufgefallen, das der Shelly Plus2PM, auf das Blu to MQTT 1.3 Script läuft, alle 6 Stunden eine Warnung im ioBroker LOG hervorruft mit der Meldung:
[authEnabled] 192.168.178.165 (shellyplus2pm / shellyplus2pm-44xxxxxxx / shellyplus2pm#44xxxxxxxx#1): BLE-Script version is invalid, check documentation for updated version
Woher kommt denn diese Meldung und was hat es damit auf sich ?
Erst gestern neu eingerichtete Geräte (Ein Shelly Plus 2 PM und ein Shelly Plus Plug S) sind nun trotz guter Signalstärke offline.
Wie sieht denn deine WLAN Infrastruktur aus, in der die Shellys eingebunden sind ?
Alles klar, und nochmals ein Dankeschön.
Natürlich keine neuen Erkenntnisse ohne neue Fragen... Von daher: Habe den Unterschied verstanden zwischen aktivem und passivem Scan, habe selbst auch vor kurzem mit einem Bluetooth LE Dongle über GAP gearbeitet, Characteristics beschrieben etc.
Bei den Shelly Blu - Geräten, zumindest jetzt beim unverschlüsselten Verarbeiten, gibt es ja kein Connect oder Bonding zum Gerät, es wird lediglich das Advertising frame empfangen und dessen Inhalt genügt ja für die Anforderungen einer Nutzung im Hausautomatisierungsbereich.
Was genau liefert denn ein Blu Device als Scan Response string an zusätzlichen Infos, wenn man den aktiven Scan verwendet ?
Mit dem, was ich in der BLE namespace Beschreibung gelesen habe und was du bereits dazu geschrieben hast, habe ich natürlich wieder ein anderes Bild von der Sache und werde den Scan dann wieder auf passiv ändern.
Erklärt dann jetzt auch, warum das auf die Latenz quasi keine Auswirkung hat.
Aber wenn du doch sowieso ioBroker etc. nutzt, also auch ein System, was 24/7 online ist und Strom verbraucht, dann ist es doch auch kein Thema, dass du die gesamte Heizungslogik dort direkt abbildest ?
Macht in meinen Augen keinen Sinn, dem Shelly vom übergeordneten System zu sagen, ob er durchschalten soll, wenn das Thermostat schaltet oder eben nicht. Mach doch einfach im ioBroker die Abfrage auf Erreichbarkeit des betreffenden Shellys und wenn er erreichbar wird, weißt du, Thermostat hat geschaltet und dann kannst du ja als Trigger im Script etc. auf dieses Ereignis reagieren und das Relais des Shelly dann aktiv schalten oder eben nicht.
Den Shelly verzögert einschalten lassen nach Wiederherstellung der Versorungsspannung wüsste ich jetzt auch nichts konkretes.
Den einzigen Ansatz, den ich hätte, wäre, dass du den Ausgang vom Thermostat zusätzlich zum Anschluss an L des Shelly auch noch an den SW Input legst.
Mit etwas Glück wertet der Shelly den HIGH Pegel am Input dann als Event aus, aber das müsstest du ausprobieren.
Wenn das klappt, müsstest du den Button type Input auf "detached" stellen und als URL Action unter "BUTTON 1 SWITCHED ON" das Relais, wie oben von dir beschrieben, per localhost Anweisung ansteuern, aber als Einschaltverzögerung:
http://localhost/relay/0?turn=off&timer=20Wie geschrieben, ich weiß nicht, wie sich der Shelly beim Boot-up verhält nach Wiederherstellung seiner Versorgung, wenn dann sofort auch L Potential am SW Input liegt. Ob er das direkt als Trigger auswertet oder ob er einfach gar nichts tut. Wenn es klappt, wird beim Schalten des Thermostats der Shelly starten, auf das Event reagieren und dann nach 20s sein Relais einschalten.
Wenn du dann im ioBroker mitbekommst, der Shelly meldet sich per MQTT, kannst du dann aktiv sagen, http://IPdesShelly/relay/0?turn=off, wenn du nicht willst, dass der Shelly nach den 20s einschaltet.
Das neue Kommando überschreibt das letzte, sodass die Einschaltverzögerung dann verworfen wird.
With Dimmer2 set to "One button mode", the second input is set to detached automatically.
If you connect a separate wall button to that input, you can use the "Button 2 switched on" and "Button 2 switched off" events to be able to control the smart light bulb.
Use the "BUTTON 2 SWITCHED ON" event to send the dim-command to your smart bulb. Now the bulb will do the dimming as long as you keep the button pressed.
Use the "BUTTON 2 SWITCHED OFF" event to stop the dimming.
Edit: @ dewaldo Nur wenn du die pid immer noch willst.
Hi De kat,
ich antworte stellvertretend auf dieses Zitat.
Also, erst mal, Missverständnis nein, habe das schon alles richtig verstanden. Meine Frage ging in die Richtung deiner 2. Erläuterung, nämlich dass ich mehrere Plus 2PM habe und auf mehreren würde ich ggfs. das Script laufen lassen, natürlich auf jedem nur 1 Mal, wüsste nicht, warum man auf die Idee käme, es 2x auf einem Gateway zu betreiben.
Und genau das war meine Frage, wie das ist, wenn z.B. ein Blu Motion eine Bewegung erkennt, er dann das Bluetooth Telegramm samit PID sendet, dieses von z.B. 3 Shellys aufgeschnappt wird und im ioBroker entsprechend 3 MQTT Nachrichten eintrudeln, die alle zum selben Blu Event gehören.
Und hier hatte ich es so verstanden, dass der Shelly Adapter im ioBroker schon so "designed" wäre, dass er die MQTT Nachrichten ja natürlich eingruppiert und hier vielleicht dabei automatisch Events vom selben Blu Device unterdrückt, wenn die PID sich nicht ändert. Wäre ja keine große Sache und hätte für eigene ioBroker Scripte den Vorteil, dass man nicht mehrere Trigger für dasselbe Event berücksichtigen müsste.
Aber das kann ich ja einfach ausprobieren und zur Not muss ich es halt selbst abfangen.
Der Hinweis mit dem ECO-Modus ist gut, da hatte ich noch gar nicht dran gedacht, teste ich mal, ob das eine Auswirkung hat.
Alle anderen Faktoren sind größtenteils gegeben, WLAN, keine Cloud, keine sonstigen Actions oder Scripte. Der Shelly langweilt sich bei mir auf jeden Fall ansonsten.
Detached arbeitet er nicht, ist halt als Rollladensteuerung im Einsatz, aber wenn es bei den von mir beobachteten 0,5s liegt, ist das ja echt ok.
Mich hatte nur gewundert, dass ich überhaupt keine Unterschiede merke zwischen aktivem und passivem Blutooth Scan, entsprechend mit der Option "Gateway aktiv" und "nicht aktiv".
Ich lasse es auf "nicht aktiv" und nutze den aktiven Scan. Vermute fast, dass dadurch ohnehin der ECO-Modus kaum noch aktiv ist, weil die CPU dann vermutlich ja permanent mit pollen beschäftigt ist.
Mit den bisherigen Erkenntnissen und Tests komme ich auf jeden Fall schon gut klar für die akuten Dinge, die ich umsetzen möchte.
Alles weitere kommt mit der Zeit.
Kann nur nochmal sagen, super Job und vielen Dank.
Vielen lieben Dank.
Ich hatte das mit der PID schon richtig verstanden, aber nicht, wie der Shelly Adapter mit den Bluetooth Topics umgeht.
Ich dachte, wenn die MQTT Daten so kommen, wie es der Adapter seit 6.6.0 versteht, landen alle "Events" dann in der Adapter Objektansicht unter ble/events.
Der JSON String im jeweiligen "Gateway" ist mir zwar schon mal aufgefallen, aber da hatte ich jetzt gar nicht nach geschaut, sondern es nur im MQTT Adapter getestet.
Na dann vertraue ich mal auf den Adapter, dass der dann Events unterdrückt, wenn mehrere Gateways das identische Telegramm empfangen.
Noch eine abschließende Frage für den Moment, ich möchte auch nicht zu sehr nerven, bin aber noch ganz am Anfang mit den BLU Geräten.
Ich habe jetzt auch einen BLU Motion in Betrieb genommen und mit dem System aus Plus-Shelly, deinem Script und ioBroker mit Shelly Adapter habe ich eine Latenz von Bewegungserkennung (rotes Licht), bis dann das Signal im ioBroker aufschlägt, von ca. 0,5s.
Ich habe versucht, die Blutooth Gateway Funktion im Plus Shelly zu aktivieren und zu deaktivieren und im Script zwischen aktiv und passivem Scan zu wechseln, aber ich muss sagen, egal, welche Variante, die Latenz scheint nahezu konstant zu sein.
Ist das korrekt ?
In der Debug-App wird das Frame quasi in Echtzeit ohne Verzögerung angezeigt.
Eine Frage noch zu den Blu Events:
In den advertising frames, z.B: beim Button wird mit jedem frame die packet_id zum 1 erhöht.
Ist es möglich, die ID mit in die Events zu packen ?
Das wäre sehr nützlich, wenn z.B. 3 oder 4 Plus Shellys das Script laufen haben und alle das Bluetooth Signal empfangen haben, dann würde das über MQTT und ioBroker Scripts mehrere Events auslösen, obwohl es nur 1 ist. Über die Paket-ID könnte man das entsprechend abfangen.
Edit:
Ich habe mir mal die BTHome Doku angesehen und dann auch gesehen, dass die pid 0x00 schon enthalten ist.
Vermutlich ist der Shelly Adapter dann nicht dafür ausgelegt, das Topic anzuzeigen...
Vielleicht muss ich dann doch auf den MQTT Adapter umsteigen statt des Shelly Adapters.
Genau, den Hinweis von funkenwerner wollte ich auch gerade nennen, aber bei Nutzung z.B. unter Windows. Wenn du den Ansatz verfolgst, mehrere Browserfenster zu nutzen, immer dran denken, bei Wechsel auf nächsten Shelly die Seite mit STRG + F5 neu zu laden, damit der Cache auch erneuert wird, sonst kann das ganz lustige Effekte bringen.
Wobei ich sagen muss, das war vor allem bei GEN1 so, die GEN2 Webinterfaces sind anders aufgebaut, hier hatte ich bislang noch keine Cache-bedingten Verwirrungen.
Genau. Wenn du den Shelly quasi so betreibst wie einen der Wandtaster, dass der Shelly das Stromstoßrelais bestromt, dann musst du auch dafür sorgen, dass sich der Shelly auch wie ein Taster verhält und nicht wie ein Schalter. Auto-Off kannst du dafür im Shelly aktivieren. Dann schaltest du den Shelly ein und der schaltet den Ausgang nach der Auto-Off Zeit wieder aus. Hier reicht auch 1 Sekunde.
Wenn du Auto-Off nicht konfigurierst bei so einer Installation, dann passiert genau das, was du erfahren hast. Der Shelly schaltet Strom auf das Stromstoßrelais und bleibt ab dann durchgehend an.
Nun willst du das Licht ausschalten, schaltest also den Shelly aus. Was passiert dann ? Nix. Das ist dann so, als würdest du den Wandtaster in dem Moment los lassen und hättest ihn zuvor durchgehend gedrückt gehalten.
Und erst, wenn du dann den Shelly nochmal anschaltest, geht das Licht aus, weil das der nächste Stromimpuls für den Stromstoßschalter ist.
Ein weiterer Punkt ist, wenn du Auto-Off nicht einstellst, und der Shelly bleibt dauerhaft ein, dann bestromst du auch den Stromstoßschaltr dauerhaft. Je nachdem, wie alt der ist und welche Technik drin steckt, kannst du den damit auch zerstören, weil seine Relaisspule ggfs. überhitzen kann.
GU5.3 sind Niederspannungs-Fassungen!
Der Dimmer2 ist ein 230V Phasenan-/abschnittdimmer.
Das heißt, du kannst so direkt nicht nach GU5.3 Lampen suchen, die mit dem Dimmer2 kompatibel sind, weil es hier keinen gemeinsamen Nenner gibt.
Die GU5.3 LEDs müssen dimmbar sein, und die Spannungsart muss passen.
Noch 2 Hinweise:
1.) Der von dir verwendete Trafo ist TRIAC dimmbar, d.h. im Dimmer2 solltest du schon mal beim Kalibrieren die Dimmart fix auf "Leading edge" stellen.
2.) Der Trafo hat einen 11,5V AC Ausgang, ist also eher klassischerweise für das Dimmen von 12V Halogen geeignet. Die von dir genannten LEDs sind ausschließlich für 12VDC geeignet, daher flackern die.
Du müsstest also entweder den Trafo wechseln gegen einen mit DC Ausgang oder deine Lampen tauschen gegen LEDs, die sowohl mit AC als auch DC klarkommen.
Sieht eigentlich alles korrekt aus.
Vielleicht ist beim sendenden Shelly noch der AP Modus aktiv, sodass der Shelly ggfs. versucht, den request im falschen Netz abzusetzen (klingt aber weit her geholt, ich weiß).
Wenn beide im gleichen Subnetz sind, sollten auch externe Ursachen in der Regel nicht existieren, aber wer weiß...
Z.B. dass der sendende Shelly als Client isoliert ist, aber dann kämst du auch nicht auf dessen WebInterface...
Ich glaube am ehesten an einen Bug, muss ich ehrlicherweise sagen.
Aber wenn du PLUS Shellys verwendest, sollstest du anstatt der alten GEN1-API mal die offizielle der GEN2 und GEN3 verwenden, also über rpc und switch Zugriff, dann sollte es klappen.
Ich hätte noch einen Tipp, der ggfs. in manchen Konstellationen helfen kann.
Bei meinen GU10 LEDs ist es so, dass die Kalibrierung halt erkennt, wann Leistung fließt und diesen Punkt merkt sich der Dimmer als quasi tiefsten Dimmwert.
Aber die LED Netzteile brauchen bei der stark angeschnittenen Phase länger, bis die Versorgung sauber ansteht (blöd formuliert, aber hoffe, es ist klar, was ich meine).
Dadurch verfälscht das den Punkt der tiefst möglichen Dimmung und man erhält im unteren Helligkeitsbereich einen zu kleinen Stellbereich.
Ich habe mir damit beholfen, dass ich beim Kalibrieren 1 LED entfernt habe und stattdessen eine dimmbare IKEA LED verwendet habe.
Diese starten schon bei kleineren Phasenwinkeln, weshalb der Dimmer dadurch die niedrigste Dimmstufe weiter unten setzt.
Dadurch komme ich im unteren Bereich weiter nach unten und habe dort noch 2-3 Schritte mehr, wo es sonst schon die LEDs komplett abdunkelt.
Alles klar, vielen Dank für die Erläuterung mit dem Brückengleichrichter. Also keine galvanische Trennung, aber in vorliegendem Fall passt es dann.
Wie ist denn das beim Shelly UNI ADC Input ?
Das ist dann wahrscheinlich auch nicht direkt der "echte ADC" vom Esp8266 via Spannungsteiler, sondern vermutlich sowas ähnliches wie bei den Add-On Modulen mit der galvanischen Trennung, oder ?
Wie sieht es dann mit dem GND Potential von Pin 2 gegenüber Pin 6 aus ? Normal würde ich erwarten, dass die beiden intern gebrückt wären ?
Wenn Spannungswerte weiterhin angezeigt werden, solltest du mal prüfen, ob der / die Wechselrichter überhaupt ordungsgemäß arbeiten ?
Die werden ja sicher Status-LEDs oder sowas haben, von daher mal kontrollieren. Vielleicht ist beim Modultausch was schief gegangen, Polarität verwechselt etc...
möglich und notwendig, denn darüber erhält man schreib Zugriff, bzw besondere Zugriffsrechte, es können Daten auf das Gerät übertragen werden, zudem läuft das ganze gesichert über den default passkey.
Das ist aber nur notwendig, um z.B. Firmware zu aktualisieren etc., nicht für den eigentlichen Betrieb, oder ?
Das Advertising, also dass z.B. jemand auf den Blu Button gedrückt hat, wird doch immer unverschlüsselt per Advertising Frame übermittelt, das könnte also "draußen" jeder mithören, z.B. mit der Shelly Debug App, oder ist die eigentliche Anwendung so gedacht, dass man den Blu Button gezielt mit einem bestimmten PLUS Shelly oder dem Gateway paired, und dass dann der Button sich jedesmal erst mit dem PLUS connected, um die Daten verschlüsselt zu übertragen ? Das wäre ja wahrscheinlich nicht förderlich für die Reaktionszeiten...
Hi Martin.
Das hatte ich sogar überlesen. Hatte das schon richtig verstanden, dass du meinst, es muss NICHT press sein 