Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)

[Adimarantis]

ja, das mit den Bits ist etwas inkonsistent, aber ist ja hinzubekommen. Dann ist das zumindest soweit klar.
Muss mir dann überlegen, wie ich da eine generische Lösung hinbekomme, die gleich die anderen Schalter mit abdeckt (zumindest theoretisch)

Kann jetzt nicht versprechen, wann ich dazu komme. Wahrscheinlich erst wenns Wetter wieder schlechter wird  .Sobald ich was habe, poste ich hier eine Testversion.

Jörg

[tschirch]

Prima. Freue mich auf das Testen.

Steffen 

[Adimarantis]

Mal ein Zwischenstand - nur zum Testen für Steffen, gut möglich das manches was vorher ging mit diesem Stand nicht mehr geht (Der Umbau der set/get Befehle ist noch nicht ganz abgeschlossen und getestet)

Bitte folgendes Testen:
1. Es erscheinen korrekt die set Befehle für pioa und piob
2. Ein z.B. "set pioa on" schaltet tatsächlich etwas und zwar nur die gewählte pio

Edit 22.9.: Nachdem die Datei bisher noch nicht runtergeladen wurde, ersetze ich sie gleich hier mit einem update. Dieses sollte bis auf die ungetesten Schalter eigentlich soweit komplett funktionieren und implemetiert ein neues feature "set clear" mit dem man Fehlerzustand und Zähler zurücksetzen kann. Ist bei mir für meine Temperatursensoren inzwischen schon wieder produktiv im Einsatz.

[Adimarantis]

Hi Steffen,

danke fürs Testen. Nachdem ich den Zweig gar nicht wirklich testen konnte, waren da noch paar grundlegende Fehler drin, die hoffentlich deine seltsamen Testergebnisse erklären.
Allein dass pioa und piob bei dir auch beim Lesen vertauscht sind, verstehe ich nicht. Die einzige Änderung war das "c" auf "C" bei der Konvertierung - und das hast du doch getestet, oder?
Ich hab jetzt mal den check ausgehebelt, der verhindert dass man Devices definiert die nicht existieren und mir damit ein 3a-* Device definiert. Jetzt krieg ich nur noch den Fehler, dass er das Device nicht schreiben kann, was ja bei mir korrekt ist.
Bitte erneut testen. Gegebenenfalls verbose=5 setzen und logfile posten.

Jörg

[tschirch]

Hi Jörg,
danke fürs Programmieren.
Die set-Befehle arbeiten jetzt. Zwar inhaltlich immer noch falsch, aber ich schaue mir morgen dein Programm mal genauer an. Ich bin mir nicht sicher, ob uns verbose 5 weiterbringt.
Meiner Meinung nach ist a und b von Anfang an vertauscht. Also auch schon vor dieser Änderung. Aber ich kann mich auch täuschen. Ich habe nur Module von Esera zur Verfügung. Durch den Schaltplan kann man die beiden Relaisausgänge im Gehäuse zuordnen. Mein Vorschlag: Wir lassen es erst mal so, wie es ist. Die Zuordnung kann man später immer noch ändern. Im Moment ist das nicht ganz so wichtig. Vielleicht gibt es noch jemanden, der es auch überprüfen kann. Ich schaue auch noch mal in der Beschreibung vom RaspiOS nach.
Ich melde mich dann wahrscheinlich morgen nochmal.

Steffen

[Adimarantis]

Danke fürs Testen.

Laut Kernel Beschreibung
https://www.kernel.org/doc/html/latest/w1/slaves/w1_ds2413.html
Ist Bit 0 der PIO A zugeordnet und Bit 2 der PIO B
Entsprechend verwende ich "1" (=binär 0000 0001) für PIO A und "4" (=binär 0000 0100) für PIO B.
Die einzige Unsicherheit wäre jetzt ob "pack" das richtig herum kodiert, wenn er es aber umdrehen würde, dann würden die Bits ja in 7 und 5 landen und somit gar nichts gehen.
Daher gehe ich eher davon aus, dass die Zuordnung in deiner Hardware vertauscht ist.

Gruß,
Jörg

[tschirch]

Gut, dass du die Kernelquelle ansprichst. Was du schreibst gilt für den Status. Aufgepasst beim Schreiben nach output. Da ist Bit0 pioa und Bit1 piob. Außerdem ist die Logik invertiert. "1" bedeutet aus und "0" ist an! Das steht in der Quelle leider nicht drin.
Es darf also "nur" eine 3, 2, 1 oder 0 ausgegeben werden. Bei dir ist eine 5 und 4 dabei (sehe ich mit verbose 5).

3: pioa aus, piob aus
2: pioa an, piob aus
1: pioa aus, piob an
0: pioa an, piob an

und im status

pioa aus, piob aus: 0000 1111 ist 0x0F
pioa an, piob aus: 0011 1100 ist 0x3C
pioa aus, piob an: 1100 0011 ist 0xC3
pioa an, piob an: 1111 0000 ist 0xF0

Bit0 bis Bit3 invertiert, bei Bit4 bis Bit7 ist "1" an und "0" aus.
Alles klar?

Steffen

[Adimarantis]

Ok, also die Logik ist sowohl bei Lesen als auch beim Schreiben invertiert? (Fürs Schreiben steht es ja in der Beschreibung, hatte ich nur übersehen).
Im Status stehen ja zwei Bits pro PIO - die scheinen in deinem Beispiel immer gleich zu sein. Ich betrachte jetzt nur den "PIN State" und ignoriere den "Output Latch State". Oder hat der aus deiner Sicht irgendeine Relevanz?

Ich habe ja parallel noch die Unterstützung für den DS2406 drin. Dort finde ich in der Kernel Beschreibung nichts zur Invertierung, also muss ich den wahrscheinlich andersrum abbilden.

Die Bits 4-7 sind ja nur zu Konsistenzprüfung, was laut Kernelbeschreibung bereits der Treiber macht. Daher sollte es ok sein sie einfach zu ignorieren.

Sollte jetzt alles angepasst sein. Neue Runde.

Jörg

[tschirch]

Ich kenne jetzt den Unterschied zwischen Latch-State und Pin-State. Damit meine angeschlossenen Geräte nicht jede Schaltbewegung mitmachen habe ich die 12V-Versorgung für die Relais abgeklemmt. Und siehe da: Pin-State ist immer 0!
Kannst du zum Testen (oder auch für immer) bitte den Latch-State nehmen. Das ist Bit1 für pioa und Bit3 für piob. Danke.

Steffen

[Adimarantis]

Hi Steffen,

grundsätzlich hört sich das so an als wäre der Pin State dann final besser, denn er repräsentiert dann den tatsächlichen Zustand des Schalters, der Latch State ist quasi nur die "Schaltanforderung".
Ändern kann man das in Zeile 577:
Original:

Code Auswählen Erweitern

$retval.= " pioa=".($pio[0]==1?0:1);
$retval.= " piob=".($pio[2]==1?0:1);
Latch State:

Code Auswählen Erweitern

$retval.= " pioa=".($pio[1]==1?0:1);
$retval.= " piob=".($pio[3]==1?0:1);

Ich hänge dir mal eine Version mit latch state an. Wenn wir mit dem Testen durch sind, würde ich aber wohl wieder auf die Bits 0 und 2 gehen.

Jörg

[tschirch]

Was hältst du davon, das Thema anders anzufassen. Ich stelle dir eines von meinen DS2413-Modulen zur Verfügung und du kannst in Ruhe selber testen. Für den den Übergang von deinem 1-wire zum Modul musst du dann selber sorgen. Mit der Klemmleiste ist das recht einfach zu bewerkstelligen. Mit einem 12V-Netzteil kommt dann auch der Pin-Status. Was meinst du?

Steffen

Du darfst diesen Dateianhang nicht ansehen.

[Adimarantis]

Grundsätzlich kann man das schon machen.
Lohnt es sich denn aber noch? Ich dachte eigentlich wir sind jetzt langsam auf der Zielgeraden.

Jörg

[tschirch]

Der Status der Schalter stimmt nicht . Das war auch vor der letzten Änderung mit den Bits1 und 3. Weißt du, wo du da ansetzen sollst? Das ging aber schon mal. Meiner Meinung nach haben wir zu große "Sprünge" gemacht. Ich hatte mal einen Kollegen, der sagte dazu: Jetzt kommen wir in's Schwingen.

Wenn wir ohne das Verschicken des Moduls weitermachen,dann müsstest du als erstes den Status wieder in Ordnung bringen. Ich weiß nicht, was dazu geführt hat, das es nicht mehr geht.

Nur dass du mich richtig verstehst, es ist ein Vorschlag. Ich dachte, damit wird es einfacher. Kostet auch nur 1,95€ für eine Richtung. Bin aber auch bereit mit dir so weiterzumachen. Ok?

Steffen

[Adimarantis]

Hi Steffen,

Ich glaube das kriegen wir einfacher hin.
Verstehe ich jetzt richtig, dass nur der Status nicht stimmt, das Setzen jetzt aber soweit hinhaut?

Dann würde ich folgendes vorschlagen:
Du kopierst das "status" File für jeden Zustand mit einem entsprechenden Namensschema (z.B. status_on_off für PIOa on, PIOb off) ins normale Filesystem - und zwar für jede Kombination - am Besten um das mit dem Latch auch abzubilden sowohl mit anklemmten 12V sowie ohne. Die zippst du alle zusammen und postest die hier.

Dann kann ich diese Files dem Modul als Testeingabe unterjubeln und schauen, dass er genau das anzeigt was er soll (halt entsprechend dem, was im Namen steht). Dann sollte das doch eigentlich hinzukriegen sein.

Jörg

[tschirch]

Hey, das ist eine coole Idee. Das mache ich.

Steffen