Beiträge von Eulhofer

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.

    Nutzt du ioBroker mit CoAp?


    Ich 3 Stück davon und bei mir wurden die CoAp-Daten gefiltert. Nach dem Austausch sofort alles wieder gut.. Da die Dinger ja unmanged sind, keine Chance da etwas zu konfigurieren..


    https://www.amazon.de/-/en/TP-Link-T…k/dp/B01EXDG2MO

    Ja, ioBroker via CoAp, Blockly-Skripte, Telegram-Menü, NodeRed-Adapter (inkl.Dashboard)... alles läuft in alle Richtungen tadellos...

    Ich hatte erst gedacht, ich müsste für die Shellys mit MQTT arbeiten - aber bisher sehe ich für dei Umstellung noch keine Notwendigkeit/Benefit...

    Dein Switch blockiert vermutlich ihm unbekannte UDP-Multicast-Pakete (CoAp)...

    hab ebenfalls TP Link Switche mit exakt diesem Verhalten hier und sie deshalb mittlerweile rausgeworfen..

    Schon komisch... ich habe exakt diese Switches von TP-Link, die Martin oben anführt.

    Und die habe ich z.T. sogar kaskadiert in meinem Netzwerkflickenteppich (Topologie will ich das gar nicht nennen :S) laufen - völlig ohne Probleme.

    Immer wieder erstaunlich wie unterschiedlich die Dinge funktionieren/nicht funktionieren. (Man sehe sich an, wie viele seit dem FW1.9 Probleme haben - bei mir läuft alles super).

    Ich befürchte auch schon eine ganze Zeit beim Lesen hier, dass der FI schon "hart an seiner Grenze" betrieben wird - meint, dass wahrscheinlich schon einige mA Fehlerstrom fließen und der Shelly den brühmten "Tropfen" beisteuert, der zum Auslösen führt.

    Ist an der Außensteckdose etwas angeschlossen?

    Wenn nicht und der Neutralleiter ist tatsächlich identisch, wie die Schaltung, wo der Shelly hängt, dann vielleicht mal einen ordentlichen Verbraucher einstecken (Strahler, Staubsauger, Heizlüfter o.ä.).

    Wenn der N nicht einwandfrei ist, dann müßte der FI ruck zuck auslösen, sobald das Gerät eingeschaltet ist.

    Falls die Gartensteckdose in so einer Säule montiert ist, kommen da von unten auch mal gerne Ameisen & Co. rein und räumen die Säule voll Erde - dann gibts Feuchtigkeit, die auch Ströme Richtung Erde/PE zur Folge haben können...

    Hallo zusammen,

    ich habe Beleuchtungen mit Shellys, die ich sowohl über die angeschlossenen (verdrahteten) Schalter, als auch über die App oder per Telegram schalte.

    Mein Dashboard in NodeRed zeigt mir die Werte der Shellys (Schaltzustand, ggf. Leistung und Temperatur), die ich mir vom ioBroker mit den entsprechenden Nodes in die Flows hole.

    Nun möchte ich die Shellys auch mittels der Switch-Node schalten können - und das Switch-Icon soll natürlich den aktuellen Schaltstatus abbilden.

    Bei den entsprechenden Video-Tutorials (leider nicht mit Shellys) klappt das einwandfrei.

    Wenn ich versuche den Datenpunkt des Shellyswitch mit der ioBroker-out-Node zu verändern, dann tut sich nix.

    Wenn ich den Datenpunkt direkt im ioBroker in den Objekten ändere (false bzw. true), dann schaltet der Shelly wie gewünscht.

    Hat das schon mal jemand gemcht/hinbekommen im NodeRed-Dashboard Shellys geschaltet und den Schaltzustand auch korrekt angezeigt bekommen, egal von wo der Shelly geschaltet wird?

    BTW: zmaier - hattes du nicht diese Dimmergeschichte, die ich in Blockly "verwurstet" hatte?

    Da hatte ich zum üben/testen einen i3 von einer SPS mit Impulsen versorgt um Short-, Long- und Overlongpush zu erzeugen. Da habe ich teilweise Impulse von 200ms an den i3 gegeben und die sind im ioBroker mit ~150ms ausgewertet worden... also vielleicht 50ms sind "auf der Strecke geblieben"....

    Bei den Standardeinstellungen in den Shellys findet man die Longpush-Duration von 800-3000ms.

    Alles darunter wird als Short-Push bewertet.

    Natürlich kann man das verändern und mir kürzeren Impulsen arbeiten... ist halt irgendwann Übung/Gewöhnung - so ähnlich wie die Doppelklick-Einstellungen bei der Computermaus...

    Hallo Axel,

    im Grunde kannst du jeden Dämmerungsschalter nehmen, der deine Betriebsspannung des Shellys an seinem Ausgang zur Verfügung stellt.

    Die Teile haben ja eine Einstellungsmöglichkeit zur Justierung der Schaltschwelle.

    Das Signal dient dann zum Schließen.

    Öffnen müsstest du dann manuell.

    Wenn du allerdings auch das Öffnen automatisieren möchtest und auch die Helligkeitswerte unterschiedlich - vielleicht sogar softwaremäßig - definieren möchtest, dann benötigst du keinen Schalter, sondern einen Helligkeitssensor.

    Und der sollte Signale zur Verführung stellen, die dein System verarbeiten kann.

    Shelly stellt zwar mit seinem Door/Windows2 einen Fenstermeldegerät mit Lichtsensor zur Verfügung... allerdings lassen sich die Helligkeitswerte (bisher) nicht direkt solo zu Steuerungsaufgaben auswerten.

    Solltest du ein System wie z.B. ioBroker laufen haben, dann könntest du die Lux-Werte vom DW2 (oder von vielen anderen Sensoren) auslesen und die gewünschten Trigger definieren.

    Hallo Marco,

    der Shelly2.5 kann nur die Spannug und Phase schalten die auch die Betriebsspannung stellt.

    D.h. wenn der Shelly mit 24VDC betrieben wird, dann kann er auch nur 24VDC schalten und wenn er 230VAC schalten soll, dann muss er auch mit dieser Phase/N mit 230VAC betieben werden.

    Wenn du eine andere Spannung schalten möchstest, als die, die den Shelly selbst betreibt, dann kannst du mit Shelly1 arbeiten oder mit Koppelrelais.

    0 und ~ -3275 hin und her.

    Das war das Erste, was mir bei dem Bild/Screenshot einfiel - hier hat einer vergessen die Vorzeichenbehafung in einem 16bit-Wort zu beachten.

    Ein 16bit-Wort ohne Vorzeichen kann Werte 0-65535 annehmen. Sobald man das Vorzeichen braucht (wenn es in den Minusbereich geht) wird Bit 16 zum Vorzeichenbit. Bleiben 15 Bit für die Werte.

    Also ein vorzeichenbehaftetes 16bit-Wort (Wort sagt eigentlich schon aus, dass es 16 Bit sind) kann Werte von -32767 bis + 32767 annehmen...

    Daher liegt es m.E. - wie ASI-Master sagte - nicht am Wert, der rein kommt (bzw. am Sensor) sondern an der Auswertprogrammierung.

    Vielleicht hat der Programmierer vergessen, den Temperaturbereich anders als den Feuchtigkeitsbereich zu programmieren - Feuchtigkeit kann dafinitiv nicht in den Minusbereich wandern...