Raspberry P + wiringPi + Schalten einer 433MHz-Steckdose + FHEM = Funkstörungen?

[habefan]

Hallo zusammen,

um 433MHz-Steckdosen schalten zu können, habe ich einen entsprechender Sender mit meinem Raspberry PI (hier läuft auch FHEM) verbunden, wiringPi installiert und auf entsprechend konfiguriert. Über ein bash-Kommando kann ich dadurch die besagten Steckdosen schalten; das klappt soweit.

In FHEM habe ich anschließend für jede Steckdose ein Dummy-Device nebst einem zugehörigen Notify angelegt. Das Notfiy reagiert dabei auf Statusänderungen "seines" Dummy-Device und führt die o.g. Bashdatei mit den entsprechenden Parametern aus. Dadurch kann ich die Steckdosen über die Dummy-Devices ein- und ausschalten.

Unabhängig von FHEM betreiben wir auch eine Wetterstation mit Außensensor, der ebenfalls auf  433MHz sendet. Nachdem ich eine Steckdose per FHEM geschaltet hatte, empfing die Wetterstation keine Temperaturdaten vom Außensensor mehr. (Das Phänomen habe ich schon einmal beobachtet, seinerzeit funktionierten auch div. Funkfernbedienungen von Zentralverriegelungen nur vor unserer Garage nicht. Ein Raspi-Reboot löste diese Probleme dann.) Auf dem Raspberry habe ich keine Prozesse gefunden, die auf weitere Sendeaktivitäten des Pi hindeuteten. Die o.g. Bashdatei wurde dabei lt. FHEM-Logger nur einmal durchlaufen und anschließend beendet, denn das entsprechende Lockfile exisitierte nicht mehr.

Nach einem shutdown restart von FHEM zeigte die Wetterstation plötzlich wieder Temperaturdaten an. Deshalb gehe ich davon aus, dass der Sender am Raspberry den 433MHz-Frequenzbereicht stört und FHEM irgendetwas damit zu tun hat. Ohne Ansatz, wie / wonach ich suchen soll, um das Problem zu lösen, bitte ich um Eure Unterstützung.

Vielen Dank dafür,

stefan

[KölnSolar]

ich tippe auf Dauerfunk durch fehlerhafte Konfiguration des notify, Stichwort Schleife.

[Syrex-o]

Hatte das selbe Problem. Guck dir mal genau deine Notifys an und ob sie sich im Weg stehen. In meiner Konfiguration sieht es so aus:

Code Auswählen Erweitern

define Subwoofer dummy
attr Subwoofer userattr room_map structexclude
attr Subwoofer alias Subwoofer Schlafzimmer
attr Subwoofer eventMap BI:on B0:off
attr Subwoofer room Schlafzimmer
attr Subwoofer setList state:on,off
define Subwoofer_ntfy notify Subwoofer:.* {\
    my $master = "11111";;\
    my $slave = "01000";;\
    my $v=Value("Subwoofer");;\
    if ($v eq "on") {connair("$master","$slave","on")};;\
    if ($v eq "off") {connair("$master","$slave","off")};;\
    }


Vielleicht hilft dir das ja.
Achte darauf, dass du überall die selben Bezeichnungen hast, sonst erreichst du nichts beim schalten oder hast einen loop.

[habefan]

Danke für Eure Tipps, ich habe mir die Notifys noch einmal angeschaut:

Code Auswählen Erweitern


define _zz433_00100_B dummy
attr _zz433_00100_B alias Lichterkette Küche
attr _zz433_00100_B room zz_Schaltfunktionen,zz_Weihnachten
attr _zz433_00100_B setList state
attr _zz433_00100_B webCmd ein:aus
.
.
.
define _ntfy_zz_433_00100_B notify _zz433_00100_B {fhem "set _zz433_00100_B ???";; system("/home/pi/002_bash/schalten433.sh fhem_00100_B $EVENT");;;; fhem "set _zz433_00100_B ?$EVENT?"}
attr _ntfy_zz_433_00100_B room zz_Labor


Das notify verändert den state des Geräts, das es beobachten soll. Triggert es sich dadurch immer wieder selbst und ruft das Bashscript mit (theoretisch) immer wieder anderen (ungültigen) Parametern auf? Wenn das so ist, warum wird das nicht protokolliert?

Vorerst sieht das notify jetzt so aus:

Code Auswählen Erweitern


define _zz433_00100_B dummy
attr _zz433_00100_B alias Lichterkette Küche
attr _zz433_00100_B room zz_Schaltfunktionen,zz_Weihnachten
attr _zz433_00100_B setList state
attr _zz433_00100_B webCmd ein:aus
.
.
.
define _ntfy_zz_433_00100_B notify _zz433_00100_B {system("/home/pi/002_bash/schalten433.sh fhem_00100_B $EVENT");;;;}
attr _ntfy_zz_433_00100_B room zz_Labor


Im Unterschied zur ersten Variante taucht im Logfile jetzt ein Return-Code -1 des notify auf. Ob diese Änderung auch Wetterstation und ZV-Fernbedienungen "glücklich" macht, mag ich jetzt nicht mehr prüfen. Das hole ich aber schnellstmöglich nach und werde berichten ...

stefan

[Hollo]

Statt Dummy UND notify kann man dafür auch direkt GenShellSwitch nutzen.

Beispiel:

Code Auswählen Erweitern

### WOHNZIMMER BLUMENLAMPE ###
define Blumenlampe GenShellSwitch /usr/local/bin/send <Steckdosencode> 1 0
attr Blumenlampe group Licht
attr Blumenlampe room Beleuchtung,Wohnzimmer

[Syrex-o]

Meistens genügt einmal ausfürlich lesen im Wiki.
Hier mal der Bereich zu den Notifys. http://www.fhemwiki.de/wiki/Notify
Falls noch was offen ist, schreib einfach.
Hat dir denn ein Tipp schon geholfen?

[DeeSPe]

Statt Dummy UND notify kann man dafür auch direkt GenShellSwitch nutzen.

Beispiel:

Code Auswählen Erweitern

### WOHNZIMMER BLUMENLAMPE ###
define Blumenlampe GenShellSwitch /usr/local/bin/send <Steckdosencode> 1 0
attr Blumenlampe group Licht
attr Blumenlampe room Beleuchtung,Wohnzimmer

Oder oder die neuere und bessere Version davon 00_ShellSwitch.pm.

Gruß
Dan

[habefan]

Hallo,

inzwischen sehen meine notify's so aus

Code Auswählen Erweitern


define _ntfy_zz_433_00100_A notify _zz433_00100_A:aus.*|_zz433_00100_A:ein.* {system("/home/pi/002_bash/schalten433.sh fhem_00100_A $EVENT")}


Damit erreiche ich ein Schalten der Steckdose und erhalte im FHEM-Logger einen Eintrag der Sorte:

Code Auswählen Erweitern


2016-10-25 21:11:44  : fhem_00100_a aus
sending systemCode[00100] unitCode[1] command[0]
sending systemCode[00100] unitCode[1] command[0]
2016.10.25 21:11:49 3: _ntfy_zz_433_00100_A return value: -1


Dennoch reißt die Funkverbindung zwischen Wetterstation und Temperatursensor weiterhin ab. Leider war ich heute sehr planlos unterwegs und werde bei Gelegenheit folgende Tests durchführen:
- Ausführen des Scripts von der Konsole aus
- einmaliges Aufrufen des Scripts aus FHEM per at
- Aufruf über die Dummiy-Devices

Bis hierher erstmal vielen Dank für Eure Hilfe, ich werde weiterhin berichten.

stefan

P.S.: Was hat der return value -1 des Notify zu sagen? Google und das Wiki haben mir da nicht geholfen ...

[habefan]

Guten Tag,

heute morgen konnte ich den ersten Test durchführen: Start des Bashscripts zum Ansteuern der Funksteckdose über die Konsole

Allein das reicht schon aus, um den Funkverkehr zwischen Wetterstation und Temperatursensor zu stören. Nach einem Neustart des pilight-Daemon kamen bei der Wetterstation wieder Daten an. 

Also werde ich erst einmal die Grundlagen richten, bevor ich weiter mit FHEM teste.

stefan

[KölnSolar]

Dann ist der Schuldige ja wenigstens gefunden. Ich hatte es auch im Verdacht, wollte das aber nicht so klar sagen, weil Du im Anfangsthread schriebst:

Über ein bash-Kommando kann ich dadurch die besagten Steckdosen schalten; das klappt soweit.

Das war dann wohl falsch, oder sagen wir mal: das Problem ist Dir zu diesem Zeitpunkt noch nicht aufgefallen. 

[habefan]

So, jetzt sieht das gut aus:
- Neben wiringPi ist auf meinem Raspberry auch pilight installiert.
- Ich habe die Steckdosen via Konsole und pilight-send angesteuert; das geht ohne Störung der Wetterstation.
- Im nächsten Schritt habe ich eine Funktion f_pilightSend gebaut, die das Parametrieren und den Aufruf von pilight-send übernnimmt.
- Das funktioniert bislang mit drei Steckdosen einwandfrei, zwei Stück fehlen noch.

Beim Stöbern im Netz bin ich u.a. über den Hinweis auf ein größeres Update im Bereich des GPIO-Zugriffs gestoßen. Ob und wie sich das auf wiringPi bzw. meine Probleme auswirkt, habe ich noch nicht untersucht. Im ersten Schritt mussten die Steckdosen funktionieren - die Weihnachtszeit naht

Da ich zwar einen Workaround, aber noch keine wirkliche Lösung habe, würde ich den Status noch nicht auf [GELÖST] setzen. Ist das in Ordnung?

Nochmals vielen Dank,

stefan