mcast ==> Diese Einstellung habe ich nicht mehr
Der Motion unterstützt seit FW v1.1.0 kein multicast mehr.
Alle anderen Shellys werden demnächst folgen.
Also am besten jetzt schon mal alles auf unicast ändern und einen direkten Peer in den Shellys eintragen.
du kannst anstatt der unicast adresse auch "mcast" reinschreiben, dann funktionieren sie auch wieder im multicast
Aber nicht mehr lange... multicast verschwindet
hab es gerade mal getestet, das funktioniert nur, wenn auch im Shelly "mcast" als Ziel eingetragen ist..
Sobald man den Shelly auf Unicast umstellt, werden gar keine Befehle mehr über CoIoT entgegen genommen..
Könnte tatsächlich sein, dass die Shellys im unicast Mode nur noch ihren eigenen State per CoAP an den Peer senden können.
Die andere Richtung — Kommandos vom Peer an den Shelly — dann aber zwingend per HTTP/REST erfolgen muss und CoAP da nicht mehr klappt. Das wird dann wohl auch Standard werden, denn Shelly wird den multicast Support in einer der nächsten FW Versionen definitiv komplett einstellen.
Entweder ist dann „Listen CoAp for color change commands“ useless oder es soll mit dieser Einstellung für die RGB Produkte weiterhin möglich gemacht werden, per CoAP zumindest Farbbefehle senden zu können.
Wundert mich allerdings, dass dann die aktuelle Implementierung im Zusammenspiel mit diesem CoAP Listen und HA im unicast Mode gar nicht mehr läuft, wie du es sagst.
Eigentlich soll ja gerade HA mehr oder weniger nativ unterstützt sein. Oder es kommt noch ein Update im HA Plugin sobald multicast im Shelly komplett gedroppt wurde.
So aktuell macht es ja wenig Sinn, wenn das angestrebte unicast alles lahmlegt.
Man wird sehen. Bin gespannt.
Grundsätzlich lässt sich alles davon zwar auch per REST-API steuern, hat allerdings einen Vorteil.
wenn man die IP einfach weglässt, wird das Coap-Kommando an die Multicast-Adresse geschickt und ALLE Shellys, bei denen die Funktion aktiviert wurde, schalten gleichzeitig
Eine kurze Frage dazu:
Allterco plant ja den Support für Multicast einzustellen. Da ich meine Shellys in HomeKit in der aktuellen FW v1.10.1 aus noch ungeklärten Gründen nur noch in Unicast ansprechen kann, hab ich bei allen devices schon auf unicast gewechselt. Bedeutet der Wechsel auf unicast auch, dass dein genannter Vorteil von „Listen CoAp for color change commands“ ALLE Shellys gleichzeitig steuern zu können wegfällt? Oder hören die Shellys selbst weiterhin auf Multicast Traffic auch wenn sie einen unicast Peer eingetragen haben. Dann würde der eingetragene Peer nur für den ausgehenden Traffic der Shellys gelten. Hast du da etwas mehr Durchblick als ich?
Wahrscheinlich bin ich einfach zu blöd, aber dieser Distanz-Zugentlastungs-Nubsi oder für was auch immer der genau gedacht ist, führt bei mir nur dazu, dass man das Button Gehäuse kaum zusammengeschraubt bekommt.
Bei der gemäß Anleitung vorgesehenen Kabelführung pieckt dieses Teil wohl mehr das Kabel kaputt als es zu entlasten.
Wie gesagt, mir ist immer noch nicht klar wofür das überhaupt ist.
Soll es eine Zugentlastung sein? Warum dann nur für den Eingang? Zumal die Kabelführung für den Ausgang deutlich mehr Gefahr bietet herausgerissen zu werden.
Ist es ein Abstandshalter oder Stütze für den Bedienknopf um diesen ins Gehäuse drücken zu können? Warum ist der dann so platziert, dass er mit seiner Spitze auf die Zuleitung quetscht.
Aber wahrscheinlich bin ich wie gesagt eher nicht smart genug zu verstehen, wie es wirklich zusammen zu setzen ist.
Kann mich ein Button Experte vielleicht „smarter“ machen und aufklären?C166CE7B-D5E7-40FE-8E6D-57211BF5D760.jpeg
Jo, mit FW v1.10 soll der 1PM Bug für den External Switch behoben sein. Dimitar hat’s grad auf Facebook veröffentlicht. Eine 1.10_rc5 BETA zum Testen gibt es bereits. Schaun wir mal...
Edit: Wen Details zur 1.10 interessieren, hier der Link:
Kann ich bestätigen, x-mal 1PM mit Addon versucht als Schalter zum Laufen zu bringen, mit Shelly 1, läuft.
Wie gesagt, mit externem PullUp gehts einwandfrei auch beim 1PM. Ist wahrscheinlich nur nicht Allterco gewollt. Ich frag die mal an, warum die das für den 1PM bewerben und dann nur der Shelly1 klare Verhältnisse an der Data Leitung aufweist.
shelly 1PM wird noch nicht mit externen Schalter am Addon unterstützt. Evtl. Demnächst mit der neuen Firmware...
In den Release Infos für 1.9 ist die Funktion aber für den 1PM mit vermerkt.
Und was auch verwundert, wenn der 1PM außen vor ist, dass sich die Funktion in der Firmware auswählen lässt und das Relais auch wie gewünscht schaltet. Sobald die Data Leitung extern mit einem pull up versorgt ist, läuft das AddOn konfiguriert als external switch exakt so wie beschrieben. Ist also eigentlich alles funktionstüchtig bis auf die floatende Data Leitung mangels eindeutigem Potential. Aber vielleicht meinst du genau das, dass der pull up für Data im 1PM per FW nachgereicht werden muss? Das würde dann ja auch bedeuten, dass der pull up softwaregesteuert im Shelly selbst auf dem Chip sitzt?
Helfen könnte bei mehreren Kontakten oder längeren Kabeln:
An Rot liegen ca. 4,2 V an, der Data (gelb) liegt intern an 4,7kOhm gegen + 4,2V.
An Data liegt also Spannung an.
Der Schelly/Addon reagiert wenn Data nach Gnd gebrückt wird.
Zum Thema pull up an der Data Leitung mal ne Frage: Ich habe mal zum Test ohne irgendwelche echten Schaltkomponenten ein AddOn an einen 1PM gehängt, „external switch“ in der FW aktiviert und den Zustand ans Relais gekoppelt. Wenn ich die Anschlussbeschreibungen richtig deute, müsste sich also jetzt durch Brücken oder Öffnen von GND (schwarz) und Data (gelb) das Relais steuern lassen.
Meine Data Leitung hängt zwar in der Luft, sollte aber ja wegen des besagten pull up nahe Vcc Spannung gegen GND führen. Tut sie aber nicht.
Schwarz gegen Rot zeigt 4,2V an, Schwarz gegen Gelb 0,5V. Offenbar scheint meine Data Leitung zu floaten.
Das führt dazu, dass bei offener Data Leitung das Relais ca. im 1Hz Takt hin und her zu schalten.
Schließe ich Data und GND kurz bleibt das Relais sauber angezogen. Aber es fällt nicht dauerhaft ab wenn ich Data und GND wieder öffne sondern fängt wieder an zu schwingen.
Für mich wirkt das so, als würde bei mir der pull up auf der Data Leitung fehlen.
Ist das eventuell nicht generell so, dass der verbaut ist und man muss eigenständig für einen pull up sorgen? Sitzt der pull up im AddOn oder im Shelly selbst?
Hab zwei verschiedene AddOns getestet, mit beiden zeigt der 1PM das geschilderte Verhalten.
Oder — wenn der Shelly selbst verantwortlich ist — gibt es einen Unterschied zwischen Shelly1 und 1PM? Konnte nur mit einem 1PM testen, aber das Verhalten verwundert mich, nachdem ich hier gelesen habe, das Data über einen pull up auf Vcc liegen sollte.
Jemand einen Tipp?
Gibt es arge Bedenken ioBroker von SD Karte laufen zu lassen? Macht das Teil derart viele Schreibzugriffe dass das nicht ratsam ist? Hab derzeit HOOBS auf SD an einem Pi3 laufen. Läuft seit etwas über 1 Jahr. Bisher gab’s da noch keine zerfledderte SD. Aber vielleicht schreibt ioBroker auch deutlich mehr als HOOBS.
Frage weil hier alle von SSD sprechen bei diesem konkreten Thema ioBroker und HOOBS parallel laufen zu lassen.
Wichtigste Pandemie-und-Elektroregel: Abstand halten ?
Da wird’s dann wohl zu eng und schon zu kuschelig warm... ???
Der Beitrag ist ja schon nicht mehr ganz neu, aber sagt mal, hat einer von euch dieses Vorhaben mit mehreren Shellies im Verteilerschrank und 3D-DIN-Haltern schon realisiert und Live Erfahrungen gesammelt?
Wenn ja, wie genau habt ihr die Halter und Shellies zueinander positioniert? Doppelhalter mit dem empfohlenen Abstand einer halben TE zueinander? Braucht ja ordentlich mehr Platz im Schrank aber wohl wärmstens empfohlen im wahrsten Sinne des Wortes.
Was sagen eure Erfahrungen zum Statement des Herstellers:
„Each shelly device emits heat. Do not place 2 or more shelly devices stacked on top of each other in the same box. There must be a minimum distance of 1 cm between them. Otherwise it is not safe“
(https://www.facebook.com/groups/ShellyI…23402417759097/)
Ein anderer User hat wohl schon ähnlich Probleme gemeldet:
https://www.facebook.com/groups/ShellyI…44159845683354/
Vielleicht doch nicht die beste Idee mehrere oder viele Shellies zusammen im Verteilerschrank zu platzieren?
Alle Shellies mit Powermessung geben mehr oder weniger deutlich Wärme ab, besonders der 2.5er aber eben auch der 1PM und der Dimmer.
Habt ihr bei eurer Umsetzung da schon Erfahrungen sammeln können ob das tatsächlich problematisch wird oder werden könnte?
Es ist ganz einfach: Cloud oder MQTT aber http geht immer
Hab mittlerweile 4 verschiedene Raspberrys mit verschiedenen Systemen.
Richtig cool finde ich das Hoobsimage (Alexa und Siri) auf den Raspberry 4/4GB mit IO Broker ( mit NodeRed als Adapter) . So steht dir ziemlich alles offen! Bin aber am überlegen das Image auf einer SSD zu übertragen da die SD Karte eine Schwachstelle ist.
Wo ich das hier lese eine kleine Zwischenfrage:
Hast du das bei dir aktuell so am laufen? ioBroker nachträglich auf dem gleichen Pi installiert auf dem das HOOBS Image läuft?
Das wollte ich auch gern angehen, aber bisher hatte mir noch niemand konkret sagen können, ob die Installation von ioBroker auf dem HOOBS Image einfach so klappt und sich da nichts in die Quere kommt. Wenn jemand was dazu sagte hieß es nein, würde nur gehen, wenn man nicht HOOBS als Image sondern homebridge manuell installiert hätte. Aber rein seitens der Dienste-Ports beider Applikationen (HOOBS/ioBroker) sollte es eigentlich ohne große Anpassungen klappen können. Das ist natürlich nicht alles, was es da zu beachten gilt.
Wenn du da also schon Erfahrung hast, wäre das toll zu wissen, ob das einfach out of the box funktioniert oder nicht, bevor ich mit einem Versuch mein HOOBS Image temporär über den Jordan schicke.
Kannst du mir, damit ich dabei auch dazu lerne, sagen, wie man diese HTTP Befehle aus der API rausliest?
https://shelly-api-docs.shelly.cloud/#settings
ich hab es mit so Varianten wie IP/roller/go=open und IP/roller/go:open probiert. Ganz falsch war ich also wohl nicht, aber auf das 0? wäre ich nie gekommen.
Die Shelly API basiert auf REST und arbeitet mit entsprechenden URL‘s und sog. Endpunkten. Jeder Endpunkt steuert dabei bestimmte Aktionen (über entsprechende Parameter mit dazugehörigen Parameterwerten) oder liefert gewisse Informationen zum Status (über entsprechende Attribute) des dahinter liegenden (Web) Dienstes.
So gibt es z. B. beim 2.5 den Endpoint /roller/0/ und für diesen Endpoint existiert das Attribut state welches Informationen über den aktuellen Status der beiden Relais (oder besser gesagt den übersetzten Status des damit angesteuerten Antriebs) gibt (nämlich stop, open, close).
Über Parameter und dazugehörigen Werten lassen sich hingegen Aktionen ansteuern. /roller/0/ besitzt beispielsweise den Parameter go der einen der Werte open, close, stop oder to_pos annehmen kann. Attribute sind per Slash (/) vom Endpoint getrennt. Parameter trennt die Shelly API mit Fragezeichen (?) vom Endpoint. Der Parameterwert wird anschließend mit einem =-Zeichen zugewiesen.
In deinem konkreten Fall heißt das also, /roller/0/ ist der Endpoint, go der Parameter und die Parameterwerte sind entweder close, stop oder open.
Also für:
Antrieb AUF —> http://xxx.xxx.xxx.xxx/roller/0?go=open
Antrieb AB —> http://xxx.xxx.xxx.xxx/roller/0?go=close
Antrieb STOP —> http://xxx.xxx.xxx.xxx/roller/0?go=stop
Hoffe das erläutert etwas die generelle Syntax der API.
Mal noch eine andere Frage:
Ich habe noch einen drehbaren Rollladentaster, sieht also von der Bedienung so aus:
https://www.rolladen-shopping.de/Rollladenschal…-Knebel-AP.html
Was passiert, wenn ich den Tastimpuls für nach unten gebe und dann nach oben statt nochmal nach unten drehe? Stoppt er oder fährt er nach oben?
Bei Button Type Toggle schaltet der 2.5 die Ausgänge nur solange an den SW Eingängen die Steuerspannung anliegt. Geht der Drehschalter in die Ruhestellung (Mittelposition) zurück, stoppt der Antrieb.
Steht Button Type auf Momentary reicht ein Tastimpuls an den Eingängen, um den Antrieb in die jeweilige Richtung zu triggern.
Dabei ist die Logik wie folgt:
Ist hoffentlich ausreichend verständlich.
Jepp, funzt. Hab die Homebridge gerade aufgesetzt.
Allerdings geht HOOBS wohl nicht, man muss die Homebridge selbst auf dem Raspi installieren und konfigurieren. Oder hast du evtl. HOOBS parallel drauf bekommen?
Hat mit dem Thema ioBroker und HOOBS parallel schon jemand Erfahrung sammeln können und weiß ob das möglich ist?
Liegt dann wohl an den hohen Induktionsspannungen die durch die Starter erzeugt werden, das Leuchtstofflampen so gar nicht funktionieren...
Auf jeden Fall macht mein Bad- und Dunstabzugs-Lüfter meinem 1PM zu schaffen. Er stirbt zwar nicht unwiederbringlich, aber bis zum ausschalten der Versorgung legt er sich vollständig in Ohnmacht.
Wohl ähnliches Störungsprinzip aber wegen geringerer Spannungsspitzen überlebt die Elektronik irgendwie, wenn sie auch völlig lahmgelegt wird.
Warum der 2.5 dann bei Rohrmotoren keine Probleme macht ist mir allerdings nicht ganz einleuchtend...
Gibt es seitens der Elektronik in punkto schalten induktiver Lasten einen Unterschied zwischen dem 1PM und dem 2.5?
Also konkret: Ist es wahrscheinlicher, dass sich ein Lüftermotor im Bad oder für die Dunsthaube in der Küche mit einem 2.5 problemloser verhält, wenn deren Schaltung einem 1PM Probleme macht? Immerhin ist der 2.5 bei Ansteuerung von Rollladen Antrieben ja grundsätzlich funktional, da geht es ja auch um die Schaltung von Motoren.
Sofern die Aussage von alsk1 zutreffend ist, müsste der 2.5 da allerdings die gleichen Probleme haben, wie der 1PM. Leistungsmessung haben sie ja beide. Oder gelten Rolladenmotoren aufgrund ihrer Bauart eher nicht als induktive Lasten? Ist dann ein Lüftermotor oder eine Leuchtstofflampe mit KVG eine „herausforderndere“ Last als ein Rohrmotor?
Hab das gleiche Problem bei einem Shelly 1PM der einen Lüftermotor steuert. Hat jemand eine entstörende Möglichkeit der Abhilfe gefunden ohne ein Koppelrelais einzusetzen oder auf den Shelly 1 zu wechseln?
Heißt das also, der 1PM ist ungeeignet zum Schalten induktiver Lasten?
Es wird übrigens auch ein Device namens SHRGBWW-01 gelistet.
Ist da vielleicht ein neuer 5-Kanal Controller in der Pipeline oder ist das vielleicht einfach nur die FW für den white mode?
