Busware CC1101 stackable for RPI zeigt nur noch "dead" HM-Devices

[georgbarlo]

Hallo,
ich benötige eure Hilfe.
Seit mehr als einem Jahr betreibe ich zwei Busware CC1101 stackable (HM + slowRF) an einem RPI mit Raspbian Jessie.
Kurze Zeit nach dem Update des Raspbian und FHEM Anfang Februar verloren alle HM-Devices den Kontakt und wurden als "dead" im FHEM angezeigt. Nach dem Tausch der CC1101 gegeneinander waren die Devices für kurze Zeit wieder "alive". Nun sind alle wieder "dead".
Ein neuer RPI 3 B+ mit "stretch" und minimal FHEM wurde aufgesetzt. Ein einzelnes CC1101 Modul definiert. Nach Einstellung lt. Busware Anleitung ist dieses auch "initialized". Ein pairen mit beliebiger HM-Device schlägt auch hier ohne erkennbare Fehlermeldung fehl. Das pairen mit einem testweise genutzten USB-CUL-Stick funktioniert sofort.
Hat jemand eine Idee, woran des liegen kann?

[RaspiLED]

Hi,
zeig mal die defines in Code Tags.
Zusätzlich hätte ich gerne die Meldungen von

Code Auswählen Erweitern

sudo dmesg -w
während Du die Sticks einsteckst.

Mein Tipp: Die USB Spannungsversorgung ist nicht gut. Und seit dem Update der Bootparamater nicht mehr gesetzt:

max_usb_current=1

https://github.com/superjamie/lazyweb/wiki/Raspberry-Pi-Power

Gruß Arnd


Gesendet von iPhone mit Tapatalk

[Otto123]

Hi,

die Busware CC1101 stackable stecken doch auf der GPIO und werden am UART betrieben?

Zur Vorbereitung: https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule

Gruß Otto

[RaspiLED]

Ah, richtig! Wie sieht denn die serielle uart in boot.txt aus? Bluetooth oder anderer Dienst getty könnten die ja auch belegen, pder?

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[georgbarlo]

Danke für die Hinweise. Werde die Einstellungen heute Abend überprüfen und ggf. diese bekannt geben

[georgbarlo]

Hallo Arndt, meintest du die /boot/config.txt? die sieht so aus:
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# SCC 09.03.19 GT
enable_uart=1
dtoverlay=pi3-miniuart-bt
core_freq=250
start_x=0

Die cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=566dd06e-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Ansonsten habe ich die Anweisungen aus Ottos Link befolgt.

[georgbarlo]

Inzwischenhabe ich das Script aus https://forum.fhem.de/index.php?topic=85142.0 probiert, aber bisher ohne Erfolg.

Ich habe den den service sccstart.service im Ordner /etc/systemd/system/ so gebaut:

Code Auswählen Erweitern

[Unit]
Description=SCC Initialisierung

[Service]
Type=simple
ExecStart=/etc/systemd/system/sccstart.sh &

[Install]
WantedBy=multi-user.target


Das Script /etc/systemd/system/sccstart.sh sieht so aus:

Code Auswählen Erweitern

#!/bin/bash
# CUL C1101 aktivien Start 29.02.16 GT#
echo "resetting 868MHz extension..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
# if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
# echo out > /sys/class/gpio/gpio18/direction
# echo 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
# CUL C1101 aktivien Ende 29.02.16 GT#


Ich kann nicht glauben, dass beide Module innerhalb kurzer Zeit ausfallen. Das wäre schon ein großer Zufall.

Hat noch irgend jemand eine Idee?

[Hauslaus]

Hallo ,

ich habe seid letzen Mittwoch das gleiche Problem. Meine Stackable 433 / 868 funktionieren einfach nicht mehr.

Mein Pi mit dem CUL von Busware liefen jahrelang prima. Jetzt gibt es plötzlich keine Rückmeldung mehr. Ich weiß leider nicht ob es das Problem nach dem letzten Gewitter oder nach einem "update all" in FHEM besteht.

Nach der Anregung von Otto aus einem anderen Beitrag, gab ich:

ls -l /dev/ser*

ein und das brachte das Ergebnis:

lrwxrwxrwx 1 root root  7 Jun 16 12:39 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root  5 Jun 16 12:39 /dev/serial1 -> ttyS0

/dev/serial:
insgesamt 0
drwxr-xr-x 2 root root 100 Jun 16 12:39 by-id
drwxr-xr-x 2 root root 100 Jun 16 12:39 by-path

Bedeutet diese Ausgabe, dass meine CULs noch leben?

Direkt in FHEM wird angezeigt:
SCC0 opened
SCC1 Defined

Wobei der SCC0 mein 433er und der SCC1 mein 868er ist.

Ich habe hoffentlich meine beiden CULs nicht zerstört.

Vielleicht hat jemand eine Idee:

Gruß
Hauslaus

[MauiJim]

Hallo ,

ich habe seid letzen Mittwoch das gleiche Problem. Meine Stackable 433 / 868 funktionieren einfach nicht mehr.

Mein Pi mit dem CUL von Busware liefen jahrelang prima. Jetzt gibt es plötzlich keine Rückmeldung mehr. Ich weiß leider nicht ob es das Problem nach dem letzten Gewitter oder nach einem "update all" in FHEM besteht.

Nach der Anregung von Otto aus einem anderen Beitrag, gab ich:

ls -l /dev/ser*

ein und das brachte das Ergebnis:

lrwxrwxrwx 1 root root  7 Jun 16 12:39 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root  5 Jun 16 12:39 /dev/serial1 -> ttyS0

/dev/serial:
insgesamt 0
drwxr-xr-x 2 root root 100 Jun 16 12:39 by-id
drwxr-xr-x 2 root root 100 Jun 16 12:39 by-path

Bedeutet diese Ausgabe, dass meine CULs noch leben?

Direkt in FHEM wird angezeigt:
SCC0 opened
SCC1 Defined

Wobei der SCC0 mein 433er und der SCC1 mein 868er ist.

Ich habe hoffentlich meine beiden CULs nicht zerstört.

Vielleicht hat jemand eine Idee:

Gruß
Hauslaus

Hier ging es nicht weiter oder?
Habe seit ein paar Tagen das gleiche Problem mit einem C1101 und auch die gleiche Ausgabe. Updates durchgelaufen, danach Gewitter 

Gruß Frank