DS18x20 Sensoren als Zustandsgeber zweckentfremden

[gelbwichtel]

Hallo,
ich wollte euch mal mein letztes Projekt vorstellen.

Ich setze fhem auf einem Raspberry-Pi in Verbindung mit einem AVR-Net-IO (Ethersex) ein.
Der Netio steht weit vom Pi weg und ich betreibe hier z.Z. 20 Temperatursensoren am 1w Bus.
Diese sind nicht parasitär angeschlossen und bus- und sternförmig gemischt betrieben. Funktioniert seit Wochen ohne Probleme, wobei ich die Sensoren alle 5 bzw. 10Minuten abfrage.

Beim Aufbau des Projekts ist mir aber mehr als einmal vorgekommen, dass beim Ansprechen von Sensoren - die nicht aktiv im System eingebunden waren - es teilweise zu sehr langen Timeouts und zu sonderbaren Daten kam.

Daher kam mir die Idee, nur noch die Devices anzusprechen, die auch wirklich existent sind.

Dazu bediene ich mir des "1w list" Kommandos. Dieses lieferte aber auf eine Anfrage teilweise unterschiedliche Antwortszenarien. Bis zum "OK" der "1w list" Antwort musste ggf. mehrfach gelesen werden. Desweiteren bin ich beim Einsatz dieser Variante auf Nummer sicher gegangen und setzte das "1w list" erst dann ab, wenn ich sicher sein kann, dass nicht noch sonstige Antworten von der Schnittstelle kommen. Ich synchronisiere hier anhand der IP-Adresse.

Soweit die Theorie. In der Praxis bedeutet dies, dass einfach nur ein Attribut "check" gesetzt werden muss.

define TESTIO ECMD telnet 192.168.178.224:2701
attr TESTIO check 1  

Werden jetzt ECMD_Devices angesprochen, die nicht existieren, so erfolgt für diese keine Kommunikation über die Schnittstelle.  

In dem Zusammenhang ist mir dann die Idee gekommen den Zustand von Geräten, Fenstern und sonstigen über den 1w Bus abzufragen.

Hier kommt die neu geschaffene Classdef ONEWIRESWITCH ins Spiel:

attr TESTIO classdefs ONEWIRESWITCH=/var/InternerSpeicher/fhem/onewireswitch.classdef

# Uebergabeparameter OnewireSwitch Geräte ID
params devIDOn devIDOff
# Umsetzung in ECMD Befehle
# 1w switchingState
get state cmd {"1w switchingState %devIDOn %devIDOff"}


Ein ONEWIRESWITCH wird dann folgendermaßen definiert:

define 1wSwitch_1 ECMDDevice ONEWIRESWITCH 100acbb00108002a 200acba00448009c

Die Abfrage erfolgt mittels "get 1wSwitch_1 state".

State gibt ein "on" zurück, wenn der Sensor 100acbb00108002a gefunden und ein "off", wenn der  200acba00448009c gefunden wird. Wird keiner oder sogar beide Sensoren gefunden, so kommt ein "undefined", was aber nur dann der Fall sein kann, wenn die dazu notwendige Beschaltung falsch ist. Das oben erwähnte "check"-Attribut ist hier nicht explizit zu setzen.

In der Praxis bedeutet dies, dass ein zu überprüfendes Gerät in Verbindung mit einem passenden Relais (Wechselkontakt) einmal den einen Sensor, einmal den anderen Sensor schaltet. Günstig eingekauft kommt man zw. 5,-- und 10,-- € hin.

Anmerkungen:
- konstengünstig, am 1w Bus einsetzbar
- bei dieser Lösung ein notitfy einzusetzen ist wahrscheinlich nicht sinnvoll, würde wahrscheinlich zu einer hohen Systemlast führen. Ich setze dies zu einem gezielten Abfragen ein.
- u.U. ist die Implementierung aus Sicht des ECMD-Modul-Entwicklers suboptimal, wenn nicht sogar in den falschen Quellen, aber ich wollte nicht noch tiefer einsteigen
- ich habe lediglich die Kommunikation zum AVR betrachtet, bei USB wird  wohl noch was angepasst werden müssen
- Sofern jemand da Gefallen dran finden sollte, das ev. in die offiziellen Quellen aufzunehmen, darf er das gerne tun, mir fehlt momentan die Zeit dazu und auch das nötige Wissen. Aber vielleicht nimmt mich jemand bei der Hand und erklärt es mir.  
- Weiterhin denke ich, dass der Quellcode lesbar ist, aber durchaus noch optimert werden kann. Ist halt mein erstes Perl-Projekt.

So viel Spaß
gelbwichtel

[Prof. Dr. Peter Henning]

Hm, so ganz verstehe ich noch nicht, was da gemacht werden soll.

Das Vorhandensein eines Sensors am Bus überprüfen ?

Das geht normalerweise sehr viel schneller, als den ganzen Bus nach allen möglichen Sensoren abzusuchen.

LG

pah

[gelbwichtel]

Hallo pah,
erst mal Danke für die Antwort.
Tatsächlich ging es zuerst darum die Existenz der Sensoren zu prüfen. Wie gesagt, das Zusammenspiel mehrerer Sensoren über Original ECMD mit dem NetIO und Ethersex lieferte  kaum nachvollziehbare Werte und Antwortverhalten, wenn Sensoren angesprochen wurden, die mal gerade nicht im Bus hingen. Da mir bei ECMD in Verbindung mit den DS18x20 außer set und get keine anderen Kommandos bekannt sind, hab ich mir halt was gestrickt. Da dies auch zum Einarbeiten in Perl auch ein lehreiches Projekt war, würde es mir noch nicht mal sonderlich missfallen, wenn es da schon eine einfachere Lösung dafür gäbe. Vielleicht kannst du mir ja mal aufzeigen, wie eine andere Lösung für oben genannte Konfiguration aussähe.
Vielen Dank auch noch für all deine lehrreichen Kommentare und Beiträge in diesem Forum.
cu
gelbwichtel

[Tobias]

Der DS18x20 hat die Besonderheit, das man abfragen kann, ob dieser parasitär oder mit einer extra 5V Spannung am Bus hängt.
Wenn man jetzt über den Schalter die 5V zu- oder abschaltet, kann man den DS18x20 als Statusgeber missbrauchen.
Selbst noch nicht gebaut, aber schon öfters gelesen

[gelbwichtel]

Ja, den Artikel kenne ich. Aber in ethersex ist der Befehl 'power' nicht implementiert.
Daher die Eigenkomposition onewireswitch.

[Prof. Dr. Peter Henning]

Immer noch verwirrend.

- Für die Feststellung der Anwesenheit reicht ein DS2401, da braucht es kein Thermometer
- Für die Feststellung eines Schaltpegels würde ich statt Relais und Thermometer doch einen Switch vorziehen.

Vielleicht erklärt noch einmal jemand deutlich, was der Anwendungszweck sein soll.

LG

pah

[gelbwichtel]

Also ich versuche es nochmal zu beschreiben, wie es zu meinem ONEWIRESWITCH gekommen ist.

Plattform:
Fhem-Server auf Raspberry in der dritten Etage, 1W Devices am AVR-Net-IO mit Ethersex im Keller, per LAN erreichbar.

Vorgabe:
zeitlich unkritische Schaltzustände am 1W Bus des AVR auslesen und keine neuen USB/seriell-Devices anbinden.

Daraus folgt aus meiner Sicht:
Es ist nur ECMD einsetzbar. OWX wird in dem Fall nicht unterstützt. Da bei ECMD über 1W aber nur die DS18xx als Sensoren angesprochen werden können, hab ich quasi diese als SerialID ( DS2401)  missbraucht. Da ich mir noch keinen DS2401 zugelegt hatte, konnte ich auch vorab nicht testen, ob und wie dieser sich vielleicht mit ECMD ansprechen lässt.

Hoffe, dass dies jetzt die Frage nach dem Sinn und Zweck mal auf den Punkt gebracht hat. Ist halt immer schwierig als Newbie was zu beschreiben, was alten Hasen quasi schon selbstverständlich ist.

Vielleicht liege ich ja mit diesen Annahmen hier falsch und lasse mich gerne eines besseren belehren.

Aber egal zu welcher Schlussfolgerung wir jetzt kommen, für mich war es ein willkommener Anlass mich in Perl einzuarbeiten.
lg
gelbwichtel

[Prof. Dr. Peter Henning]

Stimmt nicht ganz, denn ECMD kann auch den A/D-Konverter DS2450 bedienen - damit könnte man auf 4 Kanälen parallel das Vorhandensein einer Spannung überprüfen Das ist zwar auch in gewisser Weise Missbrauch eines A/D-Wandlers, aber wer denn unebdingt Ethersex verwenden will ...

Der richtige Weg wäre sicher, die Ethersex-Programme um eine echte 1-Wire-Ansprache zu erweitern - das hat aber niemand auf der Tagesordnung.

LG

pah