Ich muss den Beitrag demnächst eh mal Updaten.
Inzwischen hängt an meiner C02 Ampel auch noch ein 1602 I2C Display das den genauen Wert anzeigt.
Kann ich nur empfehlen!
Ich muss den Beitrag demnächst eh mal Updaten.
Inzwischen hängt an meiner C02 Ampel auch noch ein 1602 I2C Display das den genauen Wert anzeigt.
Kann ich nur empfehlen!
Hi.
Das lässt sich schon machen. die Messung wird ja mit dem virtuellen Relais Power1 aktiviert und deaktiviert.
Ich würde dann den GPIO an dem der BWM hängt auf Switch1 konfigurieren, damit er das virtuelle Relais1 bedient.
Dazu aber auch den Switchmode1 auf 1 oder2 stellen, je nachdem ob Schließer oder Öffner
switchmode1 1
Dann die Rule1 anpassen:
Hi.
Gezipt oder das blanke bin?
Spiele mal für gezipte Datei auf
Hi
Ja hab ich auch. Aber mir wäre lieber gewesen keinen weiteren Server dazwischen zu haben ...
Aber Hauptsache es geht
Hi.
Jepp, backlog und Semikolon muss dazu:
Oder wennv die Relais toggeln sollen:
Hi.
Eigentlich gibt's da nur den WEBSEND. Allerdings sieht man keinen respond.
Einzige Möglichkeit wäre einen eigenen http Server (Raspi) über die externe IP mit einem Websend anzusprechen und im Serverlog die Zugriffe auszuwerten.
Alternative:
Du verbietest auch den externen NTP Zugriff und schaust ob es noch synchronisiert.
Ich würde eh den Zeitsync auf die FB umstellen. also ntpserver1 192.168.178.1
Hi DejaWuest
RGBW = PWM1/PWM2/PWM3/PWM4 ist richtig,
mit SetOption37 128 werden RGB und W getrennt mit dann 2 extra button im GUI (+ slider).
Ahhh ... danke für die Info und die Screenshots
Ich hab das mit Setoption37 128 gesehen weil man dann ja mit den Dimmer<x> Befehl arbeiten kann.
Aber hab's selbst noch nie umgesetzt.
Mit den 3 Buttons werden bei Deiner Variant dann RGB-W-Relais1 geschaltet?
PS: in deiner rule müsste switch1#mode... auf switch1#state.. geändert werden
Korrekt, Schreibfehler. Ist korrigiert.
und wenn ichs richtig sehe gibt es noch keine option für einen "Master Control" Schalter, der den BWM unwirksam macht, während W manuell an
Ne, das ist in meiner Variante nicht enthalten. Da kommt's darauf an nach was man priorisiert. Nach dem BWM oder eben der manuellen Steuerung.
Ich bin mal vom BWM ausgegangen. Man könnte es ja auch noch mit Sonnenaufgangs und Untergang Szenarien auf die Spitze treiben
Das ist richtig krass wie viele Möglichkeiten/Optionen gerade mit der Stripes PWM Steuerung machbar ist inzwischen und was es da für eine Menge an Syntax gibt.
Meine Rules sind zwar stark belegt, auch mit enable/disable, aber in Verbindung mit einer Berry Kommandofunktion könnte das gelingen.
Ich hab keinerlei Ahnung von Berry. Aber eventuell würd es dir viel nutzen mit den Conditional Rules zu arbeiten:
https://tasmota.github.io/docs/Rules/#conditional-rules
Mit if then else solltest du da eigentlich recht weit kommen.
Moin.
ich hab das mal jetzt auf nem ESP12 mal durchkonfiguriert.
Das Problem ist das Tasmota davon ausgeht das die PWM Kanäle nicht getrennt geschaltet werden.
Ich weiß nicht wie das bei dir Konfiguriert ist aber der Erklärung halber sagen wir einfach RGBW = PWM1/PWM2/PWM3/PWM4
Tasmota erzeugt für alle 4PWM einen gemeinsamen Button und Slider für Farbe Helligkeit uns Sättigung.
Entweder koppelst du den "W" Kanal aus indem du ihn als Relais konfigurierst, bekommst dafür einen eigenen Button, kannst aber dafür nicht mehr Dimmen und der W-Kanal geht für den Rest verloren. Nicht elegant.
Besser wäre mit dem Bewegungsmelder und einer Rule den W Kanal mit Farbvorgabe anzusteuern.
- Die Switch/Button lösen: Setoption114 1
- Den Bewegungsmelder Eingang GPIO als Switch1 konfigurieren
- Switchmode1 auf 1 oder 2 je nachdem ob Öffner Schließer Switchmode1 1
- Die Dimmer Einstellungen von den PWM Kanäle lösen, damit wir Farbe Helligkeit einstellen können ohne das der Stripe angeht: setoption20 1
Und jetzt musst du damit spielen weil ich keine RGBW Stripes habe um es zu testen. Entweder die Farbe für alle Kanäle per Rule geben aber eben RGB mit 0 Wert color <RRGGBBWW>, also color #000000FF oder mit white 100. White 100 Sollte eigentlich nur den weißen Kanal schalten mit 100%.
Da gibts inzwischen so viele Varianten.... muss man testen. Wie gesagt ich hab kein RGBW um das selbst auszuprobieren.
Mit der Rule schaltet der Bewegungsmelder den W Kanal ein, wenn die Bewegung nicht mehr anliegt beginnt eine Nachlaufzeit via einem Ruletimer (300 =5Min) der nach Ablauf die RGB wieder ausschaltet.
Rule:
rule1 on switch1#state=1 do backlog white 100; power1 1 endon on switch1#state=0 do ruletimer1 300 endon on rules#timer=1 do power1 0 endon
(Kann sein das mit white 100 gar kein backlog und power1 benötigt wird.... verwendet man aber color RRGGBBWW und Setoption20 schon)
Hi eich
Also wenn es sich nur um EIN spezielles Signal handelt würde ich das mir Rules lösen.
Rule1 wertet den Sensor aus. Wird ein Grenzwert unterschritten wird Rule2 aktiv, wird der Grenzwert überschritten wird die Rule2 deaktiviert.
Rule2 sendet in einer Schleife (Ruletimer der sich selbst neu setzte) eine MQTT Nachricht und/oder machst sonst noch was sie soll.
Das ist zwar kein QoS 2 aber immerhin eine Redundanz des MQTT Signals.
Ich würde die MQTT Nachricht die in Rule2 gesendet wird am Server auswerten und bei Empfang eine MQTT Nachricht zurückschicken die Rule2 deaktiviert. z.B. wenn der Grenzwert wieder überschritten ist, anstatt das von Rule1 machen zu lassen. Oder eben vor dem in der Rule1 festgelegtem Grenzwert.
Dann wäre die Sicherheit falls die Nachricht vom Server zum Gerät verloren geht sich die Rule2 vom Gerät bei einem Maximum auf jeden Fall deaktiviert wird.
Damit wäre die Hysterese vorhanden und auch eine Art QoS
Hi.
da hab ich keine Idee wie man QoS 2 nachbilden könnte.
Das einzige was mir einfällt wäre, serverseitig für mehr Sicherheit zu sorgen.
Sollte es ein Linux Server sein (RaspBerry) auf dem die Sensordaten in ein File geschrieben werden, würden ja ohne Sensoränderungen spätestens die Teleperiod Sensordaten übertragen. Erstellt man ein Bash-Skript das besagte Datendatei auf die letzte Schreibzugriffzeit (geht mit while do und find) überprüft und dieser letzte Schreibzugriff länger her ist als die Teleperioddauer (MQTT Übertragung verloren), dann könnte man das senden der Teleperiod mit den aktuellen Sensorwerten erneut per MQTT antriggern (mosquitto_pub -t cmnd/<topic>/teleperiod -n)
Das muss natürlich nicht zwangsweiße Teleperiod sein obwohl man da auch mit der Häufigkeit spielen kann. Zumindest wird so sichergestellt das man innerhalb einer gewissen Zeit Daten erhält und könnte sogar nach X Fehlversuchen oder Schreibzugriffüberschreitung + X einen Alarm absetzen (Telegramm Mesenger o.ä.)
Nachdem ich gerade ein wenig mit dem MIT APP Inventor herumspiele (extrem nettes Tool übrigens!)
Wenn's z.B. nur fürs Handy sein soll hier ne kleine APP mit der immer wieder auf die Timer Webseite zurück umgeleitet wird
Für den Timer wäre dann die URL:
<IP>/tm? Das "?" MUSS mit hin! Wichtig!
Um das zu lösen müsste man den BWM mit Switch3 und einem virt. Relay 3 anlegen,
Oder man löst mit setoption114 1 die Relais vom Switch/Button und wertet mit den Rules die Switch#states direkt aus und "verknüpft" sie mit Rules mit dem gewünschten Objekt. Hat den Vorteil das ich keine GPIO'S als "virtuelle Relais" verliere.
die sollten nach wie vor mit ESP8266 sein,
sind sehr robust aufgebaut und mit pinholes einfach zu flashen, Gehäuse aber etwas klobiger,
preislich ab ca 10€ https://www.aliexpress.com/item/4000062654657.html
Danke für den Tipp! klobig ist nicht so wild aber der ist echt interessant als Ersatz für den MagicHome
Kann man auch noch schon an RX oder TX den IR Empfänger mit anschließen, nach dem flashen.
Moin
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
Retriggert das Drücken des Tasters den Ruletimer mit diesem Ruleset tatsächlich nicht?
Das verhindert definitv das Retriggern.
- Den Switch zu verwenden hat den Vorteil, das ich da eine Auswertung mit dem Switch#state zwischen1 und 0 oder 2 habe.
Was ich davon nehme kommt drauf an ob ich beim drücken oder loslassen triggern möchte. Beim toggle "2" wird jetzt der switch#state einfach doppelt getriggert. Einmal beim drücken und wieder beim loslassen des Tasters. Deshalb hatte ich den auf "1" gesetzt. Man könnte schon auch den Button1#state verwenden. Aber switch#state ist eben die besser definierte Lösung, finde ich.
- setoption114 löst den Switch/Button vom Relais. Dadurch wird nicht mehr direkt mit dem Switch auf das Relais zugegriffen und ich kann mit den Rules über den switch#state festlegen WANN getriggert wird. Bei 1/0 oder beidem.
- der Ruletimer wird nicht mehr vom switch getriggert sondern vom power#state. Wird also Power eingeschaltet ändert sich der power#state auf 1und startet den Timer. Egal wie oft ich mit dem switch nochmals geschaltet wird, der Power ist ja bereits an, also keine Statusänderung also kein nachtriggern des Timers.
EDIT:
das Relais schaltet jetzt gar nicht
Das lag am SwitchMode. Mein Fehler! Den hätte man noch auf 1 oder 2 setzen müssen.
Also SwitchMode 1 oder SwitchMode 2
Hab ich Sicherheitshalber ergänzt!
Hi.
ich gehe davon aus das die die Original FW nutzt?
Dann sollte das helfen:
Das finde ich auch interessant wenn man kein "W" braucht sondernnur RGB:
Moin.
so wie ich das verstehe soll der Button nur einschalten und ausschließlich nach Ablaufzeit ausgeschaltet werden?
Zuerst mal den Button als Switch1 konfigurieren.
Dann den SwitchMode in der Konsole auf 1 oder 2 setzen und vom Relais lösen indem man folgendes eingibt:
SwitchMode 1
setoption114 1
Dann die Rule mit Switch#State:
rule1 on switch1#state=1 do backlog power1 on; ruletimer1 300 endon on rules#timer=1 do power1 off endon
Allerdings wird hier der Timer bei jeder Switch-Betätigung nachgetriggert und erst dann abgeschaltet wenn nach der letzten Betätigung die Zeit abgelaufen ist.
Ist kein nachtiggern erwünscht:
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
EDIT:
oder anstatt mir ruletimer auch mit pulsetime1 300 lösbar.
Moin.
Gibt sogar ein RGB PWM KIT (leider ohne W) mit nem ESP12 und allen Bauteilen inl. FET und StepDown in der Bucht für kleines Geld in der Bucht.
Gut, löten muss man noch.
Zu schade das die die MagicHome umgestellt haben. Was die Vielseitigkeit betrifft, hatte ich bei den MagicHome auch nie zu meckern. Waren zwar nicht so viele GPIO herausgeführt wie beim WEMOS aber RX/TX/14 waren immer dabei.
Für den D1 Mini gab es sehr preiswert in der Bucht eine RGBW Shield Platine mit fertigem PWM Spannungswandler.
Hast du da mal nen Link damit ich mir das Teil mal ansehen kann?
Also um MQTT Dashboard zu nutzen ist auch MQTT Server nötig. Hat der IOBroker auch. Allerdnigs klappt das dort nicht mit dem Sonoff Adapter sondern man muss schon den richtigen MQTT Server/Client nehmen... und dann (leider!!!) intern mit dem Sonoff Adapter verknüpfen....
Wenn es nur darum geht schnell auf die Zeitpläne im Sonoff zuzugreifen kannst die Seite auch direkt aufrufen ohne dich durch's Menu zu klicken:
http://<IP>/tm
oder mit Password: http://<user>:<passwort>@<IP>/tm
Das Ganze in die Favoriten oder eben als Shortcut auf den Smartphone HomeBildschirm.
Evtl reicht dir das schon aus?