Beiträge von eiche

Hallo Rommy , ostfriese hat dir ja schon sehr gute Tipps gegeben.

Soweit ich dich verstand, möchtest du die Messwerte flexibel nutzen können. Dazu sollten die Sensoren keine Schaltnachrichten liefern sondern Messwerte, welche du geeignet verarbeiten lassen kannst. Alternativ könnte ein intelligenter Sensor per Nachrichten einstellbar sein.

Ich nutze derzeit so etwas nicht. Auf die Schnelle fand ich folgendes, was zu deinem Vorhaben passen könnte:

https://taaralabs.eu/1-wire-tempera…y-light-sensor/

Viel Erfolg!

Hello Tom,

I think that's impossible. But why do you want to do this?

You can use a shedule job with method "Script.Eval" and the code value contains a funtion call "foo(parameter)".

So your script function "foo()" will be called at the wished time.

Also in foo() you can write into a global Variable, e.g. a Status structure. So another function or eventhandler can use this information ...

Is there any additional behavior you would like to implement?

Bei hinreichenden Elektro-Kenntnissen - nur zu!

Dann schließe ich mich zunächst thgoebel an - mir fällt dazu leider nichts mehr ein.

Trotzdem:

1. Womit versorgst du den Shelly UNI?
2. Kannst du bei Gleichspannungsversorgung mal ein Potentiometer, evtl. mit Vorwiderstand, zwischen Vcc und GND als Spannungsteiler für den ANALOG IN einsetzen und dann die Werte prüfen?

Bei Wechselspannungsversorgung wäre eine Gleichspannung von einem einstellbaren Netzteil oder Spannungsteiler wie oben am Netzteil einzusetzen.

Das sollte mit folgender Konfiguration (ungetestet) gelingen.

1. Nach Reboot Ausgang auf On.
2. Wenn Eingang "On" (o.ä.) Ausgang auf Off.
3. Timer für Ausgang Off auf die gewünschte Dauer einstellen, automatisch On.

Zu 2.

Evtl. ist eine HTTP-Nachricht passend zu senden mit der IP-Adresse 127.0.0.1 (localhost).

Für eine DAU-Anleitung müsste ich dies selbst testen ....

Viel Erfolg!

Ich täte in solchen Fällen nicht der Cloud vertrauen.

Ich habe gerade keinen UNI in Betrieb, täte folgendes versuchen.

1. Den UNI Nachrichten senden lassen, per HTTP GET oder per MQTT - ohne Cloud versteht sich.
2. Einen Empfänger die Nachricht mit Zeitstempel erfassen, am besten speichern.
   Als Empfänger ist ein MQTT-Client oder ein übergeordnetes System geeignet. Ich setzte dafür gerne Node-RED ein.
3. Gelegentlich nachsehen, welcher analoge Wert wann gespeichert wurde.

Ich bevorzuge einen Raspberry Pi mit Node-RED, InfluxDB und Grafana. Diese Werkzeuge sind sehr verlässlich und (nicht nur) für solche zielgerichteten Zwecke sehr gut geeignet.

Evtl. kann man den UNI auch periodisch nach seinem Zustand befragen ...

Eine solche Erfassung von Werten/Zuständen ist sehr preisgünstig zusammenstellbar und kann als kleines Messlabor für sehr niederfrequente Dinge dienen.

Nachteil: Es setzt einige Kenntnisse in Node-RED, evtl. MQTT und für Aufzeichnungen Datenbanken voraus.

Die Cloud ist aber nichts dagegen.

Nachtrag: Fehlersuche ist mitunter sehr zeitaufwändig.

Danke für die Info, die 2. Generation + AddOn an 230V betreffend. Mein fertig entwickeltes Vorhaben, diese Kombination für eine Heizkörperregelung mit autarken Fähigkeiten einzusetzen, wird so relativiert. Ich werde diese Kombination an 230V betreiben und die Messwerte im Minutentakt aufzeichnen. Dann werde ich vielleicht diesen Fehler sehen können.

Ich halte ja viel von der Allterco Shelly Philosophie, aber ein solches Verhalten sollte in einem Entwicklungslabor festgestellt und Gegenmaßnahmen ergriffen werden. Das schmälert meine Allterco Begeisterung.

Andererseits las ich die Empfehlung, DS18B20 und/oder DHT22 zu verwenden. Ich habe also noch Hoffnung.

Ich nutze zwei Shelly 1. Generation mit AddOn zur Heizungsregelung an 230V seit über 1 Jahr. An einem der Shellies "hängt" ein DS18B20 in Metallröhrchen am anderen ein DHT22. Bisher habe ich solche Messwertsprünge nicht festgestellt. Und ich zeichne die gemessenen Temperaturen und mehr in einer Datenbank auf. Selbstverständlich bedeutet das nichts, was solche Sprünge an anderen Stellen betrifft.

Ich täte in einem solchen Fall als Softwaregegenmaßnahme mehrere Messwerte (per Skript) sammeln und einen Mittelwert bilden. Das greift, wenn solche Sprünge nicht ständig vorkommen. Hierzu ist das Aufzeichnen der Messwerte nützlich, um solche Ereignisse analysieren zu können. Zur Mittelwertbildung gibt es unterschiedliche Varianten. Auch eine Glättung per diskretem integrieren kann nützlich sein.

Vielleicht hat hier jemand eine elektrische Lösung für das Problem. Und schließlich wären beide Maßnahmen eine gute Kombination.

Tja, ein Skript kann hier relativ effizient und insbesondere flexibel eingesetzt werden.

Ich hab auch noch einen (wegduck).

Bei mir holen sich ausschließlich Arbeitscomputer, also solche, an denen ein Mensch sitzt, ihre IP-Adresse per DHCP.

... nur mal so

Der TE schrieb auch von einem "Bindestrick". Das lässt auf bedenkliche Bedingungen schließen.

Oha, klar. Dann ist allerdings ein Gedankenstrich sehr ungewöhnlich an dieser Stelle bis hin zu fahrlässig.

Bisher dachte ich dass "Gedankenstrich" und "Bindestrich" Synonyme seien.

Was ist ein von dir gemeinter Gedankenstrich? Oder meinst du damit zusätzliche Leerzeichen?

Pantii

Wenn du JavaScript einigermaßen kannst, empfehle ich dir folgende Hardware und ein Skript.

1. Shelly Plus 1 oder Shelly 1 mit AddOn zur Messung der Pooltemperatur,
2. Shelly Plus 1 oder Shelly 1 mit Addon an der anderen Stelle (wo das evtl. wärmere Wasser verfügbar ist, Absorber)

Für einen der beiden Shellies - bei Neukauf am besten beide - einen der zweiten Generation nehmen (Shelly Plus 1) .

Lasse das mit der Cloud, wenn du eine möglichst ausfallsichere Variante suchst! Auch ein übergeordnetes System ist dann hierfür überflüssig.

Schreibe das Skript und bringe dort die von dir gewünschte Hysterese unter!

Die beiden Shellies können per HTTP GET kommunizieren. Auf demjenigen, welcher näher an der zu schaltenden Pumpe liegt, sollte der Einfachheit wegen das Skript laufen.

Auf diese Weise arbeitet die kleine Anlage total eigenständig und braucht außer WLAN nichts zusätzliches.

Nur für eine Parametrierung und Überwachung ist ein zusätzliches System nützlich.

Für die Parametrierung kann man aber auch eine kleinere HTML-Datei erstellen, die lokal nutzbar ist und über die der Anwender den Skript-Shelly parametrieren kann.

Wenn du dazu bereit bist und weitere Infos wünschst, darfst du dich gerne direkt an mich wenden (PN).

Edit:

Es sollte auch möglich sein, meine Empfehlung und die Cloud zwecks Aufzeichnungen zu kombinieren.

Einer meiner Accesspoints hat einen Bindestrich in der von mir erstellten SSID. Es gibt bei keinem meiner geschätzt 8 Shellies, die sich mit diesem AP verbinden, der ersten und der zweiten Generation keine Probleme damit, alle mit aktueller Firmware.

Nach(t)arbeit

Es gab noch eine potentielle unangenehme Unschönheit, hervorgerufen durch eine kleine Umstellung. Diese ist inzwischen beseitigt.

Außerdem habe ich meine letzte "Nebelecke" in diesem Projekt verarbeitet. Diese betraf die gelegentlich, quasi zufällig auftretende kleine Falschanzeige der Uhr von +1 Minute.

Auch wenn meine Implementation diese Falschanzeige anschließend durch warten korrigiert, wollte ich den Grund dafür kennen.

Diesen Grund beschreibe ich auf meiner Projekte-Website (Link. s.o.).

Es wird somit eine weitere Version geben, zu welcher man eine zusätzliche Wartezeit (nach Stromausfall) für die Zeitsynchronisierung konfigurieren kann, aber nicht muss.

Dies ist bereits in der HTML-Datei zur Konfiguration eingebaut.

Edit: Diese Version 2023-04-14_01 ist verfügbar und kann heruntergeladen werden.

Ich habe diese Version mit einer zusätzlichen Zeitverzögerung von 30s und einem selektiven Stromausfall (Netzteil aus) getestet. Bei keinem dieser Tests ereignete sich der temporäre Anzeigefehler von +1 Minute.

Edit:

Sorry, ich war leider etwas zu hektisch - wohl aus Euphorie über das Finden der Ursache des temporären 1 Minute Vorgehens nach einem Stromausfall.

Nach einigen Tests steht die aktuelle Version 2023-04-15_02 und ein kurzer Changelog auf meiner Projekte-Website zur Verfügung.

Die Uhr bleibt nach einem Stromausfall solange stehen, bis eine Zeitinformation eintrifft - von einem Zeitserver oder vom Anwender. Dann stellt sich die Uhr fehlerfrei - ohne die zuvor temporäre Falschanzeige von +1 Minute.

Hiermit teile ich an dieser Stelle mit, dass ich heute das Projekt "Emulation einer Hauptuhr per Shelly Plus 2" vorläufig abgeschlossen habe.

Es steht allen Interessierten zur Verfügung.

Ich habe die Installation und Konfiguration möglichst leicht gestaltet, damit auch Benutzer ohne vertiefte RPC-Kenntnisse meine Implementation nutzen können.

Hier kurz die wesentlichen Eigenschalten der "Uhr":

1. Im Synchron-Betrieb arbeitet sie vollautomatisch, ähnlich einer Funkuhr - allerdings imho verlässlicher.
2. Im Synchron-Betrieb stellt sich die Uhr nach einem Stromausfall vollautomatisch richtig.
3. Im Synchron-Betrieb stellt sie sich auch vollautomatisch beim Wechsel Normalzeit<->Sommerzeit um, ein Nebenprodukt von Punkt 2.
4. Im Asynchron-Betrieb kann sie nach einem Stromausfall leicht per Hotspot (ca. 1 Minute lang per Smartphone zur Verfügung gestellt) automatisch eingestellt werden.
5. Alternativ zu 4. kann der Shelly interne Accesspoint mit Adresse 192.168.33.1 und eine von mir erstellte Webseite (lokal) verwendet werden.

Für den Synchron-Betrieb ist ein verfügbarer Zeitserver erforderlich. Dieser steht i.d.R. mit der Einbindung des Shelly in ein WLAN zur Verfügung.

Im Asynchron-Betrieb kann sich die Uhr nach einem Stromausfall naturgegeben nicht selbst richtig stellen. Dann ist eine Anwender-Aktion erforderlich.

Interessant.

An einem TRV am Heizkörper im alten Wintergarten hatte ich das gleiche Problem. Ich vermutete, dass das Ventil durch Alterung etwas schwergängig wurde, schraubte das alte Einfachthermostat wieder an und lies das Ventil erneuern. Bisher habe ich den TRV dort nicht wieder angeschraubt. Ich lasse die Akkustände aller Akkugeräte eh bereits per Dashboard anzeigen sowie laufend in einer Datenbank speichern.

Danke für eure Aktivitäten in dieser Angelegenheit.

Ok, irgendwelche Oxidationen o.ä. hatte ich nicht bedacht. Bei solchen Prozessen ändert sich aber der Übergangswiderstand.

Überrgangswiderstände sind eher bei starken Strömen zu bedenken als bei schwachen.

Die Frage ist, ob eine solche, nichtkonfigurierbare Entprellung für eine große Auswahl an Tastern/Schaltern ausreicht. Die Entprellzeiten sollten für anwenderfreundliche, kurze Reaktionszeiten ja nicht sehr lang sein. Ob das Prellen beim TE überhaupt ein Problemchen ist, weiß ich ja nicht einmal.