- √ - Onewire-Plugin: DS2401 als "non-iButton" funktioniert scheinbar nicht

[Robert]

Hi!

Heute habe ich auch alle Onewire-Sachen endgültig komplett auf sh.py umgestellt - vielen Dank für dieses grandiose Stück Software!

Diverse DS2438, DS18B20 und DS2406 laufen problemlos, allerdings will mein eines Fenster mit DS2401 Onewire-ROM nicht. Nach Blick in Doku ("B") und Plugin-Code festgestellt, dass es ohne einen iButton-Busmaster zu definieren nicht funktioniert. Aber auch mit einem flugs angelegten "Fake"-iButton-BM (81.xxxxx) funktioniert das ganze nicht.

Ich könnte mir da jetzt evtl. was zurecht-patchen, aber generell möchte ich anregen: die DS2401 sollten auch als "normale" Busteilnehmer funktionieren. Immerhin bieten die sich eben auch gut für einzeln überwachte Schließkontakte an. Kann da jemand was zu sagen?

Grüße
Robert

[callidomus]

Hallo Robert,

schön das Dir das Plugin gefällt.

Momentan wird für die iButton ein dedizierter BM benötigt. Kein Fake/Virtueller sondern ein Realer der auch von owfs gefunden wird.

Ich kann mir das noch mal näher ansehen, vorher möchte ich allerdings das Problem mit dem KNX-Plugin und den Wiederholungen angehen.

Bis bald

Marcus

[Robert]

Hi Marcus,

dank dir für die ultra-schnelle Antwort.

Gut, wenn ich nichts übersehen habe (eben "es geht mit Fake-BM") werde ich da mal nachschauen.

Was die KNX-Geschichte angeht: Meiner unerheblichen Meinnung nach muss die "Loop-Sperre" da tatsächlich so rein wie es mal war rein. Die auch von mir vertretene Meinung, dass ein Item immer (durch senden) sicherstellt, überall kohärente Informationen zu haben ist wohl nicht zu halten. Zu viele Neueinsteiger sind ja auch schon drüber gestolpert. Ich habe zugegebenermaßen auch mittlerweile die Abfrage (wieder) drin.

Grüße
Robert

[callidomus]

Hallo Robert,

die DS2401 sollten auch als "normale" Busteilnehmer funktionieren. Immerhin bieten die sich eben auch gut für einzeln überwachte Schließkontakte an. Kann da jemand was zu sagen?

Wenn ich Dich richtig verstehe möchtest Du die DS2401 als Binäreingang "missbrauchen".

Du kennst Dich wahrscheinlich besser aus als ich was den Bus an sich angeht.
Ich habe beim entwickeln des Plugins z.T. Probleme mit dem Bus gehabt wenn ich zu häufig Abfragen gemacht habe, dann ist die Spannung zusammengebrochen.
Auf der anderen Seite möchte ich die iButtons, für das Schlüsselbrett, wirklich zügig erkannt haben. Dafür habe ich auch in Kauf genommen einen dedizierten BM einzusetzen.
Mit dem Rewrite des Plugins habe ich auch noch für die I/O-Bausteine eine dedizierte Behandlung eingebaut die auch zügig, wenn auch nicht so zügig wie die iButtons, reagiert. Was spricht gegen normale I/Os? Der Preis? Die "Komplexität" der Schaltung?
Dein Bus an dem die DS2401 hängen ist nicht dediziert, oder? Dort hängen auch noch Temp und andere Sensoren dran?

Welches Abfrageintervall hättest Du gerne? (Momentan habe ich nicht vor das Plugin noch einmal umzubauen)

Bis bald

Marcus

[Robert]

Hi Marcus,

mit "missbrauchen" hat das nix zu tun: http://pdfserv.maximintegrated.com/en/ds/DS2401.pdf - Ich sehe da ganz normale Gehäuse und KEINEN iButton. ;-) Ja, den TO92 kann man schön einfach in die Leitung hängen - so wie es ja gedacht ist. Preis ist an dieser Stelle Nebensache - für mein eines Fenster kostet mich das Nachdenken mehr als ein 15 Euro Busankoppler... Geht eher darum es es generell schon funktionieren sollte.

Ja, dass Onewire bisweilen zickig ist kann man ausreichend nachlesen. Bis auf das Kinderbadfenster bin ich auch mittlerweile wieder komplett auf KNX umgeschwenkt - trotzdem sollte es funktionieren. Generell habe ich auch genug Busmaster, um den IOs/"iButtons" einen eigenen zu spendiern - siehe Anhang.

Das Problem ist - vielleicht auch weil ich es nicht verstehe - was für eine Addresse ich für den "BM" angeben soll. Das scheint mir sehr auf einen DS9490R USB-Master zugeschnitten zu sein, der wohl immer noch ein 1W-ROM dabei hat.
Das haben meine (und andere Geräte, Busware ROT?) mit I2C-Busmastern aber nicht (DS2482-100/101/800 bzw. DS2483) und es ist ja auch kein technisches Muss sondern ein Hack, weil die USB-Dinger immer wild in verschiedenen Reihenfolgen enumeriert werden. Bei i2c ist das aber "stabil" und es würde ausreichen, einen Busmaster über "/dev/i2c-<num>:<addr>" zu identifizieren.

Allgemein:
- iButton-Busmaster sollten für i2c-Geräte auch per Pfad (s.o.) deklariert werden können - sonst ist das mit diesen Geräten inkompatibel
- der Unterschied in 3 "Geschwindigkeitsklassen" ("Sensoren", IOs, iButtons) erscheint mir unglücklich, da man eben in so Löcher fällt dass die Chips nicht immer sich da einsortieren lassen. Wenn an einem DS2406 was wichtiges hängt soll der halt maximal gepollt werden, gleiches für einen Temperatursensor der vielleicht eine Verbrühung verhindert. Hingegen der DS2401 ("iButton") der im Briefkasten hängt kann meinetwegen alle 5min abgefragt werden.

Wunsch an den Weihnachtsmann:
- es gibt 3 Gruppen ("high", "medium", "low" - wenn programmtechnisch wesentlich einfacher) oder kontinuierlich per Sensor um das Abfrageintervall einzustellen
- für verschiedene DSxxxx gibt es Standard-Zuordnungen/Werte, also je nach Lösung DS18B20="low"/300s und DS2401="high"/20s. Diese Werte können durch "ow_priority" oder "ow_cycle" pro Sensor überschrieben werden.

Ist nur eine Anregung - aber zumindest die Addressierung der BM sollte wohl angepasst werden. Hat noch keiner der eine ROT-Extension am RasPi hat versucht iButtons einzusetzen? Ich guck da morgen/heute auch noch mal drauf.

Grüße
Robert

[callidomus]

Hallo Robert,

beim ROT kann man die OnBoard-Schnittstelle auch nicht für iButtons verwenden. Sehe ich aber als nicht tragisch an, da man eh mehr als einen Busmaster benötigt.
Wie kann man denn I2C-Busmaster eindeutig über owfs identifizieren? Also über owdir/owread?

Bis bald

Marcus

[Robert]

Hi Marcus,

die i2c-BMs kriegt man leicht über

http://smartgate:2121/bus.0/bus.3/interface/settings/address

Da kommt dann bei mir z.B. "/dev/i2c-5:18" zurück.

Bzw. den "Typ" kann man abfragen mit

http://smartgate:2121/bus.0/bus.3/interface/settings/name

-> "DS2482-100" (was bei mir falsch ist, das ist ein DS2483 der aber große Gemeinsamkeiten hat)

Grüße
Robert

[Robert]

Hi Marcus,

ich versuche heute Abend da was zu hacken...

Taktik:
vor dem Starten der "xx_loop"s erkennen, das "B" ohne "BM" -> dann iButton_busses mit dem root ausfüllen und in den io_loops den iButton-Loop mitlaufen lassen.

Hoffe das geht minimal-invasiv.

Grüße
Robert

[callidomus]

Hi Robert,

ich versuche heute Abend da was zu hacken...

dann bitte erstmal als Branch oder Fork.

Danke

Marcus

[Robert]

Funktioniert bei mir 1a und sollte auch ROT-Usern ermöglichen zumindest ihre iButtons abzufragen:

diff --git a/plugins/onewire/__init__.py b/plugins/onewire/__init__.py
index 200a4c0..4b4e64b 100755
--- a/plugins/onewire/__init__.py
+++ b/plugins/onewire/__init__.py
@@ -254,6 +254,16 @@ class OneWire(OwBase):
             return
         self._sh.scheduler.add('1w-sen', self._sensor_cycle, cycle=self._cycle, prio=5, offset=0)
         #self._sh.scheduler.add('1w', self.wrapper('bus.1'), cycle=self._cycle, prio=5, offset=4)
+        if self._ibuttons != {} and self._ibutton_masters == {}:
+            logger.debug("1-Wire: iButtons but no iButton Masters... moving to IOs")
+            for addr in self._ibuttons:
+                for key in self._ibuttons[addr]:
+                    if key == 'B':
+                        if addr in self._ios:
+                            self._ios[addr][key] = {'item': self._ibuttons[addr][key]['item'], 'path': '/' + addr}
+                        else:
+                            self._ios[addr] = {key: {'item': self._ibuttons[addr][key]['item'], 'path': '/' + addr}}
+            self._ibuttons = {}
         if self._ibutton_masters == {} and self._ios == {}:
             return
         elif self._ibutton_masters != {} and self._ios != {}:
@@ -290,11 +300,15 @@ class OneWire(OwBase):
                     logger.debug("1-Wire: no path found for {0}".format(item.id()))
                     continue
                 try:
-                    value = self.read('/uncached' + path)
+                    if key == 'B':
+                        entries = [entry.split("/")[-2] for entry in self.dir('/uncached')]
+                        value = (addr in entries)
+                    else:
+                        value = self._flip[self.read('/uncached' + path)]
                 except Exception:
                     logger.warning("1-Wire: problem reading {0}".format(addr))
                     continue
-                item(self._flip[value], '1-Wire', path)
+                item(value, '1-Wire', path)

     def _ibutton_loop(self):
         threading.currentThread().name = '1w-b'

Getestet in einem Netzwerk mit mehreren Temperatur- und Feuchtesensoren an mehreren Bussen (auch an dem wo der DS2401 dranhängt).

Grüße
Robert

[callidomus]

Hallo Robert,

sieht gut aus! Checke es doch bitte in develop ein.

Danke

Marcus