Shelly1, langer und kurzer Tastendruck

  • Mal wieder was zum Thema und auf Anfrage von Ossisp1 mit Anpassung:


    3 Minuten "Treppenlichtautomat" mit Möglichkeit Dauerlicht einzuschalten


    # 1. kurzer Tastendruck -> Licht AN für 3 Minuten (RuleTimer1 180)

    # 2. langer Tastendruck >2sec (SetOption32 20) -> kurzes Blinken als Quittierung und -> Dauer-Licht AN

    # 3. langer Tastendruck während AN (1. oder 2. läuft) -> kurzes Blinken und -> Dauer-Licht AN

    # 4. kurzer Tastendruck immer wenn Licht AN -> dann Licht AUS


    # Einstellungen:


    # auf "Switch1" einstellen (nicht Button)

    # bei Sonoff etc.

    SwitchMode1 5

    # bei Shelly

    SwitchMode1 6


    BackLog SetOption32 20; PulseTime1 0; SetOption1 1; SwitchTopic1 0

    BackLog Rule1 1;Rule2 1;Rule3 1; BlinkCount 1; BlinkTime 3


    LG

  • Hi, ja Port ist geändert. Ich habe auch einen Shelly 2.5 im IP symcon dazu verwendet einen weiteren zu schalten. Bei Garagenlicht aus, schaltet auch der Geräteraum ab. Ist das überhaupt schlau. Jetzt würde ich evtl. lieber ne Rule machen, aber ohne Publish wird es wohl nichts.


    Ich habe jetzt 100 Seiten Fotobuch für die Schwiegermutter anne Backen. Wenn das fertig ist probiere ich mit der Firmware und dem MQTT Tool aus. Noch 30 Seiten, was man nicht alles macht..


    Wenn noch jemand ne heiße Idee hat...

    Ich finde im gesamten Netz nichts dazu.


    Viele Grüße


    Manuel

  • Ich habe kein MQTT Passwort gesetzt.

    Ist das für ein Publishing nötig?

    Wenn der MQTT-Broker kein Passwort braucht, dann brauchst du auch keines für den publish-Befehl. Funktioniert denn die "Alternative" Websend?

    Code
    websend [192.168.178.XX] power 1
  • MQTT.fx sagt im Log:


    2019-12-16 23:49:50,375 INFO --- MqttFX ClientModel : attempt to add PublishTopic

    2019-12-16 23:49:50,376 INFO --- MqttFX ClientModel : sucessfully published message on to topic cmnd/test0815x/POWER (QoS 0, Retained: true)


    und beim Verbinden:


    2019-12-16 23:51:40,909 INFO --- BrokerConnectorController : onConnect

    2019-12-16 23:51:40,910 INFO --- ScriptsController : Clear console.

    2019-12-16 23:51:40,912 INFO --- MqttFX ClientModel : MqttClient with ID 003c12a41e664bb0922cbe6aadac4799 assigned.

    2019-12-16 23:51:40,920 INFO --- MqttFX ClientModel : session present: false


    Was hat das mit session present: false auf sich?

    Bei Symcon kommt es auch hier an, aber nicht in der Tasmota und nicht im MQTT.fx


    Also ich kann nur zum Nachdenken anregen... Ich gucke mal, was ich zu MQTT Sessions finde.


    Gute Nacht!

  • websend klappt, hm

    Das ist zwar schön, hilft uns aber nicht wirklich weiter, wäre nur eine mögliche Alternative, wenn es nur um die Steuerung eines anderen Gerätes geht. Für die Kontrolle (ist es wirklich passiert und muss das neue Ergebnis/der neu Zustand irgendwie weiterverarbeitet oder registriert werden) bringt es leider nichts. HTTP ist eben ein anderes Protokoll als MQTT. Wir wissen jetzt nur, dass es kein Netzwerk(hardware-)problem ist, sondern ein Software-/Konfigurationsproblem.


    Ich habe folgendes Dokument (PDF) gefunden. Ich habe es nur überflogen und es gibt dort ein Kapitel zu session present. Es scheint mit dem QoS (quality of service) zu tun zu haben. Damit kann man definieren, ob und in welchem Umfang eine geschickte Nachricht bestätigt wird. Da scheint was im Broker aktiviert zu sein, was Tasmota-Geräte standardmäßig nicht leisten können: Bestätigung. Die können zunächst nur QoS 0: fire and forget.


    http://docs.oasis-open.org/mqt…1.1/os/mqtt-v3.1.1-os.pdf


    https://mosquitto.org/man/mosquitto_pub-1.html


    Mögliche Lösung, falls meine Vermutungen im Grundsatz stimmen und der Broker sich nicht auf QoS 0 umstellen lässt, hier:

    https://github.com/arendst/Tasmota/issues/4693

  • Wie gesagt funktioniert top.


    Ein Sache hab ich noch:

    Gibt es noch die Möglichkeit das das ganze auch bei Ansteuerungen über Alexa so anzusteuern?

    Alexa an und dann nach 180 Sekunden aus?

    40x Shelly/Sonoff (Tasmota)

    2 x Yeelight (Xiaomi)

    Raspberry Pi4b mit ioBroker und ner kleinen VIS

    Conbee2 mit Ikea, Xiaomi und Philips Aktoren

    Einmal editiert, zuletzt von Ossisp1 ()

  • Hallo,

    ich fang gerade erst mit Tasmota an. Grund war die geniale Lösung von NoitaercX. Der Shelly 1 ist geflasht. Testlampe hängt dran. Taster schaltet nun alles wie man es sich wünscht.

    Wenn ich nun aber den Shelly nicht per Taster sondern über die Weboberfläche oder über Homebridge anschalte, greifen die Rules nicht. Die Lampe geht ohne Zeitsteuerung an und aus. Ich will im Ziel den Shelly über die Taster schalten, aber auch über Homebridge.

    Muss da eine eigene Rule rein? Und muss diese Rule anders sein, wenn ein Bewegungsmelder (Hue außen BWM) das ganz auslösen soll?


    Danke schon im voraus!

  • Hi.


    sondern über die Weboberfläche oder über Homebridge anschalte, greifen die Rules nicht.

    Das ist richtig, weil der Trigger ja er Switch#state ist also der Physikalisch angeschlossenee Schalter.


    Wenn du auch über die Webobeflache schalten möchtest, muss man improviesieren, da es dort keinen "kurzen" oder "langen" Tastendruck gibt.

    Man könnte auf zwei unbelegeten freien GPIO's jeweils ein "virtuelles" Relais konfigigurieren, die kurz und lang simuleieren.


    Relais2 = "kurzerTastendruck"

    Relais3 = "langer Tastendruck"


    Die Tasten könnte man beschriften:

    webbutton2 kurz

    webbutton3 lang


    Dann die Rule aus #41 erweiteren:

    Angteriggert wird dann eben mit Power2 bzw. Power3 durch die Homebridge

    benzino77 Tasmocompiler

    Gitpod Master Release


    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / MagicHome / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E / WEMOS D1 Mini / ESP32Cam

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712/INA219/MHZ19B/DS3231

    mosquitto/bash/html/cgi auf RPI 2B+/Sprachsteuerung via IFTTT/4xGoogle-Home-Mini