Mit 433MHz-Fernbedienung FHEM-Befehle steuern?

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

Vorheriges Thema - Nächstes Thema

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