@ilovegym
Sorry, dein Vorschlag bringt nichts. Wie du anhand des Logs und der ausführlichen Beschreibung sehen kannst, wird eine Änderung nur dann geschrieben, wenn auch ein Zustandswechsel erfolgt. Ich will ja nicht mit Click einschalten und Doppelklick ausschalten, sondern mit dem ersten Click einschalten und mit dem nächsten Click wieder ausschalten. Und da ein SingleCLick nun auf ein SingleCLick folgt, was definitiv keine Zustandsänderung auslöst ist das somit nicht umsetzbar.
Aus meiner Sicht ein verbesserungsfähiges Feature im Adapter.
Ach ja: eingebunden über Wifi Gateway

@ilovegym
Wird aber von Tuya App unterstützt und erkannt und auch so an den Adapter weitergegeben. Und der Adapter reagiert ja auch.

@ilovegym
Also es handelt sich um 3 verschiedene Buttons, bei denen allesamt der gleiche Effekt auftritt.
Zum Beispiel der hier:

Der Switch State kennt die Zustände singleClick und doubleClick.
Das Problem ist letztendlich, dass durch das Polling des Adapters es unmöglich ist, aufeinanderfolgende SingleClicks oder DoubleClicks zu erkennen. Die Folge Sigle/Double oder Double/Single funktioniert.
Hier ein Beispiel:
Zuerst das Skript:

Hier das Log vom Ablauf:
Zuerst kommt 3x hintereinander das Poll vom Adapter.
Dann ein DoubleClick, gefolgt von einem SingleClick und dann noch 2 weiter SingleClicks.

Hier lässt sich jetzt deutlich erkennen, dass ein mehrmaliges Clicken oder Doppelklicken nicht von einem Polling des Adapters unterschieden werden kann.

Die Frage ist also jetzt, ob es ohne Programmänderung am Adapter nun eine Lösung gibt oder nicht, was dann zwangsläufig als Issue eingekippt werden müsste.

Hi, ich brauche jetzt mal eure Hilfe. Im Forum hab ich leider nichts passendes gefunden, daher poste ich hier mal die Problematik. Im Einsatz sind mehrere Buttons, letztendlich hab ich mit allen das gleiche Problem.
Beispiel:

Dieser Button kennt den Zustand single_click und double_click.
Wird immer nur 1x gedrückt, ändert sich der Zustand nicht. Es bleibt immer bei single_click. Es ändert sich natürlich richtigerweise der Zeitstempel mit letzter Modifikation.
Daraufhin hab ich mein Skript darauf umgestellt, dass mit einfachem Click eine Lampe geschaltet wird. Läuft.
Dann ist mir aufgefallen, dass auch ohne mein Zutun in einem bestimmten Rhythmus die Lampe geschaltet wird.
Und zwar nach 60s. Verursacher ist der Adapter mit der Grundeinstellung 60 unter "Einstellungen zum Polling von lokal verbundenen Geräten". Den Wert auf 0 zu stellen hat nichts gebracht, scheint dann per Default auf 60 zu gehen. Jetzt habe ich mal auf 24h also 86400 umgestellt.

Ist aber ja nicht wirklich eine Lösung. Schaltet dann halt mindestens einmal am Tag, was ich ja doch eigentlich nicht haben will.
Soweit die Problembeschreibung. Vielleicht habt ihr ja da einen besseren Ansatz. Wobei ich eher dahin tendiere, dass das Problem im Adapter selbst zu lösen wäre. Danke

@hacki11
Ok. Das könnte das mit dem Slider erklären. Bliebe aber die Frage offen, warum ein Heizvorgang einfach so abgebrochen wird, ohne dass die Zieltemperatur erreicht ist. Und wie gesagt: nicht schon nach ein paar Sekunden, sondern nach Minuten, aber keine feste Zeitspane feststellbar.

Hi, ich muss jetzt doch mal in die Runde fragen. Ich hab eine Lochrasterlösung und setze einen Wemos D1 mini ein. Folgendes Pinout CIO data/td/rx 4 clk/tx 3 cs/ld 2 // DSP data/td/tx 7 clk/rx 6 cs/ld 5 audio 0. Zusätzlich an 1 noch einen DS18B20.
Pool: Lay Z Spa Bahamas Model 2021. Im Setup für CIO/DSP 6Wire 2021 (air) eingestellt. MQTT ist eingerichtet
Auf den ersten Blick sieht eigentlich alles sauber aus. Hab auch kein Flackern am Display.
Mir ist nur Folgendes aufgefallen:
Wenn über das Web-interface der Zustand der Pumpe/Whirlpool oder Heizung geschaltet wird wird der Slider zwar zunächst umgestellt, springt dann aber wieder zurück und stellt sich danach doch auf den gewünschten Zustand ein.
Gestern ist mir dann mal aufgefallen, dass wenn ich die Heizung aktiviere, Pumpe und Heizung zunächst laufen und dann nach mehreren Minuten sich wieder abschalten, obwohl die Zieltemperatur noch lange nicht erreicht ist. Die Dauer bis zum Abschalten ist auch unterschiedlich. Ich hab es dann erst mal so gelöst, dass ich das Heizen als wiederholendes Command in die Queue einsetze. Aber das wäre ja nur eine Notlösung.
Daher die Frage: Kennt jemand solche Effekte und ggf. auch die Lösung ?

@gelbwichtel
muss mich revidieren. Schlussfolgerung und Test war nicht korrekt. Hatte vor Aufruf meines Test auf minmaxheute das setup nicht durchlaufen. Werte werden gesetzt, wenn das Skript "richtig" gestartet wird. Ich muss mir mal meine cronjobs genauer ansehen.

@g-hawk Ich komme zu den gleichen Schlussfolgerungen. Die Datenpunkte sind korrekt angelegt, und in der InfluxDB können diese korrekt abgefragt werden. InfluxDB ist V2 Script das aktuellste.
Das Problem dürfte in wetterstation.sub in der Funktion minmaxheute() liegen.
Wird anstelle von FLUXSTART=$(date +%Y-%m-%d --date="-1 day")"T${ZULU}:00:00Z"
mit FLUXSTART="-1d" gearbeitet werden die Werte sauber abgestellt. Was jetzt genau an der Berechnung oder am Parameter für influx falsch ist, muss ich noch genauer untersuchen.

@paul53 Hi, ist zwar tricky, aber es funzt und dürfte dann auch später bei einem Update zu keinen Problemen führen. Danke

@apollon77: Erst mal Danke für deine tolle Arbeit. Mit dem Update hab ich bisher keine negativen Erfahrungen gemacht. Nachdem ich im Thread keine Hinweise auf "negativ", oder "kleiner" oder "minus" gefunden habe, würde ich gerne die folgende Frage stellen: Wie kann ich zum Beispiel Werte die kleiner als ein Minuswert sind nicht aufzeichnen lassen. Analog gilt dies für "größer als". Sobald man nämlich das Minuszeichen eingibt, kommt eine Fehlermeldung. Beispiel aus der Praxis: ein Dallas DS18B20 liefert immer -127, wenn die Abfrage nicht funktioniert hat. Diese Werte will ich dann nicht aufzeichnen. Vorab vielen Dank