SONOFF RF Bridge und IDX in Domoticz

  • Aktion bei ein soll den Impuls zum öffnen geben?

    nein, das Tor ist praktisch mit einem potentialfreien Kontakt schaltbar...

    ... ich ich taste -> Tor geht auf ... ich taste --> Tor geht zu ... (das ist der RF)

    ein Rollschalter, welcher unten am Tor sitzt schalten mir den Basic auf ON (Tor offen) wenn das Tor ca. 30 ca. in der Höhe ist... sobald der Basic einschaltet, soll eine Zeit ablaufen, also "Aktion bei ein" ist die Zeit abgelaufen, soll der das Tor (RF) wieder anpulsen, damit es wieder zumacht.

    Komisch ist, das auch in der Domo-Log nichts von der Zeit und nichts von dem eingegebenen Befehl zu sehen ist.

  • ich glaube ich hab Grundsätzlich eine falsche Vorstellung was Domo anbelangt.

    Hab mit 2 Touch in meinem Büro mal getestet, wenn ich mit Domo schalte funktioniert das genauso wie ich es haben will...

    ... einen 2. Aktor mitschalten, einschaltverzögert usw usw.

    Wenn ich allerdings auf einen externen Taster drücke, dann fallen alle Einstellungen in Domo weg... Licht schaltet sofort ein, ein zweites in Domo schaltet nicht mit usw.

    Liege ich da richtig, wenn ich diese super Einstellungen wie Verzögerung usw. haben will nur über Domo schalten könnte?

  • Wenn Domo nicht mitkriegt, dass du einen externen Taster drückst, dann schaltet alles ohne Demo.

    Ich hab mir mit einem WEMOS D2 mini eine Schalteinheit gebaut, mit der ich über sechs integrierte Schalter meine Szenen schalten kann. Dabei wird z.B. auch der TV über ein IR-Signal eingeschaltet. Wenn allerdings vorher einer den TV mit der Fernbedienung einschaltet, dann ist die ganze Routine beim Teufel, weil DOMO nicht weiß, dass die Kiste schon an ist und schaltet dann aus anstatt ein.

    Andere Frage:

    Hat einer Ahnung von MQTT, ich komme mit meiner RF-Bridge nicht weiter und

    Theo Arends

    von Tasmota meldet sich nicht bei mir :(

    Hat irgendwer einen guten Draht zu ihm?

    Danke

    Gruß

    Sepp

  • Du kannst auch im Log von Domo nachschauen, der zeigt dir auch an, wenn da Fehler von irgendeinem Modul, z.B. MQTT-Broker oder Homebridge auflaufen.

    Wenn du aber bei Betätigung des SonOff im Domo eine Statusänderung siehst, dann läuft der MQTT.

    Gruß

    Sepp

  • Du kannst auch im Log von Domo nachschauen, der zeigt dir auch an, wenn da Fehler von irgendeinem Modul, z.B. MQTT-Broker oder Homebridge auflaufen.

    Wenn du aber bei Betätigung des SonOff im Domo eine Statusänderung siehst, dann läuft der MQTT.

    Ja, die Statusmeldungen funktionieren wunderbar. Hab mir auch schon einen netten Grundriss angelegt wo Statutenänderungen sehr schnell angezeigt werden. Auch die Wetterstation Netatmo liefert alle 30 Minuten die korrekten Werde diverser Messgeräte.

    Eventuell hab ich doch in der Tasmota-Oberfäche was vergessen oder nicht/falsch eingetragen. Leider finde ich nicht wirklich hilfreiche Sachen im Bezug Sonoff und Domo ?(

    Wenns in die eine Richtung funktioniert, muss es doch in die Andere auch gehen... so hofft man :)

    vG, Manfred

    • Offizieller Beitrag

    Hi,

    also ich habe zwar kein Domo.. Aber das Script (sieht fast aus wie Blockly) müsst Ihr erweitern. Bei iOBroker mache ich das so. Wenn ein Gerät beireits eingeschaltet ist frägt eine Java Routine vorher den Zustand ab. Weil mein Fernseher meldet (Samsung TV) meldet über seine eigene Web Page den Zusatnd zurück. geht sicher nicht mit jedem Fernseher... Und darum schalte ich wenn ich nicht über Alexa schalte über mein Smatphone und nur über den Broadlink. Dieser gibt automatisch den Zustand aus. Die Original Fernbedienungen sind alle verbunkert :) Also man MUSS über das Smartphon schalten was immer auf dem Tisch liegt. Alternativ würde noch Logitech gehen.

    Gruß

    Norbert

  • Nachdem ich mich nun zwei Stunden mit dem Problem beschäftigt hatte, sehe ich dass die Diskussion sich schon weiterentwickelt hat und zwar in die Richtung, die ich auch herausgefunden haben:

    Die Kommunikation zwischen Domoticz und dem MQTT-Broker ist, naja, suboptimal. (Das erinnert mich an das von mir vor ein paarWochen gepostete Thema, dass Domoticz angeblich einen Schalter schaltet, obwohl der gar nicht am Stromnetz hängt.) Zurück zum Thema: Meines Erachtens muss der MQTT-Broker ein Script hinterlegt bekommen, welches bewirkt, das Schalter B was macht, wenn an Schalter A was passiert ist. Ich stochere da gerade in Richtung node-red, ein webbasierendes Script-Interface u.a . für mosquitto, ein MQTT-Broker, der auf dem Raspi läuft. Mit einem MQTT-Sniffer (MQTT.fx) ist klar festzustellen, dass der MQTT-Broker ganz genau weiß, welcher Schalter sich in welchem Zustand befindet. Durch Aktivierung von weblog 4 auf dem Tasmota-Sonoff sieht man auch, wie dieser dauernd quasselt (alles 20 Sek. WiFi checkt), und sauber seinen Zustand über das MQTT-Protokoll bei Veränderungen mitteilt. Beim Basic steht der an-/aus Wert im Item nvalue. Das wechselt von 0 auf 1.

    Mehr kann ich leider im Moment nicht zu diesem Thema beitragen.

    Gruß

    Jörg

  • Manfred

    Ich habe jetzt eine Lösung gefunden, die tatsächlich so funktioniert, wie ich das Problem verstanden habe:

    Egal ob Schalter A über Domoticz geschaltet wird oder anders, Schalter B soll dann auch was machen.

    Die Lösung geht für diesen Fall über das Script-Tool von Domoticz. Das Video unten ist kurz und ziemlich gut zu verstehen, finde ich.

    Ein YT-Video dazu findest du hier.

    Hier siehst du mein Blockly-Skript für den abhängigen Schalter IP65, der angeht wenn der Weihnachtsstern angeht. Es wird unter einem Namen (rechts unterlegt) gespeichert.

    Hier ist das Skript für das Ausschalten: Es sieht genauso aus, nur sind beide Zustände auf Off gesetzt.

    Auch dieses Skript wird gespeichert.

    Und dies sind die Elemente, die ich benutzt habe aus den Bereichen Control, Logic und Devices->Switches. Das geht recht flott, wenn man die rechte Maustaste einsetz. Dann kannst du die Elemente nämlich super duplizieren und immer mit den Werten versehen, die du an der Stelle brauchst. Achte auf das Dreieck.:

    Es ist jetzt völlig egal, wie ich meinen Weihnachtsstern schaltee: über Domoticz, über Webinterface, über einen (meiner heißgeliebten) Terminalbefehle oder hardwaremäßig - der Weihnachtsstern hängt an einer S20-Steckdose - immer macht der Schalter_IP65 dasselbe.

    Wäre das die Lösung deiner Aufgabenstellung?

    Gruß

    Jörg

  • Mann, Mann, Mann...

    Big Sorry für meine Dummheit, die Lösung hat mir Sepp schon in Beitrag 22 übermittelt und ich Idiot hab das offensichtlich voll übersehen.

    @ Jörg, wenn du mich nicht nochmals in diese Gasse gestoßen hättest, wäre das offensichtlich nie was geworden.

    Es funktioniert natürlich wunderbar mit euren Vorschlägen.

    Manchmal sieht man echt den Wald vor lauter Bäume nicht mehr :|

    Nochmals Sorry und einen riesen Dank an euch beiden Sepp und Jörg!

    vG, Manfred

  • Manfred

    Gerne! Ist mir auch schon so gegangen. Lösung war schon beschrieben, ich habe es nur nicht wahrgenommen. Und: reiner (doppelter) Eigennutz: So habe ich dann endlich mit dem Scripting und Blockly befasst und weiß nun wie es - im Grundsatz - funzt. Und der zweite Nutzen: Wer holft, dem wird geholfen. Ich bin sicher, dass bei mir Probleme auftauchen werden, wo ich deine und der anderen Hilfe brauchen werde. In diesem Sinne...

    Ich wünsche eich einen guten Rutsch ins Neue Jahr!

    Gruß

    Jörg

    PS: Domoticz ist, finde ich, fürchterlich dokumentiert und das so genannte Manual ist ein Witz und maximal halb fertig. Der Vorteil: Es ist sehr Ressourcen schonend (auf einem Raspi ist das einfach gut). IOBroker ist wohl besser ausgebaut, aber ein dermaßenes Dickschiff von Software - und dauernd muss was kompiliert werden -, was das das ganze System zeitweilig runterzieht.

  • PS: Domoticz ist, finde ich, fürchterlich dokumentiert und das so genannte Manual ist ein Witz und maximal halb fertig. Der Vorteil: Es ist sehr Ressourcen schonend (auf einem Raspi ist das einfach gut). IOBroker ist wohl besser ausgebaut, aber ein dermaßenes Dickschiff von Software - und dauernd muss was kompiliert werden -, was das das ganze System zeitweilig runterzieht.

    Einen Vergleich zu IOBroker hab ich noch keinen, bezüglich Domo kann ich dir aber voll zustimmen, die Doku ist ein Beibackzettel und keine wirkliche Hilfe.

    Sonst finde ich Domo nicht schlecht... natürlich hätte man einige Sachen schon etwas (wie soll ich schreiben?) logischer und nachvollziehbarer machen können. Domo sieht irgendwie noch sehr unfertig aus. als ob sich manche Sachen noch in der Beta-Phase befinden würden :)

    Aber im großen und Ganzen funktioniert Domo ganz gut bei mir unter Windows 10.

    Das mit den Skripts ist ja keine schlechte Idee, wenn es dafür eine vernünftige Übersicht geben würde :)

    Will aber nicht meckern, für mich denke ich mal reicht Domo und wie es aussieht läuft es verlässlich und dies ist die Hauptsache.

    vG und auch euch einen guten Rutsch ins Neue Jahr

    Manfred

  • Manfred

    Sonst finde ich Domo nicht schlecht... natürlich hätte man einige Sachen schon etwas (wie soll ich schreiben?) logischer und nachvollziehbarer machen können. Domo sieht irgendwie noch sehr unfertig aus. als ob sich manche Sachen noch in der Beta-Phase befinden würden

    Vermutlich wird laufend etwas angebaut und die Dokumentation leidet darunter. Der Scripting-Bereich (Ereignisse) ist auch merkwürdig aufgebaut: Die Blockly-Scripte werden in der internen Datenbank versteckt, Lua-, Python und die anderen Skripte werden "außerhalb" von Domoticz auf der Betriebssystemebene bzw. in anderen Interpreterumgebungen ausgeführt. Dann kann ich doch gleich in Python arbeiten. Das Wiki weist auf ein paar Probleme hin, z. B. das lange Schleifendurchläufe oder sleep()-Anweisungen Domoticz selbst ausbremsen können. Na schaun mer mal, wie es sich weiterentwickelt.

    • Offizieller Beitrag

    PS: Domoticz ist, finde ich, fürchterlich dokumentiert und das so genannte Manual ist ein Witz und maximal halb fertig. Der Vorteil: Es ist sehr Ressourcen schonend (auf einem Raspi ist das einfach gut). IOBroker ist wohl besser ausgebaut, aber ein dermaßenes Dickschiff von Software - und dauernd muss was kompiliert werden -, was das das ganze System zeitweilig runterzieht.

    iOBroker was muss man denn da kompilern? Nichts absulut gar nichts. Und auf dem PI 3 laufen neben dem iOBroker noch ganz bequem Plex oder ein vergleichbarer Musikserver und damit ist der Pi 3 gerade mal zu 40% ausgelastet. Wärend man wenn man Domoticz mag am Anfang ja Ressourcen schonend, sein. Aber sobald komplexere Java oder Blockly Scripte dazu kommen ist es auch aus mit Ressourcen schonend :) Nur mal so zur Info.

    Gruß

    Norbert

  • Nobbi ,

    ja ich war auch überrascht von den "Nebenwirkungen" bei IOBroker. Vielleicht ist dies eine Erklärung: Ich habe kein Image genommen sondern klassisch erforderliche Pakete und Abhängigkeiten nach dieser Anleitung auf einem Raspberry Pi 2 (single core!) installiert.

    Leider habe ich IOBroker schon wieder komplett deinstalliert, sodass ich das Verhalten, von dem ich spreche, nur grob aus dem Kopf rekonstruieren kann: Nachdem der IOBroker-Webserver im Grundsatz läuft, muss man ja einige Grundkonfigurationen vornehmen. Hießen die Adapter? Ich erinnere mich, der MQTT-Client war auch dabei. Da stellte ich fest, dass nach Aktivieren eines solchen Dienstes/Schnittstelle/Virtuellen_Gerätes dieses nicht in der Übersicht erschien. Hhm, was falsch gemacht? Ein OK oder einen Hinweis übersehen? Also nochmal. Wieder nichts.

    Gut, mache ich erst etwas anderes, z. B. eine Frage aus diesem Forum beantworten. Nach 10 Minuten schauen ich mal wieder bei IOBroker vorbei - und siehe da, nun ist der MQTT-Client da. Was passiert da eigentlich? OK - einen anderen Apapter auswählen, ein Terminal anschmeißen und mir die Prozesse (htop) anschauen. Oha: node.js und gcc-* erzeugen eine CPU-Last von 98 bis 100% und rödeln mehrere Minuten rum, bis der Adapter gebaut ist. Das geht auf einem RPi 3 Prozessor bedingt natürlich schneller - im Idealfall um den Faktor 4. Wenn der Adapter dann vorhanden ist, liegt die Systemlast auch mit IOBroker im einstelligen Prozentbereich.

    Das meinte ich mit "dauernd muss .. kompiliert werden". OK - das "dauernd" hätte ich mir stecken können, diese Arbeiten sind wohl überwiegend in der Einrichtungsphase anfallend, aber mein Hals war auch noch etwas dick, dass ich nicht mal eben klickediklick ein Alternativsystem zum Ausprobieren zusammenstöpseln konnte.

    Aber sobald komplexere Java oder Blockly Scripte dazu kommen ist es auch aus mit Ressourcen schonend Nur mal so zur Info.

    Das kann schon sein. Deswegen ist ja das MQTT-Protokoll so interessant - minimaler Overhead, ein paar Bytes übermitteln eine Menge an Informationen. Oder Terminal-Befehle: der Interpreter läuft sowieso schon im Betriebssystem. Deswegen schaue ich gerne nach schlankeren Lösungen :)

    In diesem Sinne

    wünsche ich schon einmal ein frohes, friedliches und erfolgreiches Jahr 2018

    Gruß

    Jörg

  • Beliar_666

    Ich habe zwar keinen RF, würde aber mal ein paar Fragen nach der Konfiguration stellen. Ohne diese Konfiguration kann Domoticz nämlich nichts über den Zustand erfahren. Domoticz kommuniziert mit einem MQTT-Broker. Dieser wiederum erhält vom Sonoff Signale und überträgt welche an den Sonoff. Sag mal bitte was zu folgenden Fragen:

    • Läuft ein MQTT-Broker in deinem Netz?
    • Ist bei deinem Sonoff die Nutzung des MQTT-Protokolls aktiviert?
    • Ist die IP-Nummer deines MQTT-Brokers im MQTT-Konfigurationsmenü der Weboberfläche eingetragen?
    • Falls du den Zugang zum MQTT-Broker mit Nutzernamen und Passwort beschränkt hast: Sind diese im MQTT-Konfigurationsmenü des Sonoff eingetragen?

    Gruß

    Jörg

  • JoergZ

    Ja,

    ja,

    ja,

    ja.

    Das Problem ist aber, das man bei der RF Bridge keine IDX eingeben kan für die Schalter. Lediglich für Sensoren, die man anlöten könnte.

    Beim Sonoff T1 Dualswitch geht es einwandfrei. Der wird aber eben auch über Mqtt angesprochen. Der RF lässt sich ja nur per HTMLaufruf schalten, da man keine IDX eintragen kann.