Neue Idee: 1-Wire Push Device

[Prof. Dr. Peter Henning]

1-Wire Devices haben den Nachteil, dass sie eigentlich kein "Push" können - d.h. eintretende wichtige Änderungen an den Busmaster senden können.

Vor ein paar Minuten ist mir in einer anderen Diskussion eine Idee gekommen, wie man das dennoch umsetzen könnte: Ein 1-Wire-Push Device könnte von Client auf Master wechseln und etwas in einen anderen Client schreiben (der physikalisch z.B. direkt auf dem USB des FHEM-Rechners sitzt).

Natürlich kann das zu Kollisionen führen - die sind aber im Prinzip erkennbar.

Jemand Interesse an einer solchen Lösung ?

LG

pah

[der-Lolo]

Durchaus - die intervall zeit die 1-Wire benötigt um zuverlässig zu funktionieren stört ein wenig wenn man an anwendungen wie fensterkontakte denkt...

[det.]

Immer gern, dann hätte die Tüte voll DS2401 doch noch einen späten Nutzen als Türkontakte? Gut das ich die Dinger noch nicht weggeworfen hab. Bezüglich Wechsewirkungen kann man ja für die Push Devices einen eigenen Busmaster nehmen und das Ganze auch noch auf einem extra Server laufen lassen.

[UweH]

Interessante Idee, ich denke da an die Fenster- und Türkontakte, die ich für das Alarmmodul mitverwende. Bin gespannt.

@det.: Passt jetzt nicht zum Thema, aber pah möge bitte Nachsicht walten lassen... DS2401 als Türkontakt?

Grüße
Uwe

[Prof. Dr. Peter Henning]

Denkbar. Da das hier die Kreativkiste ist: Reed-Relais, welches in geschlossenem Zustand dem DS2401 auf den 1-Wire-Bus legt (also in der Datenleitung steckt). Busmaster fragt nacheinander alle DS2401 ab (einer pro Sekunde sollte machbar sein). Fehlt einer, ist dieser Kontakt offen. Überwacht alle Fenster und Türen mit nur einer Leitung.

LG

pah

[ext23]

Moin,

dann kann ich ja auch hier antworten. Ja das was du gestern in dem anderen Thread geschrieben hast ist durchaus eine sehr interessante Sache. Ich verstehe nur nicht den benefit, zwischen unserem "double-master" und FHEM auch 1-Wire zu benutzen und nicht Ethernet. Letztendlich egal, man kann normalerweise jede Dose irgendwie Patchen im Haus, aber so könnte man es auch an einem L3 Port anschließen. Vorteil der 1-Wire Lösung ist vermutlich das Thema FHEM Module wo wenig angepasst werden müsste.

Oder habe ich da was nicht verstanden? Wolltest du das über ein und denselben Bus schicken der sonst für die "slow1wire" Geräte dient?

Gruß
Daniel

[Prof. Dr. Peter Henning]

Oder habe ich da was nicht verstanden? Wolltest du das über ein und denselben Bus schicken der sonst für die "slow1wire" Geräte dient?

Genau.
Sollte kostengünstiger sein als Ethernet, darüber hinaus mit höherem WAF (Leitungsdurchmesser, z.B. zu auf Putz liegenden Geräten).

LG

pah

[UweH]

Reed-Relais, welches in geschlossenem Zustand dem DS2401 auf den 1-Wire-Bus legt

OK, klar *handaufdiestirnklatsch* 

[der-Lolo]

Gibt es hier neuigkeiten?

[Prof. Dr. Peter Henning]

Nö. Mein Nebenjob als Koordinator eines EU-Projektes frisst derzeit 200% meiner Zeit.

LG

pah

[smurfix]

1wire-push alias "wir spielen mal eben Busmaster" halte ich ehrlich gesagt für sehr problematisch. Es gibt keine funktionierende Kollisionserkennung, und die "normalen" Busmaster kann man nicht mal eben zum Slave machen.

Aber: Es gibt doch CONDITIONAL SEARCH ... dabei lassen sich nur die Slaves finden, bei denen irgendwas ansteht. Einem 18B20 zB kann man Temperaturgrenzen verpassen (leider nur mit 1°C Genauigkeit) und er lässt sich dann darüber finden, sobald die Schwelle über- oder unterschritten wird.

Als Folge davon bauen wir uns einen 1Wire-Slave auf Basis eines atmega88 (8 MHz CPU-Takt gehen mit meinem Code gerade so), bringen ihm bei dass er sich wie ein 8-Bit-Input zu verhalten hat (den 1-Bit-Dreibeiner zu faken geht natürlich im Prinzip auch, das ist aber uninteressant), hängen den Fensterkontakt da dran, und sagen ihm "lass dich finden, sobald sich etwas ändert". OWFS listet die Slaves dann unter /alarm auf. Und zwar auch dann, wenn das Verzeichnis versteckt ist, weil sich keine Geräte am Bus befinden, die das "offiziell" können.

Ich persönlich habe das Gebastel mit dem Nachprogrammieren existierender Slave-ICs inzwischen satt und arbeite gerade an meinem eigenen parametrierbaren Multifunktions-Slave ... aber das ist ein anderes Thema.

[Prof. Dr. Peter Henning]

Erstens ist das nach wie vor Pull und nicht Push. Zweitens sind Push-Events sehr viel seltener, als Pull-Events, eine optimistische Synchronisation scheint mir deshalb durchaus möglich.

LG

pah

[smurfix]

Das ist mir schon klar, dass das strenggenommen kein Push ist.

Aber ich sehe in der Praxis keinen relevanten Unterschied zwischen "frage alle 0.1sec den Bus nach Events ab" auf Master-Seite, und "warte, bis sich auf dem Bus nichts tut, und spiele dich dann mal eben zum Master auf" im Slave.

Nur ist Letzteres zu implementieren um Einiges mehr Arbeit als Code anzupassen, den es eh schon gibt. Eigene Slaves braucht es auf jeden Fall für sowas, aber ein pushender Slave braucht (a) zusätzlichen Code, um zum Pushen mal eben Master zu spielen, und (b) auch auf seiten des eigentlichen Masters etwas Eigenes. Den Aufwand zu treiben, das alles auch noch zu bauen (und zu debuggen), sähe ich nicht ein.