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.
Ich setze i4 110V bis 240V ein, zusammen mit den 4fach Tastern. Nach Schaltplan werden die Eingänge dieses i4 mit Netzspannung geschaltet, es liegt somit 230V an - nicht potentialfrei.
Du könntest einen UNI prüfen oder einen Shelly Plus 1 mit AddOn. Mit letzterem habe ich ausschließlich Erfahrung mit Temperatur- und Luftfeuchtigkeitsmessung.
Ich will mal nachschauen, wie das AddOn für deinen Zweck nutzbar ist.
Entschuldige bitte mein leicht außenseiterisches Gebahren. 
Ich klinke mich hier noch einmal kurz ein, weil das Problem noch nicht gelöst ist.
Eine Heizungssteuerung mit selbstständig arbeitenden Geräten ohne zusätzliches System und erst recht ohne Cloud halte ich nach wie vor für erstrebenswert. Und genau das kann die von mir oben ins Spiel gebrachte Implementation. Vielleicht ist diese doch noch einen Gedanken wert. Ich arbeite für und mit einem anderen Forumsteilnehmer an einer solchen Lösung und sie funktioniert bereits grundlegend.
Gruß
Gerhard
Es wäre gut, wenn du erst einmal zeigtest, was du bisher versucht hast. Ich nutze die i4 u.a. zur Rollladensteuerung, was gut funktioniert. Aber mein Skript ist komplexer als i.a. erforderlich.
Das Prinzip
Im Skript erfasst der Eventhandler die Tastendrücke.
Du selektierst die von dir genutzten Tasten Id (0 und 1).
Du steuerst im Eventhandler die 2.5er per HTTP.
Hallo helmi55
Etwas an deiner Frage vorbei, aber durchaus nutzbar.
Ich nutze kein fertiges übergeordnetes System, kann dazu somit nichts schreiben.
Wenn dein "ESP32" ein Shelly Plus (2. Generation) ist, gelingt das, was du anstrebst, per Skript auf dem Shelly Plus. Das hat zudem den Vorteil, dass diese Implementation autark arbeiten kann.
Wenn es sich bei dem ESP32 nicht um einen Shelly handelt, welche Firmware läuft dann auf ihm?
Falls dich diese Implementation interessiert, darfst du mich gerne per PN kontaktieren.
Gruß
Gerhard
AlexAn Ok, ich ziehe mich zurück.
Deine Hinweise passen nicht zu meinen Bedenken.
Ich habe versucht, den TE darauf hinzuweisen, dass es mit diesem MQTT Id zukünftig Probleme geben kann.
Ein ankommendes Topic hat damit absolut nichts zu tun, da afaik der MQTT Id eines publishers den Anwender eines Shelly nicht interessieren kann.
Somit beende ich hier mein offenbar unerwünschtes Engagement und überlasse dir das Feld.
Ich mag mich irren. Afaik hat der Client Id nichts mit einem Topic zu tun sondern dient dem MQTT Broker zur Identifikation eines abonnierenden Client.
in #6 sehe ich in der MQTT Konfiguration unter Client ID "shellyplus1pm". Darauf bezog ich mich. Es kann schnell baugleiche Geräte geben. Wenn der TE dann denselben Client Id wählt ...
Hello Tom,
ok that's fine. I only know of KVS as global storage, afaik there is no way to share variables script independent. I think such a global sphere don't you need.
I wish you success
best regards
Gerhard
Hallo linus40 ,
ich kenne loxberry nicht und auch nicht deinen MQTT Broker (hast du nicht mitgeteilt).
Dein MQTT Client Id gefällt mir nicht, weil es nicht sehr spezifisch ist. Besser ist hier ein Id, welcher vom Shelly bereits vorgegeben ist oder einer, den du leicht von anderen solcher Shelly Geräten unterscheiden kannst.
Schedule jobs are not very popular here.
Just look at https://shelly-api-docs.shelly.cloud/gen2/Component…rvices/Schedule and https://github.com/mongoose-os-libs/cron !
You can create such two jobs , one for sunset the other for sunrise.
Each Job calls a function in your script, which set a global variable or variables to appropriate values, which other function may use.
Of course you can implement other methods, but this method works.
Btw, the called functions may immediately process the desired behavior.
Global variables are those that are declared/defined outside of any function or object in the script. This is very basic knowledge, sorry.
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:
Bei Wechselspannungsversorgung wäre eine Gleichspannung von einem einstellbaren Netzteil oder Spannungsteiler wie oben am Netzteil einzusetzen.
Das sollte mit folgender Konfiguration (ungetestet) gelingen.
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.
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
