Beiträge von eiche

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.

    Danke für die "alternativen" ;) Hinweise/Vermutungen. So ganz habe ich sie noch nicht verarbeitet.

    ich denke, das sind Buchsen mit Schraubanschluss

    Drei Leitungen hinein und Buchsen? Dann sollten es Dreifachkontaktbuchsen sein. Habe ich auch noch nie gesehen.

    sieht aus als wär es einfach bei 15cm abgeschnitten und abisoliert

    Zu einem dazu passenden Zweck fehlt mir gerade die Phantasie.

    Dann hoffe ich mal auf verlässliche Auskunft seitens des TE. :)

    e.wirries

    Thomas meint mit "möglicherweise" vermutlich, dass die Pullup Wiederstände dann nicht erforderlich sind, wenn solche im Treibermodul an den Eingängen intern vorliegen.

    Zu den zwei Shelly Plus 1:

    Es ist suboptimal, für deinen Einsatzzweck zwei Shelly Plus 1 zu verwenden.

    Grund: Diese müssen irgendwie miteinander kommunizieren, damit umgeschaltet (max. 1 Ausgang auf high) wird. Ein Shelly Plus Uni kann dies intern und braucht dazu keine solche Kommunikation.

    Eine zweckmäßigerweise, wenn auch vielleicht nicht notwendigerweise, gegenseitige Verriegelung ließe sich mit zwei Rückkopplungsleitungen Shelly Plus 1 A Ausgang zu Shelly Plus 1 B Eingang und umgekehrt realisieren. Zusätzlich wären dann noch zwei Actions, auf jedem Shelly eine, zu konfigurieren, die dafür sorgen, dass nie zwei High Pegel an die beiden Eingänge des Treiber Moduls gelangen, bzw. solche Pegel nur sehr kurzzeitig gleichzeitig anliegen. Diese Rückkopplungen funktionieren auch dann, wenn keine Kommunikation über WLAN verfügbar ist.

    Btw, ein Shelly Plus Uni verbraucht weniger Energie als zwei Shelly Plus 1. Und ersterer braucht keine Relais zu schalten, was mit zwei Shelly Plus 1 nicht vermeidbar ist, solange du diese nicht elektrisch veränderst.

    Als Konsequenz müsste das bedeuten, dass solche Abfragen, wie auch die Abfragen von <Component>.GetStatus entweder

    1. ein Limit haben, welches nicht dokumentiert ist oder
    2. die Limits von RPC und Timer veraltet sind und neu zu überarbeiten wären.

    Ich vermute 1.

    Solange die Firmware nicht fehlertransparent und -tolerant arbeitet, unterstützt sie das Shelly Skripten nur halbherzig. Das sage ich als Anhänger dieser Firmware und deren Konzept.

    pepo83 Ich wünsche dir bei deinem Vorhaben viel Erfolg.

    Mein Beitrag in #15 ist weniger an einer Anwendung orientiert. Vielmehr wollte ich damit einen Meta Beitrag leisten. Dieser sollte die (Nicht-)Möglichkeiten von absturzsicheren Shelly Skripten sowie nutzbare Codemittel aufzeigen.

    Verlasse dich möglichst nicht auf die Ausnahmebehandlung! Sie ist nicht annähernd so sicher, wie sie sein sollte. Als erstes Testmittel mag sie gerade noch taugen ...

    Nach meiner Erfahrung arbeiten richtig eingesetzte Schedule Jobs verlässlicher als Skript Timer. Und sie unterliegen per se keinem derart restriktivem Limit wie RPC und Timer - wenn man es nicht übertreibt. ;)

    Ich favorisiere für solche Zwecke mit relativ geringem Aufwand Schedule Jobs, die jeweils die RPC Methode "Script.Eval" nutzen. Auch die Timer Anwendungen unterliegen einem Limit.

    Ein anderes, rein per Skript implementiertes, Verfahren besteht in der Abspeicherung von auflaufenden Ereignissen in einer Warteschlange (Queue). Solches hat vor einiger Zeit dekatWin zusammengestellt. Ich täte vermutlich beides nutzen - sowohl die Queue als auch einen Schedule Job, der regelmäßig eine Skriptfunktion aufruft. Letztere sollte die Queue abarbeiten. Auch eine Prioritätenhierarchie kann für kritische Ereignisse nützlich sein.

    Was letztlich am zielführendsten ist, hängt vom Einsatzzweck ab.

    1. Gibt es zeitkritische Ereignisse?
    2. In welcher Zeitdichte sind zu bearbeitende Ereignisse zu erwarten?

    DIE Eier legende Wollmilchsau gibt es imho hierfür nicht. Oder: Die Kombination aus Queue, Schedule Job und Prioritäten wäre für viele Zwecke geeignet, solange die Ereignisse nicht zu dicht aufeinander folgen. Allerdings ist die Implementation einer solchen Kombination relativ aufwändig.

    In jedem Fall sind die obigen Punkte 1 und 2 zu berücksichtigen.

    Auf die Ausnahmebehandlung (try, catch) kann man sich afaik nicht verlassen. Diese täte ich somit eher weglassen.

    Schubbie

    Hast du auch mal damit experimentiert, welchen Abstand Magnetschalter und Permanentmagnet brauchen, damit die Kontakte gerade soeben geschlossen werden? Vielleicht verschwindet der unerwünschte Effekt, wenn du diesen Abstand ein wenig verringert nutzt. Der Test sollte möglichst mit einem entmagnetisierten Reed-Schalter vorgenommen werden. Vielleicht hat ein Uhrmacher eine Entmagnetisierungsdrossel und kann dir dabei helfen.

    Zum kaufen:

    bei Amazon

    bei ebay

    Zum selbst bauen:

    http://www.suessbrich.info/elek/Magnet/En…gSelbstbau.html

    Der Autor baut sich eine solche Spule mit Kern. Ich halte solches für suboptimal, weil ein ausgedehntes magnetisches Streufeld hier für eine leichte Handhabung von Vorteil sein sollte. Allerdings habe ich derzeit keine Daten für eine Windungszahl bei vorgegebener Spannung. Ich schätze mal grob, dass die Spule mindestens 50 Windungen aus Kupferlackdraht von ca. 0,2mm Durchmesser haben sollte. Diese darf und muss auch nicht im Dauerbetrieb genutzt werden, da die Entmagnetisierung zügig abläuft und die Selbstinduktion mangels Kern relativ schwach ist, wodurch ein relativ starker Wechselstrom fließen wird. Als Betriebswechselspannung halte ich grob geschätzt ca. 5V für geeignet. Alles meine Schätzungen ohne jegliche Gewähr und nur als grobe Anhaltswerte.

    Ohne Kern wird man deutlich mehr Zeit zum entmagnetisieren investieren müssen als mit Kern.

    Wer über brauchbare Wickeldaten für diesen Zweck verfügt, sollte sich hierzu mal äußern.

    Je kleiner die Spule ist, desto kleiner das Streufeld ...

    Es wäre halt interessant, ob damit das Fehlverhalten der Reed Kontakte wenigstens temporär beseitigt werden kann. Eine solche Entmagnetisierung ist jedenfalls deutlich besser als heftige Erschütterungen per Schlagen und selbstverständlich ohne Gefahr einer Zerstörung.

    horkatz in #12

    Ich kenne dergleichen ausschließlich zur Beseitigung/Verringerung von Restmagnetismus. Somit deutet imho alles darauf hin, ohne den Analysen seitens thgoebel vorgreifen zu wollen.

    Schubbie Sind irgendwelche potentiell störenden Permanentmagnete oder mit Gleichstrom versorgten Induktivitäten in der Nähe der Reedkontakte?

    Eine per Wechselstrom durchflossene Luftspule, zumindest ohne geschlossenen Kern, beginnend direkt an einem Reed Kontakt und langsamem entfernend von diesem, entmagnetisiert den Reedkontakt längs auf den Nullpunkt des B->H Koordinatensystems zulaufender magnetischer Feldstärke (Hystereseschleifen). So haben wir die frühen Farbfernseher mit großer Luftspule entmagnetisiert. Eine reine Luftspule ist dafür am besten geeignet, weil ein ferromagnetischer Kern das erzeugte magn. Wechselfeld verformt und so die Entmagnetisierung schwieriger wird.

    Die Spule einer alten Klingel ausbauen und den Kern entfernen -> an geschätzt ca. 3-5V Wechselspannung anschließen sollte geeignet sein. Dies gilt insbesondere, weil die Entmagnetisierung geschätzt nur ca. 10s in Anspruch nimmt. Wenn dies dir zu aufwändig sein sollte, was ich durchaus verstehe, dann kann solches immerhin für etwas Problemdurchblick sorgen. ;)

    Kannst Du mir so einen Kontakt zur Verfügung stellen?

    Dann möglichst zusammen mit dem Permanentmagneten!

    Die Form dieses Magneten täte mich interessieren. Ich hatte vor vielen Jahren kleine zylinderförmige Magnete genutzt. Zumindest kann die Ursache imho ausschließlich an Magnetismus liegen.

    Es gab/gibt auch Reed Kontakte, die jeweils einen Restmagnetismus für bistabile Relais aufweisen. Vielleicht liegen solche hier vor.

    Ich habe schon sehr lange keine Reed Kontakte mehr verbaut.

    Schubbie

    Als Versuch:

    Hast du es mal mit einem etwas größeren Abstand bei geschlossenem Aquariumdeckel versucht?

    Auch wenn es wenig wahrscheinlich ist, vielleicht ist der der Werkstoff der Kontaktfahnen magnetisch zu hart und behält beim öffnen zu viel Magnetismus bei.

    Ein größerer Abstand vom Permanentmagneten könnte dann den Restmagnetismus verringern.

    Alternativ könntest du etwas Pappe zwischen Magnet und Reed Röhrchen befestigen.

    Und dadurch, dass ich die ganze Elektronik per Taster mit Strom versorge, brauche ich mir auch keine Gedanken wegen dem ständigen Stromverbrauch zu machen.

    Prinzip ist klar und verständlich.

    Ist die Stromversorgung nicht daran gebunden, dass das Moped läuft? Dann dürfte bspw. ein Plus Uni erheblich weniger verbrauchen als das Rücklicht, vom Scheinwerfer ganz zu schweigen.

    Cool, ein trinärer Ausdruck. :thumbup:

    Ich kann zwecks Linearisierung nur ein Skript mit lookup table empfehlen. Aber du verfolgst ja bereits eine andere Hardware Lösung.

    Btw, wo die ggf. beabsichtigte lookup table liegt und verarbeitet wird, ist letztlich gleichgültig. ... ;)

    Oder gibts da die Möglichkeit mit den Magnetschaltern einen Befehl an den Rolltorshelly zu senden. (Drehtor offen - öffne Rolltor).

    Klar, das geht. Die Shelly können bestens miteinander kommunizieren. Das Anlegen einer Action genügt dafür.

    Mache dich gelegentlich mit den RPC vertraut!

    https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Switch

    bzw.

    https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Cover

    Ich täte dafür folgende Alternative in's Auge fassen. Sie verlangt allerdings ggf. einige Ausgaben. Sehe ich an deinem Moped bereits eine Smartphone-Halterung oder ist das ein Navi? Viel Komfort ;)

    1. Sprachassistent nutzen - ggf. ausschließlich auf dem Smartphone als App
    2. Shelly Cloud
    3. Gute Smartphone Halterung am Moped
    4. Kommunikationssystem am/im Helm

    Mit einer solchen Ausstattung lassen sich beide Shelly komfortabel und vor allem relativ sicher (Hände können am Lenker bleiben) per Sprachbefehl ansteuern. Allerdings muss dazu auch die App gestartet werden, was afaik nicht per Sprachanweisung gelingt. Und dauerhaft möchte man wohl nicht das Smartphone zuhören lassen.

    In diesem Zusammenhang wäre es interessant, eine App - hier die Sprachassistenten App - starten zu lassen, sobald das WLAN erreichbar ist. Ich kenne allerdings keine Lösung dafür.

    Edit:

    Ein Shelly Plus Uni und darauf ein Skript könnte hier automatisieren, auch ohne Cloud. Das Skript fragt bspw. alle 2s den Status ab. Sobald die WLAN Verbindung zur FRITZ!box hergestellt ist, kann automatisch ... geöffnet werden. Evtl. kann hier jemand dazu etwas über die Antennenreichweite des Uni sagen.

    Das Skript kann beim Hochfahren des Uni - Moped gestartet - diese Automatisierung erst dann aktivieren, wenn bspw. die WLAN Verbindung länger als 3 Minuten fehlt. Zusätzlich kann ein am Uni angeschlossener Taster zur manuellen Bedienung genutzt werden. Ein Schalter am zweiten Uni Eingang ließe die Möglichkeit zu, diese Automatisierung zu (de)aktivieren.

    alexjr

    Bei ADC kann man sich nie auf einen Wert "verlassen", weil es immer Fehler gibt. Aber ja, 0,2V Abweichung ist erheblich, welche vermutlich nur am Bereichsende eklatant ist.

    Für deinen Einsatzzweck ist allerdings eine 16 Bit Auflösung deutlich übertrieben.

    Ich empfehle dir, zuerst ein Konzept für dein Smart Home zu entwerfen.

    1. Welche/wieviele Projekte kommen zukünftig in Frage?
    2. Welche Firmware soll verwendet werden?
    3. Soll eine Cloud genutzt werden?
    4. Ist ein übergeordnetes System vorhanden oder beabsichtigt?
    5. Welche Kompatibilitäten sind bei unterschiedlichen IoT Geräten erwünscht?
    6. Kommen eigene Anpassungen per Programmierung in Frage?

    Ein Shelly Plus Uni hat bereits einen analogen Eingang. Dieser kann mit einem analogen Demultiplexer erweitert werden, um mehr als ein analoges Signal zu erfassen.

    Ich nutze seit Jahren deshalb die Shelly, weil mir die API und deren relativ gute Beschreibung gefällt. Wenn du bereits verschiedene Erfahrungen mit anderen Systemen gesammelt hast, wirst du selbst einschätzen können, mit welchen Firmware du gut zurechtkommst. Ich möchte hier nur drei erwähnen, die ich in der Vergangenheit ausgiebig nutzte.

    • Shelly - ausgereiftes RPC Konzept mit verschiedenen Kommunikationsschnittstellen
    • Tasmota (32) - sehr vielseitig, aber als Konzept den RPC deutlich unterlegen, Rules gewöhnungsbedürftig, gute aber wenig verbreitete Programmiersprache Berry
    • Selbst programmieren bspw. per Arduino IDE und bspw. C++

    Ansonsten wünsche ich dir viel Erfolg bei deinen Smart Home Vorhaben.