Moin.

Welche Tasmota? DIe Standart oder die Sensor? Wenn du Sensoren verwendest brauchst du die Sensor.bin

Schätze mal daran wird's liegen

Moin!

Das ist krass! Stimmt! Das geht zwar wenn man den websend direkt eingibet aber nicht von einem power#state, event command, etc.

Warum, ist mir echt nicht klar. Aber mit dem backlog davor klappt das. Sehr interessant.

Danke für die Rückinfo !!!

Ich hab das jetzt nochmal mit meiner eigenen openweather Zugang getestet.

Geht tadellos:

16:59:21.741 CMD: websend [api.openweathermap.org] /data/2.5/weather?q=Cottbus,de&units=metric&appid=<xxx>
16:59:21.855 RSL: RESULT = {"coord":{"lon":14.3333,"lat":51.7667},"weather":[{"id":500,"main":"Rain","description":"light rain","icon":"10d"}],"base":"stations","main":{"temp":10.68,"feels_like":10.1,"temp_min":9.32,"temp_max":12.74,"pressure":1013,"humidity":88,"sea_level":1013,"grnd_level":1005},"visibility":10000,"wind":{"speed":6.13,"deg":298,"gust":11.16},"rain":{"1h":1},"clouds":{"all":100},"dt":1634309670,"sys":{"type":2,"id":2035260,"country":"DE","sunrise":1634275612,"sunset":1634314179},"timezone":7200,"id":2939811,"name":"Cottbus","cod":200}
16:59:21.905 RUL: MAIN#TEMP performs "var1 10.68"
16:59:21.909 RSL: RESULT = {"Var1":"10.68"}
16:59:21.914 RSL: RESULT = {"��?��?$!�?us":"Done"}

Das kompilieren geht doch im Online Compiler sehr einfach.

Hab Dir hier mal ein BIN erstellt. Mit USE_WEBSEND_RESPONSE und USE_EXPRESSION für die erweiterten Rule.

Zip entpacken. Enthält das bin gezippt, ungezippt und die user_config_override.h

tasmota_9.5.0_DE.zip

Hi ....

Zitat von karoCB

Ist die Umgebung Tasmota 9.4 richtig übersetzt wenn die Daten wenigstens im RESULT sichtbar werden oder kann ich ein aktuelles 9.5. mit Websend_Response entladen?

Zumindest ist USE_WEBSEND_RESPONSE gesetzt wurden, sonst würde der ja nicht aufschlagen.

Bei mir ergibt:

rule2 on main#temp do var1 %value% endon

rule2 1

und diesem JSON:

{"coord":{"lon":14.3333,"lat":51.7667},"weather":[{"id":804,"main":"Clouds","description":"overcast clouds","icon":"04n"}],"base":"stations","main":{"temp":9.07,"feels_like":7.21,"temp_min":8.21,"temp_max":9.36,"pressure":1022,"humidity":77,"sea_level":1022,"grnd_level":1013},"visibility":10000,"wind":{"speed":3.32,"deg":288,"gust":5.69},"clouds":{"all":86},"dt":1634142396,"sys":{"type":2,"id":2035260,"country":"DE","sunrise":1634102607,"sunset":1634141640},"timezone":7200,"id":2939811,"name":"Cottbus","cod":200}

dieses Ergebnis:

09:46:01.065 RSL: RESULT = {"coord":{"lon":14.3333,"lat":51.7667},"weather":[{"id":804,"main":"Clouds","description":"overcast clouds","icon":"04n"}],"base":"stations","main":{"temp":9.07,"feels_like":7.21,"temp_min":8.21,"temp_max":9.36,"pressure":1022,"humidity":77,"sea_level":1022,"grnd_level":1013},"visibility":10000,"wind":{"speed":3.32,"deg":288,"gust":5.69},"clouds":{"all":86},"dt":1634142396,"sys":{"type":2,"id":2035260,"country":"DE","sunrise":1634102607,"sunset":1634141640},"timezone":7200,"id":2939811,"name":"Cottbus","cod":200}
09:46:01.075 RUL: MAIN#TEMP performs "var1 9.07"
09:46:01.080 RSL: RESULT = {"Var1":"9.07"}
09:46:01.085 RSL: RESULT = {"":"Done"}

Das macht übrigens keinen Sinn.

Zitat von karoCB

on VAR1#Status do VAR1 endon

Wenn schon dann var1#state als trigger. Und "do var1" ja was soll den mit var1 gemacht werden?

Möglich das die Rule nicht geht weil der Syntax falsch ist.

Oder Du hast noch was in der Rule1 stehen, vom experimentieren und die Rule2 gar nicht aktiviert und jetzt performt die experimentelle Rule1 oder so.

Hi.

Zitat von premo

Start war gestern laut Diagramm so gegen 19 Uhr was aber ja nicht sein sollte.

Hmmm ... Die Schaltzeiten liegen werden ja im Timer festgelegt. Das hat nix mit der Rule zu tun.

Man könnet auch ein MQTT publish mit einfügen beim schlaten:

rule1 on system#boot do var2 360 endon on clock#timer=1 do backlog dimmer 0; Power1 1; rule2 1; var1 1; publish stat/<topic>/RESULT {"Timer1":"%time%"} endon on clock#timer=2 do backlog rule3 1; var1 100; publish stat/<topic>/RESULT {"Timer2":"%time%"} endon

Hi.

mit #define USE_WEBSEND_RESPONSE in den benutzerdefinierten Parametern, geht das in allen aktuellen Tasmotaversionen. Auch in der 9.5.0.

JSON wertest du einfach mit dem Parameter aus:

Bsp:

{"PARAMETER1":"WERT1"}

on PARAMETER1 do var1 %value% endon

Durch die JSON Ebenen hangelst Du dich dann mit # und/oder "?" als Wildcard.

Bsp:

{ROOT:{"PARAMETER1":"WERT1"}}

on ?#PARAMETER1 do var1 %value% endon

In Deinem Fall:

on main#temp do var1 %value% endon

Rule Trigger~

Rule trigger names are derived from the JSON message displayed in the console. Each JSON level (all values enclosed in {...}) is separated in the trigger with a #.

A rule trigger can consist of:

• [TriggerName]#[ValueName]
• [TriggerName]#[ValueName][comparison][value]
• [SensorName]#[ValueName]
• [SensorName]#[ValueName][comparison][value]
• Tele-[SensorName]#[ValueName]
• [TriggerName1]#[TriggerName2]#[ValueName]
• [TriggerName1]#?#[ValueName]

Use ? as a wildcard for a single trigger level. Rule will trigger on [TriggerName]#?#[Value] where ? is any value.

EDIT:

Aber echt interessant das man sich so ne externe Temperatur in's gerät holen kann

Moin.

Zitat von int2k

Zum Verständniss: Der Timer in den "Zeitprogrammen" setzt die Var wie genau zurück?

Ja, genau. Das passiert über den Clocktimer, der die var1 mit 0 beschreibt. Die sollte eigentlich auch im Json übertragen werden add1 zeigt dann eigentlich nur den Wert zu dem addiert wurde, was natürlich var1 entspricht. Wenn im Zeitplan ein Timer mit Aktion auf "Regel" steht wird zur eingestellten Zeit ein event clock#timer<x> ausgeführt. In der Rule1 wird dieser Trigger ausgewertet um den Zähler (var1) zu reseten.

Zitat von int2k

Kann man das ändern? Und gibts die Möglichkeit die Variable anders zu benennen?

Die Variablennamen kannst du nicht ändern aber du kannst ein eigenes MQTT Publish nach Deinen Wünschen senden. Da kann man dann spielen, will man das mit jeder Teleperiod (default 300 Sekunden, kann man aber auch bis auf 10 runterschrauben) oder bei jeder Wertänderung (MQTT Datenlast??)

Beispiel:

Delay:

rule2 on var1#state do backlog delay 10; add1 1; publish stat/<topic>/RESULT {"Laufzeit":%value%} endon

Ruletimer

rule2 on rules#timer=1 do backlog add1 1; ruletimer1 1 endon on var1#state do publish stat/<topic>/RESULT {"Laufzeit":%value%} endon

Moin.

Naja .... wenn dir das in Sekunden reicht, könnte man die Einschaltzeit in ne Variable (var1) zählen lassen. Die wird dann ja per MQTT übertragen.

Delay ist allerdings nicht besonders exakt. Wenn das nicht genau genug ist kann man es mit Ruletimer versuchen.

In den Zeitprogrammen einen Timer auf 00:00 Uhr und auf "Regel" konfigurieren der täglich um 00:00H die Variable zurücksetzt.

Mit Delay:

rule1 on clock#timer=1 do var1 0 endon on power1#state do backlog rule2 %value%; var1 %var1% endon

rule2 on var1#state do backlog delay 10; add1 1 endon

Mit Ruletimer

rule1 on clock#timer=1 do var1 0 endon on power1#state do backlog rule2 %value%; ruletimer1 1 endon

rule2 on rules#timer=1 do backlog add1 1; ruletimer1 1 endon

Edit:

Geht natürlich auch in Minuten indem man den Delay auf 600 oder den Ruletimer auf 60 setzt.

Moin.

Kurios!

Was passiert den mit var4 bzw. was gibt die Konsole für nen var4 Wert aus, wenn du die vor dem Ruletimer nochmal mit sich selbst setzt?

on event#check>%sunrise% do Backlog Var4 0; Add4 %time%; Sub4 %sunrise%; Mult4 600; var4 %var4%; RuleTimer3 %Var4% endon

Könnte aber auch daran liegen:

Immerhin versuchst Du einen Ruletimer mit über 102 Stunden also über 4 Tage zu setzen.

Für was man das wohl in ner Sonnenauf/untergang Steuerung brauchen kann?

Moin. Die Rule2 soll auch auf 0 stehen. Die wird vom clocktimer1 aktiviert und in der Rule2 wird hochgedimmt.

Die Rule3 wird zum runterdimmen verwendet. Rule2 und Rule3 deaktivieren sich nach dem Ablauf der Dimmphase selbst.

Aktiv muss nur Rule1 sein, die aktiviert über die Clocktimer die beiden anderen.

Zum testen einfach mal den Delay auf einen kleinen Wert z.b. 20 setzen und den Clocktimer auf z.B. 3 Minuten in die Zukunft und sehen was passiert (Konsole)

Ich hab allerdings einen Fehler entdeckt. Bzw bei einem Test ist mir das erst aufgefallen. In Rule2 und Rule3 fehlt jeweils ein "=".

Denn bei add und sub werden in die Variablen Werte mit 3 Nachkommastellen geschrieben und und das muss dann numerisch vergleichen werden, sonst klappt das nicht:

rule1 on system#boot do var2 360 endon on clock#timer=1 do backlog dimmer 0; Power1 1; rule2 1; var1 1; endon on clock#timer=2 do backlog rule3 1; var1 100 endon

rule2 on var1#state<100 do backlog dimmer %var1%; delay %var2%; add1 1 endon on var1#state==100 do rule2 0 endon

rule3 on var1#state>1 do backlog dimmer %var1%; delay %var2%; sub1 1 endon on var1#state==1 do backlog dimmer 0; delay %var2%; power1 0; rule3 0 endon

Zitat von gnubbbel

Könnte man dies nicht über einen LDR und einer PWM Low Current Leuchtdiode auch realisieren?

Keine Ahnung

Aber was man machen könnte:

Man konfiguriert in Tasmota:

Ein Reilas für Wert +/- (Power1)

Ein Relais für Impuls bzw. Schritt (Power2)

Ein Relais für speichern (Power3 braucht man aber eigentlich nicht. Wenn einen Wert speichern dann in Tasmota)

Eine virtuelle PWM auf einen ungenutzten GPIO, für den bekommt nen Slider mit einem Dimmwertbereich von 0 - 100% wie das digitale Poti ja auch hat.

Und jetzt kommen mal wieder die Rules in's Spiel.

Man setzt beim Systemboot erst mal alles auf 0, den digitalen Poti und den Dimmer (Nullabgleich).

Dann fragt man den virtuellen Dimmwert ab vergleicht ihn mit dem Wert in einer Variablen die dem Widerstand von 0 - 100% entspricht.

Ist der gesetzte Dimmwert kleiner als der Sollwert wird der Power1 geschaltet um den Widerstand zu erhöhen und eben die Anzahl der Schritte das Relais2 an und aus geschaltet. Für kleiner dasselbe nur eben in die andere Richtung.

rule1 on system#boot do backlog rule2 0; dimmer 0; power1 1; var1 0; var2 0; var3 101 endon on var3#state==1 do rule2 1 endon on var3#state>1 do backlog power2 2; power2 2; sub3 1 endon

rule2 on Dimmer#state do backlog var1 %value%; var2 %var2% endon on var2#state<%var1% do backlog power1 0; power2 2; power2 2; add2 1 endon on var2#state>%var1% do backlog power1 1; power2 2; power2 2; sub2 1 endon

Man kann natürlich den erreichten Endwert auch in einen Dauerhaften Speicher mem1 schreiben der nach dem "Nullabgleich" beim booten den gespeicherten Wert automatisch anfährt.

Der Dimmwert in % entspricht dann eben dem einstellbaren Widerstandsbereich in % und kann ja in der Konsole ausgelesen, angezeigt oder per MQTT übertragen werden.

EDIT:

Ach ja ... Nachteil, die Webbutton sind eher nicht nutzbar, nur der Slider. Denn bei Bedienung über die Button würden ja die Variablen die die Werte "nachstellen" das ja nicht mitbekommen.

Zitat von gnubbbel

Schade ich dachte sowas hier könnte man unter Tasmota nutzen.

Digitales Poti

Interessant. Mit dem könnte das sogar gehen.

So wie ich das sehe wird der U/D und der INC Eingang jeweils mit nem GPIO beschaltet.

Mit HIGH/Low Signal am U/D wird eingestellt ob größer kleiner und mit jedem Impuls am INC wird dann eben in 1% Schritten der Widerstand verändert.

Mit nem weiteren GPIO an CS kann dann der aktuelle Widerstandswert gespeichert werden.

Eigentlich müssen dazu die GPIO's nur als Relais konfiguriert werden. Du musst dann halt um von Rmin auf Rmax zu kommen 100x schalten

Und Du weißt halt nie deinen aktuellen Widerstandswert, kennst also nicht den absoluten Wert sondern vergrößerst nur oder verkleinerst.

EDIT:

Bei was möchtest Du das den einsetzen, wenn ich fragen darf?

Man kann natürlich mit ner Rule auch die Schritten von 100 auf weniger reduzieren indem ich dann einfach gleich x mal schalten lasse

Moin.

Nicht das ich wüsste. Es gibt zwar Arduino digital Potentiometer die per I2C angesteuert werden aber werden nicht von Tasmota unterstützt.

Zitat von premo

Oh, ich glaube den Fehler gefunden zu haben.

Hatte vergessen die Latitude und Longitube zu setzen.

Hätte ich auch getippt. clocktimer trigger ist clocktimer trigger

Stimmt, stand ja im ersten Post mit den Clocktimer.

Ich geh davon aus das Power1 Deine LED schaltet? Ich verwende dafür jetzt Power1 ansonsten bitte anpassen.

Also einen Timer (Clocktimer1 = hochdimmen) für Sonnenuaufgang setzten und den auf Regel stellen, dasselbe für Sonnenuntergang. (Clocktimer2=runterdimmen)

Der Delay bei 100 Schritten/Stunde (0-100%) ist 36 Sekunden zwischen jeden Step, also 360)

Ich vernachlässige jetzt mal evtl vorhandene Dimmwerte sondern wie ich das verstehe dimmen wir immer von 0 auf 100 und wieder auf 0.

In der Konsole muss Setoption20 1 gesetzt sein

rule1 on system#boot do var2 360 endon on clock#timer=1 do backlog dimmer 0; Power1 1; rule2 1; var1 1; endon on clock#timer=2 do backlog rule3 1; var1 100 endon

rule2 on var1#state<100 do backlog dimmer %var1%; delay %var2%; add1 1 endon on var1#state=100 do rule2 0 endon

rule3 on var1#state>1 do backlog dimmer %var1%; delay %var2%; sub1 1 endon on var1#state=1 do backlog dimmer 0; delay %var2%; power1 0; rule3 0 endon

Der Delay wird in der Rule1 in var2 gesetzt.

Weil mit Sub nicht bis auf 0 subtrahiert werden kann sondern nur bis auf 1 muss das extra ausgewertet werden.

Zum Testen einfach den Delay kleiner stellen.

bishop

Ja stimmt! Copy & Paste Fehler. Ist korrigiert, danke für den Hinweis.

Zitat von Ossabow

Da waren vermutlich dickere Pfeile verwendet worden

Ich glaub bei Shutter Verwendungen sind in Tasmota Pfeilsymbole automatisch integriert. Vermutlich daher die dickeren Pfeile.

Hab ich aber selbst nicht deshalb kann ich das auch nicht mit Bestimmtheit sagen.

EDIT:

Können aber auch Unicode Symbole sein die man in der Zeichentabelle findet.

Hi.

hast einen MQTT Server am laufen an dem sich der Sonoff einbucht?

Moin.

Zitat von Ossabow

Supi, die Möglichkeiten dieser Software kann ich kaum überschauen!

Geht mir genauso

Zitat von Ossabow

auch andere Symbole gehabt, geht das auch mit selbsterstellten?

Was meinst du mit Symbole? Bilder? Das geht nicht. Was dargestellt wird ist Text. Damit müsste dann alles gehen was der Zeichensatz hergibt.

Nimm doch mal Speed 40

Allerdings würde ich erst fade und speed und dimmer setzen bevor ich einschalte.

backlog speed 40; fade 1; dimmer 100; power2 1

EDIT:

Spielerei am Rand:

Wenn man's ausreizt könnte man auch mit Rules spielen (ungtestet !!)

rule1 on tele-Dimmer do var2 %value% endon on power2#state=1 do backlog rule2 1; rule3 0; var1 %var2% endon on power2#state=0 do backlog rule2 0; rule3 1; var1 %var2% endon

rule2 on var1#state!=100 do backlog dimmer %var1%; delay 10; add1 1 endon

rule3 on var1#state!=0 do backlog dimmer %var1%; delay 10; sub1 1 endon

Rule1:

- wird der aktuelle Dimmwert mit jeder Teleperiod in var2 eingelesen (evtl. Teleperiod höher stellen)

- wenn Relais 2 eingeschaltet wird, wird rule2 aktiviert, rule3 deaktiviert und var1 auf den aktuellen Dimmwert gesetzt.

- wenn Relais 2 ausgeschaltet wird, wird rule2 deaktiviert, rule3 aktiviert und var1 auf den aktuellen Dimmwert gesetzt.

Rule2: dimmt hoch vom aktuellen Dimmwert bis zu 100%

Rule3: dimmt runter vom aktuellen Dimmwert auf 0%.

Wie schnell das ganze dimmt wird mit dem Delay (0,1Sekunden-Schritte) festgelegt und kann bis auf 3600 (6min) zwischen den Einzelschritten hoch geschraubt werden. Also im Extremfall 600 Miunten bis von 0% auf 100% gedimmt ist.

Wenn man sehr lange Delayzeiten hat kann man mit Fade und Speed den Übergang smoother machen.

Bei kurzen Zeiten würde ich zumindest den Speed runtersetzen nicht das das Faden länger als der Delay braucht.

Nachteil: Um vom aktuellen Dimmwert aus zu dimmen hängt das ganze leider an der Teleperiod um den aktuellen Dimmwert auszulesen.

Man könnet aber auch stattdessen immer von einem absoluten Wert aus dimmen ... also immer von 0 hoch oder von 100 runter,