moin,
... damit der Ordnung Rechnung getragen wird.... ;-) (und ohne weitere Ansprache, um Fragen deswegen zu vermeiden)
Es kann sein, dass mein Anliegen schon irgendwo in den weiten des FHEM-Universums aufgetaucht ist. Ich habe auch schon diverse threads durchgelesen.... meine Augen brennen und nun denke ich, frage mal an dieser Stelle (auch wenn es leichter ist, als selbst zu lesen).
Ich plane schon länger an eine 1-wire Lösung für die Überwachung der vielen Löcher in meinem alten Haus.... allein ca.17 davon im Erdgeschoss... Fenster und Türen verschliessen diese Löcher.
Den Schließzustand der Fenster kann ich recht leicht über winzige reed-Kontakte prüfen, die ich in den Rahmen verbaue... Diese Kontakte sind bei unverriegeltem Fenster (Kipp, Dreh, oder Geschlossen aber nicht so richtig...) geöffnet. Ist das Fenster verschlossen, schliesst der Kontakt die GND-Leitung zu einem DS2401 (ggf. auch DS24011) und dieser wird dann auf dem 1-Wire-Bus sichtbar... sichtbar = alles gut, Fenster verriegelt.
Über die Tücken der 1-Wire-Leitungsführung (Länge, Topologie usw.) bin ich halbwegs informiert, trotzdem mal der konkrete Aufbau:
- Buslänge ca. 25m
- 17 - 20 Slaves (alles reine ID's)
- alle Slaves über GND geschaltet (an/aus)
- quasi keine Stichleitungen, da die DS2401/DS2411 in kleinen Gehäusen direkt am Hauptstrang angebracht werden
Geplant war es, den Bus alle 5-10 sec. abzufragen (ggf. auch kürzere Intervalle) --> mittlerweile sind es 30 sec.
(Meine Frage an Locutus (Respekt!!) oder wer das auch weiss : Funktioniert die von Locutus entwickelte WLAN-Lösung mit solch einem Aufbau? (wär ja klasse)) --> hat sich erledigt.
Ich wollte mein Projekt mit einem ESP32 realisieren, der den Bus zyklisch abfragt und nur bei Änderungen der jeweiligen Schliess-Zustände ein MQTT-Telegram an FHEM schickt. Idee dahinter war die deep-sleep-Funktion des ESP32 in Verbindung mit Batteriebetrieb.... ( aber die Locutus Lösung ist da pragmatischer ;-), dachte ich...)
die Wahl von Schließern hatte den Grund, dass der Ausfall eines Meldekreises die gleiche Bedeutung haben soll wie ein nicht geschlossenes Fenster. Man ist dann gezwungen, die Ursache zu ergründen... offen, unverriegelt oder defekt.
Zu meiner Fenster/Türen Überwachung mittels reed-Schaltern und 1-wire ID's:
Die Software auf dem esp32 ist jetzt im Prototypenstadium und läuft brav. Zwar sollen noch ein paar Komfortfunktionen hinzukommen (WEB-Interface, erkennen der Sensortypen "ID" oder "Temperatursensor"), aber für das Rel.1.0 reicht der aktuelle Zustand aus.
Die 1-wire ID's werden vom ESP ausgelesen und via WLAN über MQTT an FHEM auf meinem RASPI übertragen. Jede gefunden ID soll einem Fenster zugeordnet werden und bei jeder Abfrage gefunden werden, wenn das jeweilige Fenster geschlossen ist. Diese Art der Abfrage hat den Vorteil, dass auch ein defekter/abgeklemmter Kontakt erkannt wird (Aufmerksamkeit wg. "offen").
Jetzt stehe ich vor der Frage, wie ich mittels FHEM erkennen kann, dass eine zuvor erfasste ID nicht übermittelt wurde.... Zunächst dachte ich an "Last Will" von MQTT... aber der zieht nur, wenn der ESP die Grätsche macht ?
Gäbe es noch eine andere Lösung.... z.B. die readings (in diesem Fall die 1-wire ID's oder irgend ein anderer Wert als MQTT-topic) zyklisch zu toggeln (z.B. nach 30sec. alle readings auf "wartend" zu setzen und dann beim Eintreffen der aktuellen readings die Lücken zu erkennen...? Ich habe mir auch überlegt, ein topic zu erzeugen, das den beginn einer ID-Lesung/Übertragung markiert und dann die vorherigen readings zurücksetzt....)... als payload könnte ich z.b. eine "1" oder "geschlossen" senden....
...hat jemand eine Idee wie man sowas in FHEM umsetzen kann?
In den readings stehen die einmal gefundenen ID#s (MQTT-topics), was ja einen Teil der Anforderungen erfüllt. Auch die aktuelle Payload pro topic ist vorhanden, eine "1" als Status "geschlossen".
Zusätzlich lasse ich vor jeder MQTT-Übertragung eine "99" als festen Wert übertragen (hatte gehofft, einem timer damit einen initialen Startzeitpunkt zu geben, der z.B. nach 29sec. eine Funktion triggert alle Status "1" auf "2" (="wartend") und alle Status "2" auf "0" ("offen") zu setzen. Die nächste Lesung der ID#s würde dann alle gefundenen ID#s wieder auf "1" setzen und die mit "0" ggf. auf "0" belassen... usw.
Einiges habe ich schon erfolglos probiert und bin soweit frustriert, dass ich jetzt eine Lösung auf dem esp zu bauen möchte ;-) ...
Möglicherweise hat jemand eine zielführende Idee, wie man sowas mit FHEM knacken kann, die Dokumentation/das WiKi hat mir zwar schon sehr weit geholfen, aber nur bis hier...
der fpg
Man kann mit MQTT alles mögliche anstellen, siehe meinen "workshop" im MQTT-Bereich.
Aber bevor wir in die (Un-) Tiefen der MQTT-Welt abtauchen, reibe ich mir aus mehreren Gründen verwundert die müden Augen:
- Erst akribisch alles auf Kabel legen, und dann ab damit ins WLAN?!? Oder soll der ESP32 wegen der LAN-Fähigkeiten her?
- pah würde vermutlich darauf hinweisen, dass man eine einfache I2C- oder USB-Schnittstelle nehmen kann und "gut ist"; will sagen, dann kann man das vermutlich direkt mit den OWX-Modulen abbilden und braucht einfach einen Bus bis zum Server. Das ist dann die ausfallsicherste Variante, nach dem Motto wenn schon Kabel, dann Kabel...
- dann gab's irgendwo von ihm auch noch eine Variante mit sofortiger Alarmierung, müßte man halt freundlich nachfragen?
(Das Rauslöschen des Beitrags vor https://forum.fhem.de/index.php/topic,18996.msg1109007.html#msg1109007 ist auch irritierend. Wenn du allg. mit solchen seltsamen Aktionen Verwirrung stiftest, wird kaum einer lange Lust haben, deine Ideen zu supporten.)
Grüße, Beta-User
moin,
...nun, auf Wunsch eines users habe ich den Beitrag gelöscht und in einen neuen thread verfrachtet. Da mir der Zusammenhang mit den vorherigen posts wichtig und für's Verständnis hilfreich erschien, sind diese hierher gewandert (Doppelposts sind ja auch so ein blödes Problem...).
Zum eigentlichen Thema, also dem Inhalt meiner Frage: es gibt Gründe für den wlan-Einsatz, der ist aber nicht das Problem, das oben geschildert wurde. Es ging um eine FHEM-Lösung, die auch bei reiner Kabelinfrastruktur (LAN, Telephon...) hilfreich wäre, wenn man z.B. MQTT verwendet. Aber auch Funk-Lösungen machen Sinn... grosse Teile des IoT basieren darauf.
Wenn ich die einzelnen 1-wire ID#s direkt anschlösse, gäbe es keine derartige Fragestellung, soweit klar und hier auch länger im Einsatz.... nun brauche ich aber eine Lösung mit ESP, WLAN und MQTT... und komme nicht weiter... daher die Frage ins Forum. Die Möglichkeiten von MQTT sind vielfältig, ja, weiss ich... aber mit MQTT unter FHEM habe ich die oben geschilderten Probleme. Es kann ja sein, dass das nicht mit FHEM lösbar ist.... dann baue ich mir halt ein Programm für den ESP... was möglicherweise einfacher ist.... und die Frage wäre für mich dann nicht mehr relevant.
(Für MQTT-SN gäbe es wahrscheinlich eine Lösung, aber man bräuchte dann ein passendes Modul auf ESP-Seite)
der fpg
Nun ja, "entfernen" hätte man m.E. auch als "Inhalt in neuen Thread kopieren" und "alten Thread mit kurzem Dank für den freundlichen Hinweis dahingehend ändern, dass unter Hinweis auf das anders gelagerte Thema auf den neuen Thread verlinkt wird" verstehen können. So steht pah's Rückmeldung etwas seltsam bezugslos im Raum.
Aber ja, er hat es so vorgeschlagen, und es ist sein Thread...
Da heißte es einleitend:
Zitat von: Prof. Dr. Peter Henning am 18 Januar 2014, 21:00:45
[...] 1-Wire Interface [...], mit dem ein 1-Wire-Bus direkt ans Ethernet angekoppelt wird. [...]
Das Teil stellt zwei UART-Ports zur Verfügung, an die man je einen DS2480 direkt anschließen kann. [...]
Das OWX-Modul als Backend greift auf diesen seriellen Port zu und funktioniert wie gewohnt. [...]
Es wird also "schlicht" der 1wire-Bus an FHEM durchgereicht.
Du scheinst jetzt was ganz anderes machen zu wollen, nämlich die 1wire-Bausteine via MCU (ESP32) direkt auszulesen und dann das Ergebnis (via MQTT) an FHEM zu übermitteln.
Mal unterstellt, du hast eine lib, mit der man die DS2401/DS24011 auslesen kann (als ich das letzte Mal mit 1wire@arduino rumgespielt habe, gab's nur libs für DS18x20, soweit ich mich entsinne):
Also, falls du die Daten auf der MCU hast: Das geht alles mit FHEM+MQTT, aber wie immer in der MQTT-Welt muss halt mal jemand entscheiden, wie es im Detail ablaufen soll. Daher habe ich gestern auch noch einen Teil in den MQTT-Workshop mit aufgenommen, der Hinweise auf eine mögliche Vorgehensweise enthält, wenn man firmware und Auswertung auf FHEM-Seite eng aufeinander abstimmen will und dabei möglichst overhead auf der FHEM-Seite vermeidet: https://forum.fhem.de/index.php/topic,116162.msg1109103.html#msg1109103
Kurz: Verpacke die Auswertungsergebnisse nach dem Lesen des Bus in einen (einzigen) JSON und übermittle alles auf einmal an FHEM. Dort nimmst du das ganze entgegen, prüfst, ob es vollständig ist und generierst dann die notwendigen/gewünschten Events.
Wenn du in der "Klartext-Variante" (pro Sensor einen Topic) bleibst, hast du viel mehr Events und musst an jeden Sensor noch eine Nachbearbeitung (irgendeinen Eventhandler) hängen, der Timer überwacht, ... Auch möglich, aber m.E. umständlich.
Einfacher wäre es vermutlich, schlicht den 1wire-Bus durchzureichen und pah um Rat zu fragen, wie man das mit den OWX-Modulen löst.
just my2ct, genauso wie ich eben nicht der Ansicht bin, dass WLAN bereits deswegen "gut" für IoT-Zeug ist, nur weil es irgendjemand in Massen an eine Menge Leute vertickt... (no comment required or expected)
moin,
...momentan sieht es halt so aus:
Aliasse der ID#s (eine mal im "original")
Eine 99 als möglicher Trigger
Text zur Anmeldekontrolle
der fpg
Na ja, scheint ja alles da zu sein, auch wenn ein list bzw. ein RAW-list einfacher zu lesen sind als screenshots...
Zitat
Zusätzlich lasse ich vor jeder MQTT-Übertragung eine "99" als festen Wert übertragen (hatte gehofft, einem timer damit einen initialen Startzeitpunkt zu geben, der z.B. nach 29sec. eine Funktion triggert alle Status "1" auf "2" (="wartend") und alle Status "2" auf "0" ("offen") zu setzen. Die nächste Lesung der ID#s würde dann alle gefundenen ID#s wieder auf "1" setzen und die mit "0" ggf. auf "0" belassen... usw.
Ich halte die ganze Konstruktion nicht für ideal, aber so wie es jetzt ist, könnten die Stichworte "readingsWatcher" (kenne ich nicht im Detail) und Benni's Code für Globale, flexible Fenster-/Tür-Offen-Meldungen (https://forum.fhem.de/index.php/topic,36504.0.html) taugliche Ansatzpunkte sein.