Beiträge von eich

    Derzeit verkaufe ich es nicht.

    Ich kann es bei Nachfrage zur Verfügung stellen. Da es inzwischen einen mittleren Umfang aufweist, scheue ich mich davor, es hier offenzulegen. Dazu sehe ich bisher bzgl. tasmota32 und Berry kein hinreichendes Interesse.

    Ich habe dir inzwischen per eMail geantwortet.

    Bei Fragen stehe ich zur Verfügung.


    Gruß
    Gerhard


    Nachtrag:
    Ich dachte bereits darüber nach, das Messsystem zum Verkauf anzubieten. Allerdings wäre es dazu sinnreich, Elektriker für die Montage an der Hand zu haben. Eine bisher erste Anfrage bei einem Elektriker in meiner Nähe ergab kein geeignetes Interesse. Also bleiben (vorerst) nur Nerds ... ;)

    Das dürfte bis auf eine Sache passen.

    Diese Sache betrifft die L Klemmen am Shelly. Diese beiden L Klemmen sind sicher nicht intern miteinander verbunden, sonst wären ja nach Anleitung nicht beide Klemmen an L zu legen. Dein Durchschleifen wird somit voraussichtlich nicht funktionieren. Du braucht somit eine hinreichend große Wago Klemme, damit du die beiden Shelly L und L an der Steuerung an L legen kannst.

    Viele Ls ;)

    Wenn deine Steuerungseinheit nur Taster bzw. Schalter ohne Elektrik/Elektronik ist, wird diese keinen Nullleiter benötigen und nur schlicht den Außenleiter L (Phase) schalten.

    Andernfalls sollte diese auch den Nullleiter brauchen.

    Ich kann in deiner Abbildung nicht erkennen, was das untere Teil ist, vermutlich deine Steuereinheit. Dann sind doch dort bereits Nullleiter hingeführt.

    Da ich deren Ausgangsspannung nicht kenne, kann ich nicht beurteilen, ob diese für die Schalteingänge SW des Shelly geeignet sind - vermutlich aber ja.

    Am sichersten ist es, wenn du die Unterlagen zu deiner Steuerungseinheit findest/verwendest, um mehr Infos zu erhalten.

    Nach Anleitung https://shelly.cloud/documents…lly_25_multi_language.pdf sind beide L-Klemmen zu beschalten und nicht nur eine, wie deine Abbildung zeigt. Nimm für den Außenleiter also eine 5polige Klemme! Oder, falls der Shelly in einer entfernten Dose sitzt, wirst du dort die Verteilung des Außenleiters vornehmen müssen.

    Da hast du ja das am besten passende Forum gefunden. Vermutlich ist die Folie elektronisch. :P

    Im Ernst, du solltest einen Dachdecker oder notfalls einen Innenausbauer fragen.

    Vermutlich dient sie dem Schutz vor trotz Dachpfannen eindringendem Niederschlagswasser. Innen gelegen wäre es eine Dampfsperre. Letztere sind aber afaik nicht schwarz.

    Aber wie finde ich nun raus, von welchem Wechselschalter der Lampendraht losgeht und welches der tausend Kabel in der Dose welches ist?

    Nach deiner Formulierung solltest du dort nichts selbst unternehmen und eine Fachkraft in Anspruch nehmen, die dir wenigstens verlässlich mitteilt, welche Leitung was führt. Dann magst du zusammen mit der Fachkraft deine Ziele besprechen und die Installation planen.

    Zusätzlich noch ein paar Hinweise:

    1. Was die Verkabelung betrifft, kann ich nur empfehlen, von nichts auszugehen. Annahmen kannst du zwar treffen, aber sicher ist erst dann etwas, wenn die Verkabelung per Messungen professionell geprüft wurde.
    2. Einen Shelly 1 kann man wie einen Eltako verwenden. Wechselschaltungen sind dann tatsächlich uninteressant, obwohl sie weiterhin nutzbar sind.
    3. Wenn in jeder beteiligten Schalterdose einer Wechselschaltung ein permanenter, also nicht geschalteter, Außenleiter (Phase) - sollte braune Leitung sein - vorliegt, kann man die vorliegende Wechselschaltung durch einfache Ausschaltungen ersetzen. Für die einfache Handhabung empfehle ich statt Schalter Taster einzusetzen. Die Schalter sind aber auch weiterhin verwendbar, weil in der Shelly Firmware der Schalter-/Tastertyp einstellbar ist.
    4. Ein Shelly 2 statt zweier Shelly 1 kann evtl. etwas platzsparender sein, ist aber für Lampenschaltungen nicht zu empfehlen. Shelly 1 können potentialfrei schalten, was Shelly 2 nicht können.
    5. Bei einer Lampenschaltungen ist der Shelly tatsächlich am besten in der zugeordneten Abzweigdose unterzubringen. Falls dies aus Volumengründen besser in einer Schalterdose gelingt, ist dies dort zwar auch technisch möglich, die Verkabelung aber schlecht/unprofessionell strukturiert. Eine spätere Erweiterung durch einen zusätzlichen Schalter/Taster würde eine "Bastelverkabelung" erfordern. Da du von Neubau schreibst, täte ich dort im Bedarfsfalle größere/tiefere Abzweigdose(n) einsetzen (lassen). Alternativ wäre der Einbau weiterer Abzweigdosen zu erwägen.

    Zu Punkt 2:

    Der kleinste schaltungstechnische Änderungsaufwand ist mit jeweils einem Shelly 1 in der Abzweigdose einer Lampenschaltung möglich. Dazu ist neben der Versorgung des Shelly nur der geschaltete Außenleiter (Phase) mit dem Schalteingang des Shelly zu verbinden. Der Rest kann der Shelly Doku und/oder eines der CREATION{X}-Videos auf youtube entnommen werden.


    Nachtrag:

    Da ich bisher keinen Shelly 2 verbaut habe, könnte meine Aussage unter Punkt 4 einen Fehler enthalten - bin zu faul, das jetzt zu recherchieren. ;)

    Zwei Node-RED Flows oder zwei Shellscripts, die ein solches proprietäres Protokoll serverseitig implementieren. Das ist eine sehr interessante, ergänzende Idee.


    Meine Rules sind zwar stark belegt, auch mit enable/disable, aber in Verbindung mit einer Berry Kommandofunktion könnte das gelingen.

    Der Timer könnte ständig laufen, die Berry Funktion kann per Boolwert oder Moduswert etwas tun oder auch nichts tun, abhängig von einer erhaltenen Quittierung.

    Auch das Umstellen auf eine andere Kommandofunktion, ähnlich einer Fallunterscheidung, nur halt ereignisgesteuert, ist eine implementierbare Option.

    Elegant und leicht anpassbar sollte dies mit Funktionszeigern gelingen. Das erinnert bereits an Schrittkettensteuerung.


    Das werde ich bei Muße mal genauer betrachten und prüfen.

    Danke für deine Anregungen, das wird mich vermutlich dem Ziel näherbringen.

    Vielen Dank HoerMirAuf .


    Ich las mit Freude deine Reaktion, da ich mit keiner Reaktion rechnen musste.

    Deine Idee eines auf MQTT aufgesetzten eigenen Protokolls hat bei mir eine weitere Idee gebären lassen, die aber leider gegen mein Konzept (s.u. 2.) verstößt.


    Zu deiner Anregung:

    1. Es sind nicht Messdaten, die ich vermisse. Wenn da mal ein Datensatz nicht gespeichert wird - btw inzwischen in einer InfluxDB Datenbank, dann stört mich das nicht.
      Es ist eine Hysterese bedingt einmalig gesendete Steuerungsnachricht, die nicht verloren gehen soll.
      Konkret: Wenn ein Benutzer definiertes Minimum des Wasserstandes unterschritten wird, wird eine Nachricht zum öffnen des Wasserzulaufs gesendet. Diese Nachricht ist tatsächlich Benutzer definiert. Trägt der Anwender dafür nichts ein, wird auch nichts gesendet. Das Öffnen des Wasserzulaufs ist ein beispielhafter Parameterwert in der von mir implementierten Konfiguration. Bei Überschreitung des Benutzer definierten Maximums wird auf entsprechende Weise eine andere Benutzer definierte Nachricht gesendet. Da diese Ereignisse, Unterschreitung Minimum und Überschreitung Maximum, eine relativ hohe Bedeutung haben, sollten sie, anders als Messwerte, nicht verloren gehen können. Der Vergleich mit der Temperaturüberwachung in einem Motor mag dies verdeutlichen.
      (Nebenbei angemerkt nutze ich TelePeriod in meinem Messsystem nicht.)
    2. Mein Messsystem Konzept beinhaltet eine hohe Flexibilität in der Anwendung und demzufolge in der Konfiguration. Bezüglich o.a. Benutzer definierter Nachrichten bedeutet dies, dass im System keine Kenntnis über die Wirkung der Nachrichten vorliegen kann. Ich mag solche hohen Flexibilitäten, das ist evtl. mein Manko. ;)

    Vielleicht sollte ich bei Unterschreitung des Minimums die Einmaligkeit des Nachrichtsendens verlassen. Dann bliebe aber das Problem immer noch bei der Überschreitung des Maximums. Also komme ich womöglich nicht an einem Protokoll vorbei, das ähnlich dem von dir aufgezeigtem sein könnte.

    Nachdenken erforderlich ... brainstorming ... mal sehen.


    Wie dem auch sei, nochmals vielen Dank für deine Reaktion.


    Nachtrag:

    Ich setze einen Raspberry Pi 4 mit 8 GB RAM und dem Raspberry OS lite ein. Auf diesem werkeln der MQTT Broker, Node-RED, InfluxDB und Grafana. Das System läuft seit dem 2021-08-29 stabil. Mein Messsytem besteht aus einem ESP32 Board mit Tasmota32 und in Berry geschriebener Anwendungsschicht incl. nativer Rules. Auch das Messsystem arbeitet zuverlässig - bis auf die vermisste QoS 2.

    Ich arbeite nach wie vor an meinem Zisternen-Messsystem. Es arbeitet bestens und zuverlässig. Inzwischen fiel mir aber etwas auf.

    Hin und wieder wird mal eine MQTT Nachricht nicht gesendet oder vom MQTT Broker nicht verarbeitet. Solange das die zu sendenden Messwerte betrifft, ist das kein Problem. Dann wird halt mal ein Messwert-Datensatz nicht gespeichert. Es gibt trotzdem genügend Datensätze, die alle 2 Minuten erfasst und gespeichert werden.

    Die Ursache liegt offensichtlich in der von Tasmota verwendeten MQTT Bibliothek "pubsub client". Darin ist die Quality of Service (QoS) nicht implementiert. Somit steht ausschließlich QoS 0 = fire and forget zur Verfügung. Eine diesbezüglich "bessere" Bibliothek könnte zukünftig zumindest in Tasmota32 verwendet/vorgesehen werden, da der ESP32 über relativ viel Speicher verfügt.


    Ich suche nun aber nach einem Workaround zu einer Art Nachbildung der QoS 2, die eine sichere und einmalige Übertragung einer Nachricht gewährleisten soll. Dazu erscheint mir meine Rahmenbedingung durchaus geeignet:

    Mein Messsystem erfasst die Unterschreitung eines benutzerdefiniertem Mindest-Wasservorrats. Daraufhin sendet es eine benutzerdefinierte MQTT Nachricht, die einen Wasserzulauf starten soll. Der Wasserzulauf wird von einem Shelly 1 mit Tasmota per Rules gesteuert. Das hier vermutlich nützliche und imho entscheidende Prinzip liegt darin, dass es genau einen zuständigen Empfänger, hier der Shelly 1, gibt. Entsprechendes ist zur Überschreitung eines Maximums implementiert.


    Meine Idee zur Nachbildung einer QoS 2:

    Der Sender, hier mein Messsystem, sendet eine retained Steuerungsnachricht. Der Empfänger, hier der Shelly 1, empfängt irgendwann diese Nachricht, wobei es sich bei irgendwann typischerweise um maximal wenige Sekunden später handelt. Da letztlich die Übertragung der Nachricht vom einzigen Adressaten empfangen wird, solange er funktioniert, kann dieser diesen Empfang durch eine Nachricht quittieren, dir zur Löschung der empfangenen Nachricht sorgt. Zu kompliziert? Ok, etwas einfacher:


    Sender sendet Steuerungsnachricht retained -> MQTT Broker -> einziger Abonnent empfängt Nachricht -> Abonnent sendet Nachricht zum löschen der retained Nachricht


    Nachdenk ... wie kann der Empfänger das Löschen der retained Nachricht erzwingen? Hm, per retained? Das habe ich noch nie nicht getestet.


    Frage:

    Hat jemand hier einschlägige Erfahrung mit einem solchen oder ähnlich gelagerten Workaround für QoS 2?


    Anmerkung:

    Für Steuerungen, die je Nachricht einmalig erfolgen sollen, sind retained Nachrichten zu unterlassen, da sich ansonsten ungewollte Phantom-Schaltvorgänge ereignen können.

    Gegen dieses Prinzip verstößt meine obige Workround-Idee. Ich vermute aber, dass sie trotzdem wie gewünscht funktionieren kann, da die retained Nachricht nach deren Empfang gelöscht werden soll.


    Irgendwie bleibt in mir der Verdacht haften, dass dieses Problem eine höhere Relevanz verdient. ;)

    Entschuldige bitte meine erste Antwort:

    Ich würde in die Birne beißen und den Saft auffangen. :D


    Und nun ernsthaft ohne Kenntnis deiner Lampe:

    Geräte wie Lampen dürften sich nur "over the air" (OTA) flashen lassen. Wenn die vorhandene Firmware ein OTA flashen bietet, sollte dies möglich sein, ansonsten dürfte es unmöglich sein.

    Dabei ist noch zu beachten, ob die Lampe beim OTA flashen die gesamte Firmware überschreibt oder nur ein Teilupdate/-upgrade durchführt.


    Ich interpretiere "Lampe" bzw. "Birne" als etwas, das in eine Fassung geschraubt oder gesteckt wird.

    Bei offener Elektronik geht sicher auch ein verdrahtetes flashen.

    Wenn die Betätigung des Button als Switch ein "Toggle" liefert, sollte zumindest testweise in der Rule auch "toggle" oder 2 eingesetzt werden:

    Code von HoerMirAuf adaptiert:

    Code
    rule1 on switch1#state=2 do backlog power1 on; ruletimer1 300 endon on rules#timer=1 do power1 off endon

    Ich denke nicht, dass der folgende Code von HoerMirAuf die Retriggerung verhindert, bin aber nicht ganz sicher.

    rule1 on switch1#state=1 do power1 on endon on power1#state=1 do ruletimer1 300 endon on rules#timer=1 do power1 off endon

    Grund: Die Anweisungen hinter on ding#state werden immer dann abgearbeitet, wenn in den "ding"-Zustand "geschrieben" wird. Und dies ist nach meiner Erfahrung mit Variablen vermutlich bei jedem Schalten der Fall.

    Zumindest sollten nun genügend Infos und Optionen vorliegen, um dein Vorhaben zum Erfolg führen zu können.

    Autsch, ja - backlog selbstverständlich. Ist korrigiert.

    Der Button kann nicht auf Grund dieser Rules ausschalten.

    Zu Beginn müssen selbstverständlich beide Rulesets eingeschaltet sein.

    Gibt es evtl. eine konfigurierte Verbindung vom Button zu Power/Relais?

    Ja, der Timer wird mit jedem Drücken des Buttons neu getriggert, was Retriggerung genannt wird.

    Hat die obige Rule von mir im Original wie gewünscht funktioniert?

    Wenn ja, geht es auch ohne Retriggerung, wie ich beschrieb.

    Code
    rule1 on button1#state=2 do backlog power1 on; ruletimer1 300; rule1 0 endon
    rule2 on rules#timer=1 do backlog power1 off; rule1 1 endon

    Rule1 sorgt für die Triggerung des Timers und sperrt sich anschließend selbst.

    Rule2 sorgt für die Freigabe/Aktivierung von Rule1, sobald der Timer abgelaufen ist.

    Vielleicht kann man Ruletimern auch per Konfiguration die Retriggerbarkeit nehmen. Dazu bin ich derzeit überfragt. Retriggerung ist oftmals erwünscht.

    Bin gespannt. ;)

    Ich setze inzwischen das Kommando "savedata 0" ein, damit nicht ständig in den nichtflüchtigen Speicher geschrieben wird, der weniger Schreibzugriffe verträgt.

    nur wenn der Timer abläuft und der Butten nochmal betätigt wird schaltet das Relais ab

    Du meinst vermutlich "wenn der Timer läuft ...". Ohne nach Details in der Konfiguration des Buttons zu suchen, hier könnte das Problem liegen. Wenn der Button bspw. toggelt, sollte er umschalten. Das tut er ja offenbar.

    Der Button sollte nach deinem Wunsch nur einschalten. Wie die Konfiguration dazu aussieht, weiß ich derzeit nicht, kann aber sicher gefunden werden.

    Stattdessen oder in Kombination mit obigem könnte auch folgendes gehen: ...#state=2 müsstest du prüfen. Afaik wird mit dem Drücken die 2 geliefert. Andernfalls bitte anpassen!

    Code
    rule1 on button1#state=2 do backlog power1 on; ruletimer1 300 endon on rules#timer=1 do power1 off endon

    So dürfte der Button nur einschalten und den Timer starten, aber nie ausschalten.

    Mit dieser Rule ist allerdings ein Retriggern des Timers verbunden. Wenn das nicht gewünscht ist, kann man zwei Rulesets verwenden. In der zweiten wäre das Ende des Timer (on rules#timer=1 ...) unterzubringen. Die erste sperrt sich selbst per Button1. Die zweite Rule aktiviert die erste Rule nach Ablauf des Timers.

    Der Programmierer der App MQTT Dash schreibt, dass diese nur etwas für Nerds sei. Ich halte das für übertrieben.

    Aber man muss schon ein wenig von MQTT verstehen, um darin die gewünschten "Kacheln" anlegen zu können.

    Dazu gehören Dinge wie Topic (Thema) und Payload (Nutzdaten). "Retain" und "QOS" muss man dazu nicht kennen und die Voreinstellung belassen.

    Der Rest ist schlicht etwas durchärgern und experimentieren. Die Funktionen der bedienbaren Kacheln ist sehr weitgehend für eigene Zwecke anpassbar.

    Es stehen folgende Kacheltypen zur Verfügung.

    • text - Wie der Text verarbeitet wird, hängt vom Empfänger der Nachricht ab.
    • switch/button - Damit kann man etwas schalten lassen.
    • range/progress - eine relative Anzeige in runder Balkenform mit Zahl in der Mitte
    • multi choice - Eine Art Auswahlmenü.
    • Image
    • Color

    Ich nutze die ersten 4 Typen ausgiebig. Zu den letzten beiden kann ich derzeit nichts aussagen.

    Einen Kalendertyp gibt es nicht. Per MQTT (Text-)Nachricht ist aber letztlich alles möglich, wenn die vom Empfänger/Abonnenten verarbeitete Nachrichtenstruktur bekannt ist.

    Die Tasmota Dokumentation ist hier sehr auskunftsfreudig. Man muss dazu halt Arbeit und Zeit investieren.

    Wenn man JavaScript kann, kann man die in der App eintreffende Nachricht vor deren Anzeige noch verarbeiten lassen.

    Die Angabe eines sog. JSON path ist ebenfalls möglich, wozu man nicht programmieren können muss.

    Die Oberfläche ist eher etwas schlicht, sie kann aber recht umfangreich werden.

    Wenn man auf einem Smartphone die App eingerichtet hat, lässt sich diese recht einfach auf ein anderes Smartphone (per MQTT) übertragen.

    Ich lasse meine fertigen Oberflächen sogar in meinem Netzwerk speichern.


    HoerMirAuf hat dir die Alternativen ja schon bestens aufgezeigt.

    Viel Erfolg!

    Du suchst eine Weboberfläche, also eine Webseite, die so aussieht, wie du das wünschst?

    Ich habe keine Vorstellung davon, wie so etwas gehen sollte, weil die von dir gewünschten Teile extra zusammengestellt werden müssten.

    Ich verwende für so etwas u.a. MQTT und Node-RED. Damit kann man nach eigenem Belieben das gewünschte zusammenstellen.

    Eigene Arbeit ist in jedem Fall damit verbunden.

    Für ein Android Smartphone kann ich MQTT und die App MQTT Dash empfehlen.

    Sorry, wenn ich hier nicht passend posten sollte. Ich fand kein Thema "InfluxDB".


    Im folgenden sind die IP-Adressen und die Namen beispielhaft. Ich weiß selbstverständlich mit diesen Namen und den IP-Adressen sowie Subnetzen umzugehen.


    Zur Sache:

    Ich kämpfe mit InfluxDB. Inzwischen kriege ich auf einem raspberry pi 3 vieles hin und möchte damit auf einen raspberry pi 4 umziehen. Zusätzlich ist mir das Thema Datenbanksicherung wichtig. Ich las die Dokumentation dazu von InfluxData viele male. Und ich habe etliche Versuche durchgeführt. Offenbar bin ich nicht in der Lage, das von InfluxData Geschriebene zu verstehen. Die lokale Sicherung gelingt. Jedenfalls wird das Zielverzeichnis angelegt und darin abgespeichert. Auch gibt es keine Fehlermeldungen.
    Dass mir das gelungen ist, habe ich nicht o.a. Doku zu verdanken. Diese lässt mich nach wie vor im Unklaren.

    Was ist hier der remote node? Meinem Eindruck nach ist der remote node auf dem remote node der, auf dem ich mich herumtreibe. :P

    Was tat ich bisher (vermutlich) wesentliches?

    Ich passte auf dem host mit der vorliegenden Datenbank in /etc/influxdb/influxdb.conf in der Hauptabteilung (oben, root level) die bind-address an und aktivierte diesen Eintrag (Unkommentierung).

    Für die lokale Sicherung ist localhost:8088 bzw. 127.0.0.1:8088 geeignet. Danach gelang die lokale Sicherung.

    Dann änderte ich diese bind-address auf die des Zielhosts, bspw. 172.16.9.12:8088. Versuch eines remote Backups:

    Code
    influxd backup -database myDatabase -host 172.16.9.12:8088 /tmp/sicherung

    Die Verbindung gelang nicht, rpc konnte nicht ausgeführt werden. Fehlermeldung: "... failed dial tcp 172.16.9.12: connect: connection refused. ..."

    Dann versuchte ich es auf der Zielseite, also dem Host, auf welchem die Datenbanksicherung landen soll. Ich passte dort in der Konfiguration die bind-address auf die des Hosts mit der vorhandenen Datenbank an, bspw. 172.16.9.5:8088

    Nun versuchte ich die Sicherung vom Zielhost aus. Es gab die gleiche Fehlermeldung wie oben. Ich änderte die bind-address auf alle mögliche Kombinationen 127.0.0.1, 172.16.9.5, 172.16.9.12 und versuchte auf beiden beteiligten Hosts das backup Kommando. Es gelang mir nicht, einen Erfolg zu erzielen.

    Ich kann offenbar die Doku hierzu von InfluxData erst dann verstehen, wenn ich es kann. Dann brauche ich diese Doku allerdings nicht mehr zum verstehen.


    Hat jemand einen Tipp für mich?


    Nachgereicht.: InfluxDB v1.8.9-1