LBS19000170 - 1 Wire owphp LBS - iButton Version

[Stoxn]

Hallo Zusammen,

basierend auf jonofe owphp Baustein habe ich mich an einer iButton Version versucht.
Ich bin kein Entwickler, darum ist der Stand mit Vorsicht zu genießen.

Der Unterschied beim Auslesen von iButtons ist, dass lediglich die Info benötigt wird, ob der Sensor am 1-Wire Bus hängt oder eben nicht. Insbesondere soll dieser Wert möglichst häufig (<= 1 Sek) ausgelesen werden, um Anwesenheit zeitnah zu schalten.

Der LBS wird mit den bekannten Infos versorgt, zusätzlich muss der iButton Busmaster angegeben werden (standardmäßig bus.0). Schaut mal in Euren owhttpd, ob ein solches Objekt existiert und darunter alle iButtons gelistet sind.

Mittels Intervall wird das Abfrageintervall angegeben - bitte startet hier mit 1000ms, statt dem Minimum 500ms. Ich übernehme keine Garantie, dass der LBS edomi oder 1-Wire in die Knie zwingt oder sogar beendet wird. Aktuell nutze ich ein sh.py Plugin und dort sind 500ms möglich. Bei mir lass ich den Baustein ebenfalls mit 1000ms laufen.

Mit jedem Intervall wird einmalig das Verzeichnis bus.0 ausgelesen und jeder Eingangs iButton auf Anwesenheit geprüft. Ausgang wird dann entsprechend auf [0|1] gesetzt.

Hier noch ein Auszug aus dem Hilfetext, falls es hakt:

In case you have issues with the connection:
- Make sure your owfs.conf on the 1-Wire server allows external connections (e.g. server: server 192.x.x.x:4304 in addition to localhost:4304)
- Make sure the libraries above are in the correct folder and have 755 permission
- Make sure /etc/php.ini is updated with "enable_dl = On" (currently line 814)

Und hier jetzt endlich der Link:
https://service.knx-user-forum.de/?c...ad&id=19000170

Viele Grüße,
Patrick

[jonofe]

Hi Patrick,

eine Empfehlung für Bausteine mit vielen Ausgängen, die durch regelmäßiges Polling gesetzt werden: Am besten ist es, wenn du in der while Schleife in einer internen Datenstruktur die Werte der Ausgänge sicherst und den Ausgang nur dann mit setLogicLinkAusgang beschreibst, wenn sich der Wert geändert hast. Das kommt in deinem Fall vermutlich sehr selten vor und das spart dann auch an jedem Ausgang einen sendByChange LBS. Denn jedes Schreiben eines Ausgangs generiert mind. einen DB Zugriff (zumindest nach meinem Verständnis) und das wirkt schon recht stark auf die Performance aus. Ich habe die Erfahrung mit meinem mPower Baustein gemacht, der bei einer Sechsfach Steckdose 36 Ausgänge hat. Sauber umgesetzt habe ich es auch noch nicht, aber es ist aus meiner Sicht beste Lösung es zu machen wie oben beschrieben.

VG
André

[wintermute]

eine Empfehlung für Bausteine mit vielen Ausgängen, die durch regelmäßiges Polling gesetzt werden...

Prinzipiell ne prima Idee, muss ich versuchen, mir zu merken!
Aber erzeugt nicht auch das Zwischenspeichern in einer Variablen nen DB-Zugriff? Also gewinnt man da intern wirklich was bei - abgesehen natuerlich von den SBC-Bausteinen, falls die benoetigt werden...

[Stoxn]

Hi André,

vielen Dank für den Tipp - da mache ich mich am WE gleich dran. Hatte nämlich bereits einen "Maximum execution time of 5 seconds exceeded" Fehler. Das kann an den vielen Operation oder den 1-Wire Abrufen liegen. Mit 5 Sekunden läuft es gerade stabil, aber das ist zu lang - wenn man beispielsweise die Alarmanlage mit Anwesenheit über iButton abschalten möchte.

Stimmt, die sendbychange-LBS macht es dann natürlich überflüssig.

Danke noch mal, dass Du Dir den Code angeschaut hast. Wünsche Dir ein schönes Wochenende!

Viele Grüße,
Patrick

[jonofe]

Die execution time musst du bei einem Daemon, d.h. bei einer Endlosschleife auf Null setzen, sonst beendet sich der LBS unweigerlich, da er ja ständig läuft und sich bei jedem Schleifendurchlauf die Ausführungszeit aufaddiert.
Anders ist es bei einem EXEC LBS, der sich nach einem Durchlauf beendet. Dann stellt die Execution sicher, dass er sich nicht in einer Endlosschleife aufhängt, sonderns sich spätestens nach x Sekunden beendet.

[coliflower]

Könnte das nicht ein Ansatz sein ?

### DEF-Teil
[v#3 = 0]


### LBS-Teil
if (($E[3]['value'] == 1) AND ($E[3]['refresh'] == 1)) {
    setLogicElementVar($id,3,1);    // PAUSE
}


### EXEC-Teil
if (getLogicElementVar($id,3) == 1) {
    $ctx=stream_context_create(array('http' => array('timeout' => 3 )));
    $r=file_get_contents($url.'pause',0,$ctx);
    writeToTraceLog(0,true,'iTunes E03 URL  :'.$url.'pause'.' / ctx '.$ctx);
    setLogicElementVar($id,3,0);
} 

Wobei in EXEC-Teil nur der If und am Ende setLeogicElementVar() wichtig ist ..

[jonofe]

Aber erzeugt nicht auch das Zwischenspeichern in einer Variablen nen DB-Zugriff? Also gewinnt man da intern wirklich was bei - abgesehen natuerlich von den SBC-Bausteinen, falls die benoetigt werden...

Ich meinte nicht die EDOMI "V" variablen, sondern ein interne PHP Datenstruktur, z.B. ein einfaches array().
Wenn man EDOMI Variablen verwnden würde, hättest Du natürlich Recht, diese würden vermutlich ähnlichen DB Overhead erzeugen.
Aber da es ja ein Daemon ist, der sich nicht beendet, bleiben ja auch die globalen PHP Variablen immer erhalten. Und da sie nur im EXEC Bereich genutzt werden und nicht im LBS Teil funktioniert das sehr gut.

[wintermute]

...da es ja ein Daemon ist...

Mea culpa, nicht richtig gelesen

[jonofe]

Könnte das nicht ein Ansatz sein ?

Ein Ansatz wofür?

[coliflower]

Um die Ausgänge nur bei Änderung am Eingang zu beschreiben ...

[jonofe]

Um die Ausgänge nur bei Änderung am Eingang zu beschreiben ...

Nein, denn das was du machst bezieht sich auf die Eingänge. Es ging hier ja um die Ausgänge, die z.B. durch ein Pollen des 1wire Buses 4 mal pro Sekunde gesetzt werden sollen. Dazu liest man die Daten im EXEC-Teil in einer Endlosschleife vom 1wire Bus, vergleich die Ergebnisse mit dem Schleifendurchlauf zuvor und setzt die Ausgänge mit SetLogicLinkAusgang() nur dann, wenn sie sich geändert haben.

[Stoxn]

So, ich habe das Time Limit auf 0 gesetzt und die Ausgänge schreibe ich nur bei Änderung. Läuft seit gestern Nacht stabil - weder edomi, noch der Server mir owfs zeigen erhöhte Last, Temperatur etc. Den Abfragezyklus habe ich auch wieder auf 500ms runtergesetzt.

Danke für Eure Anregungen und für Codeverbesserungen bin ich immer offen, da ich kein Entwickler bin.