FHEMduino

Begonnen von mdorenka, 06 Dezember 2013, 15:34:39

Vorheriges Thema - Nächstes Thema

viegener

Zitat von: motopi am 05 Januar 2016, 20:21:15
vielen Dank für euren Support. Also sollte ich die aus dem Link direkt bestellen?
http://www.ebay.de/itm/433Mhz-3400-RF-Superheterodyne-Transmitter-Receiver-Link-Kit-fur-Arduino-ARM-MCU-/281635403408

Disclaimer: Ich habe den Link eher wg. des bildes gepostet, denn einer meiner Empfänger sieht so aus, ich habe aber nicht bei diesem Versender bestellt.
Generell sieht der Empfänger aber ok aus, auch wenn es vermutlich günstigere gibt...



Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

motopi

Danke für die Nachricht, ich werde es einfach mal versuchen.

derchrome

Hallo zusammen, mein Problem kurz geschildert:
Ich habe eine Klingel an meinem Gartentor. Damit der Empfänger das  Signal des Klingeltasters noch anfängt muss ich den Empfänger in einen bestimmten Raum hängen. Leider kann man dann im restlichen Haus die Klingel nicht laut genug hören.

Kann man mit dem FHEMduino das Raw-Signal erfassen und dann z.B. die Klingel schalten? Mit pilight hab ich es nicht hinbekommen.

Vielen Dank im Voraus!

Sidey

Hi,

so was geht mit dem Signalduino.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Cruiser79

Es gab hier ja einige, die einen Fhemduino/Signalduino über das Netzwerk ansteuern wollten um die Abhängigkeit der USB Verbindung zu verlieren. Habe gerade etwas sehr interessantes entdeckt, wegen fehlender Bauteile und können, aber noch nicht ausprobieren können. Eine Ansteuerung des Fhemduino/Signalduino über WiFi mit Hilfe einiger Kleinteile und einem ESP.
http://www.hjgode.de/wp/2015/11/05/fhem-serielle-gerat-uber-wifi-anbinden/
Was haltet ihr davon?
FHEM auf Raspberry Pi
HM-CFG-LAN mit HM-TC-IT-WM-W-EU, HM-CC-RT-DN, HM-WDS10-TH-O, HM-LC-SW1-FM, HM-LC-Bl1-FM
Signalduino mit Elro AB440, LOGILINK WS0002, IT CMR-1000

motopi

#1535
Zitat von: motopi am 05 Januar 2016, 20:21:15
Hi,

vielen Dank für euren Support. Also sollte ich die aus dem Link direkt bestellen?

http://www.ebay.de/itm/433Mhz-3400-RF-Superheterodyne-Transmitter-Receiver-Link-Kit-fur-Arduino-ARM-MCU-/281635403408

Ich bräuchte eigentlich nur einen Empfänger, da ich nen guten Sender bereits von Waterott habe.

Thanks.


Update: kam diese Woche und ich habe gerade den ersten Test erfolgreich durchgeführt. Es freut mich riesig, denn nun habe ich problemlos Empfang meiner Fernbedienungen. Ich danke euch für den Support!

:-)

Nun werde ich Temperatursensoren dazukaufen ----  welche bloss?

hab mir jetzt einfach mal den günstigen Pearl Sender geshoppt und schaue mal, wieder mir so taugt. Da sollten ja dann sicher auch mehrere Sender parallel gehen, oder?

Thanks

pejonp

Zitat von: motopi am 17 Januar 2016, 14:19:42
...
Nun werde ich Temperatursensoren dazukaufen ----  welche bloss?
...
Hallo motopi,

schau mal hier http://www.fhemwiki.de/wiki/SIGNALduino. Hardware kann so bleiben nur andere SW rauf. Ich habe auch noch andere Sensoren getestet. Ich würde Bresser nehmen, dort können 5 Kanale eingestellt werden. Diese arbeiten mit 433MHz.
Ich habe auch noch Sensoren auf 868MHz. Diese sind sehr zuverlääsig und haben eine größere Reichweite, dort wird ein JeeLink genutzt.

pejonp
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

motopi

pejonp -> Danke. Aber das ist halt wieder die nächste Konfiguration. Ich selbst versteh nicht, warum es Signalduino & FHEMduino gibt und warum man da dann unterschiedliche Konfigurationen braucht.....

pejonp

Zitat von: motopi am 17 Januar 2016, 15:21:47
pejonp -> Danke. Aber das ist halt wieder die nächste Konfiguration. Ich selbst versteh nicht, warum es Signalduino & FHEMduino gibt und warum man da dann unterschiedliche Konfigurationen braucht.....
Hallo motopi,

Signalduino ist eigentlich die Weiterentwicklung von Fhemduino. In Signalduino werden schon vorhandene FHEM-Module (14_CUL_TCM97001.pm) benutzt, die auch bei anderen FHEM-Projekten (CUL,a-cul, nanoCul) zum Einsatzt kommen. Und es sind schon neue Module dazu gekommen (14_Hideki.pm, 14_SD_WS07.pm, 14_SD_WS09.pm) um neue/andere Sensoren zu erkennen. Ich hatte auch mit FHEMduino angefangen, bin aber auf Signalduino umgestiegen, weil hier die Protokollerkennung sehr gut ist. Wie gesagt die HW bleibt ja bestehen.

pejonp
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

motopi

Nochmal Danke.


Eine andere Frage habe ich noch: mein FHEMDUINO scheint sich immer wieder in sowas wie einen Sleep Modus zu setzen. Das macht natürlich keinen Sinn, wenn ich verschiedene 433 MHZ Signale aufzeichen will. Daher meine Frage: Was mache ich dagegen?

Achso: Server ist ein Raspberry Pi B mit Raspbian Wheezy FHEM Version 5.7

Danke für eine Antwort.

Motopi

viegener

Zitat von: motopi am 17 Januar 2016, 15:21:47
pejonp -> Danke. Aber das ist halt wieder die nächste Konfiguration. Ich selbst versteh nicht, warum es Signalduino & FHEMduino gibt und warum man da dann unterschiedliche Konfigurationen braucht.....

Das ist eigentlich ganz einfach:

FHEMDuino war der erste Ansatz mehrere Protokolle relativ günstig mit eine Arduino und einfachen Funkmodulen zu unterstützen. Die anderen Lösungen hatten oder haben gewisse Einschränkungen (vereinfacht: CUL - Preis vor dem Nanocul / Jeelink - ein Protokoll pro Jeelink).
Das klappt auch gut, es hat mich z.B. nur relativ wenig Zeit gekostet Empfang für Somfy (geht im CUL gar nicht bisher) hinzuzufügen.

Allerdings erfordert ein neues Protokoll eine Änderung an der Firmware für den Arduino-Stick und nicht nur ein weiteres Modul in FHEM, deshalb kam bei den FhemDuino/Signalduino-Entwicklern die Idee auf einen "allgemeingültigen" Empfänger zu machen, wobei die Analyse des Protokolls in FHEM verlagert wird. Dann brauch man im besten Fall nur ein neues FHEM-Modul wenn mal ein neues Protokoll kommt (ausserdem hilft es noch unbekannte Protokolle zu analysieren). Also eigentlich ein wirklicher Fortschritt.

Disclaimer: Das ist meine Zusammenfassung, ohne wirklich an der FHEMDuino/Signalduino-Idee beteiligt zu sein!
(Ich bin noch komplett auf FHEMDuino, da ich zuviele andere Baustellen habe)...
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

viegener

Zitat von: motopi am 17 Januar 2016, 16:48:10
Nochmal Danke.


Eine andere Frage habe ich noch: mein FHEMDUINO scheint sich immer wieder in sowas wie einen Sleep Modus zu setzen. Das macht natürlich keinen Sinn, wenn ich verschiedene 433 MHZ Signale aufzeichen will. Daher meine Frage: Was mache ich dagegen?

Achso: Server ist ein Raspberry Pi B mit Raspbian Wheezy FHEM Version 5.7

Danke für eine Antwort.

Motopi

Einen Sleepmode gibt es eigentlich nicht, was meinst Du damit, bzw. wie äussert sich das?
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

motopi

wenn ich einige Zeit nicht am FHEM Server war, dann scheint er nichts zu empfangen. Sende ich ein get Version kommt erst ein
ZitatArduino version => No answer
mache ic h dann das gleiche nochmals ->
ZitatArduino version => V 2.3v FHEMduino - compiled at Jan  4 216 22:31:35

Dachte, dass er dann in einem Sleep Modus sei.


motopi

nach einiger Recherche denke ich, dass folgendes Problem vorliegt.

https://github.com/raspberrypi/linux/issues/1187

scheinbar macht der Pi das öfter, wenn er im USB 2.0 Modus läuft. Ich versuche mal die vorgeschlagene Lösung.

viegener

Zitat von: motopi am 17 Januar 2016, 18:04:33
nach einiger Recherche denke ich, dass folgendes Problem vorliegt.

https://github.com/raspberrypi/linux/issues/1187

scheinbar macht der Pi das öfter, wenn er im USB 2.0 Modus läuft. Ich versuche mal die vorgeschlagene Lösung.

Was sagt der Arduino denn dann bei uptime, bei einer relativ kurzen uptime ist es wahrscheinlich, dass er aus irgendwelchen Gründen neugestartet hat/wird

Es gibt noch 2 weitere Möglichkeiten:
- Stromsparfunktion an USB --> Es gibt im Forum einen Thread dazu, dass USB-Anschlüsse aruntergefahren werden um Strom zu sparen (nicht sicher welches Linux und ob das auch auf dem PI vorkommt)
- Zu schwaches Netzteil ist ein ständig wiederkehrendes Problem, das sollte man immer mal prophylaktisch bedenken (Ist das wirklich in der Lage >1 / 1.5A an 5V zu liefern) das hat die interessantesten Effekte...

In beiden Fällen würde vermutlich uptime eine kurze Zeit wiedergeben


Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können