Mit 433MHz-Fernbedienung FHEM-Befehle steuern?

[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

[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.

Ich 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.   

[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.

Code Auswählen Erweitern


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]

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.

Code Auswählen Erweitern


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.

Code Auswählen Erweitern


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?

Code Auswählen Erweitern

define mypiNotify notify "mypi arctech_contact-17277950-7:closed" {}

[Wzut]

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

[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.

Code Auswählen Erweitern


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

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

2. Switch

Code Auswählen Erweitern


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

Beispiel für einen arctec_switch_old (Kaku, Intertechno)

Code Auswählen Erweitern


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 
Werde ich mir auf alle Fälle diese Woche  (vermutlich Di Abend ) mal genau anschauen

[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

[Wzut]

ein fertiges Modul welches sich pilight nennt?

doch

Ich habe jetzt hier nicht den ganzen Thread verfolgt

wenn du aber tun würdest hätte sich auch deine Frage geklärt

[Risiko]

Hallo.

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

Code Auswählen Erweitern


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


Info:
pilight 6.0 ist nun released

Risiko.

[Jens_B]

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