Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)

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

Vorheriges Thema - Nächstes Thema

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