Beiträge von JoergZ

    Ich kann zwar kein Java nur ein bisschen Python, bin aber sicher, dass es unter Java ähnlich geht:

    Schicke das Statement http://IP.../cm?cmnd=status an das Gerät. Die Antwort ist ein JSON-String in der Form

    Code
    {"Status":{"Module":1,"DeviceName":"Schalter","FriendlyName":["Schalter"],"Topic":"Schalter","ButtonTopic":"0","Power":0,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0}}

    Mit einem entsprechende JSON Parser fischt du dir den Wert von Status['Power'] raus und weist in einer Variablen zu. In der steht entweder 0 (aus) oder 1 (an). Damit kannst du weiter arbeiten.

    Wenn auf dem Raspi 2 nur mosquitto laufen soll, geht das. Wenn du aber dort IOBroker oder Homesassistant oder Domoticz laufen lassen willst, solltest du mindesten einen Raspi 3 (A oder B) bzw. einen Raspi 4 mit 2 GB Arbeitsspeicher nehmen. Dann bist du auf der sicheren Seite.

    Da Helfinger und premo da schon sehr gute Hinweise und Informationen geliefert haben (und beide auf jeden Fall mehr Kenne von E-Technik haben als ich), kann ich kaum noch was beisteuern außer einem neuen Denkanstoß: Das größte Problem scheinen mir die Distanzen zu sein wegen a) WLAN-Reichweiten und b) Kabellängen zu den Sensoren.

    Ausgehend vom gefundenen Bauvorschlag von Helfinger in Verbindung mit Tasmota (vielleicht kann's der Shelly von Haus aus auch?), kann der Sonoff am Sensor so konfiguriert werden, dass er per Rule und Websend an die anderen Sonoffs ein On schickt, wenn der Sensor getriggert wird wird. Und so könnten dann alle Scheinwerfer geschaltet werden. (Oder hängen die sowieso alle zusammen an einer Leitung?) Aber dafür braucht man eben WLAN überall.


    Das wäre aber m.E. keine große Herausforderung: Man braucht nur einen Repeater und zwar links unten außerhalb des Hauses. Der bedient locker den gesamten Innenhof, denn dort stehen nach der Skizze keine Bauten und hoffentlich auch nicht ständig 4 Meter hohe Containerlaster, oder? Und der Repeater an der Ecke wird ziemlich sicher noch ohne Problem das WLAN-Signal vom Hausinneren abgreifen können. Also hast du Wlan im gesamten Innenhof. Auf freier Strecke reicht das Signal locker 30 m weit.


    Bleibt das Thema Sensoren: Unter Tasmota geht es, mehrere Sensoren an einen GPIO zu hängen. Tasmota kann die einzelnen Geräte identifizieren und die Trigger auswerten. ABER: Die langen Leitungen wirken wie Antennen. Und da die Sensorsignale mit sehr geringen Spannungen und vor allem sehr geringen Spannungsdifferenzen als Trigger arbeiten, kann jeder EMP - und der kann schon von einer kräftigen Kreissäge beim Einschalten ausgehen - dazu führen, dass die Software meint, dass am Sensor was passiert ist. Ok, dann geht vielleicht am hellichten Tag mal das Licht an, döfer ist es natürlich, wenn es nachts auf Grund eines Störsignals ausgeht ;-) .... Ich mein ja nur. Mögliche Lösungen: geschirmte Leitungen


    Weiter mögliche Lösungen:

    Batterie betriebene Sensoren mit Zigbee; Folge: irgendwo brauchst du ein Gateway, was Zigbbe-Funk auf WLAN (und HTTP/MQTT) umsetzt. Das könnte ein Raspberry Pi sein, der dann alles andere mit der entsprechenden Software dann managed.

    Und dann gibt's da noch das recht junge Thema LoRaWAN. Das führt hier jetzt doch zu weit. Schönen Sonntag noch...

    Du siehst, niemand reißt sich darum, eine (sichere und zuverlässige) Antwort zu geben. Das mag damit zusammenhängen, dass der RF3 nicht allzu sehr verbreitet ist. Auch ich kann nicht sehr viel weiterhelfen, weil ich das Gerät nicht kenne. Aber ich lebe auf dem Land und kann einen Teil der Aufgabenstellung nachvollziehen. Zunächst einmal noch ein paar Fragen und Denkanstöße:

    • Warum der RF3? (Die Aufgabe ließe sich in Verbindung mit Tasmota-Firmware auch mit einem Basic oder einem S20 erledigen.)
    • Hast du in der Strecke der Stromleitung, die zu den Lampen führt, (stabiles) WLAN zur Verfügung?
    • Brauchst du eine Wechselschaltung aus schalten per Schalter und schalten per App bzw. Hausautomation?
    • Welche Entfernungen gibt es voraussichtlich zwischen den Sensoren und dem Sonoff-Gerät?
    • Brauchst du unbedingt schalten per Funk bzw. warum brauchst du schalten per Funk?
    • Wie schätzt du deine Kenntnisse und verfügbaren Werkzeuge/Hilfsmittel zu den Themen Elektronik/Elektrik/Löten/(Skript-)Programmierung ein?
    • Hast du in diesem Forum dir schon die Beiträge angesehen, in denen es um PIR-Sensoren geht?
    • Willst du mit dem Standardsystem EWELink oder mit Tasmota arbeiten?
    • Hast du dir die Shelly-Produkte schon angesehen?


    Grundsätzlich ist es möglich, mehrere Sensoren an einem Sonoff (in Verbindung mit der Tasmota-Firmware) anzuschließen. Es geht auf jeden Fall mit Temperatursensoren. Dass es auch mit PIR geht, kann ich allerdings nur stark vermuten. Verrate uns noch ein bisschen mehr über deine Planung, dann kannst du hier vermutlich auch noch ein paar zusätzliche Informationen bekommen.

    Setoption4 hat keinen Einfluss auf topics sondern nur auf die Struktur der Rückmeldung. Dass Sensoren so etwas haben wie eine Hardware-Adresse, siehst du doch an den ID-Nummern. Du kannst die Sensoren nicht über das topic identifizieren aber übr den Inhalt des zurück gemeldeten JSON-String. Ob man mit dem IOBroker die Payload gescheit auswerten kann, weiß ich nicht sicher. Aber ich gehe davon aus. Der IOB ist ja schließlich ein ziemliches Dickschiff und hat einen MQTT-Adapter und eine Scriptsprache bzw. IDE. Du musst also den Ausdruck auswerten und. Gib mal in der Konsole status 10 ein, dann sieht man besser, wie der Ausdruck dargestellt wird, wenn die Sensorwerte direkt abgefragt werden und nicht per teleperiod gemeldet werden. Wenn du den Ausdruck hier postest, kann ich dir den direkten Zugriff auf den Wert des jeweiligen Sensord besser darstellen. Oder schau dir im Wiki mein Beitrag zu MQTT und jq an. Vielleicht wird dir dann schon klar, wie du an den Wert deines (einzelnen) Sensors kommst.

    Mir ist kein Weg bekannt, den friendlyname (einen friendlyname...) als Topic in MQTT zu verwenden.


    Also die 3 Einträge (POWER1-3) mit aussagekräftigen Namen zu bestücken.

    Den aussagekräftige Namen kannst du dem Gerät geben über das Topic, z. B. "Mehrfachschalter". Wenn das Gerät mehrere Kanäle hat, sprichst du es so an:

    Code
    mosquitto_pub -h BROKER_IP -t cmnd/Mehrfachschalter/Power1 -m '1' #oder
    mosquitto_pub -h BROKER_IP -t cmnd/Mehrfachschalter/Power2 -m '1' #etc.

    Ich bin nicht sicher in welchem Sinn von dir die Begriffe Switch, Relais und Taster, Tastsensoren und Button benutzt werden. Am besten du tust erst einmal das, was du machen möchtest, händisch und schaust in der Konsole nach, welche MQTT-Botschaften das Gerät jeweils sendet. Dann kannst du die mqtt-Topics erkennen, die benutzt werden, und diese sollte man dann entsprechend im IOBroker abgreifen können - ich benutze allerdings leinen IOB, aber es würde mich sehr wundern, wenn es nicht ginge.

    Sorry, ich kann mich da im Moment nicht wirklich hinein vertiefen. So weit ich es verstehe, benutzt du einen Java Wrapper, um mit/über mqtt zu kommunizieren. Die Änderung, die ich angesprochen habe, bezieht sich allerdings auf Tasmota und den Flash auf dem Gerät. Es soll beeinflussen, was vom Broker retained wird. Üblicherweise ist das nur das topic LWT und darin die Werte online bzw. offline. Im beschriebenen Fall sollte eben der letzte Power-Zustand aufbewahrt werden. Der Client (MqttDash) müsste dann die retained message beim Verbinden und Abrufen des Geräte-Topics +/TH10/# (als Symboldarstellung) die Power-Meldung liefern, denke ich. Ich weiß allerdings nicht genau.in welchem Topic das aufbewahrt wird: tele oder stat.

    Ich zitiere mich mal selbst. Interessant, wie unaufmerksam selbst die älteren Hasen lesen:

    Hast du auch das 2,4 GHz WLAN aktiviert mit dem alten Namen und dem alten Passwort?

    Wenn in den Geräten die alte SSID und das alte Passwort hinterlegt sind (und beides jetzt unbekannt ist) kommen die Kisten nicht ins WLAN und weder über http noch über mqtt ist Kommunikation möglich. Bleibt noch die Nummer mit dem restart als AP. Dann meldet sich das Gerät als AccessPoint mit der IP 192.168.4.1. Dann mit dem Handy/Laptop verbinden und auf die Weboberfläche gehen und alle Einstellungen vornehmen. Folgende Varianten können zum Ziel führen:

    Variante 1: 40 Sekunden Button gedrückt halten

    Variante 2: 4 mal kurz hintereinander Button drücken

    Variante 3: 5 mal kurz hintereinander Button drücjken. Dann startet der WPS-Modus. Der sollte vorher am Router - falls vorhanden - auch angeschmissen werden.

    Die letzten beiden Varianten gegen erst mit neueren Firmware-Versionen und falls der T1 einen Button hat. Ab wann genau Variante 2 und 3 gehen, weiß ich jetzt auch nicht. Aber da kann Helfinger bestimmt helfen.

    Hört sich erst mal alles gut und richtig an. Bleiben noch Kabel (auch dieses Pferd haben wir schon vor der Apotheke ko... gesehen), Lötstellen - falls du lötest, bzw (un)sichere Kontakt, wenn du nur mit nicht verlöteten Pins arbeitest. Eine Variante hatte auch schon mal zum Erfolg geführt: Baudrate auf 9600 herunterdrehen. Flashen dauert dann zwar eine halbe Ewigkeit und diese Notwendigkeit hatte ich auch nur einmal. Oder das Design ist auf der Platine geändert. Manchmal ist auch der FTDI selbst das Problem.... Wenn kein Gerät sich flashen lässt, scheint mir das noch das Wahrscheinlichste.