Ankündigung

**enertegus** · 22.02.2014, 17:53

Zitat von kirekey Beitrag anzeigen

Ich möchte mit dem EibPC einen 1-wire Temperaturwert per Wiregate IP-Extender erfassen. Dafür gibt es "eine" Makrobibliothek EnertexOneWire.lib und das Makro OWextender. Soweit so gut, aber dann geht es auch schon los.

Grundsätzlich pflegt die Steffi die Makros und wird sich sicher am Montag hierzu äußern.
Was den IPExtender von Elabnet angeht, ist der leider auch eingestellt. Gerade mit dem Teil berichteten Kunden mit dem EibPC immer wieder Probleme, obwohl wir das in unserem Testaufbau nie nachvollziehen haben können.
Was das Versionieren betrifft, werde ich das klären.

Wird das bei anderen Makros genauso ablaufen oder habe ich gleich im ersten Versuch das mit Abstand schlimmste Beispiel erwischt?

Ich kenne in der Makrosammlung mit den mittlerweile über 1100 Makros nicht jedes einzeln, aber zumindest was den IPExtender betrifft, wirst Du leider recht haben. Wir werden diese Makros auf "obsolet" stellen.

**kirekey** · 22.02.2014, 21:37

Zitat von enertegus Beitrag anzeigen

Wir werden diese Makros auf "obsolet" stellen.

Das ist natürlich auch eine Methode, sich eines Problems zu entledigen, wenn auch nicht gerade die kundenfreundlichste.

Um den Schwarzen Peter nicht weiterhin zum IPE schieben zu können, habe ich jetzt mal ein Shell Script geschrieben welches auf beliebiger Hardware ausgeführt werden kann. Es liefert einen statischen Temperaturwert von 33,33 in dem vom Makro erwarteten Format.

Code:

#!/bin/sh

echo Content-Type: text/plain
echo
#sleep 1
echo '2840B6AA040000/temperature'
echo '33.33'

In der dargestellten Form des Scripts erkennt der EibPC bei jeder Anfrage den Wert und gibt ihn korrekt als Debugmeldung aus. Sobald ich aber das Sleep-Kommando auskommentiere und zwischen Anfrage und Antwort 1 Sekunde vergeht, zeigt mir der EibPC wieder nur noch "invalid telegr" Meldungen an. Damit ist meine erste Vermutung eigentlich zweifelsfrei bewiesen und das Problem liegt keinesfalls am IPE sondern am tcpsend bzw. tcpread.

Zitat von enertegus Beitrag anzeigen

Grundsätzlich pflegt die Steffi die Makros und wird sich sicher am Montag hierzu äußern.

Ich würde mich wirklich sehr freuen, wenn sich Steffi dem Problem nochmal unvoreingenommen annimmt, ohne gleich die Schuld auf den sonst gut funktionierenden IPE zu schieben. Da ich parallel auch den "Patch-Thread" mitlese, würde ich nicht ausschließen, dass das Problem mit der neuen Firmware zusammenhängt. Die Alte habe ich nie getestet und kann es ohne entsprechende Hardware auch nicht. Für euch sollte das aber kein Problem sein.

Grüße
Erik

**kirekey** · 22.02.2014, 23:27

Noch ein kurzer Nachtrag. Ich habe den EibPC ein paar Stunden laufen lassen und mir die Telegramme eben angesehen. Dabei ist mir aufgefallen, dass ab und zu (ca. alle 20 bis 50 Anfragen), der Temperaturwert 0.00 angezeigt wird. In diesen Fällen ist die Gesamtlänge der Antwort 136 statt der sonst üblichen 141 Byte lang. Es fehlen also genau die 5 Byte vom Temperaturwert 33.33 bzw. die zweite Zeile der Antwort. Das Problem kann demnach nicht das Makro sein, denn dieses würde in Verbindung mit dem statischen Script deterministische Werte liefern. Wahrscheinlich ist in diesen Fällen die Antwort des Servers minimal später eingetroffen als sonst. Mit einem sleep im Millisekunden-Bereich kann man die Schwelle zwischen geht und geht nicht evtl. herausfinden. Die Frage bleibt aber, warum eine leicht verzögerte Antwort überhaupt zu fehlenden Daten führt...

Code:

% 2014-02-22 23:12:00 | Sender: EibPC | GA: '1/1/1'c14 | Wert: send: 2840B6AA | Typ: Text |  Schreiben
% 2014-02-22 23:12:00 | Sender: EibPC | GA: '1/1/1'c14 | Wert: read: 2840B6AA | Typ: Text |  Schreiben
% 2014-02-22 23:12:00 | Sender: EibPC | GA: '1/1/1'c14 | Wert: DevStart: 96 | Typ: Text |  Schreiben
% 2014-02-22 23:12:00 | Sender: EibPC | GA: '1/1/1'c14 | Wert: M-size: 141 | Typ: Text |  Schreiben
% 2014-02-22 23:12:00 | Sender: EibPC | GA: '1/1/1'c14 | Wert: result: 96 | Typ: Text |  Schreiben
% 2014-02-22 23:12:00 | Sender: EibPC | GA: '1/1/1'c14 | Wert: pos: 128 | Typ: Text |  Schreiben
% 2014-02-22 23:12:00 | Sender: EibPC | GA: '1/1/1'c14 | Wert: vout: 33.34 | Typ: Text |  Schreiben
% 2014-02-22 23:12:00 | Sender: EibPC | GA: '1/1/1'c14 | Wert: size: 5 | Typ: Text |  Schreiben
% 2014-02-22 23:12:00 | Sender: EibPC | GA: '1/1/1'c14 | Wert: v: 33.34 | Typ: Text |  Schreiben

% 2014-02-22 23:12:10 | Sender: EibPC | GA: '1/1/1'c14 | Wert: send: 2840B6AA | Typ: Text |  Schreiben
% 2014-02-22 23:12:10 | Sender: EibPC | GA: '1/1/1'c14 | Wert: read: 2840B6AA | Typ: Text |  Schreiben
% 2014-02-22 23:12:10 | Sender: EibPC | GA: '1/1/1'c14 | Wert: DevStart: 96 | Typ: Text |  Schreiben
% 2014-02-22 23:12:10 | Sender: EibPC | GA: '1/1/1'c14 | Wert: M-size: 136 | Typ: Text |  Schreiben
% 2014-02-22 23:12:10 | Sender: EibPC | GA: '1/1/1'c14 | Wert: result: 96 | Typ: Text |  Schreiben
% 2014-02-22 23:12:10 | Sender: EibPC | GA: '1/1/1'c14 | Wert: pos: 128 | Typ: Text |  Schreiben
% 2014-02-22 23:12:10 | Sender: EibPC | GA: '1/1/1'c14 | Wert: vout: 0.00 | Typ: Text |  Schreiben
% 2014-02-22 23:12:10 | Sender: EibPC | GA: '1/1/1'c14 | Wert: size: 5 | Typ: Text |  Schreiben
% 2014-02-22 23:12:10 | Sender: EibPC | GA: '1/1/1'c14 | Wert: v: 0.00 | Typ: Text |  Schreiben

**saft6luck** · 23.02.2014, 08:52

Hast du noch andere TCP Verbindungen im Code? Evtl. gibt es hier ein Problem mit der Verwendung von ReadTCP()?

Das Problem mit der Antwortlänge kann ich bestätigen. Wenn die Länge der Antwort bekannt ist, sollte man darauf prüfen bzw. ansonsten andere verfügbare Plausibilisierungen durchführen.

**enertegus** · 23.02.2014, 10:47

Zitat von kirekey Beitrag anzeigen

N Das Problem kann demnach nicht das Makro sein, denn dieses würde in Verbindung mit dem statischen Script deterministische Werte liefern. Wahrscheinlich ist in diesen Fällen die Antwort des Servers minimal später eingetroffen als sonst.

Die TCP Verarbeitung wird vom Kernel mit 10x1400 Bytes gepuffert und dann jeweils mit der Länge, was im Puffer eingetroffen ist, von der Verarbeitung übernommen.
Ich bin nicht der Superexperte was TCP/IP Stack betrifft, aber ggf. spaltet der Sender auch mal die Pakete in mehrere Sendungen auf. Die Verarbeitung sieht dann eben nur 136 Bytes, weil "zufällig" die fehlenden Bytes noch nicht da sind und die Sache geht schief.
Um das robuster zu machen, müsste man prüfen, ob die richtige Länge an Bytes da sind, bevor diese verarbeitet werden:

Pseudo-Code:
if tcpread(...,data,..) and ... then {
if size(data)<140 then mypuffer=mypuffer+ data
else
mypuffer =data
}

Zum "obsolet": Wie ich das gelesen habe, ist der IPExtender nicht mehr zu kaufen. Von einem schwarzen Peter würde ich da nicht reden. Unabhängig davon unterstützte ich hier gerne.

**kirekey** · 23.02.2014, 22:06

Zitat von saft6luck Beitrag anzeigen

Hast du noch andere TCP Verbindungen im Code?

Nein, wenn ich den einen Aufruf des OW-Makros entferne, ist das EibPC-Programm komplett leer.

Zitat von enertegus Beitrag anzeigen

Die TCP Verarbeitung wird vom Kernel mit 10x1400 Bytes gepuffert und dann jeweils mit der Länge, was im Puffer eingetroffen ist, von der Verarbeitung übernommen.
Ich bin nicht der Superexperte was TCP/IP Stack betrifft, aber ggf. spaltet der Sender auch mal die Pakete in mehrere Sendungen auf. Die Verarbeitung sieht dann eben nur 136 Bytes, weil "zufällig" die fehlenden Bytes noch nicht da sind und die Sache geht schief.

So etwas ähnliches kam mir heue Früh auch in den Sinn. Das kleine Script von makki, das vom EibPC auf dem IPE aufgerufen wird, verwendet 4 echo Befehle, so wie mein statisches Beispiel-Script. Die ersten 3 echos werden sofort rausgeschickt. Dann kommt die Konvertierung des Temperaturwertes, die bis zu 700ms dauern kann, und das Ergebnis wird anschließend ebenfalls per echo weg geschrieben. Nun könnte man nach deiner Aussage vermuten, dass der IPE zwei Pakete an den EibPC sendet, da die Zeit zwischen dem 3. und 4. echo zu lang ist, und dann nur das erste Paket vom EibPC verarbeitet wird. Daher habe ich die 4 echos zu einer Ausgabe zusammengefasst.

Code:

#!/bin/sh

# Statisches Beispiel
out1="Content-Type: text/plain"
out2="$QUERY_STRING"
out3="     12.34"
printf "%s\n\n%s\n%s\n " "$out1" "$out2" "$out3"

Code:

#!/bin/sh

# Dynamisches Beispiel
#sleep 1
out1="Content-Type: text/plain"
out2="$QUERY_STRING"
out3=`owget $QUERY_STRING`
printf "%s\n\n%s\n%s\n " "$out1" "$out2" "$out3"

Das Ergebnis deckt sich dann allerdings nicht mit deiner Vermutung. Sobald jetzt der Temperaturwert berechnet werden muss oder der sleep-Befehl aktiviert wird, wird das Makro bzw. das readtcp Event gar nicht mehr aufgerufen. Nur wenn der Temperaturwert aus dem Cache kommt, also der IPE sofort antwortet, kommen die Daten korrekt im Makro an.

Das Problem ist also wahrscheinlich eher der von dir beschriebene Prozess des Pufferns und Verarbeitens der im EibPC stattfindet. Gibt es hier Timeouts, die deutlich unterhalb einer Sekunde liegen? Das wäre die einzige Ursache, die ich mir jetzt noch vorstellen könnte. Was z.B. bedeutet der Kommentar "Zeit > 600 wird problematisch" im Makro?

Eine andere Frage hätte ich da auch noch an Steffi: In dem Makro werden zur ermittelten Startposition einmal 18 Byte ("text/plain" + 8 Byte für zwei Zeilenumbrüche) und etwas später 17 Byte ("temperature" + 6 Byte für Zeilenumbruch und 5 Leerzeichen vor dem Temperaturwert) zur Suchposition addiert. Wie kommen die 8 Byte für zwei Zeilenumbrüche im Verhältnis zu 1 Byte für einen Zeilenumbruch zustande? Es funktioniert zweifellos, aber ich kann es mir technisch nicht erklären. Die 5 Byte vor der Temperatur werden wahrscheinlich einfach so vom owget geliefert, oder?

Grüße
Erik

**enertegus** · 24.02.2014, 12:09

Zitat von kirekey Beitrag anzeigen

Das Problem ist also wahrscheinlich eher der von dir beschriebene Prozess des Pufferns und Verarbeitens der im EibPC stattfindet? Das wäre die einzige Ursache, die ich mir jetzt noch vorstellen könnte.

so, habe mal das Makro angeschaut. Hier steht noch

Code:

if event(readtcp(Name_Port,Name_IP,Name_Message)) and Name_IP == Name_OwExtenderIP and Name_Port==Name_OwExtenderPort then {
    /* < 130 = Teilstring, nicht verwertbar */
    if size(Name_Message) > 130u16 then { ...

Da wurde seinerzeit ggf. die Messagesize von Elabnet geändert, oder die Steffi hatte sich verzählt (glaub ich nicht). Wenn Du einfach anstelle der 130 die 139 setzt (oder was Du da oben gezählt hattest), sollte das Problem behoben sein.

Was z.B. bedeutet der Kommentar "Zeit > 600 wird problematisch" im Makro?

Ich denke, dass der Extender die TCP-Verbindung wieder automatisch schließt, wenn da zu lange keine Nachricht eintrifft.

**kirekey** · 24.02.2014, 13:44

Zitat von enertegus Beitrag anzeigen

Wenn Du einfach anstelle der 130 die 139 setzt (oder was Du da oben gezählt hattest), sollte das Problem behoben sein.

Ähm, was soll denn damit behoben sein? Dann bekomme ich ja nur noch "invalid telegr" Meldungen - schau dir mal den else-Zweig der von dir genannten Bedingung an...
Wie bereits geschrieben, wenn die Antwort vom IPE länger dauert, gibt es kein readtcp-Event mehr, auch keine Debug-Ausgabe, folglich wird der Code gar nicht erreicht.

Ich habe es gerade mal mit dem Typ temperature9 probiert, also mit der geringsten Auflösung und da klappt es. Selbst mit temperature11 funktioniert es in den meisten Fällen. Hier dauert die Konvertierung laut Datenblatt 375ms. Nur bei temperature bzw. temperature12 (750ms) kommt gar nichts mehr. Es sieht doch eindeutig danach aus, dass der EibPC die Verbindung trennt. Und zwar nach einer Zeitspanne irgendwo zwischen 375 und 750ms.

Grüße
Erik

**enertegus** · 24.02.2014, 15:20

Zitat von kirekey Beitrag anzeigen

Ähm, was soll denn damit behoben sein? Dann bekomme ich ja nur noch "invalid telegr" Meldungen - schau dir mal den else-Zweig der von dir genannten Bedingung an...
Wie bereits geschrieben, wenn die Antwort vom IPE länger dauert, gibt es kein readtcp-Event mehr, auch keine Debug-Ausgabe, folglich wird der Code gar nicht erreicht.

oder es wird mehr (131) eingelesen und nicht mehr sauber geparst.

Nur bei temperature bzw. temperature12 (750ms) kommt gar nichts mehr. Es sieht doch eindeutig danach aus, dass der EibPC die Verbindung trennt. Und zwar nach einer Zeitspanne irgendwo zwischen 375 und 750ms.

Der EibPC macht schon nach 1 Sekunde die Verbindung wieder zu: Das seht dazu im Makro

Code:

// TCP Verbindung wieder ordentlich schlieen
if after(Startabfrage,1000u64) then {
   Name_close=closetcp(Name_Port,Name_IP)
} endif

Also würde ich hier auf 2000 gehen (die Codezeile gibt es zweimal, entsprechend der Vorgabe, ob es eine Variable oder GA sein soll).
Und die Abfrage

Code:

if after(Startabfrage == EIN,500u64) then {

sollte dann z.B. auf 1400 stehen.

Code:

if after(Startabfrage == EIN,1400u64) then {

Aus meiner Sicht hängt das v.a. am Timing des Extenders bzw. muss man hier offenbar eine Anpassung vornehmen.

**SteffiEnertex** · 24.02.2014, 15:28

Zitat von kirekey Beitrag anzeigen

In der Bibliothek gibt es zwei EnertexOneWire-Dateien, EnertexOneWire.lib und EnertexOneWire2.lib. Für mich bedeutet die 2 eine neuere (weil zweite) Version. Laut CVS-Daten im Header handelt es sich bei dieser Datei aber um Revison 1.3, im Gegensatz zu 1.4 bei der anderen Datei, also in Wahrheit um die ältere Version. Die manuell gepflegte Versionsangabe im Header ist allerdings mit v1.016 bei beiden Dateien identisch. Wer soll da durchsehen?

Das ist so nicht geplant und gewollt, sondern war mein Fehler.
Danke für den Hinweis.
Wird korrigiert und in der nächsten Version wieder passend gemacht.
(Wobei in der nächsten Version die beiden Makros zum OWextender als "obsolet" markiert sein werden).

Die Unterschiede der beiden Libs betreffen den One-Wire-Teil.
Der Teil, den Du verwendest ist identisch.

**kirekey** · 24.02.2014, 15:59

Zitat von enertegus Beitrag anzeigen

Der EibPC macht schon nach 1 Sekunde die Verbindung wieder zu: Das seht dazu im Makro

Ganz genau, DANKE! Das muss die Wurzel allen Übels sein.

Wenn ich das Makro nun richtig deute, werden 60ms für die Namensaulösung, 440ms fürs Verbinden und der Rest für die Anfrage veranschlagt und dann bleiben max. weitere 500ms bis die Verbindung nach insgesamt 1000ms wieder geschlossen wird. Sehe ich das richtig?

Da 500ms (after(Startabfrage)) + 750ms (Konvertierung) > 1000ms ist, konnte das ja NOCH NIE mit voller Auflösung funktionieren. Na gut, dass das mal geklärt ist. Mit 2000ms wird es dann wohl recht stabil funktionieren, es sei denn das Netzwerk ist mal extrem langsam.

Aber warum soll ich die 500ms auf 1400ms hoch setzen? Dann wäre 1400 + 750 > 2000 und es funktioniert wieder nicht. Aus welchem Grund sollte ich die 500 nicht einfach belassen?

Grüße
Erik

**enertegus** · 24.02.2014, 16:46

Zitat von kirekey Beitrag anzeigen

Da 500ms (after(Startabfrage)) + 750ms (Konvertierung) > 1000ms ist, konnte das ja NOCH NIE mit voller Auflösung funktionieren.

Die Frage nach der Auflösung wäre auch, ob das überhaupt sinnvoll ist. Ich hab da auch nicht die Beispiele in der Lib im Kopf, denke aber dass das passt.

Aber warum soll ich die 500ms auf 1400ms hoch setzen? Dann wäre 1400 + 750 > 2000 und es funktioniert wieder nicht. Aus welchem Grund sollte ich die 500 nicht einfach belassen?

Ja stimmt natürlich.

**makki** · 28.02.2014, 20:30

Hinweis durch PN - sorry ich bin da "etwas raus"..

Also, ich kann kein Problem damit nachvollziehen, aber das ist natürlich auch nicht besonders realistisch, wenn man das mal für 10 Minuten testet vs. 24x7x365 ..

Wir (ich) könn(t)en das Interface auf dem IP-Extender jederzeit - trotz Einstellung - auch ändern, falls dort das Problem liegt.

Aber, schonmal vorab, Fehler (leere Antwort) aufm 1Wire etc. müssen eigentlich im EibPC-Makro abgefangen werden..

Bin gerne behilflich aber dazu brauchts eine exakte Fehlerbeschreibung, die ich in diesem Thread noch nicht erkennen konnte

Grüsse Makki

**kirekey** · 01.03.2014, 11:12

Zitat von makki Beitrag anzeigen

Also, ich kann kein Problem damit nachvollziehen, aber das ist natürlich auch nicht besonders realistisch, wenn man das mal für 10 Minuten testet vs. 24x7x365 ..

Die PN war schon etwas älter. Kurz nachdem ich sie geschrieben hatte, haben wir das Problem auf der Seite des Makros identifizieren können. Dort wurde nach exakt 1s die TCP-Verbindung getrennt. Je nach

konfigurierter Auflösung/Genauigkeit des Temperaturwertes
Gültigkeit des owfs Caches
Auslastung des Netzwerkes

kam dann im Makro gar nichts, nur der Header, nur Header und Sensor-ID oder auch alles an. Das führte zu den verschiedensten Ausgaben, wie 0, invalid telegr oder auch dem korrekten Temperaturwert.

Zitat von makki Beitrag anzeigen

Wir (ich) könn(t)en das Interface auf dem IP-Extender jederzeit - trotz Einstellung - auch ändern, falls dort das Problem liegt.

Ich hatte es ja schon so angepasst, dass alles oder nichts kommt, statt der "kleinen Häppchen" mit jedem echo. Dann noch das TCP-Timeout im Makro erhöht und nun läuft es ohne Probleme.
Nur was es mit den Leerzeichen vor dem Temperaturwert auf sich hat, habe ich nicht nochmal genauer untersucht. Sofern das bisherige Interface hier eine feste Länge mit rechts ausgerichtetem Wert liefert, könnte das bei unterschiedlicher Genauigkeit (0 bis 4 Nachkommastellen) ein potentielles Problem im Makro sein.
Da ich in meinem Script den Temperaturwert mittels printf "%f" von seinen Leerzeichen befreie, habe ich damit aber kein Problem.

Bei Gelegenheit werde ich Script und Makro aktualisieren und an geeigneter Stelle (?) zur Verfügung stellen. Nur schade, dass das Problem nicht früher gelöst wurde. Einige Leute haben in diesem Forum und andere sicher auch außerhalb das "Team" EibPC + IPE genau aus diesem Grund bereits aufgegeben... teilweise sicher auch zu eurem Vorteil (Wiregate)

Wäre mal interessant zu wissen, wer den IPE mit der OWExtender-Bibliothek und dem nun gelösten Problem tatsächlich noch im Einsatz hat.

Zitat von makki Beitrag anzeigen

Bin gerne behilflich aber dazu brauchts eine exakte Fehlerbeschreibung, die ich in diesem Thread noch nicht erkennen konnte

Im Ernst? Ich glaube noch detaillierter als in den vorherigen Posts kann man's nicht erklären, sonst würde es ne wissenschaftliche Abhandlung werden...

Grüße
Erik

Ankündigung

Zuverlässigkeit und Pflege der Makrobibliotheken - eine Leidensgeschichte am Beispiel

Zuverlässigkeit und Pflege der Makrobibliotheken - eine Leidensgeschichte am Beispiel

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar