Moin Zusammen
ich habe nur einen Sender auf den PI gesteckt. Steuerung z.B. über Zeit und wetterabhänige Funksteckdosen funzt super.
Leider sendet der 433 MHZ Sender ein Dauersignal (gemessen mit Frequenzanalyer). Er sendet so gut das er die Frequenz von Funkfernbedienung für Autos überdeckt.
Ist es normal das die Sender ständig "funken"? Ich dachte sie senden nur das Signal wenn es gebraucht wird. Ich habe schon mal die fhem.cfg.demo benutzt, gleiches Fehlerbild
Danke
da passt wohl was mit deinem aufbau nicht (oder du hast ein anderes gerät welches sendet wobei die in der regel nicht durchgängig ohne pause senden).
ich kann den Sender eindeitig auf den PI schieben ->wenn PI kein Strom dann Signal aus
Was hast du für einen Sender?
Und wie ist er angeschlossen?
Und wie steuerst du ihn an?
Mach mal ein Foto.
Micky
hier meine cfg (auszug) und ein bild des senders
attr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global latitude 53.1913247
attr global logfile /opt/fhem/log/fhem-%Y-%m.log
attr global longitude 8.5953212
attr global modpath .
attr global motd SecurityCheck:\
\
WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth.\
telnetPort has no associated allowed device with password/globalpassword.\
\
Restart FHEM for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\
attr global statefile /opt/fhem/log/fhem.save
attr global updateInBackground 1
attr global verbose 3
define telnetPort telnet 7072 global
define WEB FHEMWEB 8083 global
attr WEB stylesheetPrefix dark
define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix darktouchpad
define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog /opt/fhem/log/fhem-%Y-%m.log fakelog
define autocreate autocreate
attr autocreate filelog /opt/fhem/log/%NAME-%Y.log
define eventTypes eventTypes /opt/fhem/logO/eventTypes.txt
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
define COC CUL /dev/ttyAMA0@38400 1234
########################### ENDE Grundconfig #########################
# Wetter mit Licht
define Wetter Weather xxxxxxxxxx de
attr Wetter room Wettervorhersage
define Helligkeit Twilight xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# Wetter Anzeige
define weblink_Wetter weblink htmlCode {WeatherAsHtml("Wetter",7)}
attr weblink_Wetter room Wettervorhersage
################################
##### Weihnachten ## 001101 ###
################################
#define Weihn dummy
#attr Weihn group Schalter
#attr Weihn room Weihnachten
#attr Weihn setList on off
#define off_Weihn notify Weihn:off {system("/usr/bin/send 00110 1 0 &")}
#define on_Weihn notify Weihn:on {system("/usr/bin/send 00110 1 1 &")}
define TV dummy
attr TV userattr room_map structexclude
attr TV group Schalter
attr TV room Wohnzimmer
attr TV setList on off
attr TV sortby 1
define off_TV notify TV:off {system("/usr/bin/send 01110 1 0 &")}
define on_TV notify TV:on {system("/usr/bin/send 01110 1 1 &")}
define Schranklicht dummy
attr Schranklicht userattr room_map structexclude
attr Schranklicht group Schalter
attr Schranklicht room Wohnzimmer
attr Schranklicht setList on off
define off_Schranklicht notify Schranklicht:off {system("/usr/bin/send 01110 2 0 &")}
define on_Schranklicht notify Schranklicht:on {system("/usr/bin/send 01110 2 1 &")}
#define zeit_Urlaub_Schranklicht_an at *22:15:00 set Schranklicht on
#define zeit_Urlaub_Schranklicht_aus at *22:30:00 set Schranklicht off
define WLAN dummy
attr WLAN userattr room_map structexclude
attr WLAN group Schalter
attr WLAN room Wohnzimmer
attr WLAN setList on off
define off_WLAN notify WLAN:off {system("/usr/bin/send 01110 3 0 &")}
define on_WLAN notify WALN:on {system("/usr/bin/send 01110 3 1 &")}
# # # # # # # # #
# FLUR #
# 434Mhz D #
# # # # # # # # #
define Licht_Flur dummy
attr Licht_Flur group Schalter
attr Licht_Flur room Flur
attr Licht_Flur setList on off
define off_Licht_Flur notify Licht_Flur:off {system("/usr/bin/send 01110 4 0 &")}
define on_Licht_Flur notify Licht_Flur:on {system("/usr/bin/send 01110 4 1 &")}
define Licht_Flur_auto at *{twilight("Helligkeit","ss_weather","16:00","21:30")} set Licht_Flur on
attr Licht_Flur_auto room Flur
define Licht_Flur_auto_Aus at *22:15:00 set Licht_Flur off
attr Licht_Flur_auto_Aus room Flur
#Licht im Flur Morgens innerhalb der Woche an und aus
define Licht_Flur_Morgens_Woche_an at *07:05:00 { if($we == 0) { fhem("set Licht_Flur on") }}
define Licht_Flur_Morgens_Woche_aus at *08:00:00 { if($we == 0) { fhem("set Licht_Flur off") }}
# ALLES aus
define Alles_AUS structure room TV Schranklicht WLAN
attr Alles_AUS icon Shutdown
attr Alles_AUS room Wohnzimmer
Wenn du FHEM ausschaltest, sendet der Sender dann immer noch?
Hast du ein Oszi und kannst mal die Ansteuerung des Senders messen?
Zitat von: Kuzl am 21 Dezember 2016, 14:38:20
Wenn du FHEM ausschaltest, sendet der Sender dann immer noch?
Hast du ein Oszi und kannst mal die Ansteuerung des Senders messen?
Hat er doch alles schon gemacht ???
Zitat von: kopf76 am 21 Dezember 2016, 09:48:03
ich kann den Sender eindeitig auf den PI schieben ->wenn PI kein Strom dann Signal aus
Zitat von: kopf76 am 21 Dezember 2016, 09:42:56
Leider sendet der 433 MHZ Sender ein Dauersignal (gemessen mit Frequenzanalyer).
@TE
Bitte Code-Tags (die # über den Smileys) für Codes verwenden - siehe mein angepinnter Beitrag.
Danke
Interessanter wäre
Zitat von: kopf76 am 21 Dezember 2016, 09:42:56
ich habe nur einen Sender auf den PI gesteckt.
welche Sender ist das?
Ein CUL (ein richtiger CUL) wird es wohl nicht sein - die sind idR keine Dauersender.
Zumindest meine nicht.
Und wie ein CUL sieht das Teil auf dem Foto nicht aus - zumindest nicht für meine "alten" Augen ;D
ZitatWenn du FHEM ausschaltest, sendet der Sender dann immer noch?
das hat er eben noch nicht beantwortet. Nur die fhemdemo benutzt, was aber auf das selbe rauskommt. Das Problem scheint rein gar nichts mit fhem zu tun zu haben :o
Wenn ich das richtig einschätze, ist das "ein "Pilight-System". Dessen Aufbau(Verkabelung/Software) ist zu prüfen. Fragen sinnigerweise dann im pilight-forum zu stellen.
natürlich nur, wen ich mit meiner Einschätzung richtig liege ;)
Grüße Markus
Edit: nachträgliche u. zukünftige code-tags fänd ich auch toll ;)
Zitatdas hat er eben noch nicht beantwortet.
Natürlich hat er das ::)
Zitat von: kopf76 am 21 Dezember 2016, 09:48:03
ich kann den Sender eindeitig auf den PI schieben ->wenn PI kein Strom dann Signal aus
Wenn der RasPi stromlos ist gehe ich mal davon aus das auch FHEM ausgeschaltet ist ;)
pi aus = fhem aus
fhem aus # pi aus
;)
deshalb meine Mutmaßung: pi-problem, kein fhem-problem
Zitat von: KölnSolar am 21 Dezember 2016, 20:47:21
deshalb meine Mutmaßung: pi-problem, kein fhem-problem
Das ist richtig wobei ...
Der Pi kann vermutlich auch nichts dafür - ich tippe eher auf das Funkmodul.
Aber meine Glaskugel ist leider zum reinigen im Geschirrspüler und wird erst morgen früh wieder sauber sein.
Aber auch dann wird sie nichts sehen können.
Daher wäre es gut wenn der TE mal Infos liefern würde.
Zitatwelche Sender ist das?
wie so oft. Wir Helferlein spekulieren uns die Köpfe heiß und die TEs kümmerts nicht ;)
Das Funkmodul ist vermutlich unkritisch. Hab ich auch. Dauerfeuer klingt nach falscher Verkabelung am Sende-GPIO oder looping send_script
Glaskugelblick aus(wie Du schon mal schreibst ;))
Zitat von: Puschel74 am 21 Dezember 2016, 20:57:48
Das ist richtig wobei ...
Der Pi kann vermutlich auch nichts dafür - ich tippe eher auf das Funkmodul.
Daher hab ich ja gefragt ob er mit dem Oszi messen kann - das hat er nämlich auch noch nicht sondern nur mit einem Frequenzanalyser => also das was gesendet wird.
Mit dem Oszi soll er messen mit was das Funkmodul angesteuert wird.
Kann ja sein, dass irgend ein anderes Programm auf dem Pi den Pin permanent Toggelt.
Das Funkmodul ist so ein 2€-Teil wie z.b. beim Signalduino. Das sendet einfach den Pegel der am Eingang kommt (moduliert auf die Trägerfrequenz).
Ein Dauersenden könnte also davon kommen, dass am Eingang im Leerlauf oder Immer 3.3V anliegen.
Moin Zusammen
erstmal danke für alle Hinweise.
Was für eine Aufregung hier. Auch wenn es ein akutes Problem ist, da sich wirklich die KFZs nur schwer öffnen lassen, gibts es noch andere Sachen im Leben. Ich kann es leider nur richtig auf der Arbeit testen. Oder habt ihr eine Frequenzanalyse so rum liegen? Also Sorry wenn ich mich nicht gleich zurück melde. Und jetzt kommt auch noch Weihnachten ;-)
Ich werde mich bemühen die Einträge besser zu gestalten. Bin eben Anfänger und neu hier.
Jetzt zum Thema:
- Funkmodul habe ich schon mal getauscht -> Dauersignal bleibt
- den PI ohne SD Card anschalten -> kein Dauersignal !!
- Ich habe fhem gestoppt -> keine Verbesserung -> Dauersignal bleibt
welcher von den angezeigten Diensten Steuer die Ausgänge (Sender) an.
was mich wundert ist das er "resetting 868MHz extension..." anzeigt. das ist klar ein 433 MHz Sender
nach dem Starten könnte zeitlich der kleine cut in der Messung sein siehe Bild.
pi@raspi-mm:~ $ top
595 pi 20 0 5112 2452 2100 R 0,7 0,2 0:00.51 top
368 avahi 20 0 3876 2496 2260 S 0,3 0,3 0:00.08 avahi-daemon
556 pi 20 0 12072 4304 3632 S 0,3 0,4 0:00.11 sshd
1 root 20 0 5480 3884 2732 S 0,0 0,4 0:04.05 systemd
2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 0:00.01 ksoftirqd/0
4 root 20 0 0 0 0 S 0,0 0,0 0:00.09 kworker/0:0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0,0 0,0 0:00.07 kworker/u8:0
7 root 20 0 0 0 0 S 0,0 0,0 0:00.07 rcu_sched
8 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh
9 root rt 0 0 0 0 S 0,0 0,0 0:00.00 migration/0
10 root rt 0 0 0 0 S 0,0 0,0 0:00.00 migration/1
11 root 20 0 0 0 0 S 0,0 0,0 0:00.00 ksoftirqd/1
13 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/1:0H
14 root rt 0 0 0 0 S 0,0 0,0 0:00.00 migration/2
15 root 20 0 0 0 0 S 0,0 0,0 0:00.00 ksoftirqd/2
16 root 20 0 0 0 0 S 0,0 0,0 0:00.04 kworker/2:0
pi@raspi-mm:~ $ sudo /etc/init.d/fhem start
resetting 868MHz extension...
Starting fhem...
ich werde nochmal nach loops suchen, wobei ich schon die demo.cfg benutzt habe
Pilight-System? ich glaube schon
kein CUL Sender? gute Frage. wie bekomme ich das raus?
Danke
guter hinweis kuzl !
hier das bild vom analyser
Ich würde mal den gpio wechseln. Evtl. hängt noch ein anderer Prozess (pilight z.b.?) am selben gpio.
Gesendet von meinem Toaster.
Zitat von: micky0867 am 22 Dezember 2016, 10:23:50
Ich würde mal den gpio wechseln. Evtl. hängt noch ein anderer Prozess (pilight z.b.?) am selben gpio.
Gesendet von meinem Toaster.
Und btw... du hast auch einen CUL (868 mhz?) In der config....
Gesendet von meinem Toaster.
Habe mir mal dein Bild angesehen und die vermute mal was zur Schaltung.
Ich hab mich gegen die art der Veschaltung entschieden und versuche es mint NanoCULs.
Der sender hängt an einem I/O Pin und macht exakt das was der GPIO Pin sagt.
Hier stimmt der Hinweis auf PiLigth.
Versuche mal eine LED auf den Pin zu schalten, die dürfete nicht leuchten.
Was hier aber der Fall sein dürfte.
Du könntest den GPIO Pin falsch beschaltet haben oder noch einen WiringPI dazischen haben ..
oder mal mit einem Multimeter messen.
Was auch sein könnte das dein GPIO Pin invertiert angeseuert wird.
Mehr kann ich erstmal durch Handauflegen am Blidschirm nicht vermuten
schöne Feiertage ..
danke für die Hinweise. ich werde über die Festage mal testen.
frohe Weihnachten und guten Rutsch
Hallo,
ich kenn den Sender nicht, aber wenn ich genau hingucke sieht das so aus als wenn du an Vcc den Steuereingang (lila Ader)
und in der Mitte die 3,3V (graue Ader) angeschlossen hast. Wenn das so wäre, dann ist das natürlich nicht richtig!
Ich kann mich auch vertun, man sieht es halt nicht richtig im Bild!
Zur Info: Vcc steht für die positive Spannung (also Dauerspannung).
Also wenn ich die Pins auf dem Foto richtig durchgezählt habe, (edit: und jetzt nochmal richtig, TOM111 hat doch recht)
R-GPIO - Farbe - Funkmodul
(1 = 3.3V) - grau - DATA
(6 = GND) - blau - GND
(11 = GPIO17) - lila - VCC
Wenn der Pin 11 genug Saft zur Versorgung des Chips liefert und DATA High-Aktiv ist, dann wäre das der Punkt. Sehe ich also genauso. grau und lila am Pi einfach mal tauschen. Das Modul soll mit 3.3V versorgt werden? (Ich kenne es auch nicht)
Zitat von: Pfriemler am 22 Dezember 2016, 16:38:40
Also wenn ich die Pins auf dem Foto richtig durchgezählt habe,
R-GPIO - Farbe - Funkmodul
(1 = 3.3V) - grau - DATA
(6 = GND) - blau - GND
(9 = GND) - lila - VCC
nicht 9 sondern 11 hat er angeschlossen.
Aber Pin 11 geht scheinbar nach Vcc, und das wäre falsch!
Zitat von: Tom111 am 22 Dezember 2016, 16:43:40
nicht 9 sondern 11 hat er angeschlossen.
Ja, gerade selber gemerkt und korrigiert, trotzdem danke!
Hab grade das Funkmodul im Web gefunden:
https://www.einplatinencomputer.com/raspberry-pi-433-mhz-funksteckdose-schalten/
Vcc ist in der Mitte, somit ist die Verdrahtung schon mal richtig!
Pin 1: ATAD (Daten)
Pin 2: VCC (Versorgungsspannung)
Pin 3: GND (Masse)
PS:
Die Betriebsspannung des Moduls wird an verschiedenen Stellen von 3,5 – 12V DC angegeben.
Dieser hier liegt aber an 3,3V.
@Tom111
das ist (wenn ich mich richtig erinnere) genau die Seite von der ich die Belegung habe.
oder von dem Bild, das ich aus dem Netz habe. dies ist nicht genau mein Sender aber passt von der Bauform
Also doch richtig :-\
ich werde mal Richtung falsche Ansteuerung suchen. Bei der Fehlersuche lernt man doch am meisten ;)
Zitat von: Tom111 am 22 Dezember 2016, 17:00:29
Hab grade das Funkmodul im Web gefunden:
https://www.einplatinencomputer.com/raspberry-pi-433-mhz-funksteckdose-schalten/
Vcc ist in der Mitte, somit ist die Verdrahtung schon mal richtig!
Pin 1: ATAD (Daten)
Pin 2: VCC (Versorgungsspannung)
Pin 3: GND (Masse)
PS:
Die Betriebsspannung des Moduls wird an verschiedenen Stellen von 3,5 – 12V DC angegeben.
Dieser hier liegt aber an 3,3V.
Ich meine auch, dass es 5V sein müssen.
Gesendet von meinem Toaster.