Hi barry,
yes... that would bei nice....
But do you know any Shelly the Input-potential is independent from power supply?
VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
Hi barry,
yes... that would bei nice....
But do you know any Shelly the Input-potential is independent from power supply?
Was würde denn passieren, wenn statt dem I3 mal der Shelly-Adapter im ioBroker neu gestartet wird?
Ich habe ja auch seit Monaten das Problem, dass alle Shellys brav in der App und via NodeRed arbeiten und nur immer wieder im ioBroker "einfrieren" - bis heute ohne Ergebnis/Lösung... nur Adapter Restart hilft für mehr oder weniger lange Zeit...
Bin daher auf dem Weg Richtung MQTT...
Darf ich fragen, wozu dann ioBroker benötigt wird?
Na klar....
Ich war anfangs genauso überfordert, wie der TE, der seine Shellydaten via ioBroker/NodeRed im Homee visualisieren will.
Trotz etlicher Videos wußte ich ewig nicht, was wie funktioniert, und was welche Vorsusetzungen braucht - wahrscheinlich habe ich mich selbst duch meine SPS-Vergangenheit blockiert... egal.
Ich hatte mit NodeRed begonnen und wollte die Shellywelt und die Eaton-E4-Welt zusammenbringen. Irgendwie hat das alles nicht so geklappt und mich stört bis heute, dass die Zustandsänderungen eines Shelly in NodRed erst nach ausdrücklichem Nachfragen (pollen) ankommen. Auch hat mich die Fülle der Daten, die bei Statusabgfrage reinkommen schier überfordert.
Da bin ich dann auf ioBroker umgeschwenkt, der mir alle Daten schön aufgeschlüsselt und anwählbar in seiner Liste der Objects präsentiert.
Mittlerweile habe ich darüber auch meinen Wechselrichter und andere Dinge laufen - und weiter die Shellys.
Allerdings bin ich da auch wieder nicht wirklich zufrieden, da sich bei mir der Shelly-Adapter mal gerne mehr oder weniger "verabschiedet" dass alle Werte der Shellys (komischerweise bis auf Uptime) eingefroren sind (in der Shelly-App und in NodeRed sind die Stati weiter aktualisiert verfügbar/steuerbar). Erst ein Adapterneustart bringt Abhilfe (manchmal nur für wenige Minuten, manchmal locker für den Rest des Tages - Nachts wird eh ein Neustart gemacht).
Also hier geschildert/gefragt, in Fb gefragt... ohne greifbare Ergebnisse/Hinweise/Ideen.
Also wieder mit NodeRed rumprobiert und wieder feststellen müssen, dass die Shelly-Nodes trotz einer einstellbarer "Poll-Time" nix von selbst bringen - ohne inject o.ä.
Jetzt wage ich mich an MQTT, weil ich mittlerweile auch begriffen habe, wie ich via Telegram steuern/auswerten kann - und so keine Shelly-Cloud mehr benötige, um aus der Ferne zu agieren. Zudem kommen auch in NodeRed via MQTT alle Werte so prompt rein, wie ich das via COAP beim ioBroker schätzen gelernt habe...
Vielleicht wird der ioBroker bei mir igendwann obsolet, aber zur Zeit komme ich mit der Kombination ganz gut klar:
ioBroker als Basis und alles andere als Adapter darin versammelt...
Probier es doch mal damit:
Oder meinst Du mit Script einen NodeRed-Flow?
Hallo zusammen,
ich taste mich seit ein paar Tagen an die MQTT-Anbindung heran und bin damit im Grunde auch erfolgreich.
Testweise habe ich einen Shelly-I3 und zwei Shelly1PM auf MQTT konfiguriert.
Broker ist der MQTT-Adapter im ioBroker und auswerten/steuern will ich mit NoderRed, welches auch als ioBroker-Adapterläuft.
Als sehr nützliches Hilfsmittel "was so abgeht" nutze ich MQTT.fx V1.7.1
Jetzt habe ich festgestellt, dass sich die MQTT-Konfiguration in der aktuellen Firmware doch etwas von der oben gezeigten unterscheidet:
Sehr schön ist, dass man nun ein individuelles Prefix kreieren kann, welches die MQTT-topics einleitet. Das macht das Wiederfinden/Zuordnen einfacher, als die bisher üblichen Seriennummer-Kryptogramme.
Dafür ist "Will Topic" und "Will Message" nicht mehr als Eingabefelder vorhanden - wird aber, wie oben sichtbar. Wobei diese "alive"-Meldung nur einmal bei Verlust der Verbindung mit "false" und bei Wiederverbindung mit "true" erscheint. Im "normalen" Betrieb erscheint der "alive"-Status nicht mehr.
Was ich noch nicht herausgefunden habe:
Was verbirgt sich hinter der Option "Retain" - im Grunde kenne ich diese schon, aber was macht das bei den Shellies?
Was kann ich mit Max QoS einstellen? Wenn ich "Min" QoS bestimmen könnte, das wäre mir einleuchtend - aber max QoS... Wer bestimmt wann, welcher QoS-Level genutzt wird, wenn ich z.B. max 2 einstelle?
Nochmal ich...
kann das sein, dass es mit dem Port, den der ioBroker bei mir hat (8081) nicht funktioniert?
Ich hab dann mal nur die IP im Shelly eingetragen - ohne Port (meine ich letzthin mal in einem Tutorial gesehen zu haben) - und dann hat der Shelly selbst einen Port dahinter gesetzt (5683).
Jetzt funktioniert es...
Jetzt komme ich noch um die Ecke:
Wenn ich unicast eintrage bzw. die IP meines Raspberry4 mit Port vom ioBroker, dann bekommt NUR der Shelly-Adapter die Daten? Oder auch mein NodeRed, welches als Adapter meines ioBroker läuft?
Hi,
both questions: Yes.
Warum hast du in die Abfrage (Wann) nicht direkt einen Eingang vom I3 genommen?
ich habe meine Szene erstellt und einen funktionierenden Szenenlink mit Cloudkey usw.... habe diesen Link als Toggle "Button Switched on URL" eingetragen, aber nichts passiert. Was mache ich falsch?
Dann zeig doch mal die Szene und den Link
Yes that is what I ve done on my previous post (batch update shellys 1st, then update my wifi password), no sucess
It seems the batch was not succesful, because you say:
Just tried to put back previous wifi password and e everything works again.
Maybe you batch ist not working well...
How many are "a few shelly"? Less than 20? Than I would do the modification manually...
Soweit ich weiß kann der I3 5 HTTP-Befehle PRO KANAL absondern. Und das in Kombination mit unterschiedlichen Schaltvorgängen (z.B. Short für Hochfahren und Longpress zum Schließen) müsste doch funktionieren.
Wie machst Du das denn bisher?
Diese Auswertung kann ich nur fahren, wenn der Controller am SW Eingang hängt.
Da der Shelly jedoch über den detached Modus betrieben werden muss, wird ein "Aus" Befehl dann nicht direkt durchgreifen, sondern müsste über eine Software realisiert werden (die auf verschiedene Weise ausfallen könnte).
Ich schlage vor, dass du den Gedankengang, den du fährst mal in Form eines Schaltplans darstellst... Wenn ich das lese befürchte ich da einige unnötige Knoten im Konstrukt.
Allein "Da der Shelly jedoch über den detached Modus betrieben werden muss..." da gibts 100% alternative Lösungen, die dein Sicherheitsbedüfnis befriedigen...
Trotzdem muss ich jedoch über meine Skripte auswerten können, ob der Controller eine Anforderung gesendet hat.
Was hindert dich?
Wenn du nur bestimmte Shellys zugänglich machen willst, dann nutze doch die "Share"-Funktion.
Ja Mensch.... wenn Du einen ioBroker hast, dann stellen sich doch die ganzen Fragen gar nicht.
Schreib ein passendes Blockly, oder JS und damit ist doch "der Fisch geputzt"...
Außerdem schließt die Ansteuerung eines "dummen Relais" nicht die Auswertung im ioBroker aus.
Hi,
sounds good - I never used scenes.
My idea/explanation was created really "offline"...
I think the lag is a combination of Internetspeed/Cloudserver and the Powermeter of the shelly. The meter is not sending/testing every Millisecond. I think ist is around each 1 or 2 sec.
The solution I created was because of your requirement only to use one Shelly-device.
I would prefer two Shelly (Shelly 1 or Shelly 1PM) to have a full single control for each lamp and additionally it will work nearly without a noticeable delay.
With two shelly you can use the existing switch to turn on/off the first lamp manually and the second lamp corresponding or indenpendent. But also you can control each lamp with the App.
I don't know OpenHab enough but I think, it is compareable to ioBroker (I use this).
With such a control system you can manage the devices/lamps again much more comfortable.