Beiträge von HoerMirAuf

Hi.

Wenn die Tasmota Steckdose stromlos ist dann ist sie aus, weil das Relais abfällt und weil kein Saft da ist.

Hat sie wieder Strom stellt sich mit der default Konfiguration das Relais auf den letzten Zustand ein.

Wenn das Relais vorher an war ist es das nach Strom wiederkehr auch wieder. Das ist zuverlässig. Unter welchen Umständen sollte das nicht unbedingt richtig wiedergegeben werden?

Der Zustand wird dann auch im Webinterface dementsprechend angezeigt. Ist das WebIF nicht erreichbar ist wohl kein strom da.

Mann kann sich aber auch mit sendmail und rules eine email mit dem Zustand schicken lassen nach dem reboot, vorausgesetzt das sendmail einkompiliert wurde.

Oder man überwacht das per MQTT.

Ich selbst hab nen Raspi mit mosquitto MQTT Server drauf und prokolliere mit einem bash skript die LWT online/offline meiner Geräten mit.

EDIT:

Die uptime Zeit wird übrigens auch im WebIF under Information angezeigt bzw im MQTT Status übermittelt.

Das Problem ist das das der Trigger (schalten) ja nur einmal den Timer antriggern darf auch wenn 2 mal geschaltet wird.

oke ... das wäre mein Vorschlag

rule1 on system#boot do var1 0 endon on switch1#state==1 do add1 1 endon on var1#state==1 do backlog rule2 1; ruletimer1 5 endon on var1#state==2 do backlog rule2 0;power1 2; var1 0 endon

rule2 on rules#timer=1 do backlog var1 0; rule2 0 endon

Funktion:

wenn der Schalter schaltet wird var1 hochaddiert (ist ja beim start "0")

nach dem ersten schalten ist var1=1 und die rule2 wird aktiviert und ein ruletimer gestartet

in der rule 2 wird der ruletimer überwacht. Wenn dieser nach 5 Sekunden abläuft, weil kein 2 tes mal innerhalb 5 Sekunden geschaltet wird, wird var1 wieder auf 0 gesetzt und rule2 dekativiert sich selbst.

wird aber innerhalb der 5 sekunden ein 2tes mal geschaltet ist der ruletimer ja noch nicht abgelaufen der var1 auf 0 zurücksetzt und somit wird var1 auf 2 hochgezählt. Ist diese auf 2 wird ebenfalls die rule2 mit der Timerüberwachung deaktiviert, var 1 wieder auf 0 gesetzt UND das Relais1 getoggelt,

Du siehst ... ganz so unkomliziert ist das nicht

EDIT:

auch ...

Rule 1 muss natürlichg noch aktivert werden:

rule1 1

und ich schätze rule1 muss auch auf once gesetzt werden damit der switch#state trigger erst auf 0 und wieder auf 1 wechseln muss damit er auslöst

rule1 5

Ah, schade.

Stimmt ich hatte auch nen Denkfehler mit meinen Hinweisen auf double press.

Das bezieht sich ja auch taster die am Sonoff angeschlossen sind.

Hmmmm .... ich hab noch keine rechte Idee wir das zu lösen ist.

Der Ansatz wäre:

Beim schalten wird ein ruletimer gestartet und eine variable zählt hoch.

Ist der ruletimer abgelaufen setzte er die Variable wieder auf 0

Ist die Variable auf 2 bevor der Ruletimer abgelaufen ist wird getoggelt.

EDIT ... denkfehler.

Bei jedem schalten wird ja der Ruletimer neu gestartet.

Wie wird den die Steckdose außerhalb geschaltet?

Ist die dann an dem Basic in der Leuchstofflampe angeschlossen?

Moin.

warum machst du das mit 2 x Schalten? Nimm doch einfach "long press"

Disable switch single press and use long press

SetOption11 0

Switches do not have double press feature

[assuming a connected pushbutton configured as Switch1]

• single press: Does nothing (empty Delay commands)
• hold 2 secs: Toggle Power1

 code" style="font-size: inherit; color: var(--md-default-fg-color--lightest);">Backlog SwitchTopic1 0; SwitchMode1 5; SetOption32 20  

 code" style="font-size: inherit; color: var(--md-default-fg-color--lightest);">Rule1  ON Switch1#State=3 DO Power1 2 ENDON  ON Switch1#State=2 DO Delay ENDON  

bzw. double press:

Button single press, double press and hold~

[assuming Button1 and Setoption73 0]

• single press: Toggle Power1
• double press: send a mqtt message
• hold 2 secs: send a different mqtt message

 code" style="font-size: inherit; color: var(--md-default-fg-color--lightest);">Backlog ButtonTopic 0; SetOption1 1; SetOption11 1; SetOption32 20

 code" style="font-size: inherit; color: var(--md-default-fg-color--lightest);">Rule1  ON button1#state=3 DO publish cmnd/topicHOLD/power 2 ENDON  ON button1#state=2 DO publish cmnd/topicDOUBLEPRESS/power 2 ENDON 

Rule1 1

Another example:

[assuming Button1 and Setoption73 0]

• single press: send MQTT message
• double press: Toggle Power1 (SetOption11 swaps single and double press)
• hold 2 secs: send another mqtt message

 code" style="font-size: inherit; color: var(--md-default-fg-color--lightest);">Backlog ButtonTopic 0; SetOption1 1; SetOption11 0; SetOption32 20  

 code" style="font-size: inherit; color: var(--md-default-fg-color--lightest);">Rule1  ON button1#state=3 DO publish cmnd/topicHOLD/power 2 ENDON  ON button1#state=2 DO publish cmnd/topicSINGLEPRESS/power 2 ENDON 

Ich leider auch nicht.

Nebendran sind RGB Pins ... da ist aber nix angeschlossen oder? Das hätte mich sonst an die MagicHome erinnert... da hätte ich gesagt mit PWM versuchen.

Leider erkennt man auf den Bildern nicht wirklich wohin die Leiterbahnen der Abgänge vom angelötete Kabel gehen...

Der 3 adrige Abgang erinnert mich bei RGB allerdings mehr an die WS2812 LED. Die sollten doch von Tasmota eigentlich unterstützt werde:

https://tasmota.github.io/docs/WS2812B-and-WS2813/

EDIT:

Ach Quatsch ... ist CCT steht ja drauf auf dem Teil. Wäre aber dann ja auch PWM. Evtl hilft das:

https://tasmota.github.io/docs…pwm-channel-configuration

bzw Templates für CCT von hier:

https://github.com/stefanbode/…/blob/master/TEMPLATES.md

https://github.com/stefanbode/…d#bulb-red-green-blue-cct

Zitat von Markus081

Wird es denn wohl in absehbarer Zeit möglich sein, dass man auch die "Funk" Signale auswerten kann?

Ich denke eher nicht. Wie gesagt ist der RF Empfänger ein separates gerät das nur auf die GPIO zugreift.

Zitat von Markus081

Für die RF Bridge gibt es ja neben der Tasmota Firmware auch noch extra eine für den RF Chip.

Das ist richtig, und zwar um den erweiterten RF-Bereich zu empfangen nicht nur die Sonoff Codes.

Bei der Bridge ist es auch notwendig Codes auszuwerten um sie den WebIF Buttons zuzuweisen, im Gegensatz zu nem RF Switch.

Sie soll ja als "Bridge" funktionieren da ist das unvermeitlich.

Zitat von Markus081

....ansonsten RF Bridge ist bereits bestellt.

Moin.

Zitat von Markus081

Aber in der Konsole kann ich leider keine Codes oder ähnliches erkennen, um z.B. Rules zu erstellen für KNX

Ne, da wird auch nix auftauchen. Der RF Chip bedient einfach nur einen GPIO wie ein Button, soweit ich weiß.

Wenn du die RF Codes auswerten möchtest verwendest du am besten die RF-Bridge.

Moin.

Nun ja ... was Sonoff/Shelly betrifft:

Im Prinzip bedient der Sonoff Basic und der Shelly das gleiche Anwendungsgebiete.

Für eine Nachinstallation (Schalterdose) eignet sich der Shelly besser. Der Sonoff Basic ist preislich günstiger und wenn Solche Dinge wie Einbauplatz und potentzialbehafteter Schalteingang keine Rolle spielen ist dieser wohl der Interessantere. Wenn's um's basteln geht Sensoren/GPIO Eingänge etc. ist der Sonoff halt wieder besser weil man hier das Gehäuse besser öffnen kann und besser an der Elektronik fummeln kann.

Letztendlich ist das eine Philosophiefrage, was dir besser gefällt und für den Einsatzzweck mehr Sinn macht.

EIne Anwendungsliste macht meiner Meinung nach keinen SInn. Wer mit Sonoff/Shelly arbeitet, hat sich für Bastellösungen entschieden. Das macht man weil man Spaß dran hat. Das bedingt aber ein wenig Einarbeitung und die meisten EInsatzzwecke ergeben sich doch ganz logisch von alleine:

Bedarf:

- Ich brauch eine Schaltkanal

- soll hinter die Schalterdose

- will meinen Schalter mit anschließen

Ergebnis:

Da geht nur ein Shelly !!

Bedarf:

- Ich will ne Lampe Smart machen

- Einbauplatz genug vorhanden

- will noch einen Temperatursensor anschließen

Ergebnis:

Sonoff Basic, weil günstiger und vielleicht leichter ein Sensor anzuschließen.

(Könnte aber auch ein Shelly machen ... wenn der Dir besser gefällt.)

Mein Tipp:

Überleg dir was du machen möchtest und welche Bedingungen du hast und mach Dir Gedanken wie du das am besten realisieren kannst.

Evtl. mal nen Shelly bestellen und nen Basic um zu sehen was dir besser gefällt und liegt und ansonsten von Fall zu Fall hier um Rat fragen wenn Du nicht selbst auf ein Ergebnis kommst.

Zitat von TTT

Hatte mir dazu ausgedacht das ich mit der Pulstime entsprechend der Hoch und Runterfahr dauer, mir datenpunkte im Iobroker setzen kann.

Ich dachte du willst das im IOBRoker machen?

Da ist das doch kein Problem mit einem Script eine Laufzeit einzustellen die EIN und nach einer Zeit wieder AUS schaltet?

Das braucht doch nicht mal Pulsetime.

Hast du dir das schon durchgelesen?

https://tasmota.github.io/docs/Blinds-and-Shutters/

https://tasmota.github.io/docs…and-Shutters/#calibration

Das muss ich auch mal testen ... Cam ist bestellt !

oke .... gemu2015 war schneller

Bitte beachte:

https://tasmota.github.io/docs/Arduino-IDE/

Most builds will not compile successfully with Arduino IDE anymore

Ich würde das mit dem online compiler machen.

Und ja, die defines müssten in die user_config_override. Ist aber im online compiler bequem in ein extra bereich einzugeben.

... zumal der Post 2018 erstellt wurde.

Moin,

siehe: RE: RCWL-0516 mit 3,3v am Basic?

Moin.

Ich schätze der ist sicherheitshalber nur zu Strombegrenzung. Ich denke aber das der nicht zwangsweise notwendig ist.

Dem GPIO kann ich normalerweise auch die 3,3 direkt drauf geben, da passiert nix , macht man bei nem Schalteingang mit Pulldown ja auch.

Moin.

an sich hier:

https://tasmota.github.io/docs/Scripting-Language/

Beim Scripting kann ich leider nicht helfen.

Evtl mal einen neuen Thread erstellen bzw. diesen hier umbennenen damit andere auch sehen das um Script geht.

Zitat von TTT

Also zb : 100% runter sind 10sec
Dann wären 50% runter ja nur 5sec und ich hinterlege den Datenpunkt zb. 1 Somit kann ich über einen Script die Aktuelle Position abfragen...

Jedoch sehe ich hier ein enormes Fehlerpotential...

Machen im Prinzip alle Aktoren so. Die hochwertigen z.b. bei KNX haben aber eine automatische Laufzeitermittlung um das immer auszugleichen (erkennen Laufzeiten zwischen oberer und unterer Endlage anhand des Stromflusses)

Wer auf sicher geht fährt seine Jalousien oder Rolles über den oberern oder unteren Endpunkt. Also erst ganz hoch mit der maximalen Laufzeit und dann mit der anteiligen wieder runter.

Oder man löst ab und zu eine Referenzfahrt aus um über einen Endpunkt neu zu "kalibrieren"

Zitat von juriii

Wenn ich mit Port 80 das versuche, bekomme ich eine Antwort vom Webserver, dass eine Umleitung zu https aktiv ist. Sobald ich Port 443 abfrage kommt nur der Response: "Websend completed"

hab noch nichts mit websend_respond gemacht ...

Ich vermute aber das der Webserver den Respond auch auf 443 (https) an Tasmota zurück gibt und da geht's ins Leere, da nur http (Port80 bzw. kein SSL)