OneWire.lib (insbesondere RS232 Behandlung)

[rennsemmel]

Hallo, wie im Thread (siehe Link:https://knx-user-forum.de/eibpc/1096...-eibpc-14.html) angekündigt hier meine Fragen zur Behandlung der RS232 und Details zur EnertexOneWire.lib


1a) In der enertexonewire.lib wird die Zeile "if event(readrs232(NameD_rawdata,NameD_Len)) and (ROMID==HA_Device)... " verwendet.
Könnt Ihr mir erklären, wie das readrs232 bzw der RS232 Puffer behandelt wird?
Werden die Daten in jedem Fall ausgelesen, sobald das event getriggert wird - Also neue Daten im Buffer der RS232 liegen? Oder muss die "and" Bedingung erfüllt sein? Meint: Bewirkt hier das "and", dass readrs232 nicht ausgeführt wird und der RS232 Buffer geleert wird?

1b)Was passiert, wenn vom HA7E noch gesendet wird und noch nicht alle Daten empfangen sind? Werden die Daten dann nur teilweise ausgelesen?

1c) Was passiert, nachdem der erste Befehl zum ha7e gesendet wurde, danach das Lesen des ersten Sensors erfolgt, und dann nichts im RS232 Buffer empfangen wurde. Liest dann bereits der 2te Sensor der die Funktion "Temperature(NameD, ROMID,Minute)" aufruft, die Daten des ersten Sensors und wenn ja, sind dann die Daten weg für den ersten Sensor?
(Aber dann müsste mann damit rechnen, dass es deutlich weniger oft funktioniert oder?)

Kurz, ich habe mich gefragt: Wieso kommt die Rückantwort vom seriellen Buffer immer an der richtigen Sensorabfrageschleife an , wenn bei jedem eibPC-Zyklus alle Sensoren sofort nacheinander mit (if event(readrs232(NameD_rawdata,NameD_Len)) and (ROMID==HA_Device)..." abgefragt werden?


2) Warum wurde eine Zeit von 2 min gewählt? Jeder Sensor benötigt ca 20 sec im parasitären Betrieb. Oder hängt das mit der ersten Frage zusammen:
Warum wurde die Funktion random eingebunden und wass passiert, wenn werte dicht beieinander liegen?

3)Um mehr als 20 Sensoren abzufragen, reicht es aus bei der "HA_Queue=$$" z.B. eine 5000 hinter zu schreiben oder ist hier mehr zu beachten? Klar ist, dass die Abfrage-Zeiten dann bei der enertexOneWire.lib lange werden.

4) Bleibt die Que auf einer Größe von 5000 Zeichen, wenn mann später im Code nur "HA_Queue = $$" setzt oder sollte hier wieder eine $$5000 gesetzt werden?

[saft6luck]

Da traut sich wohl keiner

Dann mach ich mal den Anfang
Aus dem, was in der Anleitung steht, wie die Beispiele aufgebaut sind und was ich im Forum gelernt habe, folgere ich:

1a) In der enertexonewire.lib wird die Zeile "if event(readrs232(NameD_rawdata,NameD_Len)) and (ROMID==HA_Device)... " verwendet.
Könnt Ihr mir erklären, wie das readrs232 bzw der RS232 Puffer behandelt wird?
Werden die Daten in jedem Fall ausgelesen, sobald das event getriggert wird - Also neue Daten im Buffer der RS232 liegen? Oder muss die "and" Bedingung erfüllt sein? Meint: Bewirkt hier das "and", dass readrs232 nicht ausgeführt wird und der RS232 Buffer geleert wird?

- der Puffer wird zyklisch ergänzt mit den neu empfangenen Daten -> den Puffer muss man umkopieren und man sollte ihn dann löschen (bzw. den Teil, der einen interessiert weg schneiden), damit nicht altes Zeugs drinnen steht
- immer wenn neue Daten vorhanden sind, wird der event ausgelöst. Das AND verhindert nur die Bearbeitung des Events.
- ob die Daten dann schon in den Puffer des Makros geschrieben werden oder nicht ist eigentlich nur für die Ausführungsgeschwindigkeit interessant. Vermutlich werden sie bereits kopiert. Da die Daten ja nicht gelöscht werden, wirkt sich dies aber so oder so nicht aus (wenn man den temporären Puffer wie gefordert verwendet). Man könnte da ja einen Test machen (z.B. 10 Sensoren anlegen, die alle 5 Minuten auslesen und die temporären Puffer beobachten).

1b)Was passiert, wenn vom HA7E noch gesendet wird und noch nicht alle Daten empfangen sind? Werden die Daten dann nur teilweise ausgelesen?

Ist das eine OneWire spezifische Frage, dann weiß ich es nicht (vermutlich Arbitrierung oder Kollision, evtl. dann mit Retry) oder eibPC spezifisch?
- die Events vom ReadRS232() können schon während des Empfanges auftreten, vor allem bei längeren Übertragungen. OneWire scheint wohl kurze Telegramme zu schicken, die überwiegend "am Stück" empfangen werden. Richtig macht man es, wenn man die Länge prüft und dann auf evtl. noch fehlende Daten wartet.

1c) Was passiert, nachdem der erste Befehl zum ha7e gesendet wurde, danach das Lesen des ersten Sensors erfolgt, und dann nichts im RS232 Buffer empfangen wurde. Liest dann bereits der 2te Sensor der die Funktion "Temperature(NameD, ROMID,Minute)" aufruft, die Daten des ersten Sensors und wenn ja, sind dann die Daten weg für den ersten Sensor?
(Aber dann müsste mann damit rechnen, dass es deutlich weniger oft funktioniert oder?)

Kurz, ich habe mich gefragt: Wieso kommt die Rückantwort vom seriellen Buffer immer an der richtigen Sensorabfrageschleife an , wenn bei jedem eibPC-Zyklus alle Sensoren sofort nacheinander mit (if event(readrs232(NameD_rawdata,NameD_Len)) and (ROMID==HA_Device)..." abgefragt werden?

2) Warum wurde eine Zeit von 2 min gewählt? Jeder Sensor benötigt ca 20 sec im parasitären Betrieb. Oder hängt das mit der ersten Frage zusammen:
Warum wurde die Funktion random eingebunden und wass passiert, wenn werte dicht beieinander liegen?

- der Event wird bei allen readrs232() erzeugt

Ich kenne die Lib nicht (will sagen: hab grad keine Zeit da rein zu schauen ) und würde daher vermuten, dass der restliche Code dafür sorgen muss, das der Inhalt passt.
Hab doch einen Blick gewagt -> ist dann wohl eher Zufall. So wie ich das seht steht das aktuelle Gerät in einer globalen Variablen. Dieses wird aus dem aktuellen Kommando gesetzt. Wenn die Kommandos zu schnell gesendet werden, wird offensichtlich das falsche Modul aktiv geschaltet -> zufällig funktioniert es bzw. die Zeiten müssen passen. Es scheint auch keine weitere Prüfung vorhanden zu sein -> Evtl. enthält die Antwort keine GeräteID?

3)Um mehr als 20 Sensoren abzufragen, reicht es aus bei der "HA_Queue=$$" z.B. eine 5000 hinter zu schreiben oder ist hier mehr zu beachten? Klar ist, dass die Abfrage-Zeiten dann bei der enertexOneWire.lib lange werden.

4) Bleibt die Que auf einer Größe von 5000 Zeichen, wenn mann später im Code nur "HA_Queue = $$" setzt oder sollte hier wieder eine $$5000 gesetzt werden?

Der Typ von HA_Queue ändert sich nicht. Wenn der Kompiler das akzeptiert ist es ok. Die Verkettung max. die Länge des längsten verwendeten Strings, dann wird auf die Länge des Zielstrings gekürzt, falls nötig.

[rennsemmel]

Hi Danke schon mal.

- der Puffer wird zyklisch ergänzt...
...- immer wenn neue Daten vorhanden sind, wird der event ausgelöst.

soweit verstanden. aber ich bin mir nicht sicher ob ich das richtig verstehe. Auf der einen Seite lese ich:

Das AND verhindert nur die Bearbeitung des Events.

Ich denke eher das AND verhindert nur den Aufruf der if Anweisung, denn auf der anderen Seite lese ich:

Vermutlich werden sie bereits kopiert. Da die Daten ja nicht gelöscht werden, wirkt sich dies aber so oder so nicht aus (wenn man den temporären Puffer wie gefordert verwendet). Man könnte da ja einen Test machen (z.B. 10 Sensoren anlegen, die alle 5 Minuten auslesen und die temporären Puffer beobachten).

Mir ist nicht klar, ob Du mit Puffer die Variable im Makro meinst oder den Puffer im RS232 - worauf ich vermute wir keinen direkten Zugrif haben.
Mein Verständis:
Der RS232 Puffer wird mit dem Befehl "readrs232(NameD_rawdata,NameD_Len)" in die Variable "NameD_rawdata" geschrieben.
Da es aber nur einen RS232 Puffer gibt, jedoch multible NameD_rawdata variablen geben kann (in der Anzahl wie oft das Makro aufgerufen wird) daher ist es aus meiner Sicht wichtig zu wissen ob der Puffer der RS232 beim nächsten Aufruf eines Makros bereits leer/gelöscht ist oder nicht.

...Richtig macht man es, wenn man die Länge prüft und dann auf evtl. noch fehlende Daten wartet.

OK das beantwortet die Frage.

...> zufällig funktioniert es bzw. die Zeiten müssen passen....

OK Danke, das bestätigt meine Annahme.

Der Typ von HA_Queue ändert sich nicht. Wenn der Kompiler das akzeptiert ist es ok. Die Verkettung max. die Länge des längsten verwendeten Strings, dann wird auf die Länge des Zielstrings gekürzt, falls nötig.

Klasse Danke für die schnellen Antworten.

[saft6luck]

Ich denke eher das AND verhindert nur den Aufruf der if Anweisung, denn auf der anderen Seite lese ich:

So kannst du es auch schreiben.

Ich unterscheide hier nur:
- Event auslösen = in diesem einen Durchlauf tritt der Event auf
- Event be- oder verarbeiten = den Event beachten und eine Aktion davon ableiten

Mir ist nicht klar, ob Du mit Puffer die Variable im Makro meinst oder den Puffer im RS232 - worauf ich vermute wir keinen direkten Zugrif haben.
Mein Verständis:
Der RS232 Puffer wird mit dem Befehl "readrs232(NameD_rawdata,NameD_Len)" in die Variable "NameD_rawdata" geschrieben.
Da es aber nur einen RS232 Puffer gibt, jedoch multible NameD_rawdata variablen geben kann (in der Anzahl wie oft das Makro aufgerufen wird) daher ist es aus meiner Sicht wichtig zu wissen ob der Puffer der RS232 beim nächsten Aufruf eines Makros bereits leer/gelöscht ist oder nicht.

Es geht um den Puffer von ReadRS232(), der für dich sichtbar ist, also NameD_rawdata. Da hat zwar jeder Sensor seinen eigenen, die empfangen aber alle die selben Daten. Und der Inhalt wird nicht automatisch gelöscht. Durch setzen des Parameters "Len" kann der Inhalt gelöscht werden.

"Je nach Konfiguration der RS232-Schnittstelle (Baudrate) können pro Verarbeitungsschleife mehr als
ein Zeichen in den Puffer des Enertex® EibPC auflaufen. Die Länge des aktuellen Puffer kann mit
dem 2. Argument erfragt werden. Wenn die Funktion im Anwenderprogramm verarbeitet wird (s.u.),
so muss dieses Argument zurückgesetzt werden."

Wird der Event bearbeitet, muss der Inhalt gelöscht werden.

Ob das LEN von einem ReadRS232() auch alle anderen LEN auf 0 setzt weiß ich nicht. -> siehe hierzu Testvorschlag von vorher.

"● Von der asynchronen seriellen Schnittstelle empfangene Daten (maximale Länge: 1400B)
werden in das Zielobjekt RawData geschrieben, beginnend an der in Len definierten Position.
Abschließend wird die Position um die Anzahl der angefügten Bytes entsprechend erhöht.
Das Zielobjekt ist i. a. nicht terminiert.
● Wenn ein RS232 Telegramm an den Enertex® EibPC geschickt wird, aktualisiert jede
Funktion readrs232 ihr Argumente in der angegebenen Weise.

Die Sache mit den geklonten Puffern finde ich im Makro etwas seltsam: Da wird erst der Teil rausgeschnitten, der verarbeitet wird
und dann wird LEN auf 0 gesetzt. Somit ist der Puffer leer -> warum dann erst den empfangenen Teil herausschneiden???

[highlight=epc]
if event(readrs232(NameD_rawdata,NameD_Len)) and (ROMID==HA_Device) then {
NameD_Buffer=split(NameD_rawdata,0u16,NameD_Len);
NameD_rawdata=split(NameD_rawdata,NameD_Len+1u16,E OS);
...
NameD_Len = 0u16
} endif
[/highlight]

NameD_Len wird aber nur für dieses Makro auf 0 gesetzt -> was passiert mit den anderen Puffern?
Ist dann aber auch wieder egal, denn jedes Makro nimmt nur den vorderen Teil und verwirft den Rest (welcher Rest ist das eigentlich?).
Da in einen Durchlauf (Zyklus) nur ein Sensor aktiv ist (HA_Device) kann auch kein anderes if den Puffer weiter bearbeiten
-> erst mit dem nächsten Empfang geht es weiter -> dann hätte man auch immer die gleiche Puffervariable verwenden können.

IMHO würde es Sinn machen, den Empfang komplett zu überarbeiten und zentral zu erschlagen.

[rennsemmel]

Dies ist mein dtitter Versuch zu deiner letzten Antwort zu Antworten. Ich sitze hier wie jemand dem ständig ein Licht aufgeht und dann doch wieder mit Fragezeichen da sitzt.

Ich habe die Antwort auf meine Frage noch nicht gefunden. Vieleicht ein Brett vorm Kopf. Stattdessen kommen neue Fragen zur RS232 auf.

Rufe ich "readrs232(rawdata, Len)" mehrfach auf ohne Len auf "0" zu setzen, so wird rawdata immer weiter mit Daten gefüllt, insofern weitere Daten an der RS232 RX ankommen.
Sobald ich Len auf "0" setze, wird beim nächsten Aufruf der (für uns nicht Sichtbare Teil des RS232 Puffers) "geleert" (Ich nehme an irgend ein Pointer wird zurück gesetzt)?
Wenn nicht, dann würde ich ja immer wieder die gleichen alten Daten auslesen.

Wenn also der RS232 Puffer "geleert" wurde, weil die Variable NameD_Len auf 0 gesetzt wurde, bewirkt der nächste Aufruf in einem anderen Makro readrs232 (inhalt,laenge), dass Inhalt nur die neu angekommenen Daten im RS232 Puffer enthält.

Richtig verstanden?

Bleibt noch die ursprüngliche Frage, ob in der Zeile "if event(readrs232(NameD_rawdata,NameD_Len)) and (ROMID==HA_Device)... " das readrs232() ausgeführt wird und wenn NameD_Len = 0 ist der RS232 Puffer "geleert"?
Denn bei jedem Aufruf des Makros temperature () wird NameD_Len auf 0 gesetzt.

...
NameD_Len wird aber nur für dieses Makro auf 0 gesetzt -> was passiert mit den anderen Puffern?
Ist dann aber auch wieder egal, denn jedes Makro nimmt nur den vorderen Teil und verwirft den Rest (welcher Rest ist das eigentlich?).
Da in einen Durchlauf (Zyklus) nur ein Sensor aktiv ist (HA_Device) kann auch kein anderes if den Puffer weiter bearbeiten
-> erst mit dem nächsten Empfang geht es weiter -> dann hätte man auch immer die gleiche Puffervariable verwenden können.

IMHO würde es Sinn machen, den Empfang komplett zu überarbeiten und zentral zu erschlagen.

Ich denke, damit bestätigst Du die Berechtigung meiner Fragen/Bedenken zur enertexOnewire.lib. Der Betrieb mit mehreren Sensoren wird nur zufällig funktionieren. Die bmxha7e15a-e.lib geht hier anders vor. Der Empfang erfolgt wie von Dir vorgeschlagen Zentral.

Kann natürlich auch sein, dass es mit der enertexOneWire.lib wie mit der Hummel ist, die rein physikalisch gar nicht fliegen kann.

[enertegus]

Die Sache mit den geklonten Puffern finde ich im Makro etwas seltsam: Da wird erst der Teil rausgeschnitten, der verarbeitet wird
und dann wird LEN auf 0 gesetzt. Somit ist der Puffer leer -> warum dann erst den empfangenen Teil herausschneiden???

Ich habe zwar das Makro nicht gemacht, denke aber dass hier die Dokumentation im Handbuch irgendetwie zum Code nicht passt. Kann sein, dass da der Hund begraben liegt. Muss ich mal nächste Woche genauer nachfragen.

[saft6luck]

Rufe ich "readrs232(rawdata, Len)" mehrfach auf ohne Len auf "0" zu setzen, so wird rawdata immer weiter mit Daten gefüllt, insofern weitere Daten an der RS232 RX ankommen.
Sobald ich Len auf "0" setze, wird beim nächsten Aufruf der (für uns nicht Sichtbare Teil des RS232 Puffers) "geleert" (Ich nehme an irgend ein Pointer wird zurück gesetzt)?

LEN gibt an, wo die Daten in rawdata geschrieben werden. Somit wird dann rawdata gelöscht (überschrieben).

Wenn nicht, dann würde ich ja immer wieder die gleichen alten Daten auslesen.

Genau das passiert, man liest rawdata und erhält kontinuierlich mehr Daten (Empfang vorausgesetzt). Erst wenn man LEN ändert, ändert man die Schreibposition.

Wenn also der RS232 Puffer "geleert" wurde, weil die Variable NameD_Len auf 0 gesetzt wurde, bewirkt der nächste Aufruf in einem anderen Makro readrs232 (inhalt,laenge), dass Inhalt nur die neu angekommenen Daten im RS232 Puffer enthält.

Richtig verstanden?

Ich würde da vorsichtig mit "ja" antworten wollen Es geht aber nicht um den Internen Puffer, sondern nur um rawdata.

Bleibt noch die ursprüngliche Frage, ob in der Zeile "if event(readrs232(NameD_rawdata,NameD_Len)) and (ROMID==HA_Device)... " das readrs232() ausgeführt wird und wenn NameD_Len = 0 ist der RS232 Puffer "geleert"?
Denn bei jedem Aufruf des Makros temperature () wird NameD_Len auf 0 gesetzt.

Du hast doch den Code und kannst dir die ganzen rawdata-Puffer anschauen. Frag einen Sensor ab und schau dir die Puffer an. Wenn alle die Daten enthalten ist die Antwort klar.

Für mein Verständnis sind es alles Zwischenpuffer, die vom Hintergrunddienst der RS232 gefüllt werden. Das Kommando ReadRS232() dient der Konfiguration der Puffer und der Event drum herum wird vor jedem Zyklus gesetzt wenn der Hintergrunddienst neue Daten in den Puffer geschrieben hat. Die Daten schreibt er an Position LEN.

Kann natürlich auch sein, dass es mit der enertexOneWire.lib wie mit der Hummel ist, die rein physikalisch gar nicht fliegen kann.

Der Vergleich ist immer wieder schön

[rennsemmel]

Danke Dir. Das bestätigt weitestgehend meine Annahmen.

Du hast doch den Code und kannst dir die ganzen rawdata-Puffer anschauen. Frag einen Sensor ab und schau dir die Puffer an. Wenn alle die Daten enthalten ist die Antwort klar.

Hmm... Um hier eine gesicherte Antwort zu erhalten, denke ich benötige ich mehr Aufwand. Ich muss wissen wann und ob Daten an die RS232 gesendet wurden. ...15 min später... Könnte vieleicht auch mit dem HA7E zu beweisen sein. Muss ich mir nochmal Durch den Kopf gehen lassen, falls es nicht vom Enetex Team beantwortet werden kann.

Zudem läuft gerade ein Langzeittest, ob sich die RS232 automatisch zurücksetzen lässt, wenn sie eingefroren ist. Zwischenbilanz: nach Tag 7 ist sie noch nicht eingefroren. Zuvor war sie eingefroren nach nach Tag 3 und 5.


@Energetus
Habt Ihr noch etwas herausfinden können?

Könnt Ihr die Frage abschließend beantworten:
"ob in der Zeile "if event(readrs232(NameD_rawdata,NameD_Len)) and (ROMID==HA_Device)... " das readrs232() ausgeführt wird" wenn neue Daten anliegen.
Da Len beim nächsten Temperatursensor auf 0 gesetzt wird, sind diese Daten dann wohl weg, weil die Daten innerhalb der if schleife nicht genutzt wurden.

[enertegus]

@Energetus
Habt Ihr noch etwas herausfinden können?

Noch nicht. Wir werden das aber sicher noch nachholen.

[enertegus]

Die Sache mit den geklonten Puffern finde ich im Makro etwas seltsam: Da wird erst der Teil rausgeschnitten, der verarbeitet wird
und dann wird LEN auf 0 gesetzt.

Das ist gemacht, um beim nächsten Durchlauf den Eingangspuffer von vorne zu füllen.
Was mir an den Makro an sicht nicht gefällt ist, dass für jeden Sensor ein readrs232-genutzt wird. Das war ursprünglich nicht so.

IMHO würde es Sinn machen, den Empfang komplett zu überarbeiten und zentral zu erschlagen.

Volle Zustimmung.

Wenn also der RS232 Puffer "geleert" wurde, weil die Variable NameD_Len auf 0 gesetzt wurde, bewirkt der nächste Aufruf in einem anderen Makro readrs232 (inhalt,laenge), dass Inhalt nur die neu angekommenen Daten im RS232 Puffer enthält.

Möglicherweise liegt hier der Hund begraben, da die "laenge" nicht zurückgesetzt wird. Ich bin mir sicher, dass dies ursprünglich mal anders war. Wir müssen also nicht die rs232 anschauen, sondern das Makro.

[enertegus]

So ich hab das mal eben umgecodet:
EDIT: gelöscht: Steffis Code (s.u.) nutzen.
Nun triggert die Variable HA_read das Auswerten des Eingangspuffers HA_read.

[saft6luck]

So ich hab das mal eben umgecodet:

Ist das getestet?

Ich frage, weil du auf mindestens 14 bytes wartest, die eigentliche Antwort aber 10 bytes -> 20 Zeichen hat. Wenn nun weitere Inhalte in der Antwort stehen wird die Abfrage auf das Scratchpad so nicht passen, oder?

[SteffiEnertex]

angepasst und getestet
- inkl. rs232reset, wenn sich ein Sensor 60 Minuten lang nicht meldet

// Init HA7E
// @date    11.01.2012
// @version    2 
// @author    Enertex Bayern GmbH
:begin HA7E()
:info $Bindet den HA7E Adapter ein$\\
    
:shortinfo $Bindet den HA7E Adapter ein$

// if you want to observe the actions please comment #undef DEBUG like this //#undef DEBUG
#define DEBUG 
#undef DEBUG
HA_Debug = ON
//Debug-Address
dummy = '9/9/9'c14
//Command-Queue
HA_Queue=$$
//One Command
HA_Command=$$
HA_Next=AUS
HA_Split=$;$
//Gap between two commands
HA_Gap = 400u64
HA_Device = $$
CarriageReturn = 13u08
HA_rawdata=$$ 
HA_Data=$$ 
HA_Len=0u16
HA_read=AUS
//Next Message
if change(HA_Next) then {
    if HA_Queue==$$ then HA_Command=$$ endif;
    if HA_Queue!=$$ then {
        HA_Command=split(HA_Queue,0u16,find(HA_Queue,HA_Split,0u16) - 1u16);
        HA_Queue=split(HA_Queue,find(HA_Queue,HA_Split,0u16)+1u16,END)
    } endif
} endif

//Is it an address command?
if split(HA_Command,0u16,0u16) == $A$ then HA_Device = split(HA_Command,1u16,END) endif

//Sending the Command
if after(change(HA_Next), HA_Gap) and HA_Command != $$ then {
    sendrs232(HA_Command, CarriageReturn);
    #ifdef DEBUG
    if HA_Debug then write('9/9/9'c14, $S:$c14+convert(HA_Command, $$c14)) endif;
    #endif 
    /*Is it the Command to convert the temperature?*/;
    if HA_Command == $W0144$ then HA_Gap = 750u64 else HA_Gap = 400u64 endif; 
    // neglect all recieved messages before
    HA_Len=0u16;
    HA_Next=!HA_Next;

} endif

if event(readrs232(HA_rawdata,HA_Len)) then {
    // ROM answer
    if (HA_Len==21u16) then HA_read =!HA_read endif;
 } endif

// if nothing happens, reset the HA7E after 60 Minutes
if delay(change(HA_read),3600000u64) then resetrs232() endif 

:end


//Family Code 10, DS18B20 Family Code 28
// @date    11.01.2012
// @version    2 
// @author    Enertex Bayern GmbH
:begin Temperature(NameD, ROMID,Minute)
:info $Liest zyklisch die Temperatur eines Sensors(DS18S20 oder DS18B20) am OneWire aus und speichert die Temperatur in der Variable NameD_Temperature als f16 Wert. Das Makro HA7E muss eingebunden sein.$\\
    $Name des Sensors$\\
    $ROM-ID des Sensors$\\
    $Gibt an in welchem Abstand der Wert aktualisiert wird, in Minuten$
:shortinfo $Liest zyklisch die Temperatur eines Sensors$
//Default-Value(e.g. important for webcharts)
NameD_TemperatureRead=100.0f16
NameD_Temperature=100.0f16
NameD_Message=$$
NameD_Buffer=$$
NameD_CR = 0f16
NameD_CP = 0f16
NameD_DS18S20 = OFF
NameD_DS18B20 = OFF
//Debug-Address

//Sequence to read temperature
if after(cycle(Minute,0),convert(random(240u32),0u64)) then {
    HA_Queue=HA_Queue + $R$ + HA_Split;
    HA_Queue=HA_Queue + $A$ + ROMID + HA_Split;    
    HA_Queue=HA_Queue + $W0144$ + HA_Split;
    HA_Queue=HA_Queue + $R$ + HA_Split;
    HA_Queue=HA_Queue + $A$ + ROMID + HA_Split;
    HA_Queue=HA_Queue + $W0ABEFFFFFFFFFFFFFFFFFF$ + HA_Split;
    HA_Next=!HA_Next;
} endif

//if change(HA_Next) then write('9/9/9'c14,$next: $c14 + convert(HA_Next,$$c14)) endif

//DS18B20 or DS18S20?
if split(ROMID,14u16,15u16) == $10$ then NameD_DS18S20 = ON endif
if split(ROMID,14u16,15u16) == $28$ then NameD_DS18B20 = ON endif

//News from this sensor
if change(HA_read) and (ROMID==HA_Device)  then {
    NameD_Buffer=split(HA_rawdata,0u16,HA_Len);
    /*Is it the Scratchpad?*/;
    if split(NameD_Buffer,0u16,1u16) == $BE$ then {
//    write('9/9/9'c14,$B2:$c14 + convert(NameD_Buffer,$$c14));
         /* Hier werden ungueltige Daten abgefangen*/;
        if split(NameD_Buffer,2u16,10u16) != $FFFFFFFFF$ then {
            NameD_TemperatureRead = convert(convert($0x$+split(NameD_Buffer,4u16,5u16) + split(NameD_Buffer,2u16,3u16),0s16),0f16) / 2.0;
            #ifdef DEBUG
            if HA_Debug then {
                write('9/9/9'c14,$TR:$c14 + convert(NameD_TemperatureRead,$$c14))
            } endif;
            #endif 
            /*DS18S20?*/;
            if NameD_TemperatureRead >= -55f16 and NameD_TemperatureRead <= 125f16 and NameD_DS18S20 then {
                NameD_CR = convert(convert($0x$ + split(NameD_Buffer,14u16,15u16),0s16),0f16);
                NameD_CP = convert(convert($0x$ + split(NameD_Buffer,16u16,17u16),0s16),0f16);
                NameD_Temperature = NameD_TemperatureRead - 0.25 + (NameD_CP - NameD_CR) / NameD_CP
            } endif;
            /*DS18B20?*/;
            if NameD_TemperatureRead > -440f16 and NameD_TemperatureRead < 1000f16 and NameD_DS18B20 then {
                NameD_Temperature = NameD_TemperatureRead / 8.0
            } endif
        } endif
    } endif;
    #ifdef DEBUG
    if HA_Debug then {
        write('9/9/9'c14,convert($R:$ + NameD_Buffer,$$c14));
        write('9/9/9'c14,convert(Minute,$$c14)+$:T:$c14 + convert(NameD_Temperature,$$c14))
    } endif;
    #endif 
    HA_Len=0u16;
} endif
:end

[rennsemmel]

angepasst und getestet
- inkl. rs232reset, wenn sich ein Sensor 60 Minuten lang nicht meldet

Ein verspätetes Danke. Code läuft seit 10 min bei mir unter der Firmware 3.012. (Der Code von Energetus weiter oben läuft nicht. Werte bleiben auf 100°C stehen.)

Was bisher geschah:
Nach dem Update auf 3.010 lief die BMX15a über 4 Wochen problemlos. Der eibPC lief ununterbrochen. Dann das Einfrieren der Werte. Ein über eine verknüpfte GA ferngesteuertes resetRS232() brachte keinen Erfolg.
Seiteneffekt: Variablen waren während dem Einfrieren nur noch verschoben über den Debugger zugreifbar. Auch den Code zurück zu laden half nicht. (siehe mein Tread Variablen verschoben)
Nur den eibPC komplett von der Spannung trennen half.

Dann hab ich auf die Firmware 3.012 geupdated. Seither greift die resetRS232() ca 3-4 mal pro Tag! Soll heißen die Werte frieren für ca 1h ein, danach wird automatisch die resetRS232() Funktion ausgeführt.

Dann habe ich die BMX15a gegen die enertexOneWire.lib getauscht. Selbiges Verhalten: 3-4 mal pro Tag frieren die Werte ein.

Wie o.g. seit 10 min läuft nun Dein Code...

Ich nehme an, dass das auch bei dem von Dir geposteten Code pasieren wird. Werde aber voraussichtlich morgen berichten.

Meine Fragen hier:
1) Kann ich auf die 3.010 zurück?
2) Sind RS232/HA7E Schnittstellenprobleme bekannt mit der 3.012?

3) An alle: Könnt Ihr mir eine kostengünstige aber ROBUSTE Alternative empfehlen bezüglich Temperaturwerterfassung von onewire auf KNX? z.B. raspberry; Wiregate...?

[enertegus]

Meine Fragen hier:
1) Kann ich auf die 3.010 zurück?
2) Sind RS232/HA7E Schnittstellenprobleme bekannt mit der 3.012?

Du kannst den Delay-Wert reduzieren, sodass Du einen Aussetzer erst gar nicht mehr mitbekommst. Ich denke, dass man bei 1-Wire mindestens mit diesen Fehlern ab einer bestimmten Größe (Kabellänge, Umgebung ...) rechnen muss - zumindest hat man mir das mal so erzählt - , je ausgedehnter der Netz ist, desto mehr ist das der Fall.
Die FW wurde jedenfalls an dieser Stelle gar nicht geändert. Vermutlich war das Wetter und die Feuchtigkeit in den 4 Wochen davor etwas anders, sodass eben der Fehler auf dem 1-Wire nicht aufgetreten ist.