Mit 433MHz-Fernbedienung FHEM-Befehle steuern?

Begonnen von marcel151, 21 April 2014, 14:29:07

Vorheriges Thema - Nächstes Thema

marcel151

Hallo,

ich habe einen 433Mhz Sender und kann damit super meine Mumbi-Steckdosen über FHEM schalten. Nun war dort auch ein Empfänger dabei. Es müsste doch Prinzipiell möglich sein damit dann über die Fernbedienung der Mumbi-Steckdosen auch andere Dinge steuern zu können (z.B. meine Hue-Lampen), oder? Über die Tasten A-C steuere ich meine 3 Funksteckdosen außerhalb FHEM. Nun habe ich z.B. noch die ungenutze Taste D die dann für andere Dinge genommen werden könnte.

pilight-receive gibt folgendes aus bei Drücken der Taste D/On:

{
"code": {
"systemcode": 15,
"unitcode": 29,
"state": "on"
},
"origin": "receiver",
"protocol": "elro_hc",
"uuid": "036D-00-00-6D-000300",
"repeats": 1
}


Die Frage ist jetzt, wie lässt sich das in FHEM einbinden? Oder gibt es dazu schon Anleitungen, die ich nur nicht gefunden habe?

betateilchen

schonmal hier im Forum nach elro gesucht? Ich meine, da hab ich schonmal was gelesen.

Ansonsten: den JSON Code auswerten und die Daten unter "code:" entsprechend auswerten. Sollte als Funktion in der 99_myUtils.pm kein allzugroßes Problem sein.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Paul

Zitatich habe einen 433Mhz Sender und kann damit super meine Mumbi-Steckdosen über FHEM schalten.

Wenn ich das richtig verstehe, ist der Sender und die Steckdosen in Fhem angebunden.

Dann brauchst du nur ein notify was bei Tastendruck deines Senders ein set HUE auslöst.

Cubietruck, HM-USB, CUL, FS20, FHT, HUE, Keymatic

mi.ke

Zitat von: marcel151 am 21 April 2014, 14:29:07
ich habe einen 433Mhz Sender

Wenn Du hier mehr Infos bereitstellst, wird es vermutlich einfacher sein, Dir zu antworten.

z.B mit einem z.B. RFXtrx geht das mit einer kleinen Modifikation der Fernbedienungen hervorragend.
http://forum.fhem.de/index.php/topic,9634.0.html
FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

marcel151

#4
Danke für eure Antworten!

Okay, dann hole ich mal weiter aus:
433 MHz Sender: Ein FS1000A, über GPIO am Pi angeschlossen.
433 MHz Empfänger: Ein XY-MK-5V, auch über GPIO am Pi angeschlossen.

Also kein USB-Empfänger/Sender oder dergleichen.

Sender bzw. Steckdosen sind "dumm" und nicht direkt in FHEM eingebunden, sondern wurden mit "GenShellSwitch" in FHEM eingerichtet.

Für die Einrichtung in FHEM bin ich nach dieser Anleitung vorgegangen. Den Empfänger hab ich also bisher garnicht gebraucht, da ich mir Hauscode und ID zusammengerechnet habe. Bin halt jetzt auf die Idee gekommen, dass man ja auch andere Dinge außer meine Funksteckdosen mit der mitgelieferten Fernbedienung über FHEM steuern könnte, pilight erkennt ja die gedrückten Tasten. Den Empfänger bzw. pilight habe ich nach dieser Anleitung eingerichet. Fehlt dann nur halt noch die Einrichtung in FHEM, da hab ich bisher noch nichts zu gefunden. FHEM müsste quasi die Ausgaben von "pilight-receive" auswerten können, damit man wie bereits erwähnt z.B. über notify damit schalten kann.

Schokohoernle

Hallo!

Genau das Gleich habe ich auch vor! Hast du bereits eine Lösung für das Einlesen von pilight-receive?
Ich bin leider was Perl angeht ein ziemlich unbeschriebenes Blatt.

PsychoD

Ich melde auch großes Interesse an - schalten geht super, ich würde aber auch gern darauf reagieren können wenn die Fernbedienungen senden. Aktuell stehe ich komplett auf dem Schlauch, wie ich das machen kann :(

VG

Jens_B

Zitat von: marcel151 am 21 April 2014, 18:29:46
Danke für eure Antworten!

Okay, dann hole ich mal weiter aus:
433 MHz Sender: Ein FS1000A, über GPIO am Pi angeschlossen.
433 MHz Empfänger: Ein XY-MK-5V, auch über GPIO am Pi angeschlossen.

Also kein USB-Empfänger/Sender oder dergleichen.

Sender bzw. Steckdosen sind "dumm" und nicht direkt in FHEM eingebunden, sondern wurden mit "GenShellSwitch" in FHEM eingerichtet.

Für die Einrichtung in FHEM bin ich nach dieser Anleitung vorgegangen. Den Empfänger hab ich also bisher garnicht gebraucht, da ich mir Hauscode und ID zusammengerechnet habe. Bin halt jetzt auf die Idee gekommen, dass man ja auch andere Dinge außer meine Funksteckdosen mit der mitgelieferten Fernbedienung über FHEM steuern könnte, pilight erkennt ja die gedrückten Tasten. Den Empfänger bzw. pilight habe ich nach dieser Anleitung eingerichet. Fehlt dann nur halt noch die Einrichtung in FHEM, da hab ich bisher noch nichts zu gefunden. FHEM müsste quasi die Ausgaben von "pilight-receive" auswerten können, damit man wie bereits erwähnt z.B. über notify damit schalten kann.


Ich glaube nicht das die Empfangsqualität resp. Reichweite des 3 Euro Empfängers ausreicht, damit er auch noch aus einer Entfernung von mehr als 2-3 Metern funktioniert.
RaspberryPi 4 (Raspian Buster)FHEM+Homebridge
HMLAN für Homematic
Z-Wave USB Stick
Shelly Devices
Fritz!Box 7590Ax

alfonsmoeller

#8
Zitat
Ich glaube nicht das die Empfangsqualität resp. Reichweite des 3 Euro Empfängers ausreicht, damit er auch noch aus einer Entfernung von mehr als 2-3 Metern funktioniert.

Hallo Jens_B,
machst Du es Dir nicht zu einfach mit "ist zu billig, kann nicht funktionieren".

Ich komme zu folgendem Ergebnis mit einer ELRO Fernbedienung Gerätecode 14,
Kanal D on off

Wenn ich die Ein-Taste drücke:

{
"code": {
"systemcode": 14,
"unitcode": 8,
"state": "on"
},
"origin": "receiver",
"protocol": "elro_he",
"uuid": "0000-00-00-45-50e00d",
"repeats": 8
}


Wenn ich die Aus-Taste drücke:

{
"code": {
"systemcode": 14,
"unitcode": 8,
"state": "off"
},
"origin": "receiver",
"protocol": "elro_he",
"uuid": "0000-00-00-45-50e00d",
"repeats": 1
}


Dies lässt sich auch zuverlässig wiederholen. Mir fehlt allerdings der Ansatz es
ins FHEM reinzu kriegen.

Ps.: Sender - Empfänger habe ich 3 Paar für zusammen 4,50 Euro erstanden. Allerdings habe ich beides
mit einem 37 cm Draht als Antenne versehen. Empfänger und Sender reichen quer durchs
ganze Haus.
m.f.G. Alfons

Jens_B

Ich habe auch Sender und Empfänger, allerdings funktioniert der Empfänger nur wenn ich mit der Fernbedienung in unmittelbare Nähe bin. Der Sender selber reicht auch bis in den Garten.
Die Antennen sind ebenfalls an die Frequenz angepasst halbe Wellenlänge.



Gesendet von meinem iPhone mit Tapatalk
RaspberryPi 4 (Raspian Buster)FHEM+Homebridge
HMLAN für Homematic
Z-Wave USB Stick
Shelly Devices
Fritz!Box 7590Ax

PsychoD

Habe das gleiche Problem: Sender reicht durch die ganze Bude, der Empfänger reicht nur max. ~50cm. Werd wohl damit leben müssen, dass die Statusanzeigen der Funksteckdosen dumm/unzuverlässig bleiben...

Wzut

Die Erfahrung das mit schlechten Empfängern kein Krieg zu gewinnen ist haben hier schon mehr Leute gemacht  :)
Tipp : im FHEMduino Thread oder auch bei ebay mal nach dem Stichwort Superheterodyne suchen , ein anderer sehr guter Empfänger ( auch aus dem FHEMduino Thread) ist der aus der Pollin Logilink Wetterstation.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

RappaSan

Hallo Alfons,
Glückwunsch zu Deinem Empfänger.
Etliche Leute hier haben allerdings mit dem Billigteil die gleichen miesen Erfahrungen gemacht - ich auch.
Nachdem ich einen etwas aufwändigeren eingebaut habe (Superheterodyne 3400RF, auch nicht viel teurer) , funktioniert aber alles prima.
Der Billigsender hingegen klappt auch bei mir bestens.

PsychoD

Hallo RappaSan,

interessant - kannst du vielleicht etwas mehr Details zu deiner Lösung (insb. Reichweite Empfänger) berichten? Das klingt, als wollte ich es dir nachmachen ;). Kann ich den auch ganz normal via GPIO an den Raspberry klemmen? Hast du ihn an 3 oder 5V?

VG

Zitat von: RappaSan am 29 Dezember 2014, 12:41:49
Hallo Alfons,
Glückwunsch zu Deinem Empfänger.
Etliche Leute hier haben allerdings mit dem Billigteil die gleichen miesen Erfahrungen gemacht - ich auch.
Nachdem ich einen etwas aufwändigeren eingebaut habe (Superheterodyne 3400RF, auch nicht viel teurer) , funktioniert aber alles prima.
Der Billigsender hingegen klappt auch bei mir bestens.

RappaSan

#14
Direkt am Raspberry wird wahrscheinlich auch gehen, aber ich kenne keinen direkten Plan dafür. Mußt Dir also den Weg selbst erarbeiten... :(
Ich hab den FHEMduino mit einem Arduino Nano als Grundlage nachgebaut. Dort sind die Sender/Empfängermodule im Sketch vorgesehen und funktionieren wie gesagt auch prima.
Ein Arduino Nano kostet nur ein paar Euro, Links zu Anbietern gibt's auch im entsprechenden Thread.
Ich kann den Nachbau nur empfehlen...

alfonsmoeller

Hallo RappaSan, Hallo alle Anderen,
Zitat
Etliche Leute hier haben allerdings mit dem Billigteil die gleichen miesen Erfahrungen gemacht - ich auch.
bevor wir das "Billigteil" verteufeln sollten wir erst mal die Grundlagen überprüfen. In der Annahme das die
meisten Leute hier ein Steckbrett verwenden gehe ich davon aus das die Stromversorgung ein mögliche
Störquelle darstellt. Geht doch mal hin und steckt direkt neben dem "Billigteil" einen Elko 100mF und einen
Folienkondensator 10-100nF.
Der Betrieb mit 3,3V oder 5,0V macht keinen großen Unterschied.

m.f.G. Alfons


RappaSan

Wie gesagt - schön, wenn's bei Dir funktioniert.
Ich möchte Dich auch nicht davon abhalten, diese Teile und Kondensatoren zu kaufen.
Ich persönlich bevorzuge lieber den Superheterodyne 3400RF ohne Zusätze.
Vielleicht  funktioniert er auch besser, weil die Frequenzstabilität dank des Quarzes besser ist...


alfonsmoeller

Hallo RappaSan,
ich habe auf Grund Deiner Schilderung folgende Formel erarbeitet:



priceA = Billigteil
priceB = Superheterodyne 3400RF

priceF = priceB/priceA

mit einem 64Bit Intel Processor berechnet

zu erwartenden Besserfaktor = 5,99/1,50 = 3,99333... Periode


Aufgrund der Erkenntnis das ein zu Erwartender Besserfaktor von fast 4 zu erreichen ist,
habe ich das Superheterodyne 3400RF sofort bestellt.
m.f.G. Alfons

JensS

Um auf den Betreff des Threads zurück zu kommen - bei mir fungiert die alte und sendestarke Elro-Fernbedienung erfolgreich zum Umstellen der Verbose-Ausgaben, da ich schreibfaul bin.
define VerboseStatus notify FB1.1 {if (Value('FB1.1') eq "on"){fhem("attr global verbose 5; attr CUL433 verbose 5;")}else{fhem("attr global verbose 0; attr CUL433 verbose 0;")}}
Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

alfonsmoeller

Hallo dirigent,
kannst Du auch die Definition der "FB1.1" und den Hintergrund durchschieben?
Danke !
m.f.G. Alfons


JensS

define FB1.1 IT F000F0FF0F FF F0
attr FB1.1 model itremote
Eine Fernbedienung halt.
Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

RappaSan

Hallo PsychoD,

Reichweite Empfänger: Zumindest ordentlich, kann ich nicht so genau sagen. Antenne am Empfänger ist eine 1/4 Lambda für 433 MHz. Versorgungsspannung siehe FHEMduino. Zur Zeit empfange ich damit die Daten von einem Oregon Temperatur/Luftfeuchtesensor und der ELRO Fernbedienung.

Ich hab ein Haus mit 3 Stockwerken, Betondecke mit ordentlich Eisen drin.
Das ist schon mal kein Problem bisher. Ab und zu bekomme ich noch von den Nachbarn Daten einer Oregon Wetterstation, aber ich weiß nicht von welchen Nachbarn... :)

Wzut

#22
Für die pilight Nutzer gibt es zum Senden bereits seit längerem unter contrib das Modul 98_pilight.pm, allerdings nützt einem das recht wenig wenn wie hier gewünscht Daten von pilight empfangen werden sollen. Ich habe mal quick & dirty  ein Modul dafür zusammengebaut.
Vorbereiitung :
a. sicher stellen das der pilight Daemon auf einem festen Port lauscht , dazu muss in der /etc/pilight/settings.json
ein Eintrag für port vorhanden sein ( nicht webserver-port !)
"port": 5000

b. das JSON Perl Modul muss installiert sein :
sudo apt-get install libjson-perl
c. die Definition in FHEM :
define mypi PILIGHTrec localhost:5000
localhost wenn pilight und FHEM auf dem gleichen Gerät laufen sonst die IP/Namen des pilight Servers plus der Port aus der /etc/pilight/settings.json
Das Modul versucht nun Meldungen des pilight Daemon in sinnvolle Readings zu packen die dann leicht weiter zu verwenden sind.
Telegramme die nicht dekodiert werden können findet man im Logfile , ggf. testweise den Loglevel von FHEM mal auf 4 erhöhen.

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

JensS

Hallo Wzut,

die Möglichkeit mit pilight klingt gut - ist pilight parallel am selben CUL433 des fhem möglich oder brauche ich einen separaten CUL?

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Wzut

CUL ? Hier geht es nicht um CULs , FHEMduinos oder andere USB Lösungen sondern direkt an die GPIO Pins des Raspberry angeschlossene Empfänger 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

JensS

Danke für die Antwort und bitte entschuldige meine unqualifizierte Frage. Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

iro

Hey Wzut,

tausend Dank, genau auf das Modul habe ich gewartet :D

Hab das Modul wie oben beschrieben eingebunden, allerdings bleibt der Status auf "disconnected".

define RemoteBananaRX PILIGHTrec 192.168.1.99:5000

Pilight läuft remote auf einem Banana Pi, Fhem auf einem NUC, deshalb auch die IP.

Kann es sein, dass dein Modul die nightly builds von pilight nicht unterstützt? Da hat sich einiges geändert, u.a. auch einiges an der config. Z.B. gibt es die /etc/pilight/settings.json nicht mehr, sondern nur noch die /etc/pilight/config.json.

Dort ist allerdings auch wie in settings.json der Port 5000 angegeben.

Gruß iro

Wzut

Zitat
Kann es sein, dass dein Modul die nightly builds von pilight nicht unterstützt?
sorry keine Ahnung , ich habe mich an diese Anleitung gehalten : http://www.pilight.org/nightlydevelopment/nightlyapi/
Teste doch ersteinmal via Telnet oder  nc lokal und danach prüfe ob irgend eine Regel auf deinem System Zugriffe von Netzwerkseite auf  Port 5000 verbietet.
Ich habe das bei mir mit Erfolg auf einem verteilten System getestet.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

iro

Ok, dann sollte es ja eigentlich funktionieren :) Installiere gerade das neuste nightly build und teste dann gleich nochmal. Danke für die schnelle Rückmeldung!

Gruß iro

iro

Nochmal getestet, leider immer noch Status "disconnected".

Auf dem Banana läuft lokal auch noch eine Fhem Instanz. Ebenfalls getestet, leider gleiches Ergebnis - Pilight disconnected.

Hab Pilight gerade im Debug Mode laufen lassen, die Clients connecten und disconnecten dann gleich wieder:

NUC Fhem remote:
[Jan 02 20:22:51:798807] pilight-daemon: INFO: new client, ip: 192.168.1.100, port: 59504
[Jan 02 20:22:51:799055] pilight-daemon: DEBUG: client fd: 17
[Jan 02 20:22:51:799174] pilight-daemon: DEBUG: client id: 4
[Jan 02 20:22:51:801718] pilight-daemon: DEBUG: socket recv: { "message": "client receiver" }
[Jan 02 20:22:51:801973] pilight-daemon: DEBUG: client disconnected, ip 192.168.1.100, port 59504


Banana Fhem lokal:
[Jan 02 20:24:25:580558] pilight-daemon: INFO: new client, ip: 127.0.0.1, port: 40837
[Jan 02 20:24:25:580741] pilight-daemon: DEBUG: client fd: 17
[Jan 02 20:24:25:580821] pilight-daemon: DEBUG: client id: 4
[Jan 02 20:24:25:590649] pilight-daemon: DEBUG: socket recv: { "message": "client receiver" }
[Jan 02 20:24:25:590850] pilight-daemon: DEBUG: client disconnected, ip 127.0.0.1, port 40837


Eine Idee? :)

Gruß iro

Wzut

#30
attr verbose auf 4 stellen und im log schauen welche Antwort der pilight Server auf die Anfrage  "message": "client receiver"  gibt.
bei mir schaut das dann nach einem "set mypi reeset"  so aus :
2015.01.02 21:10:09 3: Opening mypi device pi2.fritz.box:5000
2015.01.02 21:10:09 3: mypi device opened
2015.01.02 21:10:09 4: SimpleWrite -> { "message": "client receiver" }
2015.01.02 21:10:09 4: ReadAnswer ({"message":"accept client"}) -> {"message":"accept client"}


Oder wie bereits geschrieben via telnet versuchen dann sieht man die Antwort des pilight direkt
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

iro

#31
Folgendes steht im Log:
2015.01.02 21:42:37 3: Opening PilightRX device localhost:5000
2015.01.02 21:42:37 3: PilightRX device opened
2015.01.02 21:42:37 4: SimpleWrite -> { "message": "client receiver" }
2015.01.02 21:42:37 1: localhost:5000 disconnected, waiting to reappear (PilightRX)
2015.01.02 21:42:37 4: eventTypes: PILIGHTrec PilightRX DISCONNECTED -> DISCONNECTED
2015.01.02 21:42:37 1: Cannot init localhost:5000, ignoring it (PilightRX)


Telnet habe ich mit Putty versucht, laut pilight log connected:
[Jan 02 21:44:45:607929] pilight-daemon: INFO: new client, ip: 192.168.1.40, port: 11517
Allerdings bleibt das Putty Fenster leer.

Wie sieht denn deine Pilight config aus? Und welche Version nutzt du genau?

[EDIT]
Hier noch die Auszüge wenn ich pilight-daemon -D laufen lasse:
[ Jan 03 00:39:59:83246] pilight-daemon: INFO: new client, ip: 192.168.1.100, port: 34250
[ Jan 03 00:39:59:83406] pilight-daemon: DEBUG: client fd: 17
[ Jan 03 00:39:59:83523] pilight-daemon: DEBUG: client id: 4
[ Jan 03 00:39:59:86125] pilight-daemon: DEBUG: socket recv: { "message": "client receiver" }
[ Jan 03 00:39:59:86320] pilight-daemon: DEBUG: client disconnected, ip 192.168.1.100, port 34250


Ganz zu Anfang connected pilight selbst zu dem daemon, sieht so aus:
[Jan 03 00:44:10:241334] pilight-daemon: INFO: new client, ip: 192.168.1.99, port: 53881
[Jan 03 00:44:10:241495] pilight-daemon: DEBUG: client fd: 15
[Jan 03 00:44:10:241711] pilight-daemon: [Jan 03 00:44:10:241731] pilight-daemon: DEBUG: socket write succeeded: {"action":"identify","options":{"config":1,"core":1},"media":"web"}

DEBUG: client id: 2
[Jan 03 00:44:10:242027] pilight-daemon: DEBUG: [Jan 03 00:44:10:242064] pilight-daemon: INFO: new client, ip: 192.168.1.99, port: 53882
socket write succeeded: {"action":"identify","options":{"config":1},"media":"all"}

[Jan 03 00:44:10:242177] pilight-daemon: DEBUG: client fd: 16
[Jan 03 00:44:10:242338] pilight-daemon: DEBUG: client id: 3
[Jan 03 00:44:10:242478] pilight-daemon: DEBUG: socket recv: {"action":"identify","options":{"config":1},"media":"all"}
[Jan 03 00:44:10:242727] pilight-daemon: DEBUG: socket write succeeded: {"status":"success"}

[Jan 03 00:44:10:242857] pilight-daemon: DEBUG: socket recv: {"action":"identify","options":{"config":1,"core":1},"media":"web"}
[Jan 03 00:44:10:243032] pilight-daemon: DEBUG: socket write succeeded: {"status":"success"}


Sieht so aus als würde sich Pilightrec nicht richtig authenzifizieren, sprich das "identify" fehlt?


[EDIT2]

Test per Telnet über Putty funktioniert doch, man muss nur den richtigen String eingeben um ne Antwort zu erhalten ;)

{"action":"identify","options":{"config":1},"media":"all"}
{"status":"success"}

                    {"origin":"update","type":3,"devices":["wetterAussen"],"values":{"timestamp":1420243003,"temperature":0.9,"humidity":157.0,"battery":0}}


Zuerst mein "identify", dann der "success" des Pilight Servers und im Anschluss ein Empfangener Wert eines Außensenders der vom Server "durchgereicht" wurde.

Versuche ich wie von dir beschrieben ein "{ "message": "client receiver" }", wird die Verbindung sofort geschlossen.

Scheint imho alles auf ein fehlendes "identify" zu deuten?

Gruß iro

Wzut

also um es kurz zu machen : deine nightly builds  haben wohl nicht nur eine andere Art der config auch die API scheint sich ganz anders zu verhalten als in meiner Version bzw wie hier http://www.pilight.org/nightlydevelopment/nightlyapi/  beschrieben. Gibt es eine Anleitung zum Download usw. der von dir benutzen Version ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

iro

Heyho,

laut dem String der von dir gesendet wird, hast du dich aber an http://www.pilight.org/development/api/ und nicht an http://www.pilight.org/nightlydevelopment/nightlyapi/ orientiert. Der Befehl von mir entspricht genau der Syntax aus der nightlyapi, die du in deinem letzten Post verlinkt hast.

Installation ist simpel, unter Debian einfach drei neue Paketquellen hinzufügen, Anleitung hier: http://www.pilight.org/getting-started/installation/#stable_apt
Wichtig sind alle drei:
deb http://apt.pilight.org/ stable main
deb http://apt.pilight.org/ development main
deb http://apt.pilight.org/ nightly main


und mit aptitude install pilight wird dann die letzte nightly installiert.

Alternativ selbst kompilieren: http://www.pilight.org/getting-started/installation/#stable_git
git clone --depth 5 -b development https://github.com/pilight/pilight.git

Wichtig hierbei war bei mir allerdings, dass die erste der drei Quellen in der sources.list war. Zum selbst bauen brauch man ein paar Pakete aus dem Repository.

Falls ich noch weiter helfen, mehr Infos liefern oder testen soll, einfach melden :)

Danke für deine Mühe!

Gruß iro

Wzut

#34
Bitte mal die angehängte Version testen , die sollte sowohl mit der 5.0 Version als auch mit nightly klar kommen.
WICHTIG : bei nightly noch irgend etwas als vierten Parameter zum Umschalten der version anhängen
define mypil PILIGHTrec localhost:5000  -> alt (5.0 Version)
define mypil PILIGHTrec localhost:5000  1 -> nightly
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

iro

Getestet und funktioniert 1A, Logs kommen an. Danke! :)

Jetzt müsste nur noch pilight meine Elro Fernbedienung richtig erkennen und nicht jedes mal drei verschiedene Protkolle anzeigen^^


Hast du geplant das Modul aktiv weiter zu entwickeln? Gäbe u.a. ja auch noch die Protkolle der Wetterstationen, Tür- und Fensterkontakte, und und und die man noch einbinden könnte ;)

Ich bekomm z.B. von einem Nachbar das Signal einer Wetterstation.

Sieht in Pilight so aus:
root@banana ~ # pilight-receive
{
        "message": {
                "id": 22,
                "temperature": 1.0,
                "humidity": 99.0,
                "battery": 1
        },
        "origin": "receiver",
        "protocol": "alecto_wx500",
        "uuid": "0341-50-48-52-494848",
        "repeats": 1
}
{
        "message": {
                "id": 1664,
                "temperature": 0.9,
                "humidity": 149.0,
                "battery": 0
        },
        "origin": "receiver",
        "protocol": "alecto_ws1700",
        "uuid": "0341-50-48-52-494848",
        "repeats": 1
}
{
        "message": {
                "id": 22,
                "temperature": 1.0,
                "humidity": 99.0,
                "battery": 1
        },
        "origin": "receiver",
        "protocol": "alecto_wx500",
        "uuid": "0341-50-48-52-494848",
        "repeats": 2
}
{
        "message": {
                "id": 1664,
                "temperature": 0.9,
                "humidity": 149.0,
                "battery": 0
        },
        "origin": "receiver",
        "protocol": "alecto_ws1700",
        "uuid": "0341-50-48-52-494848",
        "repeats": 2
}
{
        "message": {
                "id": 22,
                "temperature": 1.0,
                "humidity": 99.0,
                "battery": 1
        },
        "origin": "receiver",
        "protocol": "alecto_wx500",
        "uuid": "0341-50-48-52-494848",
        "repeats": 3
}
{
        "message": {
                "id": 1664,
                "temperature": 0.9,
                "humidity": 148.0,
                "battery": 0
        },
        "origin": "receiver",
        "protocol": "alecto_ws1700",
        "uuid": "0341-50-48-52-494848",
        "repeats": 3
}


Und in Fhem so:
2015-01-03 19:08:57 PILIGHTrec RemoteBananaRX alecto_wx500: unknown
2015-01-03 19:08:57 PILIGHTrec RemoteBananaRX alecto_ws1700: unknown
2015-01-03 19:08:57 PILIGHTrec RemoteBananaRX alecto_wx500: unknown
2015-01-03 19:08:57 PILIGHTrec RemoteBananaRX alecto_wsd17: unknown
2015-01-03 19:08:57 PILIGHTrec RemoteBananaRX alecto_ws1700: unknown
2015-01-03 19:08:58 PILIGHTrec RemoteBananaRX alecto_wx500: unknown
2015-01-03 19:08:58 PILIGHTrec RemoteBananaRX alecto_ws1700: unknown


Wäre es möglich die temperature und humidity mit Hilfe einer Regex auszulesen und mit zu übergeben?

Dummerweise unterscheidet sich das alecto_wx500 Protokoll hier nochmals von dem in Pilight integrierten Protokoll (dort werden auch noch Batterie- und Windwerte erwartet) und die Werte von alecto_ws1700 machen keinen Sinn. Würde mir den Außensensor ersparen :D

Gruß iro

Wzut

#36
Zuviel Energie wollte ich eigentlich nicht in das Modul stecken da ich pilight nicht aktiv nutze. Daher sind meine Möglichkeiten was Tests betrifft stark eingeschränkt.
Was die Wetter Geschichte betrifft , teste doch mal die angehängte Version , die sollte mit openwethermap und alecto sowie dem geänderten rpi_temp  halwegs klar kommen. Wobei dann der Thread doch langsam in Richtung OT wandert da es eigentlich ja nur um das erkennen von 433Mhz Fernbedienungen ging.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

iro

Läuft ebenfalls, super! :D

Du hast Recht, gleitet wirklich etwas ab^^ Evtl. einfach einen neuen Thread für das Modul erstellen? Denke es dürften sich garantiert auch noch einige andere User darüber freuen, nicht dass das unter geht :)

Gruß iro

Wzut

Ich habe mal in meiner Bastelkiste gekramt und ein paar 433Mhz Temperatur Sensoren gefunden.
Bei der aktuellen Version überschreibt ein Sensor den nächsten wenn das gleiche Protokoll verwendet wird.
Um dies zu verhindern werte ich nun die ids aus, sofern sie von piilight gesendet werden. Allerdings kann es sein das mit durch defekte Telegramme und Sensoren Nachbarn förmlich mit Readings erschlagen wird. Um dies etwas einzudämmen gibt es in der neuen Version zwei neue Atrribute :
attr repeats (defaultwert 3) :
viele Sensoren wiederholen mehrfach ihre Telegramme, mit dem Attribut lässt sich festlegen wieviel Wiederholungen mindestens vorhanden sein müssen.
attr idlist ( default keine) : eine Liste durch Kommas getrennt welche IDs berücksichtigt werden sollen , Bsp  1, 1417
es werden nur Telegramme mit der ID 1 und 1417 ausgewertet.
Mit den beiden Attributen lässt sich die Flut recht gut auf die eigenen Sensoren begrenzen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

iro

Hi,

die repeats funktionieren super, allerdings erscheint nichts mehr im Event Monitor oder Logfile, wenn ich eine ID setze:
attr RemoteBananaRX idlist 22

Ohne idlist habe ich u.a. wieder folgendes im Event Monitor:
2015-01-06 19:20:46 PILIGHTrec RemoteBananaRX 22.alecto_wx500_temp: 0.0

Außerdem wird immer wieder zusätzlich das attr nightly 1 in die config geschrieben, welche beim fhem restart zu folgender Fehlermeldung führt:
Error messages while initializing FHEM:
configfile: RemoteBananaRX: unknown attribute nightly. Type 'attr RemoteBananaRX ?' for a detailed list.



Um zum Ursprung des Threads zurück zu kommen, ich würde jetzt natürlich gerne mit einem notify den Status des Licht-dummys ändern, wenn dieses mit der Funkfernbedienung und nicht über FHEM geschaltet wird.
Klappt natürlich nicht so richtig  ::)

Mein Versuch sieht so aus:
define n_rx_remote_Dose05 notify RemoteBananaRX:silvercrest-5-1:.* { fhem "setstate remote_Dose05 $EVENT" }

Leider passiert überhaupt nichts. Fernbedienung wird im Event Monitor folgendermaßen erkannt:
2015-01-06 20:06:52 PILIGHTrec RemoteBananaRX silvercrest-5-1: off
und
2015-01-06 20:07:01 PILIGHTrec RemoteBananaRX silvercrest-5-1: on

Gruß iro

Wzut

Hmm , ich habe den pilight z.Z nicht am laufen (andere Baustelle aktiv) , aber wegen der idlist ; setze doch einfach die 22 zweimal , also 22,22 - Ich hatte immer min zwei Werte drin vllt. habe ich da noch einen Bug drin bei nur einem Wert - kannst aber selbst mal schauen mit verbose 4 oder 5, da listet es im log auf warum ein Telegramm verworfen wurde.
Das mit dem Attr nighly ist noch ein Fehler - schiebe ich die Tage den Fix dafür nach.
Dummy setzen via notify, warum setstate ? Ich setze meine Dummys immer einfach mit set dummyname Wert :)

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

iro

idlist probiere ich morgen nochmal, eilt ja nicht :)

setstate aus dem Grund, da mit set dummyname Wert der Schaltvorgang ja nochmal getriggert wird. Wollte damit etwas Funkverkehr einsparen :)
Wichtig ist einfach nur, dass Fhem mitbekommt, dass sich der Status geändert hat und man das z.B. auch auf dem Floorplan via Icon angezeigt bekommt.

Wie es aussieht passt die Regex wohl nicht, sonst müsste im Event Monitor ja das notify auftauchen, oder?

Gruß iro

Wzut

gerade mal mit einem Temp Wert probiert und geht :
define rpi_temp notify mypil:1\.cpu_temp:.* { fhem "set rpi $EVTPART1" ;;}
der . im Reading Namen war wohl keine gute Idee von mir .....
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

iro

#43
Zitat von: Wzut am 06 Januar 2015, 22:08:37
der . im Reading Namen war wohl keine gute Idee von mir .....

Vllt. einfach durch einen Unterstrich ersetzen? :)

Das wird allerdings nicht das Problem bei meinem notify sein, das Device hat keine ID die mit einem Punkt abgetrennt ist  :-\

PILIGHTrec RemoteBananaRX silvercrest-5-1: off


[EDIT]
Das notify tut doch irgendwie, allerdings wird als Status nicht on oder off gesetzt, sondern silvercrest-5-1: off oder silvercrest-5-1: on.
Kann man das noch irgendwie rausfiltern, dass nur on oder off als Status gesetzt wird? :)

Gruß iro

Wzut

Die Lösung steckt in meinem Beispiel -> $EVTPART1 ist dein Freund
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Risiko

Hallo Wzut,

super Arbeit. Vielen Dank für das Modul. Funktioniert prima.
Ne Kleinigkeit: Habe in den Readings zwei Punkte <id>..<device>

Ich habe noch eine Fragen betreffs Blockierung bzw. korrigiere mich bitte.

Gerade in PILIGHTrec_ReadAnswer wird 3s gewartet. Da diese Funktion  immer wieder von PILIGHTrec_Ready aufgerufen wird (Prüfung ob bei einem Disconnect wieder eine Verbindung aufgebaut werden kann),kommt es doch zu häufigen Blockierungen?
Könnte man die Sachen aus PILIGHTrec_ReadAnswer nicht auch in PILIGHTrec_Ready prüfen? Die wird doch eh nur aufgerufen, wenn Daten anliegen.

Risiko.

Risiko

Hallo.

Ich habe die Version von Wzut etwas überarbeitet.
1. Die Namen der Readings sind jetzt protokoll-ID-[unit]-[etc] - bei Temperatur protokoll-ID_temp
2. Wenn der pilight-daemon nicht erreichbar ist, blockiert FHEM weniger\nicht
3. Das Attribut nightly wurde entfernt - verwendete API in den INTERNALS

Risiko.

Wzut

Oh je , ist das jetzt die Rache weil ich in deinem MAX Wochenprofil Modul rumgefuscht habe ? :)

Scherz beiseite : fein fein , besonders gefällt mir das man so elegant die Versionen unterscheiden kann !!
Aber wenn du schon am Readings Umbau bist : Mir ist die Tage bei Versuchen mit dem Conrad RSL Protokoll ein neues Feld aufgefallen , zusätzlich zu den den ganzen units , housecode, ids usw nennt sich "all" und hat als Wert 0 oder 1 . Dieses all taucht immer dann auf wenn man auf der Conrad RSL FB das unteren Tastenpaar ALL-ON oder ALL-OFF benutzt

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Risiko

Hallo Wzut,

die Sache mit den Readings war nur ne Kleinigkeit (2. Punkte im Namen). So richtig glücklich bin ich damit aber auch nicht.
Habe mich auf die Blockierung konzentriert.
Es kommen da schon einige Sachen zusammen und das alles in einen Namen zu legen, ich weiß nicht.
Ich verwende einen ITDM-250 Dimmer und da gibt es neben state logischerweise auch noch dimlevel.
Eine elegante Lösung ist mir noch nicht eingefallen.
Vielleicht sowas:

id_uid_housecode
id_uid_ALL-ON-OFF
id_uid_dimlevel

Da kommen unter Umständen aber einige Readings zusammen.

Hast du da evtl. ne besser Idee?

Mir schwebt auch vor, das Modul zu einem Controller auszubauen - also auch Senden.
Das aktuelle pilight Modul kann leider keine Dimmer. Ich habe versucht zu  Andreas Fey Kontakt aufzunehmen, (noch) kein Erfolg.

Risiko.

Wzut

Also wenn ich ehrlich bin , mir gefällt diese ganze Readings Wust ganz und gar nicht. Je nachdem wie der User sein pilight ausgebaut hat kann das noch wesentlich mehr sein. Wenn du aber eh bereit bist da noch mehr Zeit und Arbeit zu investieren ( Stichwort senden) dann wäre jetzt vielleicht der passende Zeitpunkt den "kranken Ochsen zu schlachten statt ihm noch ein Pflaster aufzukleben" :)
Ich will damit sagen das nach meiner Meinung das pilight Grundmodul sich nur um die nackte Kommunikation mit dem pilight Deamon kümmern sollte ( send & receive )  wie Bsp  das 00_CUL oder das MAXLAN Modul.
Alles was dann die eigentlichen Geräte betrifft ( Steckdosen , Temp Sensoren) mit eigenen Modulen abwickeln - bei den Wettersensoren u.U. auf bereits bestehende zurückgreifen,  da die eh nur anzeigen, bei den Steckdosen , Dimmer, Rollos, etc  ein Clone/Bruder von Bsp. 10_IT.pm. Der Vorteil wäre das dann jedes Gerät seine eigenen Readings und Attribute hat und der User kann dafür einen Namen vergeben der zum bestehenden Gerätenamen in der pilight config passt oder sogar identisch ist.
ZitatIch habe versucht zu  Andreas Fey Kontakt aufzunehmen, (noch) kein Erfolg
Ist nicht so tragisch wenn du damit keinen Erfolg hast , Module mit verschwundenen Eltern gibt es öfters und eine Adoption der Waise sollte nach einer Rücksprache mit Rudi auch kein unüberwindliches Hinderniss darstellen.   
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Risiko

Ja so eine ähnliche Antwort hatte ich schon erwartet.  ;)
Bin da voll auf deiner Seite. Das Ganze ist aber nicht gerade mal eben getan.
Werde erst mal mit kleinen Schritten weiter machen und mich weiter einarbeiten (Stichwort Grundmodul <-> Devicemodul).
Vielleicht finden sich ja Anhänger. :)

Risiko.

raspberry

Guten Abend zusammen,

das Modul ist echt ne super Idee und funktioniert klasse! Vielen Dank dafür! Ein Problem habe ich aber noch. Wie kann ich ein Reading in ein "notify" mit einbauen? Hab schon viele Möglichkeiten probiert, aber nichts hat geklappt.

z. B.

define mypiNotify notify mypi:2\.arctech_contact-17277950-7 { fhem "set switch on"}


Bin leider erst in FHEM eingestiegen und die Grundlagen fehlen noch. :(

Besten Dank und schönen Abend

raspberry

raspberry

#52
Zitat von: raspberry am 13 Februar 2015, 23:25:19
Guten Abend zusammen,

das Modul ist echt ne super Idee und funktioniert klasse! Vielen Dank dafür! Ein Problem habe ich aber noch. Wie kann ich ein Reading in ein "notify" mit einbauen? Hab schon viele Möglichkeiten probiert, aber nichts hat geklappt.

z. B.

define mypiNotify notify mypi:2\.arctech_contact-17277950-7 { fhem "set switch on"}


Bin leider erst in FHEM eingestiegen und die Grundlagen fehlen noch. :(

Besten Dank und schönen Abend

raspberry

Hab's nun herausgefunden. Hier ein Beispiel für alle die auch Probleme haben. Ich verwende den Timestamp um zu überprüfen, ob auch wirklich der entsprechende Kontakt geändert wurde, oder ein anderes Reading, dann sollte nicht geschaltet werden.


define test notify mypi {
if (ReadingsVal("mypi","arctech_contact-17277950-7","") eq "opened" && time_str2num(ReadingsTimestamp("mypi","arctech_contact-17277950-7","")) eq time) {
fhem("set WohnzimmerDeckeLampe on")
}
elsif (ReadingsVal("mypi","arctech_contact-17277950-7","") eq "closed" && time_str2num(ReadingsTimestamp("mypi","arctech_contact-17277950-7","")) eq time) {
fhem("set WohnzimmerDeckeLampe off")
}
}


Oder kann eine Änderung eines Readings direkt im notify pattern abgefragt werden? 
Irgendwie so?
define mypiNotify notify "mypi arctech_contact-17277950-7:closed" {}

Wzut

define  mypiNotify notify mypl:arctech_contact-17277950-7:.* { fhem "set WohnzimmerDeckeLampei $EVTPART1" ;;} ?

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Risiko

Hallo.

Ich habe für pilight nun Module zum Senden und Empfangen (beta).
1. pilight_ctrl - Basismodul für die Kommunikation (senden, empfangen)
2. pilight_switch - Modul für Schalter
3. pilight_dimmer- Modul für Dimmer (folgt demnächst)

Weitere Module für z.B. Sensoren, etc. können anschließend relativ einfach auf dieser Basis erstellt werden.

Es wäre schön, wenn jemand mit Testen könnte, bevor ich dann versuche das Ganze ins SVN zu bekommen.
Ich habe leider nicht so viel unterschiedliche Hardware.
Unter Umständen gehen noch nicht alle Schalter. Bin auf euer Feedback gespannt.

Zur Anwendung:

1. Basismodul z.B.

define <name> pilight_ctrl <host:port> [6.0]

6.0 nur, wenn man die nightly-Version von pilight verwendet.

2. Switch

define <name> pilight_switch <protocol> <id> <unit>

Beispiel für einen arctec_switch_old (Kaku, Intertechno)

define pilightCtrl pilight_ctrl localhost:5000 6.0
attr pilightCtrl brands arctech:kaku

define pilightSwitch pilight_switch kaku_switch_old 0 0


Da es für ein Protokoll unterschiedliche Bezeichnungen (brands) gibt, und pilight nicht alle gleich behandelt (Unterschied zwischen Senden und Empfangen) kann man mit dem Attribut brands eine Protokollumbenennung beim Empfang vornehmen.
Im Beispiel wird "arctech" durch "kaku"  ersetzt, so dass der Switch mit der kaku Protokoll Definition auch beim Empfang die Nachricht bekommt.
Das Attribut brands ist eine Liste der Form "search1:replace1, search2:replace2"

Danke und viel Spaß.

Risiko

Wzut

Mann , Mann du kniest dich da ja voll rein  8)
Werde ich mir auf alle Fälle diese Woche  (vermutlich Di Abend ) mal genau anschauen
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Jens_B

Gibt es nicht für das schalten von Steckdosen ein fertiges Modul welches sich pilight nennt? Ich habe jetzt hier nicht den ganzen Thread verfolgt, aber ich benutze das hier schon sehr lange.
Gruß
Jens


Gesendet von meinem iPhone mit Tapatalk
RaspberryPi 4 (Raspian Buster)FHEM+Homebridge
HMLAN für Homematic
Z-Wave USB Stick
Shelly Devices
Fritz!Box 7590Ax

Wzut

Zitat von: Jens_B am 25 Februar 2015, 12:16:33
ein fertiges Modul welches sich pilight nennt?
doch
Zitat
Ich habe jetzt hier nicht den ganzen Thread verfolgt
wenn du aber tun würdest hätte sich auch deine Frage geklärt :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Risiko

Hallo.

Wie angekündigt, hier nun das Dimmer-Modul.
Beispiel:

define pilightDimmer pilight_dimmer kaku_dimmer 12835681 0
attr pilightDimmer webCmd on:off:dimlevel


Info:
pilight 6.0 ist nun released ;D

Risiko.

Jens_B

Zitat von: Wzut am 25 Februar 2015, 12:43:08
dochwenn du aber tun würdest hätte sich auch deine Frage geklärt :)

Nun gut, welchen Vorteil hat pilgiht_control gegenüber den pilight Modul, so wie ich es verwende zum Schalten von Steckdosen?
Vielleicht noch mal ohne das ich den ganze Thread durcharbeiten muß?

Ich sehe schon das man damit auch Empfangen kann, aber die Steckdosen senden ja eh nicht? Und zum Empfang sollte man wohl auch noch einen ordentlichen Empfänger haben, den welchen ich nutze der taugt keine 30 centimeter....

Gruß
Jens
RaspberryPi 4 (Raspian Buster)FHEM+Homebridge
HMLAN für Homematic
Z-Wave USB Stick
Shelly Devices
Fritz!Box 7590Ax

Risiko

Hallo Jens,

also wenn du nichts empfangen willst, keine Dimmer hast und nicht auf pilight 6.0 wechselst - dann nichts.

Ja Steckdosen selbst senden nichts, die passende Fernbedienung schon ;)

Das mit den Empfängern ist hier im Forum auch schon öfters diskutiert wurden und ja es gibt bessere Empfänger.

Risiko.

Jens_B

Hallo Risiko
Danke für deine ausführliche Antwort :-).
Hm, ich habe pilight damals nicht über das rep installiert, sondern manuell. Und habe auch nur die 3er. Traue mich auch nicht upzudaten, da ich nicht weiß wie;) und ich außerdem nicht weiß was dann wieder nicht funktioniert. ;).
Ich müsste mal schauen, was zwischen 3 und 6 anders ist.
Gruß
Jens



Gesendet von meinem iPhone mit Tapatalk
RaspberryPi 4 (Raspian Buster)FHEM+Homebridge
HMLAN für Homematic
Z-Wave USB Stick
Shelly Devices
Fritz!Box 7590Ax

raspberry

Ich habe mittels pilight_ctrl und pilight_switch pilight an FHEM angebunden.


define pilight pilight_ctrl localhost:5000 6.0
attr pilight brands arctech_switch:kaku_switch

define Dev1 pilight_switch kaku_switch 17277950 2


Das Empfangen des Zustandes von Dev1 mit der Fernbedienung läuft super. Wenn ich allerdings über FHEM schalten möchte ("set Dev1 on"), erhalte ich folgende Fehlermeldung:


No IO device or WriteFn found for Dev1


Ich denke das Problem ist die Funktion IOWrite() die von pilight_switch_Set() aufgerufen wird. $iohash ($iohash = $hash->{IODev};) ist leer. Habe ich das richtig verstanden, dass pilight_ctrl und pilight_switch ein zweistufiges FHEM Modul ist? Wie kommuniziert pilight_switch zurück an pilight_ctrl?

Besten Dank für die Hilfe und viele Grüße

raspberry

Wzut

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Risiko

Hallo raspberry,

bitte den neuen Thread + letzte Version des Moduls verwenden.
Danke.

Es ist wichtig, dass von der Reihenfolge der defines erst pilight_ctrl definiert wird.
Die Verbindung zwischen den zweistufigen Modulen erfolgt in fhem.pl

Risiko.

erotikbaer

Hallo Zusammen,

ich bin am verzweifeln! ich bin absoluter fhem neuling (seit gestern).
Mittlerweile läuft FHEM, SmartVisu und Homebridge echt super. Stolz wie Bolle hab ichs meinem frauchen demonstriert!
zitat: "ja super! echt cool,aber ich hoffe ich kann die Fernbedienung noch benutzen?"

so und damit beginnt das theater :) ich komme an dem Punkt einfach nicht weiter, das hier gebaute pilight_ctrl.pm läuft und ich habe
define FhemPi pilight_ctrl 127.0.0.1:5000 gemacht und der status ist auch connected.

und nun?

ich möchte halt gern, dass wenn wir auf der fernbedienung (elro mit A B C D on und Off) ein gerät einschalten, soll das fhem übernehmen, damit der status bei fhem korrekt ist.

kann mir jemand anhand eines beispiels sagen was ich noch machen muss?
das wäre echt super!

viele Grüße aus Berlin

erotikbaer

sash.sc

Die Codes über pilight_receive auslesen, merken und über ein notify in fhem definieren.  Dann sollte es mir dem Status klappen. Habe so auch angefangen.
Bin dann auf nen nanocul gewechselt. Fernbedienung wird dann über autocreate automatisch angelegt

Gruß
Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

erotikbaer

#67
also doch noch alles manuell?! wenn ich mich ums pilight-receive selbst kümmern muss, dann verstehe ich den sinn und zweck von dem plugin nicht.

ich dachte das plugin liest die ausgabe vom pilight-receive und ich habe dann die möglichkeit aus fhem darauf zu reagieren!?


Ergänzung: ok..., sorry. nach 5 minuten nachdenken hab ich verstanden was du meinst.
also pilight-receive nur, damit ich weiß was da so ankommt von der fernbedienung und daraus dann ein notify basteln.

habs jetzt mal versucht in der doku von fhem zu verstehen, aber so richtig klick machts noch nicht...
define MeineFernbedienungTasteAan notify FhemPi set Balkon:on {"message":{"systemcode":1,"unitcode":15,"state":"on"},"origin":"receiver","protocol":"elro_400_switch","uuid":"0000-b8-27-eb-ab55ca","repeats":1}

müsste das so funktionieren?
kannst du mir da ein wenig auf die sprünge helfen?

Ergänzung2: so, nun habe ich mittlerweile gedacht es verstanden zu haben... aber anscheinend nicht.
folgendes hab ich jetzt  angelegt:
define MeineFernbedienungTasteAan notify FhemPi {"message":{"systemcode":1,"unitcode":15,"state":"on"},"origin":"receiver","protocol":"elro_400_switch","uuid":"0000-b8-27-eb-ab55ca","repeats":1} "system("/usr/bin/send 11110 4 1 &")"

und im eventmonitor sehe ich:
2016-04-09 22:43:04 pilight_ctrl FhemPi rcv_raw: {"message":{"systemcode":1,"unitcode":15,"state":"on"},"origin":"receiver","protocol":"elro_400_switch","uuid":"0000-b8-27-eb-ab55ca","repeats":1}
2016-04-09 22:43:04 pilight_ctrl FhemPi UNKNOWNCODE PISWITCH,elro_400_switch,1,15,on,1

hmm irgendwie komm ich hier alleine anscheinend nicht weiter :(

Risiko

Hallo erotikbaer,

für die pilight Module gibt es einen eigenen Thread.
https://forum.fhem.de/index.php/topic,34632.0.html
Dort wird dir geholfen  ;) Bitte aber erst einlesen