Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)

Begonnen von Adimarantis, 18 Oktober 2021, 16:16:58

Vorheriges Thema - Nächstes Thema

Adimarantis

Hallo zusammen,

als fleissiger Nutzer von 1-Wire Temperatursensoren habe ich lange Zeit das alte GPIO4 Modul unter Contrib genutzt, bis ich bemerkt habe, dass im Forum auch neuere Versionen davon "rumgeistern".
Es scheint sich aber niemand gefunden zu haben, der es wieder offiziell maintainen will. Ich möchte hierzu einen Versuch starten.

Dieses Modul basiert zwar auf den mir bekannten GPIO4 Versionen, wurde aber von grundauf neu konzipiert.

Funktionale Unterschiede zum GPIO4 Modul aus dem Forum:
- Erkennt alle in https://www.kernel.org/doc/html/latest/w1/slaves/index.html genannten 1-Wire Chips (unterstützt deswegen aber nicht zwangsläufig auch alle)
- Kann den Zustand der beiden bislang nicht supporteten 2-port switches lesen (ungetestet)
- Führt ein Attribut tempFactor zusätzlich zum tempOffset ein
- Einstellbare Anzahl Dezimalstellen der Temperaturausgabe
- Unterstützt die resolution/precision und conv_time zu lesen - und abhängig von den Rechten auch zu setzen
- Wahlweise blocking, non-blocking und timer-gesteuerter "2-fach-lese" Modus (mehr dazu unten)
- Hilfestellung wie man per udev die resolution und conv_time dauerhaft schreibbar macht
- Vollständige(?) englische Inline Dokumentation
- Unterstützung von Robue DS18B20 clones and DHT11/22 (ungetestet)
- und eben vollständig neu geschrieben, womit ich hoffe auch Bugs und Unschönheiten des alten Moduls behoben zu haben

Die Unterschiede zum Modul in contrib zähle ich jetzt nicht auf - in der Summe konnte es nur blockierend messen und kannte nur Temperatursensoren.

Warum heisst das Modul "RPI_1Wire" und nicht "GPIO4"?
- So lässt es sich parallel zu GPIO4 installieren (nicht jeder hat eine Testumgebung) - der Parallelbetrieb sollte problemlos möglich sein (ich kann aber nicht ausschliessen, dass gelegentliche "Kollisionen" bei Messungen mal zu falschen Werten führen)
- Es gibt laut FHEM Statistik 488 Installationen mit 1607 Instanzen des alten GPIO4 Moduls (und nicht jeder hat global->sendStatistics aktiviert). Nur was für Versionen sind das? Contrib? Forum Variante 1-x? Selbst gebastelt? Wenn ich ein GPIO4 über Update zur Verfügung stelle, dann werden alle diese Versionen mit ungeahnten Folgen überschrieben.
- Mein Modul ist zwar weitgehend kompatibel zu GPIO4 - aber eben nicht 100%
- Fügt sich in der Modulübersicht schön zu RPI_GPIO ein

Kurze Info zum mode=timer Feature:
Auf der Suche nach Optionen die Sensorabfrage möglichst resourcenschonend aber eben nicht blockierend zu gestalten, bin ich auf einen kleinen "hack" gekommen.
Indem man die conv_time der Temperatursensoren auf 2ms stellt (1 geht nicht, da setzt er aus unerfindlichen Gründen auf 576ms), erreicht man dass das Auslesen der Temperatur sofort zurückkehrt.
Jetzt ist natürlich noch keine Messung erfolgt, aber es wurde trotzdem eine getriggert. Daher wird im "timer" mode ein interner timer auf 1.5s gesetzt und der Wert erst dann final ausgelesen und schon hat man eine Methode den Sensor ganz ohne fork() performant auszulesen.

Eine weitere Method ist über den w1_bus_master regelmäßig ein "therm_bulk_read" abzustossen. Wenn die einzelnen Sensoren ein kürzeres polling Intervall haben, dann kann man diese auf "blocking" lassen und bekommt immer sofort einen halbwegs aktuellen Wert. Leider musste ich feststellen, das die Kernel-Implementierung einen kleinen Bug hat: Sobald weitere Geräte (außer Temperatursensoren) angeschlossen sind, funktioniert es nicht mehr (jeder Sensorabfrage dauert nach wie vor wie die conv_time). Wer nur Temperatursensoren hat, kann das Feature jedoch getrost einsetzen.

Zur Verwendung von DHT11/DHT22 Sensoren habe ich ein einfaches Perl Modul (mit C-Code Teil) geschrieben, welches entweder unter https://github.com/bublath/rpi-dht ausgecheckt und installiert werden oder für Raspberry unter Buster hänge ich ein kleines Debian Paket an, welches mit "sudo apt install ./name.deb" installiert werden kann (danach FHEM neu starten)

Update 25.10.21: therm_bulk_read hinzugefügt. Dokumenation erweitert. Kleine (eher unerhebliche) Bugfixes.
Update 27.10.21: Veröffentlichung über Update (bzw. svn) daher das Perl Modul hier entfernt.

Gruß,
Jörg

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Hi Jörg,

der Modulname gefällt mir nicht. Mir geht zu wenig die Einsetzbarkeit(nur auf dem Raspberry) aus dem Namen hervor und grenzt sich nicht genügend deutlich von den anderen OW...-Modulen ab. Vorschlag Rpi_OW  :-\

Bisher nur kurz mit einem DS18B20 getestet: es blockiert scheinbar nicht(sonst hätte mein freezemon mir freezes gemeldet). Das reading temperature wird brav gefüllt. Allerdings erfolgt kein update auf state.

Beim DHT22 gibt es mit verbose=5
Zitat2021.10.18 17:27:26 4: KlimaKeller1: Poll for dht took 0.026505 s
2021.10.18 17:27:26 1: ERROR: empty name in readingsBeginUpdate
2021.10.18 17:27:26 1: stacktrace:
2021.10.18 17:27:26 1:     main::readingsBeginUpdate           called by ./FHEM/58_OneWire.pm (518)
2021.10.18 17:27:26 1:     main::OneWire_FinishFn              called by (eval 2973345) (1)
2021.10.18 17:27:26 1:     (eval)                              called by fhem.pl (1160)
2021.10.18 17:27:26 1:     main::AnalyzePerlCommand            called by fhem.pl (1189)
2021.10.18 17:27:26 1:     main::AnalyzeCommand                called by fhem.pl (1116)
2021.10.18 17:27:26 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (256)
2021.10.18 17:27:26 1:     main::telnet_Read                   called by fhem.pl (3847)
2021.10.18 17:27:26 1:     main::CallFn                        called by fhem.pl (773)
2021.10.18 17:28:26 5: KlimaKeller1: DeviceUpdate(KlimaKeller1), pollingInterval:60
2021.10.18 17:28:26 5: KlimaKeller1: BlockingCall for KlimaKeller1
2021.10.18 17:28:26 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_temp_input
2021.10.18 17:28:26 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_humidityrelative_input
2021.10.18 17:28:27 4: KlimaKeller1: No data found in /sys/devices/platform/dht11@5/iio:device0/in_humidityrelative_input
2021.10.18 17:28:27 5: KlimaKeller1: Finish: KlimaKeller1 error=empty_data

Ein erfolgreicher Lesezugriff führt zu
Zitat2021.10.18 17:31:26 5: KlimaKeller1: DeviceUpdate(KlimaKeller1), pollingInterval:60
2021.10.18 17:31:26 5: KlimaKeller1: BlockingCall for KlimaKeller1
2021.10.18 17:31:26 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_temp_input
2021.10.18 17:31:26 5: KlimaKeller1: Read 16700
2021.10.18 17:31:26 5: KlimaKeller1: Open /sys/devices/platform/dht11@5/iio:device0/in_humidityrelative_input
2021.10.18 17:31:26 5: KlimaKeller1: Read 71000
2021.10.18 17:31:26 4: KlimaKeller1: Poll for dht took 0.028801 s
2021.10.18 17:31:26 1: ERROR: empty name in readingsBeginUpdate
2021.10.18 17:31:26 1: stacktrace:
2021.10.18 17:31:26 1:     main::readingsBeginUpdate           called by ./FHEM/58_OneWire.pm (518)
2021.10.18 17:31:26 1:     main::OneWire_FinishFn              called by (eval 2974673) (1)
2021.10.18 17:31:26 1:     (eval)                              called by fhem.pl (1160)
2021.10.18 17:31:26 1:     main::AnalyzePerlCommand            called by fhem.pl (1189)
2021.10.18 17:31:26 1:     main::AnalyzeCommand                called by fhem.pl (1116)
2021.10.18 17:31:26 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (256)
2021.10.18 17:31:26 1:     main::telnet_Read                   called by fhem.pl (3847)
2021.10.18 17:31:26 1:     main::CallFn                        called by fhem.pl (773)
Die ERROR-Meldung ist vermutlich noch vom vorhergehenden Lesefehler ?  :-\  Die "Datenreadings" erfahren deshalb vermutlich auch kein update. "failreason" u. "failcounter" werden befüllt.

Toll finde ich natürlich die commandref.  :-* Hier
Zitatmode blocking|nonblocking|timer
Reading values from the devices is typically blocking the execution of FHEM. In my tests a typical precision 12 temperature reading blocks for about 1s, a counter read for 0.2s and reading voltages about 0.5s.
While this sounds minimal there are devices that may depend on timing (e.g. CUL_HM) and can be impacted if FHEM is blocked for so long. As a result this module is by default fork()ing a seperate process that does the read operation in parallel to normal FHEM execution. However this operation also comes with cost (see more in "set conv_time" above).
Only applies to temperature measurements: Value that the measured temperature gets multiplied with to calibrate sensors that are off.
In combination with the tempOffset the factor will be applied first, then the offset is added.
Default: 0, valid values: float
sind sicherlich die letzten 3 Zeilen durchs Kopieren zu viel. Was soll mir der letzte Satz in der 4.-Letzten Zeile sagen ? Ist mein Englisch so eingerostet oder zu old-fashioned ?  ;)

Den DHT nehm ich jetzt erst einmal wieder aus dem Test raus. Das können wir dann auch im DHT-Thread weiter diskutieren, da ich vermutlich der einzige bin, der es nutzt.  ;D

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Zitat von: KölnSolar am 18 Oktober 2021, 17:50:50
Vorschlag Rpi_OW
Was mit RPI_ (wie RPI_GPIO) war mir auch schon in den Sinn gekommen.
"OW" wär mir aber zu nichtssagend. Dann eher RPI_1WIRE.

Zitat von: KölnSolar am 18 Oktober 2021, 17:50:50
Toll finde ich natürlich die commandref.  :-* Hier sind sicherlich die letzten 3 Zeilen durchs Kopieren zu viel. Was soll mir der letzte Satz in der 4.-Letzten Zeile sagen ? Ist mein Englisch so eingerostet oder zu old-fashioned ?  ;)
Ich glaub ich arbeite zu viel mit Amerikanern. An der Doku muss aber ohnehin noch gefeilt werden. z.B. fehlt komplett der Teil der erklärt wie man das mit dem dtoverlay einrichtet und wie man es am Besten verdrahtet.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Zitatz.B. fehlt komplett der Teil der erklärt wie man das mit dem dtoverlay einrichtet und wie man es am Besten verdrahtet.
Das gehört für mich aber auch nicht in eine commandref. Wird sonst zu unübersichtlich. Maximal ein Hinweis-Satz mit Link auf Forumsbeitrag oder Wiki, wo das dann detailliert beschrieben ist.

ZitatWas mit RPI_ (wie RPI_GPIO) war mir auch schon in den Sinn gekommen.
"OW" wär mir aber zu nichtssagend. Dann eher RPI_1WIRE.
Jooooo. Womit wir dann wieder an dem Punkt wären: das Modul mit oder ohne DHTxx ?  :-\ Bei "mit" käme mir noch RPI_DTO oder RPI_DTOverlay in den Sinn. Aber ich ahne, dass Dir das nicht gefällt.  ;D
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Zitat von: KölnSolar am 18 Oktober 2021, 20:53:42
Jooooo. Womit wir dann wieder an dem Punkt wären: das Modul mit oder ohne DHTxx ?  :-\ Bei "mit" käme mir noch RPI_DTO oder RPI_DTOverlay in den Sinn. Aber ich ahne, dass Dir das nicht gefällt.  ;D
Richtig geraten :)
Mit dem DHT (sofern wirs doch zum Laufen kriegen) würde ich jetzt mal nicht so sein. Aber ein autocreate kriegt es wohl eher nicht spendiert - das sind mir dann doch zu viele Sonderlocken, wo ich mich doch eigentlich bemüht habe die "if" Sonderfälle zu reduzieren bzw. zumindest sehr klein und übersichtlich zu halten.

Also bisher gefällt mir RPI_1Wire wirklich am Besten (inkl. der Vorschläge von @Beta-User im anderen Thread - das "look and feel" mit der "1" finde ich auch schöner als z.B. RPI_OneWire.
Aber der Thread ist ja noch jung - vielleicht gibt es noch andere Stimmen dazu.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Update:
Habe den Namen jetzt auf RPI_1Wire geändert, ein paar Bugs gefixed und die Handhabung von DHT11/DHT22 Sensoren verbessert.
Dazu ist jetzt statt dem Kernelmodul nur ein Perl Modul notwendig, welches auch im ersten Post zum Download zur Verfügung steht und über "apt" installiert werden kann.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Hi Jörg,
bei mir gibt es kein set conv_time Ne Idee warum ?
In der commandref ist noch ein kleiner typo: bei mode fehlt ein b in der letzten Zeile bei blocking
Sonst sehr gut geworden.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

ZitatSonst sehr gut geworden.
Danke.

Zitatbei mir gibt es kein set conv_time Ne Idee warum ?
Bei deinen DS18B20?
Schau mal nach ob das conv_time file im sysfs für den fhem User schreibbar ist - wenn nicht lösche ich es nämlich aus der "set" Liste.
Dafür gibt es ja das "get udev" welches eine Anleitung enthält wie man den Schreibzugriff per udev automatisiert herstellt.

Ich hab inzwischen auch meine beiden FHEM Instanzen per radikal Methode (replace GPIO4 -> RPI_1WIRE im fhem.cfg) umgestellt. Scheint alles sauber zu laufen.

Gruß.
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Update:
Habe jetzt doch mal das therm_bulk_read feature in den BUSMASTER eingebaut. Möglicherweise Interessant für Leute mit sehr vielen Temperatursensoren (und keinen anderen 1Wire devices, da sonst möglicherweise ein Kernelbug dazu führt dass die Funktion keinen Effekt hat).
Desweiteren habe ich noch zwei kleine Bugs gefunden und die Dokumentation erweitert.

Zur Info: Es finden zu diesem Modul parallel auch Diskussionen in diesem Thread statt: https://forum.fhem.de/index.php/topic,121893.msg1182176.html#new
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Trotz der knapp 500 Installationen mag wohl niemand mittesten.  :'( Ich schlage daher vor, dass Du es produktiv schaltest und gleichzeitig die contrib-Version entfernst. Die Legitimation hast Du, da der User fladdy nie auf meine beiden PNs vom 29.3.20 u. 21.2.20 geantwortet hat.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Adimarantis

Auch mein Gedanke. Werde jetzt noch am Wiki schmieden und dann geht es zügig raus (und GPIO4 wandert in deprecated)

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Erster Entwurf Wiki steht:
https://wiki.fhem.de/wiki/RPI_1Wire
Gerne mal Querlesen/verbessern.

Das allgemeine 1Wire Wiki https://wiki.fhem.de/wiki/Raspberry_Pi_und_1-Wire müsste auch noch etwas angepasst werden, aber das würde ich erst machen sobald das Modul per update verfügbar ist
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

bismosa

Hallo!

Da meine Temperatursensoren mich mal wieder ärgern mit div. "failures" (ich vermute nach wie vor Timing-Probleme auf meinem mittlerweile doch ausgelastetem System) habe ich mal geschaut, was sich vielleicht im Modul mittlerweile geändert hat.
Hier ist ja richtig viel passiert!  :) Das macht alles schon einen sehr ausgereiften Eindruck.

Ich finde es toll, dass es dann auch ins Offizielle Update rutscht.  Richtig interessant finde ich auch die Idee mit dem 2fachen Lesemodus. Das könnte bei mir Ressourcen schonen, da ich bereits eine Speicherauslastung von 204MB habe und die jedes Mal kopiert werden müssen. Ich darf auch nur ein Fork auf einmal machen, da sonst mein Speicher (RPi 3B 1GB) ggf. nicht mehr ausreicht.

Da ich mit der bisherigen Variante immer mal wieder Lesefehler habe, die in der Konsole nicht auftreten, habe ich schon drüber nachgedacht einfach dauerhaft per Shell-Skript die Werte an FHEM zu senden.
Dann hat man ebenfalls keine Blocking Calls mehr. 
Wäre es nicht auch eine Möglichkeit ein Script bzw, ein Exec zu starten, dass die Werte dann selbst zurück meldet? Ich mache das melden der Werte in meinen Scripts immer mit:
wget -qO/dev/null http://server:8083/fhem?cmd=setreading%20$fhemDevice%20WERT%20NEUERWERT &> /dev/null &

Jetzt werde ich erstmal schauen, wie sich das mit den unterschiedlichen Optionen hier im Modul verhält.  :)

Hab zum testen mal ein device geändert. Dank Wiki-Eintrag ja problemlos. Es könnte vielleicht noch der Hinweis mit rein, dass das Attribut "model" nicht mehr vorhanden ist und ggf. entfernt werden muss.
Aber das wird einem ja auch von FHEM mitgeteilt.

Eine Frage ist jetzt dennoch offen geblieben. Muss ich die "conv_time" auf 2 ändern, wenn ich mode = timer verwende? Oder wird das intern gelöst?

Beim testen des Moduls ist mir aufgefallen, dass bei einem "set Update" die Seite im Browser immer neu geladen wird. Dadurch sieht man auch nicht, dass ein Reading geupdatet wurde. Ist das wirklich erforderlich? Kann man das nicht beeinflussen, wenn man im "SetFn" "return undef;" zurück gibt?

Zitat von: KölnSolar am 25 Oktober 2021, 21:46:38
Trotz der knapp 500 Installationen mag wohl niemand mittesten.  :'(
Das liegt wohl daran (zumindest bei mir) das man erst liest, wenn man Probleme hat. Solange alles läuft...

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Adimarantis

Zitat von: bismosa am 27 Oktober 2021, 12:53:31
Eine Frage ist jetzt dennoch offen geblieben. Muss ich die "conv_time" auf 2 ändern, wenn ich mode = timer verwende? Oder wird das intern gelöst?
Aktuell nicht. Wäre evtl. eine Überlegung, da der Modus ja sonst echt keinen Sinn macht.

Model wird jetzt ja als internes Reading automatisch befüllt - ist mir gar nicht aufgefallen da nie verwendet, aber danke für den Hinweis, nehm ich ins das Wiki auf.

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.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

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

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

bismosa

Hallo,

Zitat von: Adimarantis am 27 Oktober 2021, 15:29:42
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.  :)

Zitat von: Adimarantis am 27 Oktober 2021, 15:29:42
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.

Zitat von: Adimarantis am 27 Oktober 2021, 19:35:12
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
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Adimarantis

Zitat von: bismosa am 27 Oktober 2021, 20:15:20
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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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.

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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
ZitatDas 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  ;)

Zitat von: Adimarantis am 28 Oktober 2021, 11:41:45
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.

Zitat von: Adimarantis am 28 Oktober 2021, 11:41:45
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
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Adimarantis

#19
Zitat von: bismosa am 28 Oktober 2021, 12:23:14
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.
Zitat
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

Zitat
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.

Zitat
- 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.
Zitat
- 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.

Zitat
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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

bismosa

Hallo!

Zitat von: Adimarantis am 28 Oktober 2021, 13:44:09
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.

Zitat von: Adimarantis am 28 Oktober 2021, 13:44:09
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
dtoverlay=w1-gpio
#2.1-Wire bus GPIO17 - Header Pin 11
dtoverlay=w1-gpio,gpiopin=17


Zitat von: Adimarantis am 28 Oktober 2021, 13:44:09
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:
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)

Zitat von: Adimarantis am 28 Oktober 2021, 13:44:09
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.

Zitat von: Adimarantis am 28 Oktober 2021, 13:44:09
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
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Adimarantis

Zitat von: bismosa am 28 Oktober 2021, 14:43:02
"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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

bismosa

Hallo!

Hab ich direkt ausgetauscht. Tests folgen.

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

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
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Adimarantis

Zitat von: bismosa am 28 Oktober 2021, 17:36:13
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.
Zitat
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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

bismosa

Hallo,

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

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

Zitat von: Adimarantis am 28 Oktober 2021, 18:58:51
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
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Adimarantis

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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

Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

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
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
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

bismosa

Hallo!

Zitat von: Adimarantis am 30 Oktober 2021, 18:26:22
Hast du geschaut ob unter w1_bus_master3 die Datei therm_bulk_read existiert und schreibar ist?
Jo...genau dort ist das Problem. Das gibt es bei mir nur unter "/sys/devices/w1_bus_master2". Bei den anderen beiden nicht.
Funktioniert wohl nur 1x. Also problem vom RPi nicht vom Modul  ;)

GRuß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

bismosa

Hallo!

Neuer Tag...

Da ich ja immer noch auf Fehlersuche in meinem System bin, habe ich gerade mal den pollingInterval einiger Sensoren auf 172800 (=48h) gesetzt. Ist dann ja fast das gleiche wie ein disable.
Alle 5Min. werden die Sensoren trotzdem neu eingelesen. Warum? Ist die Zeit zu hoch?

Gruß
Bismosa

1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Adimarantis

Seltsam, muss ich mal nachstellen. Für disable sollte 0 gehen.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

KölnSolar

Zitathabe ich gerade mal den pollingInterval einiger Sensoren auf 172800 (=48h)
Die Intervalle in FHEM(Internaltimer) haben grundsätzlich eine geringere Maximaldauer. Weiß nur gerade nicht wie groß u. wo die Info zu finden ist. :'(
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

bismosa

Hallo!

Auch ein Intervall "0" führt regelmäßig Aktualisierungen aus.
Da scheint es ein Problem zu geben. Konnte dies aber auch noch nicht im Modul entdecken. Ich schaue aber weiter nach.

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Adimarantis

Das kann weder vom Code noch per Test nachvollziehen.
Im Gegenteil, pollingInterval=0 hat den Effekt, dass selbst ein "set update" nicht mehr ausgeführt wird, was evtl. nicht optimal ist.
5min ist auch ein seltsames Intervall. Alle defaults sind 60s.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Update im SVN:
pollingInterval=0 (=disable) dokumentiert
Gefixed dass man mit pollingInterval=0 wieder manuell updates machen kann
Verhalten bei der Änderung des pollingInterval verbessert (insbesondere den Fall wenn das Attribut gelöscht wird, dass es korrekt den Default aktiviert)
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

bismosa

Hallo!

Ich wollte immer noch mal eine Rückmeldung geben. Habe nur erstmal mein Bus-System in Ordnung bringen müssen.
Ich konnte den "Fehler" bei mir jetzt wohl endlich beheben. Seit 2 Tagen läuft es stabil ohne irgendwelche Ausfälle.
Ich konnte den wohl problematischen Sensor endlich ausfindig machen und habe diesen ersetzt. Ob es am Sensor, an der Verdrahtung oder an den jetzt neu hinzugekommen Kondensatoren zur Entstörung lag kann ich gar nicht so genau sagen. Es waren aber wohl definitiv Störungen die aus dem Netz (durch Kühlschrank, Schalter etc.) kamen.

Das Modul läuft bisher super  :) 

Danke!

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Adimarantis

Auch wenn die DHT Variante wohl bisher eher nicht genutzt wird, habe ich auf Github jetzt auch mal ein Debian Package für Raspbian "bullseye" zur Verfügung gestellt (notwendig aufgrund geänderter Perl include Pfade).

Auf diesem Wege möchte ich auch noch die vielen Nutzer von GPIO4 ermutigen bei Gelegenheit umzusteigen :)
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

caldir65

Moin,

ich habe das neue RPi_DHT für Bullseye versucht, auf einem frischen fhem mit dem April-Image von RaspiOS-Lite (samt aller Empfehlungen zu fhem aus der Commandref), bekomme aber nur eine Fehlermeldung, wenn ich das Paket zu installieren versuche:
sudo dpkg -i RPi-DHT-perl_2.0-1_armhf.deb
dpkg-deb: Fehler: »RPi-DHT-perl_2.0-1_armhf.deb« ist kein Archiv im Debian-Format
dpkg: Fehler beim Bearbeiten des Archivs RPi-DHT-perl_2.0-1_armhf.deb (--install):
»dpkg-deb --control«-Unterprozess gab den Fehlerwert 2 zurück
Fehler traten auf beim Bearbeiten von:
RPi-DHT-perl_2.0-1_armhf.deb


Ich habe einmal versucht, das deb-Paket mir anzuschauen, aber im Gegensatz zum älteren Paket bekomme ich keine Inhalte zu sehen - ist das Paket evtl. defekt?

Gruß, Christoph
Alte Techniker-Regel: "kaum macht man es richtig, funktioniert es auch"
------
Dell Wyse5070 ThinClient 16GBRam, 64GB SSD, Lubuntu 22.04LTS, fhem (aktuell), debmatic, Homematic-Devs, ConBee II und deConz, viele Shellys, Rademacher, NextCloud-Anbindung, FullyKioskBrowser+FUIP uvm.

Adimarantis

Hi Christoph,

gereade nochmal probiert und bei mir klappt das. Ist bei deinem Download evtl. was schief gegangen (z.B. Windows CR/LF)?
Sollte man dann an der Größe sehen:
ls -l RPi-DHT-perl_2.0-1_armhf.deb
-rwxrw-rw- 1 pi pi 30664 24. Apr 10:28 RPi-DHT-perl_2.0-1_armhf.deb


Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

caldir65

#41
Moin Jörg,
Ich habe es jetzt noch einmal herunter geladen, jetzt scheint es besser zu laufen - apt findet jetzt nur das Paket wiringpi nicht.

Gruß, Christoph
---
Nach etwas Suchen im Netz habe ich jetzt die HP von Wiring Pi gefunden und die v2.52 herunter geladen und installiert - und schon klappt es auch mit Deinem Paket RPi-DHT-perl_2.0-1_armhf.deb.

Jetzt bekomme ich "nur" noch einen Fehler im Log:wiringPiSetup: Unable to open /dev/mem or /dev/gpiomem: Keine Berechtigung.
  Aborting your program because if it can not access the GPIO
  hardware then it most certianly won't work
  Try running with sudo?

Das konnte ich jetzt auch lösen, indem ich den User fhem in die Gruppe gpio aufgenommen und fhem neu gestartet habe. Jetzt bekomme ich Werte wie gewünscht.
Alte Techniker-Regel: "kaum macht man es richtig, funktioniert es auch"
------
Dell Wyse5070 ThinClient 16GBRam, 64GB SSD, Lubuntu 22.04LTS, fhem (aktuell), debmatic, Homematic-Devs, ConBee II und deConz, viele Shellys, Rademacher, NextCloud-Anbindung, FullyKioskBrowser+FUIP uvm.

tschirch

Hallo Adimarantis,
schön. dass du dich um das 1wire-Modul kümmerst.

Ich benutze 1wire schon seit Jahren mit GPIO4 oder OW. Sind also zwei getrennte Busse. OW habe ich deshalb benutzt, da dort OWSWITCH existiert für meine DS2413 (2port-switch). Das RPi-OS unterstützt ja mittlerweile auch diesen. Du hattest ungetestet die Schalter schon mal zur Anzeige gebracht. Nun würde ich mir wünschen, dass die Schaltfunktion noch dazukommt. Ich stehe zum Testen natürlich zur Verfügung.

Die Statusanzeige hatte nicht richtig funktioniert: In Zeile 533 muss statt "c" ein "C" stehen für unsigned Integer. Ansonsten ist die Umwandlung falsch. Kannst du das bitte korrigieren?

Meine Lösung sieht im Moment so aus:
Es gibt das Bash-Script /home/pi/ds2413.sh mit folgendem Inhalt

#!/bin/bash
echo -en '\x'$2 > /sys/bus/w1/devices/3a-000000$1/output

$1 übergibt die Adresse und $2 die gewünschte Einstellung der beiden Schalter.

Mit dem Device für Schalter gpioa kann ich den Schalter aus und einschalten ohne die Stellung von gpiob zu beeinflussen.

defmod Switcha dummy
attr Switcha room test
attr Switcha setList on off
attr Switcha userReadings test {if (ReadingsVal($name,"state","off") eq "on")\
    {if (ReadingsVal("DS2413","piob","0") eq "1")\
    {qx(/home/pi/ds2413.sh 2ac60c 0)}\
    else\
    {qx(/home/pi/ds2413.sh 2ac60c 1)}}\
    else\
    {if (ReadingsVal("DS2413","piob","0") eq "1")\
    {qx(/home/pi/ds2413.sh 2ac60c 2)}\
    else\
    {qx(/home/pi/ds2413.sh 2ac60c 3)}};;\
    fhem("set DS2413 update")\
    }
attr Switcha webCmd on:off


Es gibt natürlich auch den dummy für gpiob.

Das funktioniert zwar alles recht schön, aber im Modul RPi_1wire wäre es besser und eleganter aufgehoben. Was meinst du dazu?

Viele Grüße,
Steffen

Adimarantis

Hi Steffen,

schau ich mir gerne bei Gelegenheit an. Lange nicht mehr angefasst - muss mich erstmal wieder in den Code einlesen - evtl. was umschreiben - manches würde ich heute gar nicht mehr so lösen :)

Ganz klar ist mir jetzt trotzdem nicht, was geschrieben werden muss.
Bit 0 schaltet quasi pioa und Bit 1 schaltet piob.
Damit diese unabhängig geschaltet werden können, muss die pio die gerade nicht geschaltet wird mit dem aktuellen Wert belegt werden - richtig?

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

tschirch

Hi Jörg,
wird eine 3 geschrieben, sind beide Schalter aus. Wird eine 0 geschrieben sind beide an. Eine 2 schaltet nur pioa und die 1 nur piob an.

Zitat von: Adimarantis am 03 September 2023, 22:35:41Damit diese unabhängig geschaltet werden können, muss die pio die gerade nicht geschaltet wird mit dem aktuellen Wert belegt werden - richtig?

Genauso ist das. Man könnte das bitweise verknüpfen. Im Zustand ist es aber leider Bit 0 und Bit 2. Steht auch so bei dir richtigerweise im Modul. Ist also nicht so einfach.

Steffen

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

tschirch


Adimarantis

#47
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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

#48
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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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:
$retval.= " pioa=".($pio[0]==1?0:1);
$retval.= " piob=".($pio[2]==1?0:1);
Latch State:
$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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

tschirch

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

Steffen

tschirch

Hi Jörg,
ich schreibe in der Tabelle den Inhalt der Datei state. Es handelt sich dabei immer um ein einziges Byte.


pioa     aus         an         aus         an
piob     aus         aus        an          an
mit 12V  0F          3C         C3          F0
         0000 1111   0011 1100  1100 0011   1111 0000
ohne 12V 5A          78         D2          F0
         0101 1010   0111 1000  1011 0010   1111 0000


Man sieht, dass im unteren Nibble. Immer die "rechte" "1" fehlt. Ist halt keine Spannung da. Es gibt also mehr Nullen. Dafür gibt es im invertierten oberen Nibble mehr Einsen.

Damit dürfte auch die Zuordnung von pioa und piob geklärt sein.

Bin dann erst am Sonntag Abend wieder verfügbar. Bis dahin viel Erfolg beim Programmieren.

Steffen

Adimarantis

Hi Steffen,

bitte schick mir doch die Dateien. Sonst muss ich aus deiner Tabelle manuell Dateien erzeugen, was erstens Aufwand ist und wobei zweitens wieder Fehler passieren können.
Einfach immer
cp /sys/bus/w1/devices/xx-xxxxxxxx/state state_pioa_on_piob_off und dann alle state* files zusammenzippen

Danke,
Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Jetzt hats mich nicht losgelassen und ich hab doch selber mal so ein "state" file erzeugt und dann wurde es klar:
Bei der Konvertierung in ein Array wurde die Nummerierung umgedreht (00000011 -> 0,0,0,0,0,0,1,1), also Bit 0 wurde zu $pin[7], außerdem war die Invertierung nicht korrekt. (Operatorpräzendenz anders als ich gedacht hätte)
Daher hats wohl auch am Anfang fast funktioniert, da ich quasi versehentlich die invertierten Bits aus dem oberen Nibble genommen hatte - das vertauscht halt nur auch a und b (und nimmt latch statt pio), wie du schon angemerkt hattest.

Sowas sieht man halt erst, wenn man die entsprechenden Code Zweige wirklich mit echten Daten testen kann, wofür mir erst jetzt die Idee kam.

Ich erzeuge jetzt auch unterschiedliche Readings für pio und latch (jeweils a und b) - das kannst du dann auswerten wie du möchtest.
Um das set-Byte zusammenzusetzen, wird aber pio verwendet.


Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

tschirch

Es geht etwas! Die Zustände sind jetzt in Ordnung. Auch die Zuordnung von pioa und piob.

Beim Schalten geht die Hälfte. Laut verbose 5 werden die richtigen Werte 0, 1, 2 oder 3 ausgegeben. Jedoch bei der Ausgabe einer 2 oder einer 3 ist der zu erreichende Zustand falsch. Wie das überhaupt möglich ist, ist mir schleierhaft.

Bsp.: Zustand pioa ist aus und piob an, piob soll ausgeschalten werden mit einer 3, piob bleibt aber an.
      Zustand pioa ist aus und piob aus, pioa soll angeschalten werden mit einer 2, pioa und pio gehen auf an. piob sollte aber aus bleiben.

Kannst du dir das erklären?

Mit meinen Befehlen geht es tadellos. z.B. echo -en '\x'$2 /sys/bus/w1/devices/3a-000000$1/output Dabei wird $1 und $2 beim Aufruf als Parameter übergeben. Wichtig ist vielleicht das '\x', welches $2 hexadezimal umwandelt. Was gibst du an dieser Stelle aus? Ich habe gerade während des Schreibens die Ausgabe von ASCII (also hex 30, 31, 32 und 33) getestet. Das geht auch, also ohne das '\x'.

Steffen


Adimarantis

Ok, ich glaube wir sind fast da.
Bei der Umwandlung hatte ich noch einen Denkfehler.
Probier mal diese Version.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

tschirch

Hey, genau! Die Schaltvorgänge kommen an. Nach dem Schalten müsste direkt ein update kommen. Ich glaube die Aktualisierung erfolgt erst mit dem 60s-Polling. Kann das sein? Guckst du da bitte nochmal nach? 60s wären mir zu lange. Für meine Markise muss es schon so 1s sein.

Steffen

Adimarantis

Ok. Probier mal jetzt. Er sollte jetzt eigentlich sofort nach dem Schalten den neuen Zustand zurücklesen.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

tschirch

Ich denke, du hast es geschafft! Es funktioniert, wie gewünscht. Super. Da bin ich erst mal wunschlos glücklich. ;-)
Danke für die Arbeit!

Wollen wir es erst mal so belassen und beobachten, falls es noch etwas gibt? Oder hast du noch Ideen etwas zu verändern/verbessern?

Viele Grüße,
Steffen

Adimarantis

Ich checke es so ein. Ein paar Kleinigkeiten hab ich bei der Gelegenheit auch noch verändert.

Danke fürs Testen und die Geduld. Es klappt halt doch erst, wenn man alles bis ins Detail testen kann.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

tschirch

Prima. Hat mich gefreut mit dir zusammenzuarbeiten!

Viele Grüße,
Steffen