Erster Eindruck, Testen der Grundfunktionen
David Rütti
Hallo Sven, Hallo Betatester
Seit gestern darf ich den eWicht testen und der erste Eindruck gefällt
mir.
Er ist handlich, leicht (190 g), wirkt aufgeräumt, übersichtlich und
hochwertig verarbeitet. Die Funktionen der Tasten ist gut erkennbar,
ausser F0, da hatte ich zuerst an ein Fragezeichen gedacht. Wie sieht
z.B. das gepsiegelte F0 Symbol aus? Er liegt für Rechts- wie
Linkshänder gut in der Hand, Einhand-Bedienung ist ohne Mühe zu
bewerkstelligen. Das beleuchtete Display ist auch in der Dunkelheit
gut zu lesen.
Die Software hingegen hat noch viel Verbesserungspotential. Im
folgenden Abschnitt unterteile ich die Features nach Funktioniert/
Funktioniert nicht/Wunschliste.
Funktioniert:
- DHCP
- GL
- HTTP Server
Funktioniert nicht:
- Drehknopf im Schnelllauf. Ab einer bestimmten Winkelgeschwindigkeit
springt der Wert unkontrolliert umher
- Die Buseinstellungen sind nicht sinnvoll. Standard alle Busadressen
auf "1"
- GA stürzt ab. Eingabe der Adresse+Protokol, sowie das erste Schalten
ist möglich, dann geht nichts mehr, macht ein Ausschalten oder
erneutes Drücken auf Weiche notwendig
- Verzögerung nach Eingabe und Drücken zu gross. Z.B. IP Eingabe:
192.168. ... Wechsel zwischen den Oktetts durch 1x Drücken am
Drehregler. Gefahr durch ungewolltes verstellen des vorangegangens
Oktetts bei schneller Eingabe durch die Verzögerung
Wunschliste:
- Die Einschaltzeit (DHCP ohne Zeroconf) und die Einschaltzeit
betragen je 10 s. Die Einschaltzeit geht in Ordnung, das Ausschalten
mir zu lange. Wie kann diese verkürzt werden?
- Beim Adresswechsel (GA und GL) alte schon eingegebene Adresse
vorschlagen
- Ich empfinde den Doppelklick (Drehgeber) weniger intuitiv als z.B.
langes Drücken oder Bestätigen durch andere Tasten
- Änderung der Parameter über das Web-Interface sofort und nicht nach
Neustart
- Lokliste mit "Sprechenden" Namen, Historie der eingegebenen Adressen
- Walk around? Der eWicht muss dann aber gepuffert werden, 10 s Ein-/
Ausschalten mit Neueingabe Lokadresse ist nicht akzeptabel
- Eingabe des srcp Servers auch über DNS lookup, also sprechende Namen
wie srcp.heimnetz. Dazu braucht es aber zusätzlich einen Punkt im
Alphanumerischen Modus
Handbuch:
- Reihenfolge muss nach Wichtigkeit sortiert werden. Schnelleinstieg
ohne Hintergrundwissen zu Begin: Voraussetzungen (MoBa+SRCPD/DDL/DDW,
unterstützte srcp Versionen) und grundlegende Bedienung. Punkt.
Details später.
Nicht getestet:
- Zeroconf
Gruss
David
Sven Schlender
> Seit gestern darf ich den eWicht testen und der erste Eindruck gefällt
> mir.
Vielen Dank, dass Du Dir die Zeit nimmst, um zu testen! Das ist echt viel
wert - ich stecke einfach viel zu tief in den Details, als das ich noch
einen objektiven Blick haben kann.
> Er ist handlich, leicht (190 g), wirkt aufgeräumt, übersichtlich und
> hochwertig verarbeitet. Die Funktionen der Tasten ist gut erkennbar,
> ausser F0, da hatte ich zuerst an ein Fragezeichen gedacht. Wie sieht
> z.B. das gepsiegelte F0 Symbol aus?
Tja die Glühbirne... Ich fand sie eigentlich immer ganz nett :) Aber die
Drehung ist eine gute Idee, damit wäre es eindeutiger.
> Er liegt für Rechts- wie
> Linkshänder gut in der Hand, Einhand-Bedienung ist ohne Mühe zu
> bewerkstelligen. Das beleuchtete Display ist auch in der Dunkelheit
> gut zu lesen.
Ok. Wobei ich schon über einen Algorithmus nachgedacht habe, der die
Beleuchtung nach einer gewissen Zeit abschaltet.
> Die Software hingegen hat noch viel Verbesserungspotential. Im
> folgenden Abschnitt unterteile ich die Features nach Funktioniert/
> Funktioniert nicht/Wunschliste.
Hierzu habe ich eine Frage: Mit welchem Server (Version) hast Du getestet?
> Funktioniert nicht:
> - Drehknopf im Schnelllauf. Ab einer bestimmten Winkelgeschwindigkeit
> springt der Wert unkontrolliert umher
Ok. Hast Du den Test im GL-Betrieb oder während einer Einstellung gemacht?
> - Die Buseinstellungen sind nicht sinnvoll. Standard alle Busadressen
> auf "1"
Kommt immer drauf an. Ich habe die Tests mit DDW gemacht - da sind das genau
die richtigen Einstellungen. Welche Einstellungen sind also sinnvoll?
> Wunschliste:
> - Die Einschaltzeit (DHCP ohne Zeroconf) und die Einschaltzeit
> betragen je 10 s. Die Einschaltzeit geht in Ordnung, das Ausschalten
> mir zu lange. Wie kann diese verkürzt werden?
Das muss ich mir anschauen - grundsätzlich sollte da aber noch mehr
rauszuholen sein.
> - Änderung der Parameter über das Web-Interface sofort und nicht nach
Neustart
Würde ich mir auch wünschen - Mein Problem war hierbei, dass es dabei recht
schnell zu Inkonsistenzen zwischen Webinterface und eigentlicher Anzeige
kommen kann (gerade wenn direkt am eWicht jemand ein neues Gerät einrichtet
und parallel vom Webinterface etwas geändert wird).
> - Eingabe des srcp Servers auch über DNS lookup, also sprechende Namen
> wie srcp.heimnetz. Dazu braucht es aber zusätzlich einen Punkt im
> Alphanumerischen Modus
Für DNS sehe ich das Problem, dass dann noch irgendwo ein DNS-Server im
eWicht konfiguriert werden muss.
> Nicht getestet:
> - Zeroconf
Damit könntest Du übrigens für den Server einen sprechenden Namen eingeben.
Gruß, Sven.
David Rütti
Hallo Sven
> Vielen Dank, dass Du Dir die Zeit nimmst, um zu testen! Das ist echt viel
> wert - ich stecke einfach viel zu tief in den Details, als das ich noch
> einen objektiven Blick haben kann.
>
Gern geschehen.
>> Er liegt für Rechts- wie
>> Linkshänder gut in der Hand, Einhand-Bedienung ist ohne Mühe zu
>> bewerkstelligen. Das beleuchtete Display ist auch in der Dunkelheit
>> gut zu lesen.
>>
>
> Ok. Wobei ich schon über einen Algorithmus nachgedacht habe, der die
> Beleuchtung nach einer gewissen Zeit abschaltet.
>
Kein Problem, würde die Beleuchtung jedoch erst nach bestimmter Zeit (>
1-2 min) ohne User-Input abschalten.
>> Die Software hingegen hat noch viel Verbesserungspotential. Im
>> folgenden Abschnitt unterteile ich die Features nach Funktioniert/
>> Funktioniert nicht/Wunschliste.
>>
>
> Hierzu habe ich eine Frage: Mit welchem Server (Version) hast Du getestet?
>
srcpd 2.0.13 pre (aus svn). Sowohl mit Loconet- wie Loopback-Bus getestet.
>> Funktioniert nicht:
>> - Drehknopf im Schnelllauf. Ab einer bestimmten Winkelgeschwindigkeit
>> springt der Wert unkontrolliert umher
>>
>
> Ok. Hast Du den Test im GL-Betrieb oder während einer Einstellung gemacht?
>
Beides. Der Effekt trat sowohl bei Loks wie IP Einstellung auf
>> - Die Buseinstellungen sind nicht sinnvoll. Standard alle Busadressen
>> auf "1"
>>
>
> Kommt immer drauf an. Ich habe die Tests mit DDW gemacht - da sind das genau
> die richtigen Einstellungen. Welche Einstellungen sind also sinnvoll?
>
OK. Einverstanden. Ich bin von der aktuellen srcpd Version ausgegangen.
Aber macht der DDW wirklich für jedes Protokoll einen eigenen Bus auf?
>> - Änderung der Parameter über das Web-Interface sofort und nicht nach
>>
> Neustart
>
> Würde ich mir auch wünschen - Mein Problem war hierbei, dass es dabei recht
> schnell zu Inkonsistenzen zwischen Webinterface und eigentlicher Anzeige
> kommen kann (gerade wenn direkt am eWicht jemand ein neues Gerät einrichtet
> und parallel vom Webinterface etwas geändert wird).
>
Gute Frage. Was hälts Du, wenn per web Interface ein Neustart angeboten
(zusätzlichen Button) wird?
>> - Eingabe des srcp Servers auch über DNS lookup, also sprechende Namen
>> wie srcp.heimnetz. Dazu braucht es aber zusätzlich einen Punkt im
>> Alphanumerischen Modus
>>
>
> Für DNS sehe ich das Problem, dass dann noch irgendwo ein DNS-Server im
> eWicht konfiguriert werden muss.
>
Jein. Wer DHCP benutzt, wird wahrscheinlich auch ein DNS Server
betreiben und den über das DHCP Protokoll veröffentlichen. Müsste mit
den srcp Entwicklern koordiniert werden, als Standard könnte
srcp.locale.domäne angesehen werden. So ist es bei mir eingerichtet. In
wiefern dies für das breite Publikum Sinn macht, habe ich noch keine
Gedanken gemacht :-)
Zerokonf funktioniert ja auch ohne DHCP, oder? So hätte man die
Möglichkeit, eine vorhandene Infrastruktur (z.B. vom Route etc) zu
nutzen, Zerokonf zu installieren oder manuelle Eingabe.
>> Nicht getestet:
>> - Zeroconf
>>
>
> Damit könntest Du übrigens für den Server einen sprechenden Namen eingeben.
>
Richtig. Sehe für mich hingegen zur Zeit kein Bedarf. Vielleicht werde
ich es mal auf einem "Test"-Rechner testen...
> Gruß, Sven.
>
David
Sven Schlender
> > Ok. Wobei ich schon über einen Algorithmus nachgedacht habe, der die
> > Beleuchtung nach einer gewissen Zeit abschaltet.
> >
> Kein Problem, würde die Beleuchtung jedoch erst nach bestimmter Zeit (>
> 1-2 min) ohne User-Input abschalten.
Yup.
> > Kommt immer drauf an. Ich habe die Tests mit DDW gemacht - da sind das
genau
> > die richtigen Einstellungen. Welche Einstellungen sind also sinnvoll?
> >
>
> OK. Einverstanden. Ich bin von der aktuellen srcpd Version ausgegangen.
> Aber macht der DDW wirklich für jedes Protokoll einen eigenen Bus auf?
Ja macht er. Die Intention war IMHO eigentlich auch mal, das im SRCP genau
aus diesem Grund Busse eingebaut wurden. Warum im srcpd defaultmäßig davon
nicht Gebrauch gemacht wird, weiß ich nicht. Möglicherweise will man den
Aufwand bei der Konfiguration eines Clients gering halten, was sicher Sinn
macht. Ich könnte Michael Gräfe, den Maintainer von DDW mal befragen, was
der davon hält.
>>> - Änderung der Parameter über das Web-Interface sofort und nicht nach
>>> Neustart
> >
> > Würde ich mir auch wünschen - Mein Problem war hierbei, dass es dabei
recht
> > schnell zu Inkonsistenzen zwischen Webinterface und eigentlicher Anzeige
> > kommen kann (gerade wenn direkt am eWicht jemand ein neues Gerät
einrichtet
> > und parallel vom Webinterface etwas geändert wird).
> >
>
> Gute Frage. Was hälts Du, wenn per web Interface ein Neustart angeboten
> (zusätzlichen Button) wird?
Ja, das ist eine gute Idee, löst aber nicht das eigentliche Problem von
oben.
> >> - Eingabe des srcp Servers auch über DNS lookup, also sprechende Namen
> >> wie srcp.heimnetz. Dazu braucht es aber zusätzlich einen Punkt im
> >> Alphanumerischen Modus
> >>
> >
> > Für DNS sehe ich das Problem, dass dann noch irgendwo ein DNS-Server im
> > eWicht konfiguriert werden muss.
> >
>
> Jein. Wer DHCP benutzt, wird wahrscheinlich auch ein DNS Server
> betreiben und den über das DHCP Protokoll veröffentlichen. Müsste mit
> den srcp Entwicklern koordiniert werden, als Standard könnte
> srcp.locale.domäne angesehen werden. So ist es bei mir eingerichtet. In
> wiefern dies für das breite Publikum Sinn macht, habe ich noch keine
> Gedanken gemacht :-)
Ich weiß nicht, ob man im Rahmen von srcp die Domäne festlegen sollte. Klar
kann man den von DHCP zur Verfügung gestellten DNS-Server bei
Namensauflösung befragen, und zwar in der folgenden Reihenfolge:
1) DNS verfügbar? Dann frage ich den DNS-Server.
2) zeroconf-Dienst befragen
> Zerokonf funktioniert ja auch ohne DHCP, oder? So hätte man die
> Möglichkeit, eine vorhandene Infrastruktur (z.B. vom Route etc) zu
> nutzen, Zerokonf zu installieren oder manuelle Eingabe.
Ja genau, macht eigentlich so Sinn.
Gruß, Sven.
David Rütti
Hallo Sven
On 27.04.2009 19:20, Sven Schlender wrote:
> Hi David,
>
>
>>> Ok. Wobei ich schon über einen Algorithmus nachgedacht habe, der die
>>> Beleuchtung nach einer gewissen Zeit abschaltet.
>>>
>>>
>> Kein Problem, würde die Beleuchtung jedoch erst nach bestimmter Zeit (>
>> 1-2 min) ohne User-Input abschalten.
>>
>
> Yup.
>
Unter dieser Bedingung gibt es nicht einzuwenden :-)
>
>
>>> Kommt immer drauf an. Ich habe die Tests mit DDW gemacht - da sind das
>>>
> genau
>
>>> die richtigen Einstellungen. Welche Einstellungen sind also sinnvoll?
>>>
>>>
>> OK. Einverstanden. Ich bin von der aktuellen srcpd Version ausgegangen.
>> Aber macht der DDW wirklich für jedes Protokoll einen eigenen Bus auf?
>>
>
> Ja macht er. Die Intention war IMHO eigentlich auch mal, das im SRCP genau
> aus diesem Grund Busse eingebaut wurden. Warum im srcpd defaultmäßig davon
> nicht Gebrauch gemacht wird, weiß ich nicht. Möglicherweise will man den
> Aufwand bei der Konfiguration eines Clients gering halten, was sicher Sinn
> macht.
Ist sicherlich 1 Aspekt. Zweitens ist 1 Bus je Protokoll overkill, da ja
das Protokol auch in der Initialisierung angegeben werden muss. Der
srpcd ist ja viel mächtiger als DDL/DDW, da er neben dem Erzeugen des
Gleissignals und Rücklesen des LPT Portes (S88) auch eine grosse Anzahl
an Standalone-Zentralen unterstützt. Über die Auswahl des Busses wird
das Aus/Eingabegerät bestimmt, was ja sonst nicht im srcp Protokoll
spezifiziert ist. So lassen sich mehrere kommerzielle Zentralen neben-
und miteinander betreiben und die Vorteile jedes Systems nutzen.
> Ich könnte Michael Gräfe, den Maintainer von DDW mal befragen, was
> der davon hält.
>
Gute Idee! DDL hat es auch so gehandhabt, wie ich gerade aus der x-mas
Edition 2005 gesehen habe. Die aktuelle Version ist hingegen "nur" ein
optimiertes srpcd, die Busse sind also frei konfigurierbar. Würde es
begrüssen, wenn DDW da nachziehen könnte.
> Ich weiß nicht, ob man im Rahmen von srcp die Domäne festlegen sollte. Klar
>
Sehe ich auch keinen Nutzen. Aber ein vernünftig konfigurierter DHCP
Server liefert auch gleich seine Dömäne mit, in der dann nach srcp
gefragt werden kann.
> kann man den von DHCP zur Verfügung gestellten DNS-Server bei
> Namensauflösung befragen, und zwar in der folgenden Reihenfolge:
> 1) DNS verfügbar? Dann frage ich den DNS-Server.
> 2) zeroconf-Dienst befragen
>
3) manuelle Eingabe
Macht Sinn. Ich hoffe, damit verbauen wir nichts für das noch in den
Kinderschuhen steckende CRCF. Dein Regler wäre ja ein Paradebeispiel für
dessen Anwendung.
Gruss
David
Sven Schlender
seit gestern findet Ihr die Sourcen der Version 1.0.3 sowie die zugehörige
(doxygen-)Doku online auf
http://www.mobacon.de/eWicht/developers_ger.html
Ich habe auf der Seite "List of errors and feature requests" die offenen
Punkte von David und mir zusammengetragen. Ich denke, dass ich recht bald
eine 1.0.4 zur Verfügung stellen kann, die einige der Punkte bereinigt.
Gruß, Sven.
Sven Schlender
folgenden von David gefundenen Bug habe ich mir heute etwas genauer
angeschaut:
> - GA stürzt ab. Eingabe der Adresse+Protokol, sowie das erste Schalten
> ist möglich, dann geht nichts mehr, macht ein Ausschalten oder
> erneutes Drücken auf Weiche notwendig
Ich habe mit Linux nicht soviel am Hut, unter Cygwin habe ich den frisch
ausgecheckten srcpd-Code nicht übersetzen können (configure fehlt). Dafür
habe ich den srcpd-2.0.12-Tarball von der srcpd-Downloadseite gezogen - den
konnte ich unter cygwin übersetzen und starten. Nach einigen Tests denke
ich, dass sich der selbe Fehler auch in dieser Version zeigt.
Nach erfolgreichen Verbindungsaufbau habe ich einen Motorola-GA-Decoder, Bus
1, Adresse 1 initialisiert. Die Initialisierung läuft sauber durch, dann
kann ich den Port 0 sogar durch Drücken des Reglers umschalten. Auch im
Wireshark sieht das alles gut aus.
Wenn ich nun mittels des Reglers auf Port 1 drehe, versucht sich der eWicht
mit "GET 1 GA 1 1" die aktuelle Konfiguration zu holen. Die Antwort von
srcpd ist dann jedoch komisch: "0.000 100 INFO 1 GA 1 1 0". Die Zeit scheint
irgendwie kaputt zu sein. Der eWicht kommt mit der Zeit nicht klar (diese
Meldung liegt weit vor der zuletzt erhaltenen und wird daher ungesehen
gelöscht) und startet eine neue Abfrage: Deadlock. Mittels Terminalprogramm
konnte ich den Fehler ebenfalls reproduzieren - scheint sich also um einen
srcpd-Bug zu handeln.
Workarround:
Ab Version 1.0.4 ist das Javascript auf der eWicht-HP so geändert, dass es
auch möglich ist, nur einen Port pro GA-Protokoll zu definieren: Min. Port=0
und Max. Port=0.
@David:
Bist Du bereits auf der srcpd-Liste und wenn ja könntest Du dort auf das
Problem aufmerksam machen?
Gruß, Sven.
David Rütti
Hallo Sven
On 08.05.2009 17:33, Sven Schlender wrote:
> Hallo,
>
> folgenden von David gefundenen Bug habe ich mir heute etwas genauer
> angeschaut:
>
>
>> - GA stürzt ab. Eingabe der Adresse+Protokol, sowie das erste Schalten
>> ist möglich, dann geht nichts mehr, macht ein Ausschalten oder
>> erneutes Drücken auf Weiche notwendig
>>
>
> Ich habe mit Linux nicht soviel am Hut, unter Cygwin habe ich den frisch
> ausgecheckten srcpd-Code nicht übersetzen können (configure fehlt).
Mit 'aclocal, autoconf, autoheader, automake --add-missing und automake'
- in dieser Reihenfolge - wird das vermisste configure Skript erzeugt.
Würde aber sagen, dass die 2.0.12 Version auch geht.
> Dafür
> habe ich den srcpd-2.0.12-Tarball von der srcpd-Downloadseite gezogen - den
> konnte ich unter cygwin übersetzen und starten. Nach einigen Tests denke
> ich, dass sich der selbe Fehler auch in dieser Version zeigt.
>
> Nach erfolgreichen Verbindungsaufbau habe ich einen Motorola-GA-Decoder, Bus
> 1, Adresse 1 initialisiert. Die Initialisierung läuft sauber durch, dann
> kann ich den Port 0 sogar durch Drücken des Reglers umschalten. Auch im
> Wireshark sieht das alles gut aus.
> Wenn ich nun mittels des Reglers auf Port 1 drehe, versucht sich der eWicht
> mit "GET 1 GA 1 1" die aktuelle Konfiguration zu holen. Die Antwort von
> srcpd ist dann jedoch komisch: "0.000 100 INFO 1 GA 1 1 0". Die Zeit scheint
> irgendwie kaputt zu sein.
Oops! Danke. Da ist wirklich mit srcpd etwas kaputt. Der gleiche Fehler
ist auch bei mir reproduzierbar. Nach einmaligen Schalten mit set
funktioniert das get dann einwandfrei. Ich werden den Bug melden.
> Der eWicht kommt mit der Zeit nicht klar (diese
> Meldung liegt weit vor der zuletzt erhaltenen und wird daher ungesehen
> gelöscht) und startet eine neue Abfrage: Deadlock.
>
OK, macht Sinn. Auf jeden Fall deckt sich der Deadlock mit meinen
Beobachtungen. Im Terminal funktioniert der get Befehl nach einmaligen
set einwandfrei. Theoretisch müsste der eWicht nach manuellem set
funktionieren. Wann macht der eWicht genau seine get Anfrage? Kann ich
nach Einstellen der Adresse und Schalten am eWicht über eine zweite
Sitzung einen set Befehl absetzen?
> Workarround:
> Ab Version 1.0.4 ist das Javascript auf der eWicht-HP so geändert, dass es
> auch möglich ist, nur einen Port pro GA-Protokoll zu definieren: Min. Port=0
> und Max. Port=0.
>
Darauf bin ich gespannt.
Gruss
David
Sven Schlender
> Auf jeden Fall deckt sich der Deadlock mit meinen
> Beobachtungen. Im Terminal funktioniert der get Befehl nach einmaligen
> set einwandfrei. Theoretisch müsste der eWicht nach manuellem set
> funktionieren. Wann macht der eWicht genau seine get Anfrage? Kann ich
> nach Einstellen der Adresse und Schalten am eWicht über eine zweite
> Sitzung einen set Befehl absetzen?
Es wird immer erst versucht, einen konsistenten Stand mit dem Server
herzustellen. Wenn kein Wissen da ist, wird mittels GET das Wissen
eingeholt. Würde zuerst ein SET abgesetzt, wäre das eher kontraproduktiv im
Hinblick auf andere angeschlossene Clients und einen bereits laufenden
Betrieb.
Noch etwas, was mir aufgefallen ist:
srcpd erzeugt die Antwort (0.000 100 INFO 1 GA 1 0 0) auf ein GET sogar,
wenn das GA noch gar nicht initialisiert wurde!
Gruß, Sven.
David Rütti
Hallo Sven
Ich möchte nochmals beim "GA" Problem und srcpd einhaken. Heute habe
ich es mit DDW 0.78 getestet und da funktioniert es einwandfrei. Mit
dem srcp gibt es den beschriebenen Absturz. Die Frage bleibt warum?
Gibt es beim eWicht ein Debug-Modus, bei welchem die Kommunikation
eingesehen kann? Wenn ich nämlich vorgängig per separater Session das
GA initialisiere und setze, tritt nämlich das Timestamp-Problem nicht
mehr auf. Trotzdem stürzt der eWicht ab. Was könnte sonst noch schief
laufen?
> Workarround:
> Ab Version 1.0.4 ist das Javascript auf der eWicht-HP so geändert, dass es
> auch möglich ist, nur einen Port pro GA-Protokoll zu definieren: Min. Port=0
> und Max. Port=0.
Weiche von gerade nach gerade zu stellen? :-)
Gruss
David
Sven Schlender
> Ich möchte nochmals beim "GA" Problem und srcpd einhaken. Heute habe
> ich es mit DDW 0.78 getestet und da funktioniert es einwandfrei. Mit
> dem srcp gibt es den beschriebenen Absturz. Die Frage bleibt warum?
bis dato eben nicht.
> Gibt es beim eWicht ein Debug-Modus, bei welchem die Kommunikation
> eingesehen kann?
Du Wireshark benutzen.
> Wenn ich nämlich vorgängig per separater Session das
> GA initialisiere und setze, tritt nämlich das Timestamp-Problem nicht
> mehr auf. Trotzdem stürzt der eWicht ab. Was könnte sonst noch schief
> laufen?
liefert srcpd ebenfalls den "0"-Zeitstempel.
> > Workarround:
> > Ab Version 1.0.4 ist das Javascript auf der eWicht-HP so geändert, dass es
> > auch möglich ist, nur einen Port pro GA-Protokoll zu definieren: Min. Port=0
> > und Max. Port=0.
>
> Das funktioniert, aber wie sinnvoll findest Du die Möglichkeit, eine
> Weiche von gerade nach gerade zu stellen? :-)
doch eine Weiche umschalten?! Wenn Du also Min.Port=Max.Port=0
einstellst dann kannst Du zumindestens einen Port umschalten (so war
zumindestens meine Idee).
Gruß, Sven.
David Rütti
Hallo Sven
>> Gibt es beim eWicht ein Debug-Modus, bei welchem die Kommunikation
>> eingesehen kann?
>>
>
> Für das Mitsniffen der Kommunkation zwischen eWicht und Server kannst
> Du Wireshark benutzen.
>
Danke. Werde ich hoffentlich am WE ausprobieren können. Ich hoffe, die
Bedienung ist schnell lernbar :-)
>> Wenn ich nämlich vorgängig per separater Session das
>> GA initialisiere und setze, tritt nämlich das Timestamp-Problem nicht
>> mehr auf. Trotzdem stürzt der eWicht ab. Was könnte sonst noch schief
>> laufen?
>>
>
> Nur das GA zu initialisieren reicht nicht. Wenn Du den Port wechselst
> liefert srcpd ebenfalls den "0"-Zeitstempel.
>
OK, habe ich nicht getestet...
>>> Workarround:
>>> Ab Version 1.0.4 ist das Javascript auf der eWicht-HP so geändert, dass es
>>> auch möglich ist, nur einen Port pro GA-Protokoll zu definieren: Min. Port=0
>>> und Max. Port=0.
>>>
>> Das funktioniert, aber wie sinnvoll findest Du die Möglichkeit, eine
>> Weiche von gerade nach gerade zu stellen? :-)
>>
>
> Ein Port kann zwei Werte annehmen: 0 und 1. Mit einem Port kannst Du
> doch eine Weiche umschalten?! Wenn Du also Min.Port=Max.Port=0
> einstellst dann kannst Du zumindestens einen Port umschalten (so war
> zumindestens meine Idee).
>
Ich befürchte, da hast Du etwas falsch verstanden. Ein Port entspricht
(normalerweise) einem Ausgang des Decoders. Ein Weichendecoder für 4
Weichen besitzt also 8 Ports, welche auf 4 Adressen à 2 Ports aufgeteilt
sind (Standard bei M* und DCC). DCC würde auch die Portaddressierung
zulassen, muss aber von der Zentrale+Decoders unterstützt werden. Und
der Wert bedeutet sowiel wie Strom aus oder Strom an. Falls Port 0 und
1 gleichzeitig auf 1 stehen, gibt es ein Grillfest ;-)
Gruss
David
Sven Schlender
> Danke. Werde ich hoffentlich am WE ausprobieren können. Ich hoffe, die
> Bedienung ist schnell lernbar :-)
Ja, das Programm ist wirklich intuitiv bedienbar.
> Ich befürchte, da hast Du etwas falsch verstanden. Ein Port entspricht
> (normalerweise) einem Ausgang des Decoders. Ein Weichendecoder für 4
> Weichen besitzt also 8 Ports, welche auf 4 Adressen à 2 Ports
> aufgeteilt sind (Standard bei M* und DCC). DCC würde auch die
Portaddressierung
> zulassen, muss aber von der Zentrale+Decoders unterstützt werden. Und
> der Wert bedeutet sowiel wie Strom aus oder Strom an. Falls Port 0 und
> 1 gleichzeitig auf 1 stehen, gibt es ein Grillfest ;-)
Mmmh, ich fürchte, das habe ich wirklich falsch verstanden - bzw. falsch
ausgelegt. Steht das so irgendwo? Nur aus der SRCP-Spec. heraus ist das
nicht zu erlesen. Es gibt ja beispielsweise auch die Weichenantriebe von
Kurt mit Servo - die könnten über einen Port komplett angesteuert werden,
oder?
Gruß, Sven.
David Rütti
Hallo Sven
>> Ich befürchte, da hast Du etwas falsch verstanden. Ein Port entspricht
>> (normalerweise) einem Ausgang des Decoders. Ein Weichendecoder für 4
>> Weichen besitzt also 8 Ports, welche auf 4 Adressen à 2 Ports
>> aufgeteilt sind (Standard bei M* und DCC). DCC würde auch die
>Portaddressierung
>> zulassen, muss aber von der Zentrale+Decoders unterstützt werden. Und
>> der Wert bedeutet sowiel wie Strom aus oder Strom an. Falls Port 0
>> und
>> 1 gleichzeitig auf 1 stehen, gibt es ein Grillfest ;-)
>Mmmh, ich fürchte, das habe ich wirklich falsch verstanden - bzw. falsch
ausgelegt. Steht das so irgendwo?
Gute Frage. Ich denke mal in der DCC Spec
<http://www.nmra.org/standards/DCC/standards_rps/DCCStds.html#standards-DCC>
lässt sich etwas finden. Bin auch der Meinung, dass in der SRCP spec nichts
über die Benutzung der Ports steht. Allerdings schon, dass "Value" den Strom
ein/aus steuert. Für das ist ja der "Delay" da, damit der client nicht immer
ans Abschalten denken muss.
> Nur aus der SRCP-Spec. heraus ist das nicht zu erlesen. Es gibt ja
beispielsweise auch die Weichenantriebe
> von Kurt mit Servo - die könnten über einen Port komplett angesteuert
werden, oder?
Theoretisch ja, aber die verhalten sich genau gleich. Und das macht m.E.
auch Sinn, so sind sie mit allen Zentralen/SW/etc kompatibel und zweitens
können die konventionellen Decoder-Magnetantriebe eifach gegen die
Servoantriebe getauscht werden, ohne an der Digitalkonfiguration
(SW/Stellpult) etwas zu ändern.
> Gruß, Sven.
Gruss
David
David Rütti
Hallo Sven
> > Für das Mitsniffen der Kommunkation zwischen eWicht und Server kannst
> > Du Wireshark benutzen.
Fall sehe ich die Kommunikation zwischen eWicht und srcpd.
Und da ist mir aufgefallen, dass ich den Befehl
INIT <bus> GA <addr> <protocol> <optional further parameters>
vermisse. Der INIT <bus> GL ist da... Kannst Du mal schauen, ob dieser
Befehl wirklich nicht ausgelöst wird? Das würde den Effekt ziemlich
sicher erklären.
Zudem meldet sich der eWicht beim Server mit der Protokoll-Version 0.8
an, die neueste stabile Version ist hingegen 0.8.3. Ev. würde ich die
Änderungen verfolgen und anpassen.
Gruss
David
David Rütti
Hallo Sven
Habe noch das eine oder andere TCP Paket gesnifft und langsam
kristallisiert sich das Problem heraus.
- srcpd meldet ein ungültiger Timestamp statt Error 416. Dies würde
ich gelegentlich den srcpd-Entwicklern melden
- Da kein 416 Error gemeldet wird, wird auch kein INIT ausgelöst
(siehe mein vorheriges Mail) -> Workaround immer INIT ausführen
- Wenn ein GA vorgängig in beide Richtungen umgelegt wurde, stimmt der
Time stamp, INIT ist nicht notwendig und der eWicht sollte eigentlich
funktionieren, aber
- Nach dem Wechsel des Portes (Drehknopf), fragt eWicht andauernd nach
dem Status (z.B. GET 1 GA 1 1) und fährt sich fest. Anscheinend
gefällt ihm die korrekte Antwort* des srcpd Servers. --> gibt es da
vielleicht ein Interpretationsproblem mit Port+Value? Zudem stellt
meine Zentrale (IB) ein Port nach 50 ms (oder so) selbständig wieder
aus.
Gruss
David
PS: Bei Interesse schicke ich Dir gerne das ganze Wireshark-Protokoll
PPS: *) ein Auszug:
GET 1 GA 1 0
1243725782.365 100 INFO 1 GA 1 0 0
SET 1 GA 1 0 1 -1
1243725929.289 200 OK
1243725929.290 100 INFO 1 GA 1 0 1
1243725929.297 100 INFO 1 GA 1 0 1
1243725929.401 100 INFO 1 GA 1 0 0
[etc]
Sven Schlender
> Und da ist mir aufgefallen, dass ich den Befehl
>
> INIT <bus> GA <addr> <protocol> <optional further parameters>
>
> vermisse. Der INIT <bus> GL ist da... Kannst Du mal schauen, ob dieser
> Befehl wirklich nicht ausgelöst wird? Das würde den Effekt ziemlich
> sicher erklären.
Es wird zunächst von seitens des eWicht ein GET abgesetzt, um zu überprüfen,
ob das Gerät nicht schon beim Server angemeldet ist. Dieser liefert, falls
bekannt, eine entsprechende INFO-Meldung zurück. In dem Fall wird auch kein
INIT von eWicht generiert.
> Zudem meldet sich der eWicht beim Server mit der Protokoll-Version 0.8
> an, die neueste stabile Version ist hingegen 0.8.3. Ev. würde ich die
> Änderungen verfolgen und anpassen.
Nach meinem Kenntnisstand sind zwischen den Versionen Unterschiede, die die
Implementierung des eWicht-Clients nicht betreffen (z.B. SM u.ä.). Deswegen
wird die Minor-Version nicht wirklich berücksichtigt.
Gruß, Sven.
Sven Schlender
> - srcpd meldet ein ungültiger Timestamp statt Error 416. Dies würde
> ich gelegentlich den srcpd-Entwicklern melden
> - Da kein 416 Error gemeldet wird, wird auch kein INIT ausgelöst
> (siehe mein vorheriges Mail)
Ja, habe ich eben schon drauf geantwortet.
> -> Workaround immer INIT ausführen
Es handelt sich hierbei um einen Fehler im srcpd, der sicher einfach zu
fixen ist, warum sollte der eWicht dafür einen Workaround anbieten?
> - Wenn ein GA vorgängig in beide Richtungen umgelegt wurde, stimmt der
> Time stamp, INIT ist nicht notwendig und der eWicht sollte eigentlich
> funktionieren, aber
> - Nach dem Wechsel des Portes (Drehknopf), fragt eWicht andauernd nach
> dem Status (z.B. GET 1 GA 1 1) und fährt sich fest. Anscheinend
> gefällt ihm die korrekte Antwort* des srcpd Servers. --> gibt es da
> vielleicht ein Interpretationsproblem mit Port+Value? Zudem stellt
> meine Zentrale (IB) ein Port nach 50 ms (oder so) selbständig wieder
> aus.
Das Problem ist der Zeitstempel. Ich kann bloß nicht genau sagen, ob es ein
Denkfehler meinerseits ist, oder das ebenfalls ein srcpd-Problem ist:
Erster Port wird ausgelesen und anschließend auf 1 gesetzt:
> GET 1 GA 1 0
> 1243725782.365 100 INFO 1 GA 1 0 0
> SET 1 GA 1 0 1 -1
> 1243725929.289 200 OK
Hier liefert der Server wahrscheinlich die INFO-Meldungen an alle
angeschlossenen Clients aus:
> 1243725929.290 100 INFO 1 GA 1 0 1
> 1243725929.297 100 INFO 1 GA 1 0 1
Jetzt gibt es noch eine INFO-Meldung, die darüber informiert, dass der Wert
wieder zurückgesetzt wurde (ca. 100 ms später). Da SET mit -1 aufgerufen
wurde, sollte das eigentlich nicht passieren:
> 1243725929.401 100 INFO 1 GA 1 0 0
Nun folgt die Umstellung auf Port 1.
> GET 1 GA 1 1
> 1243725881.705 100 INFO 1 GA 1 1 0
Die Implementierung des eWicht benutzt pro GA-Adresse eine
Verwaltungsstruktur. In dieser Verwaltungsstruktur steht auch immer der
Zeitstempel der letzten Meldung vom Server: 1243725929.401. Falls nun
Nachrichten mit kleineren Zeitstempeln kommen, dann werden diese nicht
berücksichtigt.
> GET 1 GA 1 1
> 1243725881.705 100 INFO 1 GA 1 1 0
Die Antwort beinhaltet einen relativ alten Zeitstempel (vom INIT oder vom
SET), die Antwort wird nicht berücksichtigt. Die eWicht-Zustandsmaschine
fordert mit GET neue Informationen an - und so weiter.
Wie es also aussieht, führt srcpd getrennte Zeitstempel für die Ports eines
GAs. DDW führt einen Zeitstempel pro GA. Welche Implementierung von beiden
richtig ist, ist offen. Für meinen Geschmack ist die DDW-Implementierung
schöner.
Gruß, Sven.
David Rütti
Hallo Sven
>> -> Workaround immer INIT ausführen
>>
>
> Es handelt sich hierbei um einen Fehler im srcpd, der sicher einfach zu
> fixen ist, warum sollte der eWicht dafür einen Workaround anbieten?
>
Gute Frage, weil so der eWicht mit srcpd nicht funktioniert bis der
Fehler behoben ist und sich die Benutzer ärgern? Natürlich ist dies
nicht das Problem von eWicht - ich werde den Bug bestimmt den
srcpd-Entwicklern melden - jedoch was würde passieren, wenn immer ein
INIT gesendet wird?
>> > Wenn ein GA vorgängig in beide Richtungen umgelegt wurde, stimmt der
>> Time stamp, INIT ist nicht notwendig und der eWicht sollte eigentlich
>> funktionieren, aber
>> - Nach dem Wechsel des Portes (Drehknopf), fragt eWicht andauernd nach
>> dem Status (z.B. GET 1 GA 1 1) und fährt sich fest. Anscheinend
>> gefällt ihm die korrekte Antwort* des srcpd Servers. --> gibt es da
>> vielleicht ein Interpretationsproblem mit Port+Value? Zudem stellt
>> meine Zentrale (IB) ein Port nach 50 ms (oder so) selbständig wieder
>> aus.
>>
>
> Das Problem ist der Zeitstempel. Ich kann bloß nicht genau sagen, ob es ein
> Denkfehler meinerseits ist, oder das ebenfalls ein srcpd-Problem ist:
>
> Erster Port wird ausgelesen und anschließend auf 1 gesetzt:
>
>> GET 1 GA 1 0
>> 1243725782.365 100 INFO 1 GA 1 0 0
>> SET 1 GA 1 0 1 -1
>> 1243725929.289 200 OK
>>
>
> Hier liefert der Server wahrscheinlich die INFO-Meldungen an alle
> angeschlossenen Clients aus:
>
>> 1243725929.290 100 INFO 1 GA 1 0 1
>> 1243725929.297 100 INFO 1 GA 1 0 1
>>
>
> Jetzt gibt es noch eine INFO-Meldung, die darüber informiert, dass der Wert
> wieder zurückgesetzt wurde (ca. 100 ms später). Da SET mit -1 aufgerufen
> wurde, sollte das eigentlich nicht passieren:
>
Richtig, der Port wird wieder von der Zentrale (Intellibox) nach 50 ms
zurückgestellt und nicht von srpcd. Allerdings finde ich die
Standardkonfiguration -1 gefährlich bezüglich Durchbrennen von nicht
abgeschalteten Weichenantrieben (Zugegeben, solche Konstellationen sind
selten geworden :-)).
>
>> 1243725929.401 100 INFO 1 GA 1 0 0
>>
>
>
> Nun folgt die Umstellung auf Port 1.
>
>> GET 1 GA 1 1
>> 1243725881.705 100 INFO 1 GA 1 1 0
>>
>
> Die Implementierung des eWicht benutzt pro GA-Adresse eine
> Verwaltungsstruktur. In dieser Verwaltungsstruktur steht auch immer der
> Zeitstempel der letzten Meldung vom Server: 1243725929.401. Falls nun
> Nachrichten mit kleineren Zeitstempeln kommen, dann werden diese nicht
> berücksichtigt.
>
>
>> GET 1 GA 1 1
>> 1243725881.705 100 INFO 1 GA 1 1 0
>>
>
> Die Antwort beinhaltet einen relativ alten Zeitstempel (vom INIT oder vom
> SET), die Antwort wird nicht berücksichtigt. Die eWicht-Zustandsmaschine
> fordert mit GET neue Informationen an - und so weiter.
>
> Wie es also aussieht, führt srcpd getrennte Zeitstempel für die Ports eines
> GAs. DDW führt einen Zeitstempel pro GA. Welche Implementierung von beiden
> richtig ist, ist offen. Für meinen Geschmack ist die DDW-Implementierung
> schöner.
>
Genau, srcpd besitzt 1 Zeitstempel pro Port und speichert die Zeit der
letzten Änderung. Frag mich jetzt nicht, welche Server nun der Norm
entsprechen, die SRCP Definition gibt sich dies bezüglich sehr
wortkarg... Ich denke sogar, dass beide Implementierungen zulässig sind,
denn die Entwickler von srcpd haben auch an der srcp Spezifikation
mitgearbeitet.
Was bleibt, ist eine tolerantere Erkennung alter Meldungen seitens des
Clients, oder wie siehst Du das?
> Gruß, Sven.
>
Gruss
David
Sven Schlender
> > Es handelt sich hierbei um einen Fehler im srcpd, der sicher einfach zu
> > fixen ist, warum sollte der eWicht dafür einen Workaround anbieten?
> >
> Gute Frage, weil so der eWicht mit srcpd nicht funktioniert bis der
> Fehler behoben ist und sich die Benutzer ärgern?
Ja, schon klar - ich fürchte jedoch, den Workaround einzubauen erfordert
mehr Aufwand, als den wirklichen Fehler zu fixen.
> Natürlich ist dies nicht das Problem von eWicht - ich werde den Bug
bestimmt den
> srcpd-Entwicklern melden - jedoch was würde passieren, wenn immer ein
> INIT gesendet wird?
Das Verhalten ist mir nicht klar (die Spec schweigt sich darüber aus). Im
schlimmsten Fall kommt wohl eine 424-Fehlermeldung. Wie soll ein Client
damit umgehen?
Ich war davon ausgegangen, dass ein bereits initialisiertes Gerät nicht
nochmals initialisiert werden muss (bzw. darf). Deswegen auch die
GET-Abfragen.
> Allerdings finde ich die
> Standardkonfiguration -1 gefährlich bezüglich Durchbrennen von nicht
> abgeschalteten Weichenantrieben (Zugegeben, solche Konstellationen sind
> selten geworden :-)).
Ok, das ist ein guter Punkt. Bei meinen Überlegungen zur Implementierung
wollte ich dem Nutzer die Abfrage eines weiteren Parameters sparen.
Möglicherweise macht es aber doch Sinn, diesen mit abzufragen.
Vorschlag:
- Standardmäßig wird der Wert abgefragt.
- Im Webinterface ist ein globaler Parameter einstellbar und die Abfrage
abschaltbar.
> Genau, srcpd besitzt 1 Zeitstempel pro Port und speichert die Zeit der
> letzten Änderung. Frag mich jetzt nicht, welche Server nun der Norm
> entsprechen, die SRCP Definition gibt sich dies bezüglich sehr
> wortkarg... Ich denke sogar, dass beide Implementierungen zulässig
> sind,
> denn die Entwickler von srcpd haben auch an der srcp Spezifikation
> mitgearbeitet.
>
> Was bleibt, ist eine tolerantere Erkennung alter Meldungen seitens des
> Clients, oder wie siehst Du das?
Mmmh, ich glaube, Du hast Recht. Ich muss mir das im Code anschauen, was das
für Änderungen nach sich zieht.
Gruß, Sven.
David Rütti
Hi Sven
Sven Schlender wrote:
> Hi David,
>
>
>>> Es handelt sich hierbei um einen Fehler im srcpd, der sicher einfach zu
>>> fixen ist, warum sollte der eWicht dafür einen Workaround anbieten?
>>>
>>>
>> Gute Frage, weil so der eWicht mit srcpd nicht funktioniert bis der
>> Fehler behoben ist und sich die Benutzer ärgern?
>>
>
> Ja, schon klar - ich fürchte jedoch, den Workaround einzubauen erfordert
> mehr Aufwand, als den wirklichen Fehler zu fixen.
>
Die Bug-Meldung ist abgesetzt. Mal schauen, wie schnell die Entwickler
einen Fix anbieten. Da der eWicht ja nocht nicht (wirklich) öffentlich
ist, kann man mit diesem Punkt auch noch warten.
>> Natürlich ist dies nicht das Problem von eWicht - ich werde den Bug
>>
> bestimmt den
>
>> srcpd-Entwicklern melden - jedoch was würde passieren, wenn immer ein
>> INIT gesendet wird?
>>
>
> Das Verhalten ist mir nicht klar (die Spec schweigt sich darüber aus). Im
> schlimmsten Fall kommt wohl eine 424-Fehlermeldung. Wie soll ein Client
> damit umgehen?
> Ich war davon ausgegangen, dass ein bereits initialisiertes Gerät nicht
> nochmals initialisiert werden muss (bzw. darf). Deswegen auch die
> GET-Abfragen.
>
Der srcpd akzeptiert weitere INIT <bus> GA-Anfragen ohne weiteres.
Gestern wollte ich den TERM <bus> GA Befehl testen und da kam eine
Nicht-Unterstützt-Fehlermeldung zurück. Und tatsächlich ist dieser in
der Spec nicht für GA vorgesehen :-) Anscheinend ist dies für GA nicht
besonders wichtig.
>> Allerdings finde ich die
>> Standardkonfiguration -1 gefährlich bezüglich Durchbrennen von nicht
>> abgeschalteten Weichenantrieben (Zugegeben, solche Konstellationen sind
>> selten geworden :-)).
>>
>
> Ok, das ist ein guter Punkt. Bei meinen Überlegungen zur Implementierung
> wollte ich dem Nutzer die Abfrage eines weiteren Parameters sparen.
>
Genau, ich teile diese Überlegung. Ein Benutzer möchte sich nicht mit
der Einschaltzeit beschäftigen.
> Möglicherweise macht es aber doch Sinn, diesen mit abzufragen.
> Vorschlag:
> - Standardmäßig wird der Wert abgefragt.
> - Im Webinterface ist ein globaler Parameter einstellbar und die Abfrage
> abschaltbar.
>
>
Ich würde es gerade umgekehrt machen.
- Standardmässig wird der Wert *nicht* abgefragt, aber mit Default-Wert
100 oder 500 ms (ich denke, damit können fast alle Leben)
- Im Webinterface ist die Abfrage *einschaltbar* und der globale
Einschaltwert (-1 oder > 0 ms) einstellbar
>> Genau, srcpd besitzt 1 Zeitstempel pro Port und speichert die Zeit der
>> letzten Änderung. Frag mich jetzt nicht, welche Server nun der Norm
>> entsprechen, die SRCP Definition gibt sich dies bezüglich sehr
>> wortkarg... Ich denke sogar, dass beide Implementierungen zulässig
>> sind,
>> denn die Entwickler von srcpd haben auch an der srcp Spezifikation
>> mitgearbeitet.
>>
>> Was bleibt, ist eine tolerantere Erkennung alter Meldungen seitens des
>> Clients, oder wie siehst Du das?
>>
>
> Mmmh, ich glaube, Du hast Recht. Ich muss mir das im Code anschauen, was das
> für Änderungen nach sich zieht.
>
Danke.
Ich wünsche Dir einen schönen Nachmittag
David