Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)

[bismosa]

Hallo,

Aktuell nicht. Wäre evtl. eine Überlegung, da der Modus ja sonst echt keinen Sinn macht.

Dann sollte das entweder in die Doku (wobei dies dann vermutlich schnell übersehen wird) oder automatisch runtergesetzt werden. 

Das Modul macht unter der Haube wahrscheinlich auch nichts anderes als dein Shell Script - es öffnet die w1_slave Datei und liest den Inhalt aus. Sollte sich daher gleich verhalten.

Leider nur theoretisch. Es kommt in meinem System immer wieder vor, das beim Auslesen über das Modul es zu leeren Auslesevorgängen kommt. (Wird jetzt in deinem Modul super als "empty_data" erkannt. Einen Auslesefehler gab es bei einem Sensor bereits.
In einem Shell script kommt dies nie vor. Vergleich auch die längere Diskussion hier: https://forum.fhem.de/index.php?topic=11142.30
Ich vermute, dass es zu irgendwelchen Timing-Problemen in meinem System (die Kabel sind echt lang und die Sensoren vermutlich nicht die besten...) kommt.
Aber eigentlich ist dies ein anderes Thema. Ich wollte nur einen Impuls (Idee) geben, wie man das Auslesen auch ohne Fork (bzw. ohne doppeltes Auslesen) gestalten könnte. Ob das wirklich funktioniert...keine Ahnung.

Modul ist (mit ein paar weiteren kleinen Verbesserungen) im SVN eingecheckt und sollte ab morgen per update zur Verfügung stehen

Ich freu mich drauf. Werde das dann gleich die Tage vollständig umstellen 

Gruß
Bismosa

[Adimarantis]

Ich vermute, dass es zu irgendwelchen Timing-Problemen in meinem System (die Kabel sind echt lang und die Sensoren vermutlich nicht die besten...) kommt.

Ich nehme mal an "echt lang" ist mehr als die 3m + 1m gemeinsame Zuleitung die ich an meinen 10 Sensoren hab. Das aber auf einem Raspberry 1. Failures hab ich da eigentlich keine (nonblocking).
Da könntest du noch probieren die conv_time höher als der Default einzustellen - das wäre dann aber eben wieder nonblocking mit fork().
Oder auch die Precision runterdrehen (so genau sind die Dinger sowieso nicht, da sollte das nicht so viel ausmachen) und sehen, ob das was bringt.

Bei sehr vielen Sensoren ist für dich aber evtl. auch der therm_bulk_read Modus interessant (dann wieder mit "blocking" mode ohne fork()). Kann ich bei mir aktuell nicht umstellen, da der Raspberry mit den 10 Sensoren noch mit Stretch läuft.

[Adimarantis]

Ich schaue mir gerade noch an, wie man das mit dem "timer" mode und conv_time=2 löst.
Ich sehe mehrere Varianten:
1. Automatisch conv_time=2 setzen wenn mode geändert wird - Problem: Wird ausgehebelt wenn precision oder conv_time manuell geändert werden
2. Setzen von mode=timer blockieren wenn conv_time zu gross - Selbes Problem wie oben, kann ausgehebelt werden
3. Bei mode=timer oder mode=blocking eine Warnung in die "failreason" schreiben, wenn die Abfrage länger als 0.5s dauert

Persönlich gefällt mir Variante 3 am Besten, da man hier jeder einstellen kann was er will (es passiert ja nichts fatales wenn falsch eingestellt wird) und man es nicht versehentlich aushebeln kann (alle Fälle zu prüfen und z.B. klammheimlich den mode umstellen ist auch nicht schön).
Variante 3 deckt auch gleich Konfigurationsfehler mit der "blocking" Methode ab.

Mir ist übrigens noch ein Problem mit der therm_bulk_read Methode aufgefallen: Die Einstellung wird nicht gespeichert und ist nach einem Restart weg. Fix ist schon fertig - spiele ich aber erst heute abend (für update morgen) ein - vielleicht ergeben sich bis dahin ja noch weitere Änderungen.

Das bismosa geschilderte "update macht refresh" Problem, kann ich nur bedingt nachvollziehen: Bei mir werden die Readings gleich drauf rot und ich gebe bereits "undef" zurück. Allerdings schaltet der Hilfetext unter dem "set" um, so das es so aussieht als würde die Seite refreshed. Dagegen kann ich nichts machen.

[bismosa]

Hallo!

Ich habe heute direkt ein Update gemacht und die Sensoren umgestellt. 

Ich habe 10 Sensoren und eine Kabellänge von insgesamt vermutlich 30m. Leider musste ich die Kabel in zwei Richtungen verteilen. Damit ich keine Sternförmige Verkabelung bekomme, muss ich von der einen Seite einen langen Weg wieder zurück zum Verteiler nehmen. Es handelt sich bei mir um geschirmte CAT7 Kabel.
Zum eingrenzen des Fehlers bei mir habe ich derzeit zwei 1-Wire Busse aktiviert. Derzeit kommen noch drei Sensoren mit Problemen in Frage.

Leider funktioniert das Modul dann nicht mehr. Du benutzt den
$w1_path="/sys/devices/w1_bus_master1"
Dadurch werden nur die Geräte erkannt, die an dem einen Busmaster hängen.
Ich habe das bei mir mal umgestellt auf:
$w1_path="/sys/bus/w1/devices"
Dadurch können alle ausgelesen werden.
Ob das noch weitere Auswirkungen hat, weiß ich nicht. Dafür habe ich den Code noch nicht genau genug studieren und verstehen können. 

Folgendes ist mir sonst aufgefallen: (Sorry, kein meckern! Ich weiß wie viel Arbeit da schon drin steckt!)
- Wird ein Device im System nicht mehr erkannt (z.B. Kabelbruch) kommt es zu keinen Fehlermeldungen/"failures".  Zumindest nicht, wenn nach einem Neustart die Sensoren nicht vorhanden sind.
- Ich hatte testweise einen Sensor im "timer" Modus. Obwohl ich keine Werte bekommen hatte wurden auch hier die "failures" nicht hochgezählt. Ich vermute das gleiche Problem wie oben?
- Ich habe noch nicht ganz verstanden, wie ich den Busmaster definieren muss. Im Wiki steht

Das Betriebssystem listet alle bekannten Devices im sysfs Verzeichnisbaum unter /sys/device/w1_bus_master - der benötigte String entspricht dem Namen der entsprechenden Unterverzeichnisse.

Es müsste doch /sys/devices/ sein?

Leider bin ich jetzt noch nicht weiter zum testen gekommen. Bin noch dran, muss aber nachdem ich meinen Raspberry am Wochenende getauscht habe (der alte hatte mehrere zerschossene GPIO-Ports...7V waren zu viel) das Problem, das 2 Sensoren nun gar nicht mehr wollen. Da suche ich noch nach dem Problem.

Ich bin vielleicht gerade nicht der beste Tester im Moment. Meine Probleme sind doch sehr speziell 

Ich schaue mir gerade noch an, wie man das mit dem "timer" mode und conv_time=2 löst.
...
3. Bei mode=timer oder mode=blocking eine Warnung in die "failreason" schreiben, wenn die Abfrage länger als 0.5s dauert

Ich denke, das könnte gut sein. Vielleicht noch ein Hinweis in doe Commandref, das die Zeit geändert werden sollte.
Ist es möglich immer die Abfragezeit als (extra) Reading einzubauen? Ist ja ggf. ein interessanter Wert, wenn man Blocking arbeitet.

Das bismosa geschilderte "update macht refresh" Problem, kann ich nur bedingt nachvollziehen: Bei mir werden die Readings gleich drauf rot und ich gebe bereits "undef" zurück. Allerdings schaltet der Hilfetext unter dem "set" um, so das es so aussieht als würde die Seite refreshed. Dagegen kann ich nichts machen.

Ich werde das nochmal beobachten. Heute klappte das bei mir auch. Kann es vielleicht sein, dass es mit mode:"timer" zusammenhängt?

DANKE für deine Bemühungen!

Gruß
Bismosa

[Adimarantis]

Damit ich keine Sternförmige Verkabelung bekomme, muss ich von der einen Seite einen langen Weg wieder zurück zum Verteiler nehmen

Wo siehst du das Problem mit sternförmiger Verkabelung? Bei mir geht ein Kabel vom Raspi weg zu einer Verteilerdose, und da sind alle Sensoren "zusammengepfriemelt", gehen also sternförmig mit weiteren 3m weg - klappt wunderbar.

Zum eingrenzen des Fehlers bei mir habe ich derzeit zwei 1-Wire Busse aktiviert. Derzeit kommen noch drei Sensoren mit Problemen in Frage.

Wie definierst du den zweiten Bus und wie schaut dann dein Verzeichnis /sys/bus/w1/devices aus? Würde ich mal nachstellen und schauen ob ich eine generische Lösung finde

Ich habe das bei mir mal umgestellt auf:
$w1_path="/sys/bus/w1/devices"
Dadurch können alle ausgelesen werden.
Ob das noch weitere Auswirkungen hat, weiß ich nicht. Dafür habe ich den Code noch nicht genau genug studieren und verstehen können. 

Auf den ersten Blick macht das nur das therm_bulk_read kaputt, da das im Verzeichnis des Busmaster beheimated ist. Wie gesagt, müsste ich mal nachstellen.

- Wird ein Device im System nicht mehr erkannt (z.B. Kabelbruch) kommt es zu keinen Fehlermeldungen/"failures".  Zumindest nicht, wenn nach einem Neustart die Sensoren nicht vorhanden sind.

Das gibt bei mir eine "open_device" failure. Die entsprechende Datei in sysfs ist sicher weg?
EDIT: "Neustart" überlesen - ja, das stimmt und ich weiss auch warum. Schau ich mir an.

- Ich habe noch nicht ganz verstanden, wie ich den Busmaster definieren muss. Im Wiki steht Es müsste doch /sys/devices/ sein?

Ja, aber das ist eigentlich nur der Hinweis wo die Devices zu finden sind. Der FHEM Busmaster wird einfach mit "define RPi RPI_1Wire BUSMASTER" definiert. Da muss ich wohl die Doku noich ein wenig verständlicher machen.

Ist es möglich immer die Abfragezeit als (extra) Reading einzubauen? Ist ja ggf. ein interessanter Wert, wenn man Blocking arbeitet.

Hab ich in meiner aktuellen Testversion als verstecktes helper Reading (nur mit list sichtbar) schon drin. Könnte man aber auch ganz normal als Reading machen.

[bismosa]

Hallo!

Wo siehst du das Problem mit sternförmiger Verkabelung? Bei mir geht ein Kabel vom Raspi weg zu einer Verteilerdose, und da sind alle Sensoren "zusammengepfriemelt", gehen also sternförmig mit weiteren 3m weg - klappt wunderbar.

"Sollte man ja nicht machen". Bei 3m vielleicht noch kein Problem...bei mir eher schon. Es kann aber auch sein, dass es an einem defekten Sensor liegt. Dann will ich verkabelungsprobleme wenigstens ausschließen.
Ich habe jetzt nochmal auf blauen Dunst einen Sensor getauscht. Im Moment funktioniert alles prächtig mit den Grundeinstellungen  Noch kein Lesefehler.

Wie definierst du den zweiten Bus und wie schaut dann dein Verzeichnis /sys/bus/w1/devices aus? Würde ich mal nachstellen und schauen ob ich eine generische Lösung finde

In der /boot/config.txt

Code: [Auswählen]

dtoverlay=w1-gpio
#2.1-Wire bus GPIO17 - Header Pin 11
dtoverlay=w1-gpio,gpiopin=17


Auf den ersten Blick macht das nur das therm_bulk_read kaputt, da das im Verzeichnis des Busmaster beheimated ist. Wie gesagt, müsste ich mal nachstellen.

Leider auch das udev script. Das ist auch nur auf einen Bus ausgelegt. Ich habe das gerade mal für mich angepasst:

Code: [Auswählen]

SUBSYSTEM=="w1*", PROGRAM="/bin/sh -c '\
chown -R root:gpio /sys/devices/w1*;\
chmod g+w /sys/devices/w1_bus_master*/therm_bulk_read;\
chmod g+w /sys/devices/w1_bus_master*/*/resolution;\
chmod g+w /sys/devices/w1_bus_master*/*/conv_time;\ '"Dann scheint es auch wieder für alle zu funktionieren.

Vielleicht müsste man bei der Definition des Busmasters auch definieren, welcher es ist. Oder "generiesch" ermitteln, wie viele im System sind.

Ich musste leider auch gerade feststellen, dass mode=timer mit nicht neu gesetzter conv_time zu einem nicht-reagieren meines FHEMs geführt hat. Da 10 Sensoren mit einer zu langer Zeit abgefragt wurden, wurde das Web-Interface auch nach ein paar Minuten noch nicht angezeigt.
Ich habe die Hintergründe der Zeit noch nicht verstanden. Ich glaube aber das wird direkt im Treiber gesetzt? Lässt sich das abfragen? Dann könnte vor einem "Polling" die Zeit geprüft werden und ggf. neu gesetzt werden (falls durch andere Änderungen verändert). Dann wäre das fehlerfreier. (Aber doch wieder die Variante 1)

Ja, aber das ist eigentlich nur der Hinweis wo die Devices zu finden sind. Der FHEM Busmaster wird einfach mit "define RPi RPI_1Wire BUSMASTER" definiert. Da muss ich wohl die Doku noich ein wenig verständlicher machen.

Das habe ich jetzt auch endlich verstanden. Die | in der Beschreibung der Definition sind ja als "oder" gedacht. Also entweder BUSMASTER oder ein Device. War ich vielleicht nur zu blöd um es zu verstehen.

Hab ich in meiner aktuellen Testversion als verstecktes helper Reading (nur mit list sichtbar) schon drin. Könnte man aber auch ganz normal als Reading machen.

Ich würde das toll finden! 

Gruß
Bismosa

[Adimarantis]

"Sollte man ja nicht machen". Bei 3m vielleicht noch kein Problem...bei mir eher schon. Es kann aber auch sein, dass es an einem defekten Sensor liegt. Dann will ich verkabelungsprobleme wenigstens ausschließen.

Hab irgendwo gelesen, dass diese Reflexionen erst bei "mittlerer Leitungslänge" um die 15m relevant werden. Mit 5m braucht man sich da mit Stern keinen Kopf zu machen.

An die Möglichkeit mit mehreren "Bussen" hatte ich gar nicht gedacht. Ist sogar eine Lösung für das therm_bulk_read Problem mit non-therm Devices (ich möchte noch einen Counter verwenden - den häng ich einfach an den zweiten Bus und dann kann ich bulk_read für die Temperaturen verwenden)

Nachdem ich heut frei hab und in Bastellaune bin: Vielleicht kannst du beiliegende Version mal testen bevor ich die verteile.
1. Unterstützt mehrere Busmaster (das war gar nicht so trivial wie ich dachte) indem man jetzt optional BUSMASTER-x definieren kann. Einfach BUSMASTER nimmt wie gehabt w1_bus_master1
2. Pfad auf /sys/bus/w1/devices umgestellt - solange man keinen BUSMASTER für Autocreate oder bulk_read verwendet, sind dort ja dann alle Devices auf einem Haufen
3. BUSMASTER zeigt im Internal "devices" (weil "slaves" ja politisch nicht mehr korrekt ist) die Liste der zugeordneten Devices (damit man auch weiss für welche dann das bulk_read gilt)
4. Mode Wechsel auf "timer" nur möglich wenn conv_time<10 (wie du angemerkt hast, ist das so heikel, das ich das abfangen möchte, auch wenn man es theoretisch aushebeln kann)
5. Reading "duration" gibt letzte Auslesedauer an
6. Wenn die letzten zwei durations >0.5s waren, gibt es eine Warnung in failreason
7. failreason wird nach 5 Minuten ohne neue Meldungen auf "ok" gesetzt (da sonst ggf. verwirrend)
8. Wenn das Device beim Neustart nicht mehr existiert wird failreason auf "Device not found" gesetzt
9. udev entsprechend deines Posts angepasst

Gruß,
Jörg

[bismosa]

Hallo!

Hab ich direkt ausgetauscht. Tests folgen.

DANKE für Deine Bemühungen! Finde ich richtig Cool 

Für den Fall von "Device not found" beim Starten...ich persönlich würde es besser finden, wenn dann weiterhin im Intervall der Fehlerzähler mitgeht. (Und auch im Intervall weiter geprüft wird?)
Ich habe bei mir die Spannungsversorgung über einen Transistor gelegt. Kommt es zu mehr als 10 Lesefehlern, wird die Spannungsversorgung kurz unterbrochen. Meist funktionieren die Sensoren dann wieder.

Ich habe nun nach einem reboot kein Attribut "mode" mehr in den Devices. Kann aber auch sein, das ich vergessen hatte zu speichern?

Ich hatte vorher ja schon einen Sensor getauscht. Der war nicht das Problem. Ich tausche nun erstmal den nächsten. Vorhin war wieder der komplette Bus mit drei Sensoren ausgefallen.

Gruß
Bismosa

[Adimarantis]

Für den Fall von "Device not found" beim Starten...ich persönlich würde es besser finden, wenn dann weiterhin im Intervall der Fehlerzähler mitgeht. (Und auch im Intervall weiter geprüft wird?)

Ist zwar etwas speziell, tut aber auch nicht weh. In meinem ersten Versuch hatte ich es mir halt einfach gemacht - war jetzt ein bisschen mehr zum tüfteln.

Ich habe nun nach einem reboot kein Attribut "mode" mehr in den Devices. Kann aber auch sein, das ich vergessen hatte zu speichern?

Das kann eigentlich nicht sein. Ich mache ständig "shutdown restart" oder sogar reboots beim Testen (eigenes Testsystem) und "mode" stimmt.
[/quote]
Update anbei.

[bismosa]

Hallo,

du bist ja schneller beim erstellen neuer Versionen als ich testen kann 

Auch diese Version ist eingespielt und läuft derzeit stabil.

Ist zwar etwas speziell, tut aber auch nicht weh. In meinem ersten Versuch hatte ich es mir halt einfach gemacht - war jetzt ein bisschen mehr zum tüfteln.

Perfekt. Konnte ich aber noch nicht testen, da bisher die Sensoren alle nach einem Neustart funktioniert haben.

"mode" hatte ich dann vielleicht wirklich nicht gespeichert. Sorry.

Sieht also soweit erstmal alles richtig gut aus! Ich muss nur noch das Problem in meiner Installation finden.

Gruß
Bismosa

[Adimarantis]

Ist jetzt auch eingecheckt. Schluss für heute

[Adimarantis]

Die aktuelle Version hat noch einen Bug beim Startup (nach "shutdown restart") der auf manchen Systemen (habe ich nur auf meinem Raspi 1 gesehen) dazu führen kann, dass immer "empty_data" Fehler kommen bis man manuell einmal "set update" macht.
Bei der Gelegenheit habe ich noch die ganze Startreihenfolge überarbeitet.

Update im SVN https://svn.fhem.de/fhem/trunk/fhem/FHEM/58_RPI_1Wire.pm oder morgen per update

[bismosa]

Hallo!

Heute direkt wieder das Update eingespielt.

Ich habe gerade einen Sensor getauscht (im laufenden Betrieb). Dann habe ich die Definition des Devices nur angepasst.
Interessant war, dass ich die ersten Minuten eine Temperatur von "25.000" auch bei mehreren Abfragen bekommen habe.
Ist das vielleicht ein "Fehlerwert"?

Ich werde als nächstes alle Sensoren, die ich noch so rumfliegen habe an einen dritten Bus hängen. Mich interessiert, ob es dann dort zu Auslesefehlern (wegen einem defekten Sensor) kommt.
Damit kann ich dann auch mal das Bulk-Read probieren. 

Danke! (Kann man nicht oft genug sagen. Ich weiß wie viel Arbeit da drin steckt!)

Gruß
Bismosa

[bismosa]

Hallo!

Muss leider nochmal nachdieseln.
Ich habe jetzt den 3. Bus aktiviert und habe hier 6 weitere Sensoren dran. Klappt soweit prima.
Ich wollte hier nun mal das "set therm_bulk_read" ausprobieren. Leider gibt es den Set-Befehl nicht.
Ich vermute es liegt an:
Zeile 158

Code: [Auswählen]

if ($device ne "BUSMASTER") {Hier wird mein BUSMASTER-3 ausgeschlossen.

Sorry. Aber kein dringendes Problem. Ich werde das jetzt erstmal ein paar Tage normal laufen lassen um zu beobachten, ob meine Sensoren so fehlerfrei laufen.

Gruß
Bismosa

[Adimarantis]

$device sollte ohne -3 sein.
Hast du geschaut ob unter w1_bus_master3 die Datei therm_bulk_read existiert und schreibar ist?
Der set Befehl bleibt auch "weg wenn weg" und kommt erst nach einem "shutdown restart" wieder.