DS2408 mit hoher Frequenz mittels Alarming auslesen

[Oliver Vallant]

Liebe Freunde des FHEM/1-wire,

ich habe derzeit mein gesamtes Haus mittels 1-wire Elemente automatisiert und evaluiere gerade, ob ich meine derzeit in Java implementierte Ablaufsteuerung ausscheide und in FHEM nachbaue. Hierzu muss ich ein Detail klären, welches quasi ein Knock-Out Kriterium wäre:

In meinem ca. 70m langem BUS (STP-Kabel) betreibe ich etwa 80 Stk. DS2408 teils als Relais-Schalter im Schaltschrank, teils als Zimmerallzwecksensor: 6-fach Sensor-Taster mit 2 LED-Statuslichter. Von diese 50 Stk. DS2408 kann ich nicht den tatsächlichen Sensed-Input der 6 Kanäle auslesen, denn das dauert etwa: 250ms * 50 = 4sec
Deshalb hat der DS2408 ein Alarming-Bit welches auf high geht, sobald ein Eingang auf high geht, also ein Taster im Zimmer gedrückt wurde. Das scannen des Alarming-Bits aller DS2408 "kostet" etwa 15ms, sodass ich jeden DS2408 in einer Sekunde überwacht habe. Ist ein Alarming-Bit high ließt die Software alle 6 Kanäle aus und setzt das Alarming-Bit auf low zurück. Hierdurch wird das Einschalten des Lichtes in einem Raum relativ ohne Zeitverzögerung ermöglicht.

Leider habe ich in der Beschreibung des OWDevice als Abfrageintervall für den DS2408 lediglich Sekunden (min 1) angeben, dh. bei 50Stk. DS2408 würde ein Durchlauf bis zu 50sek dauern. Gibt es hier eine Möglichkeit das Element schneller zuvor auf Basis des Alarmings vorauszuwerten?

Vielen Dank!

[Prof. Dr. Peter Henning]

Das hat nichts mit dem OWDevice zu tun. Vielmehr rmüsste das die darunterliegenden OWFS-Instanz machen.

LG

pah

[Oliver Vallant]

Danke pah für dein Feedback.
Dann präzisiere ich ... gibt es eine schnelle Variante ggf. über das Alarming-Bit des DS2408 über das OWFS mittels OWDevice auf Tastendrücke Aktoren ausführen zu können?
Oder anders, wenn OWFS dies nicht implementiert haben sollte, kann man in eventu ohne das OWFS direkt die Java-APIs von Dallas-Semiconductors als externe Library in FHEM einbinden?

[Oliver Vallant]

Habe ein Posting aus 2014 von Norbert bzl. Notification  gefunden:
-----------
Antw:1wire mit notify
Zitat von: otto am 09 August 2014, 15:53:57

    Hallo hab jetzt 10 DS1820 Wie kann ich jetzt die Alarme alle auf einmal Als E-Mail weitersenden?

Beantwortet zwar nicht direkt Deine Frage, aber Ich schreib einfach mal das, was tatsächlich implementiert ist:

In OWX_ASYNC kann man ein notify auf das 'alarm'-reading des OWTHERM-devices setzen. Das notify wird nur aufgerufen, wenn sich der alarm-Zustand tatsächlich ändert. Eine regelmäßige Alarm-search wird im nach der im Attribut 'interval' konfigurierten Zahl an Sekunden durchgeführt. Zusätzlich findet man alle aktuell als alarmed geführten Devices im Internal 'ALARMDEVS'.

In OWX ist das nicht implementiert. Da muss man eine Alarm-search mit 'get <owx> alarms' triggern. Anschließend findet man alle Alarmed-devices (so wie bei OWX_ASYNC) im Internal 'ALARMDEVS'. OWX beschreibt kein alarm-reading in den Devices, daher kann man darauf auch kein notify setzen.

Gruß,
Norbert
-----------

Es scheint, dass das OWFS im Falle des  DS1820 als Alarming des Elementes abgreift und an OWServer und dann an OWDevice zur weiteren Auswertung weiterreicht. Oder interpretiere ich das obige falsch? Weis jemand, ob dies auch beim DS2408 analog zum DS1820oä durch die OWFS-Instanz durchgereicht wird, wie Peter Henning anmerkte? Und wenn ja, kann man dann mittels Intervall 1sec die Liste ALARMDEVS dann durchgehen und auswerten, sowie die tatsächlichen Inputwerte des DS2408 auslesen?

Bitte entschuldigt mein Kaffeesatzlesen, aber es müsste doch ein weit verbreitetes Problem darstellen, wenn alle DS2408 eines BUS nur mit minimal 1sec abfragbar wären? Wenn da ein Taster (input high eines Kanals) von der Person, welche zB. das Licht in einem Raum einschalten will, nicht hinreichend lange gedrückt würde, zumindest bis der scan am BUS am DS2408-Element vorbeikommt, versäumt man den Tastendruck vollständig. Von einer Rollo-Steuerung, wo mittels auf/ab-Taster die Schrägstellung der Lamellen verändert werden soll, wo eine halbe Sekunde bereits (zu)viel ist, ganz zu schweigen.

Wie habt ihr das gelöst?

[Oliver Vallant]

Liebe Kollegen, liebe Freunde des 1-wire-Bus,

ich komme leider mit dem zeitnahen Abfragen der DS2408 nicht weiter:

a) Das Lesen mehrerer DS2408 zB. mittels interval=1 auf Eingangszustand (sensed.0 bis sensed.7) oder Änderungen (latched.0 bis latched.7) hört sich bereits bei 3 Devices auf (wären 24 Input-Kanäle), da dann zB. mein Raspberry PI3 zur Abarbeitung des Front-Ends bereits keine CPU-Zeit mehr hat.
b) Hierfür hat der Hersteller das Alarming eingeführt, sodass bei geeigneter Maskierung der Devices (zB. set_alarm="133333333" dh. bei einer beliebigen Eingangsänderung) die Devices, welches eine Eingangsänderung erleben durften auf ein sehr sehr rasches Conditional-Search des Busmasters antworten. Das heißt man scanned mit hoher Frequenz (1-3 Hz) mittels Conditional-Search und bekommt nur mehr die Devices retour, bei welchen zB. ein Taster gedrückt wurde, liest dann nur mehr bei diesem Device die latch-States aus und kann dann rasch eine Aktion anstoßen. Indem man den latch-State wieder auf 0 setzt, resetet man den Alarm des Devices.
c) Hierfür hat OWFS das Verzeichnis http://server:2121/uncached/alarm bereitgestellt. In diesem sind alle (b) Devices aufgelistet.

In Element OWX scheint dies mittels Liste "alarmdevs" realisiert gewesen zu sein. Aber wenn ich das richtig verstanden habe wurden die OWX-Elemente durch OWServer/OWDevice ersetzt. Im OWServer gibt es leider kein Internal oder Attribut "alarm" oÄ.,  wenngleich es hier auf dieser Ebene angesiedelt sein müsste.
Es scheint aber grundsätzlich vorgesehen zu sein, da OWDevice sehrwohl das alarm-Reading auslesen kann und das "Muster" für die Conditional-Search in Form des set_alarm einstellen lässt. Das alarm-Reading des OWDevices abzufragen bringt nur nichts, da eben das Interval des OWDevices auf <=1 gesetzt werden müsste und wieder jedes DS2408 am Bus abgefragt werden müsste.

Kann man sonst irgendwie auf /uncached/alarm des OWFS darunter zugreifen und danach nur mehr die OWDevices lesen, die dort enthalten sind? Ein externer HTTP-Aufruf (system "wget  http://server:2121/uncached/alarm" an den OWHTTP samt parsen des Ergebnisses dauert jedenfalls viel zu lange.

[Prof. Dr. Peter Henning]

Aber wenn ich das richtig verstanden habe wurden die OWX-Elemente durch OWServer/OWDevice ersetzt

Sicher nicht.

LG

pah

[Oliver Vallant]

Kann ich OWX parallel zu OWServer an einem BUS-Master einsetzen um an alarmdevs zu gelangen? Oder OWServer/OWDevices umbauen zu OWX/OWSwitch?

[Oliver Vallant]

Da OWServer die alarmdevs nicht herausführt habe ich es mit OWX(_ASYNC) und OWSWITCH versucht.

Testaufbau: Habe einen DS2408 mit 8 Inputkanälen an einem 1-wire Busmaster DS2480 an /dev/ttyUSB0.
Dafür habe ich im fhem ein OWX_ASYNC, ein OWSWITCH und je ein Notify auf das "alarms" des OWX_ASYNC und eines auf das "alarm" des OWSWITCH erstellt:

Code Auswählen Erweitern


define iBUS OWX_ASYNC /dev/ttyUSB0
attr iBUS buspower real
attr iBUS dokick 0
attr Sensor room OWX

define Sensor OWSWITCH DS2408 433109000000
attr Sensor IODev iBUS
attr Sensor model DS2408
attr Sensor room OWX

define iBUSalarm notify iBUS:alarms { Log 3, "iBUS alarmiert" }
attr iBUSalarm room OWX

define Sensoralarm notify Sensor:alarm { Log 3, "Sensor alarmiert" }
attr Sensoralarm room OWX


Obiges setting liest als OWX noch richtig aus bei eingestelltem interval zB. 1 des OWSWITCH. OWX_ASYNC liefert keine neuen Input-Stati, egal welches interval ich am OWX_async oder OWSWITCH setzte. ALARMED des OWX_ASYNC ist immer 0 und "alarm" des OWSWITCH ist immer 1. "alarms" des OWX_ASYNC zeigt richtiger Weise das alarmierte OWSWITCH. Jetzt stehe ich an. Der Aufbau selbst funktioniert, habe ich mit OWFS manuell via owhttp, sowie OWServer und OWDevice ausprobiert.

Eigentlich müsste folgendes passieren:
1) am OWSWITCH müsste während init das Flag set_alarm="133333333" einmalig gesetzt werden. Das schaltet das Gerät überhaupt erst für alle latch.X (für X=0 bis 7) die Änderungen auf die Conditional Search.
2) danach müssten in init alle latch.X des Gerätes auf 0 gesetzt werden, damit das Alarming des gesamten Gerätes zurückgesetzt wird.
3) wenn jetzt ein Input sich ändert (1>0 oder 0>1) dann wird das entsprechende latch für diesen Input auf 1 gesetzt und es erscheint in der Conditional Search. Dazu müsste aber das OWX_ASYNC einmal oder besser mehrmals pro Sekunde die an sich sehr schnelle Conditional Search des 1-wire durchführen.
4) wenn jetzt ein Notify auf das "alarms" des OWX_ASYNC gesetzt wird, erscheint dort das alamierte Gerät und könnte ein get auf das Gerät selbst durchführen und den Input (sensed.X) auslesen.

Passiert das alles intern in OWX_ASYNC und OWSWITCH oder muss ich das in Perl nachbauen?
dh. wie kann ist die latch-States und damit den alarm eines Gerätes zurücksetzen? Bei OWDevice habe ich latch.(0-7) oder latch.ALL setzten können.
Wie kann ich die Conditional Search manuell, oder sonst über OWX_ASYNC auslösen, bzw. wird diese bei interval=1 dann sekündlich durchgeführt?
Was mache ich im Setting mit OWX_ASYNC ober falsch, dass überhaupt keine Werte mehr gelesen werden?

Jedes Stichwort ist willkommen, auch ein "geht gar nicht" hilft mir weiter,
Oliver

[Prof. Dr. Peter Henning]

1. OWX_ASYNC wird nach meinem Kenntnisstand nicht weiter entwickelt. Unabhängig davon ist die Idee des "mehrmals pro Sekunde Conditional Search" damit vermutlich nicht umsetzbar.

2. Einen Ausbau von OWSWITCH zu einer erweiterten Initialisierung habe ich nicht auf der Agenda, und werde ihn auch auf absehbare Zeit nicht darauf setzen.

3. Für den Anwendungszweck, bestimmte 1-Wire Buszustände mehrmals pro Sekunde abzufragen, kann man FHEM auf keinen Fall empfehlen - dafür ist es nicht gedacht. Der einzig sinnvolle Weg besteht in diesem Fall darin, den 1-Wire Bus an eine dezidierte Hardware anzuschließen, sagen wir einen Arduino. Der macht die schnellen Busabfragen und alarmiert FHEM nur, wenn er einen entsprechenden Zustand erkannt hat.

LG

pah

P.S.: Der Plural von Status ist nicht Stati...

[Oliver Vallant]

Hallo pah,

vielen Dank für deine Antwort - hilft mir sehr weiter.
ad 1) Deine Antwort vom 17.3. mit "Sicher nicht" bezog sich demnach auf OWX und nicht auf OWX_ASYNC.
ad 2) alles klar
ad 3) Aus meiner Sicht ist das kein Hardware-Thema, sondern einzig eine Frage des Timings, ob mit fhem in Perl zB. zwei Conditional Searches je Sekunde machbar sind - neben dem restlichen Tasks. Die Abarbeitung des Events selbst, nach Erkennung des einen alarmierten Geräts, kann dann durchaus als Notify länger (1sec) dauern. Ich denke für eine Hausautomatisierung  ist 1-2sec delay vom drücken eines Tasters bis sich das Licht einschaltet zweifelsohne akzeptabel, insbesondere da in einem Einfamilienhaus selten in einer Sekunde mehr als ein Taster gedrückt wird.
Mich würde interessieren wie du die Lichtschalter und Rollotaster oÄ. realisiert hast. Bei einigen Räumen und einigen Fenstern kommen schon mal 50 Tastpunkte (dh. min. 7sec, 7x8ports bei interval=1) zusammen. Auch bei zB. 20Stk. Homematic Funktaster muss es mehrere Sekunden dauern. Da kommt dann auch der sog. WAF (Women Acceptance Factor) zu tragen .

Vielen Dank nochmals!
LG Oliver

PS: Richtig, aber Stati klingt halt bedeutend besser als "die Status".

[Prof. Dr. Peter Henning]

Ich steuere Licht o.ä. nicht über 1-Wire, und die Funktelegramme von Homematic sin dso kurz, dass eine gegenseitige Blockade nicht auftritt. Nochzumal ich 2 Transceiver habe.

Nein, das ist keine Frage von Perl. Sondern eine Frage der Main-Loop von FHEM, die durch das jeweilige Antriggern der Bussuche lahmgelegt wird.

Über den WAF habe ich in den "Smart Home Hacks" ein Kapitel geschrieben - und trage derzeit deshalb einen Fight mit dem Verlag aus...

LG

pah

[UweH]

Über den WAF habe ich in den "Smart Home Hacks" ein Kapitel geschrieben - und trage derzeit deshalb einen Fight mit dem Verlag aus...

Huch...da steht doch nun wirklich nichts feministisch verfängliches...im Gegenteil. Ist selbst das noch zu viel?  Da ist von Rücksichtnahme die Rede...

Gruß
Uwe

[Prof. Dr. Peter Henning]

Ernsthaft.

Zwei Figuren, die nachweisbar das Buch nicht gelesen haben, haben jeweils eine Beschwerde-Mail geschrieben, und zwar innerhalb derselben Stunde nach Mitternacht. Der Verlag drängt, diesen Abschnitt für die 2. Auflage "neutraler" zu verfassen - und ich lehne das ab.

Noch ist nicht klar, ob ich mir einen neuen Verlag suchen muss.

LG

pah

[Oliver Vallant]

Lieber pah, der WAF ist doch keine Erfindung des Menschen, stattdessen ist er ein universell in Zeit und Raum gültiges physikalisches Axiom. Zur Starken und Schwachen Kernkraft, Elektomagnetismus sowie Gravitation, stellt der WAF gleichsam die fünfte Fundamentalkraft im Universum dar. Und des Öfteren wirkt der WAF zweifelsohne stärker als alle 5 Kräfte in Summe!

Schöne Ostern, Oliver

PS: Wie genau kann man im Sinne eines Sachbeweises ein - ich nehme an veröffentlichtes -  Buch "nachweisbar" nicht lesen?

[Prof. Dr. Peter Henning]

Indem man den angegriffenen Satz übereinstimmend falsch zitiert.

LG

pah