OWSwitch (OWServer) und on-for-timer

lars · 12 März 2013, 20:41:12

Hallo,
ich würde gerne für einen OWSwitch ein on-for-timer kommando absetzen.

Dabei erhalte ich in der Logdatei folgenden Fehler:
set OW_Switch_test1 needs two arguments

Ein Blick in die 11_OWServer.pm sagt auch aus, dass mehr als zwei Parameter nur für das
1wire Display zugelassen sind.

Der Befehl ist in der fhem reference unter OWSWITCH aber dokumentiert.
Ist das ein Bug in OWServer oder wird on-for-timer nur von der alten Variante (ohne OWServer) unterstützt?

MFG Lars

Dr. Boris Neubert · 12 März 2013, 20:46:55

Zitat von: lars schrieb am Di, 12 März 2013 20:41Hallo,
ich würde gerne für einen OWSwitch ein on-for-timer kommando absetzen.

Ein Blick in die 11_OWServer.pm sagt auch aus, dass mehr als zwei Parameter nur für das
1wire Display zugelassen sind.

Bitte nicht die beiden Modulfamilien durcheinanderbringen! Zu OWServer gehört OWDevice und sonst nichts. Die Module mit Namen nur in Großbuchstaben gehören zur anderen Familie. Und OWSwitch gibt es nicht, nur OWSWITCH.

Grüße
Boris

lars · 12 März 2013, 20:51:55

Ups,
da hab ich mich ja mal voll vertan.

Ich meinte Natürlich OWDevice

Und stimmt, da steht nix von on-for-timer

Mit OWSWITCH hab ich ja auch garnix am Hut...

Tja sowas dummes dann hab ich keine Möglichkeit mitm on-for-timer zu arbeiten.

MFG Lars

Prof. Dr. Peter Henning · 15 März 2013, 15:29:45

Aber klar geht das, und Boris Neubert hat nicht Recht.

Das Modul OWSWITCH (das on-for-timer kann...) arbeitet auch mit OWServer zusammen. Siehe dazu die Commandref von OWSWITCH.

Leider muss man dazu noch OWSWITCH manuell in das Modul OWServer unter "Clients" manuell eintragen. Frag die Maintainer von OWServer, warum das so ist.

LG

pah

lars · 16 März 2013, 10:16:11

Hallo,

das hört sich ja gut an. Ich probier das gleich mal aus.

In dieser Zeile muss ich das eintragen?
$hash->{Clients} = ":OWDevice:";

Ich frag mal ganz doof? Wie müsste die denn dann aussehen?
OWDevice sollte ja erstmal weiter funktionieren...

MFG Lars

Prof. Dr. Peter Henning · 16 März 2013, 10:57:00

$hash->{Clients} = ":OWDevice:OWAD:OWCOUNT:OWMULTI:OWSWITCH:OWTHERM:";

(die beiden anderen Module OWID und OWLCD unterstützen das derzeit noch nicht)

LG

pah

lars · 16 März 2013, 14:27:48

Hallo,
hab das gerade getestet und funktioniert. Vielen Dank

Ich hab da mal noch eine Frage. Ich habe am Raspberry einen I2C Master für 1wire und den
OWserver mit OWFS am laufen. Aus FHEM habe ich jetzt die Variante über OWSWITCH und OWDevice getestet.

Irgendwie finde ich meinen 1wire Bus ziemlich träge. Wobei gefühlt die OWDevice Variante noch schneller
läuft als die OWSWITCH Variante.

Im moment geht es mir ersteinmal nur um das setzen von Ausgängen. Später würde ich auch gerne
Tastersignale auswerten. Ist 1wire dafür überhaupt die richtige Wahl?

Ich habe auch das gefühl, dass wenn alle 60 sekunden die Temperatursensoren eingelesen werden in dem moment
alles andere garnicht mehr funktioniert...

Mal angenommen ich drücke einen Lichtschalter der über 1wire eingelesen wird dann sollte eine über 1wire
geschaltete Lampe in unter 200ms reagieren. Ist das überhaupt möglich?

MFG Lars

Prof. Dr. Peter Henning · 16 März 2013, 15:54:49

Möglich ja, aber nicht wahrscheinlich: Denn das würde bedeuten, den Taster auch alle 0,2 s auszulesen - und das ist vorsichtig gesagt, sehr gewagt. Es braucht nur ein anderes Device auf dem 1-Wire Bus aktiv zu sein, schon geht das so schnell nicht.

Dafür ist 1-Wire sicher nicht geeignet.

Das mit den unterschiedlichen Geschwindigkeiten glaube ich auch nicht: OWSWITCH ruft dieselben Programme aus OWServer auf, wie OWDevice.

LG

pah

lars · 16 März 2013, 18:15:51

Ja ok, deswegen hab ich ja auch gefühlt geschrieben...

die on-for-timer funktion ist aber schon praktisch weil ich z.b. ein Stromstossrelais triggern will...

Naja dann muss ich mir für meine Schalter und Lampen noch was überlegen müssen...

Mein Arduino der letztens angekommen ist hat dummerweise ne Lötbrücke am Prozi den muss ich erst
flicken.

Aber was ich so gesehn hab werden die Eingänge da auch nur gepollt.

Eine Frage hätte ich noch...
Kann ich irgendwie für on-for-timer auch kürzere Zeiten als eine sekunde angeben?

MFG Lars

lars · 16 März 2013, 18:39:30

Da fällt mir noch was ein...

Wenn ich einen Extra 1wire Master an den i2c hänge an den ich nur Lichtschalter und Lampensensorik
anschliesse und davon ausgehe, dass ich immer nur einen Lichtschalter betätige. Kann man sich da
ausrechnen wie die Verzögerungszeiten bei Anzahl x zu pollender Schalter wäre?

Hat 1wire keine Protokollspezifikationen, das man einen Rundruf machen kann ob sich irgendwelche Zustände geändert
haben damit man dann nur diesen einen direkt abfragen kann?

Ich hätte bezüglich solcher Möglichkeiten grosses Interesse tiefer in die Programmierung einzusteigen
stehe nur imo noch mit Perl auf Kriegsfuss.

Oder sind solche überlegungen von vorneherein zu vergessen weil die Umsetzung schlicht und einfach nicht möglich wäre?

MFG Lars

Prof. Dr. Peter Henning · 17 März 2013, 08:36:19

1. Kürzere Zeiten als 1 s sind m.E. nicht möglich, weil für die Ausführung das FHEM-Kommando "at" verwendet wird. Ich habe es aber noch nicht ausprobiert.

2. Bitte mal hier nachlesen: http://datasheets.maximintegrated.com/en/ds/DS2406.pdf

Es gibt 2 Möglichkeiten: Entweder einen kontinuierlichen Datenstrom mit dem DS2406 aufrecht erhalten - dann kann man innerhalb von Mikrosekunden erfanren, ob ein Eingang geschaltet hat. Oder einen Conditional Search Request definieren, der nur die Devices findet, die geschaltet haben.

LG

pah

ntruchsess · 17 März 2013, 11:31:59

Hallo Lars,

zur Frage nach dem 'Rundruf': ja, sowas geht. Das ist auch erheblich effizienter als alle Devices auf dem Bus einzeln nach Ihrem Status abzufragen. Nennt sich beim DS2406 im Datenblatt 'Conditional Search ROM [ECh]'. Bei anderen Devices heißt es eventuell anders, aber es ist jedesmal das 'ECh' Kommando (bei DS18B20 kann man beispielsweise die Devices abfragen, deren gemessene Temperatur außerhalb der gesetzten Schwellwerte liegt).

Im OWX ist das in der Funktion 'OWX_Alarms' implementiert, kann man mit 'get alarms' abfragen. Allerdings ist das der Natur nach immer ein Pollen des Busses, die 1-Wire-Devices können sich nicht selbsttätig melden. Und da der Bus ja von allen Devices geteilt wird und man nur jeweils 1 Device zur gleichen Zeit lesen oder schreiben kann, lassen sich kurze Reaktionszeiten nur dann gewärleisten, wenn der Buss nicht zwischendurch andersweitig belegt ist (also keine Devices dranhängen, die den Bus beim Auslesen länger als gewünscht benötigen).

Da Du den Arduino ins Spiel bringst: Der kann die Conditional-Search auch selbsttätig durchführen und auch mehrere 1-Wire Busse parallel bedienen (wobei die Bedienung der Busse auf dem Arduino selbst dann auch wieder konkuriert, allerdings mit viel kürzeren Zeitscheiben als im fhem vorgesehen). Die Unterstützung durch FRM und OWX ist hier allerdings noch verbesserungsbar - aktuell kann der Arduino sich noch nicht 'selber' beim OWX melden, sondern wird genauso wie die anderen Busmaster von OWX synchron abgefragt. Ich arbeite gerade daran, das so umzubauen, dass es auch asynchron geht - also OWX darauf reagiert, wenn der Arduino sich meldet ohne dass OWX selbst pollt.

Gruß,

Norbert

Prof. Dr. Peter Henning · 17 März 2013, 12:52:28

Jein.

Bei den aktiven Interfaces DS2480 etc. ist ein Feature eingebaut, bei dem jeder Bus-Reset feststellt, ob es "alarmed" devices gibt. Das wird bisher in OWX zwar getestet, dann aber ignoriert. Ein Bus Reset ist kein Polling in dem Sinn - den kann man wesentlich öfter machen, als 1x pro Sekunde.

Dann müsste allerdings eine Suche nach dem alarmierten Device erfolgen.

LG

pah

ntruchsess · 17 März 2013, 16:23:56

ja, das habe ich schon gesehen, dass OWX_Reset das Alarmed-flag nicht weiter auswertet. Sollte man vieleicht nicht unmittelbar, sondern mit updateReading setzen um darauf reagieren zu können.

Wenn ich 'pollen' schreibe will ich damit eigentlich nur ausdrücken, dass ein Informationsfluss vom 1-Wire-gerät zum Busmaster grundsätzlich nur dann stattfindet, wenn er vom BusMaster initiiert wird also ein 1-Wire-gerät nichts triggern kann ohne dass der BusMaster aktiv nachschaut. In dem Sinne nenne ich auch das Testen der Interrupt-condition beim Reset durch einen DS2480 'polling'.

Ist ja wohl auch der primäre Grund, warum 1-Wire in FHEM nicht über den fhem-main-loop + select-function implementiert ist.

Gruß,

Norbert

ntruchsess · 19 März 2013, 09:35:57

Ich hab mir das mit dem 'Alarmed Signaling' beim Reset mal genauer angeschaut, das braucht man wohl nicht weiter verfolgen. Laut Application-note AN244 von Maxim gibt wohl sowieso nur 2 1-Wire-chips, die das überhaupt unterstützen (DS1994 und DS2404), beide sind abgekündigt und können timergeteuerte Interrups generieren. Für die Nachfolger ist das Feature schon nicht mehr dokumentiert. Sensoren oder Switches die Interrupts auf dem 1Wire-bus beim Reset erzeugen würden habe ich nicht finden können. Die unterstützen alle nur regelmäßiges Abfragen des Busses mit Conditional Search (ECh).

Gruß,

Norbert