DS2408 mit hoher Frequenz mittels Alarming auslesen

[cwagner]

Auch wenn wir jetzt ein wenig OT werden: Habe mir den Abschnitt auch mit der beruflichen Erfahrung in einem Massenmedium (unter einer halben Million täglicher Leser sind sehr viele sehr unterscheidlich empfindsame Menschen) durchgelesen und meiner "besten aller Ehefrauen" gezeigt. Es stimmt auch: Für viele (überwiegend Männer) ist beim Smarthome der Weg das Ziel und die Funktion die Krönung, für viele (überwiegend Frauen) ist die Funktion gegebenenfalls nützlich und muss dann aber auch ohne Gefrickel stets nutzbar sein.
In dem Abschnitt wird sehr richtig drauf verwiesen, dass die Makes auch ohne den rettenden Eingriff des Makers laufen müssen.
Schwachpunkt des "WAF" ist das Stereotyp: Es gibt auch (reichlich) Männer, die Technik gerne einsetzen, aber keinerlei Probleme damit vertragen und es gibt eben auch Frauen, die eben auch gerne "basteln".

Das möchte ich noch um einen Aspekt aus der eigenen Erfahrung ergänzen: Bei meinem Eltern hatte ich auch manch smartes Gadget eingebaut, um ihnen das Leben in den anstrengensten letzten Lebensjahren zu erleichtern. Auch hier zeigte sich: Nur die Lösung ist gut, die schlimmstenfalls durch "Steckerziehen" wieder in Funktion gesetzt werden kann. Man muss einfach akzeptieren, dass ein(e) 90jähige(r) durchgefroren es nicht unbedingt unfallfrei in den Heizkeller schafft, um dort "Restart" zu drücken.

WAF ist ein Stereotyp, dass die Welt in Männer und Frauen teilt. Eigentlich sind aber in unserem Thema die beiden Seiten der Medaille die Maker (Bastler), die für Komfort und Zusatznutzen "schrauben" wollen, und die Nutzungsorientierten, die einfach Komfort genießen wollen.

[Oliver Vallant]

Zwischenzeitlich habe ich eine Lösung für das Alarming des DS2408 gefunden. Anbei die Beschreibung, falls jemand das Problem hat viele DS2408 zB. als Wandschalter (Taster) für Raumlicht in zumindest einer Sekunde abzutasten und ggf. einen Schaltvorgang (zB. Licht ein) auszulösen.

Grundsätzlich ist das fhem Device OWServer bereits in der Lage den OWFS Dienst owserver und dessen OWFS Verzeichnisse auszulesen. Es fehlt jedoch das Alarm-Verzeichnis in welchem OWFS die 1-wire Geräte auflistet, welche der Conditional Search entsprechen.

1) Ergänzung in 10_OWServer.pm

ab Zeile 80 einfügen:

Code Auswählen Erweitern


"/uncached/alarm"                    => "",


Zeile 492 einfügen:

Code Auswählen Erweitern


  } elsif($cmd eq "/uncached/alarm") {
        my $path= $cmd;
        my @devices= split(",", $owserver->dir($path));
        my $ret;
        for my $device (@devices) {
          my $name= "";
          my $address= substr($device, rindex($device, "/")+1);
          my $type= $owserver->read($device . "/type");
          foreach my $p (keys %defs) {
             $name= concatc(", ", $name, $p) if($defs{$p}{TYPE} eq "OWDevice" and $defs{$p}{fhem}{address} eq $address);
          }
          $ret .= sprintf("%s %10s %s\n", $address, $type, $name);
        }
        return $ret;


Die Abfrage "get <OWServer-Device> /uncached/alarm" liefert nun alle 1-wire Geräte, welche das Alarm-Flag gesetzt haben. Habe hier den Aufbau des Internals "devices" übernommen, sodass die Auswertung analog erfolgen kann.

2) Initialisierung der Conditional-Search:
Damit ein 1-wire Gerät überhaupt bei Änderung der Eingänge auf die Conditional Search antwortet müssen folgende Grundeinstellungen für jedes 1-wire Gerät durchgeführt werden:

a) por 0 ... Power On Reset. Das Bit zeigt an, dass das 1-wire Gerät nach Stromeinschalten initialisiert wurde. Es wird normalerweise beim ersten full-bus-scan gelöscht. Da OWFS das (zumindest bei mir) nur dann macht, wenn das erste Mal mittels OWFS/owhttp geöffnet wird, ist es sinnvoll manuell zu löschen.

b) set_alarm xyyyyyyyy ... Hier kann man kodieren, bei welchem Event und welchem Eingang das 1-wire Gerät auf die Conditional Search getriggert werden soll.

X  1 latch OR
Y  3 Selected HIGH

Für unseren Zweck demnach 133333333, Details siehe http://owfs.org/uploads/DS2408.html

c) latch.Y 0 ... Zum Unterschied des sensed.Y, welche die aktuellen Inputs des DS2408-Eingangs anzeigen, zeigt latch.Y die Veränderungen je Eingang an. Sobald ein einziges latch gesetzt ist, ist das gesamte Gerät alarmiert und reagiert auf die Conditional Search. Demnach müssen alle latches zuvor gelöscht werden.

d) restlichen 1-wire Geräte ... um die Conditional Search effektiv nutzen zu können, sollten naturgemäß alle anderen Geräte "schweigen", dh ich setzte bei mir die Alarm-Schranken der alarmfähigen Temperaturgeräte zB. DS18S20 auf nicht (schwer) erreichbar, mit temphigh 125, templow -50.

Folgende Funktion in 99_myUtils.pm geht die devices Liste des OWServer durch und setzt die Parameter (a-d). Die Liste muss auf die eigenen Geräte angepasst werden, ich verwende alarmfähig nur DS2408 und DS18S20:

Code Auswählen Erweitern


####################################################################
#  Setzt die Grundeinstellungen für das Alarming bei 1-wire Geräten
#  Parameter: OWServer

sub initBUSalarm($) {
   my ($bus) = @_;
   my $res = fhem("get ".$bus." devices");
   my @devices= split("\n", $res);

   #---proceed device at this 1-wire---
   for my $device (@devices) {
     my @line = split(" ", $device);
     my $type = @line[1];
     my $name = @line[2];
     if ($type eq "DS2408") {
       fhem("set ".$name." set_alarm .133333333");
       fhem("set ".$name." por 0");
       fhem("set ".$name." latch.BYTE ".owOFF);
       Log3 $name, 3, "Init alarming (set_alarm 133333333, por 0, latch.BYTE 0) at device: ".$name." type: ".$type;
     }
     if ($type eq "DS18S20") {
       fhem("set ".$name." temphigh .125");
       fhem("set ".$name." templow .-50");
       Log3 $name, 3, "Init alarming (temphigh 125, templow -50) at device: ".$name." type: ".$type;
     }
   }
}


3) Abfrage der Conditional-Search:
Ich war überrascht, aber die Conditional-Search via zusätzlichem layer OWFS kann einfach mittels at einmal pro Sekunde abgefragt werden. Folgende Funktion in 99_myUtils.pm liest die Alarmliste aus und sobald dort ein Gerät gemeldet wird, werden für dieses Gerät alle latches bewertet und wenn ein latch.Y eine Änderung anzeigt, dann und nur dann wird das entsprechende sensed.Y gelesen. Dh. es bleiben alle weiteren Notifies etc. für das OWDevice gleich, es kann jedoch das interval auf 1000000 gesetzt werden (ausschalten habe ich nicht gefunden), sodass auch zahlreiche DS2408 nicht mehr periodisch abgefragt werden müssen.

Code Auswählen Erweitern


####################################################################
#  Auslesen der Alarm-Liste vom OWFS-Server
#  Wird ein alamierter DS2408 gefunden werden alle latch ausgelesen und
#  das betroffene sensed mit get geholt.
#  Falls für das DS2408 userattr=autoClearAlarm:01234567 gesetzt ist
#  wird das latch auch wieder rückesetzt, alternativ muss dies das Notify
#  nach Ausführung dessen Auftrag manuell durchführen.
#
#  Diese Funktion muss per at sekündlich aufgerufen werden.
#
#  Parameter: OWServer

sub getBUSalarm($) {
   my ($bus) = @_;
   my $res = fhem("get ".$bus." /uncached/alarm");
   my @devices= split("\n", $res);

   #---proceed alarmed device at this 1-wire---
   for my $device (@devices) {
     my @line = split(" ", $device);
     my $type = @line[1];
     my $name = @line[2];
     Log3 $name, 4, "Alarmed: ".$name." Type: ".$type;

     #--- device dependant treatment---
     if ($type eq "DS2408") {

       #---Relais without Notifies needs to clear all latches automatically by userattr=autoClearAlarm---
       my @autoClearList=split(" ", AttrVal($name, "userattr",""));
       my $autoClear = "";
       for my $entry (@autoClearList) { if (index($entry,"autoClearAlarm") >= 0) { $autoClear=$entry; last; } }
       Log3 $name, 4, "AutoAlarmClear at device ".$name.": ".$autoClear ;

       #--- DS2408 has 8 ports---
       for (my $port=0; $port <= 7; $port++) {
         my $isLatched = fhem("get ".$name." latch." .$port);
         Log3 $name, 4, "Port at device ".$name.": ".$port." isLatched: ".$isLatched;
         #---Port ist latched, then get the input value---
         if ($isLatched == 1) {
           fhem("get ".$name." sensed.".$port);

           #---Port gets cleared if autoClearAlarm---
           if (index($autoClear,$port) >=0) {
             fhem("set ".$name." latch." .$port." ".owOFF);
             Log3 $name, 4,"autoClearedAlarm on Port: ".$port;
           }
         }
       }
     }
   }
   return undef;
}


Der aufmerksame Leser wird sich nun fragen, wie das Alarm-Flag gelöscht wird und hierfür gibt es zwei Methoden für unterschiedliche Anwendungsfälle:

a) Es geht nur um das Einlesen via get des Eingangs selbst und hierfür kann dem OWDevice ein userattr mitgegeben werden:

attr <OWDevice> userattr=autoClearAlarm:<0..Y..7>
Löscht nach alarming die angegeben latch.Y selbstständig, zB. "autoClearAlarm:0127" löscht latch.0 latch.1 latch.2 latch.7 alle anderen bleiben alarmiert.

b) Es hängt zB. ein Notify an diesem Eingang und das alarming soll erst bei positiver Ausführung des Notifies bewusst gelöscht werden. Dann in (a) den Eingang nicht angeben und im Notify mit "set <OWDevice> latch.Y 10> selbst löschen.

Es fehlt noch das at:

Code Auswählen Erweitern


define checkBUSalarm at +*00:00:01 {getBUSalarm("<OWServer>")}
attr checkBUSalarm group System
attr checkBUSalarm room hidden


Ergebnis
In meinem Testaufbau hatte ich 5Stk. DS2408 mit somit 40 Tastpunkten und jedes OWDevice mit interval=2 abgetastet, was bereits grenzwertig (Stichwort WAF) für eine normale Bedingung zB. eines Lichtschalters ist. FHEM ist auf einem Raspberry PI3 mit einem DS2408 BUS-Master via USB bereits mit sichtbaren Verzögerungen zB. bei Web-Zugriffen - insbesondere bei Plots - gelaufen. Durch die Umstellung auf Alarming wie oben angeführt merkt man subjektiv keine Last und die Reaktionszeit auf Tastpunkte liegt bei einer Sekunde. Ich bin gespannt wie es im Echtbetrieb mit 50Stk DS2408 aussieht...

LG Oliver

[habeIchVergessen]

Beim conditional search kann doch das erste Byte der Adresse (0x29; Family Code) die Einschränkung übernehmen. Ob owserver dies unterstützt, kann ich aber nicht sagen. Dann muss "nur" noch geprüfte werden, ob der erste Treffer mit dem gesuchten Family Code beginnt.

Welches PCB benutzt du für den DS2408?

[Oliver Vallant]

Was ich gesehen habe ist der Family Code im OWFS nicht in die Conditional Search einstellbar. Und nur wenn es Geräte in der Conditional Search im 1-wire Protokoll ausschließen kann bringt es was. Denn die Suche am Bus ist "teuer", das nachträgliche Entfernen der nicht benötigten Family Codes in der Alarmliste "billig".

Ich habe selbst zwei Design:

Ein Sensor-Board mit einem DS2408S frei beschaltbar zB. 6 Tasteingängen und 2 LED Ausgängen im Format 50x50, sodass es hinter der potentialfreie Kontakte-Schaltergruppe (bei mir Gira S55) in eine Unterputzdose passt. Als Stecker verwende ich normale RJ45, als Kabel cat5e. Darüber ziehe ich jeweils verdrillt, 2x 12v, 2x 1-wire, 2x 5v, 2x Aux (bei mir tlw. Audio mono) in normaler Typ A Beschaltung. jeweils 2 Ports durchgereicht pro Print, sodass weiterverbunden werden kann.

Ein Relais-Board mit jeweils 2 DS2408S mit 12V max. 200mA Ausgängen auf welche ich dann je nach Bedarf 16 Finder Relais, Opto oder 8 Stromstoßrelais (2 Kanal, 1x Last und 1x Rückkanal) hänge. Jumper für Aux-Power, dann kann man auf Aux 24V einspeisen und die Ausgänge direkt zB. im Gartenbereich Magnetventile ohne Relais verwenden. Stecker/Verkabelung analog.

Mein Problem war die SOftware. In Java geschrieben hat sie Grundfunktionen aber eben nicht mehr. Als Einzelkämpfer es sinnlos diese auf einen auch nur annähernd Feature-Stand eines Fhem zu bekommen. Deshalb freut es mich sehr auf Fhem gestoßen zu sein, vor allem mit engagierter Community.

LG Oliver

[Oliver Vallant]

Was verwendest du? Hast du analoge Geräte im Einsatz ADC DAC?

LG Oliver

[habeIchVergessen]

Ich habe die 1-wire-wlan-bridge von hexenmeister im Einsatz. Aktuell sind div. Temperatur-Sensoren, DS2423 (auf ATtiny-Basis) und DS2406 implementiert. DS2408 auf ATtiny-Basis funktioniert nicht so recht. Deshalb meine Frage nach dem PCB. Kannst du mir eine Bezugsquelle benennen?

[eldrik]

Zwischenzeitlich habe ich eine Lösung für das Alarming des DS2408 gefunden. Anbei die Beschreibung, falls jemand das Problem hat viele DS2408 zB. als Wandschalter (Taster) für Raumlicht in zumindest einer Sekunde abzutasten und ggf. einen Schaltvorgang (zB. Licht ein) auszulösen.

Grundsätzlich ist das fhem Device OWServer bereits in der Lage den OWFS Dienst owserver und dessen OWFS Verzeichnisse auszulesen. Es fehlt jedoch das Alarm-Verzeichnis in welchem OWFS die 1-wire Geräte auflistet, welche der Conditional Search entsprechen.

1) Ergänzung in 10_OWServer.pm

ab Zeile 80 einfügen:

Code Auswählen Erweitern


"/uncached/alarm"                    => "",


Zeile 492 einfügen:

Code Auswählen Erweitern


  } elsif($cmd eq "/uncached/alarm") {
        my $path= $cmd;
        my @devices= split(",", $owserver->dir($path));
        my $ret;
        for my $device (@devices) {
          my $name= "";
          my $address= substr($device, rindex($device, "/")+1);
          my $type= $owserver->read($device . "/type");
          foreach my $p (keys %defs) {
             $name= concatc(", ", $name, $p) if($defs{$p}{TYPE} eq "OWDevice" and $defs{$p}{fhem}{address} eq $address);
          }
          $ret .= sprintf("%s %10s %s\n", $address, $type, $name);
        }
        return $ret;


Die Abfrage "get <OWServer-Device> /uncached/alarm" liefert nun alle 1-wire Geräte, welche das Alarm-Flag gesetzt haben. Habe hier den Aufbau des Internals "devices" übernommen, sodass die Auswertung analog erfolgen kann.

2) Initialisierung der Conditional-Search:
Damit ein 1-wire Gerät überhaupt bei Änderung der Eingänge auf die Conditional Search antwortet müssen folgende Grundeinstellungen für jedes 1-wire Gerät durchgeführt werden:

a) por 0 ... Power On Reset. Das Bit zeigt an, dass das 1-wire Gerät nach Stromeinschalten initialisiert wurde. Es wird normalerweise beim ersten full-bus-scan gelöscht. Da OWFS das (zumindest bei mir) nur dann macht, wenn das erste Mal mittels OWFS/owhttp geöffnet wird, ist es sinnvoll manuell zu löschen.

b) set_alarm xyyyyyyyy ... Hier kann man kodieren, bei welchem Event und welchem Eingang das 1-wire Gerät auf die Conditional Search getriggert werden soll.

X  1 latch OR
Y  3 Selected HIGH

Für unseren Zweck demnach 133333333, Details siehe http://owfs.org/uploads/DS2408.html

c) latch.Y 0 ... Zum Unterschied des sensed.Y, welche die aktuellen Inputs des DS2408-Eingangs anzeigen, zeigt latch.Y die Veränderungen je Eingang an. Sobald ein einziges latch gesetzt ist, ist das gesamte Gerät alarmiert und reagiert auf die Conditional Search. Demnach müssen alle latches zuvor gelöscht werden.

d) restlichen 1-wire Geräte ... um die Conditional Search effektiv nutzen zu können, sollten naturgemäß alle anderen Geräte "schweigen", dh ich setzte bei mir die Alarm-Schranken der alarmfähigen Temperaturgeräte zB. DS18S20 auf nicht (schwer) erreichbar, mit temphigh 125, templow -50.

Folgende Funktion in 99_myUtils.pm geht die devices Liste des OWServer durch und setzt die Parameter (a-d). Die Liste muss auf die eigenen Geräte angepasst werden, ich verwende alarmfähig nur DS2408 und DS18S20:

Code Auswählen Erweitern


####################################################################
#  Setzt die Grundeinstellungen für das Alarming bei 1-wire Geräten
#  Parameter: OWServer

sub initBUSalarm($) {
   my ($bus) = @_;
   my $res = fhem("get ".$bus." devices");
   my @devices= split("\n", $res);

   #---proceed device at this 1-wire---
   for my $device (@devices) {
     my @line = split(" ", $device);
     my $type = @line[1];
     my $name = @line[2];
     if ($type eq "DS2408") {
       fhem("set ".$name." set_alarm .133333333");
       fhem("set ".$name." por 0");
       fhem("set ".$name." latch.BYTE ".owOFF);
       Log3 $name, 3, "Init alarming (set_alarm 133333333, por 0, latch.BYTE 0) at device: ".$name." type: ".$type;
     }
     if ($type eq "DS18S20") {
       fhem("set ".$name." temphigh .125");
       fhem("set ".$name." templow .-50");
       Log3 $name, 3, "Init alarming (temphigh 125, templow -50) at device: ".$name." type: ".$type;
     }
   }
}


3) Abfrage der Conditional-Search:
Ich war überrascht, aber die Conditional-Search via zusätzlichem layer OWFS kann einfach mittels at einmal pro Sekunde abgefragt werden. Folgende Funktion in 99_myUtils.pm liest die Alarmliste aus und sobald dort ein Gerät gemeldet wird, werden für dieses Gerät alle latches bewertet und wenn ein latch.Y eine Änderung anzeigt, dann und nur dann wird das entsprechende sensed.Y gelesen. Dh. es bleiben alle weiteren Notifies etc. für das OWDevice gleich, es kann jedoch das interval auf 1000000 gesetzt werden (ausschalten habe ich nicht gefunden), sodass auch zahlreiche DS2408 nicht mehr periodisch abgefragt werden müssen.

Code Auswählen Erweitern


####################################################################
#  Auslesen der Alarm-Liste vom OWFS-Server
#  Wird ein alamierter DS2408 gefunden werden alle latch ausgelesen und
#  das betroffene sensed mit get geholt.
#  Falls für das DS2408 userattr=autoClearAlarm:01234567 gesetzt ist
#  wird das latch auch wieder rückesetzt, alternativ muss dies das Notify
#  nach Ausführung dessen Auftrag manuell durchführen.
#
#  Diese Funktion muss per at sekündlich aufgerufen werden.
#
#  Parameter: OWServer

sub getBUSalarm($) {
   my ($bus) = @_;
   my $res = fhem("get ".$bus." /uncached/alarm");
   my @devices= split("\n", $res);

   #---proceed alarmed device at this 1-wire---
   for my $device (@devices) {
     my @line = split(" ", $device);
     my $type = @line[1];
     my $name = @line[2];
     Log3 $name, 4, "Alarmed: ".$name." Type: ".$type;

     #--- device dependant treatment---
     if ($type eq "DS2408") {

       #---Relais without Notifies needs to clear all latches automatically by userattr=autoClearAlarm---
       my @autoClearList=split(" ", AttrVal($name, "userattr",""));
       my $autoClear = "";
       for my $entry (@autoClearList) { if (index($entry,"autoClearAlarm") >= 0) { $autoClear=$entry; last; } }
       Log3 $name, 4, "AutoAlarmClear at device ".$name.": ".$autoClear ;

       #--- DS2408 has 8 ports---
       for (my $port=0; $port <= 7; $port++) {
         my $isLatched = fhem("get ".$name." latch." .$port);
         Log3 $name, 4, "Port at device ".$name.": ".$port." isLatched: ".$isLatched;
         #---Port ist latched, then get the input value---
         if ($isLatched == 1) {
           fhem("get ".$name." sensed.".$port);

           #---Port gets cleared if autoClearAlarm---
           if (index($autoClear,$port) >=0) {
             fhem("set ".$name." latch." .$port." ".owOFF);
             Log3 $name, 4,"autoClearedAlarm on Port: ".$port;
           }
         }
       }
     }
   }
   return undef;
}


Der aufmerksame Leser wird sich nun fragen, wie das Alarm-Flag gelöscht wird und hierfür gibt es zwei Methoden für unterschiedliche Anwendungsfälle:

a) Es geht nur um das Einlesen via get des Eingangs selbst und hierfür kann dem OWDevice ein userattr mitgegeben werden:

attr <OWDevice> userattr=autoClearAlarm:<0..Y..7>
Löscht nach alarming die angegeben latch.Y selbstständig, zB. "autoClearAlarm:0127" löscht latch.0 latch.1 latch.2 latch.7 alle anderen bleiben alarmiert.

b) Es hängt zB. ein Notify an diesem Eingang und das alarming soll erst bei positiver Ausführung des Notifies bewusst gelöscht werden. Dann in (a) den Eingang nicht angeben und im Notify mit "set <OWDevice> latch.Y 10> selbst löschen.

Es fehlt noch das at:

Code Auswählen Erweitern


define checkBUSalarm at +*00:00:01 {getBUSalarm("<OWServer>")}
attr checkBUSalarm group System
attr checkBUSalarm room hidden


Ergebnis
In meinem Testaufbau hatte ich 5Stk. DS2408 mit somit 40 Tastpunkten und jedes OWDevice mit interval=2 abgetastet, was bereits grenzwertig (Stichwort WAF) für eine normale Bedingung zB. eines Lichtschalters ist. FHEM ist auf einem Raspberry PI3 mit einem DS2408 BUS-Master via USB bereits mit sichtbaren Verzögerungen zB. bei Web-Zugriffen - insbesondere bei Plots - gelaufen. Durch die Umstellung auf Alarming wie oben angeführt merkt man subjektiv keine Last und die Reaktionszeit auf Tastpunkte liegt bei einer Sekunde. Ich bin gespannt wie es im Echtbetrieb mit 50Stk DS2408 aussieht...

LG Oliver

Hallo Oliver,

schöne Entwicklung die hier dank deiner Initiative stattgefunden hat!

Vielleicht magst du noch den Modul Maintainer auf die Erweiterung aufmerksam machen, damit diese ggfs. offiziell in das Modul aufgenommen wird.

Ich stand seinerzeit vor dem selben Problem meine DS2408 sekündlich abfragen zu wollen (Meldekontakt für Fenster, Tür, Bewegungsmelder etc. ) jedoch waren die Verzögerungen zu groß als das der gewünschte Komfortanspruch und Stabiltät darüber erreicht werden konnte.

Zwischenzeitlich habe ich meine reinen Meldekontakte DS2408 aus dem Bus herausgetrennt und frage je Stockwerk die entsprechenden Devices (ca. 5 Stück) mittels eines Ethernet angebundenen Arduino mit 1Wire Sketch ab, der die Status per mqtt meldet, klappt im Abfrageintervall von 250ms problemlos und zuverlässig, jedoch bin ich natürlich weiterhin daran interessiert, meine Umgebung möglichst homogen zu halten, daher werde ich auf deiner Basis demnächst ein paar Tests durchführen, ob hierüber die benötigten Reaktionszeit und Stabilität erreicht wird, die ich für meine Szenarien benötige.

Ist dein PCB selber entwickelt und würdest du dieses evtl. vorstellen und wäre dieses offen?

Greetz
Eldrik

[habeIchVergessen]

Und nur wenn es Geräte in der Conditional Search im 1-wire Protokoll ausschließen kann bringt es was. Denn die Suche am Bus ist "teuer"

ich habe mit dem DS2406 die Erfahrung gemacht, dass ein conditional search ca. 50ms kostet, wenn kein Device auf dem Bus anwortet.
Wenn mind. ein Temperatur-Sensor anwortet, dann vergehen ca. 160ms. Mit der Antwort ist auch klar, dass kein gesuchtest Device antwortet.

Wenn der DS2406 antwortet, dann entsteht natürlich mehr Kommunikation (mit Rücksetzen 2 Aufrufe), die zusätzlich Zeit benötigt.

Ggf. beruhen meine Beobachtungen auf unzureichenden Testszenarien (kleine Testumgebung mit max. 5 Devices).

[Oliver Vallant]

Hallo Eldrik,

vielen Dank für dein nettes Feedback - für einen kurzen Moment habe ich gedacht ich wäre der Einzige mit diesem Problem. Das DS2408 stellt für mich neben den Temperatursensoren und Counter eines der Schlüsselgeräte des 1-wire dar, da mit diesem ein echter Feldbus mit abgesetzten Relais und Sensoren mit großer Anzahl von In/Outputs erst möglich wird.

ad Modul) Ich werde die Lösung noch mit einer größeren Anzahl von Elementen testen, denn nur hierfür macht das Alarming Sinn. Verläuft dies positiv werde ich bei Dr.Neubert und M.Fischer bzl. Interesse an einer Integration anklopfen.
Grundsätzlich wäre noch interessant die Conditional Search (OWServer -> /uncached/alarm) nicht mittels at sondern im Zuge des Main Loops auszuführen, dann wäre vielleicht eine Abfrage jenseits der Sekundengrenze des at möglich. Da kenne ich mich leider nicht aus - müsste man ausprobieren. Dann wäre deine externe Lösung wieder rückführbar in fhem. Wie gesagt fängt für mich die Usability in diesem Bereich bei einer Sekunde an, eine Verbesserung unter 1Hz wäre wünschenswert aber keine Voraussetzung. Für mich überwiegt hier der reiche Fundus der fhem-Funktionalität vs. Reaktionszeit.

ad deine Tests) Bin schon sehr gespannt, vielleicht fällt dir noch eine elegantere Lösung ein.

ad PCB) Ja ist eine Eigenentwicklung. Da mehrere an der Entwicklung beteiligt waren, möchte ich nicht ohne Rücksprache veröffentlichen. Ich werde in den kommenden Tagen bei Tageslicht einige Fotos machen.

LG Oliver

[Prof. Dr. Peter Henning]

ich bleibe dabei, dass für diese Anwendung FHEM nicht gedacht ist. Der Missbrauch der Hauptschleife für die schnelle Busabfrage sorgt dafür, dass eine sinnvolle Integration mit anderen Sensoren und Aktoren nicht mehr machbar ist.

Nicht zuletzt deshalb sind alle brauchbaren Interfaces für schnelle Benutzerinteraktioinen mit separaten Protokollprozessoren versehen - sei es der CUL, oder z.B. ein HMLAN-Interface.

Es macht auch wenig Unterschied, ob man einen dezidierten Busmaster mit USB-Anschluss und DS2480B einsetzt (Kosten ca. 20 €), oder einen Arduino einsetzt, der alle 250 ms den Bus bedient und irgendwie (WLAN, oder USB) mit dem Haupsystem kommuniziert. Letzterer ist in der Regel sogar billiger.

LG

pah

[Oliver Vallant]

Hallo habeIchVergessen,

deine gemessenen 160ms für die Contitional Search mit einem Gerät ist eh optimal, da dies der Erwartungsfall ist. Wann werden schon in einem normalen Haus zwei Taster im identen 160ms Zeit-Slot gleichzeitig gedrückt? Und dann sind halt 2 Geräte mit 4 Zugriffen mit 300ms notwendig. Interessant ist nicht die Summenbetrachtung, sondern die kritische Verarbeitungskette: Tasterdruck -> Alarming -> Conditional Search -> latches auslesen bzl. Veränderung -> Aktor betätigen via Notify -> Aktor schaltet. Nachrangig weil unkritisch: auslesen des tatsächlichen Eingangs (sensed) -> quitieren des Alarms durch löschen des latch -> Betriebsstundenzähler aktualisieren-> protokollieren des Ereignisses in DB.
Die Temperatur-Sensoren würde ich gänzlich aus dem Alarming entfernen, da diese nichts wirklich bringen. Erstens müssen diese im asynchronen Betrieb zur (1) Messung "angestoßen" werden, sodass dann das Ergebnis 1s später (2) abgeholt werden kann. Alternativ meldet demnach (1) das Gerät via Alarming, wenn temphigh/maxlow Grenzen unter/überschritten wurden. Ich kann mir keinen Einsatz im Bereich Hausautomatisierung vorstellen, wo das Vorteile gegenüber einer periodischen Abfrage (zB. interval=300 Raumtemperatur oÄ) haben soll. Am ehesten noch eine Motortemperaturüberwachung mit temphigh, aber hier muss auch nicht im ms Bereich abgeschalten werden.

LG Oliver

[Oliver Vallant]

Hallo pah,

ist sicherlich eine Architekturfrage, welche zeitrelevanten Systemteile man als eigene Hardware herauszieht. Es hängt naturgemäß schlussendlich auch davon ab, was fhem auf der eingesetzten Hardware noch alles erledigen muss.
Ich für meinen Teil kann mit der 1Hz at-Variante sehr gut leben - gesetzt den Fall, dass die Abfragezeit nicht linear mit der Anzahl der Geräte steigt, was aber gegen die Lösung des alarming durch DalSemi grundsätzlich sprechen würde.

LG Oliver

[Oliver Vallant]

Hallo Eldrik,

wie versprochen mein Setting sowie meine Komponenten.

Connector-Board
Beinhaltet den BusMaster DS2480, Sicherung, Pegelumwandlung 12V auf 5V. Ein 1-wire Serial DS2401 zur eindeutigen Identifikation des USB-Stranges ist ebenfalls enthalten, da der DS2480 selbst nicht als Device erscheint und bei mehreren Connectors an einem PC, Linux gerne die /dev/ttyUSBx durcheinander bringt. Der Taster schaltet ein Master-Reset, falls notwendig.
Zusätzlich gibt es 3 Klemmböcke:
1) 12V und Masse Eingang
2) Akku Aus-/Eingang, falls man buffern möchte (permanent Ladegerät an 1 notwendig)
3) Aux (durch alle Geräte geschliffen, zB. für 1-Kanal Audio, zusätzlichen 24V etc.

An der Oberseite gibt es 3 RJ45 durchgeschliffene Busausgänge die folgend auf ein LAN-Kabel (ich verwende ungeschirmtes Cat5e):
Drillpaare: 2x 12v, 2x 1-wire, 2x 5v, 2x Aux

Und natürlich der USB-Anschluss an den PC. Bei mir verrichtet ein Kontron 1GHz Intel mit 1GB RAM und 8GB microSD passiv gekühlt auf Hutschine mit Ubuntu 11.04 und einer eigenentwickelten Fireware in Java, 5 Jahren störungsfrei seinen Dienst. Stammt noch aus einer Zeit vor einem brauchbaren Raspberry PI.

Relais-Board
Bestückt mit jeweils 2 DS2408S mit 12V max. 200mA Ausgängen auf welche ich dann je nach Bedarf 16 Finder Relais, Opto oder 8 Stromstoßrelais (2 Kanal, 1x Last und 1x Rückkanal) hänge. Jumper für Aux-Power, dann kann man auf Aux 24V einspeisen und die Ausgänge direkt zB. im Gartenbereich Magnetventile ohne Relais verwenden.

Anschlüsse:
2x RJ45 durchgeschliffen
1x Eingang DS2408(a) ... bei Verwendung von Stromstoßrelais als Rückkanäle 0 bis 7
1x Ausgang DS2408(a) ... bei Stromstoßrelais offen, bei Relais oder Opto, MosFET etc. Kanäle 0 bis 7
1x Ausgang DS2408(b) ... bei Stromstoßrelais Steuerkanäle 0 bis 7, bei Relais Kanäle 8-15

Dh. man kann jeden Kanal separat nach Notwendigkeit beschalten, das Relais lässt sich direkt mit 12V schalten oder man muss eben über Aux die notwendige Schaltspannung einspeisen:
- Finder Magnetrelais 34.51.7.012 (halbe Einbaubreite): verwende ich für kurzgeschaltene Lasten bis 6A wie Nebenlichter, Rollos etc.
- Finder Stromstoßrelais 20.22.9.012 für Lasten bis 16A, oder bei langfristigen Einschaltdauern, zB. Pelletsofen 1x ein im Herbst 1x aus im Frühjahr.
- Finder 34.81.7.024 MosFET (halbe Einbaubreite): für kleine Lasten, öftere Lastwechsel wie Lichter, Fussbodenheizungsventile etc., keine LEDs, die erreichen den notwendigen Schaltstrom zumeist nicht.
(Hab ein größeres (zu großes) Los gekauft als benötigt - bitte melden wenn jemand oben angeführte Relais benötigt, wären günstig abzugeben )

Sensor-Board
Bestückt mit einem DS2408S frei beschaltbar zB. 6 Tasteingängen und 2 LED Ausgängen im Format 50x50, sodass es hinter der potentialfreie Kontakte-Schaltergruppe (bei mir Gira S55) in eine Unterputzdose passt. Hier verwende ich auch öfters einen Eingang statt der zweiten LED für einen Bewegungsmelder PIR Rev.B von Parallax im 2er Rahmen oben das Tastfeld und unten den PIR eingebohrt in der  Gira Blindabdeckung. Der PIR verfügt über eine frontseitige rote LED in der Kuppel, die die Detektion signalisiert.

Anschlüsse:
2x RJ45 durchgeschliffen
2x 10pin IDE Pfostenstecker für eine Kabelpeitsche je nach verwendeten Tastenfeld, mit 8 Sensorleitungen, 8 LED-Ausgängen (Widerstände bereits am Board), 1x 12V mit Masse und 1x 5V mit Masse.

Hub 3 Kanal
Aus einer Not heraus entstanden, gibt es mittlerweile günstig bis 8 Kanal zu kaufen. Am Board ist zusätzlich ein Temperatursensor DS18S20, dh. ich verwende das Board auch für Raumtemperatur in einer Installationsdose hinter einer geschlitzten Gira Blindabdeckung.

Heizungsseitig habe ich meine Sonnenkraft 16port Steuerung mittels RS232 angebunden und der Rest steuer ich über einfache Relaiskontakte (Pelletsofen-Wärmeanforderung, Party-Schalter (für Nachtabschaltung), Thermostat-Schalteingänge für die Mischkreise (Radiatoren, Fussbodenhzg., 3000Ltr Bufferspeicher Mgt-Mitteleinspeisung, Boiler-Speisung umschaltbar via Buffer oder 400V Heizregister, Umschaltung bei Störung Pelletsofen 25kW auf 3x50A Elektrokessel (Backup).
Als Steckhülsentemperatursensoren verwende ich die wasserdichten Tauchsensoren von Demiawaking mit einem eingegossenen DS18B20 (grundsätzlich sehr gut, jedoch Messbereich von +125°C für Solaranlage zu gering).

Poolsteuerung mit Berechnung (Temp) Filterzeiten und Entkeimungszeiten, Filterpumpentemperaturüberwachung, Steuerung thermische Solaranlage 24m² und Poolheizung über 50kW Wärmetauscher via Buffer. Trafo 2x300W Unterwasserlicht temperaturüberwacht.

Zu den coolen Dingen wie Wetterstation, Fingerprint, Kindle-Display, Fenstersensoren etc. bin ich limitiert durch die eigene Software noch nicht gekommen, das wird sich mit FHEM jetzt ändern

LG Oliver

[Prof. Dr. Peter Henning]

bei mehreren Connectors an einem PC, Linux gerne die /dev/ttyUSBx durcheinander bringt

Das ist ein Gerücht - Linux bringt da gar nichts durcheinander. Und wie man einen bestimmten Adapter genau und fest einem I/O-Device zuordnet, ist schon ungefähr 2 Millionen Mal gefragt und beschrieben worden.

LG

pah

[Oliver Vallant]

Ich habe diesbezüglich nichts gefragt und habe die Zuordnung auch nicht zum 2.000.001ten Male beschrieben. Ich habe meine Motivation dargelegt, warum ich einen zusätzlichen DS2401 zur eindeutigen Identifikation des USB-Stranges, jenseits der Einstellungsmöglichkeiten und Erkennungsreihenfolge des OS und zukünftigen Versionen des OS erreichen kann. Hierdurch ist es möglich, bei Ausfall der Hardware kurzfristig nur durch restoren der letzten Konfiguration auf ein Ersatzgerät zu wechseln. Auch die Strangaufteilung kann ich jederzeit bequem ohne Änderung der OS Einstellungen auf mehrere PCs aufteilen, da jede Konfiguration immer auf den richtigen Strang angewendet wird. Letztlich wieder eine Architekturfrage.