Autor Thema: Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)  (Gelesen 5078 mal)

Offline bismosa

  • Developer
  • Full Member
  • ****
  • Beiträge: 455
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #30 am: 30 Oktober 2021, 18:48:58 »
Hallo!

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

Offline bismosa

  • Developer
  • Full Member
  • ****
  • Beiträge: 455
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #31 am: 31 Oktober 2021, 10:06:18 »
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, ...

Offline Adimarantis

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 688
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #32 am: 31 Oktober 2021, 10:32:40 »
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)

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5606
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #33 am: 31 Oktober 2021, 10:41:33 »
Zitat
habe 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

Offline bismosa

  • Developer
  • Full Member
  • ****
  • Beiträge: 455
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #34 am: 31 Oktober 2021, 10:49:56 »
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, ...

Offline Adimarantis

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 688
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #35 am: 31 Oktober 2021, 12:27:25 »
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)

Offline Adimarantis

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 688
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #36 am: 03 November 2021, 14:58:41 »
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)

Offline bismosa

  • Developer
  • Full Member
  • ****
  • Beiträge: 455
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #37 am: 19 November 2021, 16:41:44 »
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, ...

Offline Adimarantis

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 688
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #38 am: 15 Januar 2022, 15:42:37 »
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)

Offline caldir65

  • Full Member
  • ***
  • Beiträge: 334
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #39 am: 23 April 2022, 20:57:47 »
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
Raspi 4 mit RaspiOS Bullseye und aktuellem fhem (auf SSD), Homematic-Devs, Shellys, Rademacher, NextCloud-Anbindung, Fully+TabletUI2 uvm.

Offline Adimarantis

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 688
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #40 am: 24 April 2022, 10:31:09 »
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)

Offline caldir65

  • Full Member
  • ***
  • Beiträge: 334
Antw:Modulüberarbeitung: 58_RPI_1Wire (ersetzt 58_GPIO4)
« Antwort #41 am: 24 April 2022, 11:48:51 »
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.
« Letzte Änderung: 24 April 2022, 13:17:14 von caldir65 »
Raspi 4 mit RaspiOS Bullseye und aktuellem fhem (auf SSD), Homematic-Devs, Shellys, Rademacher, NextCloud-Anbindung, Fully+TabletUI2 uvm.

 

decade-submarginal